From: Al Viro <viro@zeniv.linux.org.uk>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Denis Kirjanov <kda@linux-powerpc.org>,
Christoph Hellwig <hch@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper
Date: Sat, 20 Feb 2021 21:08:55 +0000 [thread overview]
Message-ID: <YDF6Z8QHh3yw7es9@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <CAM_iQpXX7SBGgUkBUY6BEjCqJYbHAUW5Z3VtV2U=yhiw1YJr=w@mail.gmail.com>
On Sat, Feb 20, 2021 at 12:31:49PM -0800, Cong Wang wrote:
> 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().
*shrug*
If anything, __unix_complete_bind() might make a better name for that,
with dropping ->bindlock also pulled in, but TBH I don't have sufficiently
strong preferences - might as well leave dropping the lock to caller.
I'll post that series to netdev tonight.
next prev parent reply other threads:[~2021-02-20 21:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 15:49 [PATCH] fs: export kern_path_locked Denis Kirjanov
2021-01-27 17:57 ` Christoph Hellwig
[not found] ` <CAOJe8K0MC-TCURE2Gpci1SLnLXCbUkE7q6SS0fznzBA+Pf-B8Q@mail.gmail.com>
[not found] ` <20210129082524.GA2282796@infradead.org>
[not found] ` <CAOJe8K0iG91tm8YBRmE_rdMMMbc4iRsMGYNxJk0p9vEedNHEkg@mail.gmail.com>
[not found] ` <20210129131855.GA2346744@infradead.org>
2021-02-14 18:17 ` Al Viro
2021-02-16 14:31 ` Denis Kirjanov
2021-02-16 18:00 ` Al Viro
2021-02-19 4:11 ` Al Viro
2021-02-19 4:19 ` [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper Al Viro
2021-02-20 19:12 ` Cong Wang
2021-02-20 19:32 ` Al Viro
2021-02-20 20:31 ` Cong Wang
2021-02-20 21:08 ` Al Viro [this message]
2021-02-22 19:06 ` [PATCHSET] making unix_bind() undo mknod on failure Al Viro
2021-02-22 19:12 ` [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper Al Viro
2021-02-22 19:12 ` [PATCH 2/8] unix_bind(): allocate addr earlier Al Viro
2021-02-22 19:12 ` [PATCH 3/8] unix_bind(): separate BSD and abstract cases Al Viro
2021-02-22 19:12 ` [PATCH 4/8] unix_bind(): take BSD and abstract address cases into new helpers Al Viro
2021-02-22 19:12 ` [PATCH 5/8] fold unix_mknod() into unix_bind_bsd() Al Viro
2021-02-22 19:12 ` [PATCH 6/8] unix_bind_bsd(): move done_path_create() call after dealing with ->bindlock Al Viro
2021-02-22 19:12 ` [PATCH 7/8] unix_bind_bsd(): unlink if we fail after successful mknod Al Viro
2021-02-22 19:12 ` [PATCH 8/8] __unix_find_socket_byname(): don't pass hash and type separately Al Viro
2021-02-22 19:12 ` [PATCHSET] making unix_bind() undo mknod on failure Al Viro
2021-02-22 19:24 ` Al Viro
2021-02-24 0:40 ` Jakub Kicinski
2021-02-19 4:20 ` [PATCH 2/8] unix_bind(): allocate addr earlier Al Viro
2021-02-19 4:21 ` [PATCH 3/8] unix_bind(): separate BSD and abstract cases Al Viro
2021-02-19 4:21 ` [PATCH 4/8] unix_bind(): take BSD and abstract address cases into new helpers Al Viro
2021-02-19 4:22 ` [PATCH 5/8] fold unix_mknod() into unix_bind_bsd() Al Viro
2021-02-19 4:22 ` [PATCH 6/8] unix_bind_bsd(): move done_path_create() call after dealing with ->bindlock Al Viro
2021-02-19 4:23 ` [PATCH 7/8] unix_bind_bsd(): unlink if we fail after successful mknod Al Viro
2021-02-19 4:23 ` [PATCH 8/8] __unix_find_socket_byname(): don't pass hash and type separately Al Viro
2021-06-19 3:48 [PATCHSET] AF_UNIX bind(2) cleanup on failures after mknod Al Viro
2021-06-19 3:50 ` [PATCH 1/8] af_unix: take address assignment/hash insertion into a new helper Al Viro
2021-06-21 19:30 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YDF6Z8QHh3yw7es9@zeniv-ca.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=hch@infradead.org \
--cc=kda@linux-powerpc.org \
--cc=kuba@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.