linux/drivers/target, branch v3.1

iscsi-target: Fix sendpage breakage with proper padding+DataDigest iovec offsets

2011-09-16T23:47:07Z

This patch fixes a bug in the iscsit_fe_sendpage_sg() transmit codepath that was originally introduced with the v3.1 iscsi-target merge that incorrectly uses hardcoded cmd->iov_data_count values to determine cmd->iov_data[] offsets for extra outgoing padding and DataDigest payload vectors. This code is obviously incorrect for the DataDigest enabled case with sendpage offload, and this fix ensures correct operation for padding + DataDigest, padding only, and DataDigest only cases. The bug was introduced during a pre-merge change in iscsit_fe_sendpage_sg() to natively use struct scatterlist instead of the legacy v3.0 struct se_mem logic. Cc: Andy Grover Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger

iscsi-target: Disable markers + remove dangerous local scope array usage

2011-09-16T19:37:18Z

This patch makes iscsi-target explictly disable OFMarker=Yes and IFMarker=yes parameter key usage during iscsi login by setting IFMarkInt_Reject and OFMarkInt_Reject values in iscsi_enforce_integrity_rules() to effectively disable iscsi marker usage. With this patch, an initiator proposer asking to enable either marker parameter keys will be issued a 'No' response, and the target sets OFMarkInt + IFMarkInt parameter key response to 'Irrelevant'. With markers disabled during iscsi login, this patch removes the problematic on-stack local-scope array for marker intervals in iscsit_do_rx_data() + iscsit_do_tx_data(), and other related marker code in iscsi_target_util.c. This fixes a potentional stack smashing scenario with small range markers enabled and a large MRDSL as reported by DanC here: [bug report] target: stack can be smashed http://www.spinics.net/lists/target-devel/msg00453.html Reported-by: Dan Carpenter Signed-off-by: Nicholas Bellinger

target: Skip non hex characters for VPD=0x83 NAA IEEE Registered Extended

2011-09-16T19:36:56Z

This patch adds target_parse_naa_6h_vendor_specific() to address a bug where the conversion of PRODUCT SERIAL NUMBER to use hex2bin() in target_emulate_evpd_83() was not doing proper isxdigit() checking. This conversion of the vpd_unit_serial configifs attribute is done while generating a VPD=0x83 NAA IEEE Registered Extended DESIGNATOR format's 100 bits of unique VENDOR SPECIFIC IDENTIFIER + VENDOR SPECIFIC IDENTIFIER EXTENSION area. This patch allows vpd_unit_serial (VPD=0x80) and the T10 Vendor ID DESIGNATOR format (VPD=0x83) to continue to use free-form variable length ASCII values, and now skips any non hex characters for fixed length NAA IEEE Registered Extended DESIGNATOR format (VPD=0x83) requring the binary conversion. This was originally reported by Martin after the v3.1-rc1 change to use hex2bin() in commit 11650b859681e03fdbf26277fcfc5f1f62186703 where the use of non hex characters in vpd_unit_serial generated different values than the original v3.0 internal hex -> binary code. This v3.1 change caused a problem with filesystems who write a NAA DESIGNATOR onto it's ondisk metadata, and this patch will (again) change existing values to ensure that non hex characters are not included in the fixed length NAA DESIGNATOR. Note this patch still expects vpd_unit_serial to be set via existing userspace methods of uuid generation, and does not do strict formatting via configfs input. The original bug report and thread can be found here: NAA breakage http://www.spinics.net/lists/target-devel/msg00477.html The v3.1-rc1 formatting of VPD=0x83 w/o this patch: VPD INQUIRY: Device Identification page Designation descriptor number 1, descriptor length: 20 designator_type: NAA, code_set: Binary associated with the addressed logical unit NAA 6, IEEE Company_id: 0x1405 Vendor Specific Identifier: 0xffde35ebf Vendor Specific Identifier Extension: 0x3092f498ffa820f9 [0x6001405ffde35ebf3092f498ffa820f9] Designation descriptor number 2, descriptor length: 56 designator_type: T10 vendor identification, code_set: ASCII associated with the addressed logical unit vendor id: LIO-ORG vendor specific: IBLOCK:ffde35ec-3092-4980-a820-917636ca54f1 The v3.1-final formatting of VPD=0x83 w/ this patch: VPD INQUIRY: Device Identification page Designation descriptor number 1, descriptor length: 20 designator_type: NAA, code_set: Binary associated with the addressed logical unit NAA 6, IEEE Company_id: 0x1405 Vendor Specific Identifier: 0xffde35ec3 Vendor Specific Identifier Extension: 0x924980a82091763 [0x6001405ffde35ec30924980a82091763] Designation descriptor number 2, descriptor length: 56 designator_type: T10 vendor identification, code_set: ASCII associated with the addressed logical unit vendor id: LIO-ORG vendor specific: IBLOCK:ffde35ec-3092-4980-a820-917636ca54f1 (v2: Fix parsing code to dereference + check for string terminator instead of null pointer to ensure a zeroed payload for vpd_unit_serial less than 100 bits of NAA DESIGNATOR VENDOR SPECIFIC area. Also, remove the unnecessary bitwise assignment) Reported-by: Martin Svec Signed-off-by: Nicholas Bellinger

tcm_fc: Work queue based approach instead of managing own thread and event based mechanism

2011-09-16T09:50:09Z

Problem: Changed from wake_up_interruptible -> wake_up_process and wait_event_interruptible-> schedule_timeout_interruptible broke the FCoE target. Earlier approach of wake_up_interruptible was also looking at 'queue_cnt' which is not necessary, because it increment of 'queue_cnt' with wake_up_inetrriptible / waker_up_process introduces race condition. Fix: Instead of fixing the code which used wake_up_process and remove 'queue_cnt', using work_queue based approach is cleaner and acheives same result. As well, work queue based approach has less programming overhead and OS manages threads which processes work queues. This patch is developed by Christoph Hellwig and reviwed+validated by Kiran Patil. Signed-off-by: Christoph Hellwig Signed-off-by: Kiran Patil Signed-off-by: Nicholas Bellinger

tcm_fc: Invalidation of DDP context for FCoE target in error conditions

2011-09-16T09:29:27Z

Problem: HW DDP context wasn;t invalidated in case of ABORTS, etc... This leads to the problem where memory pages which are used for DDP as user descriptor could get reused for some other purpose (such as to satisfy new memory allocation request either by kernel or user mode threads) and since HW DDP context was not invalidated, HW continue to write to those pages, hence causing memory corruption. Fix: Either on incoming ABORTS or due to exchange time out, allowed the target to cleanup HW DDP context if it was setup for respective ft_cmd. Added new function to perform this cleanup, furthur it can be enhanced for other cleanup activity. Additinal Notes: To avoid calling ddp_done from multiple places, composed the functionality in helper function "ft_invl_hw_context" and it is being called from multiple places. Cleaned up code in function "ft_recv_write_data" w.r.t DDP. Signed-off-by: Kiran Patil Signed-off-by: Nicholas Bellinger

target: Fix race between multiple invocations of target_qf_do_work()

2011-09-16T09:29:20Z

When work is scheduled with schedule_work(), the work can end up running on multiple CPUs at the same time -- this happens if the work is already running on one CPU and schedule_work() is called on another CPU. This leads to list corruption with target_qf_do_work(), which is roughly doing: spin_lock(...); list_for_each_entry_safe(...) { list_del(...); spin_unlock(...); // do stuff spin_lock(...); } With multiple CPUs running this code, one CPU can end up deleting the list entry that the other CPU is about to work on. Fix this by splicing the list entries onto a local list and then operating on that in the work function. This way, each invocation of target_qf_do_work() operates on its own local list and so multiple invocations don't corrupt each other's list. This also avoids dropping and reacquiring the lock for each list entry. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger

target: Convert acl_node_lock to be IRQ-disabling

2011-08-22T19:28:36Z

With qla2xxx, acl_node_lock is taken inside qla2xxx's hardware_lock, which is taken in hardirq context. This means acl_node_lock must become an IRQ-disabling lock; in particular this fixes lockdep warnings along the lines of ====================================================== [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] (&(&se_tpg->acl_node_lock)->rlock){+.....}, at: [] transport_deregister_session+0x92/0x140 [target_core_mod] and this task is already holding: (&(&ha->hardware_lock)->rlock){-.-...}, at: [] qla_tgt_stop_phase1+0x57/0x2c0 [qla2xxx] which would create a new lock dependency: (&(&ha->hardware_lock)->rlock){-.-...} -> (&(&se_tpg->acl_node_lock)->rlock){+.....} but this new dependency connects a HARDIRQ-irq-safe lock: (&(&ha->hardware_lock)->rlock){-.-...} to a HARDIRQ-irq-unsafe lock: (&(&se_tpg->acl_node_lock)->rlock){+.....} Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger

target: Make locking in transport_deregister_session() IRQ safe

2011-08-22T19:26:33Z

At least the tcm_qla2xxx fabric driver calls into transport_deregister_session() while holding an IRQ-disabled spinlock, so the inner locking needs to use spin_lock_irqsave() instead of spin_lock_bh(). This fixes warnings seen with tcm_qla2xxx like: WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0x98/0xb0() Call Trace: [] warn_slowpath_common+0x7f/0xc0 [] warn_slowpath_null+0x1a/0x20 [] local_bh_enable_ip+0x98/0xb0 [] _raw_spin_unlock_bh+0x14/0x20 [] transport_deregister_session+0x96/0x180 [target_core_mod] [] tcm_qla2xxx_free_session+0xd1/0x170 [tcm_qla2xxx] [] qla_tgt_sess_put+0xc3/0x140 [qla2xxx] [] qla_tgt_stop_phase1+0x8f/0x2c0 [qla2xxx] [] tcm_qla2xxx_tpg_store_enable+0x6e/0xd0 [tcm_qla2xxx] [] target_fabric_tpg_attr_store+0x39/0x40 [target_core_mod] [] configfs_write_file+0xbd/0x120 [configfs] [] vfs_write+0xc6/0x180 [] sys_write+0x51/0x90 [] system_call_fastpath+0x16/0x1b Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger

tcm_fc: init/exit functions should not be protected by "#ifdef MODULE"

2011-08-22T19:26:32Z

There's no need for the #ifdef protection when building into the kernel, and in fact we need the module_init() for the initialization function to be called. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger

target: Print subpage too for unhandled MODE SENSE pages

2011-08-22T19:26:31Z

Make a log message more useful by printing both the page and subpage that an initiator is requesting. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger