Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753997AbdCHSCW (ORCPT ); Wed, 8 Mar 2017 13:02:22 -0500 Received: from us-smtp-delivery-194.mimecast.com ([63.128.21.194]:29937 "EHLO us-smtp-delivery-194.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753027AbdCHSCQ (ORCPT ); Wed, 8 Mar 2017 13:02:16 -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" , "konishi.ryusuke@lab.ntt.co.jp" , "neilb@suse.com" , "linux-mm@kvack.org" , "adilger@dilger.ca" , "James.Bottomley@HansenPartnership.com" , "linux-fsdevel@vger.kernel.org" , "ross.zwisler@linux.intel.com" , "openosd@gmail.com" , "jack@suse.cz" 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: AQHSmCz1bIx78jBzJEOrYwbWeiRo8qGLO7yA Date: Wed, 8 Mar 2017 18:01:47 +0000 Message-ID: <1488996103.3098.4.camel@primarydata.com> References: <20170308162934.21989-1-jlayton@redhat.com> <20170308162934.21989-7-jlayton@redhat.com> In-Reply-To: <20170308162934.21989-7-jlayton@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: 660e5920-7e69-481c-7908-08d4664d3059 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR11MB1346; x-microsoft-exchange-diagnostics: 1;BN6PR11MB1346;7:epIdrueaAttH4j6VcWMmUkjvTEbYwa6dCZQ53PaRf/BXhvh1qjpn9BXlMTJGh5CHHMlzhzvqNd74Nm7XvDpPCiICguOgkbAFmqNYxMVnukHjQiVbQyBusDhL1HM5rIKbmY62e9UWClQsF9B5d79oLtcfFG7a15b2PJX3xAQ3PQayLmOtv/khXp6OggEKUQiWb98Dku5F2pojCeUBuo38TMDON2eezmXY6iipIH2rz9eGTXvHDbTGySQgtPP1/XmMhHcdIalLuRYopIwZqifpszY0BueIvufaLpv3duv1zC78LsNVwKHBjCtfYQW8D8njW2huGkt4V/9gMbwMi2UOsA==;20:5Yvd5lzjCV24m4lDkjIj92WvdwIhuPJG42pfjBx5oTBXXYaaOYQHxB0RxsAoaruPZvVU9Ulkg+elWX+hMXKiOarFUhLiYXoz7uDiX7DsY4oSa+HYlpg7bgZzm2zVAfhNBysBSIDendzmMcHcChnkqWdE0cH3keUqBVOV0AwJwSY= 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)(2016111802025)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(6043046)(6072148);SRVR:BN6PR11MB1346;BCL:0;PCL:0;RULEID:;SRVR:BN6PR11MB1346; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39410400002)(39840400002)(377424004)(24454002)(189998001)(2906002)(5660300001)(36756003)(66066001)(39060400002)(54906002)(6512007)(2900100001)(38730400002)(99286003)(4326008)(2501003)(33646002)(6246003)(122556002)(102836003)(106116001)(81166006)(25786008)(3660700001)(6506006)(7416002)(8676002)(8936002)(2201001)(2950100002)(53936002)(229853002)(7736002)(305945005)(77096006)(50986999)(6486002)(86362001)(54356999)(76176999)(6116002)(3846002)(6436002)(3280700002)(103116003);DIR:OUT;SFP:1102;SCL:1;SRVR:BN6PR11MB1346;H:BN6PR11MB1348.namprd11.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <21F7418F71E31848A4493C2E2A5DBE3B@namprd11.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: primarydata.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 18:01:47.2654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1346 X-MC-Unique: usWOJ_6lNYmvxK5ZIsC1Dw-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 v28I2PJ5009716 Content-Length: 1268 Lines: 43 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. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com