linux-kernel - Re: [PATCH] x86: defconfig: Enable CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141201124237.GA18839@gardel-login>
Date:	Mon, 1 Dec 2014 13:42:37 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Dave Chinner <david@...morbit.com>
Cc:	Richard Weinberger <richard@....at>, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org,
	"systemd-devel@...ts.freedesktop.org" 
	<systemd-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] x86: defconfig: Enable CONFIG_FHANDLE

On Mon, 01.12.14 14:54, Dave Chinner (david@...morbit.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@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/