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: <CANn89iJtK4m1cWvCwp=L_rEOEBa+B1kLZJAw0D9_cYPQcAj+Mw@mail.gmail.com>
Date:   Wed, 14 Dec 2022 16:15:49 +0100
From:   Eric Dumazet <edumazet@...gle.com>
To:     Stanislaw Gruszka <stanislaw.gruszka@...ux.intel.com>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        david.keisarschm@...l.huji.ac.il,
        Vignesh Raghavendra <vigneshr@...com>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Alexei Starovoitov <ast@...nel.org>,
        dri-devel@...ts.freedesktop.org, Song Liu <song@...nel.org>,
        linux-mtd@...ts.infradead.org, Stanislav Fomichev <sdf@...gle.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Christoph Lameter <cl@...ux.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Richard Weinberger <richard@....at>, x86@...nel.org,
        John Fastabend <john.fastabend@...il.com>,
        Andrii Nakryiko <andrii@...nel.org>, ilay.bahat1@...il.com,
        Ingo Molnar <mingo@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Jiri Pirko <jiri@...dia.com>,
        David Rientjes <rientjes@...gle.com>,
        Yonghong Song <yhs@...com>, Paolo Abeni <pabeni@...hat.com>,
        intel-gfx@...ts.freedesktop.org, Petr Mladek <pmladek@...e.com>,
        Jiri Olsa <jolsa@...nel.org>, Hao Luo <haoluo@...gle.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        KP Singh <kpsingh@...nel.org>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Borislav Petkov <bp@...en8.de>, Hannes Reinecke <hare@...e.de>,
        Andy Lutomirski <luto@...nel.org>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        linux-scsi@...r.kernel.org,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        linux-mm@...ck.org, netdev@...r.kernel.org, bpf@...r.kernel.org,
        linux-kernel@...r.kernel.org, Pekka Enberg <penberg@...nel.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        aksecurity@...il.com, Joonsoo Kim <iamjoonsoo.kim@....com>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 1/5] Renaming weak prng invocations - prandom_bytes_state, prandom_u32_state

On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
<stanislaw.gruszka@...ux.intel.com> wrote:
>
> On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> > Please CC me on future revisions.
> >
> > As of 6.2, the prandom namespace is *only* for predictable randomness.
> > There's no need to rename anything. So nack on this patch 1/5.
>
> It is not obvious (for casual developers like me) that p in prandom
> stands for predictable. Some renaming would be useful IMHO.

Renaming makes backports more complicated, because stable teams will
have to 'undo' name changes.
Stable teams are already overwhelmed by the amount of backports, and
silly merge conflicts.

Take another example :

u64 timecounter_read(struct timecounter *tc)

You would think this function would read the timecounter, right ?

Well, it _updates_ many fields from @tc, so a 'better name' would also
be useful.

linux kernel is not for casual readers.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ