On 14 December 2016 at 00:05, Tycho Nightingale <tyc...@freebsd.org> wrote:
> On Dec 13, 2016, at 1:32 AM, Peter Grehan <gre...@freebsd.org> wrote:
>>> I have a secondary concern which is what happens if the IO thread is
>>> on its way to making a blocking system call in blockif_proc but has
>>> not actually done so when the signal is delivered. It seems like it
>>> would simply carry on and make the blocking call with perhaps
>>> unexpected consequences (i/o getting wedged, perhaps only until a
>>> second reset attempt). I've not actually seen this happening though
>>> and there's a chance I'm simply over thinking things after staring at
>>> them for so long!
>> I believe this case is handled - I discussed this at length with Tycho when 
>> the code was committed a while back.
>> Tycho - any thoughts ?
> ahci_port_stop() is called under the protection the port soft-state lock so 
> that will stem any further requests from landing in the blockif queue.  
> That’s the easy case.
> As for blockif requests which are queued, those are simply completed.  The 
> ones that are in-flight all have their status set to BST_BUSY when they are 
> moved from the pending queue to the busy queue just prior to being sent to 
> blockif_proc().  It’s therefore possible that an in-flight request (one on 
> the busy list) has yet to call blockif_proc(), or is already inside 
> blockif_proc() or has just completed blockif_proc().  In all cases however 
> BST_BUSY is cleared in blockif_complete().  The key is therefore that 
> regardless of where the thread is, blockif_cancel() will continue to issue 
> pthread_kill() until the request reaches blockif_complete() — breaking it out 
> of system calls as necessary.
> Does that make sense?

Absolutely. Somehow I had read "while (be->be_status == BST_BUSY)" as
"if (...)",

Thanks for setting me straight!

freebsd-virtualization@freebsd.org mailing list
To unsubscribe, send any mail to 

Reply via email to