lkml.org 
[lkml]   [2019]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RT WARNING] DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) with fsfreeze (4.19.25-rt16)
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.

\
 
 \ /
  Last update: 2019-05-01 20:55    [W:0.441 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site