Summary: | [x86] Cancelable syscall stubs fail to preserve 16-byte stack alignment | ||
---|---|---|---|
Product: | glibc | Reporter: | Andreas Schwab <schwab> |
Component: | libc | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | adhemerval.zanella, drepper.fsp, hjl.tools, rguenth |
Priority: | P2 | ||
Version: | 2.22 | ||
Target Milestone: | --- | ||
Host: | i?86-*-linux* | Target: | |
Build: | Last reconfirmed: |
Description
Andreas Schwab
2021-11-03 11:15:16 UTC
(In reply to Andreas Schwab from comment #0) > > This is dormant on master, since there are no longer any cancelable syscalls > that are implemented using the stubs. What do you mean by dormant on master? Under what conditions, will it come back? Whenever a cancelable syscall is implemented using this stub. (In reply to Andreas Schwab from comment #2) > Whenever a cancelable syscall is implemented using this stub. Where is this stub defined on master branch? Do you have a testcase? I tried diff --git a/nptl/cancellation.c b/nptl/cancellation.c index 2bd31686fd..ca0b14abc3 100644 --- a/nptl/cancellation.c +++ b/nptl/cancellation.c @@ -22,6 +22,14 @@ #include <futex-internal.h> +static void +check (void) +{ + char *sp = CURRENT_STACK_FRAME; + if ((((uintptr_t) sp) + sizeof (char *)) & (sizeof (char *) - 1)) + asm ("hlt"); +} + /* The next two functions are similar to pthread_setcanceltype() but more specialized for the use in the cancelable functions like write(). They do not need to check parameters etc. */ @@ -29,6 +37,7 @@ int attribute_hidden __pthread_enable_asynccancel (void) { + check (); struct pthread *self = THREAD_SELF; int oldval = THREAD_GETMEM (self, cancelhandling); on release/2.22/master branch. "hlt" was never triggered. Sorry, I missed that the arch-dependent <sysdep-cancel.h> no longer exists on master. (In reply to Andreas Schwab from comment #5) > Sorry, I missed that the arch-dependent <sysdep-cancel.h> no longer exists > on master. Cancellable entrypoints are implemented solely with C from now on. Is this really an issue? Yes, this issue has ceased to exist in 2.27. This problem only exists prior to 2.27, which is no longer maintained. |