On 9/25/24 11:39 AM, Al Viro wrote: > On Wed, Sep 25, 2024 at 12:01:01AM -0600, Jens Axboe wrote: > >> The normal policy is that anything that is read-only should remain >> stable after ->prep() has been called, so that ->issue() can use it. >> That means the application can keep it on-stack as long as it's valid >> until io_uring_submit() returns. For structs/buffers that are copied to >> after IO, those the application obviously need to keep around until they >> see a completion for that request. So yes, for the xattr cases where the >> struct is copied to at completion time, those do not need to be stable >> after ->prep(), could be handled purely on the ->issue() side. > > Hmm... Nothing in xattr is copied in both directions, actually. Even if it's just copied out at the end, it does not need to remain stable after ->prep(). But most things will still do prep appropriate things at prep time, just to keep it consistent across different op types. Regardless, other things read from the sqe need to be stable after prep anyway, so it's just the best place to do copy-in of structs too, even if they are written at completion time and could defer reading it in until issue. The ->issue() side is mostly just about that, issuing a request and posting a completion - or deferring a retry if it's not ready for issue just yet. > AFAICS, the only copy-in you leave to ->issue() is the data for write > and sendmsg and ->msg_control for sendmsg. Wait, there's that ioctl-like > mess you've got, so anything that feels like doing (seems to include > at least setsockopt)... Oh, well... Right, things that obviously write to buffers will do that there, as that's the context where the completion happens anyway. The setsockopt parts should just copy out at issue time. -- Jens Axboe
