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. cd
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 run
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
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.
> >
> > Th
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
dat
On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini 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. The variety of
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 th
Il 24/05/2013 10:02, Tejun Heo ha scritto:
> On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini 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 enforc
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
>>> > > no
On Fri, May 24, 2013 at 5:31 PM, Paolo Bonzini 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 unimplemented commands
On 2013/5/24 11:20, Santosh Y wrote:
> On Fri, May 24, 2013 at 7:52 AM, Libo Chen
> wrote:
>>
>> we should check kzalloc, avoid to hit oops
>>
>> Signed-off-by: Libo Chen
>> ---
>> drivers/scsi/megaraid.c |4
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/driver
we should check kzalloc, avoid to hit oops
Signed-off-by: Libo Chen
---
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 b/drivers/scsi/megaraid.c
index 846f47
Il 24/05/2013 11:07, Tejun Heo ha scritto:
> On Fri, May 24, 2013 at 5:31 PM, Paolo Bonzini 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 interestin
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
time
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
---
drivers/scsi/scsi_error.c | 3 +++
include/linux/blkdev.h| 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/scsi/scsi_error.c b/dri
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
---
drivers/scsi/scsi_lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drive
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 whi
Export some more functions which are used by the new FC timeout
handler.
Signed-off-by: Hannes Reinecke
---
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 a/drivers/scsi/scsi_err
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
---
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 http://
[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 differentiation
>From 22307be1bc6e404622b1f074094902e385a1bd30 Mon Sep 17 00:00:00 2001
From: Joe Lawrence
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 added an
error scenario to b
>From 5b26d593807b30f60ed41f6fd5a16a56c3c9a43c Mon Sep 17 00:00:00 2001
From: Joe Lawrence
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 conditions or during
device rem
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
> ---
> drivers/scsi/scsi_lib.c |
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
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
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 prod
On Fri, 2013-05-24 at 17:02 +0900, Tejun Heo wrote:
> On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini 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 sec
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
Il 25/05/2013 06:14, James Bottomley ha scritto:
> 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 ti
34 matches
Mail list logo
