Received: by 10.223.185.116 with SMTP id b49csp818529wrg; Sat, 10 Feb 2018 21:05:31 -0800 (PST) X-Google-Smtp-Source: AH8x224hCxcYQiF9qyxvw5+uYzpKevbmG/x9k5UhsVj85BmDjOmQMnIHt6JYuhdkppXbPnvlISb9 X-Received: by 10.99.113.85 with SMTP id b21mr2350570pgn.305.1518325531383; Sat, 10 Feb 2018 21:05:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518325531; cv=none; d=google.com; s=arc-20160816; b=D86RJz94KdweuiPyXODUPEvkU64UfxNJcneRLYa9D8TrAzmyC/Cr6pG4rbZETkmFCI w0b8n3lbp7xEYRhlu/Icwyf9wkODyzKuzcIPpINP+CMPGDW6fTSk/wOnx7T1c5sAPith eGDK2suCKzY4CH01JMSj18laWH1NUuT55mG/bx5tvEMOhH9kap6zU27FS5NmlhR1qFjj I5aCbsqBINRU6EcZwNA8NKSSmwtyS8PjZRj5/vpgiimh1OXE1n6ZwVucr8P14ITrQ7KZ j0wxaS65u62p3u85AnWLynWTaAsx1+1Lr/6NQrceab4Rtv3ExMs8GMlKetey6CvoKrbk dceA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=bAAQT61YP8gwCQiL5W+0DT7tUYypHv0SDvqgiNBY7IA=; b=ApkcZMlObhu0DEOkEwVYjC30RKKk/hqEQ9Svbj+0osF3SRHo0vvsSz2cVyp5WkNPIg K2PX/xKqY94xedJki0lA3vs3ryaAO2jxaQXIuLUeUVjytpgtiPrQcUBo4XpuAaZ7sepF tvrh6MHN0K+gXjZdhr7HTZhKnK5UiVwU4aPLEP3xKEftjsmcPytnsANcExC/QC+0RilP koMTKUgbOs0ccgWeK7ii82vLKMBopOhibmoJHkAsXkkpgRSzXRxuCLXGJUl0V+FzngWz GtH130D/YHRARL9JTUrVjfLnm6KKFeYGg0xKgFohIHX/futS89vhxj43Uxp/gMrT4iHz MXWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u18si1940086pge.232.2018.02.10.21.05.17; Sat, 10 Feb 2018 21:05:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753837AbeBKFEm (ORCPT + 99 others); Sun, 11 Feb 2018 00:04:42 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41495 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752675AbeBKEdn (ORCPT ); Sat, 10 Feb 2018 23:33:43 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ekjKe-0002hH-OQ; Sun, 11 Feb 2018 04:33:40 +0000 Received: from ben by deadeye with local (Exim 4.90) (envelope-from ) id 1ekjKX-0004U4-Sm; Sun, 11 Feb 2018 04:33:33 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Richard Genoud" , "Stanislaw Gruszka" , "Kalle Valo" Date: Sun, 11 Feb 2018 04:20:06 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.2 33/79] rt2x00usb: mark device removed when get ENOENT usb error In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.2.99-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Stanislaw Gruszka commit bfa62a52cad93686bb8d8171ea5288813248a7c6 upstream. ENOENT usb error mean "specified interface or endpoint does not exist or is not enabled". Mark device not present when we encounter this error similar like we do with ENODEV error. Otherwise we can have infinite loop in rt2x00usb_work_rxdone(), because we remove and put again RX entries to the queue infinitely. We can have similar situation when submit urb will fail all the time with other error, so we need consider to limit number of entries processed by rxdone work. But for now, since the patch fixes reproducible soft lockup issue on single processor systems and taken ENOENT error meaning, let apply this fix. Patch adds additional ENOENT check not only in rx kick routine, but also on other places where we check for ENODEV error. Reported-by: Richard Genoud Debugged-by: Richard Genoud Signed-off-by: Stanislaw Gruszka Tested-by: Richard Genoud Signed-off-by: Kalle Valo [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings --- drivers/net/wireless/rt2x00/rt2x00usb.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/net/wireless/rt2x00/rt2x00usb.c +++ b/drivers/net/wireless/rt2x00/rt2x00usb.c @@ -64,7 +64,7 @@ int rt2x00usb_vendor_request(struct rt2x * -ENODEV: Device has disappeared, no point continuing. * All other errors: Try again. */ - else if (status == -ENODEV) { + else if (status == -ENODEV || status == -ENOENT) { clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags); break; } @@ -311,7 +311,7 @@ static bool rt2x00usb_kick_tx_entry(stru status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC); if (status) { - if (status == -ENODEV) + if (status == -ENODEV || status == -ENOENT) clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags); set_bit(ENTRY_DATA_IO_FAILED, &entry->flags); rt2x00lib_dmadone(entry); @@ -400,7 +400,7 @@ static bool rt2x00usb_kick_rx_entry(stru status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC); if (status) { - if (status == -ENODEV) + if (status == -ENODEV || status == -ENOENT) clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags); set_bit(ENTRY_DATA_IO_FAILED, &entry->flags); rt2x00lib_dmadone(entry);