Bug 850965

Summary:	/usr/sbin/fsck triggers automounts, which easily cause deadlocks
Product:	[Fedora] Fedora	Reporter:	Kay Sievers <kay>
Component:	util-linux	Assignee:	Karel Zak <kzak>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	jonathan, kzak, mluscon
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-09-11 18:53:11 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kay Sievers 2012-08-22 22:44:30 UTC

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-23 00:00:25 UTC

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 15:57:15 UTC

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 16:19:17 UTC

(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 22:51:01 UTC

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 17:25:41 UTC

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 13:40:43 UTC

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 22:01:10 UTC

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.