public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Tissoires <bentiss@kernel.org>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: Jiri Kosina <jikos@kernel.org>, Shuah Khan <shuah@kernel.org>,
	 linux-input@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org,  kernel test robot <lkp@intel.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/4] selftests/hid: fix compilation when bpf_wq and hid_device are not exported
Date: Fri, 13 Mar 2026 14:28:06 +0100	[thread overview]
Message-ID: <abQQQ0KNxJeO3JIZ@beelink> (raw)
In-Reply-To: <20260313095731-682bbab2-5861-4aea-bc83-420492400c19@linutronix.de>

On Mar 13 2026, Thomas Weißschuh wrote:
> On Fri, Mar 13, 2026 at 08:40:24AM +0100, Benjamin Tissoires wrote:
> > This can happen in situations when CONFIG_HID_SUPPORT is set to no, or
> > some complex situations where struct bpf_wq is not exported.
> > 
> > So do the usual dance of hiding them before including vmlinux.h, and
> > then redefining them and make use of CO-RE to have the correct offsets.
> > 
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202603111558.KLCIxsZB-lkp@intel.com/
> > Cc: stable@vger.kernel.org
> 
> 'Fixes' missing? Also for patch 2 in the series.
> 
> > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> 
> Reviewed-by: Thomas Wei�schuh <thomas.weissschuh@linutronix.de>

Thanks!

> 
> (Some nits below, feel free to ignore them)
> 
> > ---
> >  tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> > index 80ab60905865..2c6ec907dd05 100644
> > --- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> > +++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> > @@ -8,9 +8,11 @@
> >  /* "undefine" structs and enums in vmlinux.h, because we "override" them below */
> >  #define hid_bpf_ctx hid_bpf_ctx___not_used
> >  #define hid_bpf_ops hid_bpf_ops___not_used
> > +#define hid_device hid_device___not_used
> >  #define hid_report_type hid_report_type___not_used
> >  #define hid_class_request hid_class_request___not_used
> >  #define hid_bpf_attach_flags hid_bpf_attach_flags___not_used
> > +#define bpf_wq bpf_wq___not_used
> 
> 'bpf' would sort before 'hid' alphabetically.

ack (note that the last 3 are not sorted, oops).

> 
> >  #define HID_INPUT_REPORT         HID_INPUT_REPORT___not_used
> >  #define HID_OUTPUT_REPORT        HID_OUTPUT_REPORT___not_used
> >  #define HID_FEATURE_REPORT       HID_FEATURE_REPORT___not_used
> > @@ -29,9 +31,11 @@
> >  
> >  #undef hid_bpf_ctx
> >  #undef hid_bpf_ops
> > +#undef hid_device
> >  #undef hid_report_type
> >  #undef hid_class_request
> >  #undef hid_bpf_attach_flags
> > +#undef bpf_wq
> >  #undef HID_INPUT_REPORT
> >  #undef HID_OUTPUT_REPORT
> >  #undef HID_FEATURE_REPORT
> > @@ -55,6 +59,14 @@ enum hid_report_type {
> >  	HID_REPORT_TYPES,
> >  };
> >  
> > +struct hid_device {
> > +	unsigned int id;
> > +} __attribute__((preserve_access_index));
> > +
> > +struct bpf_wq {
> > +	__u64 __opaque[2];
> > +};
> 
> The fields are never used, would a forward-declaration be sufficient?
> 
> struct bpf_wq;
> 
> Then you could also avoid the #define dance for that struct.

Unfortunately no. The fields are not used, but the struct is stored in
struct elem, and we use that struct size to compute the size of the map
elements. So we need to tell the compiler how much memory it needs to
be.

Cheers,
Benjamin

> 
> > +
> >  struct hid_bpf_ctx {
> >  	struct hid_device *hid;
> >  	__u32 allocated_size;
> > 
> > -- 
> > 2.52.0
> > 
> 

  reply	other threads:[~2026-03-13 13:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13  7:40 [PATCH 0/4] HID: bpf fixes for 7.0/7.1 Benjamin Tissoires
2026-03-13  7:40 ` [PATCH 1/4] selftests/hid: fix compilation when bpf_wq and hid_device are not exported Benjamin Tissoires
2026-03-13  9:02   ` Thomas Weißschuh
2026-03-13 13:28     ` Benjamin Tissoires [this message]
2026-03-13 15:58   ` Jiri Kosina
2026-03-13  7:40 ` [PATCH 2/4] HID: bpf: prevent buffer overflow in hid_hw_request Benjamin Tissoires
2026-03-13 15:58   ` Jiri Kosina
2026-03-16 15:59 ` (subset) [PATCH 0/4] HID: bpf fixes for 7.0/7.1 Benjamin Tissoires

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=abQQQ0KNxJeO3JIZ@beelink \
    --to=bentiss@kernel.org \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=thomas.weissschuh@linutronix.de \
    /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