linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Jann Horn <jannh@google.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	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>,
	Christian Brauner <brauner@kernel.org>,
	David Hildenbrand <dhildenb@redhat.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings
Date: Mon, 10 Jun 2024 14:00:21 +0200	[thread overview]
Message-ID: <Zmbq1dGPIYdRLw5_@tiehlicka> (raw)
In-Reply-To: <CAG48ez1k0J013tYLfmnT8NXRpG_5BR10xnH8r-yRvTLpJe-nLA@mail.gmail.com>

On Fri 07-06-24 17:50:34, Jann Horn wrote:
[...]
> Or, from a different angle: You're trying to allocate memory, and you
> can't make forward progress until that memory has been allocated
> (unless the process is killed). That's what GFP_KERNEL is for. Stuff
> like "__GFP_NOWARN | __GFP_NORETRY" is for when you have a backup plan
> that lets you make progress (perhaps in a slightly less efficient way,
> or by dropping some incoming data, or something like that), and it
> hints to the page allocator that it doesn't have to try hard to
> reclaim memory if it can't find free memory quickly.

Correct. A psedu-busy wait for allocation to succeed sounds like a very
bad idea to imprint into ABI. Is there really any design requirement to
make these mappings to never cause the OOM killer?

Making the content dropable under memory pressure because it is
inherently recoverable is something else (this is essentially an
implicit MADV_FREE semantic) but putting a requirement on the memory
allocation on the fault sounds just wrong to me.

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2024-06-10 12:00 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-28 12:19 [PATCH v16 0/5] implement getrandom() in vDSO Jason A. Donenfeld
2024-05-28 12:19 ` [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings Jason A. Donenfeld
2024-05-28 20:41   ` Frank van der Linden
2024-05-28 20:51     ` Jason A. Donenfeld
2024-05-31 10:48   ` Jann Horn
2024-05-31 12:13     ` Jason A. Donenfeld
2024-05-31 13:00       ` Jann Horn
2024-06-07 14:35         ` Jason A. Donenfeld
2024-06-07 15:12           ` Jann Horn
2024-06-07 15:50             ` Jann Horn
2024-06-10 12:00               ` Michal Hocko [this message]
2024-06-14 18:35                 ` Jason A. Donenfeld
2024-06-07 18:40   ` Andy Lutomirski
2024-05-28 12:19 ` [PATCH v16 2/5] random: add vgetrandom_alloc() syscall Jason A. Donenfeld
2024-05-31  3:59   ` Eric Biggers
2024-06-01 10:56     ` Jason A. Donenfeld
2024-06-04 17:22       ` Eric Biggers
2024-06-07 14:41         ` Jason A. Donenfeld
2024-06-07 14:45           ` Jason A. Donenfeld
2024-05-28 12:19 ` [PATCH v16 3/5] arch: allocate vgetrandom_alloc() syscall number Jason A. Donenfeld
2024-05-28 13:08   ` Geert Uytterhoeven
2024-05-28 13:10     ` Jason A. Donenfeld
2024-05-28 13:28       ` Jason A. Donenfeld
2024-05-31  2:26         ` Eric Biggers
2024-06-01 10:58           ` Jason A. Donenfeld
2024-05-28 12:19 ` [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation Jason A. Donenfeld
2024-05-31 19:12   ` Randy Dunlap
2024-05-31 19:15   ` Randy Dunlap
2024-06-07 15:37     ` Jason A. Donenfeld
2024-05-31 23:06   ` Andy Lutomirski
2024-06-07 15:52     ` Jason A. Donenfeld
2024-06-05 21:03   ` Thomas Gleixner
2024-06-05 22:10     ` Thomas Gleixner
2024-06-07 15:59       ` Jason A. Donenfeld
2024-06-07 16:32     ` Jason A. Donenfeld
2024-06-07 18:39   ` Andy Lutomirski
2024-05-28 12:19 ` [PATCH v16 5/5] x86: vdso: Wire up getrandom() vDSO implementation Jason A. Donenfeld
2024-05-31  3:38   ` Eric Biggers
2024-06-07 15:27     ` Jason A. Donenfeld
2024-05-31 19:16   ` Randy Dunlap
2024-06-07 15:30     ` Jason A. Donenfeld
2024-06-05 21:41   ` Thomas Gleixner
2024-06-07 15:32     ` Jason A. Donenfeld
2024-05-28 14:46 ` [PATCH v16 0/5] implement getrandom() in vDSO 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=Zmbq1dGPIYdRLw5_@tiehlicka \
    --to=mhocko@suse.com \
    --cc=Jason@zx2c4.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=arnd@arndb.de \
    --cc=brauner@kernel.org \
    --cc=carlos@redhat.com \
    --cc=dhildenb@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=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;
as well as URLs for NNTP newsgroup(s).