Message ID | 20221111090813.72068-1-jefflexu@linux.alibaba.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp632957wru; Fri, 11 Nov 2022 01:15:44 -0800 (PST) X-Google-Smtp-Source: AA0mqf7TXJ834eNL9PnPltJS5Xr847ThCC/NkAlx6hzVGXGksMjDKcDK+hOnJT7oCAIWUYeRqfAx X-Received: by 2002:a05:6402:b32:b0:461:a130:ea3c with SMTP id bo18-20020a0564020b3200b00461a130ea3cmr635978edb.272.1668158143834; Fri, 11 Nov 2022 01:15:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668158143; cv=none; d=google.com; s=arc-20160816; b=duZUzgw3m1emjX+rHcsWi3x+lYLZmrXFZCFNED4UACB3N6UJ+amGhsqXtYbWfE1vrw IwzeN2QG6FCfTAscfi0T0a3QfFU5PD+cUaSgxzOEhPHHbYpz7rMH5JBYvqq0rvMcXRcd D3csSisvqzMW5eRbxEoQI4qTaShUHgyraxbf3zY79STjz/lx43kMMjslgcUQj3kJJEAZ IciAXl6eEGaYAc+E2TXuUgHdv0dr7gMwy8JGZABaBnRLc8t8acf4cm3ZNc77gTbPVurf Nr1dEZ9q+TxPyfNL8NHO7VRZJJzRz7u5lU0hPsitJwNGW/NNTLh/cdJgWNDNHQptKHL4 jOBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=FYyS8XoA0aUNF/jnnD3kP4fk6cuytx64ueElhE5MSsk=; b=0JinnPKhqs9SsVG6HOjwEJSMloS4/WZROYIBq4Dtyp0jk0Vo00omQyLCGbCdB3ff1h mBZfmSpDEqtLbliZ119yRhFN6lWcF7pMVQ17db04G62w9jbIQB/1pLqqPlzB5ygiTEvx gQwM7nzgOT9gpKUwc1d9Ia1A3j29eess9wEA1/432qxjPg3jVTUAv6N4nTxEYLdgtzGF pnxs+KCp59VFSz825UOSt8ys/4F9m/Yrvf8SlB520+M11JxJ8Fblg5vhlyBA8FstMu4Z bFV7yGs0g04FTKrZXUXIbpYYL2JPV0xahAHSQQMxsndxFpnt4cGi4jL2Z/Bewup3GzAD jDwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a13-20020aa7d90d000000b00461b0b4f1afsi1572120edr.288.2022.11.11.01.15.19; Fri, 11 Nov 2022 01:15:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233476AbiKKJIU (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Fri, 11 Nov 2022 04:08:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233033AbiKKJIT (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 11 Nov 2022 04:08:19 -0500 Received: from out30-54.freemail.mail.aliyun.com (out30-54.freemail.mail.aliyun.com [115.124.30.54]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC8502AEC for <linux-kernel@vger.kernel.org>; Fri, 11 Nov 2022 01:08:17 -0800 (PST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R301e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046051;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0VUWtHXK_1668157693; Received: from localhost(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0VUWtHXK_1668157693) by smtp.aliyun-inc.com; Fri, 11 Nov 2022 17:08:14 +0800 From: Jingbo Xu <jefflexu@linux.alibaba.com> To: xiang@kernel.org, chao@kernel.org, yinxin.x@bytedance.com, linux-erofs@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org, dhowells@redhat.com Subject: [PATCH] erofs: fix missing xas_retry() in fscache mode Date: Fri, 11 Nov 2022 17:08:13 +0800 Message-Id: <20221111090813.72068-1-jefflexu@linux.alibaba.com> X-Mailer: git-send-email 2.19.1.6.gb485710b MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749190593606444396?= X-GMAIL-MSGID: =?utf-8?q?1749190593606444396?= |
Series |
erofs: fix missing xas_retry() in fscache mode
|
|
Commit Message
Jingbo Xu
Nov. 11, 2022, 9:08 a.m. UTC
The xarray iteration only holds RCU and thus may encounter
XA_RETRY_ENTRY if there's process modifying the xarray concurrently.
This will cause oops when referring to the invalid entry.
Fix this by adding the missing xas_retry(), which will make the
iteration wind back to the root node if XA_RETRY_ENTRY is encountered.
Fixes: d435d53228dd ("erofs: change to use asynchronous io for fscache readpage/readahead")
Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
---
fs/erofs/fscache.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
Comments
On Fri, Nov 11, 2022 at 05:08:13PM +0800, Jingbo Xu wrote: > The xarray iteration only holds RCU and thus may encounter > XA_RETRY_ENTRY if there's process modifying the xarray concurrently. > This will cause oops when referring to the invalid entry. > > Fix this by adding the missing xas_retry(), which will make the > iteration wind back to the root node if XA_RETRY_ENTRY is encountered. > > Fixes: d435d53228dd ("erofs: change to use asynchronous io for fscache readpage/readahead") > Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Thanks, Gao Xiang > --- > fs/erofs/fscache.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/fs/erofs/fscache.c b/fs/erofs/fscache.c > index fe05bc51f9f2..458c1c70ef30 100644 > --- a/fs/erofs/fscache.c > +++ b/fs/erofs/fscache.c > @@ -75,11 +75,15 @@ static void erofs_fscache_rreq_unlock_folios(struct netfs_io_request *rreq) > > rcu_read_lock(); > xas_for_each(&xas, folio, last_page) { > - unsigned int pgpos = > - (folio_index(folio) - start_page) * PAGE_SIZE; > - unsigned int pgend = pgpos + folio_size(folio); > + unsigned int pgpos, pgend; > bool pg_failed = false; > > + if (xas_retry(&xas, folio)) > + continue; > + > + pgpos = (folio_index(folio) - start_page) * PAGE_SIZE; > + pgend = pgpos + folio_size(folio); > + > for (;;) { > if (!subreq) { > pg_failed = true; > -- > 2.19.1.6.gb485710b
在 2022/11/11 17:08, Jingbo Xu 写道: > The xarray iteration only holds RCU and thus may encounter > XA_RETRY_ENTRY if there's process modifying the xarray concurrently. > This will cause oops when referring to the invalid entry. > > Fix this by adding the missing xas_retry(), which will make the > iteration wind back to the root node if XA_RETRY_ENTRY is encountered. > > Fixes: d435d53228dd ("erofs: change to use asynchronous io for fscache readpage/readahead") > Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by: Jia Zhu <zhujia.zj@bytedance.com> > --- > fs/erofs/fscache.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/fs/erofs/fscache.c b/fs/erofs/fscache.c > index fe05bc51f9f2..458c1c70ef30 100644 > --- a/fs/erofs/fscache.c > +++ b/fs/erofs/fscache.c > @@ -75,11 +75,15 @@ static void erofs_fscache_rreq_unlock_folios(struct netfs_io_request *rreq) > > rcu_read_lock(); > xas_for_each(&xas, folio, last_page) { > - unsigned int pgpos = > - (folio_index(folio) - start_page) * PAGE_SIZE; > - unsigned int pgend = pgpos + folio_size(folio); > + unsigned int pgpos, pgend; > bool pg_failed = false; > > + if (xas_retry(&xas, folio)) > + continue; > + > + pgpos = (folio_index(folio) - start_page) * PAGE_SIZE; > + pgend = pgpos + folio_size(folio); > + > for (;;) { > if (!subreq) { > pg_failed = true;
Jingbo Xu <jefflexu@linux.alibaba.com> wrote:
> The xarray iteration only holds RCU
I would say "the RCU read lock".
Also, I think you've copied the code to which my dodgy-maths fix applies:
https://lore.kernel.org/linux-fsdevel/166757988611.950645.7626959069846893164.stgit@warthog.procyon.org.uk/
David
Hi David, Thanks for the comment. On 11/14/22 7:44 PM, David Howells wrote: > Jingbo Xu <jefflexu@linux.alibaba.com> wrote: > >> The xarray iteration only holds RCU > > I would say "the RCU read lock". Yeah, this looks clearer. I will update the commit message in v2 later. > > Also, I think you've copied the code to which my dodgy-maths fix applies: > > https://lore.kernel.org/linux-fsdevel/166757988611.950645.7626959069846893164.stgit@warthog.procyon.org.uk/ > Thanks for the kindly reminder. Yeah this code was ever copied from libnetfs. In the scenario of erofs, currently req->start is always aligned with folio size and erofs doesn't support large folio yet. Thus req->start won't be inside the folio so far, and I think the current code works well in the scenario of erofs, though the issue indeed exist mathematically. Actually I'm working on the support for large folio now, and the completion routine of erofs in fscache mode will be refactored quite a lot. I think this issue will be fixed along with the refactoring. Thanks again for the suggestion :)
diff --git a/fs/erofs/fscache.c b/fs/erofs/fscache.c index fe05bc51f9f2..458c1c70ef30 100644 --- a/fs/erofs/fscache.c +++ b/fs/erofs/fscache.c @@ -75,11 +75,15 @@ static void erofs_fscache_rreq_unlock_folios(struct netfs_io_request *rreq) rcu_read_lock(); xas_for_each(&xas, folio, last_page) { - unsigned int pgpos = - (folio_index(folio) - start_page) * PAGE_SIZE; - unsigned int pgend = pgpos + folio_size(folio); + unsigned int pgpos, pgend; bool pg_failed = false; + if (xas_retry(&xas, folio)) + continue; + + pgpos = (folio_index(folio) - start_page) * PAGE_SIZE; + pgend = pgpos + folio_size(folio); + for (;;) { if (!subreq) { pg_failed = true;