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:
signature.asc
Description: Digital signature
