[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1229529888.13305.57.camel@nathan.suse.cz>
Date: Wed, 17 Dec 2008 17:04:48 +0100
From: Petr Tesarik <ptesarik@...e.cz>
To: Alexey Kuznetsov <kuznet@....inr.ac.ru>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
Ilpo J??rvinen <ilpo.jarvinen@...sinki.fi>,
davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] tcp: make urg+gso work for real this time
Alexey Kuznetsov píše v St 17. 12. 2008 v 18:30 +0300:
> Hello!
>
> > Probably, netbsd/openbsd have some another quirk to work this around.
> > I do not see how, though.
>
> F.e. this could be totally safe if we do this only in the case
> when octet seq+0xFFFF has not yet been sent.
>
> When we send segment with 0xFFFF inside urg_ptr is advanced and so on,
> so that receiver has no chances to corrupt stream.
>
> I.e. we set URG and urg_ptr to fake scb->seq + 0xFFFF only when:
>
> after(scb->seq + 0xFFFF, tp->snd_nxt)
>
> My brains are rusty, so take this critically. :-)
This is all nice, but it still does not solve those series of SIGURGs on
the receiving side. My suggestion is to not generate a new SIGURG until
the data for the latest one have arrived. There can be only one byte of
urgent data, so if somebody sends more than one, it cannot be handled by
the receiver, anyway, so that use case is broken and need not be taken
into account.
Oh, and since SIGURG is not a real-time signal, there is no requirement
to send as many of them as there were urgent data. Of course, this does
not help other OSes, but I'm not sure how they behave in these
situations.
Petr
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists