Re: [Xen-devel] [PATCH v2 1/3] x86/mm: mod_l<N>_entry() have no need to use __copy_from_user()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.01.2020 17:09, Andrew Cooper wrote:
> On 06/01/2020 15:34, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/page.h
>> +++ b/xen/include/asm-x86/page.h
>> @@ -55,6 +55,16 @@
>>  #define l4e_write(l4ep, l4e) \
>>      pte_write(&l4e_get_intpte(*(l4ep)), l4e_get_intpte(l4e))
>>  
>> +/* Type-correct ACCESS_ONCE() wrappers for PTE accesses. */
>> +#define l1e_access_once(l1e) 
>> (*container_of(&ACCESS_ONCE(l1e_get_intpte(l1e)), \
>> +                                            volatile l1_pgentry_t, l1))
>> +#define l2e_access_once(l2e) 
>> (*container_of(&ACCESS_ONCE(l2e_get_intpte(l2e)), \
>> +                                            volatile l2_pgentry_t, l2))
>> +#define l3e_access_once(l3e) 
>> (*container_of(&ACCESS_ONCE(l3e_get_intpte(l3e)), \
>> +                                            volatile l3_pgentry_t, l3))
>> +#define l4e_access_once(l4e) 
>> (*container_of(&ACCESS_ONCE(l4e_get_intpte(l4e)), \
>> +                                            volatile l4_pgentry_t, l4))
> 
> What's wrong with l?e_read_atomic() which already exist, and are already
> used elsewhere?

I did consider going that route, but predicted you would object to its
use here: Iirc you've previously voiced opinion in this direction
(perhaps not on the page table accessors themselves but the underlying
{read,write}_u<N>_atomic()).

> If nothing, then Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> to save another round of posting.

Let's get the above clarified - I'll be happy to switch to
l<N>e_read_atomic() if that's fine by you.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel