lkml.org 
[lkml]   [2021]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 1/2] powerpc/set_memory: Avoid spinlock recursion in change_page_attr()
Date


Le 23/12/2021 à 13:09, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")
>> included a spin_lock() to change_page_attr() in order to
>> safely perform the three step operations. But then
>> commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*() against
>> concurrent accesses") modify it to use pte_update() and do
>> the operation atomically.
>
> It's not really atomic, it's just safe against concurrent access.
>
> We still do a read / modify / write of the pte value.
>
> Which isn't safe against concurrent calls to change_page_attr() for the
> same address.
>
> But maybe that's OK? AFAICS other architectures (eg. arm64) have no
> protection against concurrent callers. I think the assumption is higher
> level code is ensuring there's only a single caller at a time.
>
> On the other hand x86 and s390 do have locking (cpa_lock / cpa_mutex).
> But it seems that's mostly to protect against splitting of page tables,
> which we aren't doing.
>
> We'd be a bit safer if we used pte_update() "properly", like I did in:
>
> https://lore.kernel.org/linuxppc-dev/20210817132552.3375738-1-mpe@ellerman.id.au/
>
>

Probably not so simple as that patch, but I get the idea.

See b6cb20fdc273 ("powerpc/book3e: Fix set_memory_x() and set_memory_nx()")

I think we then need to define platform specific helpers to do it,
similar to ptep_set_wrprotect() and avoid an #ifdefery in change_page_attr()

Christophe
\
 
 \ /
  Last update: 2021-12-23 16:15    [W:0.128 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site