From: Johan Hovold <johan@kernel.org>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
Andi Shyti <andi.shyti@kernel.org>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] i2c: dev: clean up registration
Date: Tue, 10 Nov 2026 14:07:06 +0100 [thread overview]
Message-ID: <avMW-hz61zXUbQWV@hovoldconsulting.com> (raw)
In-Reply-To: <r7a57zw5h253lhdecxdoagdcok4lobodiouutxxq3t237imdhy@n4t46uvgvf22>
On Tue, Nov 10, 2026 at 01:54:18PM +0100, Bartosz Golaszewski wrote:
> On Tue, Nov 10, 2026 at 01:42:29PM +0100, Johan Hovold wrote:
> > I had rejected that Sashiko finding as being too outlandish for us to
> > have to worry about. As I just in a reply to Bartosz:
> >
> > If a malicious actor has physical access to the machine, we have
> > bigger problems than worrying about them going out of their way
> > to cause a USB hub worker thread to hang. :)
> >
> > Limiting the critical section can possibly be done as a follow-up, but
> > it may not even be worth the effort doing that.
> >
>
> Why is limiting the scope of the semaphore such a big deal though? It's
> not a big change, literally just use scoped_guard() instead. Why would
> we commit incorrect code if we can correct it in a v3 with not much
> effort? You're fixing a use-case where user-space can hang a kernel
> thread, why not do it for corner-cases too?
A *malicious* actor with physical access (and CAP_SYS_PTRACE) can cause
a thread to hang while janking out an USB attached I2C adapter out a of
machine if they try really hard. Don't you see how silly that is?
I posted this patch months ago, but IIRC it will complicate things
somewhat without any relevant benefit. Probably just a larger diff which
is unnecessary for a patch marked for stable.
If Wolfram insists, I can revisit this, but I don't think it's needed.
Johan
next prev parent reply other threads:[~2026-11-10 13:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 10:20 [PATCH v2 0/3] i2c: dev: fix blocked adapter deregistration Johan Hovold
2026-08-27 10:20 ` [PATCH v2 1/3] " Johan Hovold
2026-11-09 15:08 ` Bartosz Golaszewski
2026-11-10 12:34 ` Johan Hovold
2026-11-12 11:07 ` Wolfram Sang
2026-08-27 10:20 ` [PATCH v2 2/3] i2c: dev: drop unnecessary sysfs device lookup Johan Hovold
2026-11-09 14:59 ` Bartosz Golaszewski
2026-11-10 11:46 ` Wolfram Sang
2026-11-12 11:07 ` Wolfram Sang
2026-08-27 10:20 ` [PATCH v2 3/3] i2c: dev: clean up registration Johan Hovold
2026-11-09 15:01 ` Bartosz Golaszewski
2026-11-10 11:50 ` Wolfram Sang
2026-11-10 12:42 ` Johan Hovold
2026-11-10 12:54 ` Bartosz Golaszewski
2026-11-10 13:07 ` Johan Hovold [this message]
2026-11-10 20:06 ` Wolfram Sang
2026-11-12 11:08 ` Wolfram Sang
2026-11-04 19:42 ` [PATCH v2 0/3] i2c: dev: fix blocked adapter deregistration Wolfram Sang
2026-11-05 8:18 ` Bartosz Golaszewski
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=avMW-hz61zXUbQWV@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=andi.shyti@kernel.org \
--cc=brgl@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wsa+renesas@sang-engineering.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.