From: "Derek J. Clark" <derekjohn.clark@gmail.com>
To: Tristan Madani <tristmd@gmail.com>,
Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org,
Tristan Madani <tristan@talencesecurity.com>
Subject: Re: [PATCH] HID: hid-oxp: use cancel_delayed_work_sync() in remove
Date: Fri, 04 Sep 2026 16:58:07 -0700 [thread overview]
Message-ID: <F0F0B5FF-2527-4577-8EAB-B09D45566824@gmail.com> (raw)
In-Reply-To: <178855662286.3192124.2102579968112413785@gmail.com>
On September 4, 2026 2:17:02 PM PDT, Tristan Madani <tristmd@gmail.com> wrote:
>Hi Derek,
>
>Thanks for the review.
>
>One thing the Sashiko bot flagged, and I think it's valid: if
>oxp_hid_probe() returns early on an unknown usage page (the
>default: return 0 path), the delayed work items are never
>initialized via INIT_DELAYED_WORK(). In that case,
>cancel_delayed_work_sync() in remove() would call __flush_work()
>on a zero-filled work struct, which hits WARN_ON(!work->func).
>
>The non-sync cancel_delayed_work() didn't trigger this because it
>never calls __flush_work().
>
>Do you think this path is actually reachable in practice, or are
>the usage page IDs exhaustive for all matched devices? If it can
>happen, I can send a v2 that guards the cancels.
>
If the usage page rejects init then I think we can safely assume that it will be an effective gate.
There's a series in the works ATM that will make drvdata unique per hid dev after the usage page checka, so we could also wait for that and if it's not fixed by that series then gate on drvdata not being NULL.
Cheers,
Derek
>Thanks,
>Tristan
prev parent reply other threads:[~2026-09-04 23:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 10:58 [PATCH] HID: hid-oxp: use cancel_delayed_work_sync() in remove Tristan Madani
2026-09-04 11:11 ` sashiko-bot
2026-09-04 14:23 ` Derek J. Clark
2026-09-04 21:17 ` Tristan Madani
2026-09-04 23:58 ` Derek J. Clark [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=F0F0B5FF-2527-4577-8EAB-B09D45566824@gmail.com \
--to=derekjohn.clark@gmail.com \
--cc=bentiss@kernel.org \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tristan@talencesecurity.com \
--cc=tristmd@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox