From nobody Wed Dec 17 04:02:28 2025 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F4F93164B1 for ; Mon, 15 Dec 2025 10:40:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765795245; cv=none; b=Q8kRkr0wSE2PpByWH3UntlK8BuM0K0VrqaSHIBce5RFEEd1vnt69GF2r0v1M9ttE6mmVRIgO//pQL4t/+floo90Wj9UmuWlCtS+NUIMcZpSFZRakEP2aG9k9INTPEf6eRE7arIB8hf6o04USCRu9WHPR4z4NKlAfyWSQFYzOFIA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765795245; c=relaxed/simple; bh=/SxEaFMNo7pFquIiCNEE+7QNb48DDtpf3LMr/IucKtw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=EI+iHrCL7FE9wmY68nam32BqTHmhDFAoigWyPmzTWsFTQqeGnKSGHchfx+jOMEcqelFrjawItRb53/KjqAKE63X1IYifah33HmMs/hMFQ2Xy605W7y1BfiWtzsx515KxYuMFDc1Vvx4AiMH2WV+YVN3sTe9G2CLd3d32qT9YbXo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=isovalent.com; spf=pass smtp.mailfrom=isovalent.com; dkim=pass (2048-bit key) header.d=isovalent.com header.i=@isovalent.com header.b=Z2siKmbE; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=isovalent.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=isovalent.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=isovalent.com header.i=@isovalent.com header.b="Z2siKmbE" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-47775fb6cb4so23012765e9.0 for ; Mon, 15 Dec 2025 02:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent.com; s=google; t=1765795241; x=1766400041; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=XypjIFMPPz3oCrw1uobW8ajykibBtZzwnq44lW9wyhM=; b=Z2siKmbEAovfvAFYb1gQrbvU4mO19Ou658kmAoCobkPDTac3rGsOaCpHp7DJTpUSOP a8qM23r5G46Obvoo7ylHVHKXXjFFMbq+WrrrWbt5wBlhe0AGQankjWehJJ0X6HLL0Plb 1Wnf6EeyT/xW6Zqt5y5Ctodl0FrXUoOnbW127bmTV5XEU8JQySh3o6MrkHNMfH8HJ48H VdvLwxdDcsbmdVQ/TnnIze8yEj2CrCqwvSSWgmk2Rd8arVyYLWynuQctGFCcrinfLDFE 4V/rc9PmLOtipA/V1NjKghHk/G1dTN7OPNwtBaIRer0WiTZ8fGpPN3ttoWP83o7UNOzw uiew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765795241; x=1766400041; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XypjIFMPPz3oCrw1uobW8ajykibBtZzwnq44lW9wyhM=; b=vFSk+HV9WwX6KHQVHnU9elwAPFdv04vdmJCZxAh7lCRAaQSmWQp3MbV1OGY/cHlyfq dr7CStt9KWue/I5ClNC0m/19EMoI6hWJCKA8Z9S+RdbjuVtFdZfTcRfEHhSn7WEfCaFJ qkHiJ/SvYDOTgvJtYbPZFloYIjybjlhNvpvZ23ZZgSJpkhjxLvY2svaI3HQEafa4660h YIHv6sQU7bvU9Qad+paYOQyAN4wiv+EoWc0q5LtrKQJI2YyPDkuxpXKci8AOQbh4gOEa 2vyUycDqN1TMhiqB0eGspr4cYKKvtVlULx7OODmNUb9ZMBPrpBfEcArkbIOPqtNypFcM dCyA== X-Forwarded-Encrypted: i=1; AJvYcCVE5CknmfJ3C/k5vBW/TSA9VVtD7mW+B8ETZXGa5zW0f5WmoJcNhi1OSqUMmRJWZZa1eLkjLmiZ+eN2dx8=@vger.kernel.org X-Gm-Message-State: AOJu0YyVCeJvBj5+RT7cnJg4EuXDtqe9xDKMUEIhLPABKbt2eFs6g+h1 ntLUXqvQaGpk5ZQyPC51eWLQHPyG3uUFl03DHzG45KCyIiNH+JJ4bfpjUQDgseiDOEM= X-Gm-Gg: AY/fxX6QJDOhMSNYCbeufCCumlr+6GmTpOOIK2LJGNt+Z53ILhaZ3+xKmxk9L0xalUY QQd8+jKD6LE6BTV+yBo1U9bvXPv01tvVxSIHASPW9MOb/1CV2lbV6gQt3vaQsIdPTLLhNNRC5pE jWmhsKoDG3j0ERt4wFapgpIgK6DOINHw/HfcBec5cU8DFPY26oXdJcKUGLwjjCZGVLlabFmMwRB C2E7Ezv94gy13bbhyz4TPXoxrV+wxeYhQmfcg9CfTaMp1T0L69D5aAp7/+due3Ef9v2ZgimBeqQ 4KyqzN3Lo6D1DRsDPAYR4bQqIUkOOsMyqfasiafxd30j6zAiTEkepOj8SFcQsTbvox7GCpFKSpl zUNHDGhObt82JF2BlUkpmrhoplQxSnk3wQkcs5h1HsgKiQmoCQdoDXmDxxabV9/n19xtnRYoSaT 5qXZnR7AoIjxtiVZ2iuICpnDhqJvguMz3K4pxgYJko3d2JRQ3njCFH6Fs0r9gTAXh50CgjGUl9F YrwutJhjQw= X-Google-Smtp-Source: AGHT+IFKg33PwsCdfmLQrXSGuuWbN6asFRauDAwGkuKbmzIP0FQVXEdLitzX17zXx3ezt3wX8qRQXw== X-Received: by 2002:a05:600c:3151:b0:45d:dc85:c009 with SMTP id 5b1f17b1804b1-47a8f8c0a52mr118993485e9.10.1765795241347; Mon, 15 Dec 2025 02:40:41 -0800 (PST) Received: from [192.168.1.240] (0.0.6.0.0.0.0.0.0.0.0.0.0.0.0.0.f.f.6.2.a.5.a.7.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:7a5a:26ff::600]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47a8f49da20sm178569895e9.5.2025.12.15.02.40.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Dec 2025 02:40:41 -0800 (PST) From: Lorenz Bauer Date: Mon, 15 Dec 2025 10:40:13 +0000 Subject: [PATCH] virtio: console: fix lost wakeup when device is written and polled Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20251215-virtio-console-lost-wakeup-v1-1-79a5c57815e7@isovalent.com> X-B4-Tracking: v=1; b=H4sIAIzlP2kC/x3MwQqDMAwA0F+RnBdoO+LBXxk7SE23YGmkcToQ/ 93i8V3eAcZV2GDoDqi8iYmWBv/oIH7H8mGUqRmCC+SDJ9ykrqIYtZhmxqy24j7O/FvQJer7SHF 6UoIWLJWT/O/89T7PC4hn8hBsAAAA X-Change-ID: 20251215-virtio-console-lost-wakeup-0f566c5cd35f To: Amit Shah , Arnd Bergmann , Greg Kroah-Hartman Cc: virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Lorenz Bauer X-Mailer: b4 0.14.2 A process issuing blocking writes to a virtio console may get stuck indefinitely if another thread polls the device. Here is how to trigger the bug: - Thread A writes to the port until the virtqueue is full. - Thread A calls wait_port_writable() and goes to sleep, waiting on port->waitqueue. - The host processes some of the write, marks buffers as used and raises an interrupt. - Before the interrupt is serviced, thread B executes port_fops_poll(). This calls reclaim_consumed_buffers() via will_write_block() and consumes all used buffers. - The interrupt is serviced. vring_interrupt() finds no used buffers via more_used() and returns without waking port->waitqueue. - Thread A is still in wait_event(port->waitqueue), waiting for a wakeup that never arrives. The crux is that invoking reclaim_consumed_buffers() may cause vring_interrupt() to omit wakeups. Fix this by making reclaim_consumed_buffers() issue an additional wake up if it consumed any buffers. Signed-off-by: Lorenz Bauer --- As far as I can tell all currently maintained stable series kernels need this commit. I've tested that it applies cleanly to 5.10.247, however wasn't able to build the kernel due to an unrelated link error. Instead I applied it to 5.15.197, which compiled and verified to be fixed. --- drivers/char/virtio_console.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 088182e54debd6029ea2c2a5542d7a28500e67b8..7cd3ad9da9b53a7a570410f1250= 1acc7fd7e3b9b 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -581,6 +581,7 @@ static ssize_t send_control_msg(struct port *port, unsi= gned int event, static void reclaim_consumed_buffers(struct port *port) { struct port_buffer *buf; + bool freed =3D false; unsigned int len; =20 if (!port->portdev) { @@ -589,7 +590,15 @@ static void reclaim_consumed_buffers(struct port *port) } while ((buf =3D virtqueue_get_buf(port->out_vq, &len))) { free_buf(buf, false); + freed =3D true; + } + if (freed) { + /* We freed all used buffers. Issue a wake up so that other pending + * tasks do not get stuck. This is necessary because vring_interrupt() + * will drop wakeups from the host if there are no used buffers. + */ port->outvq_full =3D false; + wake_up_interruptible(&port->waitqueue); } } =20 --- base-commit: d358e5254674b70f34c847715ca509e46eb81e6f change-id: 20251215-virtio-console-lost-wakeup-0f566c5cd35f Best regards, --=20 Lorenz Bauer