Bug 1650045

Summary:	When using bind mounts, df shows bind mountpoint instead of real one
Product:	Red Hat Enterprise Linux 7	Reporter:	Gonzalo Siero <gsierohu>
Component:	coreutils	Assignee:	Kamil Dudka <kdudka>
Status:	CLOSED DUPLICATE	QA Contact:	qe-baseos-daemons
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.5	CC:	kdudka
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-11-15 09:36:59 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 Gonzalo Siero 2018-11-15 09:09:37 UTC

Description of problem:

df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory.

Version-Release number of selected component (if applicable):

I've tested in RHEL 7.5/coreutils-8.22-21.el7.x86_64 but the code is the
same for newer versions.

How reproducible:

Steps to Reproduce:

Suppose you mount "/dev/sdb" in "/export/home" (in my case ext4), then by
simply creating a bind mount with shorter mountpoint (strlen), will provoke the issue :

# mount --bind -s  -o defaults /export/home/test /home/test

Actual results:

# df -k|grep sdb
/dev/sdb             5029504 1044508     3706468  22% /home/test

Expected results:

# df -k|grep sdb
/dev/sdb             5029504 1044508     3706468  22% /export/home

Additional info:

The reason why this happens is because bind mounts cannot be differentiated 
from original ones, so st_dev in a stat syscall gives the same value. Then
in filter_mount_list() (src/df.c) the "real" mountpoint is dicarded when the
bind mountpoint strlen is shorter...

Looks like there has been some discussion upstream regarding this, see
3babaf83875ceac896c8dd3a64248e955dfecef9

Comment 2 Kamil Dudka 2018-11-15 09:36:59 UTC

Thank you for reporting it!  I believe this is already tracked as bug #1042840.

*** This bug has been marked as a duplicate of bug 1042840 ***