linux-toradex.git/drivers, branch v2.6.27.56

Fix race when removing SCSI devices

2010-11-22T18:43:10+00:00

commit 546ae796bfac6399e30da4b5af2cf7a6d0f8a4ec upstream.

Removing SCSI devices through
echo 1 > /sys/bus/scsi/devices/ ... /delete

while the FC transport class removes the SCSI target can lead to an
oops:

Unable to handle kernel pointer dereference at virtual kernel address 00000000b6815000
Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: sunrpc qeth_l3 binfmt_misc dm_multipath scsi_dh dm_mod ipv6 qeth ccwgroup [last unloaded: scsi_wait_scan]
CPU: 1 Not tainted 2.6.35.5-45.x.20100924-s390xdefault #1
Process fc_wq_0 (pid: 861, task: 00000000b7331240, ksp: 00000000b735bac0)
Krnl PSW : 0704200180000000 00000000003ff6e4 (__scsi_remove_device+0x24/0xd0)
           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
Krnl GPRS: 0000000000000001 0000000000000000 00000000b6815000 00000000bc24a8c0
           00000000003ff7c8 000000000056dbb8 0000000000000002 0000000000835d80
           ffffffff00000000 0000000000001000 00000000b6815000 00000000bc24a7f0
           00000000b68151a0 00000000b6815000 00000000b735bc20 00000000b735bbf8
Krnl Code: 00000000003ff6d6: a7840001            brc 8,3ff6d8
           00000000003ff6da: a7fbffd8            aghi %r15,-40
           00000000003ff6de: e3e0f0980024        stg %r14,152(%r15)
          >00000000003ff6e4: e31021200004        lg %r1,288(%r2)
           00000000003ff6ea: a71f0000            cghi    %r1,0
           00000000003ff6ee: a7a40011            brc 10,3ff710
           00000000003ff6f2: a7390003            lghi    %r3,3
           00000000003ff6f6: c0e5ffffc8b1        brasl %r14,3f8858
Call Trace:
([<0000000000001000>] 0x1000)
 [<00000000003ff7d2>] scsi_remove_device+0x42/0x54
 [<00000000003ff8ba>] __scsi_remove_target+0xca/0xfc
 [<00000000003ff99a>] __remove_child+0x3a/0x48
 [<00000000003e3246>] device_for_each_child+0x72/0xbc
 [<00000000003ff93a>] scsi_remove_target+0x4e/0x74
 [<0000000000406586>] fc_rport_final_delete+0xb2/0x23c
 [<000000000015d080>] worker_thread+0x200/0x344
 [<000000000016330c>] kthread+0xa0/0xa8
 [<0000000000106c1a>] kernel_thread_starter+0x6/0xc
 [<0000000000106c14>] kernel_thread_starter+0x0/0xc
INFO: lockdep is turned off.
Last Breaking-Event-Address:
 [<00000000003ff7cc>] scsi_remove_device+0x3c/0x54

The function __scsi_remove_target iterates through the SCSI devices on
the host, but it drops the host_lock before calling
scsi_remove_device. When the SCSI device is deleted from another
thread, the pointer to the SCSI device in scsi_remove_device can
become invalid. Fix this by getting a reference to the SCSI device
before dropping the host_lock to keep the SCSI device alive for the
call to scsi_remove_device.

Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

gdth: integer overflow in ioctl

2010-11-22T18:43:10+00:00

commit f63ae56e4e97fb12053590e41a4fa59e7daa74a4 upstream.

gdth_ioctl_alloc() takes the size variable as an int.
copy_from_user() takes the size variable as an unsigned long.
gen.data_len and gen.sense_len are unsigned longs.
On x86_64 longs are 64 bit and ints are 32 bit.

We could pass in a very large number and the allocation would truncate
the size to 32 bits and allocate a small buffer.  Then when we do the
copy_from_user(), it would result in a memory corruption.

Signed-off-by: Dan Carpenter 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

libsas: fix NCQ mixing with non-NCQ

2010-11-22T18:43:10+00:00

commit f0ad30d3d2dc924decc0e10b1ff6dc32525a5d99 upstream.

Some cards (like mvsas) have issue troubles if non-NCQ commands are
mixed with NCQ ones.  Fix this by using the libata default NCQ check
routine which waits until all NCQ commands are complete before issuing
a non-NCQ one.  The impact to cards (like aic94xx) which don't need
this logic should be minimal

Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

pcmcia: synclink_cs: fix information leak to userland

2010-11-22T18:43:09+00:00

commit 5b917a1420d3d1a9c8da49fb0090692dc9aaee86 upstream.

Structure new_line is copied to userland with some padding fields unitialized.
It leads to leaking of stack memory.

Signed-off-by: Vasiliy Kulikov 
Signed-off-by: Dominik Brodowski 
Signed-off-by: Greg Kroah-Hartman

b44: fix carrier detection on bind

2010-10-29T04:04:18+00:00

commit bcf64aa379fcadd074449cbf0c049da70071b06f upstream.

For carrier detection to work properly when binding the driver with a cable
unplugged, netif_carrier_off() should be called after register_netdev(),
not before.

Signed-off-by: Paul Fertser 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

r6040: Fix multicast list iteration when hash filter is used

2010-10-29T04:04:17+00:00

This was fixed in mainline by the interface change made in commit
f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.

After walking the multicast list to set up the hash filter, this
function will walk off the end of the list when filling the
exact-match entries.  This was fixed in mainline by the interface
change made in commit f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.

Reported-by: spamalot@hispeed.ch
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15355
Reported-by: Jason Heeris 
Reference: http://bugs.debian.org/600155
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

r6040: fix r6040_multicast_list

2010-10-29T04:04:16+00:00

commit 3bcf8229a8c49769e48d3e0bd1e20d8e003f8106 upstream.

As reported in , r6040_
multicast_list currently crashes. This is due a wrong maximum of multicast
entries. This patch fixes the following issues with multicast:

- number of maximum entries if off-by-one (4 instead of 3)

- the writing of the hash table index is not necessary and leads to invalid
values being written into the MCR1 register, so the MAC is simply put in a non
coherent state

- when we exceed the maximum number of mutlticast address, writing the
broadcast address should be done in registers MID_1{L,M,H} instead of
MID_O{L,M,H}, otherwise we would loose the adapter's MAC address

[bwh: Adjust for 2.6.32; should also apply to 2.6.27]

Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

atl1: fix resume

2010-10-29T04:04:16+00:00

commit ec5a32f67c603b11d68eb283d94eb89a4f6cfce1 upstream.

adapter->cmb.cmb is initialized when the device is opened and freed when
it's closed. Accessing it unconditionally during resume results either
in a crash (NULL pointer dereference, when the interface has not been
opened yet) or data corruption (when the interface has been used and
brought down adapter->cmb.cmb points to a deallocated memory area).

Signed-off-by: Luca Tettamanti 
Acked-by: Chris Snook 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

dmaengine: fix interrupt clearing for mv_xor

2010-10-29T04:04:15+00:00

commit cc60f8878eab892c03d06b10f389232b9b66bd83 upstream.

When using simultaneously the two DMA channels on a same engine, some
transfers are never completed. For example, an endless lock can occur
while writing heavily on a RAID5 array (with async-tx offload support
enabled).

Note that this issue can also be reproduced by using the DMA test
client.

On a same engine, the interrupt cause register is shared between two
DMA channels. This patch make sure that the cause bit is only cleared
for the requested channel.

Signed-off-by: Simon Guinot 
Tested-by: Luc Saillard 
Acked-by: saeed bishara 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

v4l1: fix 32-bit compat microcode loading translation

2010-10-29T04:04:15+00:00

commit 3e645d6b485446c54c6745c5e2cf5c528fe4deec upstream.

The compat code for the VIDIOCSMICROCODE ioctl is totally buggered.
It's only used by the VIDEO_STRADIS driver, and that one is scheduled to
staging and eventually removed unless somebody steps up to maintain it
(at which point it should use request_firmware() rather than some magic
ioctl).  So we'll get rid of it eventually.

But in the meantime, the compatibility ioctl code is broken, and this
tries to get it to at least limp along (even if Mauro suggested just
deleting it entirely, which may be the right thing to do - I don't think
the compatibility translation code has ever worked unless you were very
lucky).

Reported-by: Kees Cook 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman