virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: michael.christie@oracle.com
Cc: axboe@kernel.dk, brauner@kernel.org, mst@redhat.com,
	linux-kernel@vger.kernel.org, linux@leemhuis.info,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	stefanha@redhat.com, nicolas.dichtel@6wind.com,
	virtualization@lists.linux-foundation.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression
Date: Mon, 29 May 2023 19:46:46 +0200	[thread overview]
Message-ID: <20230529174646.GB15193@redhat.com> (raw)
In-Reply-To: <022f4de6-9eae-0a94-0f55-b84be4982fc3@oracle.com>

Mike, sorry, I don't understand your email.

Just in case, let me remind I know nothing about drivers/vhost/

On 05/29, michael.christie@oracle.com wrote:
>
> On 5/29/23 6:19 AM, Oleg Nesterov wrote:
> > On 05/27, Eric W. Biederman wrote:
> >>
> >> Looking forward I don't see not asking the worker threads to stop
> >> for the coredump right now causing any problems in the future.
> >> So I think we can use this to resolve the coredump issue I spotted.
> >
> > But we have almost the same problem with exec.
> >
> > Execing thread will wait for vhost_worker() while vhost_worker will wait for
> > .release -> vhost_task_stop().
>
> For this type of case, what is the goal or correct behavior in the end?
>
> When get_signal returns true we can code things like you mention below

and you have mentioned in the next email that you have already coded something
like this, so perhaps we can delay the further discussions until you send the
new code?

> and
> clean up the task_struct.

Hmm... If we you CLONE_THREAD the exiting vhost_worker() will auto-reap itself,

> However, we now have a non-functioning vhost device
> open and just sitting around taking up memory and it can't do any IO.

can't comment, see above.

> For this type of case, do we expect just not to crash/hang, or was this new
> exec'd thread suppose to be able to use the vhost device?

I just tried to point out that (unless I missed something) there are more corner
cases, not just coredump.

> > Or suppose that vhost_worker's sub-thread forks a child with CLONE_FILES...
>
> You mean the vhost_task's task/thread doing a function that does a copy_process
> right?

I meant that the vhost_task's sub-thread can do sys_clone(CLONE_FILES) from
userspace. Yes, this implies copy_process() but I still can't understand you.

> That type of thing is not needed.

Do you mean that userspace should never do this? But this doesn't matter, the
kernel should handle this case anyway.

Or what?

In short let me repeat that I don't understand you and - of course! - quite
possibly I missed something.

Oleg.

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2023-05-29 17:49 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22  2:51 [PATCH 0/3] vhost: Fix freezer/ps regressions Mike Christie
2023-05-22  2:51 ` [PATCH 1/3] signal: Don't always put SIGKILL in shared_pending Mike Christie
2023-05-23 15:30   ` Eric W. Biederman
2023-05-22  2:51 ` [PATCH 2/3] signal: Don't exit for PF_USER_WORKER tasks Mike Christie
2023-05-22  2:51 ` [PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression Mike Christie
2023-05-22 12:30   ` Oleg Nesterov
2023-05-22 17:00     ` Mike Christie
2023-05-22 17:47       ` Oleg Nesterov
2023-05-23 12:15         ` Oleg Nesterov
2023-05-23 15:57           ` Eric W. Biederman
2023-05-24 14:10             ` Oleg Nesterov
2023-05-24 14:44               ` Eric W. Biederman
2023-05-25 11:55                 ` Oleg Nesterov
2023-05-25 15:30                   ` Eric W. Biederman
2023-05-25 16:20                     ` Linus Torvalds
2023-05-27  9:49                       ` Eric W. Biederman
2023-05-27 16:12                         ` Linus Torvalds
2023-05-28  1:17                           ` Eric W. Biederman
2023-05-28  1:21                             ` Linus Torvalds
2023-05-29 11:19                             ` Oleg Nesterov
2023-05-29 16:09                               ` michael.christie
2023-05-29 17:46                                 ` Oleg Nesterov [this message]
2023-05-29 17:54                                   ` Oleg Nesterov
2023-05-29 19:03                                     ` Mike Christie
2023-05-29 19:35                                   ` Mike Christie
2023-05-29 19:46                                     ` michael.christie
2023-05-30  2:48                                       ` Eric W. Biederman
2023-05-30  2:38                                 ` Eric W. Biederman
2023-05-30 15:34                                   ` Mike Christie
2023-05-31  3:30                                   ` Mike Christie
2023-05-29 16:11                               ` michael.christie
     [not found]                               ` <20230530-autor-faxnummer-01e0a31c0fb8@brauner>
2023-05-30 17:55                                 ` Oleg Nesterov
2023-05-30 15:01                         ` Eric W. Biederman
2023-05-31  5:22             ` Jason Wang
2023-05-24  0:02           ` Mike Christie
2023-05-25 16:15           ` Mike Christie
2023-05-28  1:41             ` Eric W. Biederman
2023-05-28 19:29               ` Mike Christie
2023-05-31  5:22           ` Jason Wang
2023-05-31  7:25             ` Oleg Nesterov
2023-05-31  8:17               ` Jason Wang
2023-05-31  9:14                 ` Oleg Nesterov
2023-06-01  2:44                   ` Jason Wang
2023-06-01  7:43                     ` Oleg Nesterov
2023-06-02  5:03                       ` Jason Wang
2023-06-02 17:58                         ` Oleg Nesterov
2023-06-02 20:07                           ` Linus Torvalds
2023-06-05 14:20                             ` Oleg Nesterov
2023-05-22 19:40   ` Michael S. Tsirkin
2023-05-23 15:39     ` Eric W. Biederman
2023-05-23 15:48     ` Mike Christie

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=20230529174646.GB15193@redhat.com \
    --to=oleg@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.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=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).