linux-kernel - Re: [PATCH RT] rtmutex: Flush block plug on __down

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20190109083107.xqjreevkq3lkkfzq@linutronix.de>
Date:   Wed, 9 Jan 2019 09:31:08 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Scott Wood <swood@...hat.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Mikulas Patocka <mpatocka@...hat.com>,
        linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RT] rtmutex: Flush block plug on __down_read()

On 2019-01-08 13:19:47 [-0600], Scott Wood wrote:
> >  We
> > do it for rtmutex because !RT does it for mutex.
> > Now I can't remember why this was skipped for a rw_sem since it is
> > performed for !RT as part of the schedule() invocation.
> 
> Without this we were seeing XFS hangs on our internal kernel.  I wasn't able
> to reproduce it on a newer kernel, but it's very timing-dependant so I
> wouldn't read too much into that.

In this case I don't care much if you can reproduce this or not. The
point is that !RT does this so RT should do it, too. And back then (when
this piece was added) we wanted to copy the !RT behaviour and somehow
missed that piece.

> > If I don't come up with a plausible explanation then I will apply this
> > plus a hunk for the __down_write_common() case which should also be
> > required (right?).
> 
> I don't think it's needed, as it doesn't call into the rtmutex code via a
> backdoor.  When blocking on sem->rtmutex, rt_mutex_fastlock() will call the
> flush.  When blocking with a direct call to schedule(), tsk_is_pi_blocked()
> will not be true, and thus schedule() will do the flush via
> sched_submit_work().

a backdoor :) But yes, in each case we invoke schedule() so it is good.
Okay then. Let me apply it.
Thank you.

> -Scott

Sebastian