From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Joachim Eastwood <manabian@gmail.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [git pull] vfs pile 2 (automount work)
Date: Sun, 16 Jan 2011 21:44:26 +0000 [thread overview]
Message-ID: <20110116214426.GD22723@ZenIV.linux.org.uk> (raw)
In-Reply-To: <AANLkTinZ5ng+hbOHz7DKy82HPqFwYhQvmmbM+ioSWp9x@mail.gmail.com>
On Sun, Jan 16, 2011 at 01:37:54PM -0800, Linus Torvalds wrote:
> On Sun, Jan 16, 2011 at 1:15 PM, Joachim Eastwood <manabian@gmail.com> wrote:
> >
> > f03c65993b98eeb909a4012ce7833c5857d74755 - sanitize vfsmount refcounting changes
> >
> > Breaks my ARM !CONFIG_SMP compile
>
> In fact, any non-SMP compile, it's not ARM-specific.
>
> The simple fix for the build breakage should be to just move the
> mnt_longterm thing out of the #ifdef CONFIG_SMP in
> include/linux/mount.h. But I do worry that it would cause some count
> imbalance, because there are some accesses that are still inside that
> CONFIG_SMP case in mntput_no_expire().
>
> Al, please take a look,
Already fixed. Actually, taking it out of ifdef would work (the only
place that actually cares about the value of that sucker is SMP side
of mntput()), but we are obviously better off just not touching it on
UP at all - why do pointless work and waste space?
See the patch upthread. ->mnt_longterm is SMP-only optimization of
mntput(); it's there only to free the common case of mntput() from
cacheline bouncing and on UP it's needed at all.
next prev parent reply other threads:[~2011-01-16 21:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-16 18:57 [git pull] vfs pile 2 (automount work) Al Viro
2011-01-16 21:15 ` Joachim Eastwood
2011-01-16 21:36 ` Al Viro
2011-01-16 22:05 ` Joachim Eastwood
2011-01-16 21:37 ` Linus Torvalds
2011-01-16 21:44 ` Al Viro [this message]
2011-01-16 21:57 ` Sedat Dilek
2011-01-16 23:06 ` Al Viro
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=20110116214426.GD22723@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manabian@gmail.com \
--cc=torvalds@linux-foundation.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).