linux-kernel - Re: [PATCH 5/5] random: Defer processing of randomness on PREEMPT

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: <20211220025656.GB20311@gondor.apana.org.au>
Date:   Mon, 20 Dec 2021 13:56:56 +1100
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Jason@...c4.com, linux-kernel@...r.kernel.org, tytso@....edu,
        tglx@...utronix.de, peterz@...radead.org
Subject: Re: [PATCH 5/5] random: Defer processing of randomness on PREEMPT_RT.

On Sun, Dec 19, 2021 at 10:48:12AM +0100, Sebastian Andrzej Siewior wrote:
>
> That one. I find the semantic difficult to understand. Some BH-user
> check sock_owned_by_user(), some don't.
> However, a semaphore should work. The atomic user would do
> down_trylock() while preemptible caller would invoke down() and sleep
> until the lock is available. Let me check if that works here…

Right, if your atomic user can simply discard the work then this
is enough.

In the network case, we can't just discard the packet so that's
why there is a backlog queue which the atomic user appends to
if the lock isn't available.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt