Il 25/05/2013 07:27, Christoph Hellwig ha scritto:
> 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 d
On Sat, May 25, 2013 at 09:05:25AM +0200, Paolo Bonzini wrote:
> > you could send destructive commands to a partition. The right fix
> > for that would be to not allow SG_IO on partitions at all, just
> > wondering if anything would be broken by this.
>
> Linus wanted to keep that for CAP_SYS_RAW
Il 25/05/2013 09:11, Christoph Hellwig ha scritto:
> > Linus wanted to keep that for CAP_SYS_RAWIO. We found two uses of SG_IO
> > on partitions: zfs-fuse used SYNCHRONIZE CACHE; some proprietary driver
> > used TEST UNIT READY.
> >
> > Really, the solution is to make the bitmaps configurable in
Hey, James.
On Fri, May 24, 2013 at 09:35:02PM -0700, James Bottomley wrote:
> > Well, I'd actually much prefer disabling CDB whitelisting for all !MMC
> > devices if at all possible.
>
> I'll go along with this. I'm also wondering what the problem would be
Don't think we can. It'd be a behavi
On 05/25/2013 07:08 AM, Christoph Hellwig wrote:
This looks like a good start, but why would we make this FC specific?
Because James B. said so :-)
No, seriously:
You would need to revisit the good old SCSI parallel LLDDs to figure out
if this approach works for them.
Eg aic7xxx basically has
On Sat, May 25, 2013 at 11:38:55AM +0200, Hannes Reinecke wrote:
> On 05/25/2013 07:08 AM, Christoph Hellwig wrote:
> >This looks like a good start, but why would we make this FC specific?
> >
> Because James B. said so :-)
I can't remember that at all, but I'll happily let him speak.
> No, serio
On 05/25/2013 12:26 AM, Jeremy Linton wrote:
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_don
On Fri, May 24, 2013 at 12:57:40PM -0400, J??rn Engel wrote:
> > memset(cmd->sense_buffer, 0, SCSI_SENSE_BUFFERSIZE);
> > if (cmd->cmd_len == 0)
> > cmd->cmd_len = scsi_command_size(cmd->cmnd);
> > + INIT_LIST_HEAD(&cmd->eh_entry);
> > + cmd->eh_eflags = 0;
>
> I always sus
On 05/25/2013 10:42 AM, Christoph Hellwig wrote:
On Sat, May 25, 2013 at 11:38:55AM +0200, Hannes Reinecke wrote:
On 05/25/2013 07:08 AM, Christoph Hellwig wrote:
This looks like a good start, but why would we make this FC specific?
Because James B. said so :-)
I can't remember that at all,
Il 25/05/2013 10:37, Tejun Heo ha scritto:
> Hey, James.
>
> On Fri, May 24, 2013 at 09:35:02PM -0700, James Bottomley wrote:
>>> Well, I'd actually much prefer disabling CDB whitelisting for all !MMC
>>> devices if at all possible.
>>
>> I'll go along with this. I'm also wondering what the probl
On Sat, May 25, 2013 at 01:14:37PM +0200, Paolo Bonzini wrote:
> > Don't think we can. It'd be a behavior change clearly visible to
> > userland at this point.
>
> We can (and even for MMC) if it is a build-time configuration knob. It
> would satisfy those people who want the CVE fixed, as long
Il 25/05/2013 14:48, Tejun Heo ha scritto:
>>> * Merge the patch to give out SG_IO access along with write access, so
>>> > > the use cases which want to give out SG_IO access can do so
>>> > > explicitly and be fully responsible for the device. This makes
>>> > > sense to me. If one wants
From: Gu Zheng
Use the new pci_alloc_dev(bus) to replace the existing using of
alloc_pci_dev(void).
v2:
Follow Bjorn's correction to move pci_bus_put() to
pci_release_dev() instead.
v3:
release reference to bus on error recovery path
Signed-off-by: Gu Zheng
Signed-off-by: Jiang Liu
Cc:
Roland,
I agree, and am already working around that limitation.
-- james s
On 5/23/2013 2:14 PM, Roland Dreier wrote:
At LSF this year, we had a discussion about error handling and in
particular the problem that SCSI midlayer error handling waits for the
entire SCSI host (HBA) to quiesce befo
14 matches
Mail list logo
