linux, branch v3.2.46

Linux 3.2.46

2013-05-30T13:35:16Z

um: Serve io_remap_pfn_range()

2013-05-30T13:35:15Z

commit 4d94d6d030adfdea4837694d293ec6918d133ab2 upstream. At some places io_remap_pfn_range() is needed. UML has to serve it like all other archs do. Signed-off-by: Richard Weinberger Signed-off-by: Ben Hutchings

staging: comedi: prevent auto-unconfig of manually configured devices

2013-05-30T13:35:15Z

commit 7d3135af399e92cf4c9bbc5f86b6c140aab3b88c upstream. When a low-level comedi driver auto-configures a device, a `struct comedi_dev_file_info` is allocated (as well as a `struct comedi_device`) by `comedi_alloc_board_minor()`. A pointer to the hardware `struct device` is stored as a cookie in the `struct comedi_dev_file_info`. When the low-level comedi driver auto-unconfigures the device, `comedi_auto_unconfig()` uses the cookie to find the `struct comedi_dev_file_info` so it can detach the comedi device from the driver, clean it up and free it. A problem arises if the user manually unconfigures and reconfigures the comedi device using the `COMEDI_DEVCONFIG` ioctl so that is no longer associated with the original hardware device. The problem is that the cookie is not cleared, so that a call to `comedi_auto_unconfig()` from the low-level driver will still find it, detach it, clean it up and free it. Stop this problem occurring by always clearing the `hardware_device` cookie in the `struct comedi_dev_file_info` whenever the `COMEDI_DEVCONFIG` ioctl call is successful. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

[media] mantis: fix silly crash case

2013-05-30T13:35:15Z

commit e1d45ae10aea8e8a403e5d96bf5902ee670007ff upstream. If we set mantis->fe to NULL on an error its not a good idea to then try passing NULL to the unregister paths and oopsing really. Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=16473 Signed-off-by: Alan Cox Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings

drivers/rtc/rtc-pcf2123.c: fix error return code in pcf2123_probe()

2013-05-30T13:35:15Z

commit 35623715818dfa720cccf99cd280dcbb4b78da23 upstream. Fix to return -ENODEV in the chip not found error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun Cc: Jingoo Han Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings

xfrm6: release dev before returning error

2013-05-30T13:35:14Z

[ Upstream commit 84c4a9dfbf430861e7588d95ae3ff61535dca351 ] We forget to call dev_put() on error path in xfrm6_fill_dst(), its caller doesn't handle this. Cc: Herbert Xu Cc: Steffen Klassert Cc: David S. Miller Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings

ipv6: do not clear pinet6 field

2013-05-30T13:35:14Z

[ Upstream commit f77d602124d865c38705df7fa25c03de9c284ad2 ] We have seen multiple NULL dereferences in __inet6_lookup_established() After analysis, I found that inet6_sk() could be NULL while the check for sk_family == AF_INET6 was true. Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP and TCP stacks. Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash table, we no longer can clear pinet6 field. This patch extends logic used in commit fcbdf09d9652c891 ("net: fix nulls list corruptions in sk_prot_alloc") TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method to make sure we do not clear pinet6 field. At socket clone phase, we do not really care, as cloning the parent (non NULL) pinet6 is not adding a fatal race. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings

macvlan: fix passthru mode race between dev removal and rx path

2013-05-30T13:35:14Z

[ Upstream commit 233c7df0821c4190e2d3f4be0f2ca0ab40a5ed8c, note that I had to add list_first_or_null_rcu to rculist.h in order to accomodate this fix. ] Currently, if macvlan in passthru mode is created and data are rxed and you remove this device, following panic happens: NULL pointer dereference at 0000000000000198 IP: [] macvlan_handle_frame+0x153/0x1f7 [macvlan] I'm using following script to trigger this: I run this script while "ping -f" is running on another machine to send packets to e1 rx. Reason of the panic is that list_first_entry() is blindly called in macvlan_handle_frame() even if the list was empty. vlan is set to incorrect pointer which leads to the crash. I'm fixing this by protecting port->vlans list by rcu and by preventing from getting incorrect pointer in case the list is empty. Introduced by: commit eb06acdc85585f2 "macvlan: Introduce 'passthru' mode to takeover the underlying device" Signed-off-by: Jiri Pirko Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings

if_cablemodem.h: Add parenthesis around ioctl macros

2013-05-30T13:35:13Z

[ Upstream commit 4f924b2aa4d3cb30f07e57d6b608838edcbc0d88 ] Protect the SIOCGCM* ioctl macros with parenthesis. Reported-by: Paul Wouters Signed-off-by: Josh Boyer Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings

3c59x: fix PCI resource management

2013-05-30T13:35:13Z

[ Upstream commit 4b264a1676e70dc656ba53a8cac690f2d4b65f4e ] The driver wrongly claimed I/O ports at an address returned by pci_iomap() -- even if it was passed an MMIO address. Fix this by claiming/releasing all PCI resources in the PCI driver's probe()/remove() methods instead and get rid of 'must_free_region' flag weirdness (why would Cardbus claim anything for us?). Signed-off-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings