From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
"Pali Rohár" <pali@kernel.org>
Subject: Re: [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer
Date: Fri, 2 May 2025 16:52:51 +0300 [thread overview]
Message-ID: <aBTOMzlitljoDAob@smile.fi.intel.com> (raw)
In-Reply-To: <aBBdFoBbdl8GI6da@surfacebook.localdomain>
On Tue, Apr 29, 2025 at 08:01:10AM +0300, Andy Shevchenko wrote:
> Mon, Apr 28, 2025 at 04:30:13PM -0700, Dmitry Torokhov kirjoitti:
> > On Tue, Apr 22, 2025 at 09:56:45PM +0300, Andy Shevchenko wrote:
...
> > > + n = snprintf(priv->phys2, sizeof(priv->phys2), "%s/input1",
> > > + psmouse->ps2dev.serio->phys);
> > > + if (n >= sizeof(priv->phys2)) {
> > > + psmouse_err(psmouse,
> > > + "failed to prepare path to the trackstick device\n");
> > > + error = -E2BIG;
> > > + goto init_fail;
> >
> > So you just broke touchpad of some poor guy who had it working just fine
> > for many years. For maximum impact you should add BUG() or panic()
> > here.
>
> Ha-ha. You know that your speculation most likely so far from the truth.
And actually what you are telling about is not true at all. If the device was
working it means that the file node name is not cut, and hence this patch won't
anyhow change this behaviour. Otherwise, provide an example which can fail this
and still be working in the user space.
> > In all seriousness, it is OK to have truncated phys, rarely anyone looks
> > at it and if we get a report of it being truncated then we can consider
> > addressing the size (or we can decide to live with it truncated).
>
> In all seriousness, while I agree on the statement, the 4 drivers in Input
> subsystem break the build. It's the biggest obstacle now to enable WERROR=y,
> which is default, builds on `make W=1`. So, I already gave you chance to fix,
> instead I hear nothing back for a months (to be precise 2 months and a day
> passed from my first attempt that you didn't like), the problem still exists.
> Please, address this the way you like.
For the reference, the first approach:
https://lore.kernel.org/r/20250228121147.242115-1-andriy.shevchenko@linux.intel.com
where I also asked about this one, ano got no answer.
I really don't want to try anything new as it seems a big pushback to whatever
I propose. So, please consider fixing the issues rather sooner. I will be more
than happy to test.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-05-02 13:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 18:56 [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer Andy Shevchenko
2025-04-28 23:30 ` Dmitry Torokhov
2025-04-29 5:01 ` Andy Shevchenko
2025-05-02 13:52 ` Andy Shevchenko [this message]
2025-05-06 5:34 ` Dmitry Torokhov
2025-05-07 13:49 ` Andy Shevchenko
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=aBTOMzlitljoDAob@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pali@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;
as well as URLs for NNTP newsgroup(s).