similar to: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads

The following patches made over Linus's tree fix the 2 bugs: 1. vhost worker task shows up as a process forked from the parent that did VHOST_SET_OWNER ioctl instead of a process under root/kthreadd. This was causing breaking scripts. 2. vhost_tasks didn't disable or add support for freeze requests. The following patches fix these issues by making the vhost_task task a thread under the

On 5/5/23 1:22 PM, Linus Torvalds wrote: > On Fri, May 5, 2023 at 6:40?AM Nicolas Dichtel > <nicolas.dichtel at 6wind.com> wrote: >> >> Is this an intended behavior? >> This breaks some of our scripts. > > It doesn't just break your scripts (which counts as a regression), I > think it's really wrong. > > The worker threads should show up as

On Sun, May 21, 2023 at 09:51:24PM -0500, Mike Christie wrote: > When switching from kthreads to vhost_tasks two bugs were added: > 1. The vhost worker tasks's now show up as processes so scripts doing ps > or ps a would not incorrectly detect the vhost task as another process. > 2. kthreads disabled freeze by setting PF_NOFREEZE, but vhost tasks's > didn't disable or

Hi Mike, sorry, but somehow I can't understand this patch... I'll try to read it with a fresh head on Weekend, but for example, On 06/01, Mike Christie wrote: > > static int vhost_task_fn(void *data) > { > struct vhost_task *vtsk = data; > - int ret; > + bool dead = false; > + > + for (;;) { > + bool did_work; > + > + /* mb paired w/

When switching from kthreads to vhost_tasks two bugs were added: 1. The vhost worker tasks's now show up as processes so scripts doing ps or ps a would not incorrectly detect the vhost task as another process. 2. kthreads disabled freeze by setting PF_NOFREEZE, but vhost tasks's didn't disable or add support for them. To fix both bugs, this switches the vhost task to be thread in the

On Thu, Mar 23, 2023 at 12:50:49PM +0100, Christian Brauner wrote: > On Thu, Mar 23, 2023 at 07:43:04AM -0400, Michael S. Tsirkin wrote: > > On Thu, Mar 23, 2023 at 11:44:45AM +0100, Christian Brauner wrote: > > > On Thu, Mar 23, 2023 at 03:37:19AM -0400, Michael S. Tsirkin wrote: > > > > On Wed, Mar 22, 2023 at 01:56:05PM -0500, Mike Christie wrote: > > >

On 19.05.23 14:15, Christian Brauner wrote: > On Thu, May 18, 2023 at 10:25:11AM +0200, Christian Brauner wrote: >> On Wed, May 17, 2023 at 07:09:12PM -0500, Mike Christie wrote: >>> This patch allows the vhost and vhost_task code to use CLONE_THREAD, >>> CLONE_SIGHAND and CLONE_FILES. It's a RFC because I didn't do all the >>> normal testing,

On 01.06.23 12:47, Christian Brauner wrote: > On Thu, Jun 01, 2023 at 09:58:38AM +0200, Thorsten Leemhuis wrote: >> On 19.05.23 14:15, Christian Brauner wrote: >>> On Thu, May 18, 2023 at 10:25:11AM +0200, Christian Brauner wrote: >>>> On Wed, May 17, 2023 at 07:09:12PM -0500, Mike Christie wrote: >>>>> This patch allows the vhost and vhost_task code to

On 6/1/23 5:47 AM, Christian Brauner wrote: > On Thu, Jun 01, 2023 at 09:58:38AM +0200, Thorsten Leemhuis wrote: >> On 19.05.23 14:15, Christian Brauner wrote: >>> On Thu, May 18, 2023 at 10:25:11AM +0200, Christian Brauner wrote: >>>> On Wed, May 17, 2023 at 07:09:12PM -0500, Mike Christie wrote: >>>>> This patch allows the vhost and vhost_task code to

vhost_task_create is supposed to return the vhost_task or NULL on failure. This fixes it to return the correct value when the allocation of the struct fails. Fixes: 77feab3c4156 ("vhost_task: Allow vhost layer to use copy_process") # mainline only Reported-by: syzbot+6b27b2d2aba1c80cc13b at syzkaller.appspotmail.com Signed-off-by: Mike Christie <michael.christie at oracle.com> ---

On 3/21/23 12:03 PM, syzbot wrote: > RIP: 0010:vhost_task_start+0x22/0x40 kernel/vhost_task.c:115 > Code: 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 53 48 89 fb e8 c3 67 2c 00 48 8d 7b 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0a 48 8b 7b 70 5b e9 fe bd 02 00 e8 79 ec 7e 00 eb > RSP: 0018:ffffc90003a9fc38 EFLAGS: 00010207 > RAX: dffffc0000000000 RBX:

On Thu, Jun 1, 2023 at 6:47?AM Christian Brauner <brauner at kernel.org> wrote: > > @Mike, do you want to prepare an updated version of the temporary fix. > If @Linus prefers to just apply it directly he can just grab it from the > list rather than delaying it. Make sure to grab a Co-developed-by line > on this, @Mike. Yeah, let's apply the known "fix the immediate

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

On 6/6/23 7:16 AM, Oleg Nesterov wrote: > On 06/05, Mike Christie wrote: >> >> On 6/5/23 10:10 AM, Oleg Nesterov wrote: >>> On 06/03, michael.christie at oracle.com wrote: >>>> >>>> On 6/2/23 11:15 PM, Eric W. Biederman wrote: >>>> The problem is that as part of the flush the drivers/vhost/scsi.c code >>>> will wait for

On 05/22, Mike Christie wrote: > > On 5/22/23 7:30 AM, Oleg Nesterov wrote: > >> + /* > >> + * When we get a SIGKILL our release function will > >> + * be called. That will stop new IOs from being queued > >> + * and check for outstanding cmd responses. It will then > >> + * call vhost_task_stop to tell us to return and exit. >

On 06/05, Mike Christie wrote: > > On 6/5/23 10:10 AM, Oleg Nesterov wrote: > > On 06/03, michael.christie at oracle.com wrote: > >> > >> On 6/2/23 11:15 PM, Eric W. Biederman wrote: > >> The problem is that as part of the flush the drivers/vhost/scsi.c code > >> will wait for outstanding commands, because we can't free the device and >

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see the dev->worker pointer is set and

If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we can race where: 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. 3. vhost_worker_create will set the dev->worker pointer before setting the worker->vtsk pointer. 4. thread0's vhost_work_queue will see the dev->worker pointer is set and

On 6/6/23 4:49 AM, Stefano Garzarella wrote: > On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: >> If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we >> can race where: >> 1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue >> 2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. >> 3. vhost_worker_create

On Mon, Jun 05, 2023 at 01:57:30PM -0500, Mike Christie wrote: >If userspace does VHOST_VSOCK_SET_GUEST_CID before VHOST_SET_OWNER we >can race where: >1. thread0 calls vhost_transport_send_pkt -> vhost_work_queue >2. thread1 does VHOST_SET_OWNER which calls vhost_worker_create. >3. vhost_worker_create will set the dev->worker pointer before setting >the worker->vtsk