linux-kernel - Re: [RFC] vmalloc: add warning in _

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 1 May 2012 13:22:57 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Nick Piggin <npiggin@...il.com>
cc:	Minchan Kim <minchan@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, kamezawa.hiroyu@...fujitsu.com,
	kosaki.motohiro@...il.com, Neil Brown <neilb@...e.de>,
	Artem Bityutskiy <dedekind1@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Theodore Ts'o <tytso@....edu>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Steven Whitehouse <swhiteho@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	James Morris <jmorris@...ei.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Sage Weil <sage@...dream.net>
Subject: Re: [RFC] vmalloc: add warning in __vmalloc

On Tue, 1 May 2012, Nick Piggin wrote:

> > I disagree with this approach since it's going to violently spam an
> > innocent kernel user's log with no ratelimiting and for a situation that
> > actually may not be problematic.
> 
> With WARN_ON_ONCE, it should be good.
> 

To catch a single instance of this per-boot, sure.  I've never seen us add 
WARN_ON_ONCE()'s where we have concrete examples of kernel code that will 
trigger it, though.  Not sure why spamming the kernel log and getting 
users to think something is wrong and report the bug when it's possible to 
audit the code and make a report to the subsystem maintainer.  Perhaps 
adding WARN_ON_ONCE()'s is just easier and then walk away from it?

> > Passing any of these bits (the difference between GFP_KERNEL and
> > GFP_ATOMIC) only means anything when we're going to do reclaim.  And I'm
> > suspecting we would have seen problems with this already since
> > pte_alloc_kernel() does __GFP_REPEAT on most architectures meaning that it
> > will loop infinitely in the page allocator until at least one page is
> > freed (since its an order-0 allocation) which would hardly ever happen if
> > __GFP_FS or __GFP_IO actually meant something in this context.
> >
> > In other words, we would already have seen these deadlocks and it would
> > have been diagnosed as a vmalloc(GFP_ATOMIC) problem.  Where are those bug
> > reports?
> 
> That's not sound logic to disprove a bug.
> 
> I think simply most callers are permissive and don't mask out flags.
> But for example a filesystem holding an fs lock and then doing
> vmalloc(GFP_NOFS) can certainly deadlock.
> 

I'm not disproving a bug, I'm asking for an example of how this problem 
has caused pain before and it has been the result of calling 
vmalloc(GFP_NOFS).  I agree we should certainly fix those callers, but it 
seems like adding the WARN_ON_ONCE()'s is certainly going to cause pain in 
tons of bug reports where there's no actual problem that couldn't have 
been found by auditing the code.