Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2883979pxu; Mon, 7 Dec 2020 19:45:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJwz2A4HWR+GOPz0By7sDtJ7EqT4sn8OjfhHKuEsCfBkXRzXVyNB4W8HDMR7tb+G++emNs// X-Received: by 2002:a17:906:3c04:: with SMTP id h4mr21049060ejg.220.1607399139219; Mon, 07 Dec 2020 19:45:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607399139; cv=none; d=google.com; s=arc-20160816; b=JbMMOE7OTZ3yV8jRM12cCHAxDsaOzDNqaJt5ReSXkOKvw3lkgA0hweJ//a2YqxnIHQ AN+ZoiUPiGBRz1ccvRexzI/RY1/qJziCBhrENF6h3A54JAuu6MkZaDLzlqrBOp/jEfAj A/mif4CP20ok9B9tzP/pCfSFYu2mcVIIeRigNJ/YcoMbHemAvcMzHJMCfFj7zsWnizBP BkqXpKpDkV0lJCfjxDjj7q5jfpksx4xziEZr89fQTxmk2WOEp53tkiHA41+GK9PrvaSR Csrew6CXH+0DzoBFHz26P3GC2/wF5tdwlo/gGvT4OT3NfK9Ru+9lVjvOMxYVVKN+0zDb QiWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=st18wMWZmgiJ3TrDzx8005xHPQOLYwLmv1k6E6JRd5I=; b=ZhXCVwBusCSiergun/B7nGoenRMZKWP5BC/P21eeu/d9zZSa0YSbQ7H/fWJl+Oz0v1 PLmOckwNHclkN3sbuHA4uSuq9yAbihwVSh8NyJm0ksmBy7p1gx4iRUe+Qcumi5xKvQkK VrVoIuzHUDRR+IN/K2HyWSoxYp9BUtXPWsUvZcwDtpYSCdEBYQ8I7vZUoHYxBPlySP+/ T61WK8819HtNyy2kQRDN/hlTtTxB25xkVYfIdyf4Ci5D7MxLJCCsX1/l+/sTgWMhvTPR 4jTAGG7nkdAvLCvZkQAlBb/8ljKOgcGztojJ1MMxD3qiMB3AAl566DWHlLy7xfvFm6Cs FF9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SruCpWIB; 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 z14si523158edr.470.2020.12.07.19.45.16; Mon, 07 Dec 2020 19:45:39 -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=SruCpWIB; 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 S1726614AbgLHBNq (ORCPT + 99 others); Mon, 7 Dec 2020 20:13:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726120AbgLHBNp (ORCPT ); Mon, 7 Dec 2020 20:13:45 -0500 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66440C061749; Mon, 7 Dec 2020 17:13:05 -0800 (PST) Received: by mail-lf1-x144.google.com with SMTP id 23so7794364lfg.10; Mon, 07 Dec 2020 17:13:05 -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:content-transfer-encoding; bh=st18wMWZmgiJ3TrDzx8005xHPQOLYwLmv1k6E6JRd5I=; b=SruCpWIBtgzCEDrLJ1rTREKNLpV9ILvhVkMaIhvHCznJyZhyYxbVuawqnzEy4/3ZVY JhkRHRtB3P0HZSl4yBQOcAZoNFHOyFlX2zaE/XZblnAGm04s+7If1/MkaCfAFme3uB1r G22aXxF2cK/u90ukI9L0+4UDwZqieOo+/aCqp6fmsmU9kolO7BsCebvuIFvJx6CPv47d Vy16Umsg8guwmLRciHbE9a9JOcLAazlwyVFtNyfxICHFEQjoSqDYWCH5uCnkDgYfcxx/ 0KOSAuf1VVEvkTH0p8IEkRDopb4UEHLF7z5sLDbid0sau2qp4HqFMlxhSrtI1OwoPR9X w0EQ== 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:content-transfer-encoding; bh=st18wMWZmgiJ3TrDzx8005xHPQOLYwLmv1k6E6JRd5I=; b=PY0ZCyefSA1DoPdok7DS0XOwd8Huwx1KEK39vNuCtcmItBwXnDTRMdvSxaL1Tvp3C5 8jfUUvx4prLEnPWTTAZ8Q4wsP1Lh57hbEFBTAxZ34jbhtCM382hNZvJXc+lNBwJ5snF7 QuuPAJlUAZ4TN4bDPqvsZ69iCl/rt0bLssIfLx/AGJZDlptR31fb0WwTn+4gxzi3fRcq pY1o5d9ssBZzGrUpL0NJc8KNihXG1MjDAkTZdDjwB0lpdVop42thxMyKV8vRlWKHHRC3 bZU/Oa969mwcLv81dhKqt5rwdjyD8gh6zLi+S7QeA8kIobIIU7+Ebn5eBwiAcj2s/kvW H8/g== X-Gm-Message-State: AOAM530+hODo7dKR3qty6MtgfLTEfraEAYJCOALVFWPp4jqxC8/ovug5 rQZ+HlDHuwAKN2Eenb90d11NdP0lOvUKRdeIcAO3AlVw2Zo= X-Received: by 2002:a05:6512:1102:: with SMTP id l2mr9527195lfg.500.1607389983850; Mon, 07 Dec 2020 17:13:03 -0800 (PST) MIME-Version: 1.0 References: <1604661895-5495-1-git-send-email-alex.shi@linux.alibaba.com> <20201110115037.f6a53faec8d65782ab65d8b4@linux-foundation.org> <20201207081556.pwxmhgdxayzbofpi@lion.mk-sys.cz> <20201207225351.2liywqaxxtuezzw3@lion.mk-sys.cz> In-Reply-To: From: Alexei Starovoitov Date: Mon, 7 Dec 2020 17:12:52 -0800 Message-ID: Subject: Re: [PATCH] mm/filemap: add static for function __add_to_page_cache_locked To: Michal Kubecek Cc: 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" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 7, 2020 at 2:59 PM Alexei Starovoitov wrote: > > On Mon, Dec 7, 2020 at 2:53 PM Michal Kubecek wrote: > > > > On Mon, Dec 07, 2020 at 02:44:22PM -0800, Alexei Starovoitov wrote: > > > On Mon, Dec 7, 2020 at 10:36 AM Justin Forbes = wrote: > > > > > > > > On Mon, Dec 7, 2020 at 2:16 AM Michal Kubecek wr= ote: > > > > > > > > > > On Thu, Nov 12, 2020 at 08:18:57AM +0800, Alex Shi wrote: > > > > > > > > > > > > > > > > > > =E5=9C=A8 2020/11/11 =E4=B8=8A=E5=8D=883:50, Andrew Morton =E5= =86=99=E9=81=93: > > > > > > > On Tue, 10 Nov 2020 08:39:24 +0530 Souptick Joarder wrote: > > > > > > > > > > > > > >> On Fri, Nov 6, 2020 at 4:55 PM Alex Shi wrote: > > > > > > >>> > > > > > > >>> Otherwise it cause gcc warning: > > > > > > >>> ^~~~~~~~~~~~~~~ > > > > > > >>> ../mm/filemap.c:830:14: warning: no previous prototype for > > > > > > >>> =E2=80=98__add_to_page_cache_locked=E2=80=99 [-Wmissing-pro= totypes] > > > > > > >>> noinline int __add_to_page_cache_locked(struct page *page, > > > > > > >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > >> > > > > > > >> Is CONFIG_DEBUG_INFO_BTF enabled in your .config ? > > > > > > > > > > > > > > hm, yes. > > > > > > > > > > > > When the config enabled, compiling looks good untill pahole too= l > > > > > > used to get BTF info, but I still failed on a right version pah= ole > > > > > > > 1.16. Sorry. > > > > > > > > > > > > > > > > > > > >>> > > > > > > >>> Signed-off-by: Alex Shi > > > > > > >>> Cc: Andrew Morton > > > > > > >>> Cc: linux-mm@kvack.org > > > > > > >>> Cc: linux-kernel@vger.kernel.org > > > > > > >>> --- > > > > > > >>> mm/filemap.c | 2 +- > > > > > > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > >>> > > > > > > >>> diff --git a/mm/filemap.c b/mm/filemap.c > > > > > > >>> index d90614f501da..249cf489f5df 100644 > > > > > > >>> --- a/mm/filemap.c > > > > > > >>> +++ b/mm/filemap.c > > > > > > >>> @@ -827,7 +827,7 @@ int replace_page_cache_page(struct page= *old, struct page *new, gfp_t gfp_mask) > > > > > > >>> } > > > > > > >>> EXPORT_SYMBOL_GPL(replace_page_cache_page); > > > > > > >>> > > > > > > >>> -noinline int __add_to_page_cache_locked(struct page *page, > > > > > > >>> +static noinline int __add_to_page_cache_locked(struct page= *page, > > > > > > >>> struct address_spac= e *mapping, > > > > > > >>> pgoff_t offset, gfp= _t gfp, > > > > > > >>> void **shadowp) > > > > > > > > > > > > > > It's unclear to me whether BTF_ID() requires that the target = symbol be > > > > > > > non-static. It doesn't actually reference the symbol: > > > > > > > > > > > > > > #define BTF_ID(prefix, name) \ > > > > > > > __BTF_ID(__ID(__BTF_ID__##prefix##__##name##__)) > > > > > > > > > > > > > > > > > > > The above usage make me thought BTF don't require the symbol, t= hough > > > > > > the symbol still exist in vmlinux with 'static'. > > > > > > > > > > > > So any comments of this, Alexei? > > > > > > Sorry. I've completely missed this thread. > > > Now I have a hard time finding context in archives. > > > If I understood what's going on the removal of "static" cases issues? > > > Yes. That's expected. > > > noinline alone is not enough to work reliably. > > > > Not removal, commit 3351b16af494 ("mm/filemap: add static for function > > __add_to_page_cache_locked") made the function static which breaks the > > build in btfids phase - but it seems to happen only on some > > architectures. In our case, ppc64, ppc64le and riscv64 are broken, > > x86_64, i586 and s390x succeed. (I made a mistake above, aarch64 did no= t > > fail - but only because it was not built at all.) > > > > The thread starts with > > http://lkml.kernel.org/r/1604661895-5495-1-git-send-email-alex.shi@linu= x.alibaba.com > > Got it. So the above commit is wrong. > The addition of "static" is incorrect here. > Regardless of btf_id generation. > "static noinline" means that the error injection in that spot is unreliab= le. > Even when bpf is completely compiled out of the kernel. I finally realized that the addition of 'static' was pushed into Linus's tr= ee :( Please revert commit 3351b16af494 ("mm/filemap: add static for function __add_to_page_cache_locked")