Hi Geoffrey,
On 2025/10/9 7:22, Geoffrey Thorpe wrote:
Any trivial usage of hostfs seems to be broken since commit cd140ce9 ("hostfs: convert hostfs to use the new mount API") - I bisected it down to this commit to make sure.
Sorry to trouble you, can you provide your information about mount version and kernel version (use mount -v and uname -ar) ?
Thanks, Hongbo
Steps to reproduce;
The following assumes that the ARCH=um kernel has already been compiled (and the 'vmlinux' executable is in the local directory, as is the case when building from the top directory of a source tree). I built mine from a fresh clone using 'defconfig'. The uml_run.sh script creates a bootable root FS image (from debian, via docker) and then boots it with a hostfs mount to demonstrate the regression. This should be observable with any other bootable image though, simply pass "hostfs=<hostpath>" to the ./vmlinux kernel and then try to mount it from within the booted VM ("mount -t hostfs none <guestpath>").
The following 3 text files are used, and as they're small enough for copy-n-paste I figured (hoped) it was best to inline them rather than post attachments.
uml_run.sh: #!/bin/bash set -ex cat Dockerfile | docker build -t foobar:foobar - docker export -o foobar.tar \ `docker run -d foobar:foobar /bin/true` dd if=/dev/zero of=rootfs.img \ bs=$(expr 2048 * 1024 * 1024 / 512) count=512 mkfs.ext4 rootfs.img sudo ./uml_root.sh cp rootfs.img temp.img dd if=/dev/zero of=swapfile bs=1M count=1024 chmod 600 swapfile mkswap swapfile ./vmlinux mem=4G ubd0=temp.img rw ubd1=swapfile \ hostfs=$(pwd)
uml_root.sh: #!/bin/bash set -ex losetup -D LOOPDEVICE=$(losetup -f) losetup ${LOOPDEVICE} rootfs.img mkdir -p tmpmnt mount -t auto ${LOOPDEVICE} tmpmnt/ (cd tmpmnt && tar xf ../foobar.tar) umount tmpmnt losetup -D
Dockerfile: FROM debian:trixie RUN echo 'debconf debconf/frontend select Noninteractive' | \ debconf-set-selections RUN apt-get update RUN apt-get install -y apt-utils RUN apt-get -y full-upgrade RUN echo "US/Eastern" > /etc/timezone RUN chmod 644 /etc/timezone RUN cd /etc && rm -f localtime && \ ln -s /usr/share/zoneinfo/$$MYTZ localtime RUN apt-get install -y systemd-sysv kmod RUN echo "root:root" | chpasswd RUN echo "/dev/ubdb swap swap defaults 0 0" >> /etc/fstab RUN mkdir /hosthack RUN echo "none /hosthack hostfs defaults 0 0" >> /etc/fstab RUN systemctl set-default multi-user.target
Execute ./uml_run.sh to build the rootfs image and boot the VM. This requires a system with docker, and will also require a sudo password when creating the rootfs. The boot log indicates whether the hostfs mount succeeds or not - the boot should degrade to emergency mode if the mount fails, otherwise a login prompt should indicate success. (Login is root:root, e.g. if you prefer to go in and shutdown the VM gracefully.)
Please let me know if I can/should provide anything else.
Cheers, Geoff
On 2025/10/9 10:42, Hongbo Li wrote:
Hi Geoffrey,
On 2025/10/9 7:22, Geoffrey Thorpe wrote:
Any trivial usage of hostfs seems to be broken since commit cd140ce9 ("hostfs: convert hostfs to use the new mount API") - I bisected it down to this commit to make sure.
Sorry to trouble you, can you provide your information about mount version and kernel version (use mount -v and uname -ar) ?
Sorry, is mount --version
Thanks, Hongbo
Steps to reproduce;
The following assumes that the ARCH=um kernel has already been compiled (and the 'vmlinux' executable is in the local directory, as is the case when building from the top directory of a source tree). I built mine from a fresh clone using 'defconfig'. The uml_run.sh script creates a bootable root FS image (from debian, via docker) and then boots it with a hostfs mount to demonstrate the regression. This should be observable with any other bootable image though, simply pass "hostfs=<hostpath>" to the ./vmlinux kernel and then try to mount it from within the booted VM ("mount -t hostfs none <guestpath>").
The following 3 text files are used, and as they're small enough for copy-n-paste I figured (hoped) it was best to inline them rather than post attachments.
uml_run.sh: #!/bin/bash set -ex cat Dockerfile | docker build -t foobar:foobar - docker export -o foobar.tar \ `docker run -d foobar:foobar /bin/true` dd if=/dev/zero of=rootfs.img \ bs=$(expr 2048 * 1024 * 1024 / 512) count=512 mkfs.ext4 rootfs.img sudo ./uml_root.sh cp rootfs.img temp.img dd if=/dev/zero of=swapfile bs=1M count=1024 chmod 600 swapfile mkswap swapfile ./vmlinux mem=4G ubd0=temp.img rw ubd1=swapfile \ hostfs=$(pwd)
uml_root.sh: #!/bin/bash set -ex losetup -D LOOPDEVICE=$(losetup -f) losetup ${LOOPDEVICE} rootfs.img mkdir -p tmpmnt mount -t auto ${LOOPDEVICE} tmpmnt/ (cd tmpmnt && tar xf ../foobar.tar) umount tmpmnt losetup -D
Dockerfile: FROM debian:trixie RUN echo 'debconf debconf/frontend select Noninteractive' | \ debconf-set-selections RUN apt-get update RUN apt-get install -y apt-utils RUN apt-get -y full-upgrade RUN echo "US/Eastern" > /etc/timezone RUN chmod 644 /etc/timezone RUN cd /etc && rm -f localtime && \ ln -s /usr/share/zoneinfo/$$MYTZ localtime RUN apt-get install -y systemd-sysv kmod RUN echo "root:root" | chpasswd RUN echo "/dev/ubdb swap swap defaults 0 0" >> /etc/fstab RUN mkdir /hosthack RUN echo "none /hosthack hostfs defaults 0 0" >> /etc/fstab RUN systemctl set-default multi-user.target
Execute ./uml_run.sh to build the rootfs image and boot the VM. This requires a system with docker, and will also require a sudo password when creating the rootfs. The boot log indicates whether the hostfs mount succeeds or not - the boot should degrade to emergency mode if the mount fails, otherwise a login prompt should indicate success. (Login is root:root, e.g. if you prefer to go in and shutdown the VM gracefully.)
Please let me know if I can/should provide anything else.
Cheers, Geoff
On 2025-10-08 22:42, Hongbo Li wrote:
Hi Geoffrey,
On 2025/10/9 7:22, Geoffrey Thorpe wrote:
Any trivial usage of hostfs seems to be broken since commit cd140ce9 ("hostfs: convert hostfs to use the new mount API") - I bisected it down to this commit to make sure.
Sorry to trouble you, can you provide your information about mount version and kernel version (use mount -v and uname -ar) ?
root@localhost:~# mount --version mount from util-linux 2.41 (libmount 2.41.0: selinux, smack, btrfs, verity, namespaces, idmapping, fd-based-mount, statmount, statx, assert, debug)
As for the kernel version, I have been bisecting different kernel versions to find the culprit commit. The problem occurs with the commit id I mentioned (cd140ce9: "hostfs: convert hostfs to use the new mount API"). This appears to be between v6.10 and v6.11. The most recent kernel releases all seem to exhibit the problem. My own code has been using kernel v6.6 up till now and that works fine.
By the way, did you try using the steps to reproduce? No pressure to do so, I am just curious if the instructions I provided work OK for other people (or whether I missed something essential). If you do follow those steps, you should be able to see success if you use v6.6 or older, and you should see failure with anything newer.
(Side note: when bisecting, I noticed that a number of commits had to be skipped because they seg-faulted during early boot. Fortunately, that didn't prevent me from finding the culprit. I mention this just in case you stumble across a commit that seg-faults too - it appears that's unrelated to the current regression.)
Regards, Geoff
On 2025/10/9 22:04, Geoffrey Thorpe wrote:
On 2025-10-08 22:42, Hongbo Li wrote:
Hi Geoffrey,
On 2025/10/9 7:22, Geoffrey Thorpe wrote:
Any trivial usage of hostfs seems to be broken since commit cd140ce9 ("hostfs: convert hostfs to use the new mount API") - I bisected it down to this commit to make sure.
Sorry to trouble you, can you provide your information about mount version and kernel version (use mount -v and uname -ar) ?
root@localhost:~# mount --version mount from util-linux 2.41 (libmount 2.41.0: selinux, smack, btrfs, verity, namespaces, idmapping, fd-based-mount, statmount, statx, assert, debug)
As for the kernel version, I have been bisecting different kernel versions to find the culprit commit. The problem occurs with the commit id I mentioned (cd140ce9: "hostfs: convert hostfs to use the new mount API"). This appears to be between v6.10 and v6.11. The most recent kernel releases all seem to exhibit the problem. My own code has been using kernel v6.6 up till now and that works fine.
By the way, did you try using the steps to reproduce? No pressure to do
I can reproduce this with my own rootfs (not your docker built one). Let me try to investigate more.
Thanks, Hongbo
so, I am just curious if the instructions I provided work OK for other people (or whether I missed something essential). If you do follow those steps, you should be able to see success if you use v6.6 or older, and you should see failure with anything newer.
(Side note: when bisecting, I noticed that a number of commits had to be skipped because they seg-faulted during early boot. Fortunately, that didn't prevent me from finding the culprit. I mention this just in case you stumble across a commit that seg-faults too - it appears that's unrelated to the current regression.)
Regards, Geoff
linux-stable-mirror@lists.linaro.org
-
Geoffrey Thorpe -
Hongbo Li