linux/drivers/firewire/core-cdev.c, branch v3.9

firewire: convert to idr_alloc()

2013-02-28T03:10:15Z

Convert to the much saner new idr interface. v2: Stefan pointed out that add_client_resource() may be called from non-process context. Preload iff @gfp_mask contains __GFP_WAIT. Also updated to include minor upper limit check. [tim.gardner@canonical.com: fix accidentally orphaned 'minor'[ Signed-off-by: Tejun Heo Acked-by: Stefan Richter Signed-off-by: Tim Gardner Signed-off-by: Stefan Richter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

firewire: don't use idr_remove_all()

2013-02-28T03:10:13Z

idr_destroy() can destroy idr by itself and idr_remove_all() is being deprecated. Drop its usage. Signed-off-by: Tejun Heo Cc: Stefan Richter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

firewire: cdev: fix user memory corruption (i386 userland on amd64 kernel)

2012-10-09T16:26:28Z

Fix two bugs of the /dev/fw* character device concerning the FW_CDEV_IOC_GET_INFO ioctl with nonzero fw_cdev_get_info.bus_reset. (Practically all /dev/fw* clients issue this ioctl right after opening the device.) Both bugs are caused by sizeof(struct fw_cdev_event_bus_reset) being 36 without natural alignment and 40 with natural alignment. 1) Memory corruption, affecting i386 userland on amd64 kernel: Userland reserves a 36 bytes large buffer, kernel writes 40 bytes. This has been first found and reported against libraw1394 if compiled with gcc 4.7 which happens to order libraw1394's stack such that the bug became visible as data corruption. 2) Information leak, affecting all kernel architectures except i386: 4 bytes of random kernel stack data were leaked to userspace. Hence limit the respective copy_to_user() to the 32-bit aligned size of struct fw_cdev_event_bus_reset. Reported-by: Simon Kirby Signed-off-by: Stefan Richter Cc: stable@kernel.org

firewire: core: fix DMA mapping direction

2012-04-17T20:27:37Z

Seen with recent libdc1394: If a client mmap()s the buffer of an isochronous reception buffer with PROT_READ|PROT_WRITE instead of just PROT_READ, firewire-core sets the wrong DMA mapping direction during buffer initialization. The fix is to split fw_iso_buffer_init() into allocation and DMA mapping and to perform the latter after both buffer and DMA context were allocated. Buffer allocation and context allocation may happen in any order, but we need the context type (reception or transmission) in order to set the DMA direction of the buffer. Signed-off-by: Stefan Richter

Remove all #inclusions of asm/system.h

2012-03-28T17:30:03Z

Remove all #inclusions of asm/system.h preparatory to splitting and killing it. Performed with the following command: perl -p -i -e 's!^#\s*include\s*.*\n!!' `grep -Irl '^#\s*include\s*' *` Signed-off-by: David Howells

firewire: allow explicit flushing of iso packet completions

2012-03-18T21:15:39Z

Extend the kernel and userspace APIs to allow reporting all currently completed isochronous packets, even if the next interrupt packet has not yet been reached. This is required to determine the status of the packets at the end of a paused or stopped stream, and useful for more precise synchronization of audio streams. Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter

firewire: prevent dropping of completed iso packet header data

2012-03-18T21:15:39Z

The buffer for the header data of completed iso packets has a fixed size, so it is possible to configure a stream with a big interval between interrupt packets or with big headers so that this buffer would overflow. Previously, ohci.c would drop any data that would not fit, but this could make unsuspecting applications believe that fewer than the actual number of packets have completed. Instead of dropping data, add calls to flush_iso_completion() so that there are as many events as needed to report all of the data. Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter

firewire: core: prefix log messages with card name

2012-02-22T21:36:00Z

Associate all log messages from firewire-core with the respective card because some people have more than one card. E.g. firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0 firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0 firewire_core: created device fw0: GUID 0814438400000389, S800 firewire_core: phy config: new root=ffc1, gap_count=5 firewire_core: created device fw1: GUID 0814438400000388, S800 firewire_core: created device fw2: GUID 0001d202e06800d1, S800 turns into firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0 firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0 firewire_core 0000:04:00.0: created device fw0: GUID 0814438400000389, S800 firewire_core 0000:04:00.0: phy config: new root=ffc1, gap_count=5 firewire_core 0000:05:00.0: created device fw1: GUID 0814438400000388, S800 firewire_core 0000:04:00.0: created device fw2: GUID 0001d202e06800d1, S800 This increases the module size slightly; to keep this in check, turn the former printk wrapper macros into functions. Their implementation is largely copied from driver core's dev_printk counterparts. Signed-off-by: Stefan Richter

firewire: cdev: fix 32 bit userland on 64 bit kernel compat corner cases

2011-08-12T13:30:08Z

Clemens points out that we need to use compat_ptr() in order to safely cast from u64 to addresses of a 32-bit usermode client. Before, our conversion went wrong - in practice if the client cast from pointer to integer such that sign-extension happened, (libraw1394 and libdc1394 at least were not doing that, IOW were not affected) or - in theory on s390 (which doesn't have FireWire though) and on the tile architecture, regardless of what the client does. The bug would usually be observed as the initial get_info ioctl failing with "Bad address" (EFAULT). Reported-by: Carl Karsten Reported-by: Clemens Ladisch Signed-off-by: Stefan Richter

firewire: cdev: prevent race between first get_info ioctl and bus reset event queuing

2011-07-16T05:24:32Z

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 Cc: