1. Remove duplicated boundary checks which simplify
the fill-in loop
2. Use more of scsi generic API
Cc: Douglas Gilbert
Signed-off-by: Tomas Winkler
---
V2: keep alloc_len < 4 as required by SPC-4 and newer
drivers/scsi/scsi_debug.c | 119 +-
1 file
https://bugzilla.kernel.org/show_bug.cgi?id=90601
--- Comment #14 from mer...@liao.homelinux.org ---
@Kashyap
For me it started with 3.16 on all our servers with 3ware/lsi/avagotech
controllers.
I rechecked in our internal ticket system.
We are using IOMMU so I completely disabled it, recompiled
https://bugzilla.kernel.org/show_bug.cgi?id=90601
--- Comment #13 from kashyap ---
My old email id is not working now, so I have to update my email id to new
avagotech domain. Sorry for delay in response.
Does this mean issue does not happen with 3.16.1
but only happens with 3.17.1 (onwards) ?
Acked-by: Saurav Kashyap
>struct register_host_info stores a 64-bit UTC system time timestamp.
>This patch removes the use of 'struct timeval' to obtain that timestamp
>as its tv_sec value will overflow on 32-bit systems in year 2038 beyond.
>The patch uses ktime_get_real_seconds() which returns
On Wed, Feb 11, 2015 at 7:35 PM, Bjorn Andersson
wrote:
> Changing the name of the regulator_set_optimum_mode() to
> regulator_set_load() better reflects that the API is doing.
>
Any comments on this?
I'm going to propose a patch to the mmc framework calling this api, so
it would be good to know
Hi!
> During the testing period of about 5 months I have concluded:
>
> 1) There are 3 identical Fujitsu RX200 S6 test servers which all show the
> same problem, but I also reproduced it on some Sun Fire and Dell server.
>
> 2) The problem happens with both HW RAID (MegaRAID SAS 2108) and when d
Hello,
I pulled the latest revision of this patch and tested it. I can vouch
for it working as expected with out any obvious impact to the existing
st driver
Is there any way we can move this along.
Thanks
Tested-by:Laurence Oberman
On Thu, Feb 12, 2015 at 6:15 AM, Seymour, Shane M wrote:
> The
This is intriguing. And you found a bug in our version of the decode_sense_data
function, the ASC/ASCQ bytes are reversed for the descriptor formatted sense
data.
Cool.
I'll try to work this in...
> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Monday
> Correct, so if the app client sets an allocation length
> of 3, then at your discretion, you can either leave the
> code doing what it does now, or return those 3 bytes.
> IOW leave it alone, improve it but don't make it worse.
Ack, got the new spec and looks like the check < 4 is the correct on
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Winkler, Tomas
> Sent: Wednesday, February 25, 2015 1:54 AM
> To: dgilb...@interlog.com; James E.J. Bottomley"
> Cc: linux-scsi@vger.kernel.org
> Subject: RE: [PATCH] sc
On 15-02-25 02:54 AM, Winkler, Tomas wrote:
On 15-02-24 04:37 PM, Tomas Winkler wrote:
1. Fix the error check: the alloc length should be > 16
and not > 4
You are proposing to make a marginally incorrect test
completely incorrect!
Quoting from the spec:
The great thing about standards is t
>-Original Message-
>From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
>Sent: Wednesday, February 25, 2015 6:53 PM
>To: Kashyap Desai
>Cc: Sumit Saxena; Uday Lingala; James E.J. Bottomley;
>megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org; kernel-
>janit...@vger.kernel.org
>S
--
Please View The Attached letter
This is harmless because we do the same thing either way but, from the
indenting, then it seems like lpfc_destroy_vport_work_array() was meant
to be inside the if statement.
Signed-off-by: Dan Carpenter
---
The static checker complains about some of the other indents as well.
drivers/scsi/lpfc/l
The intent here was for the "kbuff_arr[i] = NULL;" to be inside the
loop but, because the curly braces were missing, it's after the loop.
This means we corrupt a little memory one step beyond the array.
Fortunately, we weren't going to use that memory anyway so it's
harmless. Also we aren't going
>From the indenting, it looks like curly braces were intended here.
Fixes: dcd998ccdbf7 ('tcm_fc: Handle DDP/SW fc_frame_payload_get failures in
ft_recv_write_data')
Signed-off-by: Dan Carpenter
diff --git a/drivers/target/tcm_fc/tfc_io.c b/drivers/target/tcm_fc/tfc_io.c
index 97b486c..583e755
There are several missing curly braces so this function doesn't work as
intended.
Signed-off-by: Dan Carpenter
diff --git a/drivers/scsi/bfa/bfa_ioc.c b/drivers/scsi/bfa/bfa_ioc.c
index 315d6d6..59c3492 100644
--- a/drivers/scsi/bfa/bfa_ioc.c
+++ b/drivers/scsi/bfa/bfa_ioc.c
@@ -3662,7 +3662,7 @
On Wednesday 25 February 2015 07:43:54 Tina Ruchandani wrote:
> struct mvumi_hs_page2 stores a "seconds_since1970" field which is of
> type u64. It is however, written to, using 'struct timeval' which has
> a 32-bit seconds field and whose value will overflow in year 2038.
> This patch uses ktime_g
On Wednesday 25 February 2015 07:41:36 Tina Ruchandani wrote:
> @@ -364,10 +365,7 @@ MODULE_VERSION(ST_DRIVER_VERSION);
>
> static void stex_gettime(__le64 *time)
> {
> - struct timeval tv;
> -
> - do_gettimeofday(&tv);
> - *time = cpu_to_le64(tv.tv_sec);
> + *time = cpu
On Wednesday 25 February 2015 07:44:39 Tina Ruchandani wrote:
> struct timeval will have its tv_sec field overflow on 32-bit systems
> in year 2038 and beyond. This patch removes bfa_get_log_time which
> uses struct timeval, and instead replaces calls to it with
> calls to ktime_get_real_seconds()
On Wednesday 25 February 2015 07:45:12 Tina Ruchandani wrote:
> struct register_host_info stores a 64-bit UTC system time timestamp.
> This patch removes the use of 'struct timeval' to obtain that timestamp
> as its tv_sec value will overflow on 32-bit systems in year 2038 beyond.
> The patch uses
On Wednesday 25 February 2015 07:49:21 Tina Ruchandani wrote:
> struct timeval will have its tv_sec field overflow on 32-bit systems
> in year 2038 and beyond. This patch removes the usage of struct timeval
> and instead uses 64-bit ktime_t to get the current milliseconds
> to populate pmcraid_time
On 02/21/15 01:00, Nicholas A. Bellinger wrote:
> On Fri, 2015-02-20 at 11:49 +0100, Bart Van Assche wrote:
>> What I proposed myself consists of three steps:
>> 1. Updating the LIO SRP target driver to a more recent version.
>> 2. Target driver and LIO core refactoring such that the LIO and
>>
Move the constants and functions that are used by both initiator and
target drivers into new header files. This change will allow to modify
the SCSI target code such that the initiator SCSI header files are no
longer included. Note: the SCSI target driver patch is available for
review at
https://g
24 matches
Mail list logo
