Hi folks,
So this is a bit of a strange situation I'm in, where my *target*
qla2xxx firmware appears to get stuck when the *initiator* kernel is 4.1+.
The target is an Intel system with a QLE2464 running kernel 4.2.1 (from
Debian) and using fw=7.03.00. The initiator is another Intel system with
a
Hi James,
Could we please get a review for our driver? We have got some good input
on changes we need to make, and we will produce another patchset in the
coming days. However it would good to get a subsystem maintainer
review/acknowledgement to progress our upstreaming.
Thanks in advance,
J
On 10/19/2015 10:47 AM, John Garry wrote:
> Hi James,
>
> Could we please get a review for our driver? We have got some good
> input on changes we need to make, and we will produce another
> patchset in the coming days. However it would good to get a
> subsystem maintainer review/acknowledgement t
Thanks Berry,
James, the first two issues are SCSI things. I'm sending patches for
them but I can't test them myself. Especially, I'm not positive that
[patch 2/2] ses: invalid free in ses_intf_remove_enclosure() is a
complete fix. Berry, would it be possible to test that one?
regards,
dan car
"len" has to be at least 12 because we need that space for the overall
descriptor, otherwise we end up reading beyond the end of the array and
KASan complains. Later on we have some more range checking on desc_ptr
but we are checking the start of the "desc_ptr" buffer instead of the
end of the buf
If thre aren't any components, then the component[0] is beyond the end
of the array.
Reported-by: "Berry Cheng 程君(成淼)"
Signed-off-by: Dan Carpenter
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index ff474c7..a31114d 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -780,7 +780
The "len << 2" operation can have an integer overflow and leading to a
kernel crash. This is debugfs and thus root only so no one really
cares, but we should fix it anyway just to make the static checker
happy.
Signed-off-by: Dan Carpenter
diff --git a/drivers/scsi/bfa/bfad_debugfs.c b/drivers/
On 19/10/2015 09:55, Hannes Reinecke wrote:
On 10/19/2015 10:47 AM, John Garry wrote:
Hi James,
Could we please get a review for our driver? We have got some good
input on changes we need to make, and we will produce another
patchset in the coming days. However it would good to get a
subsystem
On 16/10/2015 14:47, Rob Herring wrote:
On Mon, Oct 12, 2015 at 10:20 AM, John Garry wrote:
Add devicetree bindings for HiSilicon SAS driver.
In the future, please use get_maintainers.pl.
Will do.
Signed-off-by: John Garry
---
.../devicetree/bindings/scsi/hisilicon-sas.txt | 63 +++
On 19.10.2015 07:48, Sumit Saxena wrote:
>> -Original Message-
>> From: Tomas Henzl [mailto:the...@redhat.com]
>> Sent: Friday, October 16, 2015 8:10 PM
>> To: sumit.sax...@avagotech.com; linux-scsi@vger.kernel.org;
>> martin.peter...@oracle.com; h...@infradead.org; jbottom...@parallels.com
We test that "type_ptr" is within the buffer but then we read from
"type_ptr[3]" so we could be reading beyond the end of the buffer.
Reported-by: "Berry Cheng 程君(成淼)"
Signed-off-by: Dan Carpenter
---
This isn't a complete fix because we still need more range checking in
all the other places whi
On 16/10/2015 14:36, Arnd Bergmann wrote:
On Friday 16 October 2015 14:29:55 John Garry wrote:
It could be considered.
A potential issue I see is with hisi_sas_control_phy() for
PHY_FUNC_HARD_RESET: this allocates a hisi_sas_wq struct and processes
the reset in the queue work. When we re-enabl
https://bugzilla.kernel.org/show_bug.cgi?id=106251
Bug ID: 106251
Summary: there exists a wrong return value of function
iscsi_if_recv_msg() when iscsi_lookup_endpoint() fails
Product: SCSI Drivers
Version: 2.5
Kernel Version: 4.
https://bugzilla.kernel.org/show_bug.cgi?id=106261
Bug ID: 106261
Summary: there exists a wrong return value of function
asd_map_memio() when ioremap_nocache() fails
Product: SCSI Drivers
Version: 2.5
Kernel Version: 4.2
https://bugzilla.kernel.org/show_bug.cgi?id=106261
--- Comment #1 from RUC_Soft_Sec ---
*** Bug 106211 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe l
On Monday 19 October 2015 15:11:47 John Garry wrote:
> On 16/10/2015 14:36, Arnd Bergmann wrote:
> > On Friday 16 October 2015 14:29:55 John Garry wrote:
> >>
> >> It could be considered.
> >>
> >> A potential issue I see is with hisi_sas_control_phy() for
> >> PHY_FUNC_HARD_RESET: this allocates a
When dropping a lock while iterating a list we must restart the search
as other threads could have manipulated the list under us. Without this
we can get stuck in an endless loop.
Reported-by: Johannes Thumshirn
Signed-off-by: Christoph Hellwig
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/
On 10/19/2015 06:48 PM, John Garry wrote:
On 16/10/2015 14:47, Rob Herring wrote:
+ - reg : Address and length of the register sets for the device
+ - SAS controller registers
+ - SAS controller control registers
+
+ - reset-reg : offset to reset, status, and clock registers in
control
I'd have to review more closely, but I think that's fine, as this
is how most work queues are used: you can queue the same function
multiple times, and it's guaranteed to run at least once after
the last queue, so if you queue it while it's already running,
it will be called again, otherwise it wo
On 15.10.2015 10:10, sumit.sax...@avagotech.com wrote:
> Signed-off-by: Sumit Saxena
> Signed-off-by: Kashyap Desai
Reviewed-by: Tomas Henzl
Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 15.10.2015 10:10, sumit.sax...@avagotech.com wrote:
> This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit OS.
> Donot access user memory from kernel code.
> SMAP bit restricts to access user memory from kernel code. Corresponding
> Redhat Bugzilla id for this is:[Bug 126791
On 15.10.2015 10:11, sumit.sax...@avagotech.com wrote:
> Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
On 15.10.2015 10:11, sumit.sax...@avagotech.com wrote:
> Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
On 10/19/2015 07:35 AM, Christoph Hellwig wrote:
When dropping a lock while iterating a list we must restart the search
as other threads could have manipulated the list under us. Without this
we can get stuck in an endless loop.
Hello Christoph,
Thanks for looking into this. However, I think
On Mon, Oct 19, 2015 at 08:36:23AM -0700, Bart Van Assche wrote:
> Thanks for looking into this. However, I think we need a motivation in the
> patch description why this patch does not reintroduce the soft lockup
> documented in patch "scsi_remove_target: fix softlockup regression on hot
> remo
On Mon, 2015-10-19 at 17:56 +0200, Christoph Hellwig wrote:
> On Mon, Oct 19, 2015 at 08:36:23AM -0700, Bart Van Assche wrote:
> > Thanks for looking into this. However, I think we need a motivation in the
> > patch description why this patch does not reintroduce the soft lockup
> > documented in
On Mon, Oct 19, 2015 at 8:56 AM, Christoph Hellwig wrote:
> On Mon, Oct 19, 2015 at 08:36:23AM -0700, Bart Van Assche wrote:
>> Thanks for looking into this. However, I think we need a motivation in the
>> patch description why this patch does not reintroduce the soft lockup
>> documented in patch
Smatch complains about returning hard coded error codes, silence this
warning.
drivers/target/iscsi/iscsi_target_parameters.c:211
iscsi_create_default_params() warn: returning -1 instead of -ENOMEM is sloppy
Signed-off-by: Luis de Bethencourt
---
Hi,
This doesn't change the functionality. It
Signed-off-by: Giridhar Malavali
Signed-off-by: Chad Dupuis
---
drivers/scsi/bnx2fc/bnx2fc_els.c |1 +
drivers/scsi/bnx2fc/bnx2fc_io.c |8 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_els.c b/drivers/scsi/bnx2fc/bnx2fc_els.c
index 49
Signed-off-by: Giridhar Malavali
Signed-off-by: Chad Dupuis
---
drivers/scsi/bnx2fc/57xx_hsi_bnx2fc.h |4 ++--
drivers/scsi/bnx2fc/bnx2fc.h |4 ++--
drivers/scsi/bnx2fc/bnx2fc_constants.h |4 ++--
drivers/scsi/bnx2fc/bnx2fc_debug.c |4 ++--
drivers/scsi/bnx2fc/bnx2
Signed-off-by: Giridhar Malavali
Signed-off-by: Chad Dupuis
---
drivers/scsi/bnx2fc/bnx2fc.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc.h b/drivers/scsi/bnx2fc/bnx2fc.h
index d46267d..d05866d 100644
--- a/drivers/scsi/bnx2fc/bnx2fc.h
+++
Signed-off-by: Giridhar Malavali
Signed-off-by: Chad Dupuis
---
drivers/scsi/bnx2fc/bnx2fc_io.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
index 5d6a81b..877a79a 100644
--- a/drivers/scsi/bnx2fc/b
From: Chad Dupuis
Hi James,
Please add the following patches to the scsi misc branch at your earliest
convenience.
Thanks,
Chad
Chad Dupuis (7):
bnx2fc: Update copyright for 2015.
bnx2fc: Remove 'NetXtreme II' from source files.
bnx2fc: Set ELS transfer length correctly for middle path
Explicit logouts from bnx2fc were causing race conditions in either returning
stale SCSI commands or not allowing a target to log back in.
Signed-off-by: Giridhar Malavali
Signed-off-by: Chad Dupuis
---
drivers/scsi/bnx2fc/bnx2fc.h |1 -
drivers/scsi/bnx2fc/bnx2fc_els.c |3 +-
drive
Signed-off-by: Giridhar Malavali
Signed-off-by: Chad Dupuis
---
drivers/scsi/bnx2fc/bnx2fc.h |2 +-
drivers/scsi/bnx2fc/bnx2fc_fcoe.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc.h b/drivers/scsi/bnx2fc/bnx2fc.h
index d05866d..4f3c
Signed-off-by: Giridhar Malavali
Signed-off-by: Chad Dupuis
---
drivers/scsi/bnx2fc/57xx_hsi_bnx2fc.h |2 +-
drivers/scsi/bnx2fc/Kconfig|5 ++---
drivers/scsi/bnx2fc/bnx2fc.h |2 +-
drivers/scsi/bnx2fc/bnx2fc_constants.h |2 +-
drivers/scsi/bnx2fc/bnx2fc_de
Fix a smatch warning:
drivers/scsi/mvsas/mv_sas.c:740 mvs_task_prep() warn: curly braces intended?
The code is correct, the indention is misleading. When the device is not
ready we want to return SAS_PHY_DOWN. But current indentation makes it
look like we only do so in the else branch of if (mvi_d
On Fri, 2015-10-16 at 09:54 +0200, Paul Menzel wrote:
[...]
> > BUG: unable to handle kernel NULL pointer dereference at 0014
> > IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]
> > *pdpt = 3696e001 *pde = 00
> > Oops: [#1] SMB
> > Modules linked in: sd_mod(+) sr_mod(+)
Hi Dan,
On Mon, Oct 19, 2015 at 04:48:20PM +0300, Dan Carpenter wrote:
> We test that "type_ptr" is within the buffer but then we read from
> "type_ptr[3]" so we could be reading beyond the end of the buffer.
>
> Reported-by: "Berry Cheng ??(??)"
> Signed-off-by: Dan Carpenter
> ---
> T
39 matches
Mail list logo
