Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3663920pxv; Mon, 26 Jul 2021 08:59:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOBY0KuL/DVZdp5URzDNJO2pz1ONrT9WjrGlucYPISJejwxNXDh9D1yrKFHthNj4vlb+kF X-Received: by 2002:a17:907:94c6:: with SMTP id dn6mr6960130ejc.287.1627315168307; Mon, 26 Jul 2021 08:59:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627315168; cv=none; d=google.com; s=arc-20160816; b=n7N1VdJsXsfODyjhcfVwpYFL6BFmpVvJ5rcVA697faR3Nkip5T2ClrHYE0QFSemfAp IcaCrebflY5qsFOBJmM/d0kbca2bbq7bkadc3wPne7sl1TNCvasypNVREt7P8dGDUhAC xLLt/VgKFYlBf9Gr9ME5NXqqJNo90Ioz68l++bpTSDR+iNmBCvyfSRJPLeHvxMUQMAyQ ib6PWCnlTyZhNRCReURI57NCUCT/h82Umkauz0vhSXexwBQqV5yOypfiLAbieeGPvIMy mybaHZ/JqBFCc0REq+VYhewlCklmNVTF4HImBkYwuGKVBQOWb9G2hxrXtK/8edZomYKx Y5YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=fVkRPXjffrv+h4FNRt1zUI6iwXy68QwtsDn0ouV4RrE=; b=tSSic+DLVv6P4d1zXAcozeeRftXiWTrykJfR6TFD1t9bEUasaeJQs0W0E08faQGvRB TPU7w5TJNniITwhnM9+3EOh5ntI0+tv1FCiPxIPUAWth1U0l2Rk2MNXK6zjEbDhg0gnn gcIvDMDkKzCmzc+D9lW9jtmCY+YeWe6b5oFxIwORkZOEAfXK34v7iDNCamGXhNFa+SDt DcFNYBtcuPWQGRMP1F3ZbzbmnMejhTyUqMCW2rX0d4y6B0InBUe6EhK2KG3Z8zZUlYne Lv4HsyTJgt8b2na1EVyDGCAoBr9zZf+leunEEvTRsOQtyOm//G2gZ4Dt6flyHP2BAi2D 4wEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ycWeW3VJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id du10si250980ejc.723.2021.07.26.08.59.02; Mon, 26 Jul 2021 08:59:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ycWeW3VJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235943AbhGZPQu (ORCPT + 99 others); Mon, 26 Jul 2021 11:16:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:48898 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236287AbhGZPJI (ORCPT ); Mon, 26 Jul 2021 11:09:08 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 30F3860525; Mon, 26 Jul 2021 15:48:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627314536; bh=IEETQmr9IcWo+1HLEfFLNUl30/jL3cZ8Ubi5fDGAnls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ycWeW3VJj0/xrMVJSo2Wec3bWBSEW8ghMNXyy/68yItBU7nqzU5Qq8GyuKdXszAXL DEJ0AnRoQAmntDHwzqpyVhrdhWjba1c2SoTIfnVnELl33J1VPOjJSYsg0290l+cAxn YRUqjJKHylHFuE3nhO1aMa7BZFxvJf1qm7HSkyR0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mathias Nyman Subject: [PATCH 4.14 62/82] xhci: Fix lost USB 2 remote wake Date: Mon, 26 Jul 2021 17:39:02 +0200 Message-Id: <20210726153830.187907539@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210726153828.144714469@linuxfoundation.org> References: <20210726153828.144714469@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mathias Nyman commit 72f68bf5c756f5ce1139b31daae2684501383ad5 upstream. There's a small window where a USB 2 remote wake may be left unhandled due to a race between hub thread and xhci port event interrupt handler. When the resume event is detected in the xhci interrupt handler it kicks the hub timer, which should move the port from resume to U0 once resume has been signalled for long enough. To keep the hub "thread" running we set a bus_state->resuming_ports flag. This flag makes sure hub timer function kicks itself. checking this flag was not properly protected by the spinlock. Flag was copied to a local variable before lock was taken. The local variable was then checked later with spinlock held. If interrupt is handled right after copying the flag to the local variable we end up stopping the hub thread before it can handle the USB 2 resume. CPU0 CPU1 (hub thread) (xhci event handler) xhci_hub_status_data() status = bus_state->resuming_ports; handle_port_status() spin_lock() bus_state->resuming_ports = 1 set_flag(HCD_FLAG_POLL_RH) spin_unlock() spin_lock() if (!status) clear_flag(HCD_FLAG_POLL_RH) spin_unlock() Fix this by taking the lock a bit earlier so that it covers the resuming_ports flag copy in the hub thread Cc: Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210715150651.1996099-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/xhci-hub.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -1450,11 +1450,12 @@ int xhci_hub_status_data(struct usb_hcd * Inform the usbcore about resume-in-progress by returning * a non-zero value even if there are no status changes. */ + spin_lock_irqsave(&xhci->lock, flags); + status = bus_state->resuming_ports; mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC | PORT_CEC; - spin_lock_irqsave(&xhci->lock, flags); /* For each port, did anything change? If so, set that bit in buf. */ for (i = 0; i < max_ports; i++) { temp = readl(port_array[i]);