Date: Wed, 14 Dec 2016 11:46:56 +0000 From: Ian Campbell <ian.campbell@docker.com> To: Tycho Nightingale <tychon@freebsd.org> Cc: Peter Grehan <grehan@freebsd.org>, freebsd-virtualization@freebsd.org, Anil Madhavapeddy <anil@recoil.org> Subject: Re: Query about bhyve's blockif_cancel and the signalling mechanisms Message-ID: <CAOc2ZU1W64r_Vz86Oy0CxM0MCbzhKdVq-=8Xum_fTby=Ovr4iQ@mail.gmail.com> In-Reply-To: <397B138D-3701-4FB4-A9B3-618CE2624C3C@freebsd.org> References: <CAOc2ZU0Hqvctv767ESu6fKwXJ3W35ReqM3=ud6G3MzKLSEY=Bw@mail.gmail.com> <631f775d-8d61-55ba-1e7b-8ce4fcadcbf3@freebsd.org> <397B138D-3701-4FB4-A9B3-618CE2624C3C@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 December 2016 at 00:05, Tycho Nightingale <tychon@freebsd.org> wrote: > On Dec 13, 2016, at 1:32 AM, Peter Grehan <grehan@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 w= hen 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=E2=80=99s the easy case. > > As for blockif requests which are queued, those are simply completed. Th= e ones that are in-flight all have their status set to BST_BUSY when they a= re moved from the pending queue to the busy queue just prior to being sent = to blockif_proc(). It=E2=80=99s therefore possible that an in-flight reque= st (one on the busy list) has yet to call blockif_proc(), or is already ins= ide blockif_proc() or has just completed blockif_proc(). In all cases howe= ver BST_BUSY is cleared in blockif_complete(). The key is therefore that r= egardless of where the thread is, blockif_cancel() will continue to issue p= thread_kill() until the request reaches blockif_complete() =E2=80=94 breaki= ng it out of system calls as necessary. > > Does that make sense? Absolutely. Somehow I had read "while (be->be_status =3D=3D BST_BUSY)" as "if (...)", Thanks for setting me straight! Ian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOc2ZU1W64r_Vz86Oy0CxM0MCbzhKdVq-=8Xum_fTby=Ovr4iQ>