Athlon 64 X2 3000 in 64bits Slackware64 13.1 Kernel compiled with kmemcheck and other debug options At boot I got the following warning: PCI: Using ACPI for IRQ routing PCI: pci_cache_line_size set to 64 bytes pci 0000:00:00.0: address space collision: [mem 0xe0000000-0xefffffff pref] conflicts with GART [mem 0x e0000000-0xefffffff] reserve RAM buffer: 000000000009fc00 - 000000000009ffff reserve RAM buffer: 000000003ffb0000 - 000000003fffffff WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff88003e170eb0) 0000000000000000010000000000000000000000000000000000000000000000 i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u u ^ Pid: 1, comm: swapper Not tainted 2.6.38-rc1 #2 K8 Combo-Z/K8 Combo-Z RIP: 0010:[<ffffffff8127ad72>] [<ffffffff8127ad72>] memmove+0x122/0x1a0 RSP: 0018:ffff88003e0b3c60 EFLAGS: 00010202 RAX: ffff88003e170080 RBX: ffff88003e27b500 RCX: 0000000000000020 RDX: 0000000000000018 RSI: ffff88003e170ea0 RDI: ffff88003e1700a0 RBP: ffff88003e0b3c60 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff88003e018abc CR3: 0000000001a1c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 [<ffffffff814741c2>] pskb_expand_head+0xc2/0x2a0 [<ffffffff81498fa7>] netlink_broadcast_filtered+0xa7/0x4a0 [<ffffffff814993b8>] netlink_broadcast+0x18/0x20 [<ffffffff8149b884>] genlmsg_mcast+0x144/0x180 [<ffffffff8149bc4a>] genl_ctrl_event+0xca/0x450 [<ffffffff8149c75d>] genl_register_mc_group+0x10d/0x2a0 [<ffffffff81ad9da4>] genl_init+0x6c/0x84 [<ffffffff810001de>] do_one_initcall+0x3e/0x170 [<ffffffff81aae6ea>] kernel_init+0x197/0x21b [<ffffffff81003254>] kernel_thread_helper+0x4/0x10 [<ffffffffffffffff>] 0xffffffffffffffff pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:00: [bus 00-ff] pnp 00:00: [io 0x0cf8-0x0cff] This is specific to 2.6.38-rc1.
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 20 Jan 2011 20:08:32 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=27212 > > Summary: Warning kmemcheck: Caught 64-bit read from > uninitialized memory in netlink_broadcast_filtered > Product: Other > Version: 2.5 > Kernel Version: 2.6.38-rc1 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: other_other@kernel-bugs.osdl.org > ReportedBy: casteyde.christian@free.fr > Regression: Yes > > > Athlon 64 X2 3000 in 64bits > Slackware64 13.1 > Kernel compiled with kmemcheck and other debug options > > At boot I got the following warning: > > PCI: Using ACPI for IRQ routing > PCI: pci_cache_line_size set to 64 bytes > pci 0000:00:00.0: address space collision: [mem 0xe0000000-0xefffffff pref] > conflicts with GART [mem 0x > e0000000-0xefffffff] > reserve RAM buffer: 000000000009fc00 - 000000000009ffff > reserve RAM buffer: 000000003ffb0000 - 000000003fffffff > WARNING: kmemcheck: Caught 64-bit read from uninitialized memory > (ffff88003e170eb0) > 0000000000000000010000000000000000000000000000000000000000000000 > i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u u > ^ > > Pid: 1, comm: swapper Not tainted 2.6.38-rc1 #2 K8 Combo-Z/K8 Combo-Z > RIP: 0010:[<ffffffff8127ad72>] [<ffffffff8127ad72>] memmove+0x122/0x1a0 > RSP: 0018:ffff88003e0b3c60 EFLAGS: 00010202 > RAX: ffff88003e170080 RBX: ffff88003e27b500 RCX: 0000000000000020 > RDX: 0000000000000018 RSI: ffff88003e170ea0 RDI: ffff88003e1700a0 > RBP: ffff88003e0b3c60 R08: 0000000000000001 R09: 0000000000000001 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001 > FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: ffff88003e018abc CR3: 0000000001a1c000 CR4: 00000000000006f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 > [<ffffffff814741c2>] pskb_expand_head+0xc2/0x2a0 > [<ffffffff81498fa7>] netlink_broadcast_filtered+0xa7/0x4a0 > [<ffffffff814993b8>] netlink_broadcast+0x18/0x20 > [<ffffffff8149b884>] genlmsg_mcast+0x144/0x180 > [<ffffffff8149bc4a>] genl_ctrl_event+0xca/0x450 > [<ffffffff8149c75d>] genl_register_mc_group+0x10d/0x2a0 > [<ffffffff81ad9da4>] genl_init+0x6c/0x84 > [<ffffffff810001de>] do_one_initcall+0x3e/0x170 > [<ffffffff81aae6ea>] kernel_init+0x197/0x21b > [<ffffffff81003254>] kernel_thread_helper+0x4/0x10 > [<ffffffffffffffff>] 0xffffffffffffffff > pnp: PnP ACPI init > ACPI: bus type pnp registered > pnp 00:00: [bus 00-ff] > pnp 00:00: [io 0x0cf8-0x0cff] > > This is specific to 2.6.38-rc1. >
Le jeudi 20 janvier 2011 à 12:25 -0800, Andrew Morton a écrit : > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Thu, 20 Jan 2011 20:08:32 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=27212 > > > > Summary: Warning kmemcheck: Caught 64-bit read from > > uninitialized memory in netlink_broadcast_filtered > > Product: Other > > Version: 2.5 > > Kernel Version: 2.6.38-rc1 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: other_other@kernel-bugs.osdl.org > > ReportedBy: casteyde.christian@free.fr > > Regression: Yes > > > > > > Athlon 64 X2 3000 in 64bits > > Slackware64 13.1 > > Kernel compiled with kmemcheck and other debug options > > > > At boot I got the following warning: > > > > PCI: Using ACPI for IRQ routing > > PCI: pci_cache_line_size set to 64 bytes > > pci 0000:00:00.0: address space collision: [mem 0xe0000000-0xefffffff pref] > > conflicts with GART [mem 0x > > e0000000-0xefffffff] > > reserve RAM buffer: 000000000009fc00 - 000000000009ffff > > reserve RAM buffer: 000000003ffb0000 - 000000003fffffff > > WARNING: kmemcheck: Caught 64-bit read from uninitialized memory > > (ffff88003e170eb0) > > 0000000000000000010000000000000000000000000000000000000000000000 > > i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u u > > ^ > > > > Pid: 1, comm: swapper Not tainted 2.6.38-rc1 #2 K8 Combo-Z/K8 Combo-Z > > RIP: 0010:[<ffffffff8127ad72>] [<ffffffff8127ad72>] memmove+0x122/0x1a0 > > RSP: 0018:ffff88003e0b3c60 EFLAGS: 00010202 > > RAX: ffff88003e170080 RBX: ffff88003e27b500 RCX: 0000000000000020 > > RDX: 0000000000000018 RSI: ffff88003e170ea0 RDI: ffff88003e1700a0 > > RBP: ffff88003e0b3c60 R08: 0000000000000001 R09: 0000000000000001 > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001 > > FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) > knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > > CR2: ffff88003e018abc CR3: 0000000001a1c000 CR4: 00000000000006f0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 > > [<ffffffff814741c2>] pskb_expand_head+0xc2/0x2a0 > > [<ffffffff81498fa7>] netlink_broadcast_filtered+0xa7/0x4a0 > > [<ffffffff814993b8>] netlink_broadcast+0x18/0x20 > > [<ffffffff8149b884>] genlmsg_mcast+0x144/0x180 > > [<ffffffff8149bc4a>] genl_ctrl_event+0xca/0x450 > > [<ffffffff8149c75d>] genl_register_mc_group+0x10d/0x2a0 > > [<ffffffff81ad9da4>] genl_init+0x6c/0x84 > > [<ffffffff810001de>] do_one_initcall+0x3e/0x170 > > [<ffffffff81aae6ea>] kernel_init+0x197/0x21b > > [<ffffffff81003254>] kernel_thread_helper+0x4/0x10 > > [<ffffffffffffffff>] 0xffffffffffffffff > > pnp: PnP ACPI init > > ACPI: bus type pnp registered > > pnp 00:00: [bus 00-ff] > > pnp 00:00: [io 0x0cf8-0x0cff] > > > > This is specific to 2.6.38-rc1. > > > Likely a false positive after commit ca44ac38 (net: don't reallocate skb->head unless the current one hasn't the needed extra size or is shared) ksize() allows us to use a bit more than what was asked at kmalloc() time, because of discrete kmem caches sizes. We probably need to instruct kmemcheck of this.
Reply-To: penberg@kernel.org On 1/20/11 10:41 PM, Eric Dumazet wrote: > Le jeudi 20 janvier 2011 à 12:25 -0800, Andrew Morton a écrit : >> (switched to email. Please respond via emailed reply-to-all, not via the >> bugzilla web interface). >> >> On Thu, 20 Jan 2011 20:08:32 GMT >> bugzilla-daemon@bugzilla.kernel.org wrote: >> >>> https://bugzilla.kernel.org/show_bug.cgi?id=27212 >>> >>> Summary: Warning kmemcheck: Caught 64-bit read from >>> uninitialized memory in netlink_broadcast_filtered >>> Product: Other >>> Version: 2.5 >>> Kernel Version: 2.6.38-rc1 >>> Platform: All >>> OS/Version: Linux >>> Tree: Mainline >>> Status: NEW >>> Severity: normal >>> Priority: P1 >>> Component: Other >>> AssignedTo: other_other@kernel-bugs.osdl.org >>> ReportedBy: casteyde.christian@free.fr >>> Regression: Yes >>> >>> >>> Athlon 64 X2 3000 in 64bits >>> Slackware64 13.1 >>> Kernel compiled with kmemcheck and other debug options >>> >>> At boot I got the following warning: >>> >>> PCI: Using ACPI for IRQ routing >>> PCI: pci_cache_line_size set to 64 bytes >>> pci 0000:00:00.0: address space collision: [mem 0xe0000000-0xefffffff pref] >>> conflicts with GART [mem 0x >>> e0000000-0xefffffff] >>> reserve RAM buffer: 000000000009fc00 - 000000000009ffff >>> reserve RAM buffer: 000000003ffb0000 - 000000003fffffff >>> WARNING: kmemcheck: Caught 64-bit read from uninitialized memory >>> (ffff88003e170eb0) >>> 0000000000000000010000000000000000000000000000000000000000000000 >>> i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u u >>> ^ >>> >>> Pid: 1, comm: swapper Not tainted 2.6.38-rc1 #2 K8 Combo-Z/K8 Combo-Z >>> RIP: 0010:[<ffffffff8127ad72>] [<ffffffff8127ad72>] memmove+0x122/0x1a0 >>> RSP: 0018:ffff88003e0b3c60 EFLAGS: 00010202 >>> RAX: ffff88003e170080 RBX: ffff88003e27b500 RCX: 0000000000000020 >>> RDX: 0000000000000018 RSI: ffff88003e170ea0 RDI: ffff88003e1700a0 >>> RBP: ffff88003e0b3c60 R08: 0000000000000001 R09: 0000000000000001 >>> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 >>> R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001 >>> FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) >>> knlGS:0000000000000000 >>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >>> CR2: ffff88003e018abc CR3: 0000000001a1c000 CR4: 00000000000006f0 >>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>> DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 >>> [<ffffffff814741c2>] pskb_expand_head+0xc2/0x2a0 >>> [<ffffffff81498fa7>] netlink_broadcast_filtered+0xa7/0x4a0 >>> [<ffffffff814993b8>] netlink_broadcast+0x18/0x20 >>> [<ffffffff8149b884>] genlmsg_mcast+0x144/0x180 >>> [<ffffffff8149bc4a>] genl_ctrl_event+0xca/0x450 >>> [<ffffffff8149c75d>] genl_register_mc_group+0x10d/0x2a0 >>> [<ffffffff81ad9da4>] genl_init+0x6c/0x84 >>> [<ffffffff810001de>] do_one_initcall+0x3e/0x170 >>> [<ffffffff81aae6ea>] kernel_init+0x197/0x21b >>> [<ffffffff81003254>] kernel_thread_helper+0x4/0x10 >>> [<ffffffffffffffff>] 0xffffffffffffffff >>> pnp: PnP ACPI init >>> ACPI: bus type pnp registered >>> pnp 00:00: [bus 00-ff] >>> pnp 00:00: [io 0x0cf8-0x0cff] >>> >>> This is specific to 2.6.38-rc1. >>> > Likely a false positive after commit ca44ac38 > (net: don't reallocate skb->head unless the current one hasn't the > needed extra size or is shared) > > ksize() allows us to use a bit more than what was asked at kmalloc() > time, because of discrete kmem caches sizes. > > We probably need to instruct kmemcheck of this. It actually looks like a bug in SLUB+kmemcheck. The kmemcheck_slab_alloc() call in slab_post_alloc_hook() should use ksize() instead of s->objsize. SLAB seems to do the right thing already. Anyone care to send a patch my way? Pekka
Le jeudi 20 janvier 2011 à 12:25 -0800, Andrew Morton a écrit : > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Thu, 20 Jan 2011 20:08:32 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=27212 > > > > Summary: Warning kmemcheck: Caught 64-bit read from > > uninitialized memory in netlink_broadcast_filtered > > Product: Other > > Version: 2.5 > > Kernel Version: 2.6.38-rc1 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: other_other@kernel-bugs.osdl.org > > ReportedBy: casteyde.christian@free.fr > > Regression: Yes > > > > > > Athlon 64 X2 3000 in 64bits > > Slackware64 13.1 > > Kernel compiled with kmemcheck and other debug options > > > > At boot I got the following warning: > > > > PCI: Using ACPI for IRQ routing > > PCI: pci_cache_line_size set to 64 bytes > > pci 0000:00:00.0: address space collision: [mem 0xe0000000-0xefffffff pref] > > conflicts with GART [mem 0x > > e0000000-0xefffffff] > > reserve RAM buffer: 000000000009fc00 - 000000000009ffff > > reserve RAM buffer: 000000003ffb0000 - 000000003fffffff > > WARNING: kmemcheck: Caught 64-bit read from uninitialized memory > > (ffff88003e170eb0) > > 0000000000000000010000000000000000000000000000000000000000000000 > > i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u u > > ^ > > > > Pid: 1, comm: swapper Not tainted 2.6.38-rc1 #2 K8 Combo-Z/K8 Combo-Z > > RIP: 0010:[<ffffffff8127ad72>] [<ffffffff8127ad72>] memmove+0x122/0x1a0 > > RSP: 0018:ffff88003e0b3c60 EFLAGS: 00010202 > > RAX: ffff88003e170080 RBX: ffff88003e27b500 RCX: 0000000000000020 > > RDX: 0000000000000018 RSI: ffff88003e170ea0 RDI: ffff88003e1700a0 > > RBP: ffff88003e0b3c60 R08: 0000000000000001 R09: 0000000000000001 > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001 > > FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) > knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > > CR2: ffff88003e018abc CR3: 0000000001a1c000 CR4: 00000000000006f0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 > > [<ffffffff814741c2>] pskb_expand_head+0xc2/0x2a0 > > [<ffffffff81498fa7>] netlink_broadcast_filtered+0xa7/0x4a0 > > [<ffffffff814993b8>] netlink_broadcast+0x18/0x20 > > [<ffffffff8149b884>] genlmsg_mcast+0x144/0x180 > > [<ffffffff8149bc4a>] genl_ctrl_event+0xca/0x450 > > [<ffffffff8149c75d>] genl_register_mc_group+0x10d/0x2a0 > > [<ffffffff81ad9da4>] genl_init+0x6c/0x84 > > [<ffffffff810001de>] do_one_initcall+0x3e/0x170 > > [<ffffffff81aae6ea>] kernel_init+0x197/0x21b > > [<ffffffff81003254>] kernel_thread_helper+0x4/0x10 > > [<ffffffffffffffff>] 0xffffffffffffffff > > pnp: PnP ACPI init > > ACPI: bus type pnp registered > > pnp 00:00: [bus 00-ff] > > pnp 00:00: [io 0x0cf8-0x0cff] > > > > This is specific to 2.6.38-rc1. > > [PATCH] net: add kmemcheck annotation in __alloc_skb() pskb_expand_head() triggers a kmemcheck warning when copy of skb_shared_info is done in pskb_expand_head() This is because destructor_arg field is not necessarily initialized at this point. Add kmemcheck_annotate_variable() call in __alloc_skb() to instruct kmemcheck this is a normal situation. Resolves bugzilla.kernel.org 27212 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=27212 Reported-by: Christian Casteyde <casteyde.christian@free.fr> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> CC: Andrew Morton <akpm@linux-foundation.org> --- net/core/skbuff.c | 1 + 1 files changed, 1 insertion(+) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index d31bb36..1762e97 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -210,6 +210,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask, shinfo = skb_shinfo(skb); memset(shinfo, 0, offsetof(struct skb_shared_info, dataref)); atomic_set(&shinfo->dataref, 1); + kmemcheck_annotate_variable(shinfo->destructor_arg); if (fclone) { struct sk_buff *child = skb + 1;
From: Eric Dumazet <eric.dumazet@gmail.com> Date: Wed, 26 Jan 2011 10:18:38 +0100 > [PATCH] net: add kmemcheck annotation in __alloc_skb() > > pskb_expand_head() triggers a kmemcheck warning when copy of > skb_shared_info is done in pskb_expand_head() > > This is because destructor_arg field is not necessarily initialized at > this point. Add kmemcheck_annotate_variable() call in __alloc_skb() to > instruct kmemcheck this is a normal situation. > > Resolves bugzilla.kernel.org 27212 > > Reference: https://bugzilla.kernel.org/show_bug.cgi?id=27212 > Reported-by: Christian Casteyde <casteyde.christian@free.fr> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> > CC: Andrew Morton <akpm@linux-foundation.org> Applied, thanks Eric.
Update: Still present in -rc4, even if the previous patch was applied. On another computer (a laptop, the previous one is retired), I get the following warning, that seems to be exactly the same: eth1: RX AssocResp from c2:2a:2e:a2:2e:38 (capab=0x411 status=0 aid=1) eth1: associated ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff88004b234400) 0000000000000000010000000000000000000000000000000000000000000000 u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u ^ Pid: 1883, comm: dhcpcd Not tainted 2.6.38-rc4 #2 Aspire 1510/Aspire 1510 RIP: 0010:[<ffffffff81257b00>] [<ffffffff81257b00>] memmove+0x30/0x1a0 RSP: 0018:ffff88004bbf9898 EFLAGS: 00010206 RAX: ffff88004b234400 RBX: ffff88004ba6ce00 RCX: 0000000000000020 RDX: 000000000000016f RSI: ffff88004b234400 RDI: ffff88004b234400 RBP: ffff88004bbf9898 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000200 R14: 0000000000000000 R15: 0000000000000001 FS: 00007fc8ae8f3700(0000) GS:ffffffff81a1b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff88004a82fcb8 CR3: 000000004b281000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 [<ffffffff8146cff8>] pskb_expand_head+0xd8/0x2a0 [<ffffffff815b060b>] ieee80211_skb_resize+0x9b/0x120 [<ffffffff815b29e4>] ieee80211_xmit+0xa4/0x280 [<ffffffff815b41a6>] ieee80211_subif_start_xmit+0x3e6/0x910 [<ffffffff81476f44>] dev_hard_start_xmit+0x384/0x6a0 [<ffffffff8148d354>] sch_direct_xmit+0xd4/0x260 [<ffffffff81477432>] dev_queue_xmit+0x1d2/0x6f0 [<ffffffff81554f5e>] packet_sendmsg+0x9de/0xba0 [<ffffffff814628aa>] sock_sendmsg+0xba/0xf0 [<ffffffff814631f4>] sys_sendto+0x134/0x180 [<ffffffff81002478>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff eth1: no IPv6 routers present Please note that this is a wireless network on that laptop (broadcom BCM 43xx).
Reply-To: penberg@kernel.org On Mon, Feb 14, 2011 at 7:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le vendredi 21 janvier 2011 à 09:49 +0200, Pekka Enberg a écrit : > >> It actually looks like a bug in SLUB+kmemcheck. The >> kmemcheck_slab_alloc() call in slab_post_alloc_hook() should use ksize() >> instead of s->objsize. SLAB seems to do the right thing already. Anyone >> care to send a patch my way? >> > > Hmm, what do you think of following patch ? > > Thanks, and sorry for the delay. Looks good to me. Christoph, David, any objections to the patch? > [PATCH] slub: fix kmemcheck calls to match ksize() hints > > Recent use of ksize() in network stack (commit ca44ac38 : net: don't > reallocate skb->head unless the current one hasn't the needed extra size > or is shared) triggers kmemcheck warnings, because ksize() can return > more space than kmemcheck is aware of. > > Pekka Enberg noticed SLAB+kmemcheck is doing the right thing, while SLUB > +kmemcheck doesnt. > > Bugzilla reference #27212 > > Reported-by: Christian Casteyde <casteyde.christian@free.fr> > Suggested-by: Pekka Enberg <penberg@kernel.org> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> > CC: David Miller <davem@davemloft.net> > CC: Changli Gao <xiaosuo@gmail.com> > CC: Andrew Morton <akpm@linux-foundation.org> > --- > mm/slub.c | 49 ++++++++++++++++++++++++++----------------------- > 1 file changed, 26 insertions(+), 23 deletions(-) > > diff --git a/mm/slub.c b/mm/slub.c > index e15aa7f..ee0aeb8 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -797,10 +797,34 @@ static inline int slab_pre_alloc_hook(struct kmem_cache > *s, gfp_t flags) > return should_failslab(s->objsize, flags, s->flags); > } > > +static inline size_t slab_ksize(const struct kmem_cache *s) > +{ > +#ifdef CONFIG_SLUB_DEBUG > + /* > + * Debugging requires use of the padding between object > + * and whatever may come after it. > + */ > + if (s->flags & (SLAB_RED_ZONE | SLAB_POISON)) > + return s->objsize; > + > +#endif > + /* > + * If we have the need to store the freelist pointer > + * back there or track user information then we can > + * only use the space before that information. > + */ > + if (s->flags & (SLAB_DESTROY_BY_RCU | SLAB_STORE_USER)) > + return s->inuse; > + /* > + * Else we can use all the padding etc for the allocation > + */ > + return s->size; > +} > + > static inline void slab_post_alloc_hook(struct kmem_cache *s, gfp_t flags, > void *object) > { > flags &= gfp_allowed_mask; > - kmemcheck_slab_alloc(s, flags, object, s->objsize); > + kmemcheck_slab_alloc(s, flags, object, slab_ksize(s)); > kmemleak_alloc_recursive(object, s->objsize, 1, s->flags, flags); > } > > @@ -2696,7 +2720,6 @@ EXPORT_SYMBOL(__kmalloc_node); > size_t ksize(const void *object) > { > struct page *page; > - struct kmem_cache *s; > > if (unlikely(object == ZERO_SIZE_PTR)) > return 0; > @@ -2707,28 +2730,8 @@ size_t ksize(const void *object) > WARN_ON(!PageCompound(page)); > return PAGE_SIZE << compound_order(page); > } > - s = page->slab; > > -#ifdef CONFIG_SLUB_DEBUG > - /* > - * Debugging requires use of the padding between object > - * and whatever may come after it. > - */ > - if (s->flags & (SLAB_RED_ZONE | SLAB_POISON)) > - return s->objsize; > - > -#endif > - /* > - * If we have the need to store the freelist pointer > - * back there or track user information then we can > - * only use the space before that information. > - */ > - if (s->flags & (SLAB_DESTROY_BY_RCU | SLAB_STORE_USER)) > - return s->inuse; > - /* > - * Else we can use all the padding etc for the allocation > - */ > - return s->size; > + return slab_ksize(page->slab); > } > EXPORT_SYMBOL(ksize); > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
Reply-To: cl@linux.com On Tue, 15 Feb 2011, Pekka Enberg wrote: > Looks good to me. Christoph, David, any objections to the patch? My eyes hurt. Is there some way you could use tabs or spaces instead of these weird symbols? If the kmemcheck people are fine with checking data beyond the last byte of the object then its fine with me. Acked-by: Christoph Lameter <cl@linux.com>
On Tue, 15 Feb 2011, Pekka Enberg wrote: > > [PATCH] slub: fix kmemcheck calls to match ksize() hints > > > > Recent use of ksize() in network stack (commit ca44ac38 : net: don't > > reallocate skb->head unless the current one hasn't the needed extra size > > or is shared) triggers kmemcheck warnings, because ksize() can return > > more space than kmemcheck is aware of. > > > > Pekka Enberg noticed SLAB+kmemcheck is doing the right thing, while SLUB > > +kmemcheck doesnt. > > > > Bugzilla reference #27212 > > > > Reported-by: Christian Casteyde <casteyde.christian@free.fr> > > Suggested-by: Pekka Enberg <penberg@kernel.org> > > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> > > CC: David Miller <davem@davemloft.net> > > CC: Changli Gao <xiaosuo@gmail.com> > > CC: Andrew Morton <akpm@linux-foundation.org> Acked-by: David Rientjes <rientjes@google.com>
merged in .38-rc4: commit c2aa3665cf8510b1665ee2f5a9525cf7be6dec4f Author: Eric Dumazet <eric.dumazet@gmail.com> Date: Tue Jan 25 23:18:38 2011 +0000 net: add kmemcheck annotation in __alloc_skb()
Update : Still present in 2.6.38-rc6.
A patch referencing this bug report has been merged in v2.6.38-8876-g036a982: commit b3d41885d9cd0d9db31c8f49e362bae02c96fa3f Author: Eric Dumazet <eric.dumazet@gmail.com> Date: Mon Feb 14 18:35:22 2011 +0100 slub: fix kmemcheck calls to match ksize() hints
Seems to be fixed in 2.6.38. Closing.
Really? That patch went in after 2.6.38 and has not been backported yet...
Yes, I didn't managed to reproduce it with 2.6.38. I won't check it once more, but I'm testing 2.6.39-rc1 and will check that once more.
2.6.39-rc1 has a similar, but different, bug (will open another bug): WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff88004ab13d00) 003eb14a0088ffffb6d50b81ffffffff44616544000000000000000000000000 u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u ^ Pid: 1768, comm: ifconfig Not tainted 2.6.39-rc1 #3 Acer,Inc. Aspire 1510 /Aspire 1510 RIP: 0010:[<ffffffff810b9c5d>] [<ffffffff810b9c5d>] __kmalloc+0xbd/0x1d0 RSP: 0018:ffff88004b8dba78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000010 RCX: 00000000000057e1 RDX: 00000000000057e0 RSI: ffff88004fcbf100 RDI: ffffffff8177bcc2 RBP: ffff88004b8dbaa8 R08: ffff880040bb6000 R09: ffff880040444c80 R10: 0000000000000000 R11: ffff880040444ca8 R12: ffff88004ab13d00 R13: ffff88004dc03600 R14: 00000000000080d0 R15: ffffffff814f827d FS: 00007fbfd42f4700(0000) GS:ffffffff81a1b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff88004ddd39c0 CR3: 000000004b8c9000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 [<ffffffff814f827d>] tnode_new+0x3d/0x80 [<ffffffff814f9b4c>] fib_table_insert+0x69c/0x850 [<ffffffff814f3230>] fib_magic+0xb0/0xc0 [<ffffffff814f32b1>] fib_add_ifaddr+0x71/0x180 [<ffffffff814f4490>] fib_inetaddr_event+0x30/0xb0 [<ffffffff810588e3>] notifier_call_chain+0x83/0x100 [<ffffffff81058c46>] __blocking_notifier_call_chain+0x76/0xb0 [<ffffffff81058c91>] blocking_notifier_call_chain+0x11/0x20 [<ffffffff814e8553>] __inet_insert_ifa+0x1a3/0x240 [<ffffffff814ea2b5>] devinet_ioctl+0x465/0x8d0 [<ffffffff814ebd34>] inet_ioctl+0x84/0xa0 [<ffffffff8146b1cd>] T.1014+0x1d/0x50 [<ffffffff8146b46d>] sock_ioctl+0x5d/0x2b0 [<ffffffff810cfe4c>] do_vfs_ioctl+0x9c/0x560 [<ffffffff810d035a>] sys_ioctl+0x4a/0x80 [<ffffffff815de4f8>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff So I've checked 2.6.38.2 to see if it's a regression, and indeed it is. And btw I confirm 2.6.38.2 does not have the problem reported here anymore, maybe it was fixed another way by somebody else.
Very likely. Thanks for testing. I'm changing the resolution to unreproducible then, as the commit above obviously doesn't fix this.