Il 24/05/2013 03:44, Tejun Heo ha scritto:
On Thu, May 23, 2013 at 11:47:25AM +0200, Paolo Bonzini wrote:
No no, I'm not talking about it not working for the users - it's just
passing the commands, it of course works. I'm doubting about it being
a worthy security isolation layer. cdb
On Thu, 2013-05-23 at 15:58 +0200, Paolo Bonzini wrote:
Adjust the blk_verify_command function to let it look at per-queue
data. This will be done in the next patch.
This is not a bug fix. This is an enabler for your complex and to my
mind dubious rework of the SG_IO command filter. I'm
Il 24/05/2013 09:36, James Bottomley ha scritto:
On Thu, 2013-05-23 at 15:58 +0200, Paolo Bonzini wrote:
Adjust the blk_verify_command function to let it look at per-queue
data. This will be done in the next patch.
This is not a bug fix. This is an enabler for your complex and to my
mind
On Fri, 2013-05-24 at 09:43 +0200, Paolo Bonzini wrote:
Il 24/05/2013 09:36, James Bottomley ha scritto:
On Thu, 2013-05-23 at 15:58 +0200, Paolo Bonzini wrote:
Adjust the blk_verify_command function to let it look at per-queue
data. This will be done in the next patch.
This is not a
Il 24/05/2013 09:50, James Bottomley ha scritto:
On Fri, 2013-05-24 at 09:43 +0200, Paolo Bonzini wrote:
Il 24/05/2013 09:36, James Bottomley ha scritto:
On Thu, 2013-05-23 at 15:58 +0200, Paolo Bonzini wrote:
Adjust the blk_verify_command function to let it look at per-queue
data. This will
On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini pbonz...@redhat.com wrote:
The same filtering table being applied to different classes of
hardware is a software bug, but my point is that the practive
essentially entrusts non-insignificant part of security enforcement to
the hardware itself.
On Fri, 2013-05-24 at 09:53 +0200, Paolo Bonzini wrote:
Il 24/05/2013 09:50, James Bottomley ha scritto:
On Fri, 2013-05-24 at 09:43 +0200, Paolo Bonzini wrote:
Il 24/05/2013 09:36, James Bottomley ha scritto:
On Thu, 2013-05-23 at 15:58 +0200, Paolo Bonzini wrote:
Adjust the
Il 24/05/2013 10:02, Tejun Heo ha scritto:
On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini pbonz...@redhat.com wrote:
The same filtering table being applied to different classes of
hardware is a software bug, but my point is that the practive
essentially entrusts non-insignificant part of
Il 24/05/2013 10:03, James Bottomley ha scritto:
Does anyone in the real world actually care about this bug?
Yes, or I would move on and not waste so much time on this.
Fine, so produce a simple fix for this bug which we can discuss that's
not tied to this feature.
On Fri, May 24, 2013 at 5:31 PM, Paolo Bonzini pbonz...@redhat.com wrote:
I agree intuition may not count, and it's perfectly possible that
firmware writers forgot a break; or put the wrong location in a jump
table, so that unimplemented commands give interesting results.
It's not just
On 2013/5/24 11:20, Santosh Y wrote:
On Fri, May 24, 2013 at 7:52 AM, Libo Chen clbchenlibo.c...@huawei.com
wrote:
we should check kzalloc, avoid to hit oops
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/scsi/megaraid.c |4
1 files changed, 4 insertions(+), 0
we should check kzalloc, avoid to hit oops
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/scsi/megaraid.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
instead of checking scmd-device, sdev is more appropriate.
diff --git a/drivers/scsi/megaraid.c
Il 24/05/2013 11:07, Tejun Heo ha scritto:
On Fri, May 24, 2013 at 5:31 PM, Paolo Bonzini pbonz...@redhat.com wrote:
I agree intuition may not count, and it's perfectly possible that
firmware writers forgot a break; or put the wrong location in a jump
table, so that unimplemented commands give
Hi all,
this is the first step towards a new FC error handler.
This patch implements a new FC command timeout handler
which will be sending command aborts inline without
engaging SCSI EH.
In addition the commands will be returned directly
if the command abort succeeded, cutting down recovery
Add a 'BLK_EH_SCHEDULED' return code for blk-timeout to indicate
that a delayed error recovery has been initiated.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/scsi_error.c | 3 +++
include/linux/blkdev.h| 1 +
2 files changed, 4 insertions(+)
diff --git
The 'eh_entry' list might be used even before scsi_softirq_done()
is called. Hence we should rather initialize it together with
the other eh-related variables.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/scsi_lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
When a command runs into a timeout we need to send an 'ABORT TASK'
TMF. This is typically done by the 'eh_abort_handler' LLDD callback.
Conceptually, however, this function is a normal SCSI command, so
there is no need to enter the error handler.
This patch implements a new FC timeout handler
Export some more functions which are used by the new FC timeout
handler.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/scsi_error.c | 5 -
drivers/scsi/scsi_lib.c | 2 ++
drivers/scsi/scsi_priv.h | 2 ++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git
Hi all,
after having posted the first attempt for an updated FC error
handler I found that the 'eh_abort_handler()' semantics are a bit odd.
Obviously, the 'eh_abort_handler' is called to abort a command.
But what _exactly_ is supposed to happen if it returns 'SUCCESS'?
Initially one does expect
When enable lockdep, seeing possible irq lock inversion dependency detected
error. This patch fixes the issue.
Signed-off-by: Wen Xiong wenxi...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
Index: b/drivers/scsi/ipr.c
Hi All,
When enable lockdep, seeing possible irq lock inversion dependency detected
error. This patch fixed the issue.
Thanks,
Wendy
--
--
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
[PATCH v5 0/2] block,scsi: fixup blk_get_request dead queue scenarios
Changes from v4:
- As per James' suggestion, split into two patches: the first adds
blk_get_request return value checking to avoid potential oops, the
second converts callers and friends to handle ERR_PTR
From 22307be1bc6e404622b1f074094902e385a1bd30 Mon Sep 17 00:00:00 2001
From: Joe Lawrence joe.lawre...@stratus.com
Date: Fri, 24 May 2013 12:39:04 -0400
Subject: [PATCH v5 1/2] block,scsi: verify return pointer from blk_get_request
The blk-core dead queue checks introduced in commit 70460571
From 5b26d593807b30f60ed41f6fd5a16a56c3c9a43c Mon Sep 17 00:00:00 2001
From: Joe Lawrence joe.lawre...@stratus.com
Date: Fri, 24 May 2013 13:05:09 -0400
Subject: [PATCH v5 2/2] block,scsi: convert and handle ERR_PTR from
blk_get_request
The blk_get_request function may fail in low-memory
On Fri, 24 May 2013 11:50:47 +0200, Hannes Reinecke wrote:
The 'eh_entry' list might be used even before scsi_softirq_done()
is called. Hence we should rather initialize it together with
the other eh-related variables.
Signed-off-by: Hannes Reinecke h...@suse.de
---
Il 24/05/2013 10:32, Paolo Bonzini ha scritto:
Il 24/05/2013 10:03, James Bottomley ha scritto:
Does anyone in the real world actually care about this bug?
Yes, or I would move on and not waste so much time on this.
Fine, so produce a simple fix for this bug which we can discuss that's
not
On Fri, May 24, 2013 at 11:45:33AM +0200, Paolo Bonzini wrote:
It's not just unimplemented commands. Exposing any new command exposes
its borderline problems together with it.
For commands that are used by Linux already, the right way to fix the
problems is not obscuring the commands from
On 5/24/2013 5:57 AM, Hannes Reinecke wrote:
Which leads to the interesting question: What happens with the actual
command once eh_abort_handler returns?
Well, eventually it ends up on the done_q and gets returned up the
stack via
flush_done_q(). But that wasn't what you were asking?
Martin K. Petersen, on 05/22/2013 09:32 AM wrote:
Paolo First of all, I'll note that SG_IO and block-device-specific
Paolo ioctls both have their place. My usecase for SG_IO is
Paolo virtualization, where I need to pass information from the LUN to
Paolo the virtual machine with as much
On Fri, 2013-05-24 at 10:32 +0200, Paolo Bonzini wrote:
Il 24/05/2013 10:03, James Bottomley ha scritto:
Does anyone in the real world actually care about this bug?
Yes, or I would move on and not waste so much time on this.
Fine, so produce a simple fix for this bug which we
On Fri, 2013-05-24 at 17:02 +0900, Tejun Heo wrote:
On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini pbonz...@redhat.com wrote:
The same filtering table being applied to different classes of
hardware is a software bug, but my point is that the practive
essentially entrusts non-insignificant
This looks like a good start, but why would we make this FC specific?
--
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 Fri, May 24, 2013 at 09:35:02PM -0700, James Bottomley wrote:
I'll go along with this. I'm also wondering what the problem would be
if we just allowed all commands on either CAP_SYS_RAWIO or opening the
device for write, so we just defer to the filesystem permissions and
restricted read
33 matches
Mail list logo
