Alan Cox wrote:
>
> > Nope, I think that tulip has nothing to do with that.
> > Try patch at the end of this letter, it definitely should help you.
>
> It should make absolutely no odds.
>
> > ALAN: What do you think about backporting of locking on Fasync_list
> > from 2.3 to 2.2, is that needed?
>
> That actually looks like what is needed
>
> > + if(sock->fasync_list != NULL)
> > + kill_fasync(sock->fasync_list, SIGIO);
>
> The kill_fasync code starts
>
> while(fa)
>
> so it checks this. For that oops trace to be right it would imply someone
> zapped the list. The list is only changed by fasync_helper. That locks the
> list when doing the two critical updates for adding/removing an entry and
> seems to have a small race. I find it hard to believe this is what is going
> on but unless I am missing something
>
> save_flags(flags);
> cli();
> *fp = fa->fa_next;
> restore_flags(flags);
> kfree(fa);
> return 1;
>
> is safe even SMP since the cli/restore_flags means that we cannot be part
> way down a queue walk when the entry is freed.
>
I didn't check the code, but save_flags()+cli() is rarely SMP safe:
if you call cli() with disable local interrupts, then cli() is a nop.
-- Manfred- 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 : Wed Feb 23 2000 - 21:00:24 EST