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
Thanks for setting me straight!
email@example.com mailing list
To unsubscribe, send any mail to