linux.git/drivers, branch v3.4.51

target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer()

2013-06-27T18:27:33+00:00

commit 574780fd5e6ec52bd43e0bdb777a19e4c4c6aa9c upstream.

Here is a fun one.  Bug seems to have been introduced by commit 140854cb,
almost two years ago.  I have no idea why we only started seeing it now,
but we did.

Rough callgraph:
core_tpg_set_initiator_node_queue_depth()
`-> spin_lock_irqsave(&tpg->session_lock, flags);
`-> lio_tpg_shutdown_session()
    `-> iscsit_stop_time2retain_timer()
        `-> spin_unlock_bh(&se_tpg->session_lock);
        `-> spin_lock_bh(&se_tpg->session_lock);
`-> spin_unlock_irqrestore(&tpg->session_lock, flags);

core_tpg_set_initiator_node_queue_depth() used to call spin_lock_bh(),
but 140854cb changed that to spin_lock_irqsave().  However,
lio_tpg_shutdown_session() still claims to be called with spin_lock_bh()
held, as does iscsit_stop_time2retain_timer():
 *      Called with spin_lock_bh(&struct se_portal_group->session_lock) held

Stale documentation is mostly annoying, but in this case the dropping
the lock with the _bh variant is plain wrong.  It is also wrong to drop
locks two functions below the lock-holder, but I will ignore that bit
for now.

After some more locking and unlocking we eventually hit this backtrace:
------------[ cut here ]------------
WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0xe8/0x100()
Pid: 24645, comm: lio_helper.py Tainted: G           O 3.6.11+
Call Trace:
 [] warn_slowpath_common+0x7f/0xc0
 [] ? iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
 [] warn_slowpath_null+0x1a/0x20
 [] local_bh_enable_ip+0xe8/0x100
 [] _raw_spin_unlock_bh+0x15/0x20
 [] iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
 [] iscsit_stop_session+0xfa/0x1c0 [iscsi_target_mod]
 [] lio_tpg_shutdown_session+0x7b/0x90 [iscsi_target_mod]
 [] core_tpg_set_initiator_node_queue_depth+0xe4/0x290 [target_core_mod]
 [] iscsit_tpg_set_initiator_node_queue_depth+0x12/0x20 [iscsi_target_mod]
 [] lio_target_nacl_store_cmdsn_depth+0xa9/0x180 [iscsi_target_mod]
 [] target_fabric_nacl_base_attr_store+0x39/0x40 [target_core_mod]
 [] configfs_write_file+0xbd/0x120
 [] vfs_write+0xc6/0x180
 [] sys_write+0x51/0x90
 [] system_call_fastpath+0x16/0x1b
---[ end trace 3747632b9b164652 ]---

As a pure band-aid, this patch drops the _bh.

Signed-off-by: Joern Engel 
Signed-off-by: Nicholas Bellinger

USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable

2013-06-27T18:27:33+00:00

commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.

Add product id for Abbott strip port cable for Precision meter which
uses the TI 3410 chip.

Signed-off-by: Anders Hammarquist 
Signed-off-by: Greg Kroah-Hartman

Input: cyttsp - fix memcpy size param

2013-06-27T18:27:33+00:00

commit d2983cdb480157f637df07723f28aaa657b1080d upstream.

memcpy param is wrong because of offset in bl_cmd, this may corrupt the
stack which may cause a crash.

Tested-by: Ferruh Yigit  on TMA300-DVK
Signed-off-by: Ferruh Yigit 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

bonding: rlb mode of bond should not alter ARP originating via bridge

2013-06-27T18:27:33+00:00

[ Upstream commit 567b871e503316b0927e54a3d7c86d50b722d955 ]

Do not modify or load balance ARP packets passing through balance-alb
mode (wherein the ARP did not originate locally, and arrived via a bridge).

Modifying pass-through ARP replies causes an incorrect MAC address
to be placed into the ARP packet, rendering peers unable to communicate
with the actual destination from which the ARP reply originated.

Load balancing pass-through ARP requests causes an entry to be
created for the peer in the rlb table, and bond_alb_monitor will
occasionally issue ARP updates to all peers in the table instrucing them
as to which MAC address they should communicate with; this occurs when
some event sets rx_ntt.  In the bridged case, however, the MAC address
used for the update would be the MAC of the slave, not the actual source
MAC of the originating destination.  This would render peers unable to
communicate with the destinations beyond the bridge.

Signed-off-by: Zheng Li 
Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Matthew O'Connor 
Signed-off-by: Greg Kroah-Hartman

team: check return value of team_get_port_by_index_rcu() for NULL

2013-06-27T18:27:32+00:00

[ Upstream commit 76c455decbbad31de21c727edb184a963f42b40b ]

team_get_port_by_index_rcu() might return NULL due to race between port
removal and skb tx path. Panic is easily triggeable when txing packets
and adding/removing port in a loop.

introduced by commit 3d249d4ca "net: introduce ethernet teaming device"
and commit 753f993911b "team: introduce random mode" (for random mode)

Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

8139cp: reset BQL when ring tx ring cleared

2013-06-27T18:27:31+00:00

[ Upstream commit 98962baad72fd6d393bf39dbb7c2076532c363c6 ]

This patch cures transmit timeout's with DHCP observed
while running under KVM. When the transmit ring is cleaned out,
the Byte Queue Limit values need to be reset.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

r8169: fix offloaded tx checksum for small packets.

2013-06-27T18:27:31+00:00

[ Upstream commit b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 ]

8168evl offloaded checksums are wrong since commit
e5195c1f31f399289347e043d6abf3ffa80f0005 ("r8169: fix 8168evl frame padding.")
pads small packets to 60 bytes (without ethernet checksum). Typical symptoms
appear as UDP checksums which are wrong by the count of added bytes.

It isn't worth compensating. Let the driver checksum.

Due to the skb length changes, TSO code is moved before the Tx descriptor gets
written.

Signed-off-by: Francois Romieu 
Tested-by: Holger Hoffstätte 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

gianfar: add missing iounmap() on error in gianfar_ptp_probe()

2013-06-27T18:27:31+00:00

[ Upstream commit e5f5e380e0f3bb11f04ca5bc66a551e58e0ad26e ]

Add the missing iounmap() before return from gianfar_ptp_probe()
in the error handling case.

Signed-off-by: Wei Yongjun 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

clk: remove notifier from list before freeing it

2013-06-27T18:27:30+00:00

commit 72b5322f11ff0abf6a52b3007486656578d2c982 upstream.

The @cn is stay in @clk_notifier_list after it is freed, it cause
memory corruption.

Example, if @clk is registered(first), unregistered(first),
registered(second), unregistered(second).

The freed @cn will be used when @clk is registered(second),
and the bug will be happened when @clk is unregistered(second):

[  517.040000] clk_notif_dbg clk_notif_dbg.1: clk_notifier_unregister()
[  517.040000] Unable to handle kernel paging request at virtual address 00df3008
[  517.050000] pgd = ed858000
[  517.050000] [00df3008] *pgd=00000000
[  517.060000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[  517.060000] Modules linked in: clk_notif_dbg(O-) [last unloaded: clk_notif_dbg]
[  517.060000] CPU: 1 PID: 499 Comm: modprobe Tainted: G           O 3.10.0-rc3-00119-ga93cb29-dirty #85
[  517.060000] task: ee1e0180 ti: ee3e6000 task.ti: ee3e6000
[  517.060000] PC is at srcu_readers_seq_idx+0x48/0x84
[  517.060000] LR is at srcu_readers_seq_idx+0x60/0x84
[  517.060000] pc : []    lr : []    psr: 80070013
[  517.060000] sp : ee3e7d48  ip : 00000000  fp : ee3e7d6c
[  517.060000] r10: 00000000  r9 : ee3e6000  r8 : 00000000
[  517.060000] r7 : ed84fe4c  r6 : c068ec90  r5 : c068e430  r4 : 00000000
[  517.060000] r3 : 00df3000  r2 : 00000000  r1 : 00000002  r0 : 00000000
[  517.060000] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  517.060000] Control: 18c5387d  Table: 2d85804a  DAC: 00000015
[  517.060000] Process modprobe (pid: 499, stack limit = 0xee3e6238)
[  517.060000] Stack: (0xee3e7d48 to 0xee3e8000)
....
[  517.060000] [] (srcu_readers_seq_idx+0x48/0x84) from [] (try_check_zero+0x34/0xfc)
[  517.060000] [] (try_check_zero+0x34/0xfc) from [] (srcu_advance_batches+0x58/0x114)
[  517.060000] [] (srcu_advance_batches+0x58/0x114) from [] (__synchronize_srcu+0x114/0x1ac)
[  517.060000] [] (__synchronize_srcu+0x114/0x1ac) from [] (synchronize_srcu+0x2c/0x34)
[  517.060000] [] (synchronize_srcu+0x2c/0x34) from [] (srcu_notifier_chain_unregister+0x68/0x74)
[  517.060000] [] (srcu_notifier_chain_unregister+0x68/0x74) from [] (clk_notifier_unregister+0x7c/0xc0)
[  517.060000] [] (clk_notifier_unregister+0x7c/0xc0) from [] (clk_notif_dbg_remove+0x34/0x9c [clk_notif_dbg])
[  517.060000] [] (clk_notif_dbg_remove+0x34/0x9c [clk_notif_dbg]) from [] (platform_drv_remove+0x24/0x28)
[  517.060000] [] (platform_drv_remove+0x24/0x28) from [] (__device_release_driver+0x8c/0xd4)
[  517.060000] [] (__device_release_driver+0x8c/0xd4) from [] (driver_detach+0x9c/0xc4)
[  517.060000] [] (driver_detach+0x9c/0xc4) from [] (bus_remove_driver+0xcc/0xfc)
[  517.060000] [] (bus_remove_driver+0xcc/0xfc) from [] (driver_unregister+0x54/0x78)
[  517.060000] [] (driver_unregister+0x54/0x78) from [] (platform_driver_unregister+0x1c/0x20)
[  517.060000] [] (platform_driver_unregister+0x1c/0x20) from [] (clk_notif_dbg_driver_exit+0x14/0x1c [clk_notif_dbg])
[  517.060000] [] (clk_notif_dbg_driver_exit+0x14/0x1c [clk_notif_dbg]) from [] (SyS_delete_module+0x200/0x28c)
[  517.060000] [] (SyS_delete_module+0x200/0x28c) from [] (ret_fast_syscall+0x0/0x48)
[  517.060000] Code: e5973004 e7911102 e0833001 e2881002 (e7933101)

Reported-by: Sören Brinkmann 
Signed-off-by: Lai Jiangshan 
Tested-by: Sören Brinkmann 
Signed-off-by: Mike Turquette 
[mturquette@linaro.org: shortened $SUBJECT]
Signed-off-by: Greg Kroah-Hartman

md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuilding drive completed it.

2013-06-20T18:58:46+00:00

commit 3056e3aec8d8ba61a0710fb78b2d562600aa2ea7 upstream.

Without that fix, the following scenario could happen:

- RAID1 with drives A and B; drive B was freshly-added and is rebuilding
- Drive A fails
- WRITE request arrives to the array. It is failed by drive A, so
r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B
succeeds in writing it, so the same r1_bio is marked as
R1BIO_Uptodate.
- r1_bio arrives to handle_write_finished, badblocks are disabled,
md_error()->error() does nothing because we don't fail the last drive
of raid1
- raid_end_bio_io()  calls call_bio_endio()
- As a result, in call_bio_endio():
        if (!test_bit(R1BIO_Uptodate, &r1_bio->state))
                clear_bit(BIO_UPTODATE, &bio->bi_flags);
this code doesn't clear the BIO_UPTODATE flag, and the whole master
WRITE succeeds, back to the upper layer.

So we returned success to the upper layer, even though we had written
the data onto the rebuilding drive only. But when we want to read the
data back, we would not read from the rebuilding drive, so this data
is lost.

[neilb - applied identical change to raid10 as well]

This bug can result in lost data, so it is suitable for any
-stable kernel.

Signed-off-by: Alex Lyakas 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman