On Wed, 2015-06-24 at 19:44 +0530, ratheesh kannoth wrote:
> On Wed, Jun 24, 2015 at 6:16 PM, Eric Dumazet wrote:
> > You misunderstood the comment.
> >
> > Comment only stated that sock_hold() must be used in contexts where
> > caller owns a reference (and will eventually release it later with
>
On Wed, Jun 24, 2015 at 6:16 PM, Eric Dumazet wrote:
> You misunderstood the comment.
>
> Comment only stated that sock_hold() must be used in contexts where
> caller owns a reference (and will eventually release it later with
> sock_put().
>
> There is nothing about having a lock here.
Thanks. I
nd the lookup is made under lock preventing hash table
> 564modifications.
> 565 */
>
>
> But i could see instances of sock hold() in kernel without any locks.
>
>
> How the race between sock_hold() and sock_put() is prevented in smp ?
>
> note
could see instances of sock hold() in kernel without any locks.
How the race between sock_hold() and sock_put() is prevented in smp ?
note: I would like to use sock_hold() and sock_put() in
netdev_notifier chain call back functions.
-Ratheesh
--
To unsubscribe from this list: send the line
