Open dtmdl opened 2 years ago
@flouthoc PTAL
A friendly reminder that this issue had no activity for 30 days.
@nalind @vrothberg @flouthoc @mtrmac @giuseppe any idea on this one?
Going purely by the description:
DT_REG
“for performance”, if that’s indeed what’s happening (I’m unfamiliar with the CIFS kernel code). DT_UNKNOWN
exists just for such purposes. That’s a bug that must be fixed in the kernel, IMHO.d.Info()
== lstat(2)
immediately after the symlink check. So we could do that before the check, and revert to using info.Mode()
instead of d.Type()
, to work around this. If anyone does that work, please write a detailed comment about the need for this so that it doesn’t get optimized away again.A friendly reminder that this issue had no activity for 30 days.
@nalind WDYT?
A friendly reminder that this issue had no activity for 30 days.
Description Upgrading an RHEL8.6 box from podman 4.0.2 -> podman 4.1.1 and buildah 1.24.2 -> buildah 1.26.2 broke a previously working container build. The problem seems to stem from using symlinks and CIFS, but buildah's changed behaviour is now causing an error that was previously not a problem.
Buildah is running inside a vagrant-provisioned RHEL8.6 VM, with the build context in a CIFS mount (of a shared NTFS folder from the host running Windows 10 21H2).
There is a symlink in the build context, stored as an NTFS reparse point (created using
ln -s
in WSL2 on the host) and showing as a symlink when runningls -l
on the mounted folder in the RHEL8.6 VM. The problem happens whether the 'mfsymlinks' mount option is enabled or not (vagrant defaults to enabling it).With the 'mfsymlinks' mount option enabled, the VM can run
ln -s
and create a 'symlink' that is stored on the host NTFS as a 'magic' file. The problem still happens with these symlinks. With the 'mfsymlinks' option disabled, running ln -s from the VM fails (I don't think Samba supports the creation of reparse-point style symlinks).A
git bisect
identified commit 985eec53912a5afaabe3a4abdfa054231f03ce38:Debugging with
strace
shows:Looking at the cifs module source briefly, it seems the decision to return DT_REG to readdir(), but S_IFLNK to stat() was deliberate, and motivated by performance:
https://github.com/torvalds/linux/blob/e3f259d33c0ebae1b6e4922c7cdb50e864c81928/fs/cifs/readdir.c#L195 https://github.com/torvalds/linux/blob/e3f259d33c0ebae1b6e4922c7cdb50e864c81928/fs/cifs/readdir.c#L212 https://github.com/torvalds/linux/blob/e3f259d33c0ebae1b6e4922c7cdb50e864c81928/fs/cifs/readdir.c#L278 https://github.com/torvalds/linux/blob/e3f259d33c0ebae1b6e4922c7cdb50e864c81928/fs/cifs/readdir.c#L1029
Finally, readdir(3) notes that d_type is not supported by all filesystem types:
Steps to reproduce the issue:
Describe the results you received:
Describe the results you expected:
With problematic commit reverted:
Output of
rpm -q buildah
orapt list buildah
:Output of
buildah version
:*Output of `cat /etc/release`:**
Output of
uname -a
:Output of
cat /etc/containers/storage.conf
: