]> rtime.felk.cvut.cz Git - linux-imx.git/commit
firewire: cdev: prevent race between first get_info ioctl and bus reset event queuing
authorStefan Richter <stefanr@s5r6.in-berlin.de>
Sat, 9 Jul 2011 14:43:22 +0000 (16:43 +0200)
committerStefan Richter <stefanr@s5r6.in-berlin.de>
Sat, 16 Jul 2011 05:24:32 +0000 (07:24 +0200)
commit93b37905f70083d6143f5f4dba0a45cc64379a62
treeb6917581cd390ed9967e1df9922940362ad4309e
parentd873d794235efa590ab3c94d5ee22bb1fab19ac4
firewire: cdev: prevent race between first get_info ioctl and bus reset event queuing

Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO
ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events
to be read(2) by the client.  The get_info ioctl is practically always
issued right away after open, hence this condition only occurs if the
client opens during a bus reset, especially during a rapid series of bus
resets.

The problem with this condition is twofold:

  - These bus reset events carry the (as yet undocumented) @closure
    value of 0.  But it is not the kernel's place to choose closures;
    they are privat to the client.  E.g., this 0 value forced from the
    kernel makes it unsafe for clients to dereference it as a pointer to
    a closure object without NULL pointer check.

  - It is impossible for clients to determine the relative order of bus
    reset events from get_info ioctl(2) versus those from read(2),
    except in one way:  By comparison of closure values.  Again, such a
    procedure imposes complexity on clients and reduces freedom in use
    of the bus reset closure.

So, change the ABI to suppress queuing of bus reset events before the
first FW_CDEV_IOC_GET_INFO ioctl was issued by the client.

Note, this ABI change cannot be version-controlled.  The kernel cannot
distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO
ioctl.

We will try to back-merge this change into currently maintained stable/
longterm series, and we only document the new behaviour.  The old
behavior is now considered a kernel bug, which it basically is.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
drivers/firewire/core-cdev.c
include/linux/firewire-cdev.h