From: Al Viro <viro@ZenIV.linux.org.uk>
To: Joe Perches <joe@perches.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 16/28] namespace: checkpatch wanking
Date: Wed, 30 Nov 2011 06:50:14 +0000 [thread overview]
Message-ID: <20111130065014.GU2203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1322624351.17214.5.camel@Joe-Laptop>
On Tue, Nov 29, 2011 at 07:39:11PM -0800, Joe Perches wrote:
> No worries.
>
> I think patches 1 thru 14 are reasonable though
> and do apply with a few offsets to vfsmount-guts.
OK... BTW, speaking of this one:
-static int mnt_id_start = 0;
+static int mnt_id_start;
static int mnt_group_start = 1;
this deserves a separate NAK; explicit init here is actually more clear -
the variable is more or less analogous to mnt_group_start and it's less
distracting to have initializers spelled out in similar way as well.
- if ((child_mnt = __lookup_mnt(path->mnt, path->dentry, 1)))
+ child_mnt = __lookup_mnt(path->mnt, path->dentry, 1);
+ if (child_mnt)
mntget(child_mnt);
br_read_unlock(&vfsmount_lock);
return child_mnt;
Maybe, maybe not; in the #vfsmount-guts I seriously pondered turning that
into
child_mnt = ...;
if (child_mnt) {
mnt_add_count(child_mnt);
br_read_unlock(...);
return &child_mnt->mnt;
} else {
br_read_unlock(...);
return NULL;
}
Hell knows... Since __lookup_mnt() returns struct mount now *and* lookup_mnt()
returns struct vfsmount (much shrunk subset of the original; almost nothing
in there is needed for anything outside of core VFS code) we need if or ?:
after unlock as well. So it might make sense to split the codepaths once...
- if (flags & MNT_FORCE && sb->s_op->umount_begin) {
+ if (flags & MNT_FORCE && sb->s_op->umount_begin)
sb->s_op->umount_begin(sb);
- }
Probably. It used to be just a method call, then it had grown lock/unlock
around it, then lock went down into the method instances and the compound
statement stayed.
-static int do_add_mount(struct vfsmount *newmnt, struct path *path, int mnt_flags)
+static int
+do_add_mount(struct vfsmount *newmnt, struct path *path, int mnt_flags)
I don't mind BSD style like that, but again, check #vfsmount-guts; this
one takes struct mount * now, so that line happens to be below 80 cols.
-static int select_submounts(struct vfsmount *parent, struct list_head *graveyard)
+static int
+select_submounts(struct vfsmount *parent, struct list_head *graveyard)
Ditto.
- struct vfsmount *mnt = list_entry(tmp, struct vfsmount, mnt_child);
+ struct vfsmount *mnt = list_entry(tmp, struct vfsmount,
+ mnt_child);
Ditto (mnt_child moved into struct mount now)
- if (!(page = __get_free_page(GFP_KERNEL)))
+ page = __get_free_page(GFP_KERNEL);
+ if (!page)
return -ENOMEM;
Not sure... In general I'd agree, but in this case...
next prev parent reply other threads:[~2011-11-30 6:50 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-30 2:13 [PATCH 00/28] fs: Logging style neatening and checkpatch wanking Joe Perches
2011-11-30 2:13 ` [PATCH 01/28] buffer: Use pr_<level> Joe Perches
2011-11-30 2:14 ` [PATCH 02/28] mbcache: Use current logging styles Joe Perches
2011-11-30 2:14 ` [PATCH 03/28] bio: " Joe Perches
2011-11-30 2:14 ` [PATCH 04/28] libfs: " Joe Perches
2011-11-30 2:14 ` [PATCH 05/28] super: " Joe Perches
2011-11-30 2:14 ` [PATCH 06/28] exec: Use current logging style Joe Perches
2011-11-30 2:14 ` [PATCH 07/28] namespace: Use current logging styles Joe Perches
2011-11-30 2:14 ` [PATCH 08/28] block_dev: Use current logging style Joe Perches
2011-11-30 2:14 ` [PATCH 09/28] dcache: " Joe Perches
2011-11-30 2:14 ` [PATCH 10/28] fcntl: " Joe Perches
2011-11-30 2:14 ` [PATCH 11/28] file: " Joe Perches
2011-11-30 2:14 ` [PATCH 12/28] locks: " Joe Perches
2011-11-30 2:14 ` [PATCH 13/28] open: " Joe Perches
2011-11-30 2:14 ` [PATCH 14/28] stat: " Joe Perches
2011-11-30 2:14 ` [PATCH 15/28] exec: checkpatch wanking Joe Perches
2011-11-30 2:14 ` [PATCH 16/28] namespace: " Joe Perches
2011-11-30 2:22 ` Al Viro
2011-11-30 3:39 ` Joe Perches
2011-11-30 6:50 ` Al Viro [this message]
2011-11-30 8:34 ` Joe Perches
2011-11-30 2:14 ` [PATCH 17/28] block_dev: " Joe Perches
2011-11-30 2:14 ` [PATCH 18/28] dcache: " Joe Perches
2011-11-30 2:14 ` [PATCH 19/28] fcntl: " Joe Perches
2011-11-30 2:14 ` [PATCH 20/28] file: " Joe Perches
2011-11-30 2:14 ` [PATCH 21/28] locks: " Joe Perches
2011-11-30 2:14 ` [PATCH 22/28] open: " Joe Perches
2011-11-30 2:14 ` [PATCH 23/28] stat: " Joe Perches
2011-11-30 2:14 ` [PATCH 24/28] super: " Joe Perches
2011-11-30 2:14 ` [PATCH 25/28] libfs: " Joe Perches
2011-11-30 2:14 ` [PATCH 26/28] bio: " Joe Perches
2011-11-30 2:14 ` [PATCH 27/28] mbcache: " Joe Perches
2011-11-30 2:14 ` [PATCH 28/28] buffer: " Joe Perches
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=20111130065014.GU2203@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=joe@perches.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).