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 6DD64C4332F for ; Tue, 14 Nov 2023 16:46:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3B736B02F7; Tue, 14 Nov 2023 11:46:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EEB9E6B02F9; Tue, 14 Nov 2023 11:46:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDA5D6B02FA; Tue, 14 Nov 2023 11:46:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D00266B02F7 for ; Tue, 14 Nov 2023 11:46:47 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9D52340466 for ; Tue, 14 Nov 2023 16:46:47 +0000 (UTC) X-FDA: 81457138854.14.DC142AA Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 7CDB318001A for ; Tue, 14 Nov 2023 16:46:45 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf06.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699980405; 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; bh=tRozKCHo2L86h/H7oGr8QRvNNJzJg2txoy/1KwXkuWI=; b=BxWRusDo11RvjADsDwZpEAw9U2z2kb2Bsf6qUI1tGDe1yAzmeLwv0q2LUHFI1H1lQI/gWN qlVzK0+0FFRPn2o25dX+4R1SwYaXP/TGq1BKSWMDtooyIE1mDStD1yD8Az6H7XsOtbVIhb bt1EyNgRt54frkPLm+0CN1Vr5QuS4gw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf06.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699980405; a=rsa-sha256; cv=none; b=ukB1liGwNmUZZCaktLn6xnidfXdsM2vzw09NjbNwzqJguZyAWwMzZVaVuaAG4c5/3JBbLl /ehqmgP9SLNPoO9B7ARfjQb2wJeyZshRLk5RTkrriwIICVmtb/DqBLP0t9+TYXGV7CnZIN GMlKBKpWeCN3L5avJoNzpHsLvCgtlq0= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7BEA8C15; Tue, 14 Nov 2023 08:47:29 -0800 (PST) Received: from [10.1.27.144] (XHFQ2J9959.cambridge.arm.com [10.1.27.144]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B799C3F641; Tue, 14 Nov 2023 08:46:43 -0800 (PST) Message-ID: <1628606f-a396-448d-91ec-6c4ce85b5358@arm.com> Date: Tue, 14 Nov 2023 16:46:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] mm: More ptep_get() conversion Content-Language: en-GB To: Matthew Wilcox Cc: Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org References: <20231114154945.490401-1-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7CDB318001A X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: tfiknk4x7khtb6o7f4rfshp7443ru7yf X-HE-Tag: 1699980405-8745 X-HE-Meta: U2FsdGVkX1+aliNUywEDeYHNvOuW+Xu+RWkrxEeLx2t6+NwYfaLjkqHNQjh3ekLTtfGJlUEX+u0uskkgrfV95j0HkwmP8XgT6a83CpP6bCBJk9Q5Vkad7KuDm4A1hOvCOr7PgAPXeastcPdY7CuQJzPffNJbzET2PkusMwHE222dbkOeuBltuWlfE/1c9uulzuRZ8MhNnreSPAcRvoGR6ojXeFx8KpuInSeTlCudczMubhW4zD8Z1I5iHm1/W4oHyWU3MGLw7ke3xj0l2jth0kBSrCEVTHbSXkIW2qJmAcvBdhM44o4teWidHhCFuVJEauVwi7XAWHifHPJY22fbn04sC92nNYNIf6wfviM8jJSYEBMR6rHtmkmjZFxy6LB5Q/UXq1VdNCK0skgBqY8OjehpavG9IALQsfMon0jsYfaqSclu42b44q8Vs/o+uWEBTWIfveTgJy9emz2W6xZVoFZjZJBp0pEmkReWkZcK7sFrzNKIjXX5WHFqW4B5+6/hayw/PPJEkaSwBNDEn+BRKuOytrfzNE40dzRs3SZO9owyAH0f2wFbICI8tB01XDmno8ZlxIsHAXnOKlFsJQPBEXPoF00VaR1X+i0QaiDOfZ9FGiDVBpv0OmzmZv0XBhIafnax2gXtb8g2TrVqANpxYEpoQmtUj0NmUnEMV1R3TOJHDC/RAOf+pvEURrgYFwT20rkEfQ6FLcVT8OwcRn5wZl2kS4RoQqaL1DkBW0ww67zN4jy6Ad65/VXYuOCFL3SoFnH3oeOTvDNoVhdUZvEziuOfK6Cb+NPx721A8pAqrq1aYVJ3OaAsoLtCO2ftyTQsWYDcsbM4zktVB/pXpea28gPATxnmvKD/B9QG2E9A6eKlnZnXKNPoQ5vuySTESXsKWCckOvVJsffUHeIUk1F5cRIlHdpq/+nsdUcfpNmqdTfcoPvneK9cHWeKzoryEViLWmfiKJMUrWwvkXqh4AU xagGT2yl XS5ARobBWlPCOdwrK2fuOiTK+rGgAeErRRA3ihJjPgixQJ8DzlXPoX2w6rlknttsU893pe0OahpyJDXouLYanPkbjtmhsPkMUnZKCXSKcsolUbQq2CVCBdRcnWoRHaMR7LVmNkimDPcwJdXjnQP8vFuzkhO03FCyiWsMXcGwXrXdrQrk4W6I58ZXOL8rNcNPGEklm X-Bogosity: Ham, tests=bogofilter, spamicity=0.000041, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 14/11/2023 16:30, Matthew Wilcox wrote: > On Tue, Nov 14, 2023 at 03:49:45PM +0000, Ryan Roberts wrote: >> Commit c33c794828f2 ("mm: ptep_get() conversion") converted all >> (non-arch) call sites to use ptep_get() instead of doing a direct >> dereference of the pte. Full rationale can be found in that commit's >> log. >> >> Since then, three new call sites have snuck in, which directly >> dereference the pte, so let's fix those up. >> >> Unfortunately there is no reliable automated mechanism to catch these; >> I'm relying on a combination of Coccinelle (which throws up a lot of >> false positives) and some compiler magic to force a compiler error on >> dereference (While this approach finds dereferences, it also yields a >> non-booting kernel so can't be committed). > > Well ... let's see what we can come up with. > > struct raw_pte { > pte_t pte; > }; pte_t is already a wrapper around the real value, at least on arm64: typedef struct { pteval_t pte; } pte_t; So doesn't adding extra wrapper just suggest that next year we will end up adding a third, then a fourth...? Fundamentally people can still just do pte->pte to dereference. The approach I took with the compiler magic I describe above was to pass around: typedef void* pte_handle_t; which is just a pointer to pte_t, but you can't deref without an explcit cast. So then I insert the explicit casts in the 5 or 6 places in the arm64 arch code that they are required and it mostly just works. (I have the core patch which is pretty small, then do find/replace on "pte_t *" -> "pte_handle_t" and it just works). But its a LOT of churn in the non-arch code, and leaves the other arches broken, many of which are dereferencing all over the place - it would be a huge effort to fix them all up. > > static inline pte_t ptep_get(struct raw_pte *rpte) > { > return rpte.pte; > } > > Probably quite a lot of churn to put that into place, but better than > a never-ending treadmill of fixing the places that people overlooked? Yes and no... agree it would be nice to automatically guard against it, but I didn't want to spend the next 6 months of my life fixing up all the other arches...