From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753219AbcLLPvd (ORCPT ); Mon, 12 Dec 2016 10:51:33 -0500 Received: from mga06.intel.com ([134.134.136.31]:50686 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752389AbcLLPvc (ORCPT ); Mon, 12 Dec 2016 10:51:32 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,337,1477983600"; d="scan'208";a="17044677" Subject: Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command To: Baolin Wang , mathias.nyman@intel.com References: <0c39bfed1cf6f7b747e702aa841f82c9d2140f27.1480922249.git.baolin.wang@linaro.org> Cc: gregkh@linuxfoundation.org, baolu.lu@linux.intel.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, broonie@kernel.org From: Mathias Nyman Message-ID: <584EC7B9.6040100@linux.intel.com> Date: Mon, 12 Dec 2016 17:52:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <0c39bfed1cf6f7b747e702aa841f82c9d2140f27.1480922249.git.baolin.wang@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05.12.2016 09:51, Baolin Wang wrote: > If a command event is found on the event ring during an interrupt, > we need to stop the command timer with del_timer(). Since del_timer() > can fail if the timer is running and waiting on the xHCI lock, then > it maybe get the wrong timeout command in xhci_handle_command_timeout() > if host fetched a new command and updated the xhci->current_cmd in > handle_cmd_completion(). For this situation, we need a way to signal > to the command timer that everything is fine and it should exit. Ah, right, this could actually happen. > > We should introduce a counter (xhci->current_cmd_pending) for the number > of pending commands. If we need to cancel the command timer and del_timer() > succeeds, we decrement the number of pending commands. If del_timer() fails, > we leave the number of pending commands alone. > > For handling timeout command, in xhci_handle_command_timeout() we will check > the counter after decrementing it, if the counter (xhci->current_cmd_pending) > is 0, which means xhci->current_cmd is the right timeout command. If the > counter (xhci->current_cmd_pending) is greater than 0, which means current > timeout command has been handled by host and host has fetched new command as > xhci->current_cmd, then just return and wait for new current command. A counter like this could work. Writing the abort bit can generate either ABORT+STOP, or just STOP event, this seems to cover both. quick check, case 1: timeout and cmd completion at the same time. cpu1 cpu2 queue_command(first), p++ (=1) queue_command(more), --completion irq fires-- -- timer times out at same time-- handle_cmd_completion() handle_cmd_timeout(),) lock(xhci_lock ) spin_on(xhci_lock) del_timer() fail, p (=1, nochange) cur_cmd = list_next(), p++ (=2) unlock(xhci_lock) lock(xhci_lock) p-- (=1) if (p > 0), exit OK works case 2: normal timeout case with ABORT+STOP, no race. cpu1 cpu2 queue_command(first), p++ (=1) queue_command(more), handle_cmd_timeout() p-- (P=0), don't exit mod_timer(), p++ (P=1) write_abort_bit() handle_cmd_comletion(ABORT) del_timer(), ok, p-- (p = 0) handle_cmd_completion(STOP) del_timer(), fail, (P=0) handle_stopped_cmd_ring() cur_cmd = list_next(), p++ (=1) mod_timer() OK, works, and same for just STOP case, with the only difference that during handle_cmd_completion(STOP) p is decremented (p--) So unless there is a way to find out if cur_cmd is valid in command timeout in command timeout with the help of existing flags and lists this would be a working solution. -Mathias