From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org, patches@lists.linux.dev,
tglx@linutronix.de, linux-crypto@vger.kernel.org,
linux-api@vger.kernel.org, x86@kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
"Carlos O'Donell" <carlos@redhat.com>,
Florian Weimer <fweimer@redhat.com>,
Arnd Bergmann <arnd@arndb.de>, Jann Horn <jannh@google.com>,
Christian Brauner <brauner@kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings
Date: Tue, 3 Jan 2023 12:25:59 -0800 [thread overview]
Message-ID: <CAHk-=wg4SRHF6AhYDcgyokN2BMjra91Ns4h9wWPachhf-x3=xQ@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wi4gshfKjbhEO_xZdVb9ztXf0iuv5kKhxtvAHf2HzTmng@mail.gmail.com>
On Tue, Jan 3, 2023 at 12:15 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, Jan 3, 2023 at 12:03 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > That buffering cannot be done safely currently
>
> .. again, this is "your semantics" (the (b) in my humbug list), not
> necessarily reality for anybody else.
Just to make an example: fork() is already problematic for something
as fundamental as <stdio.h>.
That doesn't mean that we do a special fork-safe stdio.h
infrastructure in the kernel. It just means that people have to do
things like fflush(NULL) (or use variations of setbuf() and friends)
when they deal with fork() and stdio interactions.
The random number generator really isn't that different. Periodic
reseeding isn't something stdio has to deal with, but having a
timestamp in user space library and forcing a re-seed isn't unheard of
in other contexts.
You don't even need anything as fancy as an actual timer, because it
doesn't need *active* flushing, just a "oh, it's been too long since
we read the random data, let's do it again".
And yes, I bet it would be a good idea to have an actual library for
this that handles (and *documents*) these kinds of issues - exactly
like a <stdio.h>, just for randomness.
I just don't think it should be involved in the kernel - again exactly
like <stdio.h>.
Linus
next prev parent reply other threads:[~2023-01-03 20:26 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230101162910.710293-1-Jason@zx2c4.com>
2023-01-01 16:29 ` Jason A. Donenfeld
2023-01-03 10:50 ` Ingo Molnar
2023-01-03 15:01 ` Jason A. Donenfeld
2023-01-03 18:15 ` Ingo Molnar
2023-01-03 18:51 ` Jason A. Donenfeld
2023-01-03 18:36 ` Andy Lutomirski
2023-01-03 19:05 ` Jason A. Donenfeld
2023-01-03 20:52 ` Andy Lutomirski
2023-01-03 19:19 ` Linus Torvalds
2023-01-03 19:35 ` Jason A. Donenfeld
2023-01-03 19:54 ` Linus Torvalds
2023-01-03 20:03 ` Jason A. Donenfeld
2023-01-03 20:15 ` Linus Torvalds
2023-01-03 20:25 ` Linus Torvalds [this message]
2023-01-03 20:44 ` Jason A. Donenfeld
2023-01-05 21:57 ` Yann Droneaud
2023-01-05 22:57 ` Jason A. Donenfeld
2023-01-06 1:02 ` Linus Torvalds
2023-01-06 2:08 ` Linus Torvalds
2023-01-06 2:42 ` Jason A. Donenfeld
2023-01-06 20:53 ` Andy Lutomirski
2023-01-06 21:10 ` Linus Torvalds
2023-01-10 11:01 ` Dr. Greg
2023-01-06 21:36 ` Jason A. Donenfeld
2023-01-06 21:42 ` Matthew Wilcox
2023-01-06 22:06 ` Linus Torvalds
2023-01-06 2:14 ` Jason A. Donenfeld
2023-01-09 10:34 ` Florian Weimer
2023-01-09 14:28 ` Linus Torvalds
2023-01-11 7:27 ` Eric Biggers
2023-01-11 12:07 ` Linus Torvalds
2023-01-01 16:29 ` [PATCH v14 3/7] x86: mm: Skip faulting instruction for VM_DROPPABLE faults Jason A. Donenfeld
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='CAHk-=wg4SRHF6AhYDcgyokN2BMjra91Ns4h9wWPachhf-x3=xQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=Jason@zx2c4.com \
--cc=adhemerval.zanella@linaro.org \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=patches@lists.linux.dev \
--cc=tglx@linutronix.de \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox