linux-toradex.git, branch v3.2.1

Linux 3.2.1

2012-01-12T19:42:45+00:00

xfs: fix acl count validation in xfs_acl_from_disk()

2012-01-12T19:29:46+00:00

commit 093019cf1b18dd31b2c3b77acce4e000e2cbc9ce upstream.

Commit fa8b18ed didn't prevent the integer overflow and possible
memory corruption.  "count" can go negative and bypass the check.

Signed-off-by: Xi Wang 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Ben Myers 
Signed-off-by: Greg Kroah-Hartman

usb: cdc-acm: Fix acm_tty_hangup() vs. acm_tty_close() race

2012-01-12T19:29:46+00:00

[Not upstream as it was fixed differently for 3.3 with a much more
"intrusive" rework of the driver - gregkh]

There is a race condition involving acm_tty_hangup() and acm_tty_close()
where hangup() would attempt to access tty->driver_data without proper
locking and NULL checking after close() has potentially already set it
to NULL.  One possibility to (sporadically) trigger this behavior is to
perform a suspend/resume cycle with a running WWAN data connection.

This patch addresses the issue by introducing a NULL check for
tty->driver_data in acm_tty_hangup() protected by open_mutex and exiting
gracefully when hangup() is invoked on a device that has already been
closed.

Signed-off-by: Thilo-Alexander Ginkel 
Signed-off-by: Greg Kroah-Hartman

bonding: fix error handling if slave is busy (v2)

2012-01-12T19:29:45+00:00

commit f7d9821a6a9c83450ac35e76d3709e32fd38b76f upstream.

If slave device already has a receive handler registered, then the
error unwind of bonding device enslave function is broken.

The following will leave a pointer to freed memory in the slave
device list, causing a later kernel panic.
# modprobe dummy
# ip li add dummy0-1 link dummy0 type macvlan
# modprobe bonding
# echo +dummy0 >/sys/class/net/bond0/bonding/slaves

The fix is to detach the slave (which removes it from the list)
in the unwind path.

Signed-off-by: Stephen Hemminger 
Reviewed-by: Nicolas de Pesloüan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

asix: fix infinite loop in rx_fixup()

2012-01-12T19:29:44+00:00

commit 6c15d74defd38e7e7f8805392578b7a1d508097e upstream.

At this point if skb->len happens to be 2, the subsequant skb_pull(skb, 4)
call won't work and the skb->len won't be decreased and won't ever reach 0,
resulting in an infinite loop.

With an ASIX 88772 under heavy load, without this patch, rx_fixup() reaches
an infinite loop in less than a minute. With this patch applied,
no infinite loop even after hours of heavy load.

Signed-off-by: Aurelien Jacobs 
Cc: Jussi Kivilinna 
Signed-off-by: David S. Miller

igmp: Avoid zero delay when receiving odd mixture of IGMP queries

2012-01-12T19:29:44+00:00

commit a8c1f65c79cbbb2f7da782d4c9d15639a9b94b27 upstream.

Commit 5b7c84066733c5dfb0e4016d939757b38de189e4 ('ipv4: correct IGMP
behavior on v3 query during v2-compatibility mode') added yet another
case for query parsing, which can result in max_delay = 0.  Substitute
a value of 1, as in the usual v3 case.

Reported-by: Simon McVittie 
References: http://bugs.debian.org/654876
Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller

usb: ch9: fix up MaxStreams helper

2012-01-12T19:29:43+00:00

commit 18b7ede5f7ee2092aedcb578d3ac30bd5d4fc23c upstream.

[ removed the dwc3 portion of the patch as it didn't apply to
older kernels - gregkh]

According to USB 3.0 Specification Table 9-22, if
bmAttributes [4:0] are set to zero, it means "no
streams supported", but the way this helper was
defined on Linux, we will *always* have one stream
which might cause several problems.

For example on DWC3, we would tell the controller
endpoint has streams enabled and yet start transfers
with Stream ID set to 0, which would goof up the host
side.

While doing that, convert the macro to an inline
function due to the different checks we now need.

Signed-off-by: Felipe Balbi 
Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

xhci: Properly handle COMP_2ND_BW_ERR

2012-01-12T19:29:43+00:00

commit 71d85724bdd947a3b42a88d08af79f290a1a767b upstream.

I encountered a result of COMP_2ND_BW_ERR while improving how the pwc
webcam driver handles not having the full usb1 bandwidth available to
itself.

I created the following test setup, a NEC xhci controller with a
single TT USB 2 hub plugged into it, with a usb keyboard and a pwc webcam
plugged into the usb2 hub. This caused the following to show up in dmesg
when trying to stream from the pwc camera at its highest alt setting:

xhci_hcd 0000:01:00.0: ERROR: unexpected command completion code 0x23.
usb 6-2.1: Not enough bandwidth for altsetting 9

And usb_set_interface returned -EINVAL, which caused my pwc code to not
do the right thing as it expected -ENOSPC.

This patch makes the xhci driver properly handle COMP_2ND_BW_ERR and makes
usb_set_interface return -ENOSPC as expected.

This should be backported to stable kernels as old as 2.6.32.

Signed-off-by: Hans de Goede 
Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

usb: fix number of mapped SG DMA entries

2012-01-12T19:29:43+00:00

commit bc677d5b64644c399cd3db6a905453e611f402ab upstream.

Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs.  Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.

This fixes warnings like the following when using USB storage devices:
 ------------[ cut here ]------------
 WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
 ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
 Modules linked in: ohci_hcd ehci_hcd
 Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
 Call Trace:
    [] warn_slowpath_common+0x80/0x98
  [] warn_slowpath_fmt+0x41/0x43
  [] check_unmap+0x4e4/0x695
  [] ? trace_hardirqs_off+0xd/0xf
  [] ? _raw_spin_unlock_irqrestore+0x33/0x50
  [] debug_dma_unmap_sg+0xeb/0x117
  [] usb_hcd_unmap_urb_for_dma+0x71/0x188
  [] unmap_urb_for_dma+0x20/0x22
  [] usb_hcd_giveback_urb+0x5d/0xc0
  [] ehci_urb_done+0xf7/0x10c [ehci_hcd]
  [] qh_completions+0x429/0x4bd [ehci_hcd]
  [] ehci_work+0x95/0x9c0 [ehci_hcd]
  ...
 ---[ end trace f29ac88a5a48c580 ]---
 Mapped at:
  [] debug_dma_map_sg+0x45/0x139
  [] usb_hcd_map_urb_for_dma+0x22e/0x478
  [] usb_hcd_submit_urb+0x63f/0x6fa
  [] usb_submit_urb+0x2c7/0x2de
  [] usb_sg_wait+0x55/0x161

Signed-off-by: Clemens Ladisch 
Signed-off-by: Greg Kroah-Hartman

USB: Add USB-ID for Multiplex RC serial adapter to cp210x.c

2012-01-12T19:29:42+00:00

commit 08e87d0d773dc9ca5faf4c3306e238ed0ea129b0 upstream.

Hi, below patch adds the USB-ID of the serial adapters sold by
Multiplex RC (www.multiplex-rc.de).

Signed-off-by: Malte Schröder 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman