Re: [PATCH 07/18] lirc driver for the CommandIR USB Transceiver

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Jonathan Corbet
Date: Wednesday, September 10, 2008 - 10:09 am

This driver has real locking problems.  Parts of it depend on the BKL, but
I would have a hard time arguing for the addition of new BKL users in this
century.  The assumption that ->open() is called under the BKL no longer
holds.  It's really time to put a proper lock here.

This driver also needs a lot of "static" keywords thrown in.


So this driver only handles a single device?


As with a previous driver, a more descriptive name than "usb_skel" would be
nice.

As far as I can tell, the kref here is just extra overhead.  Why not just
free the structure in cmdir_release()?


This struck me as a little weird, so I went and looked at where it is used:


[...]

I don't get it.  Something is wrong with sprintf()?


[...] 


This kind of stuff looks like a recipe for confusion.  Why not just deal
with the minor number as it is?


As noted before, that won't work.


For devfs??  Again, this messing around with the minor number looks like
trouble.


I bet that could be implemented without a loop.



So it ignores the count the user asked for and stuffs the full length down
there anyway?


Again, devfs compatibility is probably not needed anymore.


Who is the consumer of these exports?  (OK, I found it later).


So we have a command parser built into this driver.  It looks like somebody
wanted to avoid ioctl() at all costs.  But ioctl() exists for a reason, and
this looks like a good use for it to me.  Of course, now this is a
user-space API which will be hard to change, but I think consideration
should be given to doing just that.


This code never checks minor for validity, it just assumes that the device
exists - and that the current process has the right to mess with it.

[...]


And here it ignores junk if an "=" has not been seen yet.


Why no locks?  This code is messing with a global buffer.


I will confess that I have no clue what this function is really trying to
do.  I also note, though, that the only call to it is commented out.  So it
should maybe just go away?


Why GFP_ATOMIC?  Somehow the comment fails to shed much light.



'0' was too clear?




This looks like mdelay() in disguise?  Perhaps something that sleeps would
be even better (haven't looked at the calling context yet)?


Ah, this is why those functions are exported?  Is there any reason not to
just link the whole mess together into a single module?


Looks like memset() to me.


Hmm...  num_data_bytes can be 60, so num_data values can be 20, so i*4+3
can be 83, you've just overflowed the buffer.


Hmm...I think there ought to be a better way.  Even before considering
endian problems.


That's a global buffer - what's protecting it from concurrent access?

[...]


I assume that compatibility is not needed now?  In that case, this code
(and safe_udelay()) can go away.

jon
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 0/18] linux infrared remote control drivers, Jarod Wilson, (Mon Sep 8, 9:05 pm)
[PATCH 01/18] lirc core device driver infrastructure, Jarod Wilson, (Mon Sep 8, 9:05 pm)
[PATCH 05/18] lirc driver for i2c-based IR receivers, Jarod Wilson, (Mon Sep 8, 9:05 pm)
[PATCH 15/18] lirc driver for the SIR IrDA port, Jarod Wilson, (Mon Sep 8, 9:06 pm)
Re: [PATCH 0/18] linux infrared remote control drivers, Chris Wedgwood, (Mon Sep 8, 9:36 pm)
Re: [PATCH 0/18] linux infrared remote control drivers, Alexey Dobriyan, (Tue Sep 9, 12:06 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Sebastian Siewior, (Tue Sep 9, 12:40 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Janne Grunau, (Tue Sep 9, 1:32 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Sebastian Siewior, (Tue Sep 9, 5:33 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Christoph Hellwig, (Tue Sep 9, 5:46 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Hellwig, (Tue Sep 9, 6:01 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Stefan Richter, (Tue Sep 9, 6:27 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Jarod Wilson, (Tue Sep 9, 8:23 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Jonathan Corbet, (Tue Sep 9, 8:33 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Lennart Sorensen, (Tue Sep 9, 11:27 am)
Re: [PATCH 0/18] linux infrared remote control drivers, Jarod Wilson, (Tue Sep 9, 11:34 am)
Re: [PATCH 02/18] lirc serial port receiver/transmitter de ..., Stefan Lippers-Hollmann, (Tue Sep 9, 12:51 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Hellwig, (Wed Sep 10, 5:29 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Dmitry Torokhov, (Wed Sep 10, 6:08 am)
Re: [PATCH 06/18] lirc driver for the ATI USB RF remote re ..., Christoph Hellwig, (Wed Sep 10, 6:14 am)
Re: [PATCH 06/18] lirc driver for the ATI USB RF remote re ..., Christoph Hellwig, (Wed Sep 10, 7:19 am)
Re: [PATCH 05/18] lirc driver for i2c-based IR receivers, Jonathan Corbet, (Wed Sep 10, 8:42 am)
Re: [PATCH 07/18] lirc driver for the CommandIR USB Transc ..., Jonathan Corbet, (Wed Sep 10, 10:09 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Gerd Hoffmann, (Thu Sep 11, 1:47 am)
Re: [PATCH 09/18] lirc driver for the Streamzap PC Receiver, Jonathan Corbet, (Thu Sep 11, 8:22 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Thu Sep 11, 9:41 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Thu Sep 11, 11:03 am)
Re: [PATCH 07/18] lirc driver for the CommandIR USB Transc ..., Christoph Bartelmus, (Thu Sep 11, 11:24 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Thu Sep 11, 11:30 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Jarod Wilson, (Thu Sep 11, 12:09 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Janne Grunau, (Thu Sep 11, 12:18 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Maxim Levitsky, (Thu Sep 11, 2:28 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Dmitry Torokhov, (Thu Sep 11, 9:44 pm)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Hellwig, (Fri Sep 12, 1:33 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Sat Sep 13, 12:20 am)
Re: [PATCH 01/18] lirc core device driver infrastructure, Christoph Bartelmus, (Sat Sep 13, 12:21 am)