Received: by 10.223.176.5 with SMTP id f5csp2889322wra; Thu, 1 Feb 2018 07:35:23 -0800 (PST) X-Google-Smtp-Source: AH8x227Qqk+vjlHwhYSd65wuqbSVPE+TQcDXhoO3kn3JpFGkfrasHqsTKleiw4XDSQZkTAvJetqS X-Received: by 10.99.163.92 with SMTP id v28mr2130715pgn.432.1517499323397; Thu, 01 Feb 2018 07:35:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517499323; cv=none; d=google.com; s=arc-20160816; b=HZv1gc+8CAp5PRajndlqJDMbgNoRqcymGxyAufpnemoLM95kFtfumV3HpqRuqdDi7Y 5iIjzftxoFkZnyXwyMfbQ3vFwLm4I42mTZC7Fw9bN8BgymwYdDObhovyU1B0AdwWlib3 t6Q6mAZr+9CzmhzXhT7l+bHVSM1SFEhbQGxm32vLSGIdOuSVlcFaeLrYfmvP7r+/hJPC YD8ZA3nRk5tGWl5WjCIjX5CpvgREEe1aAxcMXLb634KHs646dVi1EzICIplMgZYt9Nbu K6vX0wk7C5i+uEFmEnJCveYeIzqOGbGDJXDNVftODT6runPaTtbHnTSjA7y5eEvZDdsM fhCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=2GQb1rMw38IHB+yRqLDOgZ3lzbo3SWYowL9Yi8YJ4vM=; b=zwLW+f1oKoZ0K5VjixVecuSBj/9ibUj6JboFeIAjlBFJEtVJNG3evo9w0R1VDZeXZt g2aLOuYuV6yZF2zV4XeS3T1sMIAjXQX4muADoyHqa+evs77lqABLERvHb8Co5ClBwm7g 2vlfYLj9K2aG2wUknZCE/UT6W56LSoDjpy7eGI4bWGrY3wvnGwGbq+UL2xMBBaXUN6m0 UmLh19aztBAtHM0914ARmxPiHx0xDyUqIPJ7/NSxsP7BZAp+wP6g1+EYFCcvI2iMbVT5 63zRdD9J9QOKl/sfwVSs/Gc7L+BZR8MQmLUt+b7rA8K2ivzy2/LX+n0EnuN9aC4Q2xef j2JA== 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 b6-v6si27898plx.696.2018.02.01.07.35.08; Thu, 01 Feb 2018 07:35:23 -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 S1752622AbeBAPdi (ORCPT + 99 others); Thu, 1 Feb 2018 10:33:38 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:48072 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751707AbeBAPde (ORCPT ); Thu, 1 Feb 2018 10:33:34 -0500 Received: (qmail 6835 invoked by uid 2102); 1 Feb 2018 10:33:33 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Feb 2018 10:33:33 -0500 Date: Thu, 1 Feb 2018 10:33:33 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Yoshida, Shigeru" cc: "Bai, Haiqing" , "gregkh@linuxfoundation.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func() In-Reply-To: <20180201.144911.2171407625301691891.shigeru.yoshida@windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 1 Feb 2018, Yoshida, Shigeru wrote: > Hi Alan, > > Thank you for your commenting. > > On Wed, 31 Jan 2018 11:02:47 -0500, Alan Stern wrote: > >> To address above scenario, this patch introduces timer_running flag to > >> ohci_hcd structure. Setting true to ohci->timer_running indicates > >> io_watchdog_func() is scheduled or is running. ohci_urb_enqueue() > >> checks the flag when it schedules the watchdog (step 4 and 12 above), > >> so ohci->prev_frame_no is not overwritten while io_watchdog_func() is > >> running. > > > > Instead of adding an extra flag variable, which has to be kept in sync > > with the timer routine, how about defining a special sentinel value for > > prev_frame_no? For example: > > > > #define IO_WATCHDOG_OFF 0xffffff00 > > > > Then whenever the timer isn't scheduled or running, set > > ohci->prev_frame_no to IO_WATCHDOG_OFF. And instead of testing > > timer_pending(), compare prev_frame_no to this special value. > > > > I think that approach will be slightly more robust. > > It's reasonable since ohci->prev_frame_no is not used while the > watchdog timer is stopped. > > I think we must choose an invalid frame number for the special > sentinel value, but I'm not sure which value is adequate for it. > Is 0xffffff00 an invalid frame number, otherwise how about simply > -1(0xffffffff)? Well, the frame_no register is 32 bits wide, but only the 16 low-order bits are meaningful. ohci_frame_no() strips off the high-order 16 bits, so any value with one of those bits set would be acceptable. (Besides, valid frame numbers only go up to 2047.) I chose 0xffffff00 because PCI reads from a non-working device generally get a value with all the bits set. But since the upper 16 bits are masked away anyhow, it doesn't matter. -1u would be fine. Alan Stern