linux-kernel - Re: [PATCH v2 6/9] mm: set mapping error when launder

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]

Message-ID: <1489000588.3098.8.camel@primarydata.com>
Date:   Wed, 8 Mar 2017 19:16:32 +0000
From:   Trond Myklebust <trondmy@...marydata.com>
To:     "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "jlayton@...hat.com" <jlayton@...hat.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC:     "linux-nilfs@...r.kernel.org" <linux-nilfs@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "neilb@...e.com" <neilb@...e.com>,
        "konishi.ryusuke@....ntt.co.jp" <konishi.ryusuke@....ntt.co.jp>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "adilger@...ger.ca" <adilger@...ger.ca>,
        "James.Bottomley@...senPartnership.com" 
        <James.Bottomley@...senPartnership.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v2 6/9] mm: set mapping error when launder_pages fails

On Wed, 2017-03-08 at 13:38 -0500, Jeff Layton wrote:
> On Wed, 2017-03-08 at 18:01 +0000, Trond Myklebust wrote:
> > On Wed, 2017-03-08 at 11:29 -0500, Jeff Layton wrote:
> > > If launder_page fails, then we hit a problem writing back some
> > > inode
> > > data. Ensure that we communicate that fact in a subsequent fsync
> > > since
> > > another task could still have it open for write.
> > > 
> > > Signed-off-by: Jeff Layton <jlayton@...hat.com>
> > > ---
> > >  mm/truncate.c | 6 +++++-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/mm/truncate.c b/mm/truncate.c
> > > index 6263affdef88..29ae420a5bf9 100644
> > > --- a/mm/truncate.c
> > > +++ b/mm/truncate.c
> > > @@ -594,11 +594,15 @@ invalidate_complete_page2(struct
> > > address_space
> > > *mapping, struct page *page)
> > >  
> > >  static int do_launder_page(struct address_space *mapping, struct
> > > page *page)
> > >  {
> > > +	int ret;
> > > +
> > >  	if (!PageDirty(page))
> > >  		return 0;
> > >  	if (page->mapping != mapping || mapping->a_ops-
> > > >launder_page 
> > > == NULL)
> > >  		return 0;
> > > -	return mapping->a_ops->launder_page(page);
> > > +	ret = mapping->a_ops->launder_page(page);
> > > +	mapping_set_error(mapping, ret);
> > > +	return ret;
> > >  }
> > >  
> > >  /**
> > 
> > No. At that layer, you don't know that this is a page error. In the
> > NFS
> > case, it could, for instance, just as well be a fatal signal.
> > 
> 
> Ok...don't we have the same problem with writepage then? Most of the
> writepage callers will set an error in the mapping if writepage
> returns
> any sort of error? A fatal signal in that codepath could cause the
> same
> problem, it seems. We don't dip into direct reclaim so much anymore,
> so
> maybe signals aren't an issue there?

If writepage() fails due to a signal, then it has the option of marking
the page as dirty and returning AOP_WRITEPAGE_ACTIVATE. That's not
possible for launder_page().

> The alternative here would be to push this down into the callers. I
> worry a bit though about getting this right across filesystems
> though.
> It'd be preferable it if we could keep the mapping_set_error call in
> generic VFS code instead, but if not then I'll just plan to do that.
> 



-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@...marydata.com