linux-kernel - Re: [PATCH v9 01/10] iomap: stash iomap read ctx in the private field of iomap

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] [day] [month] [year] [list]

Message-ID: <2ec53eec-12c5-45f9-bd7d-03f98d03a384@linux.alibaba.com>
Date: Wed, 19 Nov 2025 17:28:27 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Christoph Hellwig <hch@....de>
Cc: brauner@...nel.org, djwong@...nel.org, linux-fsdevel@...r.kernel.org,
 linux-erofs@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
 Chao Yu <chao@...nel.org>, Amir Goldstein <amir73il@...il.com>,
 Joanne Koong <joannelkoong@...il.com>, Hongbo Li <lihongbo22@...wei.com>
Subject: Re: [PATCH v9 01/10] iomap: stash iomap read ctx in the private field
 of iomap_iter



On 2025/11/19 17:12, Christoph Hellwig wrote:
> On Wed, Nov 19, 2025 at 02:17:07PM +0800, Gao Xiang wrote:
>> Hongbo didn't Cc you on this thread (I think he just added
>> recipients according to MAINTAINERS), but I know you played
>> a key role in iomap development, so I think you should be
>> in the loop about the iomap change too.
>>
>> Could you give some comments (maybe review) on this patch
>> if possible?  My own opinion is that if the first two
>> patches can be applied in the next cycle (6.19) (I understand
>> it will be too late for the whole feature into 6.19) , it
>> would be very helpful to us so at least the vfs iomap branch
>> won't be coupled anymore if the first two patch can be landed
>> in advance.
> 
> The patch itself looks fine.  But as Darrick said we really need
> to get our house in order for the iomap branch so that it actually
> works this close to the merge window.

Sigh.. I'm sorry to hear about that.

Anyway, personally I think patch 1 makes no change to iomap logic
(so I think it definitely does no harm to iomap stability), but
opens a chance for iomap users to control iter->private and pass
fs-specific contexts from iomap_begin to end (and patch 2 uses
this to get rid of kmap_to_page()). So honestly I'm eager to get
patches 1 and 2 merged.

However, it's really up to the iomap maintainers. Yet, if delayed
to the next development cycle, it might still need to resolve
cross-branch conflicts, and it could still causes some churn,
anyway...

Thanks,
Gao Xiang