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.
Signed-off-by: Richard Weinberger <[email protected]>
---
arch/x86/configs/i386_defconfig | 1 +
arch/x86/configs/x86_64_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 32d2e70..419819d 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -8,6 +8,7 @@ CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
+CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index a481dd4..4c311dd 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -7,6 +7,7 @@ CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
+CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
--
2.1.0
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.
Perhaps also note this in the kconfig entry for it ?
Dave
On Wed, Nov 26, 2014 at 12:36:52AM +0100, Richard Weinberger wrote:
> systemd has a hard dependency on CONFIG_FHANDLE.
It's been this way for a very long time, why is this suddenly an issue?
And what about all of the other systemd kernel requirements, are you
ignoring them here?
> 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.
>
> Signed-off-by: Richard Weinberger <[email protected]>
> ---
> arch/x86/configs/i386_defconfig | 1 +
> arch/x86/configs/x86_64_defconfig | 1 +
Do these files even make any sense anymore? Who uses them? The distros
sure do not...
greg k-h
Am 26.11.2014 um 00:51 schrieb Greg KH:
> On Wed, Nov 26, 2014 at 12:36:52AM +0100, Richard Weinberger wrote:
>> systemd has a hard dependency on CONFIG_FHANDLE.
>
> It's been this way for a very long time, why is this suddenly an issue?
Because nobody cared to create patch and just called systemd names? ;-)
> And what about all of the other systemd kernel requirements, are you
> ignoring them here?
No, they are already enabled in x86 defconfig.
>> 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.
>>
>> Signed-off-by: Richard Weinberger <[email protected]>
>> ---
>> arch/x86/configs/i386_defconfig | 1 +
>> arch/x86/configs/x86_64_defconfig | 1 +
>
> Do these files even make any sense anymore? Who uses them? The distros
> sure do not...
Maybe I'm oldschool but I expect a defconfig kernel to be able to boot a
recent distro.
Thanks,
//richard
Am 26.11.2014 um 00:43 schrieb Dave Jones:
> 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.
>
> Perhaps also note this in the kconfig entry for it ?
I'm not sure if this helps a lot.
But I can create patch (including for all other systemd dependencies).
Thanks,
//richard
On Wed, Nov 26, 2014 at 01:11:01AM +0100, Richard Weinberger wrote:
> Am 26.11.2014 um 00:51 schrieb Greg KH:
> > On Wed, Nov 26, 2014 at 12:36:52AM +0100, Richard Weinberger wrote:
> >> systemd has a hard dependency on CONFIG_FHANDLE.
> >
> > It's been this way for a very long time, why is this suddenly an issue?
>
> Because nobody cared to create patch and just called systemd names? ;-)
systemd documents what is needed in order for it to boot properly quite
well, I don't see why this needs to be here.
> > Do these files even make any sense anymore? Who uses them? The distros
> > sure do not...
>
> Maybe I'm oldschool but I expect a defconfig kernel to be able to boot a
> recent distro.
You are :)
How does the defconfig know your hardware in order to be able to find
the root disk properly? Video device? USB keyboard? and so on...
I thought we were getting rid of the defconfig files entirely one of
these days, didn't some arches already do this?
greg k-h
Am 26.11.2014 um 01:55 schrieb Greg KH:
> On Wed, Nov 26, 2014 at 01:11:01AM +0100, Richard Weinberger wrote:
>> Am 26.11.2014 um 00:51 schrieb Greg KH:
>>> On Wed, Nov 26, 2014 at 12:36:52AM +0100, Richard Weinberger wrote:
>>>> systemd has a hard dependency on CONFIG_FHANDLE.
>>>
>>> It's been this way for a very long time, why is this suddenly an issue?
>>
>> Because nobody cared to create patch and just called systemd names? ;-)
>
> systemd documents what is needed in order for it to boot properly quite
> well, I don't see why this needs to be here.
Because not every kernel developer knows the contents of the damn systemd readme file.
Face it, systemd is common userspace and if a defconfig is unable to boot common userspace
we have a problem.
Yesterday I was hunting down a regression in libvirt on the shiny new openSUSE 13.2,
I had to build an older kernel.
So I did a defconfig because I know that config has all drivers for my KVM setup.
(No, I my laptop don't has to power to build the bloated .config from suse)
But systemd went nuts (in terms of doing completely crap things beside of not spawning
a getty).
After one hour of painful systemd debugging I found out that I was missing
CONFIG_FHANDLE.
I really don't understand why you are so opposed to that change.
Let's make thing easier for us.
>>> Do these files even make any sense anymore? Who uses them? The distros
>>> sure do not...
>>
>> Maybe I'm oldschool but I expect a defconfig kernel to be able to boot a
>> recent distro.
>
> You are :)
> How does the defconfig know your hardware in order to be able to find
> the root disk properly? Video device? USB keyboard? and so on...
>
> I thought we were getting rid of the defconfig files entirely one of
> these days, didn't some arches already do this?
Please don't.
Thanks,
//richard
On Wed, 2014-11-26 at 09:13 +0100, Richard Weinberger wrote:
> Am 26.11.2014 um 01:55 schrieb Greg KH:
> > On Wed, Nov 26, 2014 at 01:11:01AM +0100, Richard Weinberger wrote:
> >> Am 26.11.2014 um 00:51 schrieb Greg KH:
> >>> On Wed, Nov 26, 2014 at 12:36:52AM +0100, Richard Weinberger wrote:
> >>>> systemd has a hard dependency on CONFIG_FHANDLE.
> >>>
> >>> It's been this way for a very long time, why is this suddenly an issue?
> >>
> >> Because nobody cared to create patch and just called systemd names? ;-)
> >
> > systemd documents what is needed in order for it to boot properly quite
> > well, I don't see why this needs to be here.
>
> Because not every kernel developer knows the contents of the damn systemd readme file.
> Face it, systemd is common userspace and if a defconfig is unable to boot common userspace
> we have a problem.
>
> Yesterday I was hunting down a regression in libvirt on the shiny new openSUSE 13.2,
> I had to build an older kernel.
> So I did a defconfig because I know that config has all drivers for my KVM setup.
> (No, I my laptop don't has to power to build the bloated .config from suse)
Isn't that considered best practice? Ie, you use a .config provided by
the distribution that you run - of which you know that it will boot your
(hardware/software) setup - as a base to build new kernels. That's what
I do, while my most powerful machine tends to be a laptop bought after
its production already stopped (ie, in clearance sales).
> But systemd went nuts (in terms of doing completely crap things beside of not spawning
> a getty).
> After one hour of painful systemd debugging I found out that I was missing
> CONFIG_FHANDLE.
>
> I really don't understand why you are so opposed to that change.
> Let's make thing easier for us.
>
> >>> Do these files even make any sense anymore? Who uses them? The distros
> >>> sure do not...
> >>
> >> Maybe I'm oldschool but I expect a defconfig kernel to be able to boot a
> >> recent distro.
> >
> > You are :)
> > How does the defconfig know your hardware in order to be able to find
> > the root disk properly? Video device? USB keyboard? and so on...
I think I never tried booting a kernel built with a defconfig file. But
are the (hardware/software) setups used by people that build their own
kernel so diverse that it will make a defconfig that covers (a
substantial portion of) that group grow too big? Ie, we end up with
something that looks a lot like what distributions use?
> > I thought we were getting rid of the defconfig files entirely one of
> > these days, didn't some arches already do this?
Looking at
git ls-files "*defconfig*" | sed -e "s/arch\///; s/\/.*//" | sort -u
it seems all arches have at least one defconfig file. I do think,
however, that arch/arm dropped a substantial number of defconfig files a
few years back.
Anyhow, why should we get rid of the defconfig files entirely? Because
they aren't really useful, since they won't help in building a kernel
that actually boots the targeted systems? Or is it because of the churn
involved in keeping them up to date? (Last time I checked most of them
had accumulated quite a bit of outdated stuff. But the kconfig tools
don't mind, they just skip what isn't used in the Kconfig files
anymore.)
If it's churn, perhaps the defconfig files could be moved into a
separate repository. In that repository they should be regenerated for
every release (and every -rc). That ought to be possible automagically.
The only actual fixes would then be for the problems people notice when
using those defconfig files. I'm not sure how to detect for that
repository which defconfig files can be dropped entirely - because their
targets are not supported anymore. That seems to happen often enough
with obscure, outdated, etc. ARM boards, things like that.
> Please don't.
Paul Bolle
On Wed, 2014-11-26 at 01:11 +0100, Richard Weinberger wrote:
> Am 26.11.2014 um 00:43 schrieb Dave Jones:
> > 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.
> >
> > Perhaps also note this in the kconfig entry for it ?
>
> I'm not sure if this helps a lot.
> But I can create patch (including for all other systemd dependencies).
How would people find these notes: by grepping Kconfig files for
"systemd"? Wouldn't it make more sense - if what Richard states is
correct - to just enable those dependencies by default (provided they
have no adverse effects for a, well, not too big group of x86 systems)?
Paul Bolle
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...
Cheers,
Dave.
--
Dave Chinner
[email protected]
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.
The actual struct file_handle result is always ignored.
Thanks,
//richard
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....
Cheers,
Dave.
--
Dave Chinner
[email protected]
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
On Mon, 01.12.14 01:41, Richard Weinberger ([email protected]) 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. This actually fixes real-life
problems. For example time-based recursive clean-up logic in /tmp,
where it is desirable that the clean up stops at
submounts. However, we had reports where the clean-up fucked up
people's home directories because they mounted them for some reason
into some subdir in /tmp and they had /tmp and /home on the same
fs.
b) Because we sometimes want to know the mount options used for
specific file systems. For that you want to correlate
/proc/self/mountinfo with a path in the fs. You can of course try
to do path prefix matching and then fuck things up as soon as
people do weird mounts on top of each other. Or you can use use the
mount id name_to_handle tells you and look it up in
/proc/self/mountinfo, and everything is clean and reliable.
We have no interest in the actual fhandle data. If you give us some
other syscall to figure out the mount id, we'd be delighted to use it
instead.
udev uses the logic described in b) to determine if /dev is a devtmpfs
instance. Since devtmpfs has the same fs magic as any other tmpfs we
cannot use the statfs() magic stuff to detect this case.
Lennart
On Mon, Dec 01, 2014 at 02:03:43AM +0100, Lennart Poettering wrote:
> On Mon, 01.12.14 01:41, Richard Weinberger ([email protected]) 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)?
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Mon, 01.12.14 14:54, Dave Chinner ([email protected]) wrote:
> On Mon, Dec 01, 2014 at 02:03:43AM +0100, Lennart Poettering wrote:
> > On Mon, 01.12.14 01:41, Richard Weinberger ([email protected]) 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
Commit-ID: 15bae280e412e79d74912c7ae6b6a002444edb1f
Gitweb: http://git.kernel.org/tip/15bae280e412e79d74912c7ae6b6a002444edb1f
Author: Richard Weinberger <[email protected]>
AuthorDate: Wed, 26 Nov 2014 00:36:52 +0100
Committer: Ingo Molnar <[email protected]>
CommitDate: Mon, 8 Dec 2014 12:04:17 +0100
x86/kconfig/defconfig: Enable CONFIG_FHANDLE=y
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.
Signed-off-by: Richard Weinberger <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/configs/i386_defconfig | 1 +
arch/x86/configs/x86_64_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 32d2e70..419819d 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -8,6 +8,7 @@ CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
+CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index a481dd4..4c311dd 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -7,6 +7,7 @@ CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
+CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y