linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Christophe LEROY <christophe.leroy@c-s.fr>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	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, 12 Sep 2018 18:07:57 +0200	[thread overview]
Message-ID: <fe0afb3c-8b6c-fff1-47ee-4fc25c0bc8a6@c-s.fr> (raw)
In-Reply-To: <8736uneylc.fsf@linux.ibm.com>



Le 06/09/2018 à 11:58, Aneesh Kumar K.V a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
> 
>> 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.
> 
> The series is really good. It also helps in code readability. Few things
> i am not sure there is a way to reduce the overhead
> 
> -		access = _PAGE_EXEC;
> +		access = pte_val(pte_mkexec(__pte(0)));
> 
> Considering we have multiple big endian to little endian coversion there
> for book3s 64.
> 
> Other thing is __ioremap_at where we do
> 
> +       pte_t pte = __pte(flags);
>   
>          /* Make sure we have the base flags */
> -       if ((flags & _PAGE_PRESENT) == 0)
> +       if (!pte_present(pte))
> 
> -               err = map_kernel_page(v+i, p+i, flags);
> +               err = map_kernel_page(v + i, p + i, pte_val(pte));
> 

Finally, for that I now ensure that all base flags are set by the 
callers and I have removed that hack which adds PAGE_KERNEL flags when 
_PAGE_PRESENT is not in the handedover flags.

> 
> But otherwise for the series.
> 
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> 

Thanks, I added it to all unchanged patches of the serie. You are 
welcome to give a feedback on the new ones if you have time.

Christophe

      parent reply	other threads:[~2018-09-12 16:08 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 ` [RFC PATCH v1 00/17] ban the use of _PAGE_XXX flags outside platform specific code Aneesh Kumar K.V
2018-09-05 14:32   ` 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 [this message]

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=fe0afb3c-8b6c-fff1-47ee-4fc25c0bc8a6@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --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).