linux-kernel - Re: [RT WARNING] DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current) with fsfreeze (4.19.25-rt16)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ce854251-139e-15f1-2ac5-b66a27f8284c@redhat.com>
Date:   Wed, 1 May 2019 13:26:08 -0400
From:   Waiman Long <longman@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     linux-rt-users <linux-rt-users@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Clark Williams <williams@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Oleg Nesterov <oleg@...hat.com>, jack@...e.com,
        Davidlohr Bueso <dave@...olabs.net>
Subject: Re: [RT WARNING] DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current)
 with fsfreeze (4.19.25-rt16)

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