On Fri, May 29, 2026 at 13:00:22 +0200, Radoslaw Smigielski via Devel wrote:
LXC domains with long file-backed filesystem path fail to start when the backing image path is longer than LO_NAME_SIZE (64 bytes, 63 characters plus NUL). When long file path is passed, virFileLoopDeviceAssociate() -> virStrcpy() fails and user gets missleading error and domain fails to start.
Example:
<filesystem type='file' accessmode='passthrough'> <driver type='loop' format='raw'/> <source file='/root/demoaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.raw'/> <target dir='/'/> </filesystem>
To match losetup behavior we copy the path with virStrcpy() and allow
of lo_file_name only if needed, while still calling open() on the unchanged path. Finally log VIR_WARN when the path is expected to be truncated. But still report VIR_ERR_INTERNAL_ERROR for all other virStrcpy() failures.
Umm, there are no other virStrcpy failures:
/** * virStrcpy: * * @dest: destination buffer * @src: source buffer * @destbytes: number of bytes the destination can accommodate * * Copies @src to @dest. @dest is guaranteed to be 'nul' terminated if * destbytes is 1 or more. * * Returns: 0 on success, -1 if @src doesn't fit into @dest and was
Hi Peter, Sure will fix my git config, sorry for that. On Fri, 29 May 2026 at 13:47, Peter Krempa <pkrempa@redhat.com> wrote: truncation truncated.
so what you have there is effectively dead code.
Indeed, this would need to be removed.
Another issue is that if you'll have:
<filesystem type='file' accessmode='passthrough'> <driver type='loop' format='raw'/> <source file='/root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylongpath/a.raw'/> <target dir='/'/> </filesystem> <filesystem type='file' accessmode='passthrough'> <driver type='loop' format='raw'/> <source file='/root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylongpath/b.raw'/> <target dir='/'/> </filesystem>
They'll be truncated to the same string.
So I tried to follow the same logic like losetup from util-linux uses to handle long paths: - takes the first 63 bytes of the absolute path - no intelligent path shortening (like keeping the filename and truncating middle) - adds an asterisk at position 62 to indicate the name was truncated lo->lo_file_name[LO_NAME_SIZE - 2] = '*'; // Position 62 gets '*' lo->lo_file_name[LO_NAME_SIZE - 1] = '\0'; // Position 63 is null terminator Above indeed can result in non-unique or unhelpful loop device names in the kernel's loop_info64 structure. Question if we should mimic the same logic or imlement someting smarter. Addint "*" before '\0' to indicate truncation would make it compatibile with losetup behavior. ---------------------- < Tℏanks | Radek >