Re: [PATCH v3 07/10] mm/shmem_luo: Retrieve tmpfs files onto a tmpfs mount chosen by userspace

[Pratyush Yadav]

On Wed, Nov 04 2026, David Matlack wrote:

> On 2026-11-04 05:27 PM, Pratyush Yadav wrote:
>
>> > + * If @flags contains unknown flags or O_PATH, if @mode contains unknown mode
>> > + * bits, or if @dirfd is not on a tmpfs mount, the retrieve fails with -EINVAL.
>> > + * If the file can't be created, the retrieve fails with the same errors as
>> > + * open(). A retrieve that fails before the preserved contents are restored can
>> > + * be retried.
>> 
>> How is userspace supposed to tell if preserved contents were restored?
>
> Through the error code, like Pasha said on patch 3. I'll reword this in
> v4 in terms of errors instead of kernel internals: errors from checking
> the argument and creating the file, e.g. -EINVAL, -EBADF and the errors
> that open() returns, can be retried after fixing the argument. Errors
> while restoring the contents, e.g. -ENOMEM, or -ENOSPC when the contents
> don't fit on the mount, are permanent, and retrieving the token again
> returns the same error.

I wonder if we should document per-file type error codes and what they
mean. Perhaps some time in the future...

>
> Thanks for the review. I'll address the rest in v4.

-- 
Regards,
Pratyush Yadav