Re: [RFC][BUG] io_uring: fix work corruption for poll_add

[Jens Axboe <axboe@kernel.dk>]

On 7/23/20 4:16 PM, Jens Axboe wrote:
> On 7/23/20 12:12 PM, Pavel Begunkov wrote:
>> poll_add can have req->work initialised, which will be overwritten in
>> __io_arm_poll_handler() because of the union. Luckily, hash_node is
>> zeroed in the end, so the damage is limited to lost put for work.creds,
>> and probably corrupted work.list.
>>
>> That's the easiest and really dirty fix, which rearranges members in the
>> union, arm_poll*() modifies and zeroes only work.files and work.mm,
>> which are never taken for poll add.
>> note: io_kiocb is exactly 4 cachelines now.
> 
> I don't think there's a way around moving task_work out, just like it
> was done on 5.9. The problem is that we could put the environment bits
> before doing task_work_add(), but we might need them if the subsequent
> queue ends up having to go async. So there's really no know when we can
> put them, outside of when the request finishes. Hence, we are kind of
> SOL here.

Actually, if we do go async, then we can just grab the environment
again. We're in the same task at that point. So maybe it'd be better to
work on ensuring that the request is either in the valid work state, or
empty work if using task_work.

Only potential complication with that is doing io_req_work_drop_env()
from the waitqueue handler, at least the ->needs_fs part won't like that
too much.

-- 
Jens Axboe