Oleg Nesterov writes:
> On 06/06, Mike Christie wrote:
>>
>> On 6/6/23 7:16 AM, Oleg Nesterov wrote:
>> > On 06/05, Mike Christie wrote:
>> >
>> >> So it works like if we were using a kthread still:
>> >>
>> >> 1. Userapce thread0 opens /dev/vhost-$something.
>> >> 2. thread0 does VHOST_SET_OWNER ioctl. This calls vhost_task_create() to
>> >> create the task_struct which runs the vhost_worker() function which
>> >> handles
>> >> the work->fns.
>> >> 3. If userspace now does a SIGKILL or just exits without doing a close()
>> >> on
>> >> /dev/vhost-$something, then when thread0 does exit_files() that will do
>> >> the
>> >> fput that does vhost-$something's file_operations->release.
>> >
>> > So, at least in this simple case vhost_worker() can just exit after
>> > SIGKILL,
>> > and thread0 can flush the outstanding commands when it calls
>> > vhost_dev_flush()
>> > rather than wait for vhost_worker().
>> >
>> > Right?
>>
>> With the current code, the answer is no. We would hang like I mentioned here:
>>
>> https://lore.kernel.org/lkml/ae250076-7d55-c407-1066-86b37014c...@oracle.com/
>
> If only I could fully understand this email ;)
>
> Could you spell to explain why this can't work (again, in this simple case) ?
>
> My current (and I know, very poor) understanding is that .release() should
> roughly do the following:
>
> 1. Ensure that vhost_work_queue() can't add the new callbacks
>
> 2. Call vhost_dev_flush() to ensure that worker->work_list is empty
>
> 3. Call vhost_task_stop()
At least in the case of exec by the time the final fput happens
from close_on_exec the task has already changed it's mm. So the
conditions are wrong to run the work queue items.
For close(2) and SIGKILL perhaps, but definitely not in the case of
exec.
Eric
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
