Thread (28 messages) 28 messages, 4 authors, 2021-02-24

Re: [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper

From: Cong Wang <hidden>
Date: 2021-02-20 20:33:00
Also in: lkml

On Sat, Feb 20, 2021 at 11:32 AM Al Viro [off-list ref] wrote:
On Sat, Feb 20, 2021 at 11:12:33AM -0800, Cong Wang wrote:
quoted
On Thu, Feb 18, 2021 at 8:22 PM Al Viro [off-list ref] wrote:
quoted
Duplicated logics in all bind variants (autobind, bind-to-path,
bind-to-abstract) gets taken into a common helper.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
 net/unix/af_unix.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 41c3303c3357..179b4fe837e6 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -262,6 +262,16 @@ static void __unix_insert_socket(struct hlist_head *list, struct sock *sk)
        sk_add_node(sk, list);
 }

+static void __unix_set_addr(struct sock *sk, struct unix_address *addr,
+                           unsigned hash)
+       __releases(&unix_table_lock)
+{
+       __unix_remove_socket(sk);
+       smp_store_release(&unix_sk(sk)->addr, addr);
+       __unix_insert_socket(&unix_socket_table[hash], sk);
+       spin_unlock(&unix_table_lock);
Please take the unlock out, it is clearly an anti-pattern.
Why?  "Insert into locked and unlock" is fairly common...
Because it does not lock the lock, just compare:

lock();
__unix_set_addr();
unlock();

to:

lock();
__unix_set_addr();

Clearly the former is more readable and less error-prone. Even
if you really want to do unlock, pick a name which explicitly says
it, for example, __unix_set_addr_unlock().

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help