Messages in this thread | | | Subject | Re: [RT WARNING] DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) with fsfreeze (4.19.25-rt16) | From | Waiman Long <> | Date | Wed, 1 May 2019 13:26:08 -0400 |
| |
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.
static inline void __up_write(struct rw_semaphore *sem) { long tmp;
/* * sem->owner may differ from current if the ownership is transferred * to an anonymous writer by setting the RWSEM_NONSPINNABLE bits. */ DEBUG_RWSEMS_WARN_ON((sem->owner != current) && !((long)sem->owner & RWSEM_NONSPINNABLE), sem);
Maybe I should break this part out and have it merged into tip as well.
Cheers, Longman
| |