Bug 850965 - /usr/sbin/fsck triggers automounts, which easily cause deadlocks
/usr/sbin/fsck triggers automounts, which easily cause deadlocks
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-22 18:44 EDT by Kay Sievers
Modified: 2012-09-17 18:01 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-11 14:53:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kay Sievers 2012-08-22 18:44:30 EDT
fsck seems to call readlink() on the target directory for the mounted check.

This triggers the automounter, but if fsck itself is ran from the
automounter context, the system will deadlock.

It should avoid running anything else than lstat() on the target directory,
which should not trigger the automount.
Comment 1 Kay Sievers 2012-08-22 20:00:25 EDT
Can't fsck just look up the maj:min of the blockdev to check in
/proc/self/mountinfo to determine if a blockdev is mounted?
Comment 2 Karel Zak 2012-08-23 11:57:15 EDT
Do you call fsck manually or from systemd? 

Does not have systemd enough information (as automount backend) to
avoid this scenario? Why do you call fsck for the mountpoints?

Maybe we can somehow detect that the target is managed by automount
(statfs() and struct statfs->f_type ???).
Comment 3 Kay Sievers 2012-08-23 12:19:17 EDT
(In reply to comment #2)
> Do you call fsck manually or from systemd? 

The automounter, in this case systemd, calls it.
 
> Does not have systemd enough information (as automount backend) to
> avoid this scenario? Why do you call fsck for the mountpoints?

It can not really avoid that, and it shouldn't. It's not about having
information or not. fsck gets passed a block device only, and it has
really not much business in readlink()ing mountpoints at that time,
it should avoid that.

> Maybe we can somehow detect that the target is managed by automount
> (statfs() and struct statfs->f_type ???).

Could be, not sure if that triggers the mount too, and I think it's still too
fragile. The only allowed operation on random mountpoints is probably lstat(), everything else will add fragile and needless things, which should likely be
avoided.

An lstat() with a dev_t match against the dev_t list in /proc/self/mountinfo
should really be good enough.
Comment 4 Karel Zak 2012-08-23 18:51:01 EDT
The problem is that the current code (util-linux 2.22) uses libmount
to detect mounted filesystems, the code in libmount compares fstab
entries with mountinfo entries. This is probably overkill and
incorrect (the device does not have to be specified in fstab) for fsck.

Not sure if devno is the right way, because btrfs uses some random
crazy maj:min in /proc/self/mountinfo files. Fortunately possible
fallback solution is to use open(device, O_RDONLY | O_EXCL), on
mounted devices it returns EBUSY.

I'll improve libmount (to make it less aggressive if possible) and fsck
to care about the device only rather and use so complex detection code
like now. ... will be fixed in the final 2.22 release.
Comment 5 Karel Zak 2012-08-24 13:25:41 EDT
Fixed by upstream commit 7a4f98854283a5b98e76902b12685ad1999b2802, Fedora package will be fixed after upgrade to the final 2.22 release.
Comment 6 Fedora Update System 2012-09-06 09:40:43 EDT
util-linux-2.22-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/util-linux-2.22-1.fc18
Comment 7 Fedora Update System 2012-09-17 18:01:10 EDT
util-linux-2.22-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.