linux-kernel - Re: [PATCH 04/19] Make effect of PF_FSTRANS to disable __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:	Thu, 17 Apr 2014 11:03:50 +1000
From:	NeilBrown <neilb@...e.de>
To:	NeilBrown <neilb@...e.de>
Cc:	Dave Chinner <david@...morbit.com>, linux-mm@...ck.org,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ming Lei <ming.lei@...onical.com>, xfs@....sgi.com
Subject: Re: [PATCH 04/19] Make effect of PF_FSTRANS to disable __GFP_FS
 universal.

On Wed, 16 Apr 2014 16:17:26 +1000 NeilBrown <neilb@...e.de> wrote:

> On Wed, 16 Apr 2014 15:37:56 +1000 Dave Chinner <david@...morbit.com> wrote:
> 
> > On Wed, Apr 16, 2014 at 02:03:36PM +1000, NeilBrown wrote:

> > > -	/*
> > > -	 * Given that we do not allow direct reclaim to call us, we should
> > > -	 * never be called while in a filesystem transaction.
> > > -	 */
> > > -	if (WARN_ON(current->flags & PF_FSTRANS))
> > > -		goto redirty;
> > 
> > We still need to ensure this rule isn't broken. If it is, the
> > filesystem will silently deadlock in delayed allocation rather than
> > gracefully handle the problem with a warning....
> 
> Hmm... that might be tricky.  The 'new' PF_FSTRANS can definitely be set when
> xfs_vm_writepage is called and we really want the write to happen.
> I don't suppose there is any other way to detect if a transaction is
> happening?

I've been thinking about this some more....

That code is in xfs_vm_writepage which is only called as ->writepage.
xfs never calls that directly so it could only possibly be called during
reclaim?

We know that doesn't happen, but if it does then PF_MEMALLOC would be set,
but PF_KSWAPD would not... and you already have a test for that.

How about every time we set PF_FSTRANS, we store the corresponding
xfs_trans_t in current->journal_info, and clear that field when PF_FSTRANS is
cleared.  Then xfs_vm_writepage can test for current->journal_info being
clear.
That is the field that several other filesystems use to keep track of the
'current' transaction.
??

I don't know what xfs_trans_t we would use in xfs_bmapi_allocate_worker, but
I suspect you do :-)

Thanks,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)