Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp772380pxb; Fri, 15 Oct 2021 16:02:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzfcq3BzwiTJUt9IDI6IHtn/PPywIFYovBo237510Gdv2isLw7I1E6eYEUx7zpa+ZOWsXgC X-Received: by 2002:a05:6402:5c9:: with SMTP id n9mr21248620edx.90.1634338940589; Fri, 15 Oct 2021 16:02:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634338940; cv=none; d=google.com; s=arc-20160816; b=tXno0n4TgcR056/g9BaeaIxP+MXhGADI0gh7Q26E8RXiSQ7s5GgD54eqQG1l3d2p3g MJxijO4o7iAYmZXMxoZuOikYVxwX5HiDxQqu20GcWsjkDznA3B5JxAKqPnuYjPVu1Pz2 k15P7rrckAexMemYipk+HfuYF4+jcQuhodFR6K3+PZIlQqQ+YqFR9bOZaT5yOiVYHhbm 9zo+D+KYuUFA3nJ+8Za/lUEVJxn5pfeBbsAYBfNsG0oKIBdTF0xRM7gK7j3Cef0rRCCo 0jcsdOe57vyn4MDS0Pp8eNI82eFi9nd5v6I6sbUSwd1otXYd+8zUdVOKLeXDpvQu3zSo jAoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=bLMlIGZRWtJG5pdz8uzZaobV5511jJzZGIeS5RrEQlA=; b=DH/zRwUP/z7fi6jRpO890sBGF5JXOpDeq6Mb14ql3OGBjFyFOnBEtSJbBmtFKd2sOP lUbArVcOs5x2uzoRQ70i9CnXx51jyqQ6Bekr2IQFVYPAdDEYci46j3FASemPI7n18a9W 2zveFxa1ZU7XG1dpgZZaQRoLwZRGlgaK6oZfHTvZCGpGpjBiZvDeMGB0DVrPV0Lzm+sW 3kuewHs1NYpswXGbF62aRQsgsJusaC2M8qZKkrHJV1LqPrbxEkLBieMvZenErdyf8Lzb Tb/NEPBpZWRe8saRPQZqP+KXCY43tkefW9Urbkhzo/b43DIgROPZ0GM8XKSEEp6l/qHG piLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=dTvSQqRl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cr12si13116064ejc.593.2021.10.15.16.01.57; Fri, 15 Oct 2021 16:02:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=dTvSQqRl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235658AbhJOMjS (ORCPT + 99 others); Fri, 15 Oct 2021 08:39:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234422AbhJOMjO (ORCPT ); Fri, 15 Oct 2021 08:39:14 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2BA8C061762 for ; Fri, 15 Oct 2021 05:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=bLMlIGZRWtJG5pdz8uzZaobV5511jJzZGIeS5RrEQlA=; b=dTvSQqRlNUuDdupsVJe/26lTrb sqieoyjQM+BFfZ2yQhFU/HiRNOpjWcaiFp4nb7+h/qFQ0Jun5nCI9Pcp1v78/KHTwt51ZAuMpNHsV R9LT5vv4gWpbM1KSLNtxXbOJsoM2XCi/1N/uQG2En82V8smzln0tV8pH4Fnlxl2c9WKumeDEqoYuY OCn92q7gM2EFnBSMZzGFFT3TiGPROBJS+9zTgVT9JO51NfQeG3DvrwhrFW2n3F8/Ia/YAdZhhWgfk qNrcwTOfu1PRElsZtS8Y6pzt5tE9y1efVwpHSiM661d+htuXZ+GsuMz7QwL5wUeiV3LCEQh+g/jsD MqXlJQWg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mbMRJ-0090ze-0Z; Fri, 15 Oct 2021 12:36:11 +0000 Date: Fri, 15 Oct 2021 13:35:56 +0100 From: Matthew Wilcox To: Zqiang Cc: hch@infradead.org, akpm@linux-foundation.org, sunhao.th@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mikulas Patocka , Jens Axboe , Tejun Heo Subject: Re: [PATCH] mm: backing-dev: use kfree_rcu() instead of synchronize_rcu_expedited() Message-ID: References: <20211014082433.30733-1-qiang.zhang1211@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 15, 2021 at 01:06:02PM +0800, Zqiang wrote: > > On 2021/10/15 上午10:57, Qiang Zhang wrote: > > > > > > Matthew Wilcox > > > 于2021年10月14日周四 下午7:26写道: > > > > On Thu, Oct 14, 2021 at 04:24:33PM +0800, Zqiang wrote: > > > The bdi_remove_from_list() is called in RCU softirq, however the > > > synchronize_rcu_expedited() will produce sleep action, use > > kfree_rcu() > > > instead of it. > > > > > > Reported-by: Hao Sun > > > > > Signed-off-by: Zqiang > > > > > --- > > >  include/linux/backing-dev-defs.h | 1 + > > >  mm/backing-dev.c                 | 4 +--- > > >  2 files changed, 2 insertions(+), 3 deletions(-) > > > > > > diff --git a/include/linux/backing-dev-defs.h > > b/include/linux/backing-dev-defs.h > > > index 33207004cfde..35a093384518 100644 > > > --- a/include/linux/backing-dev-defs.h > > > +++ b/include/linux/backing-dev-defs.h > > > @@ -202,6 +202,7 @@ struct backing_dev_info { > > >  #ifdef CONFIG_DEBUG_FS > > >       struct dentry *debug_dir; > > >  #endif > > > +     struct rcu_head rcu; > > >  }; > > > > >Instead of growing struct backing_dev_info, it seems to me this > > rcu_head > > >could be placed in a union with rb_node, since it will have been > > removed > > >from the bdi_tree by this point and the tree is never walked under > > >RCU protection? > > > > > > Thanks for your advice, I find this bdi_tree is traversed under the > > protection of a spin lock, not under the protection of RCU. > > I find this modification does not avoid the problem described in patch, > > the flush_delayed_work() may be called in release_bdi() > > The same will cause problems. > > may be  we can replace queue_rcu_work() of call_rcu(&inode->i_rcu, > > i_callback) or do you have any better suggestions? What? All I was suggesting was: +++ b/include/linux/backing-dev-defs.h @@ -168,7 +168,10 @@ struct bdi_writeback { struct backing_dev_info { u64 id; - struct rb_node rb_node; /* keyed by ->id */ + union { + struct rb_node rb_node; /* keyed by ->id */ + struct rcu_head rcu; + }; struct list_head bdi_list; unsigned long ra_pages; /* max readahead in PAGE_SIZE units */ unsigned long io_pages; /* max allowed IO size */ Christoph, independent of the inode lifetime problem, this actually seems like a good approach to take. I don't see why we should synchronize_rcu() here? Adding Jens (original introducer of the synchronize_rcu()), Mikulas (converted it to use _expedited) and Tejun (worked around a problem when using _expedited).