All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-xfs@vger.kernel.org, djwong@kernel.org, aalbersh@kernel.org
Subject: Re: [PATCH 0/3 V3] libxfs: better cache allocation error handling
Date: Mon, 28 Sep 2026 01:16:32 -0700	[thread overview]
Message-ID: <aroiYIl-CQ34_qee@infradead.org> (raw)
In-Reply-To: <20260925194535.397036-1-sandeen@redhat.com>

On Fri, Sep 25, 2026 at 02:41:42PM -0500, Eric Sandeen wrote:
> OK, 3rd try.
> 
> This is to handle an underlying problem that an actual ENOMEM cache
> node allocation failure is indistinguishable from "current cache full"
> and so ENOMEM may send us into a pointless cache-expansion loop which
> ultimately overflows the cache size variable, rather than just reporting
> the bad news up the chain to callers.
> 
> Darrick suggested "I think I'd almost rather we change cache_node_allocate
> to return int and the cache node as an outparam since we do that elsewhere"
> 
> on the last review cycle, and so I've done that here, I agree that it
> is cleaner.

Sorry for chiming in so late, but wouldn't it make more sense to keep
returning the node, and have a bool for what to if it is NULL?
The 0/1/-errno pattern already requires a lot of attention in the kernel,
but in userland where we have errno and -1 returns that are usually not
specifically checked it feels like even more trouble waiting to happen.

That being said, the changes themselves do look correct, so this should
not be a strong objection.

  parent reply	other threads:[~2026-09-28  8:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25 19:41 [PATCH 0/3 V3] libxfs: better cache allocation error handling Eric Sandeen
2026-09-25 19:41 ` [PATCH 1/3] libxfs: change cache_node_allocate function signature Eric Sandeen
2026-09-25 22:56   ` Darrick J. Wong
2026-09-25 19:41 ` [PATCH 2/3] libxfs: Return -ENOMEM on actual cache node allocation failures Eric Sandeen
2026-09-25 22:58   ` Darrick J. Wong
2026-09-28 15:07     ` Eric Sandeen
2026-09-25 19:41 ` [PATCH 3/3] libxfs: do not allow cache growth to overflow Eric Sandeen
2026-09-25 22:59   ` Darrick J. Wong
2026-09-28  8:16 ` Christoph Hellwig [this message]
2026-09-28 15:05   ` [PATCH 0/3 V3] libxfs: better cache allocation error handling Eric Sandeen

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=aroiYIl-CQ34_qee@infradead.org \
    --to=hch@infradead.org \
    --cc=aalbersh@kernel.org \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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.