Date: Mon, 30 Jul 2018 15:59:19 +0530 From: Pratyush Yadav <pratyush@freebsd.org> To: Akshay Jaggi <jaggi@freebsd.org> Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <royger@freebsd.org>, Edward Napierala <trasz@freebsd.org>, FreeBSD-Xen <freebsd-xen@freebsd.org> Subject: Re: Recursion in non-recursive mutex when using the grant table free callbacks Message-ID: <CA%2BX=3T%2BFV=0VbSfZUce81Any8UqLma7Kkyj-D8DWpEBx_s%2BwSQ@mail.gmail.com> In-Reply-To: <CAAeUNVmGQ-NaXcaQURcx4tzrPm==SJJzzcw10Dtnmp4P8jzjJA@mail.gmail.com> References: <CA%2BX=3T%2BnHO6_Uhx=HFhcjQGe=GF_yOyEnO_nm6GS%2Bu7wfXR5qg@mail.gmail.com> <CAAeUNVmGQ-NaXcaQURcx4tzrPm==SJJzzcw10Dtnmp4P8jzjJA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 30, 2018 at 4:00 AM Akshay Jaggi <jaggi@freebsd.org> wrote: > > Roger would be a better person to answer this and I would wait for him to respond, but here are my 2 cents. > > First let's finalize and record the semantics of the callbacks. What guarantee do we want to provide callbacks about locks held (no locks held OR x,y,z locks held)? This is mostly a product decision. Usually callbacks are called with no locks held. > Post this problem is simple. If the list_lock would be held during callbacks, we need to provide a lock-free function (which assumes lock would be held before function is called and use that) and if the lock would not be held we should fix the locking to ensure the case you mentioned should not happen. > > WDYT? The guarantee we want to provide the callback is that the allocation of grant references can not fail inside the callback (unless they try to allocate more refs than initially specified). This means that we can't call the callback without the lock held otherwise during the execution of the callback it is possible for some other thread to get the grant references, and the grant refs the callbacks needs would not be available. So a change in the locking has to be done. On Mon, Jul 30, 2018 at 3:02 PM Roger Pau Monné <royger@freebsd.org> wrote: > I agree in the analysis, however I think the proper solution is to use > a recursive lock. All right. I'll send in the patch. -- Regards, Pratyush Yadav
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BX=3T%2BFV=0VbSfZUce81Any8UqLma7Kkyj-D8DWpEBx_s%2BwSQ>