On Thu, Aug 01, 2019 at 12:50:37PM -0400, Doug Ledford wrote: > On Thu, 2019-08-01 at 16:43 +0000, Jason Gunthorpe wrote: > > On Thu, Aug 01, 2019 at 12:40:43PM -0400, Doug Ledford wrote: > > > > > > It does have a lock though, the caller holds it, hence the request > > > > for > > > > the lockdep. > > > > > > You're right, although I think the lockdep annotation can be a > > > separate > > > patch as it's neeeded on more than just the function this patch > > > touches. > > > > Why? This relies on that lock, so it should have the > > lockdep_assert_held assert. > > It does, but this patch is about the scheduling while atomic, adding a > lockdep assertion fix is doubling up on fixes in the patch. A separate > patch that addes the lockdep assert to both the bind and unbind calls > makes more sense and just feels cleaner to me. +1 Also, I'm not going to take any chances in -rc submission, and won't change in -rc patches anything without verification approval and it will take time and will come very late in -rcX. Thanks > > > If there are more functions with implicit locking theyt they can be > > fixed separately... > > -- > Doug Ledford <dledford@xxxxxxxxxx> > GPG KeyID: B826A3330E572FDD > Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
