Displaying 20 results from an estimated 27 matches for "vhost_tasks".
Did you mean:
vhost_task
2023 Mar 22
2
[PATCH 1/1] vhost_task: Fix vhost_task_create return value
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>
---
2023 Jun 01
4
[PATCH 1/1] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression
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 bo...
2023 Jun 02
2
[PATCH 1/1] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression
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/
2023 Mar 21
1
[syzbot] [kernel?] general protection fault in vhost_task_start
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:
2023 Mar 23
2
[PATCH 1/1] vhost_task: Fix vhost_task_create return value
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:
> > >
2023 May 22
3
[PATCH 0/3] vhost: Fix freezer/ps regressions
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 process that did the VHOST_SET_OWNER and uses
get_signal() to handle freeze and SIGSTOP/KILL signals which is required
when using CLONE_THREAD (really CLON...
2023 May 22
2
[PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression
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 add support f...
2023 May 05
1
[PATCH v11 8/8] vhost: use vhost_tasks for worker threads
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 threads of the thing that started
them, not as processes.
So they should show up in
2023 May 05
2
[PATCH v11 8/8] vhost: use vhost_tasks for worker threads
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
2023 Jun 01
0
[RFC PATCH 0/8] vhost_tasks: Use CLONE_THREAD/SIGHAND
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,
2023 Jun 01
0
[RFC PATCH 0/8] vhost_tasks: Use CLONE_THREAD/SIGHAND
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
2023 Jun 01
0
[RFC PATCH 0/8] vhost_tasks: Use CLONE_THREAD/SIGHAND
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
2023 Jun 01
0
[RFC PATCH 0/8] vhost_tasks: Use CLONE_THREAD/SIGHAND
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
2023 Jun 05
1
[PATCH 1/1] vhost: Fix crash during early vhost_transport_send_pkt calls
...v->worker pointer before setting
the worker->vtsk pointer.
4. thread0's vhost_work_queue will see the dev->worker pointer is
set and try to call vhost_task_wake using not yet set worker->vtsk
pointer.
5. We then crash since vtsk is NULL.
Before commit 6e890c5d5021 ("vhost: use vhost_tasks for worker
threads"), we only had the worker pointer so we could just check it to
see if VHOST_SET_OWNER has been done. After that commit we have the
vhost_worker and vhost_task pointers, so we can now hit the bug above.
This patch embeds the vhost_worker in the vhost_dev, so we can just
chec...
2023 Jun 05
1
[PATCH 1/1] vhost: Fix crash during early vhost_transport_send_pkt calls
...v->worker pointer before setting
the worker->vtsk pointer.
4. thread0's vhost_work_queue will see the dev->worker pointer is
set and try to call vhost_task_wake using not yet set worker->vtsk
pointer.
5. We then crash since vtsk is NULL.
Before commit 6e890c5d5021 ("vhost: use vhost_tasks for worker
threads"), we only had the worker pointer so we could just check it to
see if VHOST_SET_OWNER has been done. After that commit we have the
vhost_worker and vhost_task pointers, so we can now hit the bug above.
This patch embeds the vhost_worker in the vhost_dev, so we can just
chec...
2023 Jun 06
1
[PATCH 1/1] vhost: Fix crash during early vhost_transport_send_pkt calls
...setting
>the worker->vtsk pointer.
>4. thread0's vhost_work_queue will see the dev->worker pointer is
>set and try to call vhost_task_wake using not yet set worker->vtsk
>pointer.
>5. We then crash since vtsk is NULL.
>
>Before commit 6e890c5d5021 ("vhost: use vhost_tasks for worker
>threads"), we only had the worker pointer so we could just check it to
>see if VHOST_SET_OWNER has been done. After that commit we have the
>vhost_worker and vhost_task pointers, so we can now hit the bug above.
>
>This patch embeds the vhost_worker in the vhost_dev,...
2023 Jun 06
2
[PATCH 1/1] vhost: Fix crash during early vhost_transport_send_pkt calls
...sk pointer.
>> 4. thread0's vhost_work_queue will see the dev->worker pointer is
>> set and try to call vhost_task_wake using not yet set worker->vtsk
>> pointer.
>> 5. We then crash since vtsk is NULL.
>>
>> Before commit 6e890c5d5021 ("vhost: use vhost_tasks for worker
>> threads"), we only had the worker pointer so we could just check it to
>> see if VHOST_SET_OWNER has been done. After that commit we have the
>> vhost_worker and vhost_task pointers, so we can now hit the bug above.
>>
>> This patch embeds the vhost_...
2023 Jun 06
1
[PATCH 1/1] vhost: Fix crash during early vhost_transport_send_pkt calls
...hread0's vhost_work_queue will see the dev->worker pointer is
> >> set and try to call vhost_task_wake using not yet set worker->vtsk
> >> pointer.
> >> 5. We then crash since vtsk is NULL.
> >>
> >> Before commit 6e890c5d5021 ("vhost: use vhost_tasks for worker
> >> threads"), we only had the worker pointer so we could just check it to
> >> see if VHOST_SET_OWNER has been done. After that commit we have the
> >> vhost_worker and vhost_task pointers, so we can now hit the bug above.
> >>
> >> Thi...
2023 Jun 06
2
[CFT][PATCH v3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression
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
2023 May 31
1
[syzbot] [kvm?] [net?] [virt?] general protection fault in vhost_work_queue
On 5/31/23 10:15 AM, Mike Christie wrote:
>>> rcu would work for your case and for what Jason had requested.
>> Yeah, so you already have some patches?
>>
>> Do you want to send it to solve this problem?
>>
> Yeah, I'll break them out and send them later today when I can retest
> rebased patches.
>
Just one question. Do you core vhost developers