From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F066C678D7 for ; Mon, 9 Jan 2023 13:50:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236687AbjAINuD (ORCPT ); Mon, 9 Jan 2023 08:50:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233669AbjAINte (ORCPT ); Mon, 9 Jan 2023 08:49:34 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14C3B1EED9 for ; Mon, 9 Jan 2023 05:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673272135; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PvQQWSrgFrwfgP/nK/4g0KowjQbRVLSmpT5SVnvrh64=; b=Fb1HPihoPW4YCjGnJNSvHLURmHyE41exzrslpUaPRhweIJtEn7xwb/SIewRPWvaZOmym7l 1LrHTpIq0xAzBVQiOJmDkO1uTnBKId1MvPow4zpSH02BOF92+ug0xviKp/qxR4+3xWWsxx Im4AJQ6eIpUxOtSIdNHn3WCCONkTHuM= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-444-ZZg2uGmFMb68hzFEeAnilw-1; Mon, 09 Jan 2023 08:48:52 -0500 X-MC-Unique: ZZg2uGmFMb68hzFEeAnilw-1 Received: by mail-qk1-f197.google.com with SMTP id br6-20020a05620a460600b007021e1a5c48so6450340qkb.6 for ; Mon, 09 Jan 2023 05:48:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PvQQWSrgFrwfgP/nK/4g0KowjQbRVLSmpT5SVnvrh64=; b=Gj8ZSDdbpeWT8EcOgFe1Vi5JX2H6Jj+m7XEYbCPIIkghu1ud6sE2cxTmhtfCK7tZ9C 5xA8W1kOOzvjbgO3m2IW63y1eSuTEO1iEyQFlXVaVDH/UwfEPHRCq/39Be911BrN04IZ EYqWIixKz1HwmapEy6nZjyIAed3R0vZKI9zjirjFB+DcA2IebATryzftBYCr42apcpWp gRsiMlZeXf9E0edpkd+xjTcZQ9DtqWuD8m5s4lOGq/5C05YYe+TdrBcM2zuM/+E3WLFw CJ4i+52PWtpc0w/q9dC/KzpKxpwGTLt7DW5V+lEez7H0iY0V+4pEKsrANJo8zHfBg1NP QXdw== X-Gm-Message-State: AFqh2koksGYEXV3nSqzXYmiPPQG1v8A9EEVtHoCMKLaFcfvcTovjkMQJ i5cEAMtMFdKf9GX4cCVG7sGW8Eipf3ce6FxBY6zqUkyKDjuRDfzn8QKkDpz1QiZaFA7MZx3g2Bc PbqrHw/L76z6WTRfRdwMBpULG X-Received: by 2002:ac8:4509:0:b0:3a8:162d:e977 with SMTP id q9-20020ac84509000000b003a8162de977mr91039461qtn.58.1673272131567; Mon, 09 Jan 2023 05:48:51 -0800 (PST) X-Google-Smtp-Source: AMrXdXuBqYf6sR9hrOI8TK8PSKFDec2DU6T9YlCBq3DM5BjirOxhid+aIw2+3HKxNZhD/YmD4XYT3w== X-Received: by 2002:ac8:4509:0:b0:3a8:162d:e977 with SMTP id q9-20020ac84509000000b003a8162de977mr91039437qtn.58.1673272131330; Mon, 09 Jan 2023 05:48:51 -0800 (PST) Received: from [192.168.1.3] (68-20-15-154.lightspeed.rlghnc.sbcglobal.net. [68.20.15.154]) by smtp.gmail.com with ESMTPSA id z2-20020ac86b82000000b003a5c6ad428asm4551847qts.92.2023.01.09.05.48.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Jan 2023 05:48:50 -0800 (PST) Message-ID: <36311b962209353333be4c8ceaf0e0823ef9f228.camel@redhat.com> Subject: Re: [PATCH 02/11] filemap: Remove filemap_check_and_keep_errors() From: Jeff Layton To: "Matthew Wilcox (Oracle)" Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Hellwig Date: Mon, 09 Jan 2023 08:48:49 -0500 In-Reply-To: <20230109051823.480289-3-willy@infradead.org> References: <20230109051823.480289-1-willy@infradead.org> <20230109051823.480289-3-willy@infradead.org> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.2 (3.46.2-1.fc37) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2023-01-09 at 05:18 +0000, Matthew Wilcox (Oracle) wrote: > Convert both callers to use the "new" errseq infrastructure. >=20 > Signed-off-by: Matthew Wilcox (Oracle) > --- > mm/filemap.c | 18 ++++++------------ > 1 file changed, 6 insertions(+), 12 deletions(-) >=20 > diff --git a/mm/filemap.c b/mm/filemap.c > index c4d4ace9cc70..48daedc224d9 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -355,16 +355,6 @@ int filemap_check_errors(struct address_space *mappi= ng) > } > EXPORT_SYMBOL(filemap_check_errors); > =20 > -static int filemap_check_and_keep_errors(struct address_space *mapping) > -{ > - /* Check for outstanding write errors */ > - if (test_bit(AS_EIO, &mapping->flags)) > - return -EIO; > - if (test_bit(AS_ENOSPC, &mapping->flags)) > - return -ENOSPC; > - return 0; > -} > - > /** > * filemap_fdatawrite_wbc - start writeback on mapping dirty pages in ra= nge > * @mapping: address space structure to write > @@ -567,8 +557,10 @@ EXPORT_SYMBOL(filemap_fdatawait_range); > int filemap_fdatawait_range_keep_errors(struct address_space *mapping, > loff_t start_byte, loff_t end_byte) > { > + errseq_t since =3D filemap_sample_wb_err(mapping); > + > __filemap_fdatawait_range(mapping, start_byte, end_byte); > - return filemap_check_and_keep_errors(mapping); > + return filemap_check_wb_err(mapping, since); > } > EXPORT_SYMBOL(filemap_fdatawait_range_keep_errors); I looked at making this sort of change across the board alongside the original wb_err patches, but I backed off at the time. With the above patch, this function will no longer report a writeback error that occurs before the sample. Given that writeback can happen at any time, that seemed like it might be an undesirable change, and I didn't follow through. It is true that the existing flag-based code may miss errors too, if multiple tasks are test_and_clear'ing the bits, but I think the above is even more likely to happen, esp. under memory pressure. To do this right, we probably need to look at these callers and have them track a long-term errseq_t "since" value before they ever dirty the pages, and then continually check-and-advance vs. that. For instance, the main caller of the above function is jbd2. Would it be reasonable to add in a new errseq_t value to the jnode for tracking errors? > =20 > @@ -613,8 +605,10 @@ EXPORT_SYMBOL(file_fdatawait_range); > */ > int filemap_fdatawait_keep_errors(struct address_space *mapping) > { > + errseq_t since =3D filemap_sample_wb_err(mapping); > + > __filemap_fdatawait_range(mapping, 0, LLONG_MAX); > - return filemap_check_and_keep_errors(mapping); > + return filemap_check_wb_err(mapping, since); > } > EXPORT_SYMBOL(filemap_fdatawait_keep_errors); > =20 --=20 Jeff Layton