Re: [netmp] socket accesses

[Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>]

On Monday 18 August 2008, Matthew Dillon wrote:
> :I'm not sure what the protocol thread would have to do in this case. Isn't it
> :enough to just have it set the relevant flag in response to the message?
> :
> :Aggelos
> 
>     I greped through all the uses of SS_CANTRCVMORE.  Nearly all uses
>     are on the user side and not on the protocol side.  In fact, the
>     only protocol-side use, other then setting the flag and waking up
>     any blocked readers, is in the TCP stack where it looks like it
>     simply uses the flag to determine whether to append new mbufs onto
>     the sockbuf or to simply free them.
> 
>     It looks to me that the user side can just set the flag w/ an atomic
>     instruction.

Quoting myself:
> Turning to SS_CANTRCVMORE, tcp_input() references it in two ways:
>
> if (so->so_state & SS_CANTRCVMORE) {
>         m_freem(m);
> } else {
>         m_adj(m, drop_hdrlen); /* delayed header drop */
>         ssb_appendstream(&so->so_rcv, m);
> }

So, atomic or non-atomic op, if we race here, the mbufs can stay in the sockbuf
for ever...

> and
>
> if (so->so_state & SS_CANTRCVMORE) {
>         soisdisconnected(so);
>         callout_reset(tp->tt_2msl, tcp_maxidle,
>                       tcp_timer_2msl, tp);
> }

And if we race here, we'll never disconnect the socket.

>     Another alternative is to create a user-side flag set and a protocol-side
>     flag set, so userland can set flags without using atomic instructions,
>     and the protocol side would check both flags (A|B).  That seems more
>     complex though.

I'm not sure how that helps in the case above.

Aggelos