linux-kernel - Re: [PATCH] gfs2: use __vmalloc GFP

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:	Mon, 2 Feb 2015 19:11:15 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Oleg Drokin <green@...uxhacker.ru>
Cc:	Steven Whitehouse <swhiteho@...hat.com>, cluster-devel@...hat.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-mm@...ck.org
Subject: Re: [PATCH] gfs2: use __vmalloc GFP_NOFS for fs-related allocations.

On Mon, Feb 02, 2015 at 01:57:23AM -0500, Oleg Drokin wrote:
> Hello!
> 
> On Feb 2, 2015, at 12:37 AM, Dave Chinner wrote:
> 
> > On Sun, Feb 01, 2015 at 10:59:54PM -0500, green@...uxhacker.ru wrote:
> >> From: Oleg Drokin <green@...uxhacker.ru>
> >> 
> >> leaf_dealloc uses vzalloc as a fallback to kzalloc(GFP_NOFS), so
> >> it clearly does not want any shrinker activity within the fs itself.
> >> convert vzalloc into __vmalloc(GFP_NOFS|__GFP_ZERO) to better achieve
> >> this goal.
> >> 
> >> Signed-off-by: Oleg Drokin <green@...uxhacker.ru>
> >> ---
> >> fs/gfs2/dir.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
> >> index c5a34f0..6371192 100644
> >> --- a/fs/gfs2/dir.c
> >> +++ b/fs/gfs2/dir.c
> >> @@ -1896,7 +1896,8 @@ static int leaf_dealloc(struct gfs2_inode *dip, u32 index, u32 len,
> >> 
> >> 	ht = kzalloc(size, GFP_NOFS | __GFP_NOWARN);
> >> 	if (ht == NULL)
> >> -		ht = vzalloc(size);
> >> +		ht = __vmalloc(size, GFP_NOFS | __GFP_NOWARN | __GFP_ZERO,
> >> +			       PAGE_KERNEL);
> > That, in the end, won't help as vmalloc still uses GFP_KERNEL
> > allocations deep down in the PTE allocation code. See the hacks in
> > the DM and XFS code to work around this. i.e. go look for callers of
> > memalloc_noio_save().  It's ugly and grotesque, but we've got no
> > other way to limit reclaim context because the MM devs won't pass
> > the vmalloc gfp context down the stack to the PTE allocations....
> 
> Hm, interesting.
> So all the other code in the kernel that does this sort of thing (and there's quite a bit
> outside of xfs and ocfs2) would not get the desired effect?

No. I expect, however, that very few people would ever see a
deadlock as a result - it's a pretty rare sort of kernel case to hit
in most cases. XFS does make extensive use of vm_map_ram() in
GFP_NOFS context, however, when large directory block sizes are in
use, and we also have a history of lockdep throwing warnings under
memory pressure. In the end, the memalloc_noio_save() changes were
made to stop the frequent lockdep reports rather than actual
deadlocks.

> So, I did some digging in archives and found this thread from 2010 onward with various
> patches and rants.
> Not sure how I missed that before.
> 
> Should we have another run at this I wonder?

By all means, but I don't think you'll have any more luck than
anyone else in the past. We've still got the problem of attitude
("vmalloc is not for general use") and making it actually work is
seen as "encouraging undesirable behaviour". If you can change
attitudes towards vmalloc first, then you'll be much more likely to
make progress in getting these problems solved....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/