[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1280155406.2899.407.camel@edumazet-laptop>
Date: Mon, 26 Jul 2010 16:43:26 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Neshama Parhoti <pneshama@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: lock_sock or sock_hold ?
Le lundi 26 juillet 2010 à 17:00 +0300, Neshama Parhoti a écrit :
> hello everyone,
>
> can you please be kind and help me understand the differences between
> lock_sock and sock_hold ?
>
> i can see that lock_sock takes a spin lock (bh) to mark owned = 1, and
> then takes a mutex, whereas sock_hold only increases the atomic
> refcnt.
>
> but how do i know which of them I should use ?
>
> i'm puzzled as to when should those two different APIs be used..
sock_hold() only increments a refcount, so that you are sure nobody can
destroy the socket (and its memory) under you. But you cannot modify
socket state only with this refcount taken.
To get exclusive access to the socket you either :
1) Are in process context and use lock_sock().
2) Are in softirq context (input path for example) :
2.1) Lookup the socket in protocol hash tables, and get a refcount on
it (by sock_hold() or other atomic operation on refcnt)
2.2) Then, get semi exclusive access using bh_lock_sock()
2.3) Check if another process already is using the socket (we
interrupted this process on same CPU, or run on another cpu)
if (sock_owned_by_user(sk)) {
// queue work to socket backlog (delayed work)
} else {
// process packet right now
}
--
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