Re: [PATCH v3 09/10] mm/shmem_luo: Allow retrieving tmpfs files with O_RDONLY

[Pratyush Yadav <pratyush@kernel.org>]

On Wed, Nov 04 2026, David Matlack wrote:

> On 2026-11-04 02:45 PM, Pasha Tatashin wrote:
>> On 11-04 17:52, Pratyush Yadav wrote:
>> > On Tue, Nov 03 2026, David Matlack wrote:
>> > [...]
>> > 
>> > Can't you put all your binaries in a separate session, retrieve it as
>> > the very first thing, and then finish the session? Then you can execute
>> > those and retrieve all the other sessions.
>> 
>> This is a good workaround. I am not opposed to this patch for 
>> completeness of functionality, but if we decide to keep it, perhaps it 
>> should simply be squashed into an earlier patch. The current diffstat
>> looks bad, as it mostly deletes code that was introduced earlier in this 
>> series.
>> 
>> In any case, given Pratyush's suggestion, we could also drop it.
>> 
>> > 
>> > Why do we need to support this in the kernel?
>
> That would work for binaries, and I agree that use case alone doesn't
> justify this. But I see O_RDONLY as part of the retrieve interface, not
> a feature for one use case. The retrieve argument is modeled on
> openat(), and openat() lets you open an existing file read-only.
>
> open(O_TMPFILE) only requires write access because it creates an empty
> file, and an empty read-only file is useless. A retrieved file isn't
> empty, it has the preserved contents, so O_RDONLY makes as much sense as
> it does for any other existing file. Without it, every retrieved file is
> writable, even when userspace only needs to read it.
>
> Preserve already works the same way: a file can be preserved through a
> read-only fd, as long as the caller has permission to write to it.
>
> If we keep it, I'll squash it into patch 7 in v4, so retrieve supports
> O_RDONLY from the start. The commit message will lead with the openat()
> reasoning and keep binaries as just an example.

I'm guessing this all goes away after you do Christian's suggestion? I
don't think we should be retrieving anything into a file that userspace
has opened O_RDONLY. Retrieval is in effect a write operation. So
userspace _has_ to retrieve a file and reopen it O_RDONLY after
finishing the session.

-- 
Regards,
Pratyush Yadav