linux-kernel - Re: [PATCH] mm, fs: Obey gfp_mapping for add_to_page

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: <20150929150246.286cc6013bce3eec170376aa@linux-foundation.org>
Date:	Tue, 29 Sep 2015 15:02:46 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	mhocko@...nel.org
Cc:	<linux-mm@...ck.org>, Dave Chinner <david@...morbit.com>,
	"Theodore Ts'o" <tytso@....edu>, Ming Lei <ming.lei@...onical.com>,
	Andreas Dilger <andreas.dilger@...el.com>,
	Oleg Drokin <oleg.drokin@...el.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
	xfs@....sgi.com, linux-nfs@...r.kernel.org,
	linux-cifs@...r.kernel.org, Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH] mm, fs: Obey gfp_mapping for add_to_page_cache

On Fri, 25 Sep 2015 17:04:21 +0200 mhocko@...nel.org wrote:

> From: Michal Hocko <mhocko@...e.com>
> 
> 6afdb859b710 ("mm: do not ignore mapping_gfp_mask in page cache
> allocation paths) has caught some users of hardcoded GFP_KERNEL
> used in the page cache allocation paths. This, however, wasn't complete
> and there were others which went unnoticed.
> 
> Dave Chinner has reported the following deadlock for xfs on loop device:
> : With the recent merge of the loop device changes, I'm now seeing
> : XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
> :
> : The deadlocked is as follows:
> :
> : kloopd1: loop_queue_read_work
> :       xfs_file_iter_read
> :       lock XFS inode XFS_IOLOCK_SHARED (on image file)
> :       page cache read (GFP_KERNEL)
> :       radix tree alloc
> :       memory reclaim
> :       reclaim XFS inodes
> :       log force to unpin inodes
> :       <wait for log IO completion>
> :
> : xfs-cil/loop1: <does log force IO work>
> :       xlog_cil_push
> :       xlog_write
> :       <loop issuing log writes>
> :               xlog_state_get_iclog_space()
> :               <blocks due to all log buffers under write io>
> :               <waits for IO completion>
> :
> : kloopd1: loop_queue_write_work
> :       xfs_file_write_iter
> :       lock XFS inode XFS_IOLOCK_EXCL (on image file)
> :       <wait for inode to be unlocked>
> :
> : i.e. the kloopd, with it's split read and write work queues, has
> : introduced a dependency through memory reclaim. i.e. that writes
> : need to be able to progress for reads make progress.
> :
> : The problem, fundamentally, is that mpage_readpages() does a
> : GFP_KERNEL allocation, rather than paying attention to the inode's
> : mapping gfp mask, which is set to GFP_NOFS.
> :
> : The didn't used to happen, because the loop device used to issue
> : reads through the splice path and that does:
> :
> :       error = add_to_page_cache_lru(page, mapping, index,
> :                       GFP_KERNEL & mapping_gfp_mask(mapping));
> 
> This has changed by aa4d86163e4 (block: loop: switch to VFS ITER_BVEC).

xfs-on-loop deadlocks since April would appear to warrant a -stable
backport, yes?

> this is a rebase on top of the current mmotm
> (2015-09-22-15-28)

So I've redone the patch against current mainline.
--
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/