ftruncate fails

ftruncate fails

[Itaru Kitayama]

Hi,
With a recent kernel I see below program fails (Bus error) if executed from 9p mounted directory, not with the local filesystem (Ext4).


#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/memfd.h>

int main() {
        char filename[] = __FILE__"_tmpfile_XXXXXX";
        int fd, size;
        size = getpagesize();
        fd = mkstemp(filename);
        if (ftruncate(fd, size)) {
                printf("error");
        }


}

Re: ftruncate fails

[Dominique Martinet]

Itaru Kitayama wrote on Mon, Apr 08, 2024 at 10:44:51AM +0900:
> With a recent kernel I see below program fails (Bus error) if executed
> from 9p mounted directory, not with the local filesystem (Ext4).

I cannot reproduce on 6.8/6.9-rc2 with qemu and a couple of options.
Bus error would be some problem with the mmap of the executable given
this code? so probably doesn't have anything to do with the content of
the program itself...

A few questions:
- What exact kernel are you running? (or closest approximation)
- What server? (assuming qemu) what mount option? (tried default
cacheless and cache=loose)
- Does this reproduce right after boot/mounting the 9p filesystem?

Thanks
-- 
Dominique Martinet | Asmadeus

Re: ftruncate fails

[Itaru Kitayama]

Hi,

> On Apr 8, 2024, at 11:01, Dominique Martinet <asmadeus@codewreck.org> wrote:
> 
> Itaru Kitayama wrote on Mon, Apr 08, 2024 at 10:44:51AM +0900:
>> With a recent kernel I see below program fails (Bus error) if executed
>> from 9p mounted directory, not with the local filesystem (Ext4).
> 
> I cannot reproduce on 6.8/6.9-rc2 with qemu and a couple of options.
> Bus error would be some problem with the mmap of the executable given
> this code? so probably doesn't have anything to do with the content of
> the program itself...
> 
> A few questions:
> - What exact kernel are you running? (or closest approximation)

v6.9-rc3

> - What server? (assuming qemu) what mount option? (tried default
> cacheless and cache=loose)

FVP and just mount -t 9p FM /mnt

> - Does this reproduce right after boot/mounting the 9p filesystem?

Not immediately after the boot/mounting.

Thanks,
Itaru.

> 
> Thanks
> -- 
> Dominique Martinet | Asmadeus

Re: ftruncate fails

[Itaru Kitayama]

> On Apr 8, 2024, at 11:08, Itaru Kitayama <itaru.kitayama@linux.dev> wrote:
> 
> Hi,
> 
>> On Apr 8, 2024, at 11:01, Dominique Martinet <asmadeus@codewreck.org> wrote:
>> 
>> Itaru Kitayama wrote on Mon, Apr 08, 2024 at 10:44:51AM +0900:
>>> With a recent kernel I see below program fails (Bus error) if executed
>>> from 9p mounted directory, not with the local filesystem (Ext4).
>> 
>> I cannot reproduce on 6.8/6.9-rc2 with qemu and a couple of options.
>> Bus error would be some problem with the mmap of the executable given
>> this code? so probably doesn't have anything to do with the content of
>> the program itself...
>> 
>> A few questions:
>> - What exact kernel are you running? (or closest approximation)
> 
> v6.9-rc3
> 
>> - What server? (assuming qemu) what mount option? (tried default
>> cacheless and cache=loose)
> 
> FVP and just mount -t 9p FM /mnt
> 
>> - Does this reproduce right after boot/mounting the 9p filesystem?
> 
> Not immediately after the boot/mounting.

My reproducer wasn’t explaining what a kselftests was showing.

If you build the “mm” subsystem and execute one of the programs, gup_longterm from the 9p mounted directory, you’ll notice the ftruncate error.

Thanks,
Itaru.

> 
> Thanks,
> Itaru.
> 
>> 
>> Thanks
>> -- 
>> Dominique Martinet | Asmadeus

Re: ftruncate fails

[Dominique Martinet]

Itaru Kitayama wrote on Mon, Apr 08, 2024 at 11:22:56AM +0900:
>> FVP and just mount -t 9p FM /mnt

FVP is the arm "fixed virutal platforms"?
I've never used it and the doc I just found doesn't clarify much but it
looks like each individual "model" provides its own emulation program,
so they each might have a different 9p server.. doesn't look like
qemu-based either.

We have had other reports of problems with 9p recently (since 6.9-rc1)
so I'll keep digging with qemu for now, but writing down to try FVP
eventually.

> >> - Does this reproduce right after boot/mounting the 9p filesystem?
> > 
> > Not immediately after the boot/mounting.
> 
> My reproducer wasn’t explaining what a kselftests was showing.
> 
> If you build the “mm” subsystem and execute one of the programs,
> gup_longterm from the 9p mounted directory, you’ll notice the
> ftruncate error.

Okay, the failure from gup_longterm isn't what you describe in your
first mail (no bus error, ENOENT on ftruncate)
I think it is a new bug though:

openat(AT_FDCWD, "gup_longterm.c_tmpfile_vKvLVC", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("gup_longterm.c_tmpfile_vKvLVC") = 0
fstatfs(3, 0x7ffcf7f74920)              = -1 ENOENT (No such file or directory)
ftruncate(3, 4096)                      = -1 ENOENT (No such file or directory)

I think that used to work, we need to fix this.


If you can reproduce the bus error though I'd be very interested.
-- 
Dominique Martinet | Asmadeus

Re: ftruncate fails

[Itaru Kitayama]

Hi Eric,

On Tue, Apr 16, 2024 at 02:16:29PM +0000, Eric Van Hensbergen wrote:
> Itaru,
> 
> If you can, could confirm that your issues go away with the pending-fixes branch of the next tree?
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=pending-fixes
> 
> I work for Arm as well, so if you could point me at the revision of FVP you are seeing the problems on I could also have a look at the server side of it and see if its breaking any assumptions we've been operating under using Qemu as our primary server.
> 

I've tested the pending-fixes branch on FVP (FVP_Base_RevC-2xAEMvA), and
confirm that binaries built on host are immediately reflected to the
latest binary, but kselftests' mm gup_longterm test still fails. David
Hildenbrand and Ryan were talking about detect fs type, ie 9p early as unsupported and do SKIP, If I remember correctly.

execve("./gup_longterm", ["./gup_longterm"], 0xffffdfdb6790 /* 12 vars */) = 0
brk(NULL)                               = 0xaaaae4c10000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfff
faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or dir
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such fi
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\260\265\2\0\0\0\0\0".
newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1605640, ...}, AT_EMPTY_PATH) =
mmap(NULL, 1650608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xff
mmap(0xffff8900c000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENY
mmap(0xffff89011000, 49072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON
close(3)                                = 0
set_tid_address(0xffff8901def0)         = 239
set_robust_list(0xffff8901df00, 24)     = 0
rseq(0xffff8901e540, 0x20, 0, 0xd428bc00) = 0
mprotect(0xffff8900c000, 12288, PROT_READ) = 0
mprotect(0xaaaabeaff000, 4096, PROT_READ) = 0
mprotect(0xffff89048000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY})
openat(AT_FDCWD, "/sys/kernel/mm/hugepages/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DI
newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_EMPTY_PATH) = 0
getrandom("\xb9\x24\x5d\x28\x15\xeb\x16\x8f", 8, GRND_NONBLOCK) = 8
brk(NULL)                               = 0xaaaae4c10000
brk(0xaaaae4c31000)                     = 0xaaaae4c31000
getdents64(3, 0xaaaae4c102d0 /* 6 entries */, 32768) = 208
newfstatat(1, "", {st_mode=S_IFIFO|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0
getdents64(3, 0xaaaae4c102d0 /* 0 entries */, 32768) = 0
close(3)                                = 0
openat(AT_FDCWD, "/sys/kernel/debug/gup_test", O_RDWR) = 3
memfd_create("test", 0)                 = 4
fstatfs(4, {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0,
ftruncate(4, 4096)                      = 0
fallocate(4, 0, 0, 4096)                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xffff88e89000
ioctl(3, _IOC(_IOC_WRITE, 0x67, 0x7, 0x18), 0xffffdeb88850) = 0
ioctl(3, _IOC(_IOC_NONE, 0x67, 0x8, 0), 0xffffdeb88850) = 0
munmap(0xffff88e89000, 4096)            = 0
close(4)                                = 0
openat(AT_FDCWD, "/tmp", O_RDWR|O_EXCL|O_TMPFILE, 0600) = 4
fcntl(4, F_GETFL)                       = 0x424002 (flags O_RDWR|O_LARGEFILE|O_T
fstatfs(4, {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=416015, f_bfree=415998, f
ftruncate(4, 4096)                      = 0
fallocate(4, 0, 0, 4096)                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xffff88e89000
ioctl(3, _IOC(_IOC_WRITE, 0x67, 0x7, 0x18), 0xffffdeb88850) = 0
ioctl(3, _IOC(_IOC_NONE, 0x67, 0x8, 0), 0xffffdeb88850) = 0
munmap(0xffff88e89000, 4096)            = 0
close(4)                                = 0
openat(AT_FDCWD, "gup_longterm.c_tmpfile_Jbjlxi", O_RDWR|O_CREAT|O_EXCL, 0600) =
unlinkat(AT_FDCWD, "gup_longterm.c_tmpfile_Jbjlxi", 0) = 0
fstatfs(4, 0xffffdeb88760)              = -1 EOPNOTSUPP (Operation not supported
ftruncate(4, 4096)                      = -1 ENOENT (No such file or directory)

Thanks,
Itaru.

>      -eric
> 
> 
> April 7, 2024 at 9:22 PM, "Itaru Kitayama" <itaru.kitayama@linux.dev> wrote:
> > 
> > > 
> > > On Apr 8, 2024, at 11:08, Itaru Kitayama <itaru.kitayama@linux.dev> wrote:
> > > 
> > >  
> > > 
> > >  Hi,
> > > 
> > >  
> > > 
> > > > 
> > > > On Apr 8, 2024, at 11:01, Dominique Martinet <asmadeus@codewreck.org> wrote:
> > > > 
> > > >  
> > > > 
> > > >  Itaru Kitayama wrote on Mon, Apr 08, 2024 at 10:44:51AM +0900:
> > > > 
> > > 
> > >  With a recent kernel I see below program fails (Bus error) if executed
> > > 
> > >  from 9p mounted directory, not with the local filesystem (Ext4).
> > > 
> > > > 
> > > > I cannot reproduce on 6.8/6.9-rc2 with qemu and a couple of options.
> > > > 
> > > >  Bus error would be some problem with the mmap of the executable given
> > > > 
> > > >  this code? so probably doesn't have anything to do with the content of
> > > > 
> > > >  the program itself...
> > > > 
> > > >  
> > > > 
> > > >  A few questions:
> > > > 
> > > >  - What exact kernel are you running? (or closest approximation)
> > > > 
> > > 
> > >  
> > > 
> > >  v6.9-rc3
> > > 
> > >  
> > > 
> > > > 
> > > > - What server? (assuming qemu) what mount option? (tried default
> > > > 
> > > >  cacheless and cache=loose)
> > > > 
> > > 
> > >  
> > > 
> > >  FVP and just mount -t 9p FM /mnt
> > > 
> > >  
> > > 
> > > > 
> > > > - Does this reproduce right after boot/mounting the 9p filesystem?
> > > > 
> > > 
> > >  
> > > 
> > >  Not immediately after the boot/mounting.
> > > 
> > 
> > My reproducer wasn’t explaining what a kselftests was showing.
> > 
> > If you build the “mm” subsystem and execute one of the programs, gup_longterm from the 9p mounted directory, you’ll notice the ftruncate error.
> > 
> > Thanks,
> > 
> > Itaru.
> > 
> > > 
> > > Thanks,
> > > 
> > >  Itaru.
> > > 
> > >  
> > > 
> > > > 
> > > > Thanks
> > > > 
> > > >  -- 
> > > > 
> > > >  Dominique Martinet | Asmadeus
> > > >
> > >
> >

Re: ftruncate fails

[Eric Van Hensbergen]

Itaru,

If you can, could confirm that your issues go away with the pending-fixes branch of the next tree?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=pending-fixes

I work for Arm as well, so if you could point me at the revision of FVP you are seeing the problems on I could also have a look at the server side of it and see if its breaking any assumptions we've been operating under using Qemu as our primary server.

     -eric


April 7, 2024 at 9:22 PM, "Itaru Kitayama" <itaru.kitayama@linux.dev> wrote:
> 
> > 
> > On Apr 8, 2024, at 11:08, Itaru Kitayama <itaru.kitayama@linux.dev> wrote:
> > 
> >  
> > 
> >  Hi,
> > 
> >  
> > 
> > > 
> > > On Apr 8, 2024, at 11:01, Dominique Martinet <asmadeus@codewreck.org> wrote:
> > > 
> > >  
> > > 
> > >  Itaru Kitayama wrote on Mon, Apr 08, 2024 at 10:44:51AM +0900:
> > > 
> > 
> >  With a recent kernel I see below program fails (Bus error) if executed
> > 
> >  from 9p mounted directory, not with the local filesystem (Ext4).
> > 
> > > 
> > > I cannot reproduce on 6.8/6.9-rc2 with qemu and a couple of options.
> > > 
> > >  Bus error would be some problem with the mmap of the executable given
> > > 
> > >  this code? so probably doesn't have anything to do with the content of
> > > 
> > >  the program itself...
> > > 
> > >  
> > > 
> > >  A few questions:
> > > 
> > >  - What exact kernel are you running? (or closest approximation)
> > > 
> > 
> >  
> > 
> >  v6.9-rc3
> > 
> >  
> > 
> > > 
> > > - What server? (assuming qemu) what mount option? (tried default
> > > 
> > >  cacheless and cache=loose)
> > > 
> > 
> >  
> > 
> >  FVP and just mount -t 9p FM /mnt
> > 
> >  
> > 
> > > 
> > > - Does this reproduce right after boot/mounting the 9p filesystem?
> > > 
> > 
> >  
> > 
> >  Not immediately after the boot/mounting.
> > 
> 
> My reproducer wasn’t explaining what a kselftests was showing.
> 
> If you build the “mm” subsystem and execute one of the programs, gup_longterm from the 9p mounted directory, you’ll notice the ftruncate error.
> 
> Thanks,
> 
> Itaru.
> 
> > 
> > Thanks,
> > 
> >  Itaru.
> > 
> >  
> > 
> > > 
> > > Thanks
> > > 
> > >  -- 
> > > 
> > >  Dominique Martinet | Asmadeus
> > >
> >
>

Re: ftruncate fails

[Eric Van Hensbergen]

Can you confirm if this was a regression (ie. this used to work over
9p) or just that the behavior is different than a local file system?

     -eric

On Tue, Apr 16, 2024 at 7:10 PM Itaru Kitayama <itaru.kitayama@linux.dev> wrote:
>
> Hi Eric,
>
> On Tue, Apr 16, 2024 at 02:16:29PM +0000, Eric Van Hensbergen wrote:
> > Itaru,
> >
> > If you can, could confirm that your issues go away with the pending-fixes branch of the next tree?
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=pending-fixes
> >
> > I work for Arm as well, so if you could point me at the revision of FVP you are seeing the problems on I could also have a look at the server side of it and see if its breaking any assumptions we've been operating under using Qemu as our primary server.
> >
>
> I've tested the pending-fixes branch on FVP (FVP_Base_RevC-2xAEMvA), and
> confirm that binaries built on host are immediately reflected to the
> latest binary, but kselftests' mm gup_longterm test still fails. David
> Hildenbrand and Ryan were talking about detect fs type, ie 9p early as unsupported and do SKIP, If I remember correctly.
>
> execve("./gup_longterm", ["./gup_longterm"], 0xffffdfdb6790 /* 12 vars */) = 0
> brk(NULL)                               = 0xaaaae4c10000
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfff
> faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or dir
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such fi
> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\260\265\2\0\0\0\0\0".
> newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1605640, ...}, AT_EMPTY_PATH) =
> mmap(NULL, 1650608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xff
> mmap(0xffff8900c000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENY
> mmap(0xffff89011000, 49072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON
> close(3)                                = 0
> set_tid_address(0xffff8901def0)         = 239
> set_robust_list(0xffff8901df00, 24)     = 0
> rseq(0xffff8901e540, 0x20, 0, 0xd428bc00) = 0
> mprotect(0xffff8900c000, 12288, PROT_READ) = 0
> mprotect(0xaaaabeaff000, 4096, PROT_READ) = 0
> mprotect(0xffff89048000, 8192, PROT_READ) = 0
> prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY})
> openat(AT_FDCWD, "/sys/kernel/mm/hugepages/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DI
> newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_EMPTY_PATH) = 0
> getrandom("\xb9\x24\x5d\x28\x15\xeb\x16\x8f", 8, GRND_NONBLOCK) = 8
> brk(NULL)                               = 0xaaaae4c10000
> brk(0xaaaae4c31000)                     = 0xaaaae4c31000
> getdents64(3, 0xaaaae4c102d0 /* 6 entries */, 32768) = 208
> newfstatat(1, "", {st_mode=S_IFIFO|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0
> getdents64(3, 0xaaaae4c102d0 /* 0 entries */, 32768) = 0
> close(3)                                = 0
> openat(AT_FDCWD, "/sys/kernel/debug/gup_test", O_RDWR) = 3
> memfd_create("test", 0)                 = 4
> fstatfs(4, {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0,
> ftruncate(4, 4096)                      = 0
> fallocate(4, 0, 0, 4096)                = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xffff88e89000
> ioctl(3, _IOC(_IOC_WRITE, 0x67, 0x7, 0x18), 0xffffdeb88850) = 0
> ioctl(3, _IOC(_IOC_NONE, 0x67, 0x8, 0), 0xffffdeb88850) = 0
> munmap(0xffff88e89000, 4096)            = 0
> close(4)                                = 0
> openat(AT_FDCWD, "/tmp", O_RDWR|O_EXCL|O_TMPFILE, 0600) = 4
> fcntl(4, F_GETFL)                       = 0x424002 (flags O_RDWR|O_LARGEFILE|O_T
> fstatfs(4, {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=416015, f_bfree=415998, f
> ftruncate(4, 4096)                      = 0
> fallocate(4, 0, 0, 4096)                = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xffff88e89000
> ioctl(3, _IOC(_IOC_WRITE, 0x67, 0x7, 0x18), 0xffffdeb88850) = 0
> ioctl(3, _IOC(_IOC_NONE, 0x67, 0x8, 0), 0xffffdeb88850) = 0
> munmap(0xffff88e89000, 4096)            = 0
> close(4)                                = 0
> openat(AT_FDCWD, "gup_longterm.c_tmpfile_Jbjlxi", O_RDWR|O_CREAT|O_EXCL, 0600) =
> unlinkat(AT_FDCWD, "gup_longterm.c_tmpfile_Jbjlxi", 0) = 0
> fstatfs(4, 0xffffdeb88760)              = -1 EOPNOTSUPP (Operation not supported
> ftruncate(4, 4096)                      = -1 ENOENT (No such file or directory)
>
> Thanks,
> Itaru.
>
> >      -eric
> >
> >
> > April 7, 2024 at 9:22 PM, "Itaru Kitayama" <itaru.kitayama@linux.dev> wrote:
> > >
> > > >
> > > > On Apr 8, 2024, at 11:08, Itaru Kitayama <itaru.kitayama@linux.dev> wrote:
> > > >
> > > >
> > > >
> > > >  Hi,
> > > >
> > > >
> > > >
> > > > >
> > > > > On Apr 8, 2024, at 11:01, Dominique Martinet <asmadeus@codewreck.org> wrote:
> > > > >
> > > > >
> > > > >
> > > > >  Itaru Kitayama wrote on Mon, Apr 08, 2024 at 10:44:51AM +0900:
> > > > >
> > > >
> > > >  With a recent kernel I see below program fails (Bus error) if executed
> > > >
> > > >  from 9p mounted directory, not with the local filesystem (Ext4).
> > > >
> > > > >
> > > > > I cannot reproduce on 6.8/6.9-rc2 with qemu and a couple of options.
> > > > >
> > > > >  Bus error would be some problem with the mmap of the executable given
> > > > >
> > > > >  this code? so probably doesn't have anything to do with the content of
> > > > >
> > > > >  the program itself...
> > > > >
> > > > >
> > > > >
> > > > >  A few questions:
> > > > >
> > > > >  - What exact kernel are you running? (or closest approximation)
> > > > >
> > > >
> > > >
> > > >
> > > >  v6.9-rc3
> > > >
> > > >
> > > >
> > > > >
> > > > > - What server? (assuming qemu) what mount option? (tried default
> > > > >
> > > > >  cacheless and cache=loose)
> > > > >
> > > >
> > > >
> > > >
> > > >  FVP and just mount -t 9p FM /mnt
> > > >
> > > >
> > > >
> > > > >
> > > > > - Does this reproduce right after boot/mounting the 9p filesystem?
> > > > >
> > > >
> > > >
> > > >
> > > >  Not immediately after the boot/mounting.
> > > >
> > >
> > > My reproducer wasn’t explaining what a kselftests was showing.
> > >
> > > If you build the “mm” subsystem and execute one of the programs, gup_longterm from the 9p mounted directory, you’ll notice the ftruncate error.
> > >
> > > Thanks,
> > >
> > > Itaru.
> > >
> > > >
> > > > Thanks,
> > > >
> > > >  Itaru.
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > >  --
> > > > >
> > > > >  Dominique Martinet | Asmadeus
> > > > >
> > > >
> > >
>

Re: ftruncate fails

[Itaru Kitayama]

> On Apr 17, 2024, at 9:20, Eric Van Hensbergen <ericvh@kernel.org> wrote:
> 
> Can you confirm if this was a regression (ie. this used to work over
> 9p) or just that the behavior is different than a local file system?

It’s not a regression, I’ve tested that program on 9p only, and it’s been that way for a while.
I am curious to know whether the 9p folk permit this as a bug or not.

Itaru.

>     -eric
> 
> On Tue, Apr 16, 2024 at 7:10 PM Itaru Kitayama <itaru.kitayama@linux.dev> wrote:
>> 
>> Hi Eric,
>> 
>> On Tue, Apr 16, 2024 at 02:16:29PM +0000, Eric Van Hensbergen wrote:
>>> Itaru,
>>> 
>>> If you can, could confirm that your issues go away with the pending-fixes branch of the next tree?
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=pending-fixes
>>> 
>>> I work for Arm as well, so if you could point me at the revision of FVP you are seeing the problems on I could also have a look at the server side of it and see if its breaking any assumptions we've been operating under using Qemu as our primary server.
>>> 
>> 
>> I've tested the pending-fixes branch on FVP (FVP_Base_RevC-2xAEMvA), and
>> confirm that binaries built on host are immediately reflected to the
>> latest binary, but kselftests' mm gup_longterm test still fails. David
>> Hildenbrand and Ryan were talking about detect fs type, ie 9p early as unsupported and do SKIP, If I remember correctly.
>> 
>> execve("./gup_longterm", ["./gup_longterm"], 0xffffdfdb6790 /* 12 vars */) = 0
>> brk(NULL)                               = 0xaaaae4c10000
>> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfff
>> faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or dir
>> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such fi
>> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
>> read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\260\265\2\0\0\0\0\0".
>> newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1605640, ...}, AT_EMPTY_PATH) =
>> mmap(NULL, 1650608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xff
>> mmap(0xffff8900c000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENY
>> mmap(0xffff89011000, 49072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON
>> close(3)                                = 0
>> set_tid_address(0xffff8901def0)         = 239
>> set_robust_list(0xffff8901df00, 24)     = 0
>> rseq(0xffff8901e540, 0x20, 0, 0xd428bc00) = 0
>> mprotect(0xffff8900c000, 12288, PROT_READ) = 0
>> mprotect(0xaaaabeaff000, 4096, PROT_READ) = 0
>> mprotect(0xffff89048000, 8192, PROT_READ) = 0
>> prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY})
>> openat(AT_FDCWD, "/sys/kernel/mm/hugepages/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DI
>> newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=0, ...}, AT_EMPTY_PATH) = 0
>> getrandom("\xb9\x24\x5d\x28\x15\xeb\x16\x8f", 8, GRND_NONBLOCK) = 8
>> brk(NULL)                               = 0xaaaae4c10000
>> brk(0xaaaae4c31000)                     = 0xaaaae4c31000
>> getdents64(3, 0xaaaae4c102d0 /* 6 entries */, 32768) = 208
>> newfstatat(1, "", {st_mode=S_IFIFO|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0
>> getdents64(3, 0xaaaae4c102d0 /* 0 entries */, 32768) = 0
>> close(3)                                = 0
>> openat(AT_FDCWD, "/sys/kernel/debug/gup_test", O_RDWR) = 3
>> memfd_create("test", 0)                 = 4
>> fstatfs(4, {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0,
>> ftruncate(4, 4096)                      = 0
>> fallocate(4, 0, 0, 4096)                = 0
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xffff88e89000
>> ioctl(3, _IOC(_IOC_WRITE, 0x67, 0x7, 0x18), 0xffffdeb88850) = 0
>> ioctl(3, _IOC(_IOC_NONE, 0x67, 0x8, 0), 0xffffdeb88850) = 0
>> munmap(0xffff88e89000, 4096)            = 0
>> close(4)                                = 0
>> openat(AT_FDCWD, "/tmp", O_RDWR|O_EXCL|O_TMPFILE, 0600) = 4
>> fcntl(4, F_GETFL)                       = 0x424002 (flags O_RDWR|O_LARGEFILE|O_T
>> fstatfs(4, {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=416015, f_bfree=415998, f
>> ftruncate(4, 4096)                      = 0
>> fallocate(4, 0, 0, 4096)                = 0
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xffff88e89000
>> ioctl(3, _IOC(_IOC_WRITE, 0x67, 0x7, 0x18), 0xffffdeb88850) = 0
>> ioctl(3, _IOC(_IOC_NONE, 0x67, 0x8, 0), 0xffffdeb88850) = 0
>> munmap(0xffff88e89000, 4096)            = 0
>> close(4)                                = 0
>> openat(AT_FDCWD, "gup_longterm.c_tmpfile_Jbjlxi", O_RDWR|O_CREAT|O_EXCL, 0600) =
>> unlinkat(AT_FDCWD, "gup_longterm.c_tmpfile_Jbjlxi", 0) = 0
>> fstatfs(4, 0xffffdeb88760)              = -1 EOPNOTSUPP (Operation not supported
>> ftruncate(4, 4096)                      = -1 ENOENT (No such file or directory)
>> 
>> Thanks,
>> Itaru.
>> 
>>>     -eric
>>> 
>>> 
>>> April 7, 2024 at 9:22 PM, "Itaru Kitayama" <itaru.kitayama@linux.dev> wrote:
>>>> 
>>>>> 
>>>>> On Apr 8, 2024, at 11:08, Itaru Kitayama <itaru.kitayama@linux.dev> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> On Apr 8, 2024, at 11:01, Dominique Martinet <asmadeus@codewreck.org> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Itaru Kitayama wrote on Mon, Apr 08, 2024 at 10:44:51AM +0900:
>>>>>> 
>>>>> 
>>>>> With a recent kernel I see below program fails (Bus error) if executed
>>>>> 
>>>>> from 9p mounted directory, not with the local filesystem (Ext4).
>>>>> 
>>>>>> 
>>>>>> I cannot reproduce on 6.8/6.9-rc2 with qemu and a couple of options.
>>>>>> 
>>>>>> Bus error would be some problem with the mmap of the executable given
>>>>>> 
>>>>>> this code? so probably doesn't have anything to do with the content of
>>>>>> 
>>>>>> the program itself...
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> A few questions:
>>>>>> 
>>>>>> - What exact kernel are you running? (or closest approximation)
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> v6.9-rc3
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> - What server? (assuming qemu) what mount option? (tried default
>>>>>> 
>>>>>> cacheless and cache=loose)
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> FVP and just mount -t 9p FM /mnt
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> - Does this reproduce right after boot/mounting the 9p filesystem?
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Not immediately after the boot/mounting.
>>>>> 
>>>> 
>>>> My reproducer wasn’t explaining what a kselftests was showing.
>>>> 
>>>> If you build the “mm” subsystem and execute one of the programs, gup_longterm from the 9p mounted directory, you’ll notice the ftruncate error.
>>>> 
>>>> Thanks,
>>>> 
>>>> Itaru.
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Itaru.
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Thanks
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>> Dominique Martinet | Asmadeus
>>>>>> 
>>>>> 
>>>> 
>> 

Re: ftruncate fails

[Eric Van Hensbergen]

It's fine as a bug, I'm just making sure it wasn't part of the
regressions of some recent patches.  (those were my first priority).
I'll take a look at reproducing and see if there is something we can
do here, I haven't looked at ftruncate/fstatfs and what path they
typically take through the kernel - but we should be able to figure
out how to accommodate the open/unlink idiom but I really need to look
at the in-kernel trace and server trace to understand why you are
getting the EOPNOTSUPP which doesn't make sense to me because we
implement statfs in the client (there is no seperate path that I see
for fstatfs) (so maybe worth double checking FVP actually implemented
that in their server) -- but also need to make sure the fid it grabs
is the open fid and not try for a transient fid (although I think that
would be ENOENT, not EOPNOTSUPP).   Similar probably for
v9fs_vfs_setattr_dotl -- both of these are used to grabbing the
transient fids, not open fids -- so I may need a catch for fstatfs and
ftruncate to find an open fid on that file.

Will let you know what I find tomorrow.

        -eric