Hello,
The attached is a fix against 2.2.17 for the
spurious SIGIO signal returned from send_sigio() depending
on the "current" process permissions. No changes for the
applications, no changes in the si_code values.
The change allows the EPERM check to be skipped for
si_code==SI_SIGIO sent from the kernel. The calls to
send_sig_info from arch/<arch>/kernel/signal.c can be
changed to the new function send_sig_info_nocheck(), for
performance reasons, i.e. the requeue of the signal can't
return EINVAL or EPERM - "current" always passes the EPERM
check in send_sig_info (current->uid==t->uid when
t==current).
I can boot with this patch but the maintainers have
to check it and whether the arch/*/kernel/signal.c can
switch to the new _nocheck() function to save some CPU
cycles.
On Thu, 21 Sep 2000, Jamie Lokier wrote:
> Julian Anastasov wrote:
> > I'm talking about test8. __SI_CODE is in 2.4, not in 2.2.
> > The handling is very different. We can't wait for si_code==SI_SIGIO
> > in 2.4 anymore. SI_SIGIO is used only in 2.2:fs/fcntl.c. 2.4 stores
> > POLL_xxx in si_code instead of SI_SIGIO.
>
> Why does it do that? si_band already stores the POLL_xxx code.
si_band=POLLxxx not POLL_xxx :) Not sure, may be
(1) the 2.4 binaries will be surprised in 2.2 or (2) The
Single UNIX Specification, Version 2
> -- Jamie
Regards
-- Julian Anastasov <ja@ssi.bg>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:27 EST