linux-kernel - Re: [PATCH] sparc: replace __GFP_NOFAIL with GFP_ATOMIC in mdesc

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20140107.141115.513158198056746890.davem@davemloft.net>
Date:	Tue, 07 Jan 2014 14:11:15 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	ethan.kernel@...il.com
Cc:	sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sparc: replace __GFP_NOFAIL with GFP_ATOMIC in
 mdesc_kmalloc()

From: Ethan Zhao <ethan.kernel@...il.com>
Date: Tue,  7 Jan 2014 17:31:17 +0800

> Has kmalloc() failure checking there, so it is unnecessary to allocate with
> __GFP_NOFAIL flag that might block forever.
> 
> Signed-off-by: Ethan Zhao <ethan.kernel@...il.com>

This allocation failing borders on catastrophic.  The allocation failure
handling is just for looks.

This function is triggered when the firmware tells us that new cpus or
other devices are available.  This memory being allocated will hold
the machine description that we traverse to find those new devices.

If this allocation is allowed to fail, we will never have any way to
get the notification again.  It really is __GFP_NOFAIL and must
succeed.

I'm not applying this, sorry.
--
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/