lkml.org 
[lkml]   [2025]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v3] io: add io_pgtable abstraction
From
On 2025-12-01 9:58 am, Alice Ryhl wrote:
[...]
>>> We need a different signature if it's possible to have mapped != 0 when
>>> returning an error.
>>
>> Aha, thanks for clarifying - indeed this is not the common "value or error"
>> case, it is two (almost) orthogonal return values. However if we're not
>> permitting callers to try to do anything clever with -EEXIST then it might
>> make sense to just embed the inevitable cleanup-on-failure boilerplate here
>> anyway (even if we still leave retry-on-partial-success to the caller).
>
> Is the only possible error -EEXIST? I could encode that in the API if
> that is the case.

No, I was just calling out -EEXIST as the only error where I imagine a
caller *might* want to continue without cleaning up a partial mapping,
if for instance they were playing clever tricks like a background
mapping of a large buffer while already allowing other threads to
eagerly demand-page bits of it, so the "main" mapping thread just
adjusts and restarts to skip over already-present pages. Other errors
are still possible, but generally represent terminal failure conditions
at the caller's level too - in practice things like -EINVAL and -ENOMEM
are likely to happen before any mappings can be made, but io-pgtable
doesn't guarantee any particular behaviour here, so a well-behaved
caller should still generally handle cleaning up after an error (at
least if they intend to keep trying to use the pagetable beyond that point).

Cheers,
Robin.

\
 
 \ /
  Last update: 2025-12-01 14:56    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog