Message ID | 1532526312-26993-1-git-send-email-will.deacon@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | Don't use SIGMINSTKSZ when enforcing alternative signal stack size for compat tasks | expand |
On 2018-07-25 14:45, Will Deacon wrote: > Hi all, > > The Debian folks have observed a failure in the 32-bit arm glibc testsuite > when running under a 64-bit kernel. They tracked this down to sigaltstack(2) > enforcing the alternative signal stack to be at least SIGMINSTKSZ bytes, > which is higher for native arm64 tasks than compat 32-bit tasks. > > These patches resolve the issue by allowing an architecture to define > COMPAT_SIGMINSTKSZ for compat tasks, which is then used by the sigaltstack > checking code. > > Feedback welcome, > > Will > > --->8 > > Will Deacon (2): > signal: Introduce COMPAT_SIGMINSTKSZ for use in compat_sys_sigaltstack > arm64: compat: Provide definition for COMPAT_SIGMINSTKSZ Only the first patch went to the stable kernels. The second one is missing, so the bug is still not fixed in those kernels. Would it be possible to also get it included? Thanks, Aurelien
On Mon, Jul 29, 2019 at 10:23:02PM +0200, Aurelien Jarno wrote: > On 2018-07-25 14:45, Will Deacon wrote: > > Hi all, > > > > The Debian folks have observed a failure in the 32-bit arm glibc testsuite > > when running under a 64-bit kernel. They tracked this down to sigaltstack(2) > > enforcing the alternative signal stack to be at least SIGMINSTKSZ bytes, > > which is higher for native arm64 tasks than compat 32-bit tasks. > > > > These patches resolve the issue by allowing an architecture to define > > COMPAT_SIGMINSTKSZ for compat tasks, which is then used by the sigaltstack > > checking code. > > > > Feedback welcome, > > > > Will > > > > --->8 > > > > Will Deacon (2): > > signal: Introduce COMPAT_SIGMINSTKSZ for use in compat_sys_sigaltstack > > arm64: compat: Provide definition for COMPAT_SIGMINSTKSZ > > Only the first patch went to the stable kernels. The second one is > missing, so the bug is still not fixed in those kernels. Would it be > possible to also get it included? Damn, you're right. I think the autosel bot picked the first commit but not the second. In hindsight, we should've tagged them both, but oh well. I've posted the patch here for -stable, with you on cc: https://lore.kernel.org/lkml/20190730092547.1284-1-will@kernel.org/T/#u Will