Re: Re: [Xen-devel] [PATCH v12 2/5] xenbus/backend: Protect xenbus callback with lock

[SeongJae Park]

On Wed, 18 Dec 2019 13:27:37 +0100 "JÃrgen GroÃ" <jgross@xxxxxxxx> wrote:

> On 18.12.19 11:42, SeongJae Park wrote:
> > From: SeongJae Park <sjpark@xxxxxxxxx>
> > 
> > '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.


Thanks,
SeongJae Park

> 
> 
> Juergen