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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59CD6C433ED for ; Thu, 8 Apr 2021 20:49:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CDD9A61181 for ; Thu, 8 Apr 2021 20:49:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDD9A61181 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=dxuuu.xyz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3A64E6B0036; Thu, 8 Apr 2021 16:49:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 37C426B006C; Thu, 8 Apr 2021 16:49:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 243EB6B006E; Thu, 8 Apr 2021 16:49:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 07DBA6B0036 for ; Thu, 8 Apr 2021 16:49:41 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id ABE19A74C for ; Thu, 8 Apr 2021 20:49:40 +0000 (UTC) X-FDA: 78010390920.34.61114C0 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by imf08.hostedemail.com (Postfix) with ESMTP id DDA5080192E9 for ; Thu, 8 Apr 2021 20:49:31 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CEA125C011A; Thu, 8 Apr 2021 16:49:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 08 Apr 2021 16:49:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=MQtSHPJqtnoPnzsLmLnzXyuX+LY DZOGWduO0MWZnQ4w=; b=V0/BROVaZviWOXWayii4M2rCj+aWENTi/HG+cw32BK6 JwhVkZg2PDP75XW8rAo4GS1xZQZ2ILRd2l4ZimrvbLdGYbv7IBIqsn/+paoScYUG QwhDVizRXDtp0qp8MNmLjSmqdq8BgOwXeHbrM5ZARicn8lvD2Mr1pUkvlH1eI/p8 WQLiLuzD66Crf5G/8F2h86YpLZ3KDJi7uZyldlvPb754gQozWoKp8a1ihrPC5qYS KpqpSoFUTxkxY5sPylqoIMRnordMt8jczn6Ci9kFJbwMOpMp+Blh+UzjvOlVCkZP vMERXaRuzac1ndSim1CPUVvwG1btvbTxGq4GXHR0g7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=MQtSHP JqtnoPnzsLmLnzXyuX+LYDZOGWduO0MWZnQ4w=; b=BL1kxNiYfljceJuJ5rR2GA 21qCSxk5t0DAhehulEWmXzDETz/h5OX//HNTnOdDXwsvTacRu49pWW53U6vLPyx+ kdm15sbFdteNVvZnUzlp/YlauBg8pDZ2+WSfxQmFdOVK/0Ne/LOm1BY8zjw6kFIF XJF/+2vF0ZQLSeKW1T9a0VizAP/RmVqAJ7cXdx+RSOlKQnzNirp/1rNGIJgE9ZWR t77Ehod/E5YrDajk2Sxe+jvEJWnqZRAvXj8s6/N28UEyuEc246JuL6ELoyCMiRO+ h7sxP2a/X2dJLPQdumIhEaIX6KfAcsWrQ8bbCziVGQ7aSOuYH08TdSvQ4XbUUxKA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudejledgudehhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enfghrlhcuvffnffculdejtddmnecujfgurhepfffhvffukfhfgggtuggjsehttdertddt tddvnecuhfhrohhmpeffrghnihgvlhcuighuuceougiguhesugiguhhuuhdrgiihiieqne cuggftrfgrthhtvghrnhepueduvdejfefflefgueevheefgeefteefteeuudduhfduhfeh veelteevudelheejnecukfhppeduieefrdduudegrddufedvrddunecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugiguhesugiguhhuuhdrgiih ii X-ME-Proxy: Received: from dlxu-fedora-R90QNFJV (unknown [163.114.132.1]) by mail.messagingengine.com (Postfix) with ESMTPA id 0BD031080063; Thu, 8 Apr 2021 16:49:36 -0400 (EDT) Date: Thu, 8 Apr 2021 13:49:35 -0700 From: Daniel Xu To: Al Viro Cc: bpf@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, jolsa@kernel.org, hannes@cmpxchg.org, yhs@fb.com Subject: Re: [RFC bpf-next 1/1] bpf: Introduce iter_pagecache Message-ID: <20210408204935.4itnxm4ekdv7zlrw@dlxu-fedora-R90QNFJV> References: <22bededbd502e0df45326a54b3056941de65a101.1617831474.git.dxu@dxuuu.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: DDA5080192E9 X-Stat-Signature: qoedanqwdninikriru9tr7og9b1tn74u Received-SPF: none (dxuuu.xyz>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=out3-smtp.messagingengine.com; client-ip=66.111.4.27 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617914971-402663 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 Thu, Apr 08, 2021 at 04:45:37PM +0000, Al Viro wrote: > On Wed, Apr 07, 2021 at 02:46:11PM -0700, Daniel Xu wrote: > > > +static void fini_seq_pagecache(void *priv_data) > > +{ > > + struct bpf_iter_seq_pagecache_info *info = priv_data; > > + struct radix_tree_iter iter; > > + struct super_block *sb; > > + void **slot; > > + > > + radix_tree_for_each_slot(slot, &info->superblocks, &iter, 0) { > > + sb = (struct super_block *)iter.index; > > + atomic_dec(&sb->s_active); > > + radix_tree_delete(&info->superblocks, iter.index); > > + } > > ... and if in the meanwhile all other contributors to ->s_active have > gone away, that will result in...? Ah right, sorry. Nobody will clean up the super_block. > IOW, NAK. The objects you are playing with have non-trivial lifecycle > and poking into the guts of data structures without bothering to > understand it is not a good idea. > > Rule of the thumb: if your code ends up using fields that are otherwise > handled by a small part of codebase, the odds are that you need to be > bloody careful. In particular, ->ns_lock has 3 users - all in > fs/namespace.c. ->list/->mnt_list: all users in fs/namespace.c and > fs/pnode.c. ->s_active: majority in fs/super.c, with several outliers > in filesystems and safety of those is not trivial. > > Any time you see that kind of pattern, you are risking to reprise > a scene from The Modern Times - the one with Charlie taking a trip > through the guts of machinery. I'll take a closer look at the lifetime semantics. Hopefully the overall goal of the patch is ok. Happy to iterate on the implementation details until it's correct. Thanks, Daniel