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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=ham 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 1FB69C433E0 for ; Thu, 14 Jan 2021 20:10:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA90323117 for ; Thu, 14 Jan 2021 20:10:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA90323117 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AA60E8D0120; Thu, 14 Jan 2021 15:10:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A562E8D00F0; Thu, 14 Jan 2021 15:10:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 993BA8D0120; Thu, 14 Jan 2021 15:10:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id 8644D8D00F0 for ; Thu, 14 Jan 2021 15:10:00 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 45A28180AD807 for ; Thu, 14 Jan 2021 20:10:00 +0000 (UTC) X-FDA: 77705471760.21.comb66_0a1110427529 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 26E1E18045A44 for ; Thu, 14 Jan 2021 20:10:00 +0000 (UTC) X-HE-Tag: comb66_0a1110427529 X-Filterd-Recvd-Size: 7261 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 20:09:59 +0000 (UTC) Received: by mail-pf1-f182.google.com with SMTP id m6so4031894pfk.1 for ; Thu, 14 Jan 2021 12:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iB3Jw2esdANcXXH44eCvOPFepBca1nOJGZGOnewNohA=; b=lcbZ3BC5P4onmRMYQ9hVh1BhepJnL5kj7yeaJnlqQJci2AhhD1uTyOtCSGG7iYVnH9 zbJtF1PW43ulgDUYMEtMSkSXlBmPDuw0wXuSjZqlD8oZvPfetlNRcYRkNokRTsW3YJAC fWkpDS4G9qlMGD4taq4KMbrtifDbnv35KGEHA1GboksETpRQZHyF8b+sJ89+PEhudn8U SLQeGGdall+yZDICyOE3k6fGcJV8IXsQzxJZna0mPNqa7Qz8QdBmtbH6rohR8YAiafdJ cvVM80mIC64CxX6Dx2JKBcNVWLRmuqrqo5zghfxmRsnEUOll/H56kCb4Zk649Q+bHkeO Eaxg== 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=iB3Jw2esdANcXXH44eCvOPFepBca1nOJGZGOnewNohA=; b=G7Zdd8twRao2sJdUSaYyWU2IumR+Up5cHeyccPdOwn3DaQMY4pbH8GZI0J20StHfTv IeujSn1enlixRkx75UqA8Y3tiele/YvDMxx+DQoKL6uezB6UYm6r3RoQMyIuto4dWUfG X1CnEfMLFtn1ssRQcure9SRlJwFkMer5v3jiZvjLBYkfMcIZbLYpgaj/rToMSfn0/55R iGxmxpa8qnK7ekKlcemkBzprZwk7XEzyB3AVQ/1RT3hVtIp9UhYPQBgKCPvzYW1h/1QW 6NGDa2Yif9kb/1AoE54xywhGS+UiHyrzUlCTZUhOJgzaHKphMHglC1Ygc2bDSa4UPRvp I+fQ== X-Gm-Message-State: AOAM533Ttbe15pe08FklStiVm2TySDbZ0X7FEYYy57KxJVu/lJHjyEA8 qyvjoPQFcW3KrwBmUP1iOtcOiF8YCPrnnFBCOdaAoQ== X-Google-Smtp-Source: ABdhPJxdMZ11aeWYCth9RA14e3mnlFGCx9jVnSpd7hRCxYaZPBNfFDyacpfxrLMLEc0a6oFlcupomXmnJU7N7G73aak= X-Received: by 2002:a63:1142:: with SMTP id 2mr9162380pgr.263.1610654998210; Thu, 14 Jan 2021 12:09:58 -0800 (PST) MIME-Version: 1.0 References: <20210114175934.13070-1-will@kernel.org> <20210114175934.13070-5-will@kernel.org> <20210114190021.GB13135@willie-the-truck> <20210114194129.GA13314@willie-the-truck> In-Reply-To: <20210114194129.GA13314@willie-the-truck> From: Nick Desaulniers Date: Thu, 14 Jan 2021 12:09:47 -0800 Message-ID: Subject: Re: [RFC PATCH 4/8] mm: Separate fault info out of 'struct vm_fault' To: Will Deacon Cc: Linus Torvalds , Linux Kernel Mailing List , Linux-MM , Linux ARM , Catalin Marinas , Jan Kara , Minchan Kim , Andrew Morton , "Kirill A . Shutemov" , Vinayak Menon , Hugh Dickins , Android Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, Jan 14, 2021 at 11:41 AM Will Deacon wrote: > > On Thu, Jan 14, 2021 at 11:09:01AM -0800, Linus Torvalds wrote: > > On Thu, Jan 14, 2021 at 11:00 AM Will Deacon wrote: > > > > > > I tried that initially, but I found that I had to make all of the > > > members const to get it to work, at which point the anonymous struct > > > wasn't really adding anything. Did I just botch the syntax? > > > > I'm not sure what you tried. But this stupid test-case sure works for m= e: > > > > struct hello { > > const struct { > > unsigned long address; > > }; > > unsigned int flags; > > }; > > > > extern int fn(struct hello *); > > > > int test(void) > > { > > struct hello a =3D { > > .address =3D 1, > > }; > > a.flags =3D 0; > > return fn(&a); > > } > > > > and because "address" is in that unnamed constant struct, you can only > > set it within that initializer, and cannot do > > > > a.address =3D 0; > > > > without an error (the way you _can_ do "a.flags =3D 0"). > > > > I don't see naming the struct making a difference - apart from forcing > > that big rename patch, of course. > > > > But maybe we're talking about different issues? > > Urgh... > > We _are_ both on the same page, and your reply above had me thinking I've > lost the plot, so I went back to the start. Check out v5.11-rc3 and apply > this patch: > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index ecdf8a8cd6ae..1eb950865450 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -514,11 +514,14 @@ static inline bool fault_flag_allow_retry_first(uns= igned int flags) > * pgoff should be used in favour of virtual_address, if possible. > */ > struct vm_fault { > - struct vm_area_struct *vma; /* Target VMA */ > + const struct { > + struct vm_area_struct *vma; /* Target VMA */ > + gfp_t gfp_mask; /* gfp mask to be used fo= r allocations */ > + pgoff_t pgoff; /* Logical page offset ba= sed on vma */ > + unsigned long address; /* Faulting virtual addre= ss */ > + }; > + > unsigned int flags; /* FAULT_FLAG_xxx flags */ > - gfp_t gfp_mask; /* gfp mask to be used for alloca= tions */ > - pgoff_t pgoff; /* Logical page offset based on v= ma */ > - unsigned long address; /* Faulting virtual address */ > pmd_t *pmd; /* Pointer to pmd entry matching > * the 'address' */ > pud_t *pud; /* Pointer to pud entry matching > > > Sure enough, an arm64 defconfig builds perfectly alright with that change= , > but it really shouldn't. I'm using clang 11.0.5, so I had another go with > GCC 9.2.1 and bang: > > mm/filemap.c: In function =E2=80=98filemap_map_pages=E2=80=99: > mm/filemap.c:2963:16: error: assignment of member =E2=80=98address=E2=80= =99 in read-only object > 2963 | vmf->address +=3D (xas.xa_index - last_pgoff) << PAGE_SHIFT; > | ^~ > make[1]: *** [scripts/Makefile.build:279: mm/filemap.o] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [Makefile:1805: mm] Error 2 > make: *** Waiting for unfinished jobs.... > > Nick -- any clue what's happening here? We would like that const anonymou= s > struct to behave like a const struct member, as the alternative (naming t= he > thing) results in a lot of refactoring churn. Weird, looks like a bug to me in Clang, filed https://bugs.llvm.org/show_bug.cgi?id=3D48755. --=20 Thanks, ~Nick Desaulniers