Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp4736544rwe; Tue, 30 Aug 2022 16:18:22 -0700 (PDT) X-Google-Smtp-Source: AA6agR7g+t50pr0jUsSACM1acl5xjx/kBuck/A9+bnsYRl2z1BvXEmoQR33/jCM7a5IRDAXpcP+p X-Received: by 2002:a05:6402:4017:b0:448:2d1d:c805 with SMTP id d23-20020a056402401700b004482d1dc805mr14056982eda.269.1661901501892; Tue, 30 Aug 2022 16:18:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661901501; cv=none; d=google.com; s=arc-20160816; b=pBrSXOIdxJQcY0J1dE5k7dhtT1Od/BNG7s+Apr538Yli/tygC7d8spb4XQ+LS+Jb7n llePr6gSzpNFdtluqEVpgn7PZxHTGeE/KbhVzOdFwmm377mjbDyqaTO9DHuSyVFqBPV7 ZMBVP2x4t4HnrA/e1sOKZaoEwBNrzUy+rO27ztNc7jfNRqAGWnQxCcK3w1M9kL14qVCV En9OkkDifVDgGH7pjs35FXjxjrd6nZjCTksWaRRXP1p9tEP/K4WZ8CGKZ/9NHfh0JAYy FhCswUzw58LesVG9KuqHR3mQdNlfsrGvBnK0FcwgwBuYMy3Ft6evs+hQHkdjyO6ax6VS /p1A== 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=Vynfz887MVYBr6yRDwVUmonMdQzXB6om2UVf81HGico=; b=FCUB1A2bUoWM3ghpnk3FIZ6Y6NpbzcS7IQih9FWFCivJd/4/EIFvpXS2mSmRnFuLj7 9AOr7xH/rq8FbzlnTMDllPUqJny1JBStm8GVTIG3xkKJD541OrLgDHQ++o1AtsKLLN+2 60c4/upzNoEV9KcDnCckJwfE/EmKYq4Vux8hxr8VrAJNm55KnRwEEymATX3nlJA4424s iI4vKzo3p3i3Lhv2gNggroejI6qvwzeDSWuv/p43N60UBSAg+TgQdGMI0BjGh0tO/x5P rOaZZ2grc5UzaqEbtbOp4kqeTXDagL57Qc2YwcinuIfGPDgKBgOqadJGZPqGKQa+Ioij QB9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=RkRI1opr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n25-20020a170906089900b007312789a037si8434931eje.144.2022.08.30.16.17.56; Tue, 30 Aug 2022 16:18:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=RkRI1opr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230459AbiH3XH7 (ORCPT + 99 others); Tue, 30 Aug 2022 19:07:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbiH3XH5 (ORCPT ); Tue, 30 Aug 2022 19:07:57 -0400 Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07F4FA0246 for ; Tue, 30 Aug 2022 16:07:55 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id f185so8200811vsc.4 for ; Tue, 30 Aug 2022 16:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=Vynfz887MVYBr6yRDwVUmonMdQzXB6om2UVf81HGico=; b=RkRI1oprMfXXLpzBKkKjNEE0iBv/FK31O/Vsua3ZqNk5Jw/g1s21qy0kTygzKtnHfC lY9wR+G5UlcjIwAA4/39IeybLoAteKygD1Ow+DgBGPLpyRJ1v6W16eZKGEorS1bXrjhI 4+Qcl6NLpMPAjU8VSXwekJNBCMdrndJ6vytCRXox2Hb4G1b25XWISysG2vBM3guf69op 24L7hI6lu3HlJgn2PekWGQMvbjBOeYr8HzMgHuB12x91JrH53OLu7wEPNlXGeSiGgmUj rejb2k4cpa+RKoMggqHVM2isuE0e3U2zzPcNwVwrRuVBAwrpQIu2ss6QKoTL9+VQBtvH mh2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=Vynfz887MVYBr6yRDwVUmonMdQzXB6om2UVf81HGico=; b=bbBpIHXPCenEvby0LGmWX6mM8GNYnwkr4QAkO8wt1C8DleljErBkXud/jdEH3rkCx2 LONi5cEUDOrLq+gb0GAasxPNsldaphKlGOvCiKZ+ea5UknpjC2lwlz46Eo5YBdaq1FUQ 3FJgtKmiVjYJfomkbNEMXT3vbijGnE4mPF+5ZIY6G7pncIVVmi/ZbMM9NTtjCQFiZR/f 85fIBtJvILCkDOSNHVA1Yii8uUoemKScoBT514D+DYX1lmKqHMqiGAnGojfZ09gJLXaZ 2CjosllB6qXJLbEpL8FD+HLULpgZlBK/mJvk3bQrqLXCkaPi6wkxBjyjkDbS7KVFLnDm kq/w== X-Gm-Message-State: ACgBeo3ZydqFViTSsoBksroEB0OX5S2t8k3vk04Vs/Fe2BwZnUw+O6rw n0g80mc8OFX822lPBYv+fHJV1zo6jIAUmwhxgUtd9Q== X-Received: by 2002:a05:6102:e93:b0:390:d839:9aa2 with SMTP id l19-20020a0561020e9300b00390d8399aa2mr5153556vst.65.1661900873993; Tue, 30 Aug 2022 16:07:53 -0700 (PDT) MIME-Version: 1.0 References: <20220826150807.723137-1-glider@google.com> <20220826150807.723137-5-glider@google.com> <20220826211729.e65d52e7919fee5c34d22efc@linux-foundation.org> <20220829122452.cce41f2754c4e063f3ae8b75@linux-foundation.org> <20220830150549.afa67340c2f5eb33ff9615f4@linux-foundation.org> <20220830160035.8baf16a7f40cf09963e8bc55@linux-foundation.org> In-Reply-To: <20220830160035.8baf16a7f40cf09963e8bc55@linux-foundation.org> From: Yu Zhao Date: Tue, 30 Aug 2022 17:07:17 -0600 Message-ID: Subject: Re: [PATCH v5 04/44] x86: asm: instrument usercopy in get_user() and put_user() To: Andrew Morton Cc: Alexander Potapenko , Marco Elver , Alexander Viro , Alexei Starovoitov , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Mark Rutland , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev , Linux Memory Management List , Linux-Arch , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 30, 2022 at 5:00 PM Andrew Morton w= rote: > > On Tue, 30 Aug 2022 16:25:24 -0600 Yu Zhao wrote: > > > On Tue, Aug 30, 2022 at 4:05 PM Andrew Morton wrote: > > > > > > On Tue, 30 Aug 2022 16:23:44 +0200 Alexander Potapenko wrote: > > > > > > > > from init/do_mounts.c:2: > > > > > ./include/linux/page-flags.h: In function =E2=80=98page_fixed_fak= e_head=E2=80=99: > > > > > ./include/linux/page-flags.h:226:36: error: invalid use of undefi= ned type =E2=80=98const struct page=E2=80=99 > > > > > 226 | test_bit(PG_head, &page->flags)) { > > > > > | ^~ > > > > > ./include/linux/bitops.h:50:44: note: in definition of macro =E2= =80=98bitop=E2=80=99 > > > > > 50 | __builtin_constant_p((uintptr_t)(addr) !=3D (ui= ntptr_t)NULL) && \ > > > > > | ^~~~ > > > > > ./include/linux/page-flags.h:226:13: note: in expansion of macro = =E2=80=98test_bit=E2=80=99 > > > > > 226 | test_bit(PG_head, &page->flags)) { > > > > > | ^~~~~~~~ > > > > > ... > > > > > > > > Gotcha, this is a circular dependency: mm_types.h -> sched.h -> > > > > kmsan.h -> gfp.h -> mmzone.h -> page-flags.h -> mm_types.h, where t= he > > > > inclusion of sched.h into mm_types.h was only introduced in "mm: > > > > multi-gen LRU: support page table walks" - that's why the problem w= as > > > > missing in other trees. > > > > > > Ah, thanks for digging that out. > > > > > > Yu, that inclusion is regrettable. > > > > Sorry for the trouble -- it's also superfluous because we don't call > > lru_gen_use_mm() when switching to the kernel. > > > > I've queued the following for now. > > Well, the rest of us want it too. > > > --- a/include/linux/mm_types.h > > +++ b/include/linux/mm_types.h > > @@ -3,7 +3,6 @@ > > #define _LINUX_MM_TYPES_H > > > > #include > > -#include > > > > #include > > #include > > @@ -742,8 +741,7 @@ static inline void lru_gen_init_mm(struct mm_struct= *mm) > > > > static inline void lru_gen_use_mm(struct mm_struct *mm) > > { > > - if (!(current->flags & PF_KTHREAD)) > > - WRITE_ONCE(mm->lru_gen.bitmap, -1); > > + WRITE_ONCE(mm->lru_gen.bitmap, -1); > > } > > Doesn't apply. I did: > > --- a/include/linux/mm_types.h~mm-multi-gen-lru-support-page-table-walks-= fix > +++ a/include/linux/mm_types.h > @@ -3,7 +3,6 @@ > #define _LINUX_MM_TYPES_H > > #include > -#include > > #include > #include > @@ -742,11 +741,7 @@ static inline void lru_gen_init_mm(struc > > static inline void lru_gen_use_mm(struct mm_struct *mm) > { > - /* unlikely but not a bug when racing with lru_gen_migrate_mm() *= / > - VM_WARN_ON_ONCE(list_empty(&mm->lru_gen.list)); Yes. I got a report that somebody tripped over this "unlikely" condition (and ascertained it's not a bug). So I deleted this part as well. Will refresh the series around rc5. Thanks.