[PATCH 1/1] libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu

2014-09-02 Thread michaelc
From: Mike Christie This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu. This function is used by iscsi drivers and userspace to send iscsi PDUs/ commands. For login commands, we have a set buffer size. For all other commands we do not support data buffers. This was reported b

Re: Re: [RFC PATCH 07/10] scsi/trace: Use scsi_show_result trace point instead of printk

2014-09-02 Thread Yoshihiro YUNOMAE
Hi Christoph, Sorry for the late reply. (2014/08/29 9:50), Christoph Hellwig wrote: I'm not sure this is the correct way. Currently we have quite some code duplication in scsi_trace.c and constants.c, correct. So I definitely would like to see them both merged. But constants.c is influenced by

[PATCH] target: target_core_transport: Don't try to strlen() an integer

2014-09-02 Thread Mark Brown
In transport_dump_vpd_ident_type() we try to call strlen() on the integer len which is obviously a typo; take the length of the string already in buf instead. Fixes: 6cfa853ceee4a (target: target_core_transport.c: Cleaning up missing null-terminate in conjunction with strncp

[PATCH 1/1] Drivers: scsi: storvsc: Get rid of warning messages

2014-09-02 Thread K. Y. Srinivasan
Get rid of the warning messages since they will clutter up various system logs and are of questionable value to the end user. For debugging purposes, this information can be gotten by setting the scsi log level appropriately. Signed-off-by: K. Y. Srinivasan --- drivers/scsi/storvsc_drv.c | 12

Re: [RFC 1/2] target: Add documentation on the target userspace pass-through driver

2014-09-02 Thread Andy Grover
On 08/31/2014 02:22 PM, Richard W.M. Jones wrote: Reading this several times, I now think I get what it's trying to say, but I think it needs to introduces the terms (as the Economist style does). Something like this: "TCM is the new name for LIO, an in-kernel iSCSI target (server). Exist

Re: [PATCH 2/5] kexec: Export kexec_in_progress

2014-09-02 Thread Brian King
On 08/30/2014 03:02 PM, Eric W. Biederman wrote: > Brian King writes: > >> On 08/04/2014 09:21 AM, Brian King wrote: >>> On 07/28/2014 03:28 PM, Brian King wrote: Export kexec_in_progress for use by device drivers and other modules to optimize kexec boot. Signed-off-by: B

[PATCH] bnx2fc: fix incorrect DMA memory mapping in bnx2fc_unmap_sg_list()

2014-09-02 Thread Chad Dupuis
This patch is based on a problem and solution from Maurizio Lombardi where bnx2fc isn't consistent in which device struct we using for DMA map and unmap operations. Make them consistent by using dma_sg_unmap in bnx2fc_unmap_sg_list like bnx2fc_map_sg. Reviewed-by: Eddie Wai Signed-off-by: Chad D

[PATCH] SCSI: Don't store LUN bits in CDB[1] for USB mass-storage devices

2014-09-02 Thread Alan Stern
The SCSI specification requires that the second Command Data Byte should contain the LUN value in its high-order bits if the recipient device reports SCSI level 2 or below. Nevertheless, some USB mass-storage devices use those bits for other purposes in vendor-specific commands. Currently Linux h

Re: Adaptec 71605H HBA randomly failing to detect any drives at init

2014-09-02 Thread Emmanuel Florac
Le Mon, 1 Sep 2014 09:06:46 -0700 Andrew Robertson écrivait: > I'm happy to test patches/etc on this system if necessary -- and/or if > someone can help point me in the right direction, I'd appreciate it. In my experience the 7xxx5 are very sensitive to cable length and backplane type: basically

RE: Adaptec 71605H HBA randomly failing to detect any drives at init

2014-09-02 Thread Suresh Thiagarajan
On Mon, Sep 1, 2014 at 9:36 PM, Andrew Robertson wrote: > Hi, > > I have an Adaptec 71605H HBA that's randomly failing to detect any > drives at boot. I have two systems with this HBA, and both are > showing the exact same behavior. I can reproduce this randomly about > 3 out of 4 times, where

Re: [uas/3.16.1] panic in uas_data_cmplt()

2014-09-02 Thread Chunwei Chen
On 西元2014年09月02日 14:50, Hans de Goede wrote: > Hi, > > On 09/02/2014 06:18 AM, Chunwei Chen wrote: >> Dear all: >> >> The kernel version is 3.16.1-1-ARCH >> >> Today I keep getting this panic when booting up. >> http://i.imgur.com/0Rx93Kr.jpg >> >> It might be that the UAS device was in some str