* Re: [RFC 2/4] net: netfilter conntrack - add per-net functionality for DCCP protocol
From: Cyrill Gorcunov @ 2009-03-10 10:59 UTC (permalink / raw)
To: Daniel Lezcano
Cc: davem, kaber, netdev, linux-next, xemul, adobriyan,
Cyrill Gorcunov
In-Reply-To: <49B6420B.4080309@free.fr>
On Tue, Mar 10, 2009 at 1:33 PM, Daniel Lezcano <daniel.lezcano@free.fr> wrote:
> Daniel Lezcano wrote:
>>
>> Cyrill Gorcunov wrote:
>>>
>>> Module specific data moved into per-net site and being allocated/freed
>>> during net namespace creation/deletion.
>>>
>>> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
>>> ---
>>> net/netfilter/nf_conntrack_proto_dccp.c | 148
>>> ++++++++++++++++++++++++--------
>>> 1 file changed, 111 insertions(+), 37 deletions(-)
>>>
>>>
>>> static int __init nf_conntrack_proto_dccp_init(void)
>>> {
>>> int err;
>>> - err = nf_conntrack_l4proto_register(&dccp_proto4);
>>> + err = register_pernet_gen_device(&dccp_net_id, &dccp_net_ops);
>>>
>
> [ cut ]
>>
>> Shouldn't it be register_pernet_gen_subsys ?
No, I believe. By using register_pernet_gen_device I'm allowed to
not modify 'struct net' and friends and keep all I need in my own
pointer retrieved thru per-net gen-device id I've registered.
>
> If you use register_pernet_gen_device, your subsystem will be deleted before
> the network devices and potentially you can receive a packet even if your
> subsystem is already freed.
>
> Eric did a fix for tcp and icmp a few weeks ago. I thing its explanation is
> better than mine :)
> it is the commit 6eb0777228f31932fc941eafe8b08848466630a1 for net-2.6
>
> Thanks.
> -- Daniel
>
Thanks a lot Daniel, will check!
^ permalink raw reply
* Re: linux-next: Tree for March 10
From: Stephen Rothwell @ 2009-03-10 11:07 UTC (permalink / raw)
To: Wim Van Sebroeck; +Cc: linux-next, LKML
In-Reply-To: <20090310093324.GA26779@infomag.iguana.be>
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
Hi Wim,
On Tue, 10 Mar 2009 10:33:24 +0100 Wim Van Sebroeck <wim@iguana.be> wrote:
>
> > Merging watchdog/master
> > CONFLICT (content): Merge conflict in drivers/watchdog/orion5x_wdt.c
> > CONFLICT (content): Merge conflict in drivers/watchdog/rc32434_wdt.c
>
> I redid the linux-2.6-watchdog-next tree. Should be fixed next time.
Thanks. I could see that they were just continuations of patches that
went into Linus' tree, so was not worried about them.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC 2/4] net: netfilter conntrack - add per-net functionality for DCCP protocol
From: David Miller @ 2009-03-10 11:25 UTC (permalink / raw)
To: daniel.lezcano
Cc: gorcunov, kaber, netdev, linux-next, xemul, adobriyan, gorcunov
In-Reply-To: <49B63EA6.2060802@free.fr>
From: Daniel Lezcano <daniel.lezcano@free.fr>
Date: Tue, 10 Mar 2009 11:19:18 +0100
> > static int __init nf_conntrack_proto_dccp_init(void)
> > {
> > int err;
> > - err = nf_conntrack_l4proto_register(&dccp_proto4);
> > + err = register_pernet_gen_device(&dccp_net_id, &dccp_net_ops);
> >
>
> Shouldn't it be register_pernet_gen_subsys ?
Do I really have to carefully and meticuliously scan down
hundreds and hundreds of irrelevant quoted patch text just
to see what bit you're commenting on?
Please, just provide the necessary context of the patch for
your comments, don't quote the whole thing :-(
Thanks.
^ permalink raw reply
* Re: [RFC 2/4] net: netfilter conntrack - add per-net functionality for DCCP protocol
From: Pavel Emelyanov @ 2009-03-10 11:35 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Daniel Lezcano, davem, kaber, netdev, linux-next, adobriyan,
Cyrill Gorcunov
In-Reply-To: <aa79d98a0903100359x5cba797fu9611823b91c64b42@mail.gmail.com>
Cyrill Gorcunov wrote:
> On Tue, Mar 10, 2009 at 1:33 PM, Daniel Lezcano <daniel.lezcano@free.fr> wrote:
>> Daniel Lezcano wrote:
>>> Cyrill Gorcunov wrote:
>>>> Module specific data moved into per-net site and being allocated/freed
>>>> during net namespace creation/deletion.
>>>>
>>>> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
>>>> ---
>>>> net/netfilter/nf_conntrack_proto_dccp.c | 148
>>>> ++++++++++++++++++++++++--------
>>>> 1 file changed, 111 insertions(+), 37 deletions(-)
>>>>
>>>>
>>>> static int __init nf_conntrack_proto_dccp_init(void)
>>>> {
>>>> int err;
>>>> - err = nf_conntrack_l4proto_register(&dccp_proto4);
>>>> + err = register_pernet_gen_device(&dccp_net_id, &dccp_net_ops);
>>>>
>> [ cut ]
>>> Shouldn't it be register_pernet_gen_subsys ?
>
> No, I believe. By using register_pernet_gen_device I'm allowed to
> not modify 'struct net' and friends and keep all I need in my own
> pointer retrieved thru per-net gen-device id I've registered.
I believe Daniel means, that we need the register_xxx_get_subsys call
for subsystems, rather than devices, that will behave according to the
generic net pointers.
Daniel, am I right with this suggestion?
>> If you use register_pernet_gen_device, your subsystem will be deleted before
>> the network devices and potentially you can receive a packet even if your
>> subsystem is already freed.
>>
>> Eric did a fix for tcp and icmp a few weeks ago. I thing its explanation is
>> better than mine :)
>> it is the commit 6eb0777228f31932fc941eafe8b08848466630a1 for net-2.6
>>
>> Thanks.
>> -- Daniel
>>
>
> Thanks a lot Daniel, will check!
>
^ permalink raw reply
* Re: [RFC 2/4] net: netfilter conntrack - add per-net functionality for DCCP protocol
From: Cyrill Gorcunov @ 2009-03-10 11:51 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: Daniel Lezcano, davem, kaber, netdev, linux-next, adobriyan,
Cyrill Gorcunov
In-Reply-To: <49B65076.6090003@openvz.org>
On Tue, Mar 10, 2009 at 2:35 PM, Pavel Emelyanov <xemul@openvz.org> wrote:
...
>>>>> static int __init nf_conntrack_proto_dccp_init(void)
>>>>> {
>>>>> int err;
>>>>> - err = nf_conntrack_l4proto_register(&dccp_proto4);
>>>>> + err = register_pernet_gen_device(&dccp_net_id, &dccp_net_ops);
>>>>>
>>> [ cut ]
>>>> Shouldn't it be register_pernet_gen_subsys ?
>>
>> No, I believe. By using register_pernet_gen_device I'm allowed to
>> not modify 'struct net' and friends and keep all I need in my own
>> pointer retrieved thru per-net gen-device id I've registered.
>
> I believe Daniel means, that we need the register_xxx_get_subsys call
> for subsystems, rather than devices, that will behave according to the
> generic net pointers.
>
> Daniel, am I right with this suggestion?
>
...
Ah, yes, just checked register_pernet_gen_subsys -- it's what I need. Thanks!
^ permalink raw reply
* Re: [RFC 2/4] net: netfilter conntrack - add per-net functionality for DCCP protocol
From: Pavel Emelyanov @ 2009-03-10 11:56 UTC (permalink / raw)
To: Cyrill Gorcunov, Daniel Lezcano
Cc: davem, kaber, netdev, linux-next, adobriyan, Cyrill Gorcunov
In-Reply-To: <aa79d98a0903100451r6179ca61l3573cd8ae6e171b7@mail.gmail.com>
>> I believe Daniel means, that we need the register_xxx_get_subsys call
>> for subsystems, rather than devices, that will behave according to the
>> generic net pointers.
>>
>> Daniel, am I right with this suggestion?
>>
> ...
> Ah, yes, just checked register_pernet_gen_subsys -- it's what I need. Thanks!
>
Good. This would require some factorization work as well. Cyrill, your turn ;)
^ permalink raw reply
* next-20090310: ext4 hangs
From: Alexander Beregalov @ 2009-03-10 12:17 UTC (permalink / raw)
To: linux-next@vger.kernel.org, linux-ext4, LKML
Hi
It is similar to http://lkml.org/lkml/2009/2/6/304,
http://bugzilla.kernel.org/show_bug.cgi?id=12579
I run dbench on ext4 on loop on ext3 on sparc.
The kernel is 2.6.29-rc7-next-20090310
e2fsprogs -1.41.4
ioctl32(mkfs.ext4:1668): Unknown cmd fd(3) cmd(40041272){t:12;sz:4}
arg(ffb2ce60) on /testfs
ioctl32(mkfs.ext4:1668): Unknown cmd fd(3) cmd(20001260){t:12;sz:0}
arg(ffb2ce6c) on /testfs
ioctl32(mkfs.ext4:1668): Unknown cmd fd(3) cmd(401c0204){t:02;sz:28}
arg(ffb2ce44) on /testfs
ioctl32(mkfs.ext4:1668): Unknown cmd fd(3) cmd(20001268){t:12;sz:0}
arg(ffb2d564) on /testfs
ioctl32(mkfs.ext4:1668): Unknown cmd fd(3) cmd(2000125e){t:12;sz:0}
arg(ffb2ce6c) on /testfs
EXT4-fs: barriers enabled
EXT4 FS on loop0, internal journal on loop0:8
EXT4-fs: delayed allocation enabled
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs: mounted filesystem loop0 with ordered data mode
kjournald2 starting: pid 1672, dev loop0:8, commit interval 5 seconds
JBD: barrier-based sync failed on loop0:8 - disabling barriers
INFO: task kjournald2:1672 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kjournald2 D 0000000000557a0c 0 1672 2
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[0000000000557a0c] jbd2_journal_commit_transaction+0x208/0x1718
[000000000055d758] kjournald2+0x14c/0x318
[0000000000465d34] kthread+0x48/0x7c
[000000000042b364] kernel_thread+0x3c/0x54
[0000000000465c88] kthreadd+0xc8/0x12c
INFO: lockdep is turned off.
INFO: task dbench:1674 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
dbench D 000000000055716c 0 1674 1673
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052a9b8] ext4_dirty_inode+0xd4/0xf0
[00000000004d1a14] __mark_inode_dirty+0x2c/0x188
[00000000004c7714] touch_atime+0x160/0x178
[00000000004c2a3c] vfs_readdir+0x88/0xb0
[00000000004eab90] compat_sys_getdents+0x3c/0x8c
[0000000000406154] linux_sparc_syscall32+0x34/0x40
^ permalink raw reply
* Re: [RFC 2/4] net: netfilter conntrack - add per-net functionality for DCCP protocol
From: Daniel Lezcano @ 2009-03-10 12:43 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Pavel Emelyanov, davem, kaber, netdev, linux-next, adobriyan,
Cyrill Gorcunov
In-Reply-To: <aa79d98a0903100451r6179ca61l3573cd8ae6e171b7@mail.gmail.com>
Cyrill Gorcunov wrote:
> On Tue, Mar 10, 2009 at 2:35 PM, Pavel Emelyanov <xemul@openvz.org> wrote:
> ...
>
>>>>>> static int __init nf_conntrack_proto_dccp_init(void)
>>>>>> {
>>>>>> int err;
>>>>>> - err = nf_conntrack_l4proto_register(&dccp_proto4);
>>>>>> + err = register_pernet_gen_device(&dccp_net_id, &dccp_net_ops);
>>>>>>
>>>>>>
>>>> [ cut ]
>>>>
>>>>> Shouldn't it be register_pernet_gen_subsys ?
>>>>>
>>> No, I believe. By using register_pernet_gen_device I'm allowed to
>>> not modify 'struct net' and friends and keep all I need in my own
>>> pointer retrieved thru per-net gen-device id I've registered.
>>>
>> I believe Daniel means, that we need the register_xxx_get_subsys call
>> for subsystems, rather than devices, that will behave according to the
>> generic net pointers.
>>
>> Daniel, am I right with this suggestion?
>>
>>
Correct, otherwise that can lead to a kernel panic if you receive a
packet while the namespace is exiting.
> ...
> Ah, yes, just checked register_pernet_gen_subsys -- it's what I need. Thanks!
>
You are welcome :)
-- Daniel
^ permalink raw reply
* Re: next-20090310: ext4 hangs
From: Theodore Tso @ 2009-03-10 12:46 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next@vger.kernel.org, linux-ext4, LKML
In-Reply-To: <a4423d670903100517y42f342d4pd73c4c36f5c64dd7@mail.gmail.com>
On Tue, Mar 10, 2009 at 03:17:51PM +0300, Alexander Beregalov wrote:
> Hi
>
> It is similar to http://lkml.org/lkml/2009/2/6/304,
> http://bugzilla.kernel.org/show_bug.cgi?id=12579
>
> I run dbench on ext4 on loop on ext3 on sparc.
> The kernel is 2.6.29-rc7-next-20090310
> e2fsprogs -1.41.4
Thanks for reporting this; does it show up on stock 2.6.29-rc7? And
any chance you can enable LOCKDEP? Finally, how many CPU's do you
have on your machine?
Thanks again,
- Ted
^ permalink raw reply
* Re: next-20090310: ext4 hangs
From: Alexander Beregalov @ 2009-03-10 12:54 UTC (permalink / raw)
To: Theodore Tso, Alexander Beregalov, linux-next@vger.kernel.org,
linux-ext4, LKML
In-Reply-To: <20090310124658.GE8840@mit.edu>
2009/3/10 Theodore Tso <tytso@mit.edu>:
> On Tue, Mar 10, 2009 at 03:17:51PM +0300, Alexander Beregalov wrote:
>> Hi
>>
>> It is similar to http://lkml.org/lkml/2009/2/6/304,
>> http://bugzilla.kernel.org/show_bug.cgi?id=12579
>>
>> I run dbench on ext4 on loop on ext3 on sparc.
>> The kernel is 2.6.29-rc7-next-20090310
>> e2fsprogs -1.41.4
>
> Thanks for reporting this; does it show up on stock 2.6.29-rc7? And
> any chance you can enable LOCKDEP? Finally, how many CPU's do you
> have on your machine?
I will try it with current -git.
LOCkDEP is enabled already.
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
It is UP system.
^ permalink raw reply
* Re: [RFC 2/4] net: netfilter conntrack - add per-net functionality for DCCP protocol
From: Daniel Lezcano @ 2009-03-10 13:02 UTC (permalink / raw)
To: David Miller
Cc: gorcunov, kaber, netdev, linux-next, xemul, adobriyan, gorcunov
In-Reply-To: <20090310.042537.49464370.davem@davemloft.net>
David Miller wrote:
> From: Daniel Lezcano <daniel.lezcano@free.fr>
> Date: Tue, 10 Mar 2009 11:19:18 +0100
>
>
>>> static int __init nf_conntrack_proto_dccp_init(void)
>>> {
>>> int err;
>>> - err = nf_conntrack_l4proto_register(&dccp_proto4);
>>> + err = register_pernet_gen_device(&dccp_net_id, &dccp_net_ops);
>>>
>>>
>> Shouldn't it be register_pernet_gen_subsys ?
>>
>
> Do I really have to carefully and meticuliously scan down
> hundreds and hundreds of irrelevant quoted patch text just
> to see what bit you're commenting on?
>
> Please, just provide the necessary context of the patch for
> your comments, don't quote the whole thing :-(
>
Sorry, I will do that in the future.
-- Daniel
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Geert Uytterhoeven @ 2009-03-10 13:31 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, Jason Baron, Greg Banks, Herbert Xu,
Linux Kernel Development, Martin Schwidefsky
In-Reply-To: <20090310192440.949884a1.sfr@canb.auug.org.au>
On Tue, 10 Mar 2009, Stephen Rothwell wrote:
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> crypto/zlib.c: In function 'zlib_compress_update':
> crypto/zlib.c:148: warning: initialization makes integer from pointer without a cast
> crypto/zlib.c:148: error: initializer element is not computable at load time
> crypto/zlib.c:148: error: (near initialization for 'descriptor.primary_hash')
> crypto/zlib.c:148: warning: excess elements in struct initializer
> crypto/zlib.c:148: warning: (near initialization for 'descriptor')
>
> And many more similar. This line is a pr_debug() statement, so the
> finger points at commit 25b67b75587d43ff3f09ad88c03c70a38372d95d
> ("dynamic debug: combine dprintk and dynamic printk") from the
> driver-core tree.
>
> The preprocessed code looks like this:
>
> static int zlib_compress_update(struct crypto_pcomp *tfm,
> struct comp_request *req)
> {
> int ret;
> struct zlib_ctx *dctx = crypto_tfm_ctx(crypto_pcomp_tfm(tfm));
> struct z_stream_s *stream = &dctx->comp_stream;
>
> do { do { static struct _ddebug descriptor __attribute__((__used__)) __attribute__((section("__verbose"), aligned(8))) = { "zlib", __func__, "/scratch/sfr/next/crypto/zlib.c", "%s: " "avail_in %u, avail_out %u\n", __func__, 55, 33, 148, 0 }; if (({ int __ret = 0; if (__builtin_expect(!!((dynamic_debug_enabled & (1LL << 55)) && (dynamic_debug_enabled2 & (1LL << 33))), 0)) if (__builtin_expect(!!(descriptor.flags), 0)) __ret = 1; __ret; })) printk("<7>" "zlib" ":" "%s: " "avail_in %u, avail_out %u\n", __func__, req->avail_in, req->avail_out); } while (0); } while (0);
>
> The problem is the line:
>
> #define pr_fmt(fmt) "%s: " fmt, __func__
>
> in crypto/zlib.c which was introduced by commit
> bf68e65ec9ea61e32ab71bef59aa5d24d255241f ("crypto: zlib - New zlib crypto
> module, using pcomp") from the crypto tree.
>
> For today, I have removed the above line from crypto/zlib.c, but
> something better needs to be done for tomorrow!
I had a closer look. It happens on all archs, if CONFIG_DYNAMIC_DEBUG=y.
crypto/zlib.c has:
#define pr_fmt(fmt) "%s: " fmt, __func__
If CONFIG_DYNAMIC_DEBUG is set, include/linux/kernel.h has:
#define pr_debug(fmt, ...) do { \
dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
} while (0)
include/linux/dynamic_debug.h has:
#define dynamic_pr_debug(fmt, ...) do { \
static struct _ddebug descriptor \
__used \
__attribute__((section("__verbose"), aligned(8))) = \
{ KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH, \
DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
if (__dynamic_dbg_enabled(descriptor)) \
printk(KERN_DEBUG KBUILD_MODNAME ":" fmt, \
##__VA_ARGS__); \
} while (0)
So in crypto/zlib.c,
| pr_debug("avail_in %u, avail_out %u\n", req->avail_in, req->avail_out);
is expanded to
| do {
| do {
| static struct _ddebug descriptor
| __attribute__((__used__))
| __attribute__((section("__verbose"), aligned(8))) = {
| "zlib",
| __func__,
| "crypto/zlib.c",
| "%s: " "avail_in %u, avail_out %u\n",
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the actual format string
| __func__,
^^^^^^^^^
But this is the first parameter, which should not be here!!!
| 55,
| 33,
| 150,
| 0
| };
| if (({
| int __ret = 0;
| if (__builtin_expect(!!((dynamic_debug_enabled & (1LL << 55)) &&
| (dynamic_debug_enabled2 & (1LL << 33))), 0))
| if (__builtin_expect(!!(descriptor.flags), 0))
| __ret = 1;
| __ret;
| }))
| printk("<7>" "zlib" ":" "%s: " "avail_in %u, avail_out %u\n", __func__,
| req->avail_in, req->avail_out);
| } while (0);
| } while (0);
Due the the superfluous `__func__', all field members are shifted by one
position, and compilation breaks.
Apparently inside dynamic_pr_debug(), `fmt' is:
"avail_in %u, avail_out %u\n", __func__
instead of only the part before the comma:
"avail_in %u, avail_out %u\n"
For the non-CONFIG_DYNAMIC_DEBUG case, pr_debug() is expanded correctly:
DEBUG is defined:
#define pr_debug(fmt, ...) \
printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
and the line is expanded to:
| printk("<7>" "%s: " "avail_in %u, avail_out %u\n", __func__, req->avail_in, req->avail_out);
DEBUG is not defined:
#define pr_debug(fmt, ...) \
({ if (0) printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); 0; })
and the line is expanded to:
| ({ if (0) printk("<7>" "%s: " "avail_in %u, avail_out %u\n", __func__, req->avail_in, req->avail_out); 0; });
Why doesn't it work for dynamic_pr_debug()?
BTW, Martin: Is `#define pr_fmt(fmt) "%s: " fmt, __func__' a valid and
intended usage of your pr_fmt() infrastructure?
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Herbert Xu @ 2009-03-10 13:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, Greg KH, linux-next, Jason Baron, Greg Banks,
Linux Kernel Development, Martin Schwidefsky
In-Reply-To: <alpine.LRH.2.00.0903101423200.25436@vixen.sonytel.be>
On Tue, Mar 10, 2009 at 02:31:17PM +0100, Geert Uytterhoeven wrote:
>
> Why doesn't it work for dynamic_pr_debug()?
Because fmt is expanded twice?
> BTW, Martin: Is `#define pr_fmt(fmt) "%s: " fmt, __func__' a valid and
> intended usage of your pr_fmt() infrastructure?
I never liked this in the first place :) If anyone wants to debug
this they can add whatever printks they want.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Martin Schwidefsky @ 2009-03-10 13:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, Greg KH, linux-next, Jason Baron, Greg Banks,
Herbert Xu, Linux Kernel Development
In-Reply-To: <alpine.LRH.2.00.0903101423200.25436@vixen.sonytel.be>
On Tue, 10 Mar 2009 14:31:17 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> crypto/zlib.c has:
>
> #define pr_fmt(fmt) "%s: " fmt, __func__
>
> If CONFIG_DYNAMIC_DEBUG is set, include/linux/kernel.h has:
>
> #define pr_debug(fmt, ...) do { \
> dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
> } while (0)
>
> include/linux/dynamic_debug.h has:
>
> #define dynamic_pr_debug(fmt, ...) do { \
> static struct _ddebug descriptor \
> __used \
> __attribute__((section("__verbose"), aligned(8))) = \
> { KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH, \
> DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
> if (__dynamic_dbg_enabled(descriptor)) \
> printk(KERN_DEBUG KBUILD_MODNAME ":" fmt, \
> ##__VA_ARGS__); \
> } while (0)
The dynamic_pr_debug macro currently works only with pr_fmt definitions
that do not add additional parameters. The way how we use the pr_fmt
macro is:
#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
The same could be done with the problematic pr_fmt definition:
#define pr_fmt(fmt) __func__ ": " fmt
> BTW, Martin: Is `#define pr_fmt(fmt) "%s: " fmt, __func__' a valid and
> intended usage of your pr_fmt() infrastructure?
The indended use is a simple prefix to the format string. To paste an
additional parameter is an interesting use of the pr_fmt macro ..
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Next 10: Badness at mm/allocpercpu.c:123
From: Sachin P. Sant @ 2009-03-10 14:12 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, linuxppc-dev
In-Reply-To: <20090310195534.8f8f3c7a.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]
While booting Next 20090310 on a powerpc box (Power6 9117-MMA)
i observed the following badness :
[ 0.339662] ------------[ cut here ]------------
[ 0.339666] Badness at mm/allocpercpu.c:123
[ 0.339670] NIP: c0000000001129dc LR: c0000000001129b8 CTR: 0000000000000000
[ 0.339676] REGS: c0000000fe1efa10 TRAP: 0700 Not tainted (2.6.29-rc7-next-20090310)
[ 0.339681] MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24000024 XER: 20000002
[ 0.339695] TASK = c0000000fe1dd3d0[1] 'swapper' THREAD: c0000000fe1ec000 CPU: 0
[ 0.339701] GPR00: 0000000000000001 c0000000fe1efc90 c000000000948660 c0000000fe019000
[ 0.339711] GPR04: 0000000000000000 0000000000000000 c0000000fe019080 c00000000122e980
[ 0.339721] GPR08: 0000000000000000 c000000001467dec c0000000fe0e2610 c0000000fe1dd3d0
[ 0.339732] GPR12: 0000000044000022 c000000000a22300 c000000000733ad0 c00000000065e0c5
[ 0.339742] GPR16: 0000000003c33a08 0000000000000000 c000000000733a08 0000000002f1fc90
[ 0.339752] GPR20: c000000000733a20 c000000000679b30 0000000000000000 0000000002f1fc90
[ 0.339763] GPR24: 0000000000000000 0000000000000000 c000000000670ccd 0000000000000001
[ 0.339773] GPR28: c0000000fe019000 0000000000000080 c0000000008cb908 0000000000000100
[ 0.339788] NIP [c0000000001129dc] .__alloc_percpu+0x7c/0x244
[ 0.339793] LR [c0000000001129b8] .__alloc_percpu+0x58/0x244
[ 0.339798] Call Trace:
[ 0.339801] [c0000000fe1efc90] [c0000000001129b8] .__alloc_percpu+0x58/0x244 (unreliable)
[ 0.339810] [c0000000fe1efdc0] [c00000000007ce84] .__create_workqueue_key+0x74/0x2a0
[ 0.339819] [c0000000fe1efe70] [c000000000716990] .cpuset_init_smp+0x78/0xa4
[ 0.339827] [c0000000fe1eff00] [c000000000700334] .kernel_init+0x16c/0x224
[ 0.339834] [c0000000fe1eff90] [c00000000002adc8] .kernel_thread+0x54/0x70
[ 0.339839] Instruction dump:
[ 0.339843] 3863007f 78630624 4bffb94d 60000000 2bbd0008 7c7c1b78 40fd0030 e93e8010
[ 0.339856] 80090000 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41fe0010 e93e8010
I have attached the dmesg log here.
Next 20090306 had the same problem, while 20090305 did not.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: dmesg_next_20090310 --]
[-- Type: text/plain, Size: 12751 bytes --]
Using 006299d6 bytes for initrd buffer
Please wait, loading kernel...
Allocated 01600000 bytes for kernel @ 03500000
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded 006299d6 @ 01600000
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: root=/dev/sda5 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M
memory layout at init:
alloc_bottom : 00000000049c0000
alloc_top : 0000000008000000
alloc_top_hi : 0000000008000000
rmo_top : 0000000008000000
ram_top : 0000000008000000
Looking for displays
instantiating rtas at 0x00000000074e0000 ... done
boot cpu hw idx 0000000000000000
starting cpu hw idx 0000000000000002... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000004bd0000 -> 0x0000000004bd15d3
Device tree struct 0x0000000004be0000 -> 0x0000000004c00000
Calling quiesce ...
returning from prom_init
[ 0.000000] Crash kernel location must be 0x2000000
[ 0.000000] Reserving 256MB of memory at 32MB for crashkernel (System RAM: 4096MB)
[ 0.000000] Phyp-dump disabled at boot time
[ 0.000000] Using pSeries machine description
[ 0.000000] Using 1TB segments
[ 0.000000] Found initrd at 0xc000000001600000:0xc000000001c299d6
[ 0.000000] console [udbg0] enabled
[ 0.000000] Partition configured for 4 cpus.
[ 0.000000] CPU maps initialized for 2 threads per core
[ 0.000000] Starting Linux PPC64 #1 SMP Tue Mar 10 17:25:05 IST 2009
[ 0.000000] -----------------------------------------------------
[ 0.000000] ppc64_pft_size = 0x1a
[ 0.000000] physicalMemorySize = 0x100000000
[ 0.000000] htab_hash_mask = 0x7ffff
[ 0.000000] -----------------------------------------------------
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.29-rc7-next-20090310 (root@llm62) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Tue Mar 10 17:25:05 IST 2009
[ 0.000000] [boot]0012 Setup Arch
[ 0.000000] EEH: No capable adapters found
[ 0.000000] PPC64 nvram contains 15360 bytes
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000000 -> 0x00010000
[ 0.000000] Normal 0x00010000 -> 0x00010000
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0x00000000 -> 0x00010000
[ 0.000000] [boot]0015 Setup Done
[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 65448
[ 0.000000] Policy zone: DMA
[ 0.000000] Kernel command line: root=/dev/sda5 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M
[ 0.000000] NR_IRQS:512
[ 0.000000] [boot]0020 XICS Init
[ 0.000000] [boot]0021 XICS Done
[ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[ 0.000000] clocksource: timebase mult[7d0000] shift[22] registered
[ 0.000054] Console: colour dummy device 80x25
[ 0.000086] console handover: boot [udbg0] -> real [hvc0]
[ 0.000113] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.000118] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.000121] ... MAX_LOCK_DEPTH: 48
[ 0.000124] ... MAX_LOCKDEP_KEYS: 8191
[ 0.000128] ... CLASSHASH_SIZE: 4096
[ 0.000132] ... MAX_LOCKDEP_ENTRIES: 8192
[ 0.000135] ... MAX_LOCKDEP_CHAINS: 16384
[ 0.000139] ... CHAINHASH_SIZE: 8192
[ 0.000142] memory used by lock dependency info: 4607 kB
[ 0.000146] per task-struct memory footprint: 1920 bytes
[ 0.000476] Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes)
[ 0.001534] Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes)
[ 0.002663] allocated 2621440 bytes of page_cgroup
[ 0.002667] please try cgroup_disable=memory option if you don't want
[ 0.002672] freeing bootmem node 0
[ 0.079853] Memory: 3864320k/4194304k available (7552k kernel code, 329984k reserved, 1984k data, 10855k bss, 384k init)
[ 0.080373] Calibrating delay loop... 1022.36 BogoMIPS (lpj=5111808)
[ 0.330475] Security Framework initialized
[ 0.330481] SELinux: Disabled at boot.
[ 0.330541] Mount-cache hash table entries: 4096
[ 0.333232] Initializing cgroup subsys ns
[ 0.333237] Initializing cgroup subsys cpuacct
[ 0.333242] Initializing cgroup subsys memory
[ 0.333251] Initializing cgroup subsys devices
[ 0.333257] Initializing cgroup subsys freezer
[ 0.334039] Processor 1 found.
[ 0.338524] Processor 2 found.
[ 0.339010] Processor 3 found.
[ 0.339021] Brought up 4 CPUs
[ 0.339662] ------------[ cut here ]------------
[ 0.339666] Badness at mm/allocpercpu.c:123
[ 0.339670] NIP: c0000000001129dc LR: c0000000001129b8 CTR: 0000000000000000
[ 0.339676] REGS: c0000000fe1efa10 TRAP: 0700 Not tainted (2.6.29-rc7-next-20090310)
[ 0.339681] MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24000024 XER: 20000002
[ 0.339695] TASK = c0000000fe1dd3d0[1] 'swapper' THREAD: c0000000fe1ec000 CPU: 0
[ 0.339701] GPR00: 0000000000000001 c0000000fe1efc90 c000000000948660 c0000000fe019000
[ 0.339711] GPR04: 0000000000000000 0000000000000000 c0000000fe019080 c00000000122e980
[ 0.339721] GPR08: 0000000000000000 c000000001467dec c0000000fe0e2610 c0000000fe1dd3d0
[ 0.339732] GPR12: 0000000044000022 c000000000a22300 c000000000733ad0 c00000000065e0c5
[ 0.339742] GPR16: 0000000003c33a08 0000000000000000 c000000000733a08 0000000002f1fc90
[ 0.339752] GPR20: c000000000733a20 c000000000679b30 0000000000000000 0000000002f1fc90
[ 0.339763] GPR24: 0000000000000000 0000000000000000 c000000000670ccd 0000000000000001
[ 0.339773] GPR28: c0000000fe019000 0000000000000080 c0000000008cb908 0000000000000100
[ 0.339788] NIP [c0000000001129dc] .__alloc_percpu+0x7c/0x244
[ 0.339793] LR [c0000000001129b8] .__alloc_percpu+0x58/0x244
[ 0.339798] Call Trace:
[ 0.339801] [c0000000fe1efc90] [c0000000001129b8] .__alloc_percpu+0x58/0x244 (unreliable)
[ 0.339810] [c0000000fe1efdc0] [c00000000007ce84] .__create_workqueue_key+0x74/0x2a0
[ 0.339819] [c0000000fe1efe70] [c000000000716990] .cpuset_init_smp+0x78/0xa4
[ 0.339827] [c0000000fe1eff00] [c000000000700334] .kernel_init+0x16c/0x224
[ 0.339834] [c0000000fe1eff90] [c00000000002adc8] .kernel_thread+0x54/0x70
[ 0.339839] Instruction dump:
[ 0.339843] 3863007f 78630624 4bffb94d 60000000 2bbd0008 7c7c1b78 40fd0030 e93e8010
[ 0.339856] 80090000 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41fe0010 e93e8010
[ 0.348162] net_namespace: 2160 bytes
[ 0.348476] NET: Registered protocol family 16
[ 0.348532] IBM eBus Device Driver
[ 0.352290] PCI: Probing PCI hardware
[ 0.354439] bio: create slab <bio-0> at 0
[ 0.355321] SCSI subsystem initialized
[ 0.355468] usbcore: registered new interface driver usbfs
[ 0.355500] usbcore: registered new interface driver hub
[ 0.355577] usbcore: registered new device driver usb
[ 0.380869] NET: Registered protocol family 2
[ 0.470537] IP route cache hash table entries: 32768 (order: 2, 262144 bytes)
[ 0.471080] TCP established hash table entries: 131072 (order: 5, 2097152 bytes)
[ 0.471514] TCP bind hash table entries: 65536 (order: 5, 3670016 bytes)
[ 0.473611] TCP: Hash tables configured (established 131072 bind 65536)
[ 0.473618] TCP reno registered
[ 0.500558] NET: Registered protocol family 1
[ 0.500632] Unpacking initramfs... done
[ 0.645207] Freeing initrd memory: 6310k freed
[ 0.658465] IOMMU table initialized, virtual merging enabled
[ 0.659595] ====[ backtrace testing ]===========
[ 0.659599] Testing a backtrace from process context.
[ 0.659603] The following trace is a kernel self test and not a bug!
[ 0.659607] Call Trace:
[ 0.659613] [c0000000fe1efc70] [c000000000011608] .show_stack+0x6c/0x16c (unreliable)
[ 0.659622] [c0000000fe1efd20] [c0000000000a6758] .backtrace_regression_test+0x44/0x134
[ 0.659630] [c0000000fe1efe10] [c000000000009254] .do_one_initcall+0x80/0x1a4
[ 0.659638] [c0000000fe1eff00] [c000000000700370] .kernel_init+0x1a8/0x224
[ 0.659645] [c0000000fe1eff90] [c00000000002adc8] .kernel_thread+0x54/0x70
[ 0.659650] Testing a backtrace from irq context.
[ 0.659654] The following trace is a kernel self test and not a bug!
[ 0.659664] Call Trace:
[ 0.659668] [c000000001f9fcf0] [c000000000011608] .show_stack+0x6c/0x16c (unreliable)
[ 0.659676] [c000000001f9fda0] [c0000000000a66f0] .backtrace_test_irq_callback+0x18/0x3c
[ 0.659684] [c000000001f9fe20] [c00000000006bfa0] .tasklet_action+0x100/0x1d0
[ 0.659691] [c000000001f9fec0] [c00000000006ce20] .__do_softirq+0xe8/0x1f8
[ 0.659698] [c000000001f9ff90] [c00000000002ac04] .call_do_softirq+0x14/0x24
[ 0.659704] [c0000000fe257db0] [c00000000000d4fc] .do_softirq+0x90/0x110
[ 0.659711] [c0000000fe257e50] [c00000000006c49c] .ksoftirqd+0xbc/0x18c
[ 0.659718] [c0000000fe257f00] [c000000000081cec] .kthread+0x80/0xcc
[ 0.659725] [c0000000fe257f90] [c00000000002adc8] .kernel_thread+0x54/0x70
[ 0.659733] Testing a saved backtrace.
[ 0.659736] The following trace is a kernel self test and not a bug!
[ 0.659741] [<c0000000000a680c>] .backtrace_regression_test+0xf8/0x134
[ 0.659747] [<c000000000009254>] .do_one_initcall+0x80/0x1a4
[ 0.659753] [<c000000000700370>] .kernel_init+0x1a8/0x224
[ 0.659759] [<c00000000002adc8>] .kernel_thread+0x54/0x70
[ 0.659764] ====[ end of backtrace testing ]====
[ 0.659795] audit: initializing netlink socket (disabled)
[ 0.659810] type=2000 audit(1236686641.658:1): initialized
[ 0.679339] Kprobe smoke test started
[ 0.890631] Kprobe smoke test passed successfully
[ 0.890700] rcu-torture:--- Start of test: nreaders=8 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1
[ 0.891677] HugeTLB registered 16 MB page size, pre-allocated 0 pages
[ 0.891682] HugeTLB registered 16 GB page size, pre-allocated 0 pages
[ 0.892086] VFS: Disk quotas dquot_6.5.2
[ 0.892203] Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
[ 0.892884] msgmni has been set to 7556
[ 0.893258] alg: No test for stdrng (krng)
[ 0.893329] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
[ 0.893335] io scheduler noop registered
[ 0.893339] io scheduler anticipatory registered
[ 0.893343] io scheduler deadline registered
[ 0.893396] io scheduler cfq registered (default)
[ 0.893490] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 0.893495] rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
[ 0.895965] Generic RTC Driver v1.07
[ 0.895999] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 0.896309] input: Macintosh mouse button emulation as /devices/virtual/input/input0
[ 0.896362] Uniform Multi-Platform E-IDE driver
[ 0.896423] ide-gd driver 1.18
[ 0.896625] ibmvscsi 30000002: SRP_VERSION: 16.a
[ 0.896717] scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
[ 0.896983] ibmvscsi 30000002: partner initialization complete
[ 0.896991] ibmvscsi 30000002: sent SRP login
[ 0.897062] ibmvscsi 30000002: SRP_LOGIN succeeded
[ 0.897104] ibmvscsi 30000002: host srp version: 16.a, host partition VIO (1), OS 3, max io 1048576
[ 0.910829] scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3
[ 0.911151] scsi 0:0:2:0: CD-ROM AIX VOPTA PQ: 0 ANSI: 4
[ 0.966517] ibmvfc: IBM Virtual Fibre Channel Driver version: 1.0.4 (November 14, 2008)
[ 0.966616] scsi 0:0:1:0: Attached scsi generic sg0 type 0
[ 0.966661] scsi 0:0:2:0: Attached scsi generic sg1 type 5
[ 0.966739] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.966793] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.966835] uhci_hcd: USB Universal Host Controller Interface driver
[ 1.000469] mice: PS/2 mouse device common for all mice
[ 1.040547] EDAC MC: Ver: 2.1.0 Mar 10 2009
[ 1.041711] usbcore: registered new interface driver hiddev
[ 1.041743] usbcore: registered new interface driver usbhid
[ 1.041749] usbhid: v2.6:USB HID core driver
[ 1.042399] TCP cubic registered
[ 1.042405] NET: Registered protocol family 15
[ 1.042574] registered taskstats version 1
[ 1.042745] Freeing unused kernel memory: 384k freed
doing fast boot
[ 1.074740] SysRq : Changing Loglevel
[ 1.074747] Loglevel set to 1
FATAL: Module ibmvscsic not found.
Creating device nodes with udev
Boot logging started on /dev/hvc0(/dev/console) at Tue Mar 10 12:04:02 2009
^ permalink raw reply
* Re: next-20090310: ext4 hangs
From: Alexander Beregalov @ 2009-03-10 14:18 UTC (permalink / raw)
To: Theodore Tso, linux-next@vger.kernel.org, linux-ext4, LKML
In-Reply-To: <20090310124658.GE8840@mit.edu>
2009/3/10 Theodore Tso <tytso@mit.edu>:
> On Tue, Mar 10, 2009 at 03:17:51PM +0300, Alexander Beregalov wrote:
>> Hi
>>
>> It is similar to http://lkml.org/lkml/2009/2/6/304,
>> http://bugzilla.kernel.org/show_bug.cgi?id=12579
>>
>> I run dbench on ext4 on loop on ext3 on sparc.
>> The kernel is 2.6.29-rc7-next-20090310
>> e2fsprogs -1.41.4
>
> Thanks for reporting this; does it show up on stock 2.6.29-rc7?
No, I can not reproduce it.
It is a slow system, I would not like to bisect it, only if it is the
last possibility.
^ permalink raw reply
* Re: linux-next: manual merge of the lblnet tree with Linus' tree
From: Paul Moore @ 2009-03-10 15:00 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Dave Jones, Matthew Garrett
In-Reply-To: <20090310171334.bd6d51fb.sfr@canb.auug.org.au>
On Tuesday 10 March 2009 02:13:34 am Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next merge of the lblnet tree got a conflict in
> Documentation/feature-removal-schedule.txt between commit
> 753b7aea8e4611433c13ac157f944d8b4bf42482 ("[CPUFREQ] Add p4-clockmod
> sysfs-ui removal to feature-removal schedule") from Linus' tree and
> commit 4c7098cc3b1ccf2930bfb866e108e6cd10f4b2f3 ("selinux: Remove the
> "compat_net" compatibility code") from the lblnet tree.
>
> Just overlapping additions/removal. I fixed it up (see below) and can
> carry the fix for a while.
Thanks Stephen, I just updated the lblnet tree so there should be no conflict
here come tomorrow.
--
paul moore
linux @ hp
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Geert Uytterhoeven @ 2009-03-10 15:29 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Stephen Rothwell, Greg KH, linux-next, Jason Baron, Greg Banks,
Herbert Xu, Linux Kernel Development
In-Reply-To: <20090310145311.6bf9d9e9@skybase>
On Tue, 10 Mar 2009, Martin Schwidefsky wrote:
> On Tue, 10 Mar 2009 14:31:17 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> > crypto/zlib.c has:
> >
> > #define pr_fmt(fmt) "%s: " fmt, __func__
> >
> > If CONFIG_DYNAMIC_DEBUG is set, include/linux/kernel.h has:
> >
> > #define pr_debug(fmt, ...) do { \
> > dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
> > } while (0)
> >
> > include/linux/dynamic_debug.h has:
> >
> > #define dynamic_pr_debug(fmt, ...) do { \
> > static struct _ddebug descriptor \
> > __used \
> > __attribute__((section("__verbose"), aligned(8))) = \
> > { KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH, \
> > DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
> > if (__dynamic_dbg_enabled(descriptor)) \
> > printk(KERN_DEBUG KBUILD_MODNAME ":" fmt, \
> > ##__VA_ARGS__); \
> > } while (0)
>
> The dynamic_pr_debug macro currently works only with pr_fmt definitions
> that do not add additional parameters. The way how we use the pr_fmt
> macro is:
>
> #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
>
> The same could be done with the problematic pr_fmt definition:
>
> #define pr_fmt(fmt) __func__ ": " fmt
No, that also doesn't work:
| crypto/zlib.c:150: error: expected '}' before string constant
| crypto/zlib.c:150: error: expected ')' before '__func__'
| crypto/zlib.c:162: error: expected '}' before string constant
| crypto/zlib.c:162: error: expected ')' before '__func__'
| crypto/zlib.c:166: error: expected '}' before string constant
| crypto/zlib.c:166: error: expected ')' before '__func__'
| crypto/zlib.c:170: error: expected '}' before string constant
| crypto/zlib.c:170: error: expected ')' before '__func__'
> > BTW, Martin: Is `#define pr_fmt(fmt) "%s: " fmt, __func__' a valid and
> > intended usage of your pr_fmt() infrastructure?
>
> The indended use is a simple prefix to the format string. To paste an
> additional parameter is an interesting use of the pr_fmt macro ..
Bummer, I was so happy I could do things like
| #define pr_fmt(fmt) "%s:%u: " fmt, __func__, __LINE__
...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: next-20090310: ext4 hangs
From: Theodore Tso @ 2009-03-10 15:47 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next@vger.kernel.org, linux-ext4, LKML
In-Reply-To: <a4423d670903100718w1a532143he767782ae598d0fb@mail.gmail.com>
On Tue, Mar 10, 2009 at 05:18:55PM +0300, Alexander Beregalov wrote:
> > Thanks for reporting this; does it show up on stock 2.6.29-rc7?
> No, I can not reproduce it.
> It is a slow system, I would not like to bisect it, only if it is the
> last possibility.
Just to be clear; you weren't able to reproduce it on stock 2.6.29-rc7
---- does it reproduce easily on linux-next?
Next question --- does the system hang completely, or just the dbench
process (and probably any process that tries touching the filesystem
that's hung up)? Do you have a serial console, or someone of
recording all of the dumps coming from sysrq-t? The two stack traces
you gave weren't the ones causing the problem, but rather the ones
waiting for the journal lock.
I don't think is related to BZ #12579, although some of the symptoms
look superficially the same.
- Ted
P.S. What are your dbench parameters, and how big is your filesystem,
so I can try to reproduce it on my side? And how long do you
typically need to run before this triggers? Thanks!
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Martin Schwidefsky @ 2009-03-10 16:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, Greg KH, linux-next, Jason Baron, Greg Banks,
Herbert Xu, Linux Kernel Development
In-Reply-To: <alpine.LRH.2.00.0903101626450.25436@vixen.sonytel.be>
On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > The same could be done with the problematic pr_fmt definition:
> >
> > #define pr_fmt(fmt) __func__ ": " fmt
>
> No, that also doesn't work:
>
> | crypto/zlib.c:150: error: expected '}' before string constant
> | crypto/zlib.c:150: error: expected ')' before '__func__'
> | crypto/zlib.c:162: error: expected '}' before string constant
> | crypto/zlib.c:162: error: expected ')' before '__func__'
> | crypto/zlib.c:166: error: expected '}' before string constant
> | crypto/zlib.c:166: error: expected ')' before '__func__'
> | crypto/zlib.c:170: error: expected '}' before string constant
> | crypto/zlib.c:170: error: expected ')' before '__func__'
>
> > > BTW, Martin: Is `#define pr_fmt(fmt) "%s: " fmt, __func__' a valid and
> > > intended usage of your pr_fmt() infrastructure?
> >
> > The indended use is a simple prefix to the format string. To paste an
> > additional parameter is an interesting use of the pr_fmt macro ..
>
> Bummer, I was so happy I could do things like
>
> | #define pr_fmt(fmt) "%s:%u: " fmt, __func__, __LINE__
Actually that seem like a nice thing to have. With the upstream version of
dynamic_pr_debug this works, there the format string is used only on a printk.
git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
that pastes the format string to the _ddebug structure.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: linux-next: Tree for March 10 (crypto & NLATTR)
From: Randy Dunlap @ 2009-03-10 18:57 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, herbert, David Miller, linux-crypto
In-Reply-To: <20090310195534.8f8f3c7a.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20090306:
>
>
> The driver-core tree gained a build failure due to a conflict with the
> crypto tree. I have applied a patch to the crypto tree for today.
I had several (4 of 50) randconfig builds fail with:
lib/built-in.o: In function `__nla_reserve_nohdr':
(.text+0xd08d): undefined reference to `skb_put'
lib/built-in.o: In function `__nla_reserve':
(.text+0xd121): undefined reference to `skb_put'
lib/built-in.o: In function `nla_append':
(.text+0xd493): undefined reference to `skb_put'
which happens with CONFIG_NET=n, CONFIG_CRYPTO=y, CONFIG_CRYPTO_ZLIB=[my].
CRYPTO_ZLIB selects NLATTR, but obviously the build of nlattr.c fails
when CONFIG_NET=n. Should CRYPTO_ZLIB depend on NET?
Please don't say that CRYPTO_ZLIB should select NET.
--
~Randy
^ permalink raw reply
* [PATCH -next] staging/p9auth: fix dependency/build error
From: Randy Dunlap @ 2009-03-10 18:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Greg KH
In-Reply-To: <20090310195534.8f8f3c7a.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix p9auth dependency/build failure. It needs to depend on
CRYPTO.
p9auth.c:(.text+0x107297): undefined reference to `crypto_alloc_base'
p9auth.c:(.text+0x1073d4): undefined reference to `crypto_destroy_tfm'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/staging/p9auth/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20090310.orig/drivers/staging/p9auth/Kconfig
+++ linux-next-20090310/drivers/staging/p9auth/Kconfig
@@ -1,6 +1,7 @@
config PLAN9AUTH
tristate "Plan 9 style capability device implementation"
default n
+ depends on CRYPTO
help
This module implements the Plan 9 style capability device.
^ permalink raw reply
* Re: linux-next: Tree for March 10 (crypto & NLATTR)
From: Geert Uytterhoeven @ 2009-03-10 19:56 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, herbert, David Miller,
linux-crypto
In-Reply-To: <49B6B821.5050302@oracle.com>
On Tue, Mar 10, 2009 at 19:57, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Stephen Rothwell wrote:
>> Changes since 20090306:
>>
>>
>> The driver-core tree gained a build failure due to a conflict with the
>> crypto tree. I have applied a patch to the crypto tree for today.
>
> I had several (4 of 50) randconfig builds fail with:
>
> lib/built-in.o: In function `__nla_reserve_nohdr':
> (.text+0xd08d): undefined reference to `skb_put'
> lib/built-in.o: In function `__nla_reserve':
> (.text+0xd121): undefined reference to `skb_put'
> lib/built-in.o: In function `nla_append':
> (.text+0xd493): undefined reference to `skb_put'
>
> which happens with CONFIG_NET=n, CONFIG_CRYPTO=y, CONFIG_CRYPTO_ZLIB=[my].
>
> CRYPTO_ZLIB selects NLATTR, but obviously the build of nlattr.c fails
> when CONFIG_NET=n. Should CRYPTO_ZLIB depend on NET?
> Please don't say that CRYPTO_ZLIB should select NET.
Bummer, my fault (commit e9cc8bddaea3944fabfebb968bc88d603239beed,
netlink: Move netlink attribute parsing support to lib).
Obviously I was only worried about crypto/zlib.c needing nlattr.c
without pulling in the whole networking code, not about nlattr.c
itself needing networking functionality. But still, how could I have
missed this compile failure?
Does it sound sane to protect the routines that do call skb_put() by
#ifdef CONFIG_NET?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Jason Baron @ 2009-03-10 20:02 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Geert Uytterhoeven, Stephen Rothwell, Greg KH, linux-next,
Greg Banks, Herbert Xu, Linux Kernel Development
In-Reply-To: <20090310170841.2257de86@skybase>
On Tue, Mar 10, 2009 at 05:08:41PM +0100, Martin Schwidefsky wrote:
> On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> > > The same could be done with the problematic pr_fmt definition:
> > >
> > > #define pr_fmt(fmt) __func__ ": " fmt
> >
> > No, that also doesn't work:
> >
> > | crypto/zlib.c:150: error: expected '}' before string constant
> > | crypto/zlib.c:150: error: expected ')' before '__func__'
> > | crypto/zlib.c:162: error: expected '}' before string constant
> > | crypto/zlib.c:162: error: expected ')' before '__func__'
> > | crypto/zlib.c:166: error: expected '}' before string constant
> > | crypto/zlib.c:166: error: expected ')' before '__func__'
> > | crypto/zlib.c:170: error: expected '}' before string constant
> > | crypto/zlib.c:170: error: expected ')' before '__func__'
> >
> > > > BTW, Martin: Is `#define pr_fmt(fmt) "%s: " fmt, __func__' a valid and
> > > > intended usage of your pr_fmt() infrastructure?
> > >
> > > The indended use is a simple prefix to the format string. To paste an
> > > additional parameter is an interesting use of the pr_fmt macro ..
> >
> > Bummer, I was so happy I could do things like
> >
> > | #define pr_fmt(fmt) "%s:%u: " fmt, __func__, __LINE__
>
> Actually that seem like a nice thing to have. With the upstream version of
> dynamic_pr_debug this works, there the format string is used only on a printk.
> git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
> that pastes the format string to the _ddebug structure.
>
hmmm...yeah, some macro magic in include/linux/dynamic_debug.h converts
the 'fmt' arg into a series of strings. It doesn't look as pretty in the
dynamic debug control file:
crypto/zlib.c:333 [zlib]zlib_decompress_final - "\042%s: \042
\042avail_in %u, avail_out %u (consumed %u, produced %u)\n\042,
__func__"
with all those '\042' there, which are the '"' characters, but we
probably could live with it.
patch below.
thanks,
-Jason
Signed-off-by: Jason Baron <jbaron@redhat.com>
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 07781aa..16cf212 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -50,28 +50,30 @@ extern int ddebug_remove_module(char *mod_name);
__ret = 1; \
__ret; })
-#define dynamic_pr_debug(fmt, ...) do { \
- static struct _ddebug descriptor \
- __used \
- __attribute__((section("__verbose"), aligned(8))) = \
- { KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH, \
- DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
- if (__dynamic_dbg_enabled(descriptor)) \
- printk(KERN_DEBUG KBUILD_MODNAME ":" fmt, \
- ##__VA_ARGS__); \
+#define STRINGIFY(args...) #args
+
+#define dynamic_pr_debug(fmt, ...) do { \
+ static struct _ddebug descriptor \
+ __used \
+ __attribute__((section("__verbose"), aligned(8))) = \
+ { KBUILD_MODNAME, __func__, __FILE__, STRINGIFY(fmt), DEBUG_HASH, \
+ DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
+ if (__dynamic_dbg_enabled(descriptor)) \
+ printk(KERN_DEBUG KBUILD_MODNAME ":" fmt, \
+ ##__VA_ARGS__); \
} while (0)
-#define dynamic_dev_dbg(dev, fmt, ...) do { \
- static struct _ddebug descriptor \
- __used \
- __attribute__((section("__verbose"), aligned(8))) = \
- { KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH, \
- DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
- if (__dynamic_dbg_enabled(descriptor)) \
- dev_printk(KERN_DEBUG, dev, \
- KBUILD_MODNAME ": " fmt, \
- ##__VA_ARGS__); \
+#define dynamic_dev_dbg(dev, fmt, ...) do { \
+ static struct _ddebug descriptor \
+ __used \
+ __attribute__((section("__verbose"), aligned(8))) = \
+ { KBUILD_MODNAME, __func__, __FILE__, STRINGIFY(fmt), DEBUG_HASH, \
+ DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
+ if (__dynamic_dbg_enabled(descriptor)) \
+ dev_printk(KERN_DEBUG, dev, \
+ KBUILD_MODNAME ": " fmt, \
+ ##__VA_ARGS__); \
} while (0)
#else
^ permalink raw reply related
* Re: linux-next: manual merge of the sound tree with the arm tree
From: Mark Brown @ 2009-03-10 20:04 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Takashi Iwai, linux-next, Ben Dooks, Alexander Schulz,
Russell King
In-Reply-To: <20090310144528.0fa208dd.sfr@canb.auug.org.au>
On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> I fixed it up (see below) and can carry the fix as necessary.
I've pushed a patch which should do the equivalent thing to Takashi, it
should hopefully show up in -next soon via his tree.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox