tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Problem with syscall_disestablish() - PR kern/50430



My understanding is that l_sysent is *always* overriden by syscalls
from within signal handlers, right?

It's not a question of "being overwritten".  The real situation is
that the _initial_ syscall returns first (with ERESTART), and l_sysent
is reset to NULL.  Then when the signal handler calls some other
syscall, there is nothing to lose.

Then, when the handler returns, the _original_ syscall is automatically
restarted.

As I said earlier, I have not identified the exact code where all of
this happens.  But empirical evidence (from printf()s inserted in
sy_call() both before and after the dispatch) shows that it works as
I've described.  There was never any non-NULL value in l_sysent at
the point where sy_call() stores a new value.  And the printf() I
had inserted after the syscall dispatch clearly showed a return value
of -3 == ERESTART.

If anyone wants to reconfirm my empirical results, I have attached my
test program here.

1. Apply the syscallvar.h.diff patch file
2. Build and boot a new kernel
3. Build the test program, and run it.

BTW, using qemu and anita is great for this sort of testing.  :)

And if there's anyone who really understands HOW the initial syscall
gets interrupted when the signal is being delivered (and HOW it gets
restarted when the handler returns) I would love an explanation!


+------------------+--------------------------+-------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+------------------+--------------------------+-------------------------+

Attachment: test.tgz
Description: Binary data



Home | Main Index | Thread Index | Old Index