2019-05-17 18:09:54

by Dmitry Vyukov

[permalink] [raw]
Subject: [PATCH] kmemleak: fix check for softirq context

From: Dmitry Vyukov <[email protected]>

in_softirq() is a wrong predicate to check if we are in a softirq context.
It also returns true if we have BH disabled, so objects are falsely
stamped with "softirq" comm. The correct predicate is in_serving_softirq().

Signed-off-by: Dmitry Vyukov <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
mm/kmemleak.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index e57bf810f7983..6584ff9778895 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -588,7 +588,7 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size,
if (in_irq()) {
object->pid = 0;
strncpy(object->comm, "hardirq", sizeof(object->comm));
- } else if (in_softirq()) {
+ } else if (in_serving_softirq()) {
object->pid = 0;
strncpy(object->comm, "softirq", sizeof(object->comm));
} else {
--
2.21.0.1020.gf2820cf01a-goog


2019-05-17 21:43:18

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH] kmemleak: fix check for softirq context

On Fri, 17 May 2019 19:15:07 +0200 Dmitry Vyukov <[email protected]> wrote:

> From: Dmitry Vyukov <[email protected]>
>
> in_softirq() is a wrong predicate to check if we are in a softirq context.
> It also returns true if we have BH disabled, so objects are falsely
> stamped with "softirq" comm. The correct predicate is in_serving_softirq().
>
> ...
>
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -588,7 +588,7 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size,
> if (in_irq()) {
> object->pid = 0;
> strncpy(object->comm, "hardirq", sizeof(object->comm));
> - } else if (in_softirq()) {
> + } else if (in_serving_softirq()) {
> object->pid = 0;
> strncpy(object->comm, "softirq", sizeof(object->comm));
> } else {

What are the user-visible runtime effects of this change?

2019-05-18 07:52:18

by Dmitry Vyukov

[permalink] [raw]
Subject: Re: [PATCH] kmemleak: fix check for softirq context

On Fri, May 17, 2019 at 11:37 PM Andrew Morton
<[email protected]> wrote:
>
> On Fri, 17 May 2019 19:15:07 +0200 Dmitry Vyukov <[email protected]> wrote:
>
> > From: Dmitry Vyukov <[email protected]>
> >
> > in_softirq() is a wrong predicate to check if we are in a softirq context.
> > It also returns true if we have BH disabled, so objects are falsely
> > stamped with "softirq" comm. The correct predicate is in_serving_softirq().
> >
> > ...
> >
> > --- a/mm/kmemleak.c
> > +++ b/mm/kmemleak.c
> > @@ -588,7 +588,7 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size,
> > if (in_irq()) {
> > object->pid = 0;
> > strncpy(object->comm, "hardirq", sizeof(object->comm));
> > - } else if (in_softirq()) {
> > + } else if (in_serving_softirq()) {
> > object->pid = 0;
> > strncpy(object->comm, "softirq", sizeof(object->comm));
> > } else {
>
> What are the user-visible runtime effects of this change?


If user does cat from /sys/kernel/debug/kmemleak previously they would
see this, which is clearly wrong, this is system call context (see the
comm):

unreferenced object 0xffff88805bd661c0 (size 64):
comm "softirq", pid 0, jiffies 4294942959 (age 12.400s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
backtrace:
[<0000000007dcb30c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<0000000007dcb30c>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000007dcb30c>] slab_alloc mm/slab.c:3326 [inline]
[<0000000007dcb30c>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<00000000969722b7>] kmalloc include/linux/slab.h:547 [inline]
[<00000000969722b7>] kzalloc include/linux/slab.h:742 [inline]
[<00000000969722b7>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
[<00000000969722b7>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
[<00000000a4134b5f>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
[<00000000d20248ad>] do_ip_setsockopt.isra.0+0x19fe/0x1c00
net/ipv4/ip_sockglue.c:957
[<000000003d367be7>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
[<000000003c7c76af>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
[<000000000c1aeb23>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130
[<000000000157b92b>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078
[<00000000a9f3d058>] __do_sys_setsockopt net/socket.c:2089 [inline]
[<00000000a9f3d058>] __se_sys_setsockopt net/socket.c:2086 [inline]
[<00000000a9f3d058>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
[<000000001b8da885>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301
[<00000000ba770c62>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

now they will see this:

unreferenced object 0xffff88805413c800 (size 64):
comm "syz-executor.4", pid 8960, jiffies 4294994003 (age 14.350s)
hex dump (first 32 bytes):
00 7a 8a 57 80 88 ff ff e0 00 00 01 00 00 00 00 .z.W............
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
backtrace:
[<00000000c5d3be64>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000c5d3be64>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000c5d3be64>] slab_alloc mm/slab.c:3326 [inline]
[<00000000c5d3be64>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<0000000023865be2>] kmalloc include/linux/slab.h:547 [inline]
[<0000000023865be2>] kzalloc include/linux/slab.h:742 [inline]
[<0000000023865be2>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
[<0000000023865be2>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
[<000000003029a9d4>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
[<00000000ccd0a87c>] do_ip_setsockopt.isra.0+0x19fe/0x1c00
net/ipv4/ip_sockglue.c:957
[<00000000a85a3785>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
[<00000000ec13c18d>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
[<0000000052d748e3>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130
[<00000000512f1014>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078
[<00000000181758bc>] __do_sys_setsockopt net/socket.c:2089 [inline]
[<00000000181758bc>] __se_sys_setsockopt net/socket.c:2086 [inline]
[<00000000181758bc>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
[<00000000d4b73623>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301
[<00000000c1098bec>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

2019-05-18 09:57:59

by Catalin Marinas

[permalink] [raw]
Subject: Re: [PATCH] kmemleak: fix check for softirq context

On Sat, May 18, 2019 at 09:10:59AM +0200, Dmitry Vyukov wrote:
> On Fri, May 17, 2019 at 11:37 PM Andrew Morton
> <[email protected]> wrote:
> > On Fri, 17 May 2019 19:15:07 +0200 Dmitry Vyukov <[email protected]> wrote:
> >
> > > From: Dmitry Vyukov <[email protected]>
> > >
> > > in_softirq() is a wrong predicate to check if we are in a softirq context.
> > > It also returns true if we have BH disabled, so objects are falsely
> > > stamped with "softirq" comm. The correct predicate is in_serving_softirq().
> > >
> > > ...
> > >
> > > --- a/mm/kmemleak.c
> > > +++ b/mm/kmemleak.c
> > > @@ -588,7 +588,7 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size,
> > > if (in_irq()) {
> > > object->pid = 0;
> > > strncpy(object->comm, "hardirq", sizeof(object->comm));
> > > - } else if (in_softirq()) {
> > > + } else if (in_serving_softirq()) {
> > > object->pid = 0;
> > > strncpy(object->comm, "softirq", sizeof(object->comm));
> > > } else {
> >
> > What are the user-visible runtime effects of this change?
>
> If user does cat from /sys/kernel/debug/kmemleak previously they would
> see this, which is clearly wrong, this is system call context (see the
> comm):

Indeed, with your patch you get the correct output.

Acked-by: Catalin Marinas <[email protected]>

Thanks.

--
Catalin