All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-input@vger.kernel.org, Ping Cheng <Ping.Cheng@wacom.com>,
	Jason Gerecke <Jason.Gerecke@wacom.com>
Subject: Re: HID: wacom: check for wacom->shared before following the pointer
Date: Thu, 19 Mar 2015 12:06:02 -0400	[thread overview]
Message-ID: <20150319160601.GC18134@mail.corp.redhat.com> (raw)
In-Reply-To: <20150319155425.GA727@mwanda>

Hi Dan,

On Mar 19 2015 or thereabouts, Dan Carpenter wrote:
> Hello Benjamin Tissoires,
> 
> This is a semi-automatic email about new static checker warnings.
> 
> The patch e2c7d8877e5c: "HID: wacom: check for wacom->shared before 
> following the pointer" from Mar 5, 2015, leads to the following 
> Smatch complaint:
> 
> drivers/hid/wacom_wac.c:602 wacom_intuos_inout()
> 	 error: we previously assumed 'wacom->shared' could be null (see line 584)
> 
> drivers/hid/wacom_wac.c
>    583	
>    584		if (wacom->shared) {
> 
> In the original code we checked "if (features->quirks & WACOM_QUIRK_MULTI_INPUT)"
> which is ensures that "wacom->shared" is non-NULL.
> 
>    585			wacom->shared->stylus_in_proximity = true;
>    586	
>    587			if (wacom->shared->touch_down)
>    588				return 1;
>    589		}
>    590	
>    591		/* in Range while exiting */
>    592		if (((data[1] & 0xfe) == 0x20) && wacom->reporting_data) {
>    593			input_report_key(input, BTN_TOUCH, 0);
>    594			input_report_abs(input, ABS_PRESSURE, 0);
>    595			input_report_abs(input, ABS_DISTANCE, wacom->features.distance_max);
>    596			return 2;
>    597		}
>    598	
>    599		/* Exit report */
>    600		if ((data[1] & 0xfe) == 0x80) {
>    601			if (features->quirks & WACOM_QUIRK_MULTI_INPUT)
>                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> We still check for that here.  Smatch is confused.
> 
>    602				wacom->shared->stylus_in_proximity = false;
>                                 ^^^^^^^^^^^^^
> This is not a bug, but change the previous change to
> "if (wacom->shared)" would make the code more consistent.

Yep, I agree. That's for these cases that I preferred having a test
against wacom->shared not null rather than (features->quirks &
WACOM_QUIRK_MULTI_INPUT).

> 
>    603			wacom->reporting_data = false;
>    604	
> 
> [ snip ]
> 
>   1072  static int wacom_24hdt_irq(struct wacom_wac *wacom)
>   1073  {
>   1074          struct input_dev *input = wacom->input;
>   1075          unsigned char *data = wacom->data;
>   1076          int i;
>   1077          int current_num_contacts = data[61];
>   1078          int contacts_to_send = 0;
>   1079          int num_contacts_left = 4; /* maximum contacts per packet */
>   1080          int byte_per_packet = WACOM_BYTES_PER_24HDT_PACKET;
>   1081          int y_offset = 2;
>   1082          static int contact_with_no_pen_down_count = 0;
>   1083  
>   1084          if (wacom->features.type == WACOM_27QHDT) {
>   1085                  current_num_contacts = data[63];
>   1086                  num_contacts_left = 10;
>   1087                  byte_per_packet = WACOM_BYTES_PER_QHDTHID_PACKET;
>   1088                  y_offset = 0;
>   1089          }
>   1090  
>   1091          /*
>   1092           * First packet resets the counter since only the first
>   1093           * packet in series will have non-zero current_num_contacts.
>   1094           */
>   1095          if (current_num_contacts) {
>   1096                  wacom->num_contacts_left = current_num_contacts;
>   1097                  contact_with_no_pen_down_count = 0;
>   1098          }
>   1099  
>   1100          contacts_to_send = min(num_contacts_left, wacom->num_contacts_left);
>   1101  
>   1102          for (i = 0; i < contacts_to_send; i++) {
>   1103                  int offset = (byte_per_packet * i) + 1;
>   1104                  bool touch = (data[offset] & 0x1) && !wacom->shared->stylus_in_proximity;
>                                                               ^^^^^^^^^^^^^
> I assume this hardware is always quirky so this won't cause a NULL
> deref?

Yes. 24hdt has the quirk WACOM_QUIRK_MULTI_INPUT, so wacom->shared can
not be null. I wonder what we could put in the code to make static
checkers happy...


Thanks for the report and the analysis!

Cheers,
Benjamin

> 
>   1105                  int slot = input_mt_get_slot_by_key(input, data[offset + 1]);
>   1106  
>   1107                  if (slot < 0)
>   1108                          continue;
> 
> regards,
> dan carpenter

  reply	other threads:[~2015-03-19 16:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19 15:54 HID: wacom: check for wacom->shared before following the pointer Dan Carpenter
2015-03-19 16:06 ` Benjamin Tissoires [this message]
2015-03-19 16:41   ` Ping Cheng
2015-03-19 17:08     ` Benjamin Tissoires
2015-03-19 16:50   ` Dan Carpenter

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=20150319160601.GC18134@mail.corp.redhat.com \
    --to=benjamin.tissoires@redhat.com \
    --cc=Jason.Gerecke@wacom.com \
    --cc=Ping.Cheng@wacom.com \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-input@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 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.