[PATCH RFC] nvmet-rdma: use a private workqueue for delete

[johannes@sipsolutions.net (Johannes Berg)]

On Tue, 2018-10-23@21:59 +0200, Johannes Berg wrote:
> On Tue, 2018-10-23@12:54 -0700, Bart Van Assche wrote:
> > On Tue, 2018-10-23@21:18 +0200, Johannes Berg wrote:
> > > On Mon, 2018-10-22@14:17 -0700, Bart Van Assche wrote:
> > > > On Mon, 2018-10-22@10:56 +0200, Johannes Berg wrote:
> > > > > On Fri, 2018-10-19@16:23 +0000, Bart Van Assche wrote:
> > > > > > On Thu, 2018-10-18@18:08 -0700, Sagi Grimberg wrote:
> > > > > > > > It seems like this has not yet been fixed entirely. This is what appeared
> > > > > > > > in the kernel log this morning on my test setup with Christoph's nvme-4.20
> > > > > > > > branch (commit cb4bfda62afa ("nvme-pci: fix hot removal during error
> > > > > > > > handling")):
> > > > > 
> > > > > FWIW, I'm not sure where to find this tree (it's not on kernel.org,
> > > > > apparently, at least none of hch's?). As a result, I don't have the
> > > > > correct code here now.
> > > > 
> > > > Christoph's NVMe tree is available at git://git.infradead.org/nvme.git.
> > > 
> > > Ok, thanks. I think I'll go off Sagi Grimberg's explanation though
> > > rather than try to understand the code myself.
> > 
> > Are the lockdep annotations in kernel/workqueue.c correct? My understanding
> > is that lock_map_acquire() should only be used to annotate mutually exclusive
> > locking (e.g. mutex, spinlock). However, multiple work items associated with
> > the same workqueue can be executed concurrently. From lockdep.h:
> > 
> > #define lock_map_acquire(l) lock_acquire_exclusive(l, 0, 0, NULL, _THIS_IP_)
> 
> I've talked about this in the other thread, in the interest of keeping
> things together, can you ask that again over there?

Actually, I'll just go answer over there, no need to repost the
question.

johannes