From nobody Fri Apr 10 01:07:27 2026 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 25C19331A7B for ; Wed, 4 Mar 2026 15:58:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772639887; cv=none; b=YvpMF86e1ynrsOxEAy8yhlXyXyGfxmLJPMkeZA/ysg7fmnnZv6304IAIKXpfAVYWfuUc+YeVfFpN/1G5HpAajA3dAksHGKaQVDcO8UI6DESAWGsmR5CnN3ZvQVELvemtk67SSe8a47cGdIqwgOzU4O8Xy86mGyB/AWrWliAPa2s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772639887; c=relaxed/simple; bh=mPXwZWa4eHz0YL3YTSq6W6+iPPLg7SeIK3t2yr84HCg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=hZlFQNA9zi7GKzD9TOVz2Ux2+ekrFrDO5/0YSUM4mplv2quhUcD3VhEInEzOwd3qRIMU1H7XFlCY8KilicOgT/eKPlDvNJG+897Z5zi1tSfFapOSjI/ncneFAjykBba8KMgT/fN7WjKnLgjPzJ6oSOA1MBi78NZROvK6kNsfuzs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PlLIigVp; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PlLIigVp" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-439b6d9c981so2393238f8f.1 for ; Wed, 04 Mar 2026 07:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772639884; x=1773244684; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=9+/LHtNh7an4h28r1sY/9YG7bYLPolTGox4UZl5BWIM=; b=PlLIigVpWDllFdvaVf4UYeD1oAu8eFR3DGBgb28h9rLwEOnkaaJiScO/BJ/L3ibjWB W9MoWXxe6uzf+TM4MfBLwuPhan0jK3/gH2885fctsAjvWqxzDYIJr+9NwFKZwKKUGDPW O1PRU/KugGG//QPeHgFFEsQN+6h/vwEW3+HetKLPk+GiFIJRoJNT7rz7zbO5fepBCjwo oVtGy+CQvQ5zJaetmoYCpxsJJcwXs/HtBou8e8FRTJ0YOYBQElW8y2iWLiB3pHGiVXhF p5NbqS3vT1WJy56gbQm63t1oZI0w0avFcGWlb+a/lOz/5orVW899hL7UwOm9nxxkMeZF DG7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772639884; x=1773244684; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9+/LHtNh7an4h28r1sY/9YG7bYLPolTGox4UZl5BWIM=; b=islUtScv1w3nWSy1091y9wL5ruPkPD7pNvrIYfB9wkoectWWlBlO9eiHLtjX3JlQgw t3Lp96KD0/AwX5I6iVnGd063fw8WN/7Z5hA2v02p2rDtoPJ/Ake1ILXzzcPKjSeZgko0 QNs4lGbyCR1vh8/ubzw1qRF3Jnk7NEiXGrbqfv1wo6xmBM6YQOkeZwnTjsNXlxxMbT3d p+hN1MVqHiNa703fyMe58t/uuJXlFJiMNWC03fCAgh6abWX/yubsEXlw+H+ivLJlT2tz uDirUZA3AHlAXCC4b/DwmW0U6VWO0EVAhVRdhOmVM0EZSHF0wOSwqbP5600gnLw+694K 1ylg== X-Forwarded-Encrypted: i=1; AJvYcCWmrRIhYaMrMy1d0MWL6sZgktBpUMIFL97jMOSYixi5wtRbuxbjo84C8TxatSx1DrhU64lmc80klRubRLM=@vger.kernel.org X-Gm-Message-State: AOJu0YxJ6KxVBXFXHUtU/TEmfg15iLdnB7D3N+zHx/I5e9CSKIsjk8/0 uNUBcjc0SxNEj3TtlEKnua7G/zSdrgf87TG9vnkuMb7rT2q1Ztg3bcmG X-Gm-Gg: ATEYQzy8hS40L33c7ScH8TKQgt1AqbgoF/54b9P/F5nW6BbmZh3dxMRC0O9odfP4/LK 2bKPn6lnyrFS7fYpEvi7e8ypgn6aAPkfARixslW1nr63Yv3vQbD8+hIa8skjs+rmSyx4ZBY/dVb R8tZhktvwr/3gk8MijVv848cwO+NpXVqrILzLP7igpywzHhGikotluqU9BJVs+STcbE8cg2lUPW nmkE0/bfwRYI+hGvfRKsDZEG9fNYZGNsuey39UyXay3rruxn5GTjvaO6vqQb/fVCTMFqHvFwWX3 xZyqj4ii3PT+k4JHzT6KlYBxL2pJ77rLf2nKiohr0ogZ95OquF3O5Ojn52QM/THQwHKAgWSugP6 gjzwKbDtKxtu4Hv4IaWHc4fV75B0CVcMctfU6EqRkv7+R0wDc1+5r+4GBJdYXDsmxIx4XMA+15p qYrx9OzgIbZ0J9JYunt1X/pzpNMZMetDKsRg== X-Received: by 2002:a05:6000:2302:b0:439:bb42:dbde with SMTP id ffacd0b85a97d-439c8ad48dfmr4505539f8f.23.1772639884340; Wed, 04 Mar 2026 07:58:04 -0800 (PST) Received: from fedora-dev ([2a01:5a8:304:153c:d983:1bac:a686:ee59]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439abdf5430sm33027380f8f.5.2026.03.04.07.58.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 07:58:03 -0800 (PST) From: "Nikola Z. Ivanov" To: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, enelsonmoore@gmail.com, kees@kernel.org, oneukum@suse.com, n.zhandarovich@fintech.ru Cc: linux-usb@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Nikola Z. Ivanov" , syzbot+48dc1e8dfc92faf1124c@syzkaller.appspotmail.com Subject: [PATCH net] net: usb: aqc111: Do not perform PM inside runtime suspend callback Date: Wed, 4 Mar 2026 17:57:34 +0200 Message-ID: <20260304155734.110734-1-zlatistiv@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" syzbot reports "task hung in rpm_resume" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status =3D=3D RPM_SUSPE= NDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will nev= er happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants in the case where we are inside a runtime suspend call. Reported-by: syzbot+48dc1e8dfc92faf1124c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D48dc1e8dfc92faf1124c Fixes: e58ba4544c77 ("net: usb: aqc111: Add support for wake on LAN by MAGI= C packet") Signed-off-by: Nikola Z. Ivanov --- This patch is untested! I do not have access to a real device to test it, testing on real hardware would be appreciated, if anyone has a device laying around. I have found no reason for the PM variants to be used in the ->suspend callback when it comes to the device driver. The PM docs suggest that PM should not be done during runtime suspend, but I cannot find a definitive answer for system suspend, hence the conditional if(PMSG_IS_AUTO(message)) drivers/net/usb/aqc111.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/drivers/net/usb/aqc111.c b/drivers/net/usb/aqc111.c index cbffa9ae1bb6..2f0d66c7ade0 100644 --- a/drivers/net/usb/aqc111.c +++ b/drivers/net/usb/aqc111.c @@ -1395,14 +1395,27 @@ static int aqc111_suspend(struct usb_interface *int= f, pm_message_t message) aqc111_write16_cmd_nopm(dev, AQ_ACCESS_MAC, SFR_MEDIUM_STATUS_MODE, 2, ®16); =20 - aqc111_write_cmd(dev, AQ_WOL_CFG, 0, 0, - WOL_CFG_SIZE, &wol_cfg); - aqc111_write32_cmd(dev, AQ_PHY_OPS, 0, 0, - &aqc111_data->phy_cfg); + if (PMSG_IS_AUTO(message)) { + aqc111_write_cmd_nopm(dev, AQ_WOL_CFG, 0, 0, + WOL_CFG_SIZE, &wol_cfg); + aqc111_write32_cmd_nopm(dev, AQ_PHY_OPS, 0, 0, + &aqc111_data->phy_cfg); + } else { + aqc111_write_cmd(dev, AQ_WOL_CFG, 0, 0, + WOL_CFG_SIZE, &wol_cfg); + aqc111_write32_cmd(dev, AQ_PHY_OPS, 0, 0, + &aqc111_data->phy_cfg); + } } else { aqc111_data->phy_cfg |=3D AQ_LOW_POWER; - aqc111_write32_cmd(dev, AQ_PHY_OPS, 0, 0, - &aqc111_data->phy_cfg); + + if (PMSG_IS_AUTO(message)) { + aqc111_write32_cmd_nopm(dev, AQ_PHY_OPS, 0, 0, + &aqc111_data->phy_cfg); + } else { + aqc111_write32_cmd(dev, AQ_PHY_OPS, 0, 0, + &aqc111_data->phy_cfg); + } =20 /* Disable RX path */ aqc111_read16_cmd_nopm(dev, AQ_ACCESS_MAC, --=20 2.53.0