Skip to contentSkip to conversation

New: Warning kmemcheck: Caught 64-bit read from uninitialized memory in netlink_broadcast_filtered

Bugme-new Applied Andrew Morton 6 participants 10 messages Jan 20, 2011 – Feb 15, 2011 1 message not in the archive

Subsystems (4)
Networking Network drivers Memory management Slab allocator
lore
Share & tools
lore

Andrew Morton

author maintainer
#1 lore raw
In reply to a message not in the archive

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 69 lines · On Thu, 20 Jan 2011 20:08:32 GMT [email protected] 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: [email protected]
ReportedBy: [email protected]
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.

#2 lore raw
Quoted 76 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 69 lines · On Thu, 20 Jan 2011 20:08:32 GMT [email protected] 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: [email protected]
ReportedBy: [email protected]
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.

#3 lore raw
Quoted 76 lines · Eric Dumazet
Quoted 75 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 69 lines · On Thu, 20 Jan 2011 20:08:32 GMT [email protected] 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: [email protected]
ReportedBy: [email protected]
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.

Quoted 8 lines

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

#9 lore raw
In reply to Andrew Morton
Quoted 75 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 69 lines · On Thu, 20 Jan 2011 20:08:32 GMT [email protected] 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: [email protected]
ReportedBy: [email protected]
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 <[email protected]>
Signed-off-by Eric Dumazet <[email protected]>
CC Andrew Morton <[email protected]>
---
 net/core/skbuff.c |    1 +
 1 files changed, 1 insertion(+)
net/core/skbuff.c +1 -0
index d31bb36..1762e97 100644
@@ -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;
maintainer Applied
#10 lore raw

From: Eric Dumazet <[email protected]>
Date: Wed, 26 Jan 2011 10:18:38 +0100

Quoted 9 lines

[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.

Quoted 6 lines

Resolves bugzilla.kernel.org 27212

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=27212

Reported-by Christian Casteyde <[email protected]>
Signed-off-by Eric Dumazet <[email protected]>
CC Andrew Morton <[email protected]>

Applied, thanks Eric.

#4 lore raw
In reply to Pekka Enberg
Quoted 5 lines · Pekka Enberg

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.

[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 <[email protected]>
Suggested-by Pekka Enberg <[email protected]>
Signed-off-by Eric Dumazet <[email protected]>
CC David Miller <[email protected]>
CC Changli Gao <[email protected]>
CC Andrew Morton <[email protected]>
---
 mm/slub.c |   49 ++++++++++++++++++++++++++-----------------------
 1 file changed, 26 insertions(+), 23 deletions(-)
mm/slub.c +26 -23
index e15aa7f..ee0aeb8 100644
@@ -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);
maintainer Acked-by
#5 lore raw

From: Eric Dumazet <[email protected]>
Date: Mon, 14 Feb 2011 18:35:22 +0100

Quoted 19 lines · Pekka Enberg
Quoted 6 lines

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.

[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.

Quoted 8 lines

Pekka Enberg noticed SLAB+kmemcheck is doing the right thing, while SLUB +kmemcheck doesnt.

Bugzilla reference #27212

Reported-by Christian Casteyde <[email protected]>
Suggested-by Pekka Enberg <[email protected]>
Signed-off-by Eric Dumazet <[email protected]>
Acked-by David S. Miller <[email protected]>
#6 lore raw
In reply to Eric Dumazet
Quoted 11 lines · Eric Dumazet
Quoted 5 lines · Pekka Enberg

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?

Quoted 108 lines

[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 <[email protected]>
Suggested-by Pekka Enberg <[email protected]>
Signed-off-by Eric Dumazet <[email protected]>
CC David Miller <[email protected]>
CC Changli Gao <[email protected]>
CC Andrew Morton <[email protected]>

---
 mm/slub.c |   49 ++++++++++++++++++++++++++-----------------------

 1 file changed, 26 insertions(+), 23 deletions(-)
mm/slub.c +26 -24
index e15aa7f..ee0aeb8 100644
@@ -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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Acked-by
#7 lore raw
Quoted 1 line · Pekka Enberg

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 <[email protected]>
reviewer Acked-by
#8 lore raw
In reply to Pekka Enberg
Quoted 10 lines · Pekka Enberg
Quoted 10 lines

[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.

Quoted 8 lines
Quoted 8 lines

Bugzilla reference #27212

Reported-by Christian Casteyde <[email protected]>
Suggested-by Pekka Enberg <[email protected]>
Signed-off-by Eric Dumazet <[email protected]>
CC David Miller <[email protected]>
CC Changli Gao <[email protected]>
CC Andrew Morton <[email protected]>
Acked-by David Rientjes <[email protected]>