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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 340DEECAAA1 for ; Tue, 30 Aug 2022 23:07:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 994278D0001; Tue, 30 Aug 2022 19:07:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91B2F6B0072; Tue, 30 Aug 2022 19:07:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BB858D0001; Tue, 30 Aug 2022 19:07:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6EEAE6B0071 for ; Tue, 30 Aug 2022 19:07:55 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 45B3740149 for ; Tue, 30 Aug 2022 23:07:55 +0000 (UTC) X-FDA: 79857798510.29.1008C4A Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) by imf16.hostedemail.com (Postfix) with ESMTP id 06B6318001A for ; Tue, 30 Aug 2022 23:07:54 +0000 (UTC) Received: by mail-vs1-f42.google.com with SMTP id i1so2825795vsc.9 for ; Tue, 30 Aug 2022 16:07:54 -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=AIWZ9/o+G0Laxr6Bp068TibfhSgAWlXiGGHho6KyBjRKdGPFmLcxQqYJG8ceOEVRks pHBYJx04OW35OxmGkCHkdXn0rEKG1hlcZsIU3Jzq53dNLW+G6ZzpEU7oYYtC/sWehXjc lajZDvAnWk3pvSSvafMJ+tftWvXdADnCRGHwXv1ULvfhczkKi2i9wrYbZcdTasNy2eXk 2R7INrW18/9g6qpKTE9a/aGeKVBsUc+BLUxcvVQWqiDndBn3a4mUfgJqffvY1kgJf/P3 lfSSPZfNmOf44clygsfmwj2hWEfWcwEjdXNbd3F69Cy7ZVfLkbVoqc2i++J4oxVoI6YL EGnQ== X-Gm-Message-State: ACgBeo2HZh8X27bPSdV27ocDbsOIjds3i6t81FMtQFri/5snPATwo/IM bLB9ZDA9JFw+s/BTwLb+adxKwsmqMX9k36x+2TPJIg== X-Google-Smtp-Source: AA6agR7+hhtQNr2WwEZoh61BOKtr4K7KVpgcvB0U7/bL9aMM3hfCAlmVJnFGNFxDqyRYeNjdxYV5Ue+xFWHIlN3sOxw= 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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661900875; a=rsa-sha256; cv=none; b=p+2zlZYMMSsYSDOEbMl+Ot7vQx/GjCv7EsHa1HTFEAeVTht/Q2r5AteY41lVpxRpgN/x8r lvZ4C7H6RB48Jet8Ql6cP3l73YmE43QuEJp5u6rTg+4SpDV5VE5ghzT8ub6q4PipDXoL/C VJvOaRXJiB5iZdMT+oMmclHjmnt+gj0= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=RkRI1opr; spf=pass (imf16.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.42 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661900875; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Vynfz887MVYBr6yRDwVUmonMdQzXB6om2UVf81HGico=; b=3yXEYwjEEkKvBgY2c/j1BT4HU81wr8leGWfHlmqTwTaqpLGqBKDDmy4Ci8+tvOJ40qsfyu XY96fABPFe9ZBdGnWpNafiUFdzIBEvNAGHCDD/Zp/EO1w40wg4svKobGNPhW/c0CCZnUBs Uc+GnF7yZ4U/8xcA7QsFsrXg8ReeygI= X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 06B6318001A X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=RkRI1opr; spf=pass (imf16.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.42 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: 9mw49t6ii1fbcfcwaefginnxah6a86oz X-HE-Tag: 1661900874-486743 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 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.