linux-kernel - Re: [PATCH] xfs: Remove i_rwsem lock in buffered read

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: <7dd3e6e2-0f85-4db3-a10b-0ef910889e12@oracle.com>
Date: Thu, 9 Jan 2025 12:40:42 +0000
From: John Garry <john.g.garry@...cle.com>
To: Amir Goldstein <amir73il@...il.com>
Cc: Chi Zhiling <chizhiling@....com>, Dave Chinner <david@...morbit.com>,
        djwong@...nel.org, cem@...nel.org, linux-xfs@...r.kernel.org,
        linux-kernel@...r.kernel.org, Chi Zhiling <chizhiling@...inos.cn>
Subject: Re: [PATCH] xfs: Remove i_rwsem lock in buffered read

On 09/01/2025 10:07, Amir Goldstein wrote:
>> Please note that IOCB_ATOMIC is not supported for buffered IO, so we
>> can't do this - we only support direct IO today.
> Oops. I see now.
> 
>> And supporting buffered IO has its challenges; how to handle overlapping
>> atomic writes of differing sizes sitting in the page cache is the main
>> issue which comes to mind.
>>
> How about the combination of RWF_ATOMIC | RWF_UNCACHED [1]
> Would it be easier/possible to support this considering that the write of folio
> is started before the write system call returns?

I am not sure exactly what you are proposing. Is it that RWF_ATOMIC for 
buffered IO auto-sets RWF_UNCACHED? Or that RWF_ATOMIC requires 
RWF_UNCACHED to be set?

But that is not so important, as I just think that future users of 
RWF_ATOMIC may not want the behavior of RWF_UNCACHED always (for 
buffered IO).

And I don't think that RWF_UNCACHED even properly solves the issues of 
RWF_ATOMIC for buffered IO in terms of handling overlapping atomic 
writes in the page cache.

Thanks,
John

> 
> Note that application that desires mutithreaded atomicity of writes vs. reads
> will only need to opt-in for RWF_ATOMIC | RWF_UNCACHED writes, so this
> is not expected to actually break its performance by killing the read caching.
> 
> Thanks,
> Amir.
> 
> [1]https://urldefense.com/v3/__https://lore.kernel.org/linux- 
> fsdevel/20241220154831.1086649-1-axboe@...nel.dk/__;!!ACWV5N9M2RV99hQ! 
> J7_5N_kSixl5iSy8IX37Cup3uKTHAaC5Oy-RlvsJeTE2kr3iJ2IXNww_rApK7TwI_ocCBSE- 
> G2vZSKSRHqY$