[lkml]   [2019]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Re: [Xen-devel] [PATCH v12 2/5] xenbus/backend: Protect xenbus callback with lock
On Wed, 18 Dec 2019 13:27:37 +0100 "Jürgen Groß" <> wrote:

> On 18.12.19 11:42, SeongJae Park wrote:
> > From: SeongJae Park <>
> >
> > 'reclaim_memory' callback can race with a driver code as this callback
> > will be called from any memory pressure detected context. To deal with
> > the case, this commit adds a spinlock in the 'xenbus_device'. Whenever
> > 'reclaim_memory' callback is called, the lock of the device which passed
> > to the callback as its argument is locked. Thus, drivers registering
> > their 'reclaim_memory' callback should protect the data that might race
> > with the callback with the lock by themselves.
> Any reason you don't take the lock around the .probe() and .remove()
> calls of the backend (xenbus_dev_probe() and xenbus_dev_remove())? This
> would eliminate the need to do that in each backend instead.

First of all, I would like to keep the critical section as small as possible.
With my small test, I could see slightly increasing memory pressure as the
critical section becomes wider. Also, some drivers might share the data their
'reclaim_memory' callback touches with other functions. I think only the
driver owners can know what data is shared and what is the minimum critical
section to protect it.

If you think differently or I am missing something, please let me know.

SeongJae Park

> Juergen

 \ /
  Last update: 2019-12-18 13:44    [W:0.038 / U:1.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site