On Sat, May 17, 2014 at 05:14:13PM -0400, Mikulas Patocka wrote:
> BTW. if we talk about performance - what about replacing:
>
> if (atomic_dec_and_test(&variable)) {
> ... release(object);
> }
>
> with this:
>
> if (atomic_read(&variable) == 1 || atomic_dec_and_t
On 05/16/2014 10:05 PM, Ewan Milne wrote:
On Fri, 2014-05-16 at 19:02 +, Elliott, Robert (Server Storage)
wrote:
There is an issue with a command timeout followed by a failed
abort in the linux SCSI stack.
This might explain some odd crashes I've seen, where it looks like
a command might
On 05/19/14 10:32, Hannes Reinecke wrote:
> Well, problem here is that the 'REQUEST SENSE' command has two problems:
> a) Most modern HBA (ie all non-SPI HBAs) use autosense, ie the sense
> code is returned with the command. So issuing 'REQUEST SENSE' here is
> pointless.
> b) The sense code (when
https://bugzilla.kernel.org/show_bug.cgi?id=76241
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 05/19/2014 12:29 PM, Bart Van Assche wrote:
On 05/19/14 10:32, Hannes Reinecke wrote:
Well, problem here is that the 'REQUEST SENSE' command has two problems:
a) Most modern HBA (ie all non-SPI HBAs) use autosense, ie the sense
code is returned with the command. So issuing 'REQUEST SENSE' her
On 05/19/14 12:37, Hannes Reinecke wrote:
> Plus this is just a test patch, nothing official yet.
> I'm happy to include the changes for SRP if you can confirm that SRP
> requires autosense.
Hello Hannes,
Since the SRP protocol supports returning sense data in the SRP response
message and since e
On Sun, 2014-05-18 at 21:50 +0200, Guennadi Liakhovetski wrote:
> On Sun, 18 May 2014, Rickard Strandqvist wrote:
>
> > There is otherwise a risk of a possible null pointer dereference.
> >
> > Was largely found by using a static code analysis program called cppcheck.
> >
> > Signed-off-by: Rick
On 05/16/14 21:02, Elliott, Robert (Server Storage) wrote:
> The command is still outstanding; data transfers might still occur,
> and a completion using its tag could still appear at any time.
> However, the error handler declares that the command is done,
> so all the buffers are freed and the
From: Tej Parkash
Signed-off-by: Tej Parkash
Signed-off-by: Vikas Chaudhary
---
drivers/scsi/bnx2i/bnx2i_iscsi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index 166543f..cabc8c1 100644
--- a/drivers/scsi/bnx2i/bnx
On Mon, 2014-05-19 at 10:32 +0200, Hannes Reinecke wrote:
> On 05/16/2014 10:05 PM, Ewan Milne wrote:
> > On Fri, 2014-05-16 at 19:02 +, Elliott, Robert (Server Storage)
> > wrote:
> >> There is an issue with a command timeout followed by a failed
> >> abort in the linux SCSI stack.
> >
> > Th
Prior patch still had a whitespace error. This should be the good one.
---
Checkpatch wants comments prior to mb() insertions. A good idea. Added the
comments.
---
Add a memory barrier to ensure the valid bit is read before
any of the cqe payload is read. This fixes an issue seen
on Power wher
I'd like to announce the new scsi patch queue tree, which will pick up
any scsi core or driver patches promptly to allow easy integration and
feedback that contributors might be used to from other kernel subsystems.
There are two branches, one for the SCSI core and upper level drivers,
and one for
On Mon, May 19, 2014 at 10:04:29AM -0400, James Smart wrote:
> Prior patch still had a whitespace error. This should be the good one.
FYI, I fixed thos manually when I picked up the patch for the scsi-queue
tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body
I'm still looking for one more review for each of the patches.
--
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/majordomo-info.html
Hi all,
I'm trying to understand asynchronous abort in the current upstream
code, and the code seems to have some dubious locking.
Here are some examples of the issue:
1) dangling pointers: scsi_put_command calls cancel_delayed_work(), but
that doesn't mean that the scmd_eh_abort_handler cou
Any comments on this series?
The last time the subject came up in
http://marc.info/?t=13905694535&r=1&w=2 Tomo said:
"I'm not sure there are any users of the driver. I guess that
you could try to remove the driver to see if someone would complain."
and Hannes brought up a mysteria out of tre
On 05/19/14 16:08, Paolo Bonzini wrote:
> 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run
> concurrently, and call scsi_finish_command without any lock protecting
> the calls. You can then get memory corruption.
I'm not sure what the recommended approach is to address this ra
> -Original Message-
> From: James Bottomley [mailto:jbottom...@parallels.com]
> Sent: Monday, 19 May, 2014 8:42 AM
> To: h...@suse.de
> Cc: linux-scsi@vger.kernel.org; emi...@redhat.com; Elliott, Robert (Server
> Storage); scame...@beardog.cce.hp.com; h...@infradead.org
> Subject: Re: sc
On Mon, May 19, 2014 at 05:08:56PM +0200, Bart Van Assche wrote:
> On 05/19/14 16:08, Paolo Bonzini wrote:
> > 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run
> > concurrently, and call scsi_finish_command without any lock protecting
> > the calls. You can then get memory corr
Il 19/05/2014 17:08, Bart Van Assche ha scritto:
On 05/19/14 16:08, Paolo Bonzini wrote:
2) reentrancy: the softirq handler and scmd_eh_abort_handler can run
concurrently, and call scsi_finish_command without any lock protecting
the calls. You can then get memory corruption.
I'm not sure what
Hi Julia,
Status is already set to 0 at the beginning of the function, I think
we should just "return status" here to be consistent with the rest of
the function.
==
diff --git a/drivers/scsi/qla2xxx/qla_init.c
b/drivers/scsi/qla2xxx/qla_init.c
index 76af6b6..e339833 100644
--- a/drivers/
On 05/19/14 18:09, Paolo Bonzini wrote:
> Il 19/05/2014 17:08, Bart Van Assche ha scritto:
>> On 05/19/14 16:08, Paolo Bonzini wrote:
>>> 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run
>>> concurrently, and call scsi_finish_command without any lock protecting
>>> the calls. Y
FYI, this was part of the boot_nic sysfs patch which would allow iscsid
to sync_session with info from the iBFT for iSCSI BFS via offload.
This looks good to me.
Acked-by: Eddie Wai
On Mon, 2014-05-19 at 07:32 -0400, vikas.chaudh...@qlogic.com wrote:
> From: Tej Parkash
>
> Signed-off-by: Tej
The whole series looks good to me,
Reviewed-by: Christoph Hellwig
--
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/majordomo-info.html
Looks good to me,
Reviewed-by: Christoph Hellwig
--
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/majordomo-info.html
On Mon, May 12, 2014 at 11:53:27AM -0400, James Smart wrote:
> Removed obsolete PCI IDs from the driver.
How are these obsolete?
--
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.kerne
On Tue, Apr 01, 2014 at 11:03:00PM +0200, Ondrej Zary wrote:
> Introduce wd719x, a driver for Western Digital WD7193, WD7197 and WD7296 PCI
> SCSI controllers based on WD33C296A chip.
> Tested with WD7193 card.
>
> Signed-off-by: Ondrej Zary
Looks good to me,
Reviewed-by: Christoph Hellwig
--
:)
for those distros, that want to pull only upstream'd patches, and where
customers expect someone to take phone calls on any hardware recognized
by the distro... the patch is to remove the hardware Emulex/the distro
won't answer any questions for anymore.
true - the hardware, if you can fi
On Thu, 2014-05-01 at 16:51 +0200, Christoph Hellwig wrote:
> Taken almost entirely from Nicholas Bellinger's scsi-mq conversion.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Paolo Bonzini
> ---
Reviewed-by: Nicholas Bellinger
> drivers/scsi/virtio_scsi.c | 25 +++--
On Thu, 2014-05-01 at 16:51 +0200, Christoph Hellwig wrote:
> Add an option to only transfer half the data for every n-th command.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Douglas Gilbert
Reviewed-by: Nicholas Bellinger
> ---
> drivers/scsi/scsi_debug.c |8
> 1 file chan
On Mon, May 19, 2014 at 01:39:50PM -0400, James Smart wrote:
> :)
>
> for those distros, that want to pull only upstream'd patches, and
> where customers expect someone to take phone calls on any hardware
> recognized by the distro... the patch is to remove the hardware
> Emulex/the distro won't a
On Wed, 2014-05-07 at 12:13 +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 07, 2014 at 01:56:59AM -0700, Nicholas A. Bellinger wrote:
> > On Mon, 2014-04-07 at 11:45 +0300, Michael S. Tsirkin wrote:
> > > On Sun, Apr 06, 2014 at 09:32:09PM +, Nicholas A. Bellinger wrote:
> > > > From: Nicholas
On Mon, May 19, 2014 at 12:07:03PM -0700, Nicholas A. Bellinger wrote:
> On Wed, 2014-05-07 at 12:13 +0300, Michael S. Tsirkin wrote:
> > On Mon, Apr 07, 2014 at 01:56:59AM -0700, Nicholas A. Bellinger wrote:
> > > On Mon, 2014-04-07 at 11:45 +0300, Michael S. Tsirkin wrote:
> > > > On Sun, Apr 06,
On Mon, May 19, 2014 at 04:07:52PM +, Saurav Kashyap wrote:
> Hi Julia,
>
> Status is already set to 0 at the beginning of the function, I think
> we should just "return status" here to be consistent with the rest of
> the function.
"return 0;" is more clear than "return status;".
Consistenc
On Mon, 2014-05-19 at 22:15 +0300, Michael S. Tsirkin wrote:
> On Mon, May 19, 2014 at 12:07:03PM -0700, Nicholas A. Bellinger wrote:
> > On Wed, 2014-05-07 at 12:13 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Apr 07, 2014 at 01:56:59AM -0700, Nicholas A. Bellinger wrote:
> > > > On Mon, 2014-04
To be future-proof and for better readability the time comparisons are modified
to use time_after() instead of plain, error-prone math.
Signed-off-by: Manuel Schölling
---
drivers/scsi/lpfc/lpfc_scsi.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lp
On Mon, May 19, 2014 at 01:54:50PM -0700, Nicholas A. Bellinger wrote:
> On Mon, 2014-05-19 at 22:15 +0300, Michael S. Tsirkin wrote:
> > On Mon, May 19, 2014 at 12:07:03PM -0700, Nicholas A. Bellinger wrote:
> > > On Wed, 2014-05-07 at 12:13 +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Apr 07,
On Mon, 19 May 2014, Dan Carpenter wrote:
> On Mon, May 19, 2014 at 04:07:52PM +, Saurav Kashyap wrote:
> > Hi Julia,
> >
> > Status is already set to 0 at the beginning of the function, I think
> > we should just "return status" here to be consistent with the rest of
> > the function.
>
> "
On Tue, May 20, 2014 at 07:36:48AM +0800, Julia Lawall wrote:
>
>
> On Mon, 19 May 2014, Dan Carpenter wrote:
>
> > On Mon, May 19, 2014 at 04:07:52PM +, Saurav Kashyap wrote:
> > > Hi Julia,
> > >
> > > Status is already set to 0 at the beginning of the function, I think
> > > we should jus
Hi Christoph,
On Mon, 19 May 2014 07:06:14 -0700 Christoph Hellwig wrote:
>
> I'd like to announce the new scsi patch queue tree, which will pick up
> any scsi core or driver patches promptly to allow easy integration and
> feedback that contributors might be used to from other kernel subsystems.
On 05/20/2014 01:18 AM, Christoph Hellwig wrote:
> Looks good to me,
>
> Reviewed-by: Christoph Hellwig
>
OK, thanks.
And I shall continue, and should finish allmodconfig for unicore32
within this month (which I already delayed one month more).
Thanks.
--
Chen Gang
Open, share, and attitu
https://bugzilla.kernel.org/show_bug.cgi?id=76241
--- Comment #3 from zhouqi ---
(In reply to Alan from comment #2)
> 2.6.27 is obsolete.
Sorry，Not obsolete for my program
I need to reopen it
--
You are receiving this mail because:
You are the assignee for the bug.--
To unsubscribe from this l
https://bugzilla.kernel.org/show_bug.cgi?id=76241
zhouqi changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|OBSOLETE
This triggers every time we do a SCSI abort:
virtscsi_tmf -> virtscsi_kick_cmd (grab lock and call) -> virtscsi_add_cmd
-> virtqueue_add_sgs (GFP_NOIO)
Logs look like this:
sd 0:0:0:0: [sda] abort
BUG: sleeping function called from invalid context at mm/slub.c:966
in_atomic(): 1, irqs_
On Tue, May 20, 2014 at 10:03:43AM +1000, Stephen Rothwell wrote:
> Is this a request for inclusion of those branches into linux-next
> separately from the scsi tree itself?
James said he wants to include it in the scsi tree, but given how late
we are in the cycle I'd love to see separate exposure
45 matches
Mail list logo
