search for: signal_pend

...ERESTARTSYS. Error code > 27499 corresponds to 0x6b6b, so the rq_errno field seems to be the only > one being set after freeing the slab. > > In smb_add_request (which is the only place in smbfs where I found > ERESTARTSYS), I found the following: > > if (!timeleft || signal_pending(current)) { > /* > * On timeout or on interrupt we want to try and remove the > * request from the recvq/xmitq. > */ > smb_lock_server(server); > if (!(req->rq_flags & SMB_...

...; > In this case the main for (;;) loop will spin without sleeping until > > vhost_task_should_stop() becomes true? > > I see. So I either have to be able to call get_signal after SIGKILL or > at this time work like a kthread and ignore signals like a > > if (dead && signal_pending()) > flush_signals() > ? Right now I think that "int dead" should die, and you should simply do get_signal() + clear(SIGPENDING) if signal_pending() == T , but let me think tomorrow. Oleg.

...ker->work_list); if (!node) { schedule(); /* * 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. */ if (signal_pending(current)) { struct ksignal ksig; if (!killed) killed = get_signal(&ksig); clear_thread_flag(TIF_SIGPENDING); } continue; } ------------------------------------------------------------------------------- But let me ask a couple of questions. Let's forget this...

...ernels/4.11.12-100.fc24.x86_64' CC [M] /local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.o /local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.c: In function ?dahdi_ioctl_iomux?: /local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.c:5954:7: error: implicit declaration of function ?signal_pending? [-Werror=implicit-function-declaration] if (signal_pending(current)) { ^~~~~~~~~~~~~~ cc1: some warnings being treated as errors scripts/Makefile.build:294: recipe for target '/local/src/dahdi-linux-master/drivers/dahdi/dahdi-base.o' failed make[2]: *** [/local/src/dahdi-linux...

...tx work, it enters handle_tx(), and enters busyloop without suppression again. This is likely to be repeated, so with event_idx we are almost not able to suppress notification in this case. To fix this, poll the work instead of enabling notification when busypoll is interrupted by something. IMHO signal_pending() and vhost_has_work() are kind of interruptions rather than signals to completely cancel the busypoll, so let's run busypoll after the necessary work is done. In order to avoid too long busyloop due to interruption, save the endtime in vq field and use it when reentering the work function....

...tx work, it enters handle_tx(), and enters busyloop without suppression again. This is likely to be repeated, so with event_idx we are almost not able to suppress notification in this case. To fix this, poll the work instead of enabling notification when busypoll is interrupted by something. IMHO signal_pending() and vhost_has_work() are kind of interruptions rather than signals to completely cancel the busypoll, so let's run busypoll after the necessary work is done. In order to avoid too long busyloop due to interruption, save the endtime in vq field and use it when reentering the work function....

.../char/hw_random/core.c > @@ -195,8 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > > mutex_unlock(&rng_mutex); > > - if (need_resched()) > - schedule_timeout_interruptible(1); > + schedule_timeout_interruptible(10); > > if (signal_pending(current)) { > err = -ERESTARTSYS; > -- > 1.9.3

.../char/hw_random/core.c > @@ -195,8 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > > mutex_unlock(&rng_mutex); > > - if (need_resched()) > - schedule_timeout_interruptible(1); > + schedule_timeout_interruptible(10); > > if (signal_pending(current)) { > err = -ERESTARTSYS; > -- > 1.9.3

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My original was pain, Rusty posted a real fix. This patchset fixed two issue in v1, and tested by my 6+ cases. | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: |

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My original was pain, Rusty posted a real fix. This patchset fixed two issue in v1, and tested by my 6+ cases. | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: |

If we read hwrng by long-running dd process, it takes too much cpu time and almost hold the mutex lock. When we check hwrng attributes from sysfs by cat, it gets stuck in waiting the lock releaseing. The problem can only be reproduced with non-smp guest with slow backend. This patchset resolves the issue by changing rng_dev_read() to always schedule 10 jiffies after release mutex lock, then cat

If we read hwrng by long-running dd process, it takes too much cpu time and almost hold the mutex lock. When we check hwrng attributes from sysfs by cat, it gets stuck in waiting the lock releaseing. The problem can only be reproduced with non-smp guest with slow backend. This patchset resolves the issue by changing rng_dev_read() to always schedule 10 jiffies after release mutex lock, then cat

...-------------------------- /* If we're racing another node to the join, then we * need to back off temporarily and let them * complete. */ #define DLM_JOIN_TIMEOUT_MSECS 90000 if (status == -EAGAIN) { if (signal_pending(current)) { status = -ERESTARTSYS; goto bail; } if (total_backoff > msecs_to_jiffies(DLM_JOIN_TIMEOUT_MSECS)) { status =...

If we read hwrng by long-running dd process, it takes too much cpu time. When we check hwrng attributes from sysfs by cat, it gets stuck. The problem can only be reproduced with non-smp guest with slow backend. This patchset changed hwrng core to always delay 10 jiffies, cat process have chance to execute protected code, the problem is resolved. Thanks. Amos Kong (2): virtio-rng cleanup: move

If we read hwrng by long-running dd process, it takes too much cpu time. When we check hwrng attributes from sysfs by cat, it gets stuck. The problem can only be reproduced with non-smp guest with slow backend. This patchset changed hwrng core to always delay 10 jiffies, cat process have chance to execute protected code, the problem is resolved. Thanks. Amos Kong (2): virtio-rng cleanup: move

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

...e_tx(), and enters busyloop without suppression again. > This is likely to be repeated, so with event_idx we are almost not able > to suppress notification in this case. > > To fix this, poll the work instead of enabling notification when > busypoll is interrupted by something. IMHO signal_pending() and > vhost_has_work() are kind of interruptions rather than signals to > completely cancel the busypoll, so let's run busypoll after the > necessary work is done. In order to avoid too long busyloop due to > interruption, save the endtime in vq field and use it when reentering...

Hi Jason, On 2018/06/29 18:30, Jason Wang wrote: > On 2018?06?29? 16:09, Toshiaki Makita wrote: ... >> To fix this, poll the work instead of enabling notification when >> busypoll is interrupted by something. IMHO signal_pending() and >> vhost_has_work() are kind of interruptions rather than signals to >> completely cancel the busypoll, so let's run busypoll after the >> necessary work is done. In order to avoid too long busyloop due to >> interruption, save the endtime in vq field and use it...

Hi Jason, On 2018/06/29 18:30, Jason Wang wrote: > On 2018?06?29? 16:09, Toshiaki Makita wrote: ... >> To fix this, poll the work instead of enabling notification when >> busypoll is interrupted by something. IMHO signal_pending() and >> vhost_has_work() are kind of interruptions rather than signals to >> completely cancel the busypoll, so let's run busypoll after the >> necessary work is done. In order to avoid too long busyloop due to >> interruption, save the endtime in vq field and use it...

...ita wrote: >> Hi Jason, >> >> On 2018/06/29 18:30, Jason Wang wrote: >>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >> ... >>>> To fix this, poll the work instead of enabling notification when >>>> busypoll is interrupted by something. IMHO signal_pending() and >>>> vhost_has_work() are kind of interruptions rather than signals to >>>> completely cancel the busypoll, so let's run busypoll after the >>>> necessary work is done. In order to avoid too long busyloop due to >>>> interruption, save th...