This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bump microblaze minimum kernel requirement to 3.15?



On 18/11/2017 14:18, Florian Weimer wrote:
> Earlier kernels do not provide preadv and pwritev, and our emulation is severely broken; see bug 22442.

I think you mean BZ#22457 (Generic preadv/pwritev incorrectly calls __posix_memalign)
and related to this issue I think the generic preadv/pwritev incorrectly calls
'free' instead.  It requires a posix_memalign that align to page size and an
interposed malloc might not correctly provide it, so I think it would be safer
to call internal implementation. 

Also the fix is quite straightforward: since glibc already defines __libc_free
with libc_hidden_def, it is a matter of exporting the libc_hidden_def on
include/malloc.h and use it on preadv/pwritev. Another option would be to use
mmap/munmap directly, which seems more reasonable since  minimum alignment
required (I don't think it requires to be cancel-safe since pread/pwritev
itself is already a cancellation point). I will prepare a patch.

> 
> I'd like to simply bump the kernel version requirement for microblaze instead of trying to fix the fallback code (probably using mmap, but it will still not be cancel-safe).
> 
> Another alternative would be to rip out the emulation code completely and change the system call wrappers to return ENOSYS if the system call is not defined.
> 

Although we already impose different kernel version for different archs,
I would like to avoid it and aim for baseline one for all architecture
unless it is not really possible either by a primitive that is required
for a key API or if the minimum ABI for the architecture/abi requires
a minimum kernel different than the baseline.

My main problem is the minimum kernel version to get rid of wrappers
for microblaze is to raise the bar and being quite different than rest
of other architectures. We could apply same idea for 
__ASSUME_SET_ROBUST_LIST and raise the minimum kernel for the 
architecture/chips that do not support the futex primitive for robust
mutexes.  But I think it will cap glibc usage on scenarios where it
still works robustly.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]