From: Lennart Poettering <mzxreary@0pointer.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Richard Weinberger <richard@nod.at>,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
"systemd-devel@lists.freedesktop.org"
<systemd-devel@lists.freedesktop.org>
Subject: Re: [PATCH] x86: defconfig: Enable CONFIG_FHANDLE
Date: Mon, 1 Dec 2014 13:42:37 +0100 [thread overview]
Message-ID: <20141201124237.GA18839@gardel-login> (raw)
In-Reply-To: <20141201035426.GK9561@dastard>
On Mon, 01.12.14 14:54, Dave Chinner (david@fromorbit.com) wrote:
> On Mon, Dec 01, 2014 at 02:03:43AM +0100, Lennart Poettering wrote:
> > On Mon, 01.12.14 01:41, Richard Weinberger (richard@nod.at) wrote:
> >
> > > CC'ing systemd folks.
> > >
> > > Lennart, can you please explain why you need CONFIG_FHANDLE for systemd?
> > > Maybe I'm reading the source horrible wrong.
> >
> > For two usecases:
> >
> > a) Being able to detect if something is a mount point. The traditional
> > way to do this is by stat()ing the dir in question and its parent
> > and comparing st_dev. That logic is not able to detect bind mounts
> > however, if destination and the place the mount is at are actually
> > on the same file system... Thus we check the mount id too, if we
> > can get our hands on it.
>
> So what you really want in the mount id in st_buf.st_dev, not the
> underlying device number. i.e. fstatat(dirfd, path, buf,
> AT_MOUNTID)?
Well, I am not a fan of overloading things, and there might be reasons
why one would want to know both the mount id and the device id at the
same time with one atomic call, but ultimately I don't really care,
and fstatat(AT_MOUNT_ID) would certainly be at least as useful as
name_to_handle_at() is.
Lennart
next prev parent reply other threads:[~2014-12-01 12:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-25 23:36 [PATCH] x86: defconfig: Enable CONFIG_FHANDLE Richard Weinberger
2014-11-25 23:43 ` Dave Jones
2014-11-26 0:11 ` Richard Weinberger
2014-11-26 9:43 ` Paul Bolle
2014-11-25 23:51 ` Greg KH
2014-11-26 0:11 ` Richard Weinberger
2014-11-26 0:55 ` Greg KH
2014-11-26 8:13 ` Richard Weinberger
2014-11-26 9:30 ` Paul Bolle
2014-11-30 20:54 ` Dave Chinner
2014-11-30 21:08 ` Richard Weinberger
2014-12-01 0:18 ` Dave Chinner
2014-12-01 0:41 ` Richard Weinberger
2014-12-01 1:03 ` Lennart Poettering
2014-12-01 3:54 ` Dave Chinner
2014-12-01 12:42 ` Lennart Poettering [this message]
2014-12-09 10:18 ` [tip:x86/debug] x86/kconfig/defconfig: Enable CONFIG_FHANDLE=y tip-bot for Richard Weinberger
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=20141201124237.GA18839@gardel-login \
--to=mzxreary@0pointer.de \
--cc=david@fromorbit.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard@nod.at \
--cc=systemd-devel@lists.freedesktop.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