mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: aruiz@redhat.com
Cc: Shuah Khan <shuah@kernel.org>,
	linux-fsdevel@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 0/2] fuse: fix CUSE device node leak and add regression test
Date: Thu, 11 Jun 2026 12:28:41 +0200	[thread overview]
Message-ID: <CAJfpegsDNoT7MYDMdwFDmnZQNBK6FWd2o7KNncpyk6e2CAuMYQ@mail.gmail.com> (raw)
In-Reply-To: <20260408-wip-cuse-leak-fix-v1-0-1c028d575e97@redhat.com>

On Wed, 8 Apr 2026 at 17:23, Alberto Ruiz via B4 Relay
<devnull+aruiz.redhat.com@kernel.org> wrote:

> Patch 2 adds a kselftest that reproduces the bug by forcing cdev_alloc()
> to fail after device_add() has succeeded, then verifying that no /dev
> node is leaked.  To trigger the failure deterministically, a
> CONFIG_FAULT_INJECTION-guarded module parameter (cuse_inject_cdev_failure)
> is added to cuse.c.  The test falls back to failslab with stack-trace
> filtering when the parameter is unavailable.
>
> I'm on the fence about the fault injection parameter in patch 2 -- it's
> only a few lines and it's guarded behind CONFIG_FAULT_INJECTION, but I
> understand if it feels too intrusive for production code.  Happy to drop
> the kselftest or rework the injection approach if the maintainers prefer.
> The fix in patch 1 stands on its own regardless.

I don't think it's worth adding this to upstream, though I'm impressed
by the  thoroughness of your work.

I'll reference this patchset from commit header so the information is retained.

Thanks,
Miklos

      parent reply	other threads:[~2026-06-11 10:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08 15:23 Alberto Ruiz via B4 Relay
2026-04-08 15:23 ` [PATCH 1/2] fuse: fix device node leak in cuse_process_init_reply() Alberto Ruiz via B4 Relay
2026-06-11 10:22   ` Miklos Szeredi
2026-04-08 15:23 ` [PATCH 2/2] selftests: add CUSE device-node leak regression test Alberto Ruiz via B4 Relay
2026-06-11 10:28 ` Miklos Szeredi [this message]

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=CAJfpegsDNoT7MYDMdwFDmnZQNBK6FWd2o7KNncpyk6e2CAuMYQ@mail.gmail.com \
    --to=miklos@szeredi.hu \
    --cc=aruiz@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@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

all inboxes | Powered by JetHome®