Re: [PATCH v2 1/8] x86: vdso: Introduce asm/vdso/mman.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 25/09/2024 22:23, Arnd Bergmann wrote:
> On Wed, Sep 25, 2024, at 06:51, Christophe Leroy wrote:
>> Le 23/09/2024 à 16:19, Vincenzo Frascino a écrit :
>>> @@ -0,0 +1,15 @@
...

>>
>> I still can't see the point with that change.
>>
>> Today 4 architectures implement getrandom and none of them require that 
>> indirection. Please leave prot and flags as they are in the code.
>>
>> Then this file is totally pointless, VDSO code can include 
>> uapi/linux/mman.h directly.
>>
>> VDSO is userland code, it should be safe to include any UAPI file there.
> 
> I think we are hitting an unfortunate corner case in the build
> system here, based on the way we handle the uapi/ file namespace
> in the kernel:
> 
> include/uapi/linux/mman.h includes three headers: asm/mman.h,
> asm-generic/hugetlb_encode.h and linux/types.h. Two of these
> exist in both include/uapi/ and include/, so while building
> kernel code we end up picking up the non-uapi version which
> on some architectures includes many other headers.
> 
> I agree that moving the contents out of uapi/ into vdso/ namespace
> is not a solution here because that removes the contents from
> the installed user headers, but we still need to do something
> to solve the issue.
>
> The easiest workaround I see for this particular file is to
> move the contents of arch/{arm,arm64,parisc,powerpc,sparc,x86}/\
> include/asm/mman.h into a different file to ensure that the
> only existing file is the uapi/ one. Unfortunately this does
> not help to avoid it regressing again in the future.
> 
> To go a little step further I would also move
> uapi/asm-generic/hugetlb_encode.h to uapi/linux/hugetlb_encode.h
> or merge it into uapi/linux/mman.h. This file has no business
> in asm-generic/* since there is only one copy.
> 
> After looking at this file for way too long, I somehow
> ended up with a (completely unrelated) cleanup series that
> I now posted at
> https://lore.kernel.org/lkml/20240925210615.2572360-1-arnd@xxxxxxxxxx/T/#t
>

I had a look at your proposal and it seems definitely better then mine. Thanks
Arnd. I am happy to drop my changes and re-post only a small series with
PAGE_SIZE/MASK required rework.

>      Arnd

-- 
Regards,
Vincenzo




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux