Buildresult: linus/x86_64-defconfig/x86_64-gcc8 built on Jun 27, 04:06

kisskb

Revisions | Branches | Compilers | Configs | Build Results | Build Failures |

Status:	OK
Date/Time:	Jun 27, 04:06
Duration:	0:07:50.938967
Builder:	alpine3
Revision:	Merge tag 'v6.5/vfs.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs (`c0a572d9d32fe1e95672f24e860776dba0750a38)`
Target:	linus/x86_64-defconfig/x86_64-gcc8
Branch:	linus
Compiler:	x86_64-gcc8 (x86_64-linux-gcc (GCC) 8.5.0 / GNU ld (GNU Binutils) 2.36.1)
Config:	defconfig (download)
Log:	Download original No warnings found in log. Full Log # git gc Expanding reachable commits in commit graph: 54730 Expanding reachable commits in commit graph: 112494 Expanding reachable commits in commit graph: 171033 Expanding reachable commits in commit graph: 230660 Expanding reachable commits in commit graph: 289754 Expanding reachable commits in commit graph: 350727 Expanding reachable commits in commit graph: 411911 Expanding reachable commits in commit graph: 473568 Expanding reachable commits in commit graph: 532270 Expanding reachable commits in commit graph: 594521 Expanding reachable commits in commit graph: 656711 Expanding reachable commits in commit graph: 719081 Expanding reachable commits in commit graph: 781691 Expanding reachable commits in commit graph: 844173 Expanding reachable commits in commit graph: 906385 Expanding reachable commits in commit graph: 968062 Expanding reachable commits in commit graph: 1029752 Expanding reachable commits in commit graph: 1085675 Expanding reachable commits in commit graph: 1152253 Expanding reachable commits in commit graph: 1199732, done. Writing out commit graph in 4 passes: 56% (2708028/4798928) Writing out commit graph in 4 passes: 57% (2735389/4798928) Writing out commit graph in 4 passes: 58% (2783379/4798928) Writing out commit graph in 4 passes: 59% (2831368/4798928) Writing out commit graph in 4 passes: 60% (2879357/4798928) Writing out commit graph in 4 passes: 61% (2927347/4798928) Writing out commit graph in 4 passes: 62% (2975336/4798928) Writing out commit graph in 4 passes: 63% (3023325/4798928) Writing out commit graph in 4 passes: 64% (3071314/4798928) Writing out commit graph in 4 passes: 65% (3119304/4798928) Writing out commit graph in 4 passes: 66% (3167293/4798928) Writing out commit graph in 4 passes: 66% (3177542/4798928) Writing out commit graph in 4 passes: 67% (3215282/4798928) Writing out commit graph in 4 passes: 68% (3263272/4798928) Writing out commit graph in 4 passes: 69% (3311261/4798928) Writing out commit graph in 4 passes: 70% (3359250/4798928) Writing out commit graph in 4 passes: 71% (3407239/4798928) Writing out commit graph in 4 passes: 72% (3455229/4798928) Writing out commit graph in 4 passes: 73% (3503218/4798928) Writing out commit graph in 4 passes: 74% (3551207/4798928) Writing out commit graph in 4 passes: 75% (3599196/4798928) Writing out commit graph in 4 passes: 76% (3647186/4798928) Writing out commit graph in 4 passes: 77% (3695175/4798928) Writing out commit graph in 4 passes: 78% (3743164/4798928) Writing out commit graph in 4 passes: 79% (3791154/4798928) Writing out commit graph in 4 passes: 80% (3839143/4798928) Writing out commit graph in 4 passes: 81% (3887132/4798928) Writing out commit graph in 4 passes: 82% (3935121/4798928) Writing out commit graph in 4 passes: 83% (3983111/4798928) Writing out commit graph in 4 passes: 84% (4031100/4798928) Writing out commit graph in 4 passes: 85% (4079089/4798928) Writing out commit graph in 4 passes: 86% (4127079/4798928) Writing out commit graph in 4 passes: 87% (4175068/4798928) Writing out commit graph in 4 passes: 88% (4223057/4798928) Writing out commit graph in 4 passes: 89% (4271046/4798928) Writing out commit graph in 4 passes: 89% (4303103/4798928) Writing out commit graph in 4 passes: 90% (4319036/4798928) Writing out commit graph in 4 passes: 91% (4367025/4798928) Writing out commit graph in 4 passes: 92% (4415014/4798928) Writing out commit graph in 4 passes: 93% (4463004/4798928) Writing out commit graph in 4 passes: 94% (4510993/4798928) Writing out commit graph in 4 passes: 95% (4558982/4798928) Writing out commit graph in 4 passes: 96% (4606971/4798928) Writing out commit graph in 4 passes: 97% (4654961/4798928) Writing out commit graph in 4 passes: 98% (4702950/4798928) Writing out commit graph in 4 passes: 99% (4750939/4798928) Writing out commit graph in 4 passes: 100% (4798928/4798928) Writing out commit graph in 4 passes: 100% (4798928/4798928), done. # git rev-parse -q --verify c0a572d9d32fe1e95672f24e860776dba0750a38^{commit} # git fetch -q -n -f git://fs.ozlabs.ibm.com/kernel/linus master # git rev-parse -q --verify c0a572d9d32fe1e95672f24e860776dba0750a38^{commit} c0a572d9d32fe1e95672f24e860776dba0750a38 # git checkout -q -f -B kisskb c0a572d9d32fe1e95672f24e860776dba0750a38 # git clean -qxdf # < git log -1 # commit c0a572d9d32fe1e95672f24e860776dba0750a38 # Merge: 1f2300a73821 6ac392815628 # Author: Linus Torvalds <torvalds@linux-foundation.org> # Date: Mon Jun 26 10:27:04 2023 -0700 # # Merge tag 'v6.5/vfs.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs # # Pull vfs mount updates from Christian Brauner: # "This contains the work to extend move_mount() to allow adding a mount # beneath the topmost mount of a mount stack. # # There are two LWN articles about this. One covers the original patch # series in [1]. The other in [2] summarizes the session and roughly the # discussion between Al and me at LSFMM. The second article also goes # into some good questions from attendees. # # Since all details are found in the relevant commit with a technical # dive into semantics and locking at the end I'm only adding the # motivation and core functionality for this from commit message and # leave out the invasive details. The code is also heavily commented and # annotated as well which was explicitly requested. # # TL;DR: # # > mount -t ext4 /dev/sda /mnt # \| # └─/mnt /dev/sda ext4 # # > mount --beneath -t xfs /dev/sdb /mnt # \| # └─/mnt /dev/sdb xfs # └─/mnt /dev/sda ext4 # # > umount /mnt # \| # └─/mnt /dev/sdb xfs # # The longer motivation is that various distributions are adding or are # in the process of adding support for system extensions and in the # future configuration extensions through various tools. A more detailed # explanation on system and configuration extensions can be found on the # manpage which is listed below at [3]. # # System extension images may – dynamically at runtime — extend the # /usr/ and /opt/ directory hierarchies with additional files. This is # particularly useful on immutable system images where a /usr/ and/or # /opt/ hierarchy residing on a read-only file system shall be extended # temporarily at runtime without making any persistent modifications. # # When one or more system extension images are activated, their /usr/ # and /opt/ hierarchies are combined via overlayfs with the same # hierarchies of the host OS, and the host /usr/ and /opt/ overmounted # with it ("merging"). When they are deactivated, the mount point is # disassembled — again revealing the unmodified original host version of # the hierarchy ("unmerging"). Merging thus makes the extension's # resources suddenly appear below the /usr/ and /opt/ hierarchies as if # they were included in the base OS image itself. Unmerging makes them # disappear again, leaving in place only the files that were shipped # with the base OS image itself. # # System configuration images are similar but operate on directories # containing system or service configuration. # # On nearly all modern distributions mount propagation plays a crucial # role and the rootfs of the OS is a shared mount in a peer group # (usually with peer group id 1): # # TARGET SOURCE FSTYPE PROPAGATION MNT_ID PARENT_ID # / / ext4 shared:1 29 1 # # On such systems all services and containers run in a separate mount # namespace and are pivot_root()ed into their rootfs. A separate mount # namespace is almost always used as it is the minimal isolation # mechanism services have. But usually they are even much more isolated # up to the point where they almost become indistinguishable from # containers. # # Mount propagation again plays a crucial role here. The rootfs of all # these services is a slave mount to the peer group of the host rootfs. # This is done so the service will receive mount propagation events from # the host when certain files or directories are updated. # # In addition, the rootfs of each service, container, and sandbox is # also a shared mount in its separate peer group: # # TARGET SOURCE FSTYPE PROPAGATION MNT_ID PARENT_ID # / / ext4 shared:24 master:1 71 47 # # For people not too familiar with mount propagation, the master:1 means # that this is a slave mount to peer group 1. Which as one can see is # the host rootfs as indicated by shared:1 above. The shared:24 # indicates that the service rootfs is a shared mount in a separate peer # group with peer group id 24. # # A service may run other services. Such nested services will also have # a rootfs mount that is a slave to the peer group of the outer service # rootfs mount. # # For containers things are just slighly different. A container's rootfs # isn't a slave to the service's or host rootfs' peer group. The rootfs # mount of a container is simply a shared mount in its own peer group: # # TARGET SOURCE FSTYPE PROPAGATION MNT_ID PARENT_ID # /home/ubuntu/debian-tree / ext4 shared:99 61 60 # # So whereas services are isolated OS components a container is treated # like a separate world and mount propagation into it is restricted to a # single well known mount that is a slave to the peer group of the # shared mount /run on the host: # # TARGET SOURCE FSTYPE PROPAGATION MNT_ID PARENT_ID # /propagate/debian-tree /run/host/incoming tmpfs master:5 71 68 # # Here, the master:5 indicates that this mount is a slave to the peer # group with peer group id 5. This allows to propagate mounts into the # container and served as a workaround for not being able to insert # mounts into mount namespaces directly. But the new mount api does # support inserting mounts directly. For the interested reader the # blogpost in [4] might be worth reading where I explain the old and the # new approach to inserting mounts into mount namespaces. # # Containers of course, can themselves be run as services. They often # run full systems themselves which means they again run services and # containers with the exact same propagation settings explained above. # # The whole system is designed so that it can be easily updated, # including all services in various fine-grained ways without having to # enter every single service's mount namespace which would be # prohibitively expensive. The mount propagation layout has been # carefully chosen so it is possible to propagate updates for system # extensions and configurations from the host into all services. # # The simplest model to update the whole system is to mount on top of # /usr, /opt, or /etc on the host. The new mount on /usr, /opt, or /etc # will then propagate into every service. This works cleanly the first # time. However, when the system is updated multiple times it becomes # necessary to unmount the first update on /opt, /usr, /etc and then # propagate the new update. But this means, there's an interval where # the old base system is accessible. This has to be avoided to protect # against downgrade attacks. # # The vfs already exposes a mechanism to userspace whereby mounts can be # mounted beneath an existing mount. Such mounts are internally referred # to as "tucked". The patch series exposes the ability to mount beneath # a top mount through the new MOVE_MOUNT_BENEATH flag for the # move_mount() system call. This allows userspace to seamlessly upgrade # mounts. After this series the only thing that will have changed is # that mounting beneath an existing mount can be done explicitly instead # of just implicitly. # # The crux is that the proposed mechanism already exists and that it is # so powerful as to cover cases where mounts are supposed to be updated # with new versions. Crucially, it offers an important flexibility. # Namely that updates to a system may either be forced or can be delayed # and the umount of the top mount be left to a service if it is a # cooperative one" # # Link: https://lwn.net/Articles/927491 [1] # Link: https://lwn.net/Articles/934094 [2] # Link: https://man7.org/linux/man-pages/man8/systemd-sysext.8.html [3] # Link: https://brauner.io/2023/02/28/mounting-into-mount-namespaces.html [4] # Link: https://github.com/flatcar/sysext-bakery # Link: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 # Link: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2 # Link: https://github.com/systemd/systemd/pull/26013 # # * tag 'v6.5/vfs.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: # fs: allow to mount beneath top mount # fs: use a for loop when locking a mount # fs: properly document __lookup_mnt() # fs: add path_mounted() # < /opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux-ld --version # < git log --format=%s --max-count=1 c0a572d9d32fe1e95672f24e860776dba0750a38 # make -s -j 160 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux- x86_64_defconfig # < make -s -j 160 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux- help # make -s -j 160 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux- olddefconfig # make -s -j 160 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux- Completed OK # rm -rf /kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 # Build took: 0:07:50.938967

© Michael Ellerman 2006-2018.