Messages in this thread |  | | Date | Mon, 1 Dec 2025 13:55:34 +0000 | | Subject | Re: [PATCH v3] io: add io_pgtable abstraction | | From | Robin Murphy <> |
| |
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.
|  |