From: Guenter Roeck <linux@roeck-us.net>
To: Maximilian Luz <luzmaximilian@gmail.com>
Cc: "Jean Delvare" <jdelvare@suse.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Hans de Goede" <hdegoede@redhat.com>,
"Ivor Wanders" <ivor@iwanders.net>,
linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org, linux-hwmon@vger.kernel.org
Subject: Re: [PATCH 2/3] hwmon: surface_temp: Add support for sensor names
Date: Tue, 16 Apr 2024 14:08:09 -0700 [thread overview]
Message-ID: <8d62af9d-281a-44c0-a40c-93ae76827705@roeck-us.net> (raw)
In-Reply-To: <97d0f68f-63da-4f72-ae8d-89fbf9aadf62@gmail.com>
On Tue, Apr 16, 2024 at 09:00:05PM +0200, Maximilian Luz wrote:
> On 4/16/24 3:30 PM, Guenter Roeck wrote:
> > On Sat, Mar 30, 2024 at 12:24:01PM +0100, Maximilian Luz wrote:
>
> [...]
>
> > > +static int ssam_tmp_get_name(struct ssam_device *sdev, u8 iid, char *buf, size_t buf_len)
> > > +{
> > > + struct ssam_tmp_get_name_rsp name_rsp;
> > > + int status;
> > > +
> > > + status = __ssam_tmp_get_name(sdev->ctrl, sdev->uid.target, iid, &name_rsp);
> > > + if (status)
> > > + return status;
> > > +
> > > + /*
> > > + * This should not fail unless the name in the returned struct is not
> > > + * null-terminated or someone changed something in the struct
> > > + * definitions above, since our buffer and struct have the same
> > > + * capacity by design. So if this fails blow this up with a warning.
> > > + * Since the more likely cause is that the returned string isn't
> > > + * null-terminated, we might have received garbage (as opposed to just
> > > + * an incomplete string), so also fail the function.
> > > + */
> > > + status = strscpy(buf, name_rsp.name, buf_len);
> > > + WARN_ON(status < 0);
> >
> > Not acceptable. From include/asm-generic/bug.h:
> >
> > * Do not use these macros when checking for invalid external inputs
> > * (e.g. invalid system call arguments, or invalid data coming from
> > * network/devices), and on transient conditions like ENOMEM or EAGAIN.
> > * These macros should be used for recoverable kernel issues only.
> >
>
> Hmm, I always interpreted that as "do not use for checking user-defined
> input", which this is not.
>
"invalid data coming from network/devices" is not user-defined input.
> The reason I added/requested it here was to check for "bugs" in how we
> think the interface behaves (and our definitions related to it) as the
> interface was reverse-engineered. Generally, when this fails I expect
> that we made some mistake in our code (or the things we assume about the
> interface), which likely causes us to interpret the received data as
> "garbage" (and not the EC sending corrupted data, which it is generally
> not due to CRC checking and validation in the SAM driver). Hence, I
> personally would prefer if this blows up in a big warning with a trace
> attached to it, so that an end-user can easily report this to us and
> that we can appropriately deal with it. As opposed to some one-line
> error message that will likely get overlooked or not taken as seriously.
>
I have heard the "This backtrace is absolutely essential" argument before,
including the "will be fixed" part. Chromebooks report more than 500,000
warning backtraces _every single day_. None of them is getting fixed.
> If you still insist, I could change that to a dev_err() message. Or
> maybe make the comment a bit clearer.
dev_err() would be acceptable. WARN() or WARN_ON() are no-go.
Guenter
next prev parent reply other threads:[~2024-04-16 21:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-30 11:23 [PATCH 0/3] Add thermal sensor driver for Surface Aggregator Maximilian Luz
2024-03-30 11:24 ` [PATCH 1/3] hwmon: Add thermal sensor driver for Surface Aggregator Module Maximilian Luz
2024-03-30 11:58 ` Guenter Roeck
2024-03-30 12:58 ` Maximilian Luz
2024-04-08 13:32 ` Hans de Goede
2024-04-08 13:33 ` Hans de Goede
2024-04-16 13:15 ` Guenter Roeck
2024-04-16 13:27 ` Guenter Roeck
2024-04-16 18:12 ` Maximilian Luz
2024-03-30 11:24 ` [PATCH 2/3] hwmon: surface_temp: Add support for sensor names Maximilian Luz
2024-04-08 13:34 ` Hans de Goede
2024-04-16 13:30 ` Guenter Roeck
2024-04-16 19:00 ` Maximilian Luz
2024-04-16 21:08 ` Guenter Roeck [this message]
2024-05-02 20:05 ` Maximilian Luz
2024-04-16 21:34 ` Ivor Wanders
2024-05-02 20:04 ` Maximilian Luz
2024-03-30 11:24 ` [PATCH 3/3] platform/surface: aggregator_registry: Add support for thermal sensors on the Surface Pro 9 Maximilian Luz
2024-04-08 15:22 ` Hans de Goede
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=8d62af9d-281a-44c0-a40c-93ae76827705@roeck-us.net \
--to=linux@roeck-us.net \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=ivor@iwanders.net \
--cc=jdelvare@suse.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luzmaximilian@gmail.com \
--cc=platform-driver-x86@vger.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 read-only IMAP folder(s) and NNTP newsgroup(s).