Messages in this thread | | | From | Christophe Leroy <> | Subject | Re: [PATCH v2 1/2] powerpc/set_memory: Avoid spinlock recursion in change_page_attr() | Date | Thu, 23 Dec 2021 15:14:20 +0000 |
| |
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
| |