All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Mingye Wang <arthur200126@gmail.com>
Cc: linux-man <linux-man@vger.kernel.org>
Subject: Re: [PATCH v4 1/3] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes
Date: Sun, 18 Jan 2026 23:21:07 +0100	[thread overview]
Message-ID: <aW1cv66DwJiydmyM@devuan> (raw)
In-Reply-To: <tevwgko5kxlkooyvzqgvs67svntqlhhqpdewgooph7hdgc64hc@wskpnevhgwam>

[-- Attachment #1: Type: text/plain, Size: 5432 bytes --]

Ping.  :)

On Mon, Nov 24, 2025 at 05:44:17PM +0100, Alejandro Colomar wrote:
> Hi Mingye,
> 
> On Mon, Nov 10, 2025 at 11:51:30AM +0800, Mingye Wang wrote:
> > On Mon, Nov 10, 2025 at 11:05 AM Mingye Wang <arthur200126@gmail.com> wrote:
> > >
> > > > Does /dev/urandom block when reading with read(2) before the pool is
> > > ready?  I assume it blocks.
> > >
> > > From what I've heard it does not. Working on other comments.
> > 
> [...]
> > 
> > I am sending only the revised version of the patch you commented on
> > (the one that touches three files, random.{4,7}, getrandom.2). You
> > might notice that this patch is much larger. This is because when
> > editing the table I noticed that there's really no reason to keep the
> > "Pool" column around for 5.6+, but removing it also felt off. In the
> > end I just made two separate tables, but with identical cell-width
> > settings.
> 
> Please split into more patches.  I think this patch could be broken into
> a set of many small patches, each of which does one thing.  5 or 10
> patches would be okay.
> 
> > Speaking of cell-width settings, the existing version was not filling
> > the entire screen, which contravenes what man-pages(7) says about
> > using lbx. Adding an "x" does make it look nicer too.
> > 
> > (I have no idea whether this is the fourth version, but it's
> > definitely after the third and five seems too many. In any case, I
> > will be incrementing this number in future patch submissions to keep
> > things navigable.)
> > 
> > Regards,
> > Mingye Wang (Artoria2e5)
> 
> Some review of v4:
> 
> 	diff --git a/man/man4/random.4 b/man/man4/random.4
> 	index 0a651b03f..071fc99ef 100644
> 	--- a/man/man4/random.4
> 	+++ b/man/man4/random.4
> 	@@ -56,17 +56,29 @@ .SH DESCRIPTION
> 	 .I /dev/random
> 	 instead.
> 	 .P
> 	-The
> 	+.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
> 	+Since Linux 5.6,
> 	 .I /dev/random
> 	-device is a legacy interface which dates back to
> 	+is identical to
> 	+.IR /dev/urandom ,
> 	+except that it blocks during early boot.
> 	+A jitter-based seeding technique added in Linux 5.4 should help reduce
> 	+block time.
> 	+.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
> 	+.P
> 	+The pre-Linux 5.6
> 	+.I /dev/random
> 	+device was a legacy interface which dates back to
> 
> I'd prefer 'Before Linux 5.6,' instead of 'The pre-Linux 5.6'.
> 
> 	 a time where the cryptographic primitives used in the implementation
> 	 of
> 	 .I /dev/urandom
> 	 were not widely trusted.
> 	-It will return random bytes only within the estimated number of
> 	-bits of fresh noise in the entropy pool, blocking if necessary.
> 	+It would return random bytes only within the estimated number of bits of fresh
> 	+noise in the entropy pool, blocking until additional environmental noise is
> 	+gathered.
> 	+This old
> 	 .I /dev/random
> 
> Please use semantic newlines.  See man-pages(7):
> 
> $ MANWIDTH=72 man man-pages | sed -n '/Use semantic newlines/,/^$/p'
>    Use semantic newlines
>      In the source of a manual page, new sentences should be started on
>      new lines, long sentences should be split  into  lines  at  clause
>      breaks  (commas,  semicolons, colons, and so on), and long clauses
>      should be split at phrase boundaries.  This convention,  sometimes
>      known as "semantic newlines", makes it easier to see the effect of
>      patches, which often operate at the level of individual sentences,
>      clauses, or phrases.
> 
> I'd write it as:
> 
> ```
> It would return random bytes
> only within the estimated number of bits of fresh noise
> in the entropy pool,
> blocking until additional environmental noise is gathered.
> ```
> 
> Same here:
> 
> 	@@ -121,7 +133,8 @@ .SH DESCRIPTION
> 	 .BR read (2)
> 	 from
> 	 .I /dev/random
> 	-will return at most 512 bytes
> 	+has the same maximum size since Linux 5.6. Between Linux 3.16 and 5.5,
> 	+the maximum size was 512 bytes
> 	 .\" SEC_XFER_SIZE in drivers/char/random.c
> 	 (340 bytes before Linux 2.6.12).
> 	 .P
> 
> Use .P instead of .PP here:
> 
> 	diff --git a/man/man7/random.7 b/man/man7/random.7
> 	index fda408d38..65e21a07e 100644
> 	--- a/man/man7/random.7
> 	+++ b/man/man7/random.7
> 	@@ -54,17 +54,16 @@ .SS Initialization of the entropy pool
> 	 When a sufficient number of random bits has been collected, the
> 	 entropy pool is considered to be initialized.
> 	 .SS Choice of random source
> 	-Unless you are doing long-term key generation (and most likely not even
> 	-then), you probably shouldn't be reading from the
> 	+Unless your program may run at early-boot, before the entropy pool
> 	+is initialized, there is no longer any palpable difference between
> 	 .I /dev/random
> 	-device or employing
> 	-.BR getrandom (2)
> 	-with the
> 	-.B GRND_RANDOM
> 	-flag.
> 	-Instead, either read from the
> 	+and
> 	 .I /dev/urandom
> 	-device or employ
> 	+since Linux 5.6 (see the table below).
> 	+.PP
> 	+On older kernels, either read from the
> 	+.I /dev/urandom
> 	+device or (especially if you are concerned with early boot) employ
> 	 .BR getrandom (2)
> 	 without the
> 	 .B GRND_RANDOM
> 
> 
> Have a lovely day!
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es>
> Use port 80 (that is, <...:80/>).



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-01-18 22:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-30 16:42 [Bug 214885] New: random.{4,7} [man-pages 5.13] do not reflect changes to /dev/random semantics since kernel 5.6 bugzilla-daemon
2021-10-30 17:01 ` [Bug 214885] " bugzilla-daemon
2023-05-25 11:34 ` bugzilla-daemon
2023-05-25 12:36 ` bugzilla-daemon
2023-05-29  8:50   ` [PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes Mingye Wang
2023-05-31 22:20     ` Alejandro Colomar
2023-06-02 11:35       ` Mingye Wang
2023-06-05  3:13         ` Mingye Wang
2023-07-08 19:06           ` Alejandro Colomar
2025-03-04 14:29             ` Mingye Wang
2025-03-09 19:03               ` Alejandro Colomar
2025-11-09  2:36                 ` [PATCH 1/3] " Mingye Wang
2025-11-09 11:32                   ` Alejandro Colomar
     [not found]                     ` <CAD66C+Z0iOJig457DQDVg+CgcVsE0C=wbuXK21we5XcNyGVizw@mail.gmail.com>
2025-11-10  3:51                       ` [PATCH v4 " Mingye Wang
2025-11-10  9:59                         ` Alejandro Colomar
2025-11-24 16:44                         ` Alejandro Colomar
2026-01-18 22:21                           ` Alejandro Colomar [this message]
2026-04-21 14:07                             ` Alejandro Colomar
2024-03-25 12:44 ` [Bug 214885] random.{4,7} [man-pages 5.13] do not reflect changes to /dev/random semantics since kernel 5.6 bugzilla-daemon
2024-03-25 13:26 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aW1cv66DwJiydmyM@devuan \
    --to=alx@kernel.org \
    --cc=arthur200126@gmail.com \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.