linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
To: todd.e.brandt@linux.intel.com, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org, Even Xu <even.xu@intel.com>
Cc: p.jungkamp@gmx.net, Jonathan.Cameron@huawei.com, jkosina@suse.cz,
	todd.e.brandt@intel.com
Subject: Re: BUG: hid-sensor-ids code includes binary data in device name
Date: Fri, 10 Mar 2023 01:51:41 -0800	[thread overview]
Message-ID: <317ce138f63b9317ac7be1949a68db5117c19b92.camel@linux.intel.com> (raw)
In-Reply-To: <592bcdcbb3603cf5dfefd09abdd6916db4efc691.camel@linux.intel.com>

+Even

On Thu, 2023-03-09 at 15:33 -0800, Todd Brandt wrote:
> 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
> 

Here tag is:
.tag = "INT",
.luid = "020B000000000000",


The LUID is still a string. Probably too long for a dev_name.

Even,

Please check.

Thanks.
Srinivas


> 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?
> 


  reply	other threads:[~2023-03-10  9:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09 23:33 BUG: hid-sensor-ids code includes binary data in device name Todd Brandt
2023-03-10  9:51 ` srinivas pandruvada [this message]
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=317ce138f63b9317ac7be1949a68db5117c19b92.camel@linux.intel.com \
    --to=srinivas.pandruvada@linux.intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=even.xu@intel.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=p.jungkamp@gmx.net \
    --cc=todd.e.brandt@intel.com \
    --cc=todd.e.brandt@linux.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).