executor: fix overlay layer limit for non-rootfs mounts #4815
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix #4810
Historic layer limit for Docker images is 127. Because in overlayfs mounting 127 layers usually reaches the page size limit of mount options in Linux kernel, there is special code to work around the limitation.
This custom code was used for rootfs of container because runc takes rootfs as a directory path, meaning buildkit needs to mount it and then pass the path. For non-rootfs mounts runc takes them as direct mount configuration and performs the mount itself. As runc does not have this special way to mount long overlayfs mounts it will perform the mount with clipped options what will fail in some way in kernel depending on the precise cutoff point.
Workaround is to detect when the mount passed to runc is too long for runc to mount it itself and it that case let BuildKit mount it and in runc perform bind of the BuildKit mount.