linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Mike Christie <michael.christie@oracle.com>,
	linux@leemhuis.info, nicolas.dichtel@6wind.com, axboe@kernel.dk,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, mst@redhat.com,
	sgarzare@redhat.com, jasowang@redhat.com, stefanha@redhat.com,
	brauner@kernel.org
Subject: Re: [CFT][PATCH v3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression
Date: Sun, 11 Jun 2023 15:27:37 -0500	[thread overview]
Message-ID: <87o7llycau.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20230606193907.GB18866@redhat.com> (Oleg Nesterov's message of "Tue, 6 Jun 2023 21:39:07 +0200")

Oleg Nesterov <oleg@redhat.com> 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-86b37014c69c@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

  parent reply	other threads:[~2023-06-11 20:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01 18:32 [PATCH 1/1] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression Mike Christie
2023-06-01 19:11 ` Michael S. Tsirkin
2023-06-02  0:43 ` Eric W. Biederman
2023-06-02 14:34 ` Nicolas Dichtel
2023-06-02 19:22 ` Oleg Nesterov
2023-06-03  3:44   ` Eric W. Biederman
2023-06-05 13:26     ` Oleg Nesterov
2023-06-03  4:15   ` [CFT][PATCH v3] " Eric W. Biederman
2023-06-04  3:28     ` michael.christie
2023-06-05 15:10       ` Oleg Nesterov
2023-06-05 15:46         ` Mike Christie
2023-06-06 12:16           ` Oleg Nesterov
2023-06-06 15:57             ` Mike Christie
2023-06-06 19:39               ` Oleg Nesterov
2023-06-06 20:38                 ` Mike Christie
2023-06-14  6:02                   ` Can vhost translate to io_uring? Eric W. Biederman
2023-06-14  6:25                     ` michael.christie
2023-06-14 14:30                       ` Jens Axboe
2023-06-14 17:59                       ` Mike Christie
2023-06-14 14:20                     ` Michael S. Tsirkin
2023-06-14 15:02                     ` Michael S. Tsirkin
2023-06-11 20:27                 ` Eric W. Biederman [this message]
2023-06-14 17:08                   ` [CFT][PATCH v3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression Oleg Nesterov
2023-06-05 12:38     ` Oleg Nesterov
2023-06-05 13:48 ` [PATCH 1/1] " Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7llycau.fsf@email.froward.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --cc=michael.christie@oracle.com \
    --cc=mst@redhat.com \
    --cc=nicolas.dichtel@6wind.com \
    --cc=oleg@redhat.com \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).