[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [PATCH] Fix queued SIGIO
From:       Julian Anastasov <ja () ssi ! bg>
Date:       2000-09-20 19:20:57
[Download RAW message or body]


	Hello,

On Wed, 20 Sep 2000, Robert H. de Vries wrote:

> >	This is not needed for SI_SIGIO. It is not generated from
> >the kernel. It seems this interface is already obsoleted.
>
> I think you are mistaking. The purpose of SIGIO is to notify user programs of
> IO events detected by the kernel. So its use is almost exclusively in the
> kernel.

	Not in 2.4-test. You have to show me the right place
in the sources :)

	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.

> The reason it currently breaks is that when send_sig_info is used with real
> info data the check SI_FROMUSER evaluates to true.
> Other calls use a pointer to address 1 (ugh!) to inform bad_signal() that
> this signal is generated by the kernel.

	If your are talking about 2.2, of course it is broken but I'm
not sure if this bug can be fixed without breaking the binary
compatibility.

	But what about this ugly fix for 2.2:

#define	SI_KERN_SIGIO    (0x200+SI_SIGIO)	/* select better value */

fs/fcntl.c:send_sigio() to send SI_KERN_SIGIO (instead of SI_SIGIO) and
send_sig_info() to change it to SI_SIGIO after the EPERM check:

/* Send SI_SIGIO to user space */
if (info->si_code == SI_KERN_SIGIO) info->si_code = SI_SIGIO;

The FROMUSER check is already performed from sys_rt_sigqueueinfo()
before send_sig_info(). The other users of send_sig_info() always
use info == 0 or 1. So, this allows the PERM check to be bypassed for
the SI_SIGIO sent from the kernel.

	If there are other such codes that we must rewrite before
sending them to the user space we can group them using something
like this (0x100..0x1FF, SI_KERNEL=0x80 is not in this group, so > 0x100):

if (info->si_code - 0x0100 >= 0) info->si_code -= 0x200;

si_code is int

No changes in the user space. The main goal: to bypass the EPERM
check for SI_SIGIO sent from the kernel. Can such fix solve the
problem?


> 	Robert
>
> --
> Robert de Vries
> rhdv@rhdv.cistron.nl


Regards

--
Julian Anastasov <ja@ssi.bg>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[prev in list] [next in list] [prev in thread] [next in thread]