All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: David Carlier <devnexen@gmail.com>
Cc: David Vernet <void@manifault.com>,
	Andrea Righi <arighi@nvidia.com>,
	linux-kernel@vger.kernel.org,
	Emil Tsalapatis <emil@etsalapatis.com>,
	sched-ext@lists.linux.dev
Subject: Re: [PATCH] sched_ext/selftests: Fix bpf_link leak on assertion failure
Date: Tue, 17 Mar 2026 08:09:39 -1000	[thread overview]
Message-ID: <ab7caad06bd6990657c2bfe5d11c5043@kernel.org> (raw)
In-Reply-To: <20260317174402.48082-1-devnexen@gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hello,

In numa.c and rt_stall.c, the assertions check for SCX_EXIT_NONE — i.e.
the scheduler ran without error. bpf_link__destroy() triggers unregistration
which changes uei.kind to SCX_EXIT_UNREG, so moving it before the assertions
would make them always fail. Did you run the selftests after this patch?

A simpler approach would be using __attribute__((cleanup())) to auto-destroy
the link on any return path:

  static inline void autolink_destroy(struct bpf_link **linkp)
  {
  	if (*linkp)
  		bpf_link__destroy(*linkp);
  }

  #define __autolink __attribute__((cleanup(autolink_destroy)))

Then each test just does:

  struct bpf_link *link __autolink = bpf_map__attach_struct_ops(...);

No reordering needed — the link auto-destroys on any return, including
early returns from assertion failures.

Thanks.

--
tejun

           reply	other threads:[~2026-03-17 18:09 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20260317174402.48082-1-devnexen@gmail.com>]

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=ab7caad06bd6990657c2bfe5d11c5043@kernel.org \
    --to=tj@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=devnexen@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=void@manifault.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.