On Tue, Nov 14, 2023 at 1:40 AM Anders Larsen <[email protected]> wrote: > < Snipped> > > sizeof(de->di_fname) is evaluated as QNX4_SHORT_NAME_MAX already at compile > time, see the definition of di_fname in uapi/linux/qnx4_fs.h > > I agree that the code is confusing, as 'de' is declared as a pointer to a > struct qnx4_inode_entry but in reality points to a struct qnx4_link_info iff > QNX4_FILE_LINK is set in de->di_status. > (Note that the corresponding field dl_status in qnx4_link_info is at the same > offset as di_status in qnx4_inode_entry - that's the disk layout.) >
Thanks for the details, yes in struct qnx4_inode_entry its size char di_fname[QNX4_SHORT_NAME_MAX]; < snipped> > > Niek reported that this fix improved the situation, but he later got a crash, > albeit at a different place (but still within the qnx4fs). Yes I saw that Niek has shared the second crash dump stack in above email thread and also in [1] Bugzilla 218111.The dump stack of the crash looks to be doing a similar lookup call context, do_statx => vfs_statx => filename_lookup => qn4x_lookup => fortify_panic ( ) [1] https://bugzilla.kernel.org/show_bug.cgi?id=218111#c4 But I also see a softlockup also in the dump stack, so something in their environment is causing softlock ups. And that tallies with the symptoms of system freeze that Niek mentioned " I can mount and view the directories, but after several hours my system froze up again." watchdog: BUG: soft lockup - CPU#7 stuck for 26s! [pool-gvfsd-admi:31952] <<<< It's possible the softlockups were occurring on fews of the CPUs on the system for a few hours before the crash occurred that caused a system slow down. BR, Ronald
