This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] misc: Set generic pselect as ENOSYS
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: <libc-alpha at sourceware dot org>, Lukasz Majewski <lukma at denx dot de>
- Date: Thu, 14 Nov 2019 20:49:57 +0000
- Subject: Re: [PATCH 1/2] misc: Set generic pselect as ENOSYS
- Ironport-sdr: zjyN2rz0ld+qqRch9pD+5JvrPzKAblO408JA6K8rSP+UKUutgeB3ljgEFTqXAJObEF76sXIi9Y 6nK1DM4PmOHXnzRvu7OaoAqfck3oLid/5XZCS2h2UaacTmHxjmEqD2R/pmCBAhD/hW7oehxpgZ YrX8romla3NZpkouUCeLtEjBHPTS33zRAd5yGhO+Bbdb3/xfiwsjq1kp5AqN4rqobAXCl8bOfL fP+kZpGCFfmxKjoEgmMEiFmfPbVlXs/tAx4ngrvYLF+Oorxd/TWdIRV3s4xyo9XLHJRgMFCLu+ q+8=
- Ironport-sdr: rxWy5Js1/lw7XRNXXV2Zp/02SfyJXlZ8WUuxmLl1a4T22IXIhWKpOnyl8rBUaG5rLI2QrZ9Xy8 SOC28kwtp+nLsNBiRkNK8vHlT+WNl+s3ufUiqnjnQKdvHLMw2zneFw03bBltIimzrjmI8vi463 0LbfVZGxuWeEM0HksRDeK+ki3ElbmmjEpJn4whqgvfq4/AikHIzVUqBSaBV4F9dMvaftxbOxkG oa5lAPU+b7O5mBgE7w62lo9DyLuOSQj7UzfsmrN/gxaTIdlH/dDj76yBC8Vp+p9K65yWwtG7oR j1s=
- References: <20191114185059.6403-1-adhemerval.zanella@linaro.org>
On Thu, 14 Nov 2019, Adhemerval Zanella wrote:
> The generic pselect implementation has the very specific race condition
> that motived the creation of the pselect syscall (no atomicity in
> signal mask set/reset). Using it as generic implementation is
> counterproductive Also currently only microblaze uses it as fallback
> when used on kernel prior 3.15.
>
> This patch moves the generic implementation to a microblaze specific
> one, sets the generic internal as a ENOSYS, and cleanups the Linux
> generic implementation.
>
> Also, the microblaze generic implementation first try to issue
> pselect instead of use the fallback (since it is expect that if
> the microblaze usage does rely on pselect, a sufficient updated
> kernel will be used). Microblaze defines __NR_pselect6 for Linux
> v3.2, although it was only wire-up on v3.15 (and the syscall number
> is the same as previous defined).
I'll raise the same issue here I raise whenever someone proposes having
fallback code for old kernels without a corresponding __ASSUME_* macro.
We need a simple and uniform way, when increasing the minimum kernel
version, to find all the fallback code that can be removed. That means
__ASSUME_* macros in kernel-features.h based on __LINUX_KERNEL_VERSION.
A free-form text comment mentioning "3.15" is no good for that purpose as
there is no sensible automated way to find all such comments when
increasing the minimum from 3.2 to 4.4 (for example, as the next such
increase that seems to make sense in terms of the cleanups it enables).
--
Joseph S. Myers
joseph@codesourcery.com