linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).