From: Linus Torvalds <torvalds@linuxfoundation.org>
To: Andrew Morton <akpm@linux-foundation.org>,
Dmitry Antipov <dmantipov@yandex.ru>,
Joseph Qi <joseph.qi@linux.alibaba.com>,
Heming Zhao <heming.zhao@suse.com>,
Mark Fasheh <mark@fasheh.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
mm-commits@vger.kernel.org,
Pasha Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [GIT PULL] non-MM updates for 6.19-rc1
Date: Sat, 6 Dec 2025 15:40:08 -0800 [thread overview]
Message-ID: <CAHk-=wgG3xqJn1=SVw-npsdwCRtyY=sYbLa7HFkmj_Q0U=vdHQ@mail.gmail.com> (raw)
In-Reply-To: <20251206111533.f1b18ce84d0854b5f6d86a8f@linux-foundation.org>
On Sat, 6 Dec 2025 at 11:15, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Dmitry Antipov (8):
> ocfs2: annotate flexible array members with __counted_by_le()
This causes the build to fail for me with gcc 15.2.1:
In function ‘fortify_memset_chk’,
inlined from ‘ocfs2_reflink_xattr_header’ at fs/ocfs2/xattr.c:6365:5:
include/linux/fortify-string.h:480:25: error: call to
‘__write_overflow_field’ declared with attribute warning: detected
write beyond size of field (1st parameter); maybe use struct_group()?
[-Werror=attribute-warning]
And the reason appears to likely be a bug this exposes, rather than a
bug in the annotation. But I really don't know the ocfs2 code at all,
so I'm going by "the error message is horrendous, but I can follow the
logic in the code, and I think the code was actually wrong".
I have "fixed" things.
And I put that "fixed' in quotes, because my fix looks sane to me, and
makes the array counting logic happy, and my fix may well be the
RightThing(tm), but somebody who actually knows the ocfs2 code needs
to check it out.
See commit c06c303832ec ("ocfs2: fix xattr array entry __counted_by
error") which simply makes the 'last' pointer point to the actual last
entry, rather than point to one _past_ the last entry. So now the
memmove() and memset() in the "possibly remove entry" loop below might
actually work right, in addition to building cleanly.
But again: I did this without knowing anything about the code, just by
looking at the logic.
I _think_ the code used to copy one entry too much, and cleared an
entry past the end. It probably worked fine, because the code also
decrements xh_count, so even if it cleared the wrong entry, it was
past the counted end.
I'm a bit unhappy that this didn't show up in linux-next and that I
had to chase this down. I don't think my gcc version is that odd.
Anyway, it's building for me, but I really really want some ocfs2
person to take a look. Please?
Linus
next prev parent reply other threads:[~2025-12-06 23:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-06 19:15 Andrew Morton
2025-12-06 23:33 ` pr-tracker-bot
2025-12-06 23:40 ` Linus Torvalds [this message]
2025-12-08 1:11 ` Joseph Qi
2025-12-08 2:21 ` Linus Torvalds
2025-12-08 4:01 ` Joseph Qi
2025-12-08 4:08 ` Linus Torvalds
2025-12-08 7:58 ` Heming Zhao
2025-12-08 19:07 ` Mark Fasheh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wgG3xqJn1=SVw-npsdwCRtyY=sYbLa7HFkmj_Q0U=vdHQ@mail.gmail.com' \
--to=torvalds@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=dmantipov@yandex.ru \
--cc=heming.zhao@suse.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark@fasheh.com \
--cc=mm-commits@vger.kernel.org \
--cc=pasha.tatashin@soleen.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox