From nobody Sat Feb 7 06:55:08 2026 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 B123214A91 for ; Wed, 28 Jan 2026 07:02:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769583761; cv=none; b=qTC2XPTq4omND9X6FLH1PloNPwZlgFLqSxpRnaTAGmgLwFlltyaMjIygOYpkJgh7UvEofilEvCRaJMxYPorlyRqA8a718nqzj1A0rdg8D8BCBJbJapWWo3+yDaj9nT9arwE4Fuc3ocCGxoPnzoGkE1nLDKDBkf9Yt/cAdaPNn0M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769583761; c=relaxed/simple; bh=jNWVs3NoJCDLt3Uob6MZkTWfmT/4JmZ5ZegDFFtHMQ8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=XSrlQ8AyEQiJSbmu1727DZuajn0fvaTWQ3T0bh1Mbj9QBru1bLVH1UybEsVcv+VcAwBt5YRtxmSgugQsiXvv4TTk+afMPUUKa8tH5aGDuZ8mF2X8iwFlCwZfLQ4K0hr2800WxsLfLJlKEfo//J759CwSFHl2AaRJOJQGfzbEoUA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=Eu/btvwj; arc=none smtp.client-ip=209.85.214.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Eu/btvwj" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-29f30233d8aso43696805ad.0 for ; Tue, 27 Jan 2026 23:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1769583759; x=1770188559; 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=zpz1+E5bIfL6Vl+vGItOAAFJ78Sq/brE0PF9AQXfuD0=; b=Eu/btvwjDHWSVkM9sBMw1iYxgv4q/mCO7Cw+OEWWYn2R9r5ftSc8DJ4Zsx+LGvcBM9 +nfPnxxJETpAAKIx6p2eYeI5qqEO/fgie7iWQwsITNKGv3DW1SUF8lmPFHc52nWdZ4ZS eLCJcB3xtHYc4uz9gNZQmv5pfyjMpXzC5cpBs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769583759; x=1770188559; 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=zpz1+E5bIfL6Vl+vGItOAAFJ78Sq/brE0PF9AQXfuD0=; b=uL+cEPY3twbNKhqYxac1KgyHDFsJ0PgXKsRrUyMXrWhgctfXqqbE9Ve6kdx9RFLQpa T6CwvoVr9BBJVsDzfl+ZR19deFUOds0NEEgW/eST57UteU22b641H35hwUeECn/eATz2 Mt5wHllktEtsJsk6lC4HVMLuYDXlt9eVJvLBp8eHPpiyBjqsksYgGKmw2tULmT6KZ0ov B5MUbzZwRk0+WCc1WITQRhB69JS3uEeOOvqDYOLuc1Lipq3a0JlGNkpKCh0s6hWzO9/0 eVgwF5ebeiFzRQ5i+KViaavOu3srETBGYWU/9U8pw9mQgSXpYsO45ifvXHB827q5YQcz hVRg== X-Forwarded-Encrypted: i=1; AJvYcCVLlO+tSsN2ee9tfbrz1fH0gVW+UE4u2g0awpb8eEUlMdBHGsL/g1bz816uTCRjNCKrInYUHFBvYkBSj00=@vger.kernel.org X-Gm-Message-State: AOJu0YzeoPmRL9O9C5P0KAb3Dq9K8zd49+jXJUN2JRaDK8bhXrx6JrID tCHjT2SdI1MZA7O4RUvylzZ6c6wxtMM7LGVm3nG1jCmoz0ioKQl8YT63pOK4HtBKW30sV6a/l0+ TbSo= X-Gm-Gg: AZuq6aKnVKSbiouSAHIuW519F+6NKAIwqX8TkVD50bkqQgbU6YV+s9fxJjf33E/9tvO 94ONHImCNcZPb57bPz/A8Z8XVY/mP1E9dhEdFcU979Hh9Sz/f39bsC3Cw0A+VlJxRD/FcUYq+T7 zRtn6c4UNsY8rOSDB3UYv+vdbYpDX+VY5cuUYIsOF7960e13kMjZ5Stbo0LSDnT8/RqM4/ItENh vC7tvWxIhSgjkr7svePNjZJyzBsGujpNsSbqlv361F/yQ32hs2PDNCv9ITMFx08HEN1OtYU/hpl 2jlzj1cnV7vmtU6nZDwHo1T3jb6XjMWAqcv+3QRPSDLHXV8/oytv+FeN2CEWC1bBkxE2673yhKR hY/FayID2gkwgI+LLbmfAU60MwmNHIhMF/a5CGi/nNF76gsFsEGvz7kWGdopZ+wusUManeNggil p19sM1UDwFt5ac5MGLs/3ef0DxRfrSHqSGsPJGVzwpTNLBY9HD30ny3vl/9isug4m6ixf1gV8g X-Received: by 2002:a17:903:40ca:b0:2a0:f0db:690e with SMTP id d9443c01a7336-2a870e8ac0bmr41142995ad.52.1769583758569; Tue, 27 Jan 2026 23:02:38 -0800 (PST) Received: from tigerii.tok.corp.google.com ([2a00:79e0:2031:6:bf24:413d:1e8a:6aa]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a88b3eedd0sm12975735ad.3.2026.01.27.23.02.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jan 2026 23:02:37 -0800 (PST) From: Sergey Senozhatsky To: Paolo Abeni , Jakub Kicinski , Eric Dumazet , "David S. Miller" , Andrew Lunn Cc: Douglas Anderson , Tomasz Figa , linux-usb@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: [PATCH] net: usb: r8152: fix resume reset deadlock Date: Wed, 28 Jan 2026 16:01:52 +0900 Message-ID: <20260128070222.3393746-1-senozhatsky@chromium.org> X-Mailer: git-send-email 2.53.0.rc1.225.gd81095ad13-goog 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" rtl8152 can trigger device reset during reset which potentially can result in a deadlock: **** DPM device timeout after 10 seconds; 15 seconds until panic **** Call Trace: schedule+0x483/0x1370 schedule_preempt_disabled+0x15/0x30 __mutex_lock_common+0x1fd/0x470 __rtl8152_set_mac_address+0x80/0x1f0 dev_set_mac_address+0x7f/0x150 rtl8152_post_reset+0x72/0x150 usb_reset_device+0x1d0/0x220 rtl8152_resume+0x99/0xc0 usb_resume_interface+0x3e/0xc0 usb_resume_both+0x104/0x150 usb_resume+0x22/0x110 The problem is that rtl8152 resume calls reset under tp->control mutex while reset basically re-enters rtl8152 and attempts to acquire the same tp->control lock once again. Reset INACCESSIBLE device outside of tp->control mutex scope to avoid recursive mutex_lock() deadlock. Fixes: 4933b066fefb ("r8152: If inaccessible at resume time, issue a reset") Signed-off-by: Sergey Senozhatsky Reviewed-by: Douglas Anderson --- drivers/net/usb/r8152.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 30f937527cd2..c4f4e6a35ff4 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -8538,19 +8538,6 @@ static int rtl8152_system_resume(struct r8152 *tp) usb_submit_urb(tp->intr_urb, GFP_NOIO); } =20 - /* If the device is RTL8152_INACCESSIBLE here then we should do a - * reset. This is important because the usb_lock_device_for_reset() - * that happens as a result of usb_queue_reset_device() will silently - * fail if the device was suspended or if too much time passed. - * - * NOTE: The device is locked here so we can directly do the reset. - * We don't need usb_lock_device_for_reset() because that's just a - * wrapper over device_lock() and device_resume() (which calls us) - * does that for us. - */ - if (test_bit(RTL8152_INACCESSIBLE, &tp->flags)) - usb_reset_device(tp->udev); - return 0; } =20 @@ -8661,6 +8648,7 @@ static int rtl8152_suspend(struct usb_interface *intf= , pm_message_t message) static int rtl8152_resume(struct usb_interface *intf) { struct r8152 *tp =3D usb_get_intfdata(intf); + bool system_resume =3D !test_bit(SELECTIVE_SUSPEND, &tp->flags); int ret; =20 mutex_lock(&tp->control); @@ -8674,6 +8662,19 @@ static int rtl8152_resume(struct usb_interface *intf) =20 mutex_unlock(&tp->control); =20 + /* If the device is RTL8152_INACCESSIBLE here then we should do a + * reset. This is important because the usb_lock_device_for_reset() + * that happens as a result of usb_queue_reset_device() will silently + * fail if the device was suspended or if too much time passed. + * + * NOTE: The device is locked here so we can directly do the reset. + * We don't need usb_lock_device_for_reset() because that's just a + * wrapper over device_lock() and device_resume() (which calls us) + * does that for us. + */ + if (system_resume && test_bit(RTL8152_INACCESSIBLE, &tp->flags)) + ret =3D usb_reset_device(tp->udev); + return ret; } =20 --=20 2.53.0.rc1.225.gd81095ad13-goog