search for: get_signed

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/

On 05/22, Oleg Nesterov wrote: > > Right now I think that "int dead" should die, No, probably we shouldn't call get_signal() if we have already dequeued SIGKILL. > but let me think tomorrow. May be something like this... I don't like it but I can't suggest anything better right now. bool killed = false; for (;;) { ... node =

Oleg Nesterov <oleg at redhat.com> writes: > On 05/22, Oleg Nesterov wrote: >> >> Right now I think that "int dead" should die, > > No, probably we shouldn't call get_signal() if we have already > dequeued SIGKILL. Very much agreed. It is one thing to add a patch to move do_exit out of get_signal. It is another to keep calling get_signal after that.

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

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 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. >

When get_pending detects the task has been marked to be killed we try to clean up the SIGKLL by doing a sigdelset and recalc_sigpending, but we still leave it in shared_pending. If the signal is being short circuit delivered there is no need to put in shared_pending so this adds a check in complete_signal. This patch was modified from Eric Biederman <ebiederm at xmission.com> original

On 05/23, Eric W. Biederman wrote: > > I want to point out that we need to consider not just SIGKILL, but > SIGABRT that causes a coredump, as well as the process peforming > an ordinary exit(2). All of which will cause get_signal to return > SIGKILL in this context. Yes, but probably SIGABRT/exit doesn't really differ from SIGKILL wrt vhost_worker(). > It is probably not

On (06/14/19 11:50), Sergey Senozhatsky wrote: > dmesg > > nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon > nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] > nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery > nouveau 0000:01:00.0: fifo: channel 5: killed > nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery >

On 2018?03?24? 20:32, syzbot wrote: > syzbot has found reproducer for the following crash on upstream commit > 99fec39e7725d091c94d1bb0242e40c8092994f6 (Fri Mar 23 22:34:18 2018 +0000) > Merge tag 'trace-v4.16-rc4' of > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace > syzbot dashboard link: >

On 5/16/19 10:35 PM, Pankaj Gupta wrote: > Can I take it your reviewed/acked-by? or tested-by tag? for the virtio patch :)I don't feel that I have enough expertise to give the reviewed-by tag, but you can take my acked-by + tested-by. Acked-by: Jakub Staron <jstaron at google.com> Tested-by: Jakub Staron <jstaron at google.com> No kernel panics/stalls encountered during

On 5/16/19 10:35 PM, Pankaj Gupta wrote: > Can I take it your reviewed/acked-by? or tested-by tag? for the virtio patch :)I don't feel that I have enough expertise to give the reviewed-by tag, but you can take my acked-by + tested-by. Acked-by: Jakub Staron <jstaron at google.com> Tested-by: Jakub Staron <jstaron at google.com> No kernel panics/stalls encountered during

On Mon, Sep 30, 2019 at 06:43:50PM +0000, Dexuan Cui wrote: > Lockdep is unhappy if two locks from the same class are held. > > Fix the below warning for hyperv and virtio sockets (vmci socket code > doesn't have the issue) by using lock_sock_nested() when __vsock_release() > is called recursively: > > ============================================ > WARNING: possible

https://bugs.freedesktop.org/show_bug.cgi?id=106080 Bug ID: 106080 Summary: Time-out in `nvkm_fifo_chan_child_fini()` Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Hi Dexuan, On Thu, Sep 26, 2019 at 01:11:27AM +0000, Dexuan Cui wrote: > Lockdep is unhappy if two locks from the same class are held. > > Fix the below warning for hyperv and virtio sockets (vmci socket code > doesn't have the issue) by using lock_sock_nested() when __vsock_release() > is called recursively: > > ============================================ >

5.2.0-rc4-next-20190613 dmesg nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery nouveau 0000:01:00.0: fifo: channel 5: killed nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery nouveau 0000:01:00.0: fifo: engine 0: scheduled for recovery

> On 5/16/19 10:35 PM, Pankaj Gupta wrote: > > Can I take it your reviewed/acked-by? or tested-by tag? for the virtio > > patch :)I don't feel that I have enough expertise to give the reviewed-by > > tag, but you can > take my acked-by + tested-by. > > Acked-by: Jakub Staron <jstaron at google.com> > Tested-by: Jakub Staron <jstaron at google.com>

Adding linux-kselftest at vger.kernel.org for the test config question. On 3/19/20 11:17 AM, Jason Gunthorpe wrote: > On Tue, Mar 17, 2020 at 04:14:31PM -0700, Ralph Campbell wrote: >> >> On 3/17/20 5:59 AM, Christoph Hellwig wrote: >>> On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote: >>>> I've been using v7 of Ralph's tester and it is

Hello Minchan, -next 4.7.0-rc3-next-20160614 [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN [ 315.146576] Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon crc32c_intel r8169 i2c_i801 mii snd_hda_codec_realtek snd_hda_codec_generic