All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Michal Hocko <mhocko@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Yafang Shao <laoar.shao@gmail.com>,
	jack@suse.cz, Vlastimil Babka <vbabka@suse.cz>,
	Dave Chinner <dchinner@redhat.com>,
	Christian Brauner <brauner@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Paul Moore <paul@paul-moore.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-bcachefs@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM
Date: Thu, 5 Sep 2024 11:24:56 -0400	[thread overview]
Message-ID: <20240905152456.GW9627@mit.edu> (raw)
In-Reply-To: <4ty2psn26sergqax6yhcs3htt2tsg3wuvrfyvfdvseom22zhqk@yppva6vxpmjz>

On Thu, Sep 05, 2024 at 10:05:15AM -0400, Kent Overstreet wrote:
> > That may be the currrent state of affiars; but is it
> > ****guaranteed**** forever and ever, amen, that GFP_KERNEL will never
> > fail if the amount of memory allocated was lower than a particular
> > multiple of the page size?  If so, what is that size?  I've checked,
> > and this is not documented in the formal interface.
> 
> Yeah, and I think we really need to make that happen, in order to head
> off a lot more sillyness in the future.

I don't think there's any "sillyness"; I hear that you believe that
it's silly, but I think what we have is totally fine.

I've done a quick check of ext4, and we do check the error returns in
most if not all of the calls where we pass in __GFP_NOFAIL and/or are
small allocations less than the block size.  We won't crash if someone
sends a patch which violates the documented guarantee of __GFP_NOFAIL.

So what's the sillynesss?

In any case, Michal has said ix-nay on making GFP_KERNEL == GFP_NOFAIL
for small allocations as documented guarantee, as opposed to the way
things work today, so as far as I'm concerned, the matter is closed.

	       	    	      	     	- Ted

  reply	other threads:[~2024-09-05 15:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-02  9:51 [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM Michal Hocko
2024-09-02  9:51 ` [PATCH 1/2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Michal Hocko
2024-09-05  9:28   ` kernel test robot
2024-09-02  9:51 ` [PATCH 2/2] Revert "mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN" Michal Hocko
2024-09-02  9:53 ` [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM Kent Overstreet
2024-09-02 21:52   ` Andrew Morton
2024-09-02 22:32     ` Kent Overstreet
2024-09-03  7:06       ` Michal Hocko
2024-09-04 16:15         ` Kent Overstreet
2024-09-04 16:50           ` Michal Hocko
2024-09-03 23:53       ` Kent Overstreet
2024-09-04  7:14         ` Michal Hocko
2024-09-04 16:05           ` Kent Overstreet
2024-09-04 16:46             ` Michal Hocko
2024-09-04 18:03               ` Kent Overstreet
2024-09-04 22:34                 ` Dave Chinner
2024-09-04 23:05                   ` Kent Overstreet
2024-09-05 11:26                 ` Michal Hocko
2024-09-05 13:53                   ` Theodore Ts'o
2024-09-05 14:05                     ` Kent Overstreet
2024-09-05 15:24                       ` Theodore Ts'o [this message]
2024-09-05 14:12                     ` Michal Hocko
2024-09-03  5:13     ` Christoph Hellwig
2024-09-04 16:27       ` Kent Overstreet
2024-09-04 17:01         ` Michal Hocko
2024-09-10 19:29 ` Andrew Morton
2024-09-10 19:37   ` Kent Overstreet

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=20240905152456.GW9627@mit.edu \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jmorris@namei.org \
    --cc=kent.overstreet@linux.dev \
    --cc=laoar.shao@gmail.com \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    /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.