From: Todd Brandt <todd.e.brandt@linux.intel.com>
To: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: p.jungkamp@gmx.net, Jonathan.Cameron@huawei.com,
srinivas.pandruvada@linux.intel.com, jkosina@suse.cz,
todd.e.brandt@intel.com
Subject: BUG: hid-sensor-ids code includes binary data in device name
Date: Thu, 09 Mar 2023 15:33:08 -0800 [thread overview]
Message-ID: <592bcdcbb3603cf5dfefd09abdd6916db4efc691.camel@linux.intel.com> (raw)
Hi all, I've run into an issue in 6.3.0-rc1 that causes problems with
ftrace and I've bisected it to this commit:
commit 98c062e8245199fa9121141a0bf1035dc45ae90e (HEAD, refs/bisect/bad)
Author: Philipp Jungkamp p.jungkamp@gmx.net
Date: Fri Nov 25 00:38:38 2022 +0100
HID: hid-sensor-custom: Allow more custom iio sensors
The known LUID table for established/known custom HID sensors was
limited to sensors with "INTEL" as manufacturer. But some vendors
such
as Lenovo also include fairly standard iio sensors (e.g. ambient
light)
in their custom sensors.
Expand the known custom sensors table by a tag used for the
platform
device name and match sensors based on the LUID as well as
optionally
on model and manufacturer properties.
Signed-off-by: Philipp Jungkamp p.jungkamp@gmx.net
Reviewed-by: Jonathan Cameron Jonathan.Cameron@huawei.com
Acked-by: Srinivas Pandruvada srinivas.pandruvada@linux.intel.com
Signed-off-by: Jiri Kosina jkosina@suse.cz
You're using raw data as part of the devname in the "real_usage"
string, but it includes chars other than ASCII, and those chars end
up being printed out in the ftrace log which is meant to be ASCII only.
- /* HID-SENSOR-INT-REAL_USAGE_ID */
- dev_name = kasprintf(GFP_KERNEL, "HID-SENSOR-INT-%s",
real_usage);
+ /* HID-SENSOR-TAG-REAL_USAGE_ID */
+ dev_name = kasprintf(GFP_KERNEL, "HID-SENSOR-%s-%s",
+ match->tag, real_usage);
My sleepgraph tool started to crash because it read these lines from
ftrace:
device_pm_callback_start: platform HID-SENSOR-INT-020b?.39.auto,
parent: 001F:8087:0AC2.0003, [suspend]
device_pm_callback_end: platform HID-SENSOR-INT-020b?.39.auto, err=0
The "HID-SENSOR-INT-020b?.39.auto" string includes a binary char that
kills
python3 code that loops through an ascii file as such:
File "/usr/bin/sleepgraph", line 5579, in executeSuspend
for line in fp:
File "/usr/lib/python3.10/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position
1568: invalid start byte
I've updated sleepgraph to handle random non-ascii chars, but other
tools
may suffer the same fate. Can you rewrite this to ensure that no binary
chars make it into the devname?
next reply other threads:[~2023-03-09 23:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 23:33 Todd Brandt [this message]
2023-03-10 9:51 ` BUG: hid-sensor-ids code includes binary data in device name srinivas pandruvada
2023-03-10 14:35 ` Philipp Jungkamp
2023-03-10 23:35 ` Todd Brandt
2023-03-17 5:49 ` Xu, Even
2023-03-17 15:37 ` Todd Brandt
2023-03-20 0:30 ` Xu, Even
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=592bcdcbb3603cf5dfefd09abdd6916db4efc691.camel@linux.intel.com \
--to=todd.e.brandt@linux.intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.jungkamp@gmx.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=todd.e.brandt@intel.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;
as well as URLs for NNTP newsgroup(s).