> See the comments below, I guess we don't need yet another lock :-)

Will look at some more about locks as time permits - we take
possession of our house today :-)
> > @@ -191,7 +192,7 @@ static int dccp_wait_for_ccid(struct soc
> >         while (1) {
> >                 prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE);
> >
> > -               if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))
> > +               if (sk->sk_err)
>
> Humm, have to check this one...

The reason for this is to allow sending of queued packets when user
application says close...

> sk_reset_timer() please, so that we make sure we have a reference count
> for the sock as its going to be on a timer

As I read the timer source code if the timer returns do I have to do a
sock_put (I am guessing so as I don't see how it would happen
elsewise).

> > +       dp->dccps_xmit_lock = SPIN_LOCK_UNLOCKED;
>
> Not needed

I presume you mean because that is the default state? (Provided I
don't get rid of the lock altogether)

> sk_stop_timer please, to drop the refcount we grabbed with sk_reset_timer()
> elsewhere.
>
The thing with sk_stop_timer is that it doesn't check if the timer
routine is in use which would mean that we can have problems (I hit
this in testing). I presume the best way is to create a
sk_stop_timer_sync rather than use generic timer...

Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to