Christian Borntraeger
2022-Sep-26 12:32 UTC
[PATCH v3 6/6] freezer,sched: Rewrite core freezer logic
Am 26.09.22 um 12:55 schrieb Christian Borntraeger:> > > Am 26.09.22 um 10:06 schrieb Christian Borntraeger: >> >> >> Am 23.09.22 um 09:53 schrieb Christian Borntraeger: >>> Am 23.09.22 um 09:21 schrieb Christian Borntraeger: >>>> Peter, >>>> >>>> as a heads-up. This commit (bisected and verified) triggers a >>>> regression in our KVM on s390x CI. The symptom is that a specific >>>> testcase (start a guest with next kernel and a poky ramdisk, >>>> then ssh via vsock into the guest and run the reboot command) now >>>> takes much longer (300 instead of 20 seconds). From a first look >>>> it seems that the sshd takes very long to end during shutdown >>>> but I have not looked into that yet. >>>> Any quick idea? >>>> >>>> Christian >>> >>> the sshd seems to hang in virtio-serial (not vsock). >> >> FWIW, sshd does not seem to hang, instead it seems to busy loop in >> wait_port_writable calling into the scheduler over and over again. > > -#define TASK_FREEZABLE???????????????? 0x00002000 > +#define TASK_FREEZABLE???????????????? 0x00000000 > > "Fixes" the issue. Just have to find out which of users is responsible.So it seems that my initial test was not good enough. diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 9fa3c76a267f..e93df4f735fe 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -790,7 +790,7 @@ static int wait_port_writable(struct port *port, bool nonblock) if (nonblock) return -EAGAIN; - ret = wait_event_freezable(port->waitqueue, + ret = wait_event_interruptible(port->waitqueue, !will_write_block(port)); if (ret < 0) return ret; Does fix the problem. My initial test was the following --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -790,10 +790,8 @@ static int wait_port_writable(struct port *port, bool nonblock) if (nonblock) return -EAGAIN; - ret = wait_event_freezable(port->waitqueue, + wait_event(port->waitqueue, !will_write_block(port)); - if (ret < 0) - return ret; } /* Port got hot-unplugged. */ if (!port->guest_connected) and obviously it did not provide an exit path.
Peter Zijlstra
2022-Sep-26 12:55 UTC
[PATCH v3 6/6] freezer,sched: Rewrite core freezer logic
On Mon, Sep 26, 2022 at 02:32:24PM +0200, Christian Borntraeger wrote:> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > index 9fa3c76a267f..e93df4f735fe 100644 > --- a/drivers/char/virtio_console.c > +++ b/drivers/char/virtio_console.c > @@ -790,7 +790,7 @@ static int wait_port_writable(struct port *port, bool nonblock) > if (nonblock) > return -EAGAIN; > - ret = wait_event_freezable(port->waitqueue, > + ret = wait_event_interruptible(port->waitqueue, > !will_write_block(port)); > if (ret < 0) > return ret; > > Does fix the problem.It's almost as if someone does try_to_wake_up(.state = TASK_FREEZABLE) -- which would be quite insane. Could you please test with something like the below on? I can boot that with KVM, but obviously I didn't suffer any weirdness to begin with :/ --- diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 4e6a6417211f..ef9ccfc3a8c0 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4051,6 +4051,8 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags) unsigned long flags; int cpu, success = 0; + WARN_ON_ONCE(state & TASK_FREEZABLE); + preempt_disable(); if (p == current) { /*