Query about bhyve's blockif_cancel and the signalling mechanisms

[Ian Campbell]

On 14 December 2016 at 00:05, Tycho Nightingale <tychon at freebsd.org> wrote:
> On Dec 13, 2016, at 1:32 AM, Peter Grehan <grehan at 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!

Ian.