linux-kernel - Re: [PATCH] kmemleak: Fix scheduling-while-atomic bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <84144f020907010110u1dc23666y744b09ed17ba2535@mail.gmail.com>
Date:	Wed, 1 Jul 2009 11:10:00 +0300
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	git-commits-head@...r.kernel.org
Subject: Re: [PATCH] kmemleak: Fix scheduling-while-atomic bug

Hi Ingo,

On Wed, Jul 1, 2009 at 10:53 AM, Ingo Molnar<mingo@...e.hu> wrote:
> From 5ba1a8143c502f40b976a0ea1df5e5a10056fcc6 Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <mingo@...e.hu>
> Date: Wed, 1 Jul 2009 09:43:53 +0200
> Subject: [PATCH] kmemleak: Fix scheduling-while-atomic bug
>
> One of the kmemleak changes caused the following
> scheduling-while-holding-the-tasklist-lock regression on x86:
>
> BUG: sleeping function called from invalid context at mm/kmemleak.c:795
> in_atomic(): 1, irqs_disabled(): 0, pid: 1737, name: kmemleak
> 2 locks held by kmemleak/1737:
>  #0:  (scan_mutex){......}, at: [<c10c4376>] kmemleak_scan_thread+0x45/0x86
>  #1:  (tasklist_lock){......}, at: [<c10c3bb4>] kmemleak_scan+0x1a9/0x39c
> Pid: 1737, comm: kmemleak Not tainted 2.6.31-rc1-tip #59266
> Call Trace:
>  [<c105ac0f>] ? __debug_show_held_locks+0x1e/0x20
>  [<c102e490>] __might_sleep+0x10a/0x111
>  [<c10c38d5>] scan_yield+0x17/0x3b
>  [<c10c3970>] scan_block+0x39/0xd4
>  [<c10c3bc6>] kmemleak_scan+0x1bb/0x39c
>  [<c10c4331>] ? kmemleak_scan_thread+0x0/0x86
>  [<c10c437b>] kmemleak_scan_thread+0x4a/0x86
>  [<c104d73e>] kthread+0x6e/0x73
>  [<c104d6d0>] ? kthread+0x0/0x73
>  [<c100959f>] kernel_thread_helper+0x7/0x10
> kmemleak: 834 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>
> The bit causing it is highly dubious:
>
> static void scan_yield(void)
> {
>        might_sleep();
>
>        if (time_is_before_eq_jiffies(next_scan_yield)) {
>                schedule();
>                next_scan_yield = jiffies + jiffies_scan_yield;
>        }
> }
>
> It called deep inside the codepath and in a conditional way,
> and that is what crapped up when one of the new scan_block()
> uses grew a tasklist_lock dependency.
>
> This minimal patch removes that yielding stuff and adds the
> proper cond_resched().
>
> The background scanning thread could probably also be reniced
> to +10.
>
> Signed-off-by: Ingo Molnar <mingo@...e.hu>

Looks good to me, thanks!

Acked-by: Pekka Enberg <penberg@...helsinki.fi>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/