From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964817AbcHJSoQ (ORCPT ); Wed, 10 Aug 2016 14:44:16 -0400 Received: from mga02.intel.com ([134.134.136.20]:21781 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937722AbcHJSoN (ORCPT ); Wed, 10 Aug 2016 14:44:13 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,497,1464678000"; d="scan'208";a="1038401415" Subject: Re: [PATCH 1/1] usb: misc: usbtest: add fix for driver hang To: Alan Stern , Felipe Balbi References: Cc: Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org From: Lu Baolu Message-ID: <57AAB78F.8030203@linux.intel.com> Date: Wed, 10 Aug 2016 13:11:43 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 08/09/2016 10:18 PM, Alan Stern wrote: > On Tue, 9 Aug 2016, Felipe Balbi wrote: > >> Hi, >> >> Lu Baolu writes: >>> In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling >>> into usb_sg_cancel(). usb_sg_cancel() will do nothing and return >>> directly if req->status has been set to a non-zero value. This will >>> cause driver hang as soon as transfer time out is triggered. > ... > >>> This patch fixes this driver hang. It should be back-ported to stable >>> kernel with version after v3.15. >>> >>> Cc: stable@vger.kernel.org >>> Cc: Alan Stern >>> Signed-off-by: Lu Baolu >>> --- >>> drivers/usb/misc/usbtest.c | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c >>> index 6b978f0..6c6586d 100644 >>> --- a/drivers/usb/misc/usbtest.c >>> +++ b/drivers/usb/misc/usbtest.c >>> @@ -585,7 +585,6 @@ static void sg_timeout(unsigned long _req) >>> { >>> struct usb_sg_request *req = (struct usb_sg_request *) _req; >>> >>> - req->status = -ETIMEDOUT; >>> usb_sg_cancel(req); >>> } >> IMO, req->status = -ETIMEDOUT should still be done, but perhaps after >> usb_sg_cancel(). Alan? > That would race with sg_complete(), perhaps causing a bunch of error > messages. A better approach would be to delete the assignment as > above and then change perform_sglist(): > > usb_sg_wait(req); > - del_timer_sync(&sg_timer); > retval = req->status; > + if (!del_timer_sync(&sg_timer)) > + retval = -ETIMEDOUT; I agree. I will send v2 with this change included. I am afraid that req->status is managed by usb core. A spin lock is used to serialize the change of it. The driver could check the value of req->status, but should not change it (especially change it without the hold of the lock). Otherwise, it could cause race or errors in usb core. This happens in another driver implemented in drivers/mfd/rtsx_usb.c. static void rtsx_usb_sg_timed_out(unsigned long data) { struct rtsx_ucr *ucr = (struct rtsx_ucr *)data; dev_dbg(&ucr->pusb_intf->dev, "%s: sg transfer timed out", __func__); usb_sg_cancel(&ucr->current_sg); /* we know the cancellation is caused by time-out */ ucr->current_sg.status = -ETIMEDOUT; (^^^^ status being changed by driver without hold of lock) } I will send another patch to enhance this later. Best regards, Lu Baolu