RE: [EXT] Re: RPMsg FS on NuttX and Linux

[Andre Heinemans]

Hi Wang Bowen,

Thanks for sending me the updated files.

I think I found the problem with the move/rename. When porting to 6.6.23 I had 
to adapt the assignment of 'struct renamedata rd' since the struct got changed 
in commit abf0857.
Previously I only updated 'rd.old_mnt_userns = &init_user_ns;' to 
'rd.old_mnt_idmap = &nop_mnt_idmap;'. The error disappeared when I added 
'rd.new_mnt_idmap = &nop_mnt_idmap;' as well.
See below our rpmsgfs_rename_handler.

Do you also have the file that contain the rpmsg_release_tx_buffer() function? 
It could not be resolved. I guess rpmsg_core.c.

Kind regards,
Andre Heinemans

static int rpmsgfs_rename_handler(struct rpmsg_device *rpdev,
  void *data, int len, void *priv, u32 src)
{
struct rpmsgfs_rename *msg = data;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 12, 0)
struct renamedata rd;
#endif
struct path oldpath, newpath;
struct dentry *newdentry;
char *oldname, *newname;
int ret, oldlen;
oldname = msg->pathname;
oldlen  = (strlen(msg->pathname) + 1 + 0x7) & ~0x7;
newname = msg->pathname + oldlen;
ret = kern_path(oldname, 0, &oldpath);
if (ret < 0)
goto fail;
if (!oldpath.dentry || !oldpath.dentry->d_parent) {
ret = -ENOENT;
goto fail1;
}
newdentry = kern_path_locked(newname, &newpath);
if (IS_ERR(newdentry)) {
ret = PTR_ERR(newdentry);
goto fail1;
}
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 12, 0)
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0)
rd.old_mnt_idmap = &nop_mnt_idmap;
rd.new_mnt_idmap = &nop_mnt_idmap;
 #else
rd.old_mnt_userns = &init_user_ns;
 #endif
rd.old_dir = oldpath.dentry->d_parent->d_inode;
rd.old_dentry = oldpath.dentry;
rd.new_dir = d_inode(newpath.dentry);
rd.new_dentry = newdentry;
rd.delegated_inode = NULL;
rd.flags = 0;
ret = vfs_rename(&rd);
#else
ret = vfs_rename(oldpath.dentry->d_parent->d_inode, oldpath.dentry,
 d_inode(newpath.dentry), newdentry, NULL, 0);
#endif
dput(newdentry);
inode_unlock(d_inode(newpath.dentry));
path_put(&newpath);
fail1:
path_put(&oldpath);
fail:
msg->header.result = ret;
return rpmsg_send(rpdev->ept, msg, sizeof(*msg));
}

> -Original Message-
> From: 汪博文 
> Sent: Friday, 8 November 2024 10:11
> To: dev@nuttx.apache.org; Andre Heinemans 
> Subject: Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
> 
>   Caution: This is an external email. Please take care when clicking links
> or opening attachments. When in doubt, report the message using the 'Report
> this email' button
> 
> Hi Andre,
> 
> Sorry for late reply.
> ‍
> ‍About your questions:
> 1. Your small fixes in Linux Rpmsg FS is right or not?
> 
> ‍‍
>  Yes, your fix is right and we will update our internal version.
> 2. Any updates in our internal rpmsgfs and rpmsgtty?
> 
> Actually, only some minor updates:
> ‍
> - We changed the rpmsg_fs and rpmsg_tty to kernel modules, and I have
> attached the new rpmsg_fs.c and rpmsg_tty.c in this email, you can check
> them;
> -  We also add some kernel version checks in rpmsg_fs and rpmsg_tty to make
> them can work with both kernel v5.10 and v5.15 And no other updates in
> rpmsg_fs and rpmsg_tty But we are planing to implement the rpmsg_fs client
> in linux (linux mount nuttx file system) and also port these rpmsg services to
> the linux kernel v6.6.
> 3. The panic in linux caused by move or rename operation We haven't
> encountered this problem before, but we can try this case in v6.6 when we
> porting rpmsg services to the new kernel version.
> 
> Kind regards,
> Wang Bowen
> 
>  Replied Message 
> From   Andre Heinemans 
> 
> Date   11/8/2024 00:33
> To dev@nuttx.apache.org,
>  Xiang Xiao,
>  Bowen
> Wang 
> Subject[External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
> [外部邮件]
> 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将
> 邮件转发给mi...@xiaomi.com进行反馈
> 
> Hi Wang Bowen, Xiang Xiao,
> 
> When I want to move a file through rpmsgfs from within nuttx on a filesystem
> hosted on linux, then I get this linux kernel oops below.
> I used the rpmsgfs linux implementation provided on this mail thread but
> ported it to 6.6.23.
> 
> It looks like every move or rename gives the error. Do you know what could
> cause the problem?
> 
> Are there maybe any updates of the linux rpmsgfs driver which I could try?
> 
> Kind regards,
> Andre
> 
> [  121.160624] Unable to handle kernel paging request at virtual address
> 8003848c38dc [  121.168612] Mem abort info:
> [  121.171464]   ESR = 0x9605
> [  121.175216]   EC = 0x25: DABT (current EL), IL = 32 bits
> [  121.180568]   SE

Re: [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux

[汪博文]

Hi Andre,

Sorry for late reply.
‍
‍About your questions:
1. Your small fixes in Linux Rpmsg FS is right or not?
‍‍
 Yes, your fix is right and we will update our internal version.
2. Any updates in our internal rpmsgfs and rpmsgtty?
Actually, only some minor updates:
‍
- We changed the rpmsg_fs and rpmsg_tty to kernel modules, and I have attached 
the
new rpmsg_fs.c and rpmsg_tty.c in this email, you can check them;
-  We also add some kernel version checks in rpmsg_fs and rpmsg_tty to make 
them can
work with both kernel v5.10 and v5.15
And no other updates in rpmsg_fs and rpmsg_tty
But we are planing to implement the rpmsg_fs client in linux (linux mount nuttx 
file system) and also
port these rpmsg services to the linux kernel v6.6.
3. The panic in linux caused by move or rename operation
We haven't encountered this problem before, but we can try this case in v6.6 
when we porting rpmsg
services to the new kernel version.

Kind regards,
Wang Bowen
 Replied Message 
FromAndre Heinemans
Date11/8/2024 00:33
To  dev@nuttx.apache.org,
Xiang Xiao,
Bowen 
Wang
Subject [External Mail]RE: [EXT] Re: RPMsg FS on NuttX and Linux
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给mi...@xiaomi.com进行反馈

Hi Wang Bowen, Xiang Xiao,

When I want to move a file through rpmsgfs from within nuttx on a filesystem 
hosted on linux, then I get this linux kernel oops below.
I used the rpmsgfs linux implementation provided on this mail thread but ported 
it to 6.6.23.

It looks like every move or rename gives the error. Do you know what could 
cause the problem?

Are there maybe any updates of the linux rpmsgfs driver which I could try?

Kind regards,
Andre

[  121.160624] Unable to handle kernel paging request at virtual address 
8003848c38dc
[  121.168612] Mem abort info:
[  121.171464]   ESR = 0x9605
[  121.175216]   EC = 0x25: DABT (current EL), IL = 32 bits
[  121.180568]   SET = 0, FnV = 0
[  121.183660]   EA = 0, S1PTW = 0
[  121.186801]   FSC = 0x05: level 1 translation fault
[  121.191709] Data abort info:
[  121.194592]   ISV = 0, ISS = 0x0005, ISS2 = 0x
[  121.200094]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  121.205172]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  121.210511] swapper pgtable: 4k pages, 48-bit VAs, pgdp=9216d000
[  121.217236] [8003848c38dc] pgd=10047003, p4d=10047003, 
pud=
[  121.225975] Internal error: Oops: 9605 [#1] PREEMPT SMP
[  121.232241] Modules linked in:
[  121.235320] CPU: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.6.23-g32082bae40f6 
#55
[  121.242735] Hardware name: NXP i.MX95 19X19 board (DT)
[  121.247885] Workqueue: imx95-cm7 imx_rproc_vq_work
[  121.252703] pstate: a049 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  121.259678] pc : cmp_map_id+0x4/0x64
[  121.263266] lr : bsearch+0x50/0xb8
[  121.266698] sp : 8000825d39e0
[  121.270026] x29: 8000825d39e0 x28: 812c7600 x27: 824f8900
[  121.277176] x26: 8000825d3bd8 x25: 800080158ae0 x24: 8000825d3a5c
[  121.284326] x23: 800080fffe1c x22: 000c x21: 404baf90
[  121.291476] x20: 8003848c38dc x19: 80975f1f x18: 800082e7be28
[  121.298626] x17: 672cba83 x16: 0fdc x15: 1000
[  121.305793] x14:  x13: 8086e029 x12: 8000825d3a74
[  121.312943] x11: 00075b7a4da2 x10: 0002 x9 : 0007
[  121.320102] x8 : 8874affc x7 : 000c x6 : 0001
[  121.327243] x5 : 0001 x4 : 0001 x3 : 000c
[  121.334385] x2 : 80975f20 x1 : 8003848c38dc x0 : 8000825d3a5c
[  121.341536] Call trace:
[  121.343997]  cmp_map_id+0x4/0x64
[  121.347238]  map_id_up+0xe4/0xec
[  121.350479]  from_kuid+0x10/0x1c
[  121.353712]  from_vfsuid+0x48/0x7c
[  121.357135]  vfs_rename+0x43c/0xa14
[  121.360627]  rpmsgfs_rename_handler+0xcc/0x148
[  121.365091]  rpmsgfs_callback+0x34/0x88
[  121.368930]  rpmsg_recv_done+0x114/0x368
[  121.372874]  vring_interrupt+0x74/0x110
[  121.376721]  rproc_vq_interrupt+0x3c/0x90
[  121.380751]  imx_rproc_notified_idr_cb+0x18/0x28
[  121.385397]  idr_for_each+0x68/0xf4
[  121.388907]  imx_rproc_vq_work+0x24/0x30
[  121.392850]  process_one_work+0x138/0x260
[  121.396880]  worker_thread+0x32c/0x438
[  121.400633]  kthread+0x118/0x11c
[  121.403883]  ret_from_fork+0x10/0x20
[  121.407506] Code: 1280 17dd  3944 (29400823)
[  121.413609] ---[ end trace  ]---

-Original Message-
From: Andre Heinemans 
Sent: Friday, 1 November 2024 12:14
To: dev@nuttx.apache.org
Subject: RE: [EXT] Re: RPMsg FS on NuttX and Linux

Caution: This is an external email. Please take care when clicking links or 
opening
attachments. When in doubt, report the message using the 'Report th

Re: Change time_t to signed type

[Gregory Nutt]

On 11/8/2024 1:41 AM, Takashi Yamamoto wrote:

have you decided that targets w/o 64-bit integers are not good enough
reason to diverge from what the latest posix says about time_t?
are we effectively dropping those targets?


Anything that has a GCC port should have int64_t.  For other cases, it 
will depend on the toolchain.  I think that only z8, z80, z180,  and 
zNEO would be a problem.


Of these, I consider only z180 to be of any value because it is often 
used in contemporary FPGAs.  The others suffer from numerous issues much 
larger than time_t:


 * z80 - I think NuttX outgrew the 64Kb address space years ago. There
   is no viable toolchain for z80 (or z180).  SDCC has some of the same
   broken behavior as ZDS-II.*
 * z8 and zNEO - These depend the ZDS-II toolchain which will never be
   supported again.  It will not support many other POSIX definitions. 
   We burned that bridge years ago in order to keep NuttX consistent
   with POSIX.  There was never a verified port of z8.

   * Specifically, they cannot pass structure or union types by value. 
   They cannot return values if these tyoes either.  This breaks
   numerous POSIX interfaces.  There once was an option to change the
   POSIX interfaces just for these toolchains, it worked but was
   removed to avoid conditional POSIX support.  See commit
   67ec3d7926d871c515fb1a55a11da8630fe53649

There was one person (other than me) that had hopes for zNEO. But the 
silicon was too buggy and ZiLOG basically stopped maintaining zNEO after 
it was sold.


https://zilog.com/ is now owned by Littlefuse.  Perhaps they will be 
better custodians than their previous foster family.


I can just do nothing with these architectures.  These have been broken 
for years and the change to time_t does not effect their broken-ness.  
Or, since they have not value, they could just be removed.  It would be 
nice to keep z180, if possible.