From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754115AbdCHTU7 (ORCPT ); Wed, 8 Mar 2017 14:20:59 -0500 Received: from us-smtp-delivery-194.mimecast.com ([63.128.21.194]:35932 "EHLO us-smtp-delivery-194.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752620AbdCHTU4 (ORCPT ); Wed, 8 Mar 2017 14:20:56 -0500 From: Trond Myklebust To: "viro@zeniv.linux.org.uk" , "jlayton@redhat.com" , "akpm@linux-foundation.org" CC: "linux-nilfs@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "neilb@suse.com" , "konishi.ryusuke@lab.ntt.co.jp" , "linux-mm@kvack.org" , "adilger@dilger.ca" , "James.Bottomley@HansenPartnership.com" , "linux-fsdevel@vger.kernel.org" Subject: Re: [PATCH v2 6/9] mm: set mapping error when launder_pages fails Thread-Topic: [PATCH v2 6/9] mm: set mapping error when launder_pages fails Thread-Index: AQHSmCz1bIx78jBzJEOrYwbWeiRo8qGLO7yAgAAKLQCAAAq1AA== Date: Wed, 8 Mar 2017 19:16:32 +0000 Message-ID: <1489000588.3098.8.camel@primarydata.com> References: <20170308162934.21989-1-jlayton@redhat.com> <20170308162934.21989-7-jlayton@redhat.com> <1488996103.3098.4.camel@primarydata.com> <1488998288.2802.25.camel@redhat.com> In-Reply-To: <1488998288.2802.25.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [68.49.162.121] x-ms-office365-filtering-correlation-id: 8baea221-99d0-4740-ed73-08d46657a1ac x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR11MB1345; x-microsoft-exchange-diagnostics: 1;BN6PR11MB1345;7:5rK9YJXj8z7jBV67WApVvWvp/pq/OBuQC54FjfuqnMkBW8hnsPtK0MJsBTbzbOa5F+fbm8RVZ+baAqJ51cJNSK77M7V/oEFld/I+3lbaEf0A3QQ2N02m/w+LgBaCLI8zRsxCIyclNZagcH6N+yrURYzRUEnYzlx9rLocvTSo2Ii3/swBznTlvtqSAIgRX1U4nu62AtsrZ695Oetil21UaVARW92McWthbCq2saR26cDE3ZsJ+7CEn/tusLuYG7thDJ6zPyUw3Q+BXPs6c82T3/pBE7T6fSIaXTq2rMU/q2OEgfxFLZ7oe4kB3hRvsghBxluZiLkL0R0tmrXLVbf6NQ==;20:RIaQiWNPnNxjh95j8SIu1UmiDedS8di+AAap2YlIZG7P+epzKQhDvAGsHhidUanVDX8+ST+h2Ykgu8mGEWYoJNqLw1EHrOcJRHIg/ILrTNcccpn3BMbxphrere1R0Ilm99WASXBPkIj5lPY/T6TrWFQK3qxEaVNIPE0/vpWLkug= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(2016111802025)(20161123558025)(20161123555025)(20161123562025)(6043046)(6072148);SRVR:BN6PR11MB1345;BCL:0;PCL:0;RULEID:;SRVR:BN6PR11MB1345; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39840400002)(39410400002)(39450400003)(377424004)(24454002)(6246003)(7416002)(66066001)(8936002)(2501003)(6436002)(6486002)(4326008)(103116003)(122556002)(6512007)(2900100001)(305945005)(54906002)(25786008)(7736002)(38730400002)(106116001)(81166006)(99286003)(6506006)(77096006)(8676002)(3660700001)(36756003)(2950100002)(189998001)(53936002)(2201001)(50986999)(76176999)(3280700002)(54356999)(2906002)(229853002)(102836003)(3846002)(86362001)(6116002)(33646002)(5660300001)(93886004);DIR:OUT;SFP:1102;SCL:1;SRVR:BN6PR11MB1345;H:BN6PR11MB1348.namprd11.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <86D654C6A10F1C4D81696080C0DA62EE@namprd11.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: primarydata.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 19:16:32.4072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1345 X-MC-Unique: q6A89panPmOKRvL5TJDbWA-1 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v28JL3os001862 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 > > > --- > > >  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@primarydata.com