Messages in this thread | | | Date | Sun, 5 Mar 2000 14:15:19 +0200 (EET) | From | Julian Anastasov <> | Subject | Re: accept() improvements for rt signals |
| |
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/
| |