On Wed, Sep 04, 2019 at 11:37:36AM +0100, Cristian Marussi wrote:
On 04/09/2019 11:05, Dave Martin wrote:
On Fri, Aug 30, 2019 at 03:29:29PM +0100, Cristian Marussi wrote:
Hi
On 13/08/2019 17:25, Dave Martin wrote:
On Fri, Aug 02, 2019 at 06:02:55PM +0100, Cristian Marussi wrote:
[...]
diff --git a/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_magic.c b/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_magic.c
[...]
+static int fake_sigreturn_bad_magic_run(struct tdescr *td,
siginfo_t *si, ucontext_t *uc)+{
- size_t resv_sz, offset;
- struct _aarch64_ctx *shead = GET_SF_RESV_HEAD(sf), *head;
- /* just to fill the ucontext_t with something real */
- if (!get_current_context(td, &sf.uc))
return 1;- resv_sz = GET_SF_RESV_SIZE(sf);
- /*
* find the terminator, preserving existing headers* and verify amount of spare room in __reserved area.*/- head = get_terminator(shead, resv_sz, &offset);
- /*
* try stripping extra_context header when low on space:* we need at least 2*HDR_SZ space ... one for the KSFT_BAD_MAGIC* and the other for the usual terminator.*/- if (head && resv_sz - offset < HDR_SZ * 2) {
Can we factor out this logic for finding space in the signal frame?
We do pretty much the same thing in all the fake_sigreturn tests...
Ok
fprintf(stderr, "Low on space:%zd. Discarding extra_context.\n",resv_sz - offset);head = get_header(shead, EXTRA_MAGIC, resv_sz, &offset);- }
- /* just give up and timeout if still not enough space */
Do we actually time out? I don't see where we actually wait, so doesn't test_run() just fail immediately?
The same applies to all the other fake_sigreturn tests too.
Right. It is probably a leftover.
SIGALRM is used as an extreme measure to kill tests gone bad, but this can happen only once the fake sigframe has been effectively placed on the stack and sigreturned.
OK, so this gets reported as a test failure because with no SIGSEGV, nothing ever sets td->pass?
Yes exactly. End result is based on value on td->pass, in case of abrupt termination or timeout nobody sets td->pass ever.
This is probably OK for now, though I wonder whether this should be reported as a skipped test instead.
In case of doubt, reporting a failure is preferable anyway, since that will encourage people actually to investigate what went wrong.
As of now I never skip a test in fact...also tests for unsupported features are built and run expecting a SIGILL, and reported as PASS in that case.
OK, just wanted to check I'd understood correcly.
Cheers ---Dave