* [Bug 197069] systemd service with ProtectHome=yes causes ELOOP when accessing /home
2017-09-28 20:17 [Bug 197069] New: systemd service with ProtectHome=yes causes ELOOP when accessing /home bugzilla-daemon
@ 2017-09-30 0:34 ` bugzilla-daemon
2017-09-30 1:04 ` bugzilla-daemon
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2017-09-30 0:34 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.kernel.org/show_bug.cgi?id=197069
Theodore Tso (tytso@mit.edu) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |tytso@mit.edu
Resolution|--- |INVALID
--- Comment #1 from Theodore Tso (tytso@mit.edu) ---
This has nothing to do with the kernel or a file system. It's a systemd bug.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 197069] systemd service with ProtectHome=yes causes ELOOP when accessing /home
2017-09-28 20:17 [Bug 197069] New: systemd service with ProtectHome=yes causes ELOOP when accessing /home bugzilla-daemon
2017-09-30 0:34 ` [Bug 197069] " bugzilla-daemon
@ 2017-09-30 1:04 ` bugzilla-daemon
2017-09-30 1:07 ` bugzilla-daemon
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2017-09-30 1:04 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.kernel.org/show_bug.cgi?id=197069
--- Comment #2 from Jack (xxjack12xx@gmail.com) ---
According to CentOS, they say it's not a systemd bug
https://bugs.centos.org/view.php?id=13927
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 197069] systemd service with ProtectHome=yes causes ELOOP when accessing /home
2017-09-28 20:17 [Bug 197069] New: systemd service with ProtectHome=yes causes ELOOP when accessing /home bugzilla-daemon
2017-09-30 0:34 ` [Bug 197069] " bugzilla-daemon
2017-09-30 1:04 ` bugzilla-daemon
@ 2017-09-30 1:07 ` bugzilla-daemon
2017-09-30 5:28 ` bugzilla-daemon
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2017-09-30 1:07 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.kernel.org/show_bug.cgi?id=197069
Jack (xxjack12xx@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #3 from Jack (xxjack12xx@gmail.com) ---
Before this commit into the -lt branch, autofs and symlinked /home worked fine.
After that commit, this issue appeared.
commit 839d42687dfce0ed0ea2c6bd8d707cc0e276fbe7
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Fri Jan 20 18:28:35 2017 +1300
mnt: Tuck mounts under others instead of creating shadow/side mounts.
commit 1064f874abc0d05eeed8993815f584d847b72486 upstream.
Ever since mount propagation was introduced in cases where a mount in
propagated to parent mount mountpoint pair that is already in use the
code has placed the new mount behind the old mount in the mount hash
table.
This implementation detail is problematic as it allows creating
arbitrary length mount hash chains.
Furthermore it invalidates the constraint maintained elsewhere in the
mount code that a parent mount and a mountpoint pair will have exactly
one mount upon them. Making it hard to deal with and to talk about
this special case in the mount code.
Modify mount propagation to notice when there is already a mount at
the parent mount and mountpoint where a new mount is propagating to
and place that preexisting mount on top of the new mount.
Modify unmount propagation to notice when a mount that is being
unmounted has another mount on top of it (and no other children), and
to replace the unmounted mount with the mount on top of it.
Move the MNT_UMUONT test from __lookup_mnt_last into
__propagate_umount as that is the only call of __lookup_mnt_last where
MNT_UMOUNT may be set on any mount visible in the mount hash table.
These modifications allow:
- __lookup_mnt_last to be removed.
- attach_shadows to be renamed __attach_mnt and its shadow
handling to be removed.
- commit_tree to be simplified
- copy_tree to be simplified
The result is an easier to understand tree of mounts that does not
allow creation of arbitrary length hash chains in the mount hash table.
The result is also a very slight userspace visible difference in semantics.
The following two cases now behave identically, where before order
mattered:
case 1: (explicit user action)
B is a slave of A
mount something on A/a , it will propagate to B/a
and than mount something on B/a
case 2: (tucked mount)
B is a slave of A
mount something on B/a
and than mount something on A/a
Histroically umount A/a would fail in case 1 and succeed in case 2.
Now umount A/a succeeds in both configurations.
This very small change in semantics appears if anything to be a bug
fix to me and my survey of userspace leads me to believe that no programs
will notice or care of this subtle semantic change.
v2: Updated to mnt_change_mountpoint to not call dput or mntput
and instead to decrement the counts directly. It is guaranteed
that there will be other references when mnt_change_mountpoint is
called so this is safe.
v3: Moved put_mountpoint under mount_lock in attach_recursive_mnt
As the locking in fs/namespace.c changed between v2 and v3.
v4: Reworked the logic in propagate_mount_busy and __propagate_umount
that detects when a mount completely covers another mount.
v5: Removed unnecessary tests whose result is alwasy true in
find_topper and attach_recursive_mnt.
v6: Document the user space visible semantic difference.
Fixes: b90fa9ae8f51 ("[PATCH] shared mount handling: bind and rbind")
Tested-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 197069] systemd service with ProtectHome=yes causes ELOOP when accessing /home
2017-09-28 20:17 [Bug 197069] New: systemd service with ProtectHome=yes causes ELOOP when accessing /home bugzilla-daemon
` (2 preceding siblings ...)
2017-09-30 1:07 ` bugzilla-daemon
@ 2017-09-30 5:28 ` bugzilla-daemon
2017-09-30 7:40 ` bugzilla-daemon
2017-10-01 0:37 ` bugzilla-daemon
5 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2017-09-30 5:28 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.kernel.org/show_bug.cgi?id=197069
Theodore Tso (tytso@mit.edu) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Theodore Tso (tytso@mit.edu) ---
According to Centos, it's not a bug in the Centos kernel. That's why they
closed it.
And it's not an ext4 bug, which is why I'm closing it here.
Opening bugs in random bug trackers is not going to help you win friends, and
it's certainly not going to help you get it anyone to look at it.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 197069] systemd service with ProtectHome=yes causes ELOOP when accessing /home
2017-09-28 20:17 [Bug 197069] New: systemd service with ProtectHome=yes causes ELOOP when accessing /home bugzilla-daemon
` (3 preceding siblings ...)
2017-09-30 5:28 ` bugzilla-daemon
@ 2017-09-30 7:40 ` bugzilla-daemon
2017-10-01 0:37 ` bugzilla-daemon
5 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2017-09-30 7:40 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.kernel.org/show_bug.cgi?id=197069
Jack (xxjack12xx@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #5 from Jack (xxjack12xx@gmail.com) ---
Your opinion that I made a mistake in opening bug reports in random bug
trackers and trying to win friends in a place where I'm sure it wouldn't help
either way is very condescending. I'm reporting this bug because this bug
happens in the kernel series 4.4 and 4.9 lt series after the commit I had
mentioned previously. The bug does not happen in the same 4.4 and 4.9 series
before the commit.
Instead of closing my issue, how about helping me find the correct place to
report it? Obviously I don't know where I should file it under because I seem
to have posted it in a random place.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 197069] systemd service with ProtectHome=yes causes ELOOP when accessing /home
2017-09-28 20:17 [Bug 197069] New: systemd service with ProtectHome=yes causes ELOOP when accessing /home bugzilla-daemon
` (4 preceding siblings ...)
2017-09-30 7:40 ` bugzilla-daemon
@ 2017-10-01 0:37 ` bugzilla-daemon
5 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2017-10-01 0:37 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.kernel.org/show_bug.cgi?id=197069
Theodore Tso (tytso@mit.edu) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Theodore Tso (tytso@mit.edu) ---
The Fedora bug report you referenced indicates that it is fixed by installing
systemd 232 or above.
I suggest you post a bugfix in bug tracker system used by your distribution.
And if their answer is they don't support newer kernels on an older / obsolete
distribution, then that's your answer.
You indicated you are using Red Hat 7.0. I'm going to assume that's RHEL 7.0,
which is based on a 3.10 kernel, and a systemd from 3+ years ago. If things
fall apart when you try installing a newer kernel, that won't be the first time
RHEL has compatibility problems with newer kernels. If you are using RHEL 7,
that generally means you value stability more than you do new features. If you
want to be using a newer kernel, you should try upgrading to a more modern
distribution *first*.
If you are indeed using RHEL, then the place to ask is the Red Hat Support. I
can tell you that using a 4.4 or 4.9 kernel is not a supported kernel, so it
may very well be that the answer is that there is no right place, and what you
are doing is just not anything anyone is interested in supporting. If you want
to pay someone enough money, or you want to retain your own Linux experts, I'm
sure they might be able to make it work --- as the old NASA saying goes,
"anything will fly if you give it enough thrust" --- but it's highly likely no
one is going to be interested in supporting you for free.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread