From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7989431F983 for ; Sun, 2 Aug 2026 19:08:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785697704; cv=none; b=DBFH5yPO8NjMtsvv0anvKmKQPBPRw/tiWfzGTLPQxxdGURxFtcfVlhLnVb4hwq1oumH6nA34WWsozJAVg7OnMk+41v/EYC1aTC6Y3SkoDUWS0ZLwaPRkhqJsGQCIotaSvowumSZQSKf/xu7V3Jcw6mzi8Acxre/ihxnSoq0STlo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785697704; c=relaxed/simple; bh=fdafD+f1wymzNcufy3OXoFEK6YXbdBzplnansnGg7M8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=szUAq0Q4EUsh9sJq56c5PIxI5WBSPBLkh/4Xsi6YCU3REAMycOgQ8OD09ubpFleD3b8ZYbKPhBVYZc2GNCyMN6aFyeJ1GWDgV1tJw2C8DMl4Pu0pHSvOuidYcg+pHapT2YOdUY8XyTm+LrHBIwtqPpcR2Ufli3UkZ2YLtBrvhUk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=G3/pTXxW; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=NlSyhjN/; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="G3/pTXxW"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="NlSyhjN/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785697700; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BInnex2CUENRve7TOZngJ+kLiWL4JajzKi2RPRW31mY=; b=G3/pTXxWI2ZVf/qY9TpVd4+8+AnUlE7QHohkXw/2PU3fz9W38ql2Dn6H6k7Z0t3yNXdst2 RACQxGaa07qfLs74bQHHid/HvjEaLMQ8XnZN0pnZ+sTZDDlKIxcrPfS37GEWfz8ajCiLy5 IfO1IvpC3+pwc6o/+Nvj8YtbkOiNoiU= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-458-jL8N_B_COuqGVeEFLF9tQA-1; Sun, 02 Aug 2026 15:08:18 -0400 X-MC-Unique: jL8N_B_COuqGVeEFLF9tQA-1 X-Mimecast-MFC-AGG-ID: jL8N_B_COuqGVeEFLF9tQA_1785697697 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-47f4bff865cso1702020f8f.0 for ; Sun, 02 Aug 2026 12:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1785697697; x=1786302497; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=BInnex2CUENRve7TOZngJ+kLiWL4JajzKi2RPRW31mY=; b=NlSyhjN/9IA9/JUDliNWALPChSDn3KynhSo8nk1ZkZoqybyyDB+Ph3wDZx1pzlKpao +ocSX/BweDHZdTopMcBhfej5WV0u3L0OqyXPGYb6ffrh63WEzeS0ysQZMLrSEZk9pinu beKTnLiO+NEdTzUzIhgZKJfkC0r963FnbMc5EcZ4Zw0ClMBCyKHHIgKaRITveV5HNLvz bW6Y52AKj7hSDl45YgJr8meR31fhLj4mhmzp2W+sB2qvig/uFlQDfUFwQ5dSgzVOPtuw FfWJaSmruYEyud0JaEG2/AFFx/DUUgjdFiHEQ3zLOyayalvt7jkLrJr79JNrS7vgJaoH 7fqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785697697; x=1786302497; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BInnex2CUENRve7TOZngJ+kLiWL4JajzKi2RPRW31mY=; b=FjOObFFmriMwhLznYxeqXaiyiA3kih/neHI72447bsVa/+U3uZi4aHRTQtmj+AJ7wt uA9crLBe/ME4ixdoPxMW8+V8qbwwmlJqBRFQGRMPE+jiRi+nkm9QbmSxRZqApDakVs2L 6BI2G37qcITeA+i9RGvulArZ4M8lXWoB/ENU+fmyEYJmrVz7aGCAss0JbozHLJkr9Oqs 2eT0gzHoyRb5za9Y0IBAEWF0PD0MJNhnjkkFE4NyLYU9i2iA+kTN118lQVJW4wyR1aaW xZm0LKYav7dBEMayypL3vh82gNs1WTbD/XZMEOtjcOVYIZPxEHkw5o8PXOatqnCUQavK kmnw== X-Forwarded-Encrypted: i=1; AHgh+Rre1/dPe/dR5D6T/6NStM4Chyl42jqeigWexFNXlAJ73Nim9wFZ4Ud9oOUtBAToHR4gSRJN99DyYN4P9+U=@vger.kernel.org X-Gm-Message-State: AOJu0Yy3lk/pT60e4dUpN4GaQGi3F9ULnHETHV8tYBl9OmkuGZFf6e3y UUDLuI+Ikof/vaj94orT8VoXT4+AgsAe+0b3XRviwHmbuMuACNiCbejkvddupvgcBOKtE7tshyM Wrz1bEr9Ad/hhgUr5/6uOXS0edmpb17KdmELG9aD0nUitxg0Iju6unzQyRgmd/RYqKQ== X-Gm-Gg: AR+sD12IQqwLHxCQSI+DqPCf5Gtn8L8mNc61Ugdgy+6alapt+P2ZY0gzpOQQ5KCe+TW ngAmW1xssTM/8I9WVO210SO+L7Qr869MfXS88mC2SdcIA4V3cTBMvw/UDnj2V8i1xjqpGJkySpw MAW49NR4iuyntoJLy9SfTVhXzboyxbdqiPg48Il6DM+laFjmwjUPvCm5wcxhK/Ld/UwqWiSlQq9 3/LUehDl1C4gbiw5dQL/wxi/yfNcCY5nM2rpYcXv7/0a2bWf+kl1itcSqAtaX9HppDtV+Kj9XKn Z8aZeKAzuTLZP1xwbcPn/32v8wyTXc2z3hK9nN7ORImdtYpQ+9TLlYtx9g9t813k98dj1mO8xbn AZf1ONmAjGaV389dpSjm8Ig== X-Received: by 2002:a5d:5e86:0:b0:47f:9461:7747 with SMTP id ffacd0b85a97d-47fd72c55camr18142615f8f.20.1785697697209; Sun, 02 Aug 2026 12:08:17 -0700 (PDT) X-Received: by 2002:a5d:5e86:0:b0:47f:9461:7747 with SMTP id ffacd0b85a97d-47fd72c55camr18142566f8f.20.1785697696722; Sun, 02 Aug 2026 12:08:16 -0700 (PDT) Received: from redhat.com (IGLD-80-230-28-14.inter.net.il. [80.230.28.14]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd4068fb7sm26795069f8f.0.2026.08.02.12.08.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Aug 2026 12:08:16 -0700 (PDT) Date: Sun, 2 Aug 2026 15:08:12 -0400 From: "Michael S. Tsirkin" To: Abhin Parekadan Jose Cc: jasowangio@gmail.com, xuanzhuo@linux.alibaba.com, eperezma@redhat.com, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] virtio_pci_modern: fix vp_reset() hang on unresponsive device Message-ID: <20260802145944-mutt-send-email-mst@kernel.org> References: <20260802174059.4082-1-abhinjoses@gmail.com> <20260802134443-mutt-send-email-mst@kernel.org> 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=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Aug 02, 2026 at 06:28:03PM +0000, Abhin Parekadan Jose wrote: > On Sun, Aug 02, 2026 at 01:47:01PM -0400, Michael S. Tsirkin wrote: > > On Sun, Aug 02, 2026 at 05:40:57PM +0000, Abhin Parekadan Jose wrote: > > > While investigating a syzbot report of a WARN_ON_ONCE firing in > > > virtio_dev_remove() [1], > > > > > > And I responded to that syzbot report, and I quote: > > > > So it writes 0 into pci command, effectively killing the device, > > and then is unhappy that the driver prints warnings? > > Who thought it's a good idea? Why? > > I was learning how to reproduce syzbot bugs when I found this > issue by writing 0 to PCI_COMMAND to simulate an unresponsive > device. Yea I have no idea where does this syzbot "bug report" come from. Poking at random at device registers is ... not a very good idea. > While doing that I noticed that echo 1 > /sys/../remove > hung completely rather than just printing the warning. Since the > device_status register lives in the virtio common config MMIO > space and has defined values(based on the bits set) in the spec. > I thought it made sense for virtio to detect this and handle it > gracefully rather than spin forever, so I wrote up a small fix > for that. > > > > I found a related but more serious issue: > > > vp_reset() in the modern virtio-pci transport can hang indefinitely > > > if PCI_COMMAND memory-space decode is disabled while the device is > > > bound (e.g. surprise removal, hardware fault, or -- as reproduced > > > here -- a direct write to the PCI_COMMAND register). The status > > > register poll loop has no way to distinguish "device still resetting" > > > from "device unreachable," so it never terminates. > > > > > > Patch 1 adds a VIRTIO_STATUS_ERROR() check that recognizes an > > > all-ones status read as invalid (per spec, bits 4-5 are reserved and > > > can never legitimately be set) and warns once at the point the bad > > > read actually happens. > > > > > > Patch 2 uses that check to break out of vp_reset()'s poll loop > > > instead of spinning forever. > > > > Was all this including the cover letter written with ai assistance? > > if yes pls disclose this. > > Yes, I used AI assistance (Claude). The commit messages were written > by me and then refined with AI for spelling and grammar; the cover > letter was generated by Claude and reviewed by me. I suggest limiting it to fixing spelling and grammar exclusively. It tends to do things like dramatize, e.g. "more serious issue", like it did here. > The code, testing, > and debugging were done by me -- I reproduced the hang in QEMU, > debugged to reach the hanging loop, and wrote the actual fix. > > I should have disclosed this upfront. I'll do so in future > submissions. > > Do I need to add Assisted-by: Claude to the > commit messages? Assisted-by: Claude:claude-sonnet-4-6 > > P.S. This is my first kernel patch set. Thanks, keep at it. Bonus points if you find a real fix for issues raised in thread about surprise removal, see e.g. here cover.1752094439.git.mst@redhat.com but don't expect it to be easy. -- MST