From: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, gregkh@suse.de,
linux-input@vger.kernel.org, kay.sievers@vrfy.org
Subject: Re: [PATCH 0/4] fix some improper uses of dev_set_name
Date: Wed, 22 Apr 2009 18:06:11 -0300 [thread overview]
Message-ID: <20090422210610.GL4691@vespa.holoscopio.com> (raw)
In-Reply-To: <20090422054531.GD9009@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
On Tue, Apr 21, 2009 at 10:45:31PM -0700, Greg KH wrote:
> On Mon, Apr 20, 2009 at 09:17:12PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > dev_set_name expects a format string. Many of its uses, however, blindly
> > call it with a string variable that comes from some external, perhaps
> > unreliable source. Some of those uses are safe, like those in the third
> > patch in the series and most of those not fixed by any of them. Some few
> > remaining uses may require some more attention to decide if a patch is
> > really required. Perhaps converting all of them for safeness is a good
> > compromise.
> >
> > Thadeu Lima de Souza Cascardo (4):
> > driver core: use string format when name is another device's name
> > driver core: use string format when name is given to an exported
> > function
>
> These two patches were a bit more than just the "driver core". Care to
> split them up into the subsystem-proper sections and send them to the
> different subsystem maintainers?
>
> I don't see anything here that can come from a user supplied string, do
> you? So it's a pretty low priority.
>
> thanks,
>
> greg k-h
OK. I will do the split by subsystem and send each one separately to the
maintainer and lkml.
Besides the fourth patch, I think. I will do some more check and,
perhaps, even send it to stable.
The third one will be sent to input subsystem and it is pretty much
2.6.31 material.
For the other two, I've separated them (and joined them) because the
situation is pretty much the same as well as the decision about applying
them into stable, rc, next or not at all.
The first one is when you set a device name using another device's name,
like this:
dev_set_name(&idkp->dev, dev_name(&drive->gendev));
I've never seen a device name with a '%', but there's currently nothing
stopping any driver of doing that. Perhaps, it is a case-by-case thing,
as gendev may never be named like that. But we may as well decide that
no device may be named like that ever and document this properly or put
the code there that will prohibit that. Then, this patch is useless.
The second one is the case when the function is exported and an
out-of-tree driver may use it giving a name that contains a '%'. If we
don't care about out-of-tree drivers, I may even check every in-tree
user and fix the user instead of/besides the callee. If we DO care about
out-of-tree drivers TOO much, this may even be stable material.
Since I am not sure what the position/decision is about each one, I
would like some input while I work into splitting them into subsystems.
Regards,
Cascardo.
After this message, I think linux-input and Kay may be left out of the
loop.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-04-22 21:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-21 0:17 Thadeu Lima de Souza Cascardo
[not found] ` <cover.1240272928.git.cascardo@holoscopio.com>
2009-04-21 0:17 ` [PATCH 1/4] driver core: use string format when name is another device's name Thadeu Lima de Souza Cascardo
2009-04-21 0:17 ` [PATCH 2/4] driver core: use string format when name is given to an exported function Thadeu Lima de Souza Cascardo
2009-04-21 0:17 ` [PATCH 3/4] input: set the device's name and copy it to private version Thadeu Lima de Souza Cascardo
2009-04-21 0:17 ` [PATCH 4/4] ARM: use put_device instead of kfree Thadeu Lima de Souza Cascardo
2009-04-22 5:45 ` [PATCH 0/4] fix some improper uses of dev_set_name Greg KH
2009-04-22 21:06 ` Thadeu Lima de Souza Cascardo [this message]
2009-05-11 1:09 ` Dmitry Torokhov
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=20090422210610.GL4691@vespa.holoscopio.com \
--to=cascardo@holoscopio.com \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®