Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4471368pxu; Wed, 9 Dec 2020 19:06:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJy5nZN+NtxctzzGiYXab3WLO9CU4DYSWDYjY32iHPhFPFNeXc1n416wGeU8NOOJ3A2ZG0m7 X-Received: by 2002:a05:6402:491:: with SMTP id k17mr4794702edv.370.1607569616311; Wed, 09 Dec 2020 19:06:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607569616; cv=none; d=google.com; s=arc-20160816; b=Pn+fmKOx74l0pcDGHYlfU6lHQd9WTV3s/alwCF4qxjWaies8JqQtNpKf81qOykuyas b7lrhdH3ROMob9HdArn7ls4KVMGGB6sloVuteuLR64LSxk+7qIQuqp9uqbr4C51SVsrF POcusWgcyLSXbq6GSXxDQcIjROCpn9YgRjv9YS9ajYmjzH50hsqshl4cTo1gu3foFkul 4M5dJw8Wvtr99EUL7kGNMJByX75dmQ5yRd87Exq1JjncaOFZv9yVYwrGyS11RJSmkd1B SFHVpPrZyBpBgH4bmUQ6VxII8jvkFfCtYxmezBZ6rouv0iGzfyxIQEwnX/zI/PotAY8l cnRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=7VknBs3+OO4cbPFyac6UMvtv/ygbv9sRyQgm0I2urpo=; b=zEocLeFYvEtP2JNVcrmep97wFg9Y9u6xq8JDG5Pu4dWOj1WrCkFVmxvXFbEwH2Eo8r J+sEQpgzQ7fc44IFnJa801miArizL5N8Ehc7ceHM4dtfhBsBeqkc3FPMtsQSazIL4FRN pWKDDQe8A1LlEu5COPu+iJn101UozkVmHiTpVO02OsT1o7WvzmYeUCWCKMonjlYafOgR +f7GxWOgb/IWxFZv42kBBXxdFQJvn4MzW2kF0/ottjVfEBKy9hJIXorjdlhPm+0bNaMl tmrSqM7b9hbzc5BRZZxw61PUhoJYQrryFMjZ7WOL4VJ/h4sliX3XxtZyZtfCBucF6FwE yu3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=j+aa7raW; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q18si2177427eji.696.2020.12.09.19.06.32; Wed, 09 Dec 2020 19:06:56 -0800 (PST) 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=@gmail.com header.s=20161025 header.b=j+aa7raW; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727229AbgLJDDF (ORCPT + 99 others); Wed, 9 Dec 2020 22:03:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbgLJDDF (ORCPT ); Wed, 9 Dec 2020 22:03:05 -0500 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0D5CC0613CF; Wed, 9 Dec 2020 19:02:24 -0800 (PST) Received: by mail-lj1-x244.google.com with SMTP id s11so5018716ljp.4; Wed, 09 Dec 2020 19:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7VknBs3+OO4cbPFyac6UMvtv/ygbv9sRyQgm0I2urpo=; b=j+aa7raWma8/6rkZiaQr+3m+3eWKFsEjNE2U004caJXgeqcLOk/0EKUSSxYF1AnZa7 qowaaEO66hpXpFQoRi2dLfJRIH7Z9LIlcmEkm6WLOzqLOJDcQu8B679Hxc+5YzaFQKfu VKSE3GHyafnkGyZNudp2lDvCya3eH3tNh311Ue7d6j6nVyOqzPmf/FBy5Q7/qLlJXwXO 2MfdooZFVmgqzFs9XB/pJuFYIM8akbY2HJebXyLMM0VsgBzjx3Rl6ptJ0sAscl378Dv8 0V7q/Gb7jYRvbTm1SC8OAodTySZYNtXgDkrbl9OcLlWD0l611UJcv4tR1wdmWquXUyip yS6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7VknBs3+OO4cbPFyac6UMvtv/ygbv9sRyQgm0I2urpo=; b=ofEc38aMdnS2SzWtYfyQZMjUnhMIfnk035LgPjS000fY+irBd4fsGKJyKTZ4qHoCA4 AFuApU94DbuJg+9pKWPbi8rbyZvrJxsUXwD4IRcYZ+Zfu9GHh0GbYEEo4O13pF0pX8Cr 7I3rAGCVC/917r8VmriPjqwpxaofl78AeihV08ULdc0C2zBbm6KMFK6eZUtlOIZltVeK xgPGqmC5tQ0NKSqwbxJFhhb1FVQZIPIEvSOYfkaw5P9NmYhp87T/b/fz56D3GOAfY3NC 7odfxAWrJeJlQ2F/910PHKPqO/Yqt8t2hIxFN8p0igosV5KfvzLlFxNQ4WAgbEHWs8Xl TYRQ== X-Gm-Message-State: AOAM530zg2nzH70JmRlcwU/HkxQ6t/0A9W8SBKkYZKvwsdDVNAL86pCI XfED4DqhzCQhesZwpfTCSRnQBiSOcVgWTT+frMA= X-Received: by 2002:a2e:96c9:: with SMTP id d9mr2243344ljj.258.1607569343217; Wed, 09 Dec 2020 19:02:23 -0800 (PST) MIME-Version: 1.0 References: <20201207081556.pwxmhgdxayzbofpi@lion.mk-sys.cz> <20201207225351.2liywqaxxtuezzw3@lion.mk-sys.cz> <20201209144628.GA3474@wp.pl> <20201209150826.GP7338@casper.infradead.org> <20201209155148.GA5552@wp.pl> <20201209180552.GA28692@infradead.org> <20201209223206.GA1935@home.goodmis.org> <20201209213126.79ca1326@oasis.local.home> In-Reply-To: <20201209213126.79ca1326@oasis.local.home> From: Alexei Starovoitov Date: Wed, 9 Dec 2020 19:02:11 -0800 Message-ID: Subject: Re: [PATCH] mm/filemap: add static for function __add_to_page_cache_locked To: Steven Rostedt Cc: Christoph Hellwig , Stanislaw Gruszka , Matthew Wilcox , Michal Kubecek , Justin Forbes , bpf , Alex Shi , Andrew Morton , Souptick Joarder , Linux-MM , LKML , Alexei Starovoitov , Daniel Borkmann , Josef Bacik Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 9, 2020 at 6:31 PM Steven Rostedt wrote: > > On Wed, 9 Dec 2020 17:12:43 -0800 > Alexei Starovoitov wrote: > > > > > > > FWIW, I intend to do some consolidation/renaming in this area. I > > > > > > trust that will not be a problem? > > > > > > > > > > If it does not break anything, it will be not a problem ;-) > > > > > > > > > > It's possible that __add_to_page_cache_locked() can be a global symbol > > > > > with add_to_page_cache_lru() + add_to_page_cache_locked() being just > > > > > static/inline wrappers around it. > > > > > > > > So what happens to BTF if we change this area entirely? Your IDs > > > > sound like some kind of ABI to me, which is extremely scary. > > > > > > Is BTF becoming the new tracepoint? That is, random additions of things like: > > > > > > BTF_ID(func,__add_to_page_cache_locked) > > > > > > Like was done in commit 1e6c62a882155 ("bpf: Introduce sleepable BPF > > > programs") without any notification to the maintainers of the > > > __add_to_page_cache_locked code, will suddenly become an API? > > > > huh? what api/abi you're talking about? > > If the function __add_to_page_cache_locked were to be removed due to > the code being rewritten, would it break any user space? If not, then > there's nothing to worry about. ;-) That function is marked with ALLOW_ERROR_INJECTION. So any script that exercises it via debugfs (or via bpf) will not work. That's nothing new. Same "breakage" happens with kprobes, etc. The function was marked with error_inject for a reason though. The refactoring or renaming of this code ideally should provide a way to do similar pattern of injecting errors in this code path. It could be a completely new function, of course.