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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A37DC433F5 for ; Fri, 15 Oct 2021 03:39:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ED733611BD for ; Fri, 15 Oct 2021 03:39:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ED733611BD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=qcraft.ai Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 3F4C66B006C; Thu, 14 Oct 2021 23:39:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A4FF6B0071; Thu, 14 Oct 2021 23:39:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26BDC900002; Thu, 14 Oct 2021 23:39:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0093.hostedemail.com [216.40.44.93]) by kanga.kvack.org (Postfix) with ESMTP id 1815B6B006C for ; Thu, 14 Oct 2021 23:39:46 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B8FC8180EE412 for ; Fri, 15 Oct 2021 03:39:45 +0000 (UTC) X-FDA: 78697267530.01.A25DBB8 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf13.hostedemail.com (Postfix) with ESMTP id 590241041527 for ; Fri, 15 Oct 2021 03:39:44 +0000 (UTC) Received: by mail-pf1-f180.google.com with SMTP id q19so7256747pfl.4 for ; Thu, 14 Oct 2021 20:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qcraft-ai.20210112.gappssmtp.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=8tJVhTiQMmvCknI0GqVyNSnP+8+m2C9KfZp82f5A95w=; b=OgPHax59p7dxOq1UneLj2e24WVL+J8TRz9e5yW7DQz3JIOUVWWi2uUX013KkbDxBgt jE9CFu6TM/B3csSS7vLYRSzn/HObUJq82Rq5RJw1nQcc/mZQeQSyv2KoTFJpBelI3Qmo M3QwP7qpXdpsrLogBW3MQekgDEn+2YV5JJuDvDG2E/wVe8bUH11QERDFn9kiitfyi+2h jIbzaXChRWrqQEyZsN3HKFSPdx5ik8RpMvFyUPysoLHFoPCaO+RqZ046pNV0O55vKhOe 5zFo2QAd1fstBRKoUJ9e/mno6f3oPTtChI5VIc8RW0DmV7joHl1JvdTD9fsNAx71Awxa SQvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8tJVhTiQMmvCknI0GqVyNSnP+8+m2C9KfZp82f5A95w=; b=SsFbqbOdKAK3tCFjReAOz3uvFpnJQLjQeB1PGAoyFzVeRQJKlwpK4DGcn2gFSrjZEH 6SkQZUBSXvD1EjJKutw35CEVC/J0gNOGIq76arncbrm7LvOm7r1md9cyxee5lq34g9FK tXLuvK3SyhWPhfsuu2l+0AHzxc3kz2e5kl1CQhKB917VKqOQgxzAx6cRfgMsLqbftHc3 CefDfSmXi1oiYPVINT3Bxb5AkHuFPUXELlESw0SQk9HAa5PjnUuSpgjx4Qqu9+kGCLOD KwYszwvuGoDpSbO0e7BtzYpqEwxVrnK27BB7BB9cUGDAMAqZx+H6wrya2gWMcqGSniaS 7ljg== X-Gm-Message-State: AOAM5311vXSfe48Dbn+lYlYutCAQ95kdutbmnyrEK90Vi7JoUAnR+b2E jtpQFGruX5qz9DT/mGP39DBwKwGOVMZZ7ybY/nQ= X-Google-Smtp-Source: ABdhPJwS4CJKkN0q/MXyh0mORBFW5eWSnNoCUxu/gCWLts25/W4/CT6tTymJiYq0q1ruu0FBhsxYZg== X-Received: by 2002:a63:cf44:: with SMTP id b4mr7363255pgj.215.1634269184039; Thu, 14 Oct 2021 20:39:44 -0700 (PDT) Received: from [172.18.2.138] ([137.59.101.13]) by smtp.gmail.com with ESMTPSA id v12sm3726240pjd.9.2021.10.14.20.39.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Oct 2021 20:39:43 -0700 (PDT) Subject: Re: [PATCH] mm: backing-dev: use kfree_rcu() instead of synchronize_rcu_expedited() To: Matthew Wilcox , Zqiang , hch@infradead.org Cc: akpm@linux-foundation.org, sunhao.th@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20211014082433.30733-1-qiang.zhang1211@gmail.com> From: zhangqiang Message-ID: <0c31aa44-62fb-58a7-abaf-aec580e561bd@qcraft.ai> Date: Fri, 15 Oct 2021 11:39:40 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 590241041527 X-Stat-Signature: naj6qi4tbx8zj54zig7m4go457g64rk7 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=qcraft-ai.20210112.gappssmtp.com header.s=20210112 header.b=OgPHax59; dmarc=none; spf=pass (imf13.hostedemail.com: domain of zhangqiang@qcraft.ai designates 209.85.210.180 as permitted sender) smtp.mailfrom=zhangqiang@qcraft.ai X-HE-Tag: 1634269184-195886 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2021/10/14 =E4=B8=8B=E5=8D=887:24, Matthew Wilcox wrote: > 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_hea= d > could be placed in a union with rb_node, since it will have been remove= d > 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=20 protection of a spin lock, not under the protection of RCU. I find this modification does not avoid the problem described in patch,=20 the flush_delayed_work() may be called in release_bdi() The same will cause problems. may be=C2=A0 we can replace queue_rcu_work() of call_rcu(&inode->i_rcu,=20 i_callback) or do you have any better suggestions? Thanks Zqiang