linux-kernel - Re: [PATCH] rxrpc: struct mutex cannot be used for rxrpc_call::user

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: <20191218190833.ufpxjrvin5jvp3m5@linux-p48b>
Date:   Wed, 18 Dec 2019 11:08:33 -0800
From:   Davidlohr Bueso <dave@...olabs.net>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     David Howells <dhowells@...hat.com>, linux-afs@...ts.infradead.org,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] rxrpc: struct mutex cannot be used for
 rxrpc_call::user_mutex

On Wed, 18 Dec 2019, Peter Zijlstra wrote:

>On Tue, Dec 17, 2019 at 03:32:00PM +0000, David Howells wrote:
>> Standard kernel mutexes cannot be used in any way from interrupt or softirq
>> context, so the user_mutex which manages access to a call cannot be a mutex
>> since on a new call the mutex must start off locked and be unlocked within
>> the softirq handler to prevent userspace interfering with a call we're
>> setting up.
>>
>> Commit a0855d24fc22d49cdc25664fb224caee16998683 ("locking/mutex: Complain
>> upon mutex API misuse in IRQ contexts") causes big warnings to be splashed
>> in dmesg for each a new call that comes in from the server.
>
>FYI that patch has currently been reverted.
>
>commit c571b72e2b845ca0519670cb7c4b5fe5f56498a5 (tip/locking/urgent, tip/locking-urgent-for-linus)

Will we ever want to re-add this warning (along with writer rwsems) at some point?

It seems that having it actually prompts things getting fixed, as opposed to
just sitting there forever borken (at least in -rt).

Thanks,
Davidlohr