On Wed, May 01, 2019 at 01:26:08PM -0400, Waiman Long wrote: > On 5/1/19 1:09 PM, Peter Zijlstra wrote: > > On Tue, Apr 30, 2019 at 03:28:11PM +0200, Peter Zijlstra wrote: > > > >> Yeah, but AFAIK fs freezing code has a history of doing exactly that.. > >> This is just the latest incarnation here. > >> > >> So the immediate problem here is that the task doing thaw isn't the same > >> that did freeze, right? The thing is, I'm not seeing how that isn't a > >> problem with upstream either. > >> > >> The freeze code seems to do: percpu_down_write() for the various states, > >> and then frobs lockdep state. > >> > >> Thaw then does the reverse, frobs lockdep and then does: percpu_up_write(). > >> > >> percpu_down_write() directly relies on down_write(), and > >> percpu_up_write() on up_write(). And note how __up_write() has: > >> > >> DEBUG_RWSEMS_WARN_ON(sem->owner != current, sem); > >> > >> So why isn't this same code coming unstuck in mainline? > > That code is in just in the tip tree. It is not in the mainline yet. I > do realize that it can be a problem and so I have it modified to the > following in my part2 patchset. Nah, the percpu_rwsem abuse by the freezer is atrocious, we really should not encourage that. Also, it completely wrecks -RT. Hence the proposed patch.
