linux-kernel - Re: [GIT PULL] non-MM updates for 6.19-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f72b8316-ddae-466e-a72d-0df9960d6c82@linux.alibaba.com>
Date: Mon, 8 Dec 2025 12:01:09 +0800
From: Joseph Qi <joseph.qi@...ux.alibaba.com>
To: Linus Torvalds <torvalds@...uxfoundation.org>,
 Heming Zhao <heming.zhao@...e.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Dmitry Antipov <dmantipov@...dex.ru>, Mark Fasheh <mark@...heh.com>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 mm-commits@...r.kernel.org, Pasha Tatashin <pasha.tatashin@...een.com>
Subject: Re: [GIT PULL] non-MM updates for 6.19-rc1



On 2025/12/8 10:21, Linus Torvalds wrote:
> On Mon, 8 Dec 2025 at 10:11, Joseph Qi <joseph.qi@...ux.alibaba.com> wrote:
>>
>> On 2025/12/7 07:40, Linus Torvalds wrote:
>>>
>>> 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.
>>
>> It looks fine to me.
>> Sorry for the noise and thank you for pointing out my mistake.
> 
> Note that if my fix is correct, the mistake is most certainly not
> yours and goes all the way back to 2009, and commit 0fe9b66c65f3
> ("ocfs2: Add preserve to reflink").
> 
> But I would really love to have somebody who knows that code go
> through it, and see if my fix actually is the right thing to do.
> 

Go through the code logic again, maybe I'm wrong before.

Take the following flow for example:

ocfs2_reflink_xattr_in_block
  ocfs2_create_empty_xattr_block
    ocfs2_create_xattr_block
      memset(xblk, 0, inode->i_sb->s_blocksize);
  ocfs2_reflink_xattr_block
    ocfs2_reflink_xattr_header

It seems now new_xh->xh_count is 0. That's means, it is trying to add a
new entry and here 'last' is pointing the next free entry.
If so, the original code seems right.

Heming, could you please verify this? I'm not familiar with this logic...

Thanks,
Joseph