From: Kevin Daughtridge <kevin@kdau.com>
To: Jiri Slaby <jslaby@suse.cz>, Jiri Kosina <jkosina@suse.cz>
Cc: Henrik Rydberg <rydberg@euromail.se>,
Kevin Daughtridge <kevin@kdau.com>,
linux-input@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] HID: leave dev_rdesc unmodified and use it for comparisons
Date: Wed, 19 Sep 2012 09:53:06 -0700 [thread overview]
Message-ID: <5059F872.3080203@kdau.com> (raw)
In-Reply-To: <50597CAD.7010801@suse.cz>
On 09/19/12 01:05 N.U., Jiri Slaby wrote:
> AFAICS this is incorrect. Some drivers return pointers to their own
> static structure from their .report_fixup. Hence there are two problems:
> * leak, because kmemdup'ped start is never freed
> * invalid free -- kfree(device->rdesc) will try to free a static
> structure regards,
On 09/19/12 04:55 N.U., Jiri Kosina wrote:
> How do you avoid memory leak on 'start' here?
Hmm. I hadn't noticed that the other drivers are returning a static
structure. In that case, it seems that report_fixup itself is broken
from a memory perspective, in that it returns pointers to inconsistent
storage types depending on the driver. (As evidenced by how my first
patch version would have also caused invalid frees that weren't evident
from the declaration in hid.h.) I see two options:
1. Ugly workaround: make a temporary copy of the dev_rdesc, give it to
report_fixup, make a copy of the return, store that copy in rdesc, free
the temporary copy. Though ugly, this would at least involve the
smallest diff.
2. Standardize the behavior of the drivers' report_fixup
implementations. Given that some of them need to change the size of the
descriptor, modifying the passed structure is not an option. Probably
all of them should return a newly allocated structure, either a modified
copy of the input or a copy of their static, that can then be stored
directly in rdesc. Especially since report_fixup is only ever called
right before a copy is going to be taken anyway. (Adding constness to a
parameter isn't considered a severe ABI break, is it?)
Thoughts?
-Kevin
next prev parent reply other threads:[~2012-09-19 16:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-19 2:36 [PATCH v2] HID: leave dev_rdesc unmodified and use it for comparisons Kevin Daughtridge
2012-09-19 8:05 ` Jiri Slaby
2012-09-19 16:53 ` Kevin Daughtridge [this message]
2012-09-19 18:32 ` Henrik Rydberg
2012-09-19 11:47 ` Sergei Shtylyov
2012-09-19 11:55 ` Jiri Kosina
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=5059F872.3080203@kdau.com \
--to=kevin@kdau.com \
--cc=jkosina@suse.cz \
--cc=jslaby@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rydberg@euromail.se \
/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).