While this commit is not affecting on the struct file refcounter leak, it affects on *which* struct vfsmnt will leak (because struct file leak tends to struct path leak, struct path leak results into struct vfsmnt leak).
In focal kernel it will be *private* (created with clone_private_mount() helper) mount leak, but in the Lunar kernel it will be userspace visible mount leak. That's why umount fails with EBUSY.
Secondly, refcounter leak happens only when one overlayfs stacked on top of another overlayfs and if mmap(2) was called with this "stacked" overlayfs configuration.
I've spent some time to look at this issue closely.
First of all I want to confirm that the issue is present in the original patch: /git.launchpad. net/~ubuntu- kernel/ ubuntu/ +source/ linux/+ git/focal/ commit/ fs/overlayfs/ file.c? h=master- next&id= 28eab192cf0e371 56fc41b36f06790 d5ca984834
("UBUNTU: SAUCE: overlayfs: fix incorrect mnt_id of files opened from map_files")
https:/
But, this leak is not clearly visible on Ubuntu Focal (5.4) kernel, while being clearly visible (as "umount: /tmp/ovlissue/ mountpointtmp/ firstunion/ tmp/ovlissue/ mountpointtmp/ secondunion: target is busy." error) on Lunar kernel. Reason for this difference in behavior is that this commit was lost in Lunar kernel: /git.launchpad. net/~ubuntu- kernel/ ubuntu/ +source/ linux/+ git/jammy/ commit/ fs/overlayfs/ file.c? h=master- next&id= 730264093da2829 4476d5c41b055a2 71facdd998
("UBUNTU: SAUCE: overlayfs: allow with shiftfs as underlay")
https:/
While this commit is not affecting on the struct file refcounter leak, it affects on *which* struct vfsmnt will leak (because struct file leak tends to struct path leak, struct path leak results into struct vfsmnt leak).
In focal kernel it will be *private* (created with clone_private_ mount() helper) mount leak, but in the Lunar kernel it will be userspace visible mount leak. That's why umount fails with EBUSY.
Secondly, refcounter leak happens only when one overlayfs stacked on top of another overlayfs and if mmap(2) was called with this "stacked" overlayfs configuration.