From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93F191DE8A4 for ; Thu, 11 Dec 2025 00:29:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765412977; cv=none; b=KXWIpsV6iF/B9cBPWinaH/c19bCO1NlWool+ikBkoXQ4plUrtX+MVrtQA+vWpct5K8inX41xYok8b6A8RmmgJDdX+6PYgpopKl32qKzsIG0KLdFAGS66of/iKTTnPAD8Y4/ALcR1Yx79oB22KXv81o0C/kbytQpE1B3xwmloMhQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765412977; c=relaxed/simple; bh=miPtFXPjQNvxTz6ptrwfqOKKfUKaGCFr92LjoipOyMs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WyvcRsF3frtkzp6tDI2RGLlteFFUkyQeW7TgXzIovIknj4i5XQquk88kcUXxHg1Ue0dVKPs1h1/YJYrKjjDJ0hH3HQ5ZEa1oQ8o83Yb8VoWWUAIVA9C/ZvjkS7VMZjzTdjK7902GQYE9BY9W28YSGWg8ZXsDQsRlUadC+zISw9M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com; spf=pass smtp.mailfrom=sifive.com; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b=UhH4xqTJ; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="UhH4xqTJ" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-298144fb9bcso4296955ad.0 for ; Wed, 10 Dec 2025 16:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1765412975; x=1766017775; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hph6c6mLrMrxrVM4J3elgrKqEusrkULz2AJc0PIUBG4=; b=UhH4xqTJV7OnKLxaLGTHqPjOX7o83Kw1MFwnZ4ybCSn7mWbrWDS9tlL/B7htYglQl5 543aU/Y5vzywK8LdUoT6gTBMFlLtpGMe/xFt4xUNGOHD9qUd8zux6c5KhinYV7G4MbqN wM/1EHcFgSr9ZdcEdzO/ave4EMngGXISW4Jk6/k/Blw0MDTNJqHjgazxEroXB8xATTJC +YWTmw3iHdcKs3Fls6wiCroVsUdpOFn22ESwOpiFowDa1rijm8a+2Kw//zd1HDf8XQVE 8jYd0Yy5io/4zxoMqI1rf89yU5va4T789oM38lkd6Dccw/9YVOoQQwRIyrmyFHNoFETE zxdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765412975; x=1766017775; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hph6c6mLrMrxrVM4J3elgrKqEusrkULz2AJc0PIUBG4=; b=tneIf/ot2zTWUzyUZMIzGY+rWaA6+gvXLkDPPhxxp29tvovxUYmOOEsPxtuo9Bh22x GwgkX8EGUN7h34ggDKBM26RpBeSBmtdzVySYJpp/vfCoU66LUuArZMNE81Dp7VDGqWBG 5D4alPw+pKjDShomvVRzNfwyTo4yOJC7xYBYmLJJeln9AN7mSwBBCvLcRnDW9wbIPEjR aIJaryV0xf92GHaNvYTKnEFfrZTwYg+L0MiMJ8UubjxmDOB9yBc9YnGj1hiUTo1Q+9cW ZI4n6ushkzxlWCtYjrH9rDXjfg1TSmCB6M9YGiPzOZIHcLRy6XzrjfVojfraKBL5nq+M D88g== X-Forwarded-Encrypted: i=1; AJvYcCXaE2SiFY72GuD7Xc8DEmjk6NNPXSjNixGULoPTd91WA1oxjggQ8SDihnNXE62F6uTA3QJpp+LSmN6dvvo=@vger.kernel.org X-Gm-Message-State: AOJu0YwK91cYKgm5+4yEbOZAekJCK1sUu1vzSC+xOy02O23NEvV9Quqk zY06UR/+KqlIdmX41ULaAqMR2IFZnHhRqQkAFs6e95Qbi6Ls8RwjeDeYaHDwQwMOczY= X-Gm-Gg: AY/fxX4Gfi7Y/jJ+m+xEWUr4Wz00olhgv2NmIxcNbFZpN3c2nejmDlwhNYyhlvbd1T6 wibJY+EOkrSOuyye9JIXZAZJYzoFGS57o6Levz/YSKH5Y022/Tdic0UAXU1ej4JJh1j/IvyEQeL 1QBPpIApXRN5m6fZ8KleIOfO1buAccdO5199nAAtcuFNl2PGlCMi8e85qOagzhMGU//oraA6LJR DvVqF0UmSIV3CBDI09g7DZqumLorWSbkMAUf46rZSCp9YSdWa5yplEcABdYQeg+JM5eojAft7mU ypXnbM/QMt7dkpfl37ciF15q3Nx0qADsF36UsiJtJOfujs9ff5afbnUZAjc2VSrXW/yXFF4Bcuy 23EB3CUA1iPmgnVkqFR+CzazNSlJD63f8NTU1uATpiO6G9ovlBs97+wvPsz/Ldf/dA4LCdQgFNo pxzH4VAvRwy9o5HX/Fb8nAaPJRUI7gaA== X-Google-Smtp-Source: AGHT+IEqajP6+u4eTxzUYHfF6PVb972s/3Qa3UlhPbS0/TAJuALl6ObT5PUNXanFEPyHtJ8XnDuE7g== X-Received: by 2002:a17:903:234c:b0:299:e041:ecf6 with SMTP id d9443c01a7336-29ec27ce2b4mr43176775ad.40.1765412974654; Wed, 10 Dec 2025 16:29:34 -0800 (PST) Received: from [100.64.0.1] ([167.103.29.104]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c0c2b8e0fb4sm539653a12.25.2025.12.10.16.29.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Dec 2025 16:29:34 -0800 (PST) Message-ID: <818ba76e-0553-459d-b956-520f23762034@sifive.com> Date: Thu, 11 Dec 2025 09:29:28 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 07/22] checkpatch: Warn on page table access without accessors To: "David Hildenbrand (Red Hat)" , Joe Perches , Palmer Dabbelt , Paul Walmsley , linux-riscv@lists.infradead.org, Andrew Morton , linux-mm@kvack.org Cc: devicetree@vger.kernel.org, Suren Baghdasaryan , linux-kernel@vger.kernel.org, Mike Rapoport , Michal Hocko , Conor Dooley , Lorenzo Stoakes , Krzysztof Kozlowski , Alexandre Ghiti , Emil Renner Berthing , Rob Herring , Vlastimil Babka , "Liam R . Howlett" , Andy Whitcroft , Dwaipayan Ray , Lukas Bulwahn References: <20251113014656.2605447-1-samuel.holland@sifive.com> <20251113014656.2605447-8-samuel.holland@sifive.com> <1dfa1e3566cafbe43a1d4753defef9c82ddb3b64.camel@perches.com> <273b638e-8251-4faf-929a-87432a48abdc@kernel.org> From: Samuel Holland Content-Language: en-US In-Reply-To: <273b638e-8251-4faf-929a-87432a48abdc@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2025-11-14 4:17 AM, David Hildenbrand (Red Hat) wrote: > On 13.11.25 03:36, Samuel Holland wrote: >> On 2025-11-12 8:21 PM, Joe Perches wrote: >>> On Wed, 2025-11-12 at 17:45 -0800, Samuel Holland wrote: >>>> Architectures may have special rules for accessing the hardware page >>>> tables (for example, atomicity/ordering requirements), so the generic MM >>>> code provides the pXXp_get() and set_pXX() hooks for architectures to >>>> implement. These accessor functions are often omitted where a raw >>>> pointer dereference is believed to be safe (i.e. race-free). However, >>>> RISC-V needs to use these hooks to rewrite the page table values at >>>> read/write time on some platforms. A raw pointer dereference will no >>>> longer produce the correct value on those platforms, so the generic code >>>> must always use the accessor functions. >>> [] >>>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl >>> [] >>>> @@ -7721,6 +7721,13 @@ sub process { >>>>                   ERROR("MISSING_SENTINEL", "missing sentinel in ID >>>> array\n" . "$here\n$stat\n"); >>>>               } >>>>           } >>>> + >>>> +# check for raw dereferences of hardware page table pointers >>>> +        if ($realfile !~ m@^arch/@ && >>>> +            $line =~ /(?))? >>>> (pte|p[mu4g]d)p?\b/) { >>>> +            WARN("PAGE_TABLE_ACCESSORS", >>>> +                 "Use $3p_get()/set_$3() instead of dereferencing page >>>> table pointers\n" . $herecurr); >>>> +        } >>>>       } >>> >>> Seems like a lot of matches >>> >>> $ git grep -P '(?))?(pte| >>> p[mu4g]d)p?\b' | \ >>>    grep -v '^arch/' | wc -l >>> 766 > > That is indeed concerning. > > I recall that we discussed an alternative approach with Ryan in the past: I > don't remember all the details, but essentially it was about using separate > types, such that dereferencing would not get you the type the other functions > would be expecting. Such that the compiler will bark when you try to dereference. Even if some functions a new incompatible pointer type, don't we still have the problem that neither type would be safe to dereference? A similar option to a new type would be to add a sparse annotation to the pointers that reference hardware page tables, similar to __user. I have prototyped a coccinelle script to add this annotation, and the sparse checking works. But I don't have the coccinelle expertise to automate the whole thing, so there's a lot of manual cleanup required. And this requires touching all architectures at once to avoid introducing erroneous sparse warnings. So I did not include this for v3 because it is quite a lot of churn. Is this something I should try to fully implement for v4? Regards, Samuel