From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
npiggin@gmail.com, aneesh.kumar@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH v1 00/17] ban the use of _PAGE_XXX flags outside platform specific code
Date: Wed, 5 Sep 2018 19:33:33 +0530 [thread overview]
Message-ID: <95ee30b8-70b5-0f74-b677-417d3b0ca19e@linux.ibm.com> (raw)
In-Reply-To: <cover.1535913369.git.christophe.leroy@c-s.fr>
On 09/05/2018 06:06 PM, Christophe Leroy wrote:
> Today flags like for instance _PAGE_RW or _PAGE_USER are used through
> common parts of code.
> Using those directly in common parts of code have proven to lead to
> mistakes or misbehaviour, because their use is not always as trivial
> as one could think.
>
> For instance, (flags & _PAGE_USER) == 0 isn't enough to tell
> that a page is a kernel page, because some targets are using
> _PAGE_PRIVILEDGED and not _PAGE_USER, so the test has to be
> (flags & (_PAGE_USER | _PAGE_PRIVILEDGED)) == _PAGE_PRIVILEDGED
> This has to (bad) consequences:
>
> - All targets must define every bit, even the unsupported ones,
> leading to a lot of useless #define _PAGE_XXX 0
> - If someone forgets to take into account all possible _PAGE_XXX bits
> for the case, we can get unexpected behaviour on some targets.
>
> This becomes even more complex when we come to using _PAGE_RW.
> Testing (flags & _PAGE_RW) is not enough to test whether a page
> if writable or not, because:
>
> - Some targets have _PAGE_RO instead, which has to be unset to tell
> a page is writable
> - Some targets have _PAGE_R and _PAGE_W, in which case
> _PAGE_RW = _PAGE_R | _PAGE_W
> - Even knowing whether a page is readable is not always trivial because:
> - Some targets requires to check that _PAGE_R is set to ensure page
> is readable
> - Some targets requires to check that _PAGE_NA is not set
> - Some targets requires to check that _PAGE_RO or _PAGE_RW is set
>
> Etc ....
>
> In order to work around all those issues and minimise the risks of errors,
> this serie aims at removing all use of _PAGE_XXX flags from powerpc code
> and always use pte_xxx() and pte_mkxxx() accessors instead. Those accessors
> are then defined in target specific parts of the kernel code.
We recently did on book3s 64.
static inline int pte_present(pte_t pte)
{
/*
* A pte is considerent present if _PAGE_PRESENT is set.
* We also need to consider the pte present which is marked
* invalid during ptep_set_access_flags. Hence we look for _PAGE_INVALID
* if we find _PAGE_PRESENT cleared.
*/
return !!(pte_raw(pte) & cpu_to_be64(_PAGE_PRESENT | _PAGE_INVALID));
}
So I guess with that pte_present conversion we need to be careful.
Do you have a git tree which I can use to double check?
-aneesh
next prev parent reply other threads:[~2018-09-05 14:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 12:36 [RFC PATCH v1 00/17] ban the use of _PAGE_XXX flags outside platform specific code Christophe Leroy
2018-09-05 12:36 ` [RFC PATCH v1 01/17] powerpc/32: Add ioremap_wt() Christophe Leroy
2018-09-05 12:36 ` [RFC PATCH v1 02/17] powerpc/mm: remove direct use of flags related to cache Christophe Leroy
2018-09-05 12:36 ` [RFC PATCH v1 03/17] powerpc/mm: dont't use _PAGE_EXEC in book3s/32 Christophe Leroy
2018-09-05 12:36 ` [RFC PATCH v1 04/17] powerpc/mm: move some nohash pte helpers in nohash/[32:64]/pgtable.h Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 05/17] powerpc/mm: add pte helpers to query and change pte flags Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 06/17] powerpc/mm: use pte helpers in generic code Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 07/17] powerpc/mm: Split dump_pagelinuxtables flag_array table Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 08/17] powerpc/mm: drop unused page flags Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 09/17] powerpc/mm: move __P and __S tables in the common pgtable.h Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 10/17] powerpc/book3s/32: do not include pte-common.h Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 11/17] powerpc/mm: Move pte_user() into nohash/pgtable.h Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 12/17] powerpc/mm: Distribute platform specific PAGE and PMD flags and definitions Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 13/17] powerpc/nohash/64: do not include pte-common.h Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 14/17] powerpc/mm: Allow platforms to redefine some helpers Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 15/17] powerpc/mm: Define platform default caches related flags Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 16/17] powerpc/mm: Get rid of pte-common.h Christophe Leroy
2018-09-05 12:37 ` [RFC PATCH v1 17/17] powerpc/8xx: change name of a few page flags to avoid confusion Christophe Leroy
2018-09-05 14:03 ` Aneesh Kumar K.V [this message]
2018-09-05 14:32 ` [RFC PATCH v1 00/17] ban the use of _PAGE_XXX flags outside platform specific code Christophe Leroy
2018-09-06 9:58 ` Aneesh Kumar K.V
2018-09-06 21:36 ` Christophe Leroy
2018-09-10 6:08 ` Aneesh Kumar K.V
2018-09-12 16:05 ` Christophe LEROY
2018-09-07 9:41 ` Christophe Leroy
2018-09-12 16:07 ` Christophe LEROY
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=95ee30b8-70b5-0f74-b677-417d3b0ca19e@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@c-s.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).