Re: [PATCH v3 0/2] nolibc: Add fallocate()

Re: [PATCH v3 0/2] nolibc: Add fallocate()

[Thomas Weißschuh]

On 2026-05-04 10:46:29+0900, Daniel Palmer wrote:
> On Mon, 4 May 2026 at 01:21, Thomas Weißschuh <linux@weissschuh.net> wrote:
> > Can you elaborate on what is broken?
> >
> > >    sparc32 doesn't seem to support fallocate() so made it skip
> > >    the test.
> > >  - Rebase on nolibc/for-next with the large file support bits.
> >
> > (...)
> 
> For loongarch I seem to be missing OVMF:
> 
> qemu-system-loongarch64 -display none -no-reboot -kernel
> "/home/daniel/.cache/nolibc-tests/loongarch/arch/loongarch/boot/vmlinuz.efi"
> -initrd initramfs.cpio -serial file:/dev/stdout -m 1G
> -M virt -append "console=ttyS0,115200 panic=-1 " -bios
> /usr/share/edk2//loongarch64/OVMF_CODE.fd  >
> "/home/daniel/coding/cleantrees/linux-nolibc/tools/testing/selftests/nolibc/run.out"
> qemu-system-loongarch64: Could not find ROM image
> '/usr/share/edk2//loongarch64/OVMF_CODE.fd'
> make: *** [Makefile.nolibc:341: run] Error 1
> 
> Debian doesn't seem to have a package for this.

There is this in trixie:

https://packages.debian.org/trixie/all/qemu-efi-loongarch64

Unfortunately the path to the firmware files differ between distros and
QEMU versions. There are standard JSON descriptors which could be
queried but no tool for that is provided...

(...)

> For sh4, qemu-system-sh4 is 100% on one CPU and the test never
> completes. I guess it's getting stuck during boot.

See commit b0aa5e4b087b ("sh: Fix fallout from ZERO_PAGE
consolidation"). I now merged v7.1-rc2 into the nolibc tree to get
this fix.


Thomas

Re: [PATCH v3 0/2] nolibc: Add fallocate()

[Daniel Palmer]

Hi Thomas,

On Tue, 5 May 2026 at 00:33, Thomas Weißschuh <linux@weissschuh.net> wrote:
> > Debian doesn't seem to have a package for this.
>
> There is this in trixie:
>
> https://packages.debian.org/trixie/all/qemu-efi-loongarch64

For sid it is now /usr/share/qemu-efi-loongarch64/QEMU_EFI.fd
I've changed to that locally and the tests complete now.

> > For sh4, qemu-system-sh4 is 100% on one CPU and the test never
> > completes. I guess it's getting stuck during boot.
>
> See commit b0aa5e4b087b ("sh: Fix fallout from ZERO_PAGE
> consolidation"). I now merged v7.1-rc2 into the nolibc tree to get
> this fix.

SH4 is also completing now.

Thanks,

Daniel

Re: [PATCH v3 1/2] tools/nolibc: fcntl: Add fallocate()

[Thomas Weißschuh]

Hi David,

sorry for the long delay.

On 2026-05-03 23:38:52+0100, David Laight wrote:
> On Sun, 3 May 2026 18:28:39 +0200
> Thomas Weißschuh <linux@weissschuh.net> wrote:
> 
> > On 2026-05-02 22:26:07+0100, David Laight wrote:
> > > On Sat, 2 May 2026 05:00:06 +0200
> > > Willy Tarreau <w@1wt.eu> wrote:
> > >   
> > > > On Fri, May 01, 2026 at 09:18:31AM +0100, David Laight wrote:  
> > > > > On Fri,  1 May 2026 01:41:24 +0900
> > > > > Daniel Palmer <daniel@thingy.jp> wrote:  
> > 
> > (...)
> ...
> > > Looking again, the code is trying to copy what the compiler generates
> > > when it passes a 64bit quantity on stack or in 2 registers.
> > > So f(a, b, c, d) is traditionally 'push d; push c; push b, push a; call f'.
> > > With the normal 'stack grows down' this gives (in increasing addresses):
> > > 	return address
> > > 	a
> > > 	b
> > > 	c
> > > 	d
> > > If 'b,c' is replaced by a 64bit value then you want the stack memory
> > > to contain the correct representation of a 64bit value.
> > > So for LE you need to pass the low part before the high part.  
> > 
> > Most architectures should use registers and not the stack.
> 
> Indeed, but the registers are picked as though they are caching on-stack locations.
> So the way the stack would look is relevant.

So I was a bit confused about the 64-bit arguments.
When I worked on llseek(), the system call definition explicitly splits
the 64-bit arguments into two 32-bit ones. For fallocate, that split
happens implicitly according to the function-call ABI.
I still don't see, where the stack layout is supposed to come into play.

> > > But there is one architecture (parisc) where the stack goes the other way.
> > > It is BE (I believe), but would need the LE argument order.
> > > 
> > > I think all the conditionals could be moved out of the fallocate code.
> > > I'm not sure of the exact pre-processor conditionals but something like:
> > > 
> > > #if (__BITS_PER_LONG == 64) || defined(x86_x32) || defined(mips_n32)
> > > #define __NOLIBC_ARG64(x) (x)
> > > #else
> > > /* The on-stack data has to be in the natural order for a 64bit value. */
> > > #if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN_) ^ defined(STACK_GROWS_UP)
> > > #define __NOLIBC_ARG64(x) ((int)(x)), ((int)((long long)(x) >> 32))
> > > #else
> > > #define __NOLIBC_ARG64(x) ((int)((long long)(x) >> 32)), ((int)(x))
> > > #endif
> > > #endif  
> > 
> > I highly dislike macros like these which may expand to either a single
> > or multiple arguments.
> 
> > Also this logic looks much more complicated than what Daniel proposed.
> 
> I'm not sure the casts are needed.
> The implicit casts from the function calls may mean that it is enough
> to use (x) and (x) >> 32.
> 
> I really didn't like the expansions Daniel proposed in sys_fallocate() itself.
> Neither the fallocate code nor the header file really said what was going on.
> You had to read both together and then read between the lines so see why
> it was necessary at all. 

We should have a longer explanatory comment next to the macros which
explains them.

> > > Then (if I've got it right):
> > > static __attribute__((unused))
> > > int _sys_fallocate(int fd, int mode, off_t offset, off_t size)
> > > {
> > > 	return _syscall(__NR_fallocate, fd, mode, __NOLIBC_ARG64(offset),
> > > 			__NOLIBC_ARG64(size));
> > > }  
> > 
> > We intentionally use __nolibc_syscallX() inside nolibc proper over
> > _syscall()/syscall() to have the arity of the syscall written out.
> 
> In this case the number of arguments varies - so that wouldn't work.
> But I can see why it would normally be better.
> 
> > 
> > > There is the other problem that arm32 (and maybe others) requires the 64bit
> > > variable be aligned in the stack frame.
> > > So f(int a, long long b) is effectively f(int a, int pad, long long b).
> > > (This usually causes grief with lseek().)
> > > So a pad might be needed for some system calls on some 32bit architectures.
> > > This could be done with something that expands to '' or '0,'.  
> > 
> > I don't see why we have to worry about variable alignment or stack
> > direction at all. That's the compilers job.
> 
> Except you do because you are trying to match what the compiler would
> generate for a 64bit argument by passing two 32bit values.

I still can't follow.

> I'm pretty sure that the normal syscall interface just passes the registers
> that contain arguments over from user space to kernel space and then calls
> the kernel function (ie without any regard for the types of the parameters).
> This is normally fine except for lseek() and mmap() - they may have an
> interface that re-orders the arguments.

Yes, but if we explain that our custom macros do the same as the
implicit argument splitting, and test that it works, that should be
clear enough.

> > We do have both lseek() and
> > parisc32 nowadays and both work fine. Also with Daniel's series on top.
> > Am I missing something?
> 
> godbolt doesn't have a parisc32 compiler - so I couldn't check.
> But I think if you compare the code for calls to f1(int, int, int, int),
> f2(int, long long, int) and f3(int, int long long) for f1(1,2,3,4),
> f2(1, 2ull<<32 | 3, 4) and f3(1, 2, 3ull<<32 | 4) against another BE
> system the 64bit constants will overlay different 32bit ones.

There are parisc compilers here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/


Thomas

Re: [PATCH v3 1/2] tools/nolibc: fcntl: Add fallocate()

[David Laight]

On Thu, 14 May 2026 13:51:59 +0200
Thomas Weißschuh <linux@weissschuh.net> wrote:

> Hi David,
> 
> sorry for the long delay.
> 
> On 2026-05-03 23:38:52+0100, David Laight wrote:
> > On Sun, 3 May 2026 18:28:39 +0200
> > Thomas Weißschuh <linux@weissschuh.net> wrote:
> >   
> > > On 2026-05-02 22:26:07+0100, David Laight wrote:  
> > > > On Sat, 2 May 2026 05:00:06 +0200
> > > > Willy Tarreau <w@1wt.eu> wrote:
> > > >     
> > > > > On Fri, May 01, 2026 at 09:18:31AM +0100, David Laight wrote:    
> > > > > > On Fri,  1 May 2026 01:41:24 +0900
> > > > > > Daniel Palmer <daniel@thingy.jp> wrote:    
> > > 
> > > (...)  
> > ...  
> > > > Looking again, the code is trying to copy what the compiler generates
> > > > when it passes a 64bit quantity on stack or in 2 registers.
> > > > So f(a, b, c, d) is traditionally 'push d; push c; push b, push a; call f'.
> > > > With the normal 'stack grows down' this gives (in increasing addresses):
> > > > 	return address
> > > > 	a
> > > > 	b
> > > > 	c
> > > > 	d
> > > > If 'b,c' is replaced by a 64bit value then you want the stack memory
> > > > to contain the correct representation of a 64bit value.
> > > > So for LE you need to pass the low part before the high part.    
> > > 
> > > Most architectures should use registers and not the stack.  
> > 
> > Indeed, but the registers are picked as though they are caching on-stack locations.
> > So the way the stack would look is relevant.  
> 
> So I was a bit confused about the 64-bit arguments.
> When I worked on llseek(), the system call definition explicitly splits
> the 64-bit arguments into two 32-bit ones. For fallocate, that split
> happens implicitly according to the function-call ABI.
> I still don't see, where the stack layout is supposed to come into play.

Think about what happens if/when a 64bit value is passed on stack (on 32bit).
The called code wants the two 32bit values be the same way around and have the
same alignment constraints as any other 64bit value so that it can be passed
by address to another function.
If the 64bit value is put on the stack with two 'push' instructions then the order
of the 32bit words in memory depends on whether the stack grow up or down.
Since the last argument is pushed first (so the called code can always find the
first argument), if the stack grows down (normal) then LE wants the LSW on the
lower address so it must pushed second and thus be first in the argument list.
The order needs swapping for BE (as done here) but also swapping if the stack
grows in the opposite direction.

When integer arguments are passed in registers AFAICT the registers match what
would have been placed on the stack.
So for arm32 the pad that would be required to align an on-stack 64bit value
results in an unset/unused register.

And, if you think about it, the kernel syscall takes the registers used to pass
the arguments and converts them back to into a normal C function call without
knowing anything about the function signature.
So although the (no)libc stub is copying values into registers they have to
look like a normal function call.

> 
> > > > But there is one architecture (parisc) where the stack goes the other way.
> > > > It is BE (I believe), but would need the LE argument order.
> > > > 
> > > > I think all the conditionals could be moved out of the fallocate code.
> > > > I'm not sure of the exact pre-processor conditionals but something like:
> > > > 
> > > > #if (__BITS_PER_LONG == 64) || defined(x86_x32) || defined(mips_n32)
> > > > #define __NOLIBC_ARG64(x) (x)
> > > > #else
> > > > /* The on-stack data has to be in the natural order for a 64bit value. */
> > > > #if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN_) ^ defined(STACK_GROWS_UP)
> > > > #define __NOLIBC_ARG64(x) ((int)(x)), ((int)((long long)(x) >> 32))
> > > > #else
> > > > #define __NOLIBC_ARG64(x) ((int)((long long)(x) >> 32)), ((int)(x))
> > > > #endif
> > > > #endif    
> > > 
> > > I highly dislike macros like these which may expand to either a single
> > > or multiple arguments.  
> >   
> > > Also this logic looks much more complicated than what Daniel proposed.  
> > 
> > I'm not sure the casts are needed.
> > The implicit casts from the function calls may mean that it is enough
> > to use (x) and (x) >> 32.
> > 
> > I really didn't like the expansions Daniel proposed in sys_fallocate() itself.
> > Neither the fallocate code nor the header file really said what was going on.
> > You had to read both together and then read between the lines so see why
> > it was necessary at all.   
> 
> We should have a longer explanatory comment next to the macros which
> explains them.
> 
> > > > Then (if I've got it right):
> > > > static __attribute__((unused))
> > > > int _sys_fallocate(int fd, int mode, off_t offset, off_t size)
> > > > {
> > > > 	return _syscall(__NR_fallocate, fd, mode, __NOLIBC_ARG64(offset),
> > > > 			__NOLIBC_ARG64(size));
> > > > }    
> > > 
> > > We intentionally use __nolibc_syscallX() inside nolibc proper over
> > > _syscall()/syscall() to have the arity of the syscall written out.  
> > 
> > In this case the number of arguments varies - so that wouldn't work.
> > But I can see why it would normally be better.
> >   
> > >   
> > > > There is the other problem that arm32 (and maybe others) requires the 64bit
> > > > variable be aligned in the stack frame.
> > > > So f(int a, long long b) is effectively f(int a, int pad, long long b).
> > > > (This usually causes grief with lseek().)
> > > > So a pad might be needed for some system calls on some 32bit architectures.
> > > > This could be done with something that expands to '' or '0,'.    
> > > 
> > > I don't see why we have to worry about variable alignment or stack
> > > direction at all. That's the compilers job.  
> > 
> > Except you do because you are trying to match what the compiler would
> > generate for a 64bit argument by passing two 32bit values.  
> 
> I still can't follow.

The syscall entry code just treats the parameters as two 32bit values
(in the same order as they are passed).
But the called kernel function will interpret them as a 64bit value.
It'll want that in the 'native' word order, and that depends on LE/BE
and (I'm pretty sure) the stack direction.
The compiler doesn't help you get them in the right order.

> 
> > I'm pretty sure that the normal syscall interface just passes the registers
> > that contain arguments over from user space to kernel space and then calls
> > the kernel function (ie without any regard for the types of the parameters).
> > This is normally fine except for lseek() and mmap() - they may have an
> > interface that re-orders the arguments.  
> 
> Yes, but if we explain that our custom macros do the same as the
> implicit argument splitting, and test that it works, that should be
> clear enough.
> 
> > > We do have both lseek() and
> > > parisc32 nowadays and both work fine. Also with Daniel's series on top.
> > > Am I missing something?  
> > 
> > godbolt doesn't have a parisc32 compiler - so I couldn't check.
> > But I think if you compare the code for calls to f1(int, int, int, int),
> > f2(int, long long, int) and f3(int, int long long) for f1(1,2,3,4),
> > f2(1, 2ull<<32 | 3, 4) and f3(1, 2, 3ull<<32 | 4) against another BE
> > system the 64bit constants will overlay different 32bit ones.  
> 
> There are parisc compilers here:
> https://mirrors.edge.kernel.org/pub/tools/crosstool/

I'll take a look tomorrow.

-- David

> 
> 
> Thomas