linux-kernel - Re: [PATCH 3/3] random: use trylock in irq handler rather than spinning

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: <CAHmME9rtP=YUGk1UbTQQiONhssn8v+c_0ZXnt7tex3mQWY7g+Q@mail.gmail.com>
Date:   Sun, 13 Feb 2022 11:51:31 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     linux-kernel@...r.kernel.org, "Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH 3/3] random: use trylock in irq handler rather than spinning

Hi Dominik,

Yes, the decision about RT and trylocks is still undecided, and I'm
actually trying to get the existing design into as optimal shape as
possible before considering deferring it, so we can really have a
complete comparison. It was an error (my error) to introduce the full
lock here in the original patch that added this. So I've actually made
this patch into a fixup for that original one, so we don't need this
one on top.

I'll be looking at the deferred work next week, but I'd like the
existing thing to be as solid as possible before. Otherwise it's too
hard to evaluate pros and cons.

Jason