https://bugzilla.kernel.org/show_bug.cgi?id=217522 --- Comment #2 from Vladimir Lomov (lomov.vl@xxxxxxxx) --- Hello ** bugzilla-daemon@xxxxxxxxxx <bugzilla-daemon@xxxxxxxxxx> [2023-06-03 14:50:24 +0000]: >https://bugzilla.kernel.org/show_bug.cgi?id=217522 > >--- Comment #1 from Darrick J. Wong (djwong@xxxxxxxxxx) --- >On Sat, Jun 03, 2023 at 03:58:25AM +0000, bugzilla-daemon@xxxxxxxxxx wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=217522 >> >> Bug ID: 217522 >> Summary: xfs_attr3_leaf_add_work produces a warning >> Product: File System >> Version: 2.5 >> Hardware: All >> OS: Linux >> Status: NEW >> Severity: normal >> Priority: P3 >> Component: XFS >> Assignee: filesystem_xfs@xxxxxxxxxxxxxxxxxxxxxx >> Reporter: lomov.vl@xxxxxxxx >> Regression: No >> >> Hi. >> >> While running linux-next >> (6.4.0-rc4-next-20230602-1-next-git-06849-gbc708bbd8260) on one of my hosts, >> I >> see the following message in the kernel log (`dmesg`): >> ``` >> Jun 02 20:01:19 smoon.bkoty.ru kernel: ------------[ cut here ]------------ >> Jun 02 20:01:19 smoon.bkoty.ru kernel: memcpy: detected field-spanning write >> (size 12) of single field "(char *)name_loc->nameval" at > > Yes, this bug is a collision between the bad old ways of doing flex > arrays: > > typedef struct xfs_attr_leaf_name_local { > __be16 valuelen; /* number of bytes in value */ > __u8 namelen; /* length of name bytes */ > __u8 nameval[1]; /* name/value bytes */ > } xfs_attr_leaf_name_local_t; > And the static checking that gcc/llvm purport to be able to do properly. Something similar has caused problems with kernel compilation before: https://lkml.org/lkml/2023/5/24/576 (I'm not 100% sure if the origin is the same though). > This is encoded into the ondisk structures, which means that someone > needs to do perform a deep audit to change each array[1] into an > array[] and then ensure that every sizeof() performed on those structure > definitions has been adjusted. Then they would need to run the full QA > test suite to ensure that no regressions have been introduced. Then > someone will need to track down any code using > /usr/include/xfs/xfs_da_format.h to let them know about the silent > compiler bomb heading their way. > I prefer we leave it as-is since this code has been running for years > with no problems. Should I assume that this problem is not significant and won't have any effect to the FS and won't cause the FS to misbehave or become corrupted? If so, why does the problem only show up on one host but not on the other? Or is this a runtime check, and it somehow happens on the first system (even rebooted twice), but not on the second one. [...] --- Vladimir Lomov -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
