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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 33F58C4361B for ; Thu, 10 Dec 2020 03:02:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B7C382332A for ; Thu, 10 Dec 2020 03:02:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B7C382332A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D4F686B0036; Wed, 9 Dec 2020 22:02:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CD9DE6B005D; Wed, 9 Dec 2020 22:02:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC9A26B0068; Wed, 9 Dec 2020 22:02:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0140.hostedemail.com [216.40.44.140]) by kanga.kvack.org (Postfix) with ESMTP id A3AB86B0036 for ; Wed, 9 Dec 2020 22:02:25 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6E4D3180AD815 for ; Thu, 10 Dec 2020 03:02:25 +0000 (UTC) X-FDA: 77575874250.29.feet89_14155db273f4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 3F8A8180868EC for ; Thu, 10 Dec 2020 03:02:25 +0000 (UTC) X-HE-Tag: feet89_14155db273f4 X-Filterd-Recvd-Size: 5498 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Dec 2020 03:02:24 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id a1so5033307ljq.3 for ; 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=JdG231F3g+G6QmeN5QSukyBeIxOCwoUuZbQGuMjigQaZdyLT0wL4vuH2N6mp5zXjlU 4ED0caCS6iaPML79m3e24/s4ZtCF/w530PI9yMekWQipP5Gxl4bJAsL4pUfw8kFD6XzM M3F8IRz3h6i4ZpMN/d6dyvb81I+taCHiBBVNeYYdyPi8xulpygnekcNDocleSSBUUS7s LDvyDWhUldh3ZdesFbRmjufmOW0+HXa+jHL/Qbh3fZDuI9Eil4OAdcfUh1nQha1Mx6dX 2QIA8as/q5TnKeDzS5vay3dwh1MhtXwISWfQd9wVGECiwDoAEvOqlWUvqghOV8VenN6p cLbA== X-Gm-Message-State: AOAM530SyipQ4jdD7GjgQ23RUtktUP2Zyro2RMxh9Jhbk0H3wsAHOyAm U8wNsnTrRYFPC//xd95fljeejaPuRe4wm7+96mw= X-Google-Smtp-Source: ABdhPJwjascmpY96Tnzqi0NKpxktPoJnXSP0VBwfFTVswcQyH7eU8Zay190L548EDADATSwsDcNP6YaEq3VulbQW7HU= 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" 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 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.