Hello,
On Sun, 5 Mar 2000, Alessandro Sala wrote:
> Hello,
>
> Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Tue, 22 Feb 2000, Stephen C. Tweedie wrote:
> >
> > > Hi,
> > >
> > > On Tue, 22 Feb 2000 17:38:45 +0200 (EET), Julian Anastasov
> > > <uli@linux.tu-varna.acad.bg> said:
> > >
> > > > Is there a known problem with O_NONBLOCK|O_ASYNC listening
> > > > sockets (2.2.15pre7 UP) ? I receive unexpected SIGIO after accept()
> > > > using such listening socket.
> > >
> >
> > After adding some debugging in the kernel I found that
> > send_sig_info() returns EPERM and send_sigio() fallbacks to
> > SIGIO delivery using "send_sig(SIGIO, p, 1);". I have stopped to
> > search the exact values used in the EPERM checking because I found
> > this posting from Alessandro Sala <a.sala@mclink.it> on 06-DEC-1999
> > with the subject:
> > "PROBLEM: Asynchronous I/O with realtime signals erroneously sends SIGIO".
> >
> > http://kernelnotes.org/lnxlists/linux-kernel/lk_9912_01/msg01206.html
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=94451812209885&w=2
> >
> > The problem is described very well and I think I have
> > the same one. send_sigio() must pass the perm checking in
> > send_sig_info(). I didn't checked the corresponding 2.3 code. This
>
> I checked 2.3.34 and it seems the problem is still there: the perm
> checking code in send_sig_info() is the same as 2.2.x, SI_SIGIO still
> has a negative value, and the macro SI_FROMUSER(siptr) is still
> defined as (siptr)->si_code <= 0.
I don't know when si_band field is ported in 2.3 but I'm using
2.3.47+ where SI_SIGIO is already not generated. Now POLL_xxx events are
generated instead. There is no problem with si_code < 0 in 2.3.
I consider rt mechanism in 2.2.x (x<15) as unusable because:
- we don't receive the event type/mask
- sometimes SI_SIGIO can't pass the permission checks (EPERM), this is a
2.2 bug, as you found it.
I backported si_code/si_band patch from 2.3 in 2.2.15 and now I'm
happy. Now si_code contains POLL_xxx and there is no problem with the
unexpected SIGIOs.
>
> If you need to use realtime signals with F_SETSIG, I suggest you
> apply the workaround I suggested in my posting: replace
> the definition of SI_FROMUSER in asm-i386/siginfo.h with
>
> #define SI_FROMUSER(siptr) ((siptr)->si_code <= 0 && \
> (siptr)->si_code >= SI_QUEUE)
>
> I'am using this and I've had no problems so far, but I realize
> it's only a workaround: I'd like someone commented about my proposed
> solution: changing the definition of SI_SIGIO, SI_ASYNCIO, SI_MESGQ
> and SI_TIMER to positive values. I think this would solve the problem
> and would make the realtime signals more compliant with The Single Unix
> specification.
You can check all problems You found in 2.3 too. For 2.2 may be
nobody wants to modify this behavior - the "applications" could be broken.
In 2.3 you have to check si_code for POLL_xxx instead for SI_SIGIO.
si_band is useless as the events are not merged and the info in si_code
is enough.
May be it is time the problems, if any, to be fixed in 2.3.
May be sys_rt_sigqueueinfo really need to be fixed, current->uid/pid can
be used to replace the user provided si_uid/pid.
I don't see SI_MESGQ, SI_TIMER and already SI_SIGIO to be
generated from the kernel (2.3.49). But SI_ASYNCIO is generated which is a
bug if SI_ASYNCIO < 0 and if it is generated not from user space. Any
SI_xxx < 0 generated from the kernel must be corrected. But may be these
codes are still not used.
So, the only correction which is needed for now is in
sys_rt_sigqueueinfo. Are the other codes generated not from user space?
Or they are still not implemented.
Regards
-- Julian Anastasov <uli@linux.tu-varna.acad.bg>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:18 EST