kernel/linux.git/drivers/target, branch v3.4.34

target: Fix divide by zero bug in fabric_max_sectors for unconfigured devices

2013-02-28T14:59:03+00:00

commit 7a3cf6ca1ab2a2f7161c6dec5a787fc7a5de864e upstream This patch fixes a possible divide by zero bug when the fabric_max_sectors device attribute is written and backend se_device failed to be successfully configured -> enabled. Go ahead and use block_size=512 within se_dev_set_fabric_max_sectors() in the event of a target_configure_device() failure case, as no valid dev->dev_attrib.block_size value will have been setup yet. Signed-off-by: Nicholas Bellinger Cc: Herton Ronaldo Krzesinski Signed-off-by: Greg Kroah-Hartman

target: fix regression with dev_link_magic in target_fabric_port_link

2013-02-04T00:24:42+00:00

This is to fix a regression that only affect the stable (not for the mainline) that the stable commit fdf9d86 was incorrectly placed dev->dev_link_magic check before the *dev assignment in target_fabric_port_link() due to fuzzy automatically context adjustment during the back-porting. Reported-by: Chris Boot Signed-off-by: Nicholas Bellinger Signed-off-by: CAI Qian Signed-off-by: Greg Kroah-Hartman

target: Add link_magic for fabric allow_link destination target_items

2013-01-21T19:45:24+00:00

commit 0ff8754981261a80f4b77db2536dfea92c2d4539 upstream. This patch adds [dev,lun]_link_magic value assignment + checks within generic target_fabric_port_link() and target_fabric_mappedlun_link() code to ensure destination config_item *target_item sent from configfs_symlink() -> config_item_operations->allow_link() is the underlying se_device->dev_group and se_lun->lun_group that we expect to symlink. Reported-by: Sebastian Andrzej Siewior Cc: Sebastian Andrzej Siewior Signed-off-by: Nicholas Bellinger Signed-off-by: CAI Qian Signed-off-by: Greg Kroah-Hartman

target: Release se_cmd when LUN lookup fails for TMR

2013-01-21T19:45:14+00:00

commit 5a3b6fc0092c5f8dee7820064ee54d2631d48573 upstream. When transport_lookup_tmr_lun() fails and we return a task management response from target_complete_tmr_failure(), we need to call transport_cmd_check_stop_to_fabric() to release the last ref to the cmd after calling se_tfo->queue_tm_rsp(), or else we will never remove the failed TMR from the session command list (and we'll end up waiting forever when trying to tear down the session). (nab: Fix minor compile breakage) Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

tcm_fc: Do not report target role when target is not defined

2013-01-21T19:45:14+00:00

commit edec8dfefa1f372b2dd8197da555352e76a10c03 upstream. Clear the target role when no target is provided for the node performing a PRLI. Signed-off-by: Mark Rustad Reviewed-by: Bhanu Prakash Gollapudi Acked by Robert Love Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

tcm_fc: Do not indicate retry capability to initiators

2013-01-21T19:45:14+00:00

commit f2eeba214bcd0215b7f558cab6420e5fd153042b upstream. When generating a PRLI response to an initiator, clear the FCP_SPPF_RETRY bit in the response. Signed-off-by: Mark Rustad Reviewed-by: Bhanu Prakash Gollapudi Acked by Robert Love Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

target/tcm_fc: fix the lockdep warning due to inconsistent lock state

2013-01-17T16:50:45+00:00

commit 9f4ad44b264f8bb61ffdd607148215566568430d upstream. The lockdep warning below is in theory correct but it will be in really weird rare situation that ends up that deadlock since the tcm fc session is hashed based the rport id. Nonetheless, the complaining below is about rcu callback that does the transport_deregister_session() is happening in softirq, where transport_register_session() that happens earlier is not. This triggers the lockdep warning below. So, just fix this to make lockdep happy by disabling the soft irq before calling transport_register_session() in ft_prli. BTW, this was found in FCoE VN2VN over two VMs, couple of create and destroy would get this triggered. v1: was enforcing register to be in softirq context which was not righ. See, http://www.spinics.net/lists/target-devel/msg03614.html v2: following comments from Roland&Nick (thanks), it seems we don't have to do transport_deregister_session() in rcu callback, so move it into ft_sess_free() but still do kfree() of the corresponding ft_sess struct in rcu callback to make sure the ft_sess is not freed till the rcu callback. ... [ 1328.370592] scsi2 : FCoE Driver [ 1328.383429] fcoe: No FDMI support. [ 1328.384509] host2: libfc: Link up on port (000000) [ 1328.934229] host2: Assigned Port ID 00a292 [ 1357.232132] host2: rport 00a393: Remove port [ 1357.232568] host2: rport 00a393: Port sending LOGO from Ready state [ 1357.233692] host2: rport 00a393: Delete port [ 1357.234472] host2: rport 00a393: work event 3 [ 1357.234969] host2: rport 00a393: callback ev 3 [ 1357.235979] host2: rport 00a393: Received a LOGO response closed [ 1357.236706] host2: rport 00a393: work delete [ 1357.237481] [ 1357.237631] ================================= [ 1357.238064] [ INFO: inconsistent lock state ] [ 1357.238450] 3.7.0-rc7-yikvm+ #3 Tainted: G O [ 1357.238450] --------------------------------- [ 1357.238450] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 1357.238450] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE0:SE0] takes: [ 1357.238450] (&(&se_tpg->session_lock)->rlock){+.?...}, at: [] transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] {SOFTIRQ-ON-W} state was registered at: [ 1357.238450] [] mark_held_locks+0x6d/0x95 [ 1357.238450] [] trace_hardirqs_on_caller+0x12d/0x197 [ 1357.238450] [] trace_hardirqs_on+0xd/0xf [ 1357.238450] [] _raw_spin_unlock_irq+0x2d/0x45 [ 1357.238450] [] __transport_register_session+0xb8/0x122 [target_core_mod] [ 1357.238450] [] transport_register_session+0x44/0x5a [target_core_mod] [ 1357.238450] [] ft_prli+0x1e3/0x275 [tcm_fc] [ 1357.238450] [] fc_rport_recv_req+0x95e/0xdc5 [libfc] [ 1357.238450] [] fc_lport_recv_els_req+0xc4/0xd5 [libfc] [ 1357.238450] [] fc_lport_recv_req+0x12f/0x18f [libfc] [ 1357.238450] [] fc_exch_recv+0x8ba/0x981 [libfc] [ 1357.238450] [] fcoe_percpu_receive_thread+0x47a/0x4e2 [fcoe] [ 1357.238450] [] kthread+0xb1/0xb9 [ 1357.238450] [] ret_from_fork+0x7c/0xb0 [ 1357.238450] irq event stamp: 275411 [ 1357.238450] hardirqs last enabled at (275410): [] rcu_process_callbacks+0x229/0x42a [ 1357.238450] hardirqs last disabled at (275411): [] _raw_spin_lock_irqsave+0x22/0x8e [ 1357.238450] softirqs last enabled at (275394): [] __do_softirq+0x246/0x26f [ 1357.238450] softirqs last disabled at (275399): [] run_ksoftirqd+0x29/0x62 [ 1357.238450] [ 1357.238450] other info that might help us debug this: [ 1357.238450] Possible unsafe locking scenario: [ 1357.238450] [ 1357.238450] CPU0 [ 1357.238450] ---- [ 1357.238450] lock(&(&se_tpg->session_lock)->rlock); [ 1357.238450] [ 1357.238450] lock(&(&se_tpg->session_lock)->rlock); [ 1357.238450] [ 1357.238450] *** DEADLOCK *** [ 1357.238450] [ 1357.238450] no locks held by ksoftirqd/0/3. [ 1357.238450] [ 1357.238450] stack backtrace: [ 1357.238450] Pid: 3, comm: ksoftirqd/0 Tainted: G O 3.7.0-rc7-yikvm+ #3 [ 1357.238450] Call Trace: [ 1357.238450] [] print_usage_bug+0x1f5/0x206 [ 1357.238450] [] ? save_stack_trace+0x2c/0x49 [ 1357.238450] [] ? print_irq_inversion_bug.part.14+0x1ae/0x1ae [ 1357.238450] [] mark_lock+0x106/0x258 [ 1357.238450] [] __lock_acquire+0x2e7/0xe53 [ 1357.238450] [] ? pvclock_clocksource_read+0x48/0xb4 [ 1357.238450] [] ? rcu_process_gp_end+0xc0/0xc9 [ 1357.238450] [] ? transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [] lock_acquire+0x119/0x143 [ 1357.238450] [] ? transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [] _raw_spin_lock_irqsave+0x54/0x8e [ 1357.238450] [] ? transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [] transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [] ? rcu_process_callbacks+0x229/0x42a [ 1357.238450] [] ft_sess_rcu_free+0x17/0x24 [tcm_fc] [ 1357.238450] [] ? ft_sess_free+0x1b/0x1b [tcm_fc] [ 1357.238450] [] rcu_process_callbacks+0x260/0x42a [ 1357.238450] [] __do_softirq+0x13a/0x26f [ 1357.238450] [] ? __schedule+0x65f/0x68e [ 1357.238450] [] run_ksoftirqd+0x29/0x62 [ 1357.238450] [] smpboot_thread_fn+0x1a5/0x1aa [ 1357.238450] [] ? smpboot_unregister_percpu_thread+0x47/0x47 [ 1357.238450] [] kthread+0xb1/0xb9 [ 1357.238450] [] ? wait_for_common+0xbb/0x10a [ 1357.238450] [] ? __init_kthread_worker+0x59/0x59 [ 1357.238450] [] ret_from_fork+0x7c/0xb0 [ 1357.238450] [] ? __init_kthread_worker+0x59/0x59 [ 1417.440099] rport-2:0-0: blocked FC remote port time out: removing rport Signed-off-by: Yi Zou Cc: Open-FCoE Cc: Nicholas A. Bellinger Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

iscsit: use GFP_ATOMIC under spin lock

2013-01-17T16:50:44+00:00

commit 3c989d7603872bf878840f7ce3ea49b73bea4c6c upstream. The function iscsit_build_conn_drop_async_message() is called from iscsit_close_connection() with spin lock 'sess->conn_lock' held, so we should use GFP_ATOMIC instead of GFP_KERNEL. Signed-off-by: Wei Yongjun Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

target: Fix incorrect usage of nested IRQ spinlocks in ABORT_TASK path

2012-11-17T21:15:55+00:00

commit ab74b3d62f05192bf8fb8f169e7999d1183b2e08 upstream. This patch changes core_tmr_abort_task() to use spin_lock -> spin_unlock around se_cmd->t_state_lock while spin_lock_irqsave is held via se_sess->sess_cmd_lock. Signed-off-by: Steve Hodgson Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

iscsi-target: Fix missed wakeup race in TX thread

2012-11-17T21:15:55+00:00

commit d5627acba9ae584cf4928af19f7ddf5f6837de32 upstream. The sleeping code in iscsi_target_tx_thread() is susceptible to the classic missed wakeup race: - TX thread finishes handle_immediate_queue() and handle_response_queue(), thinks both queues are empty. - Another thread adds a queue entry and does wake_up_process(), which does nothing because the TX thread is still awake. - TX thread does schedule_timeout() and sleeps forever. In practice this can kill an iSCSI connection if for example an initiator does single-threaded writes and the target misses the wakeup window when queueing an R2T; in this case the connection will be stuck until the initiator loses patience and does some task management operation (or kills the connection entirely). Fix this by converting to wait_event_interruptible(), which does not suffer from this sort of race. Signed-off-by: Roland Dreier Cc: Andy Grover Cc: Hannes Reinecke Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman