All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Dave Chinner <david@fromorbit.com>
Cc: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	hpa@zytor.com, gregkh@linuxfoundation.org,
	rafael.j.wysocki@intel.com, pebolle@tiscali.nl,
	linux-kernel@vger.kernel.org,
	"systemd-devel@lists.freedesktop.org" 
	<systemd-devel@lists.freedesktop.org>,
	Lennart Poettering <lennart@poettering.net>
Subject: Re: [PATCH] x86: defconfig: Enable CONFIG_FHANDLE
Date: Mon, 01 Dec 2014 01:41:13 +0100	[thread overview]
Message-ID: <547BB929.3020805@nod.at> (raw)
In-Reply-To: <20141201001849.GJ9561@dastard>

Am 01.12.2014 um 01:18 schrieb Dave Chinner:
> On Sun, Nov 30, 2014 at 10:08:01PM +0100, Richard Weinberger wrote:
>> Am 30.11.2014 um 21:54 schrieb Dave Chinner:
>>> On Wed, Nov 26, 2014 at 12:36:52AM +0100, Richard Weinberger wrote:
>>>> systemd has a hard dependency on CONFIG_FHANDLE.
>>>> If you run systemd with CONFIG_FHANDLE=n it will somehow
>>>> boot but fail to spawn a getty or other basic services.
>>>> As systemd is now used by most x86 distributions it
>>>> makes sense to enabled this by default and save kernel
>>>> hackers a lot of value debugging time.
>>>
>>> The bigger question to me is this: why does systemd need to
>>> store/open by handle rather than just opening paths directly when
>>> needed? This interface is intended for stable, pathless access to
>>> inodes across unmount/mount contexts (e.g. userspace NFS servers,
>>> filesystem backup programs, etc) so I'm curious as to the problem
>>> systemd is solving using this interface. I just can't see the
>>> problem being solved here, and why path based security checks on
>>> every open() aren't necessary...
>>
>> Digging inter systemd source shows that they are using name_to_handle_at()
>> to get the mount id of a given path.
> 
> From the name_to_handle_at() man page:
> 
>     The mount_id argument returns an identifier for the filesystem
>     mount that corresponds to pathname.  This corresponds to the
>     first  field in  one  of  the records in /proc/self/mountinfo.
>     Opening the pathname in the fifth field of that record yields a
>     file descriptor for the mount point; that file descriptor can be
>     used in a subsequent call to open_by_handle_at().
> 
> So why do they need CONFIG_FHANDLE to get the mount id in userspace?
> Indeed, what do they even need the mount id for?
> 
>> The actual struct file_handle result is always ignored.
> 
> That sounds like a classic case of interface abuse. i.e. using an
> interface for something it was not designed or intended for....

CC'ing systemd folks.

Lennart, can you please explain why you need CONFIG_FHANDLE for systemd?
Maybe I'm reading the source horrible wrong.

Thanks,
//richard

  reply	other threads:[~2014-12-01  0:41 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 [this message]
2014-12-01  1:03         ` Lennart Poettering
2014-12-01  3:54           ` Dave Chinner
2014-12-01 12:42             ` Lennart Poettering
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=547BB929.3020805@nod.at \
    --to=richard@nod.at \
    --cc=david@fromorbit.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=lennart@poettering.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pebolle@tiscali.nl \
    --cc=rafael.j.wysocki@intel.com \
    --cc=systemd-devel@lists.freedesktop.org \
    --cc=tglx@linutronix.de \
    --cc=x86@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 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.