linux-kernel - Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Dec 2016 17:52:25 +0200
From:   Mathias Nyman <mathias.nyman@...ux.intel.com>
To:     Baolin Wang <baolin.wang@...aro.org>, mathias.nyman@...el.com
Cc:     gregkh@...uxfoundation.org, baolu.lu@...ux.intel.com,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        broonie@...nel.org
Subject: Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

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