On Sat, May 25, 2013 at 09:05:25AM +0200, Paolo Bonzini wrote:
> 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.
FYI I looked at the zfs code and the way it uses it is part
On Sat, May 25, 2013 at 09:05:25AM +0200, Paolo Bonzini wrote:
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.
FYI I looked at the zfs code and the way it uses it is part of a
Martin K. Petersen, on 05/28/2013 01:25 PM wrote:
> Vladislav> Linux block layer is purely artificial creature slowly
> Vladislav> reinventing wheel creating more problems, than solving.
>
> On the contrary. I do think we solve a whole bunch of problems.
>
>
> Vladislav> It enforces approach,
Martin K. Petersen, on 05/28/2013 01:25 PM wrote:
Vladislav Linux block layer is purely artificial creature slowly
Vladislav reinventing wheel creating more problems, than solving.
On the contrary. I do think we solve a whole bunch of problems.
Vladislav It enforces approach, where often
> "Vladislav" == Vladislav Bolkhovitin writes:
Vladislav> Linux block layer is purely artificial creature slowly
Vladislav> reinventing wheel creating more problems, than solving.
On the contrary. I do think we solve a whole bunch of problems.
Vladislav> It enforces approach, where often
Vladislav == Vladislav Bolkhovitin v...@vlnb.net writes:
Vladislav Linux block layer is purely artificial creature slowly
Vladislav reinventing wheel creating more problems, than solving.
On the contrary. I do think we solve a whole bunch of problems.
Vladislav It enforces approach, where
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
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 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
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
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
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
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
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 defer
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_RAWIO. We
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 behavior
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 problem would be
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 as
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 to be allowed to
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
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
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
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
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
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
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
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
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.
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 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.
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
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
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
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
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 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
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
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 filtering (of any form really)
> > has
Il 23/05/2013 11:02, Tejun Heo ha scritto:
> On Thu, May 23, 2013 at 09:45:42AM +0200, Paolo Bonzini wrote:
>> Il 23/05/2013 00:17, Tejun Heo ha scritto:
>>> Then let's make it fit the use case better. I really can't see much
>>> point in crafting the cdb filter when you basically have to entrust
On Thu, May 23, 2013 at 09:45:42AM +0200, Paolo Bonzini wrote:
> Il 23/05/2013 00:17, Tejun Heo ha scritto:
> > Then let's make it fit the use case better. I really can't see much
> > point in crafting the cdb filter when you basically have to entrust
> > the device to the user anyway. Let's
Il 23/05/2013 00:17, Tejun Heo ha scritto:
> Then let's make it fit the use case better. I really can't see much
> point in crafting the cdb filter when you basically have to entrust
> the device to the user anyway. Let's either trust the user with the
> device or not. I'm very doubtful that
Il 23/05/2013 00:17, Tejun Heo ha scritto:
Then let's make it fit the use case better. I really can't see much
point in crafting the cdb filter when you basically have to entrust
the device to the user anyway. Let's either trust the user with the
device or not. I'm very doubtful that the
On Thu, May 23, 2013 at 09:45:42AM +0200, Paolo Bonzini wrote:
Il 23/05/2013 00:17, Tejun Heo ha scritto:
Then let's make it fit the use case better. I really can't see much
point in crafting the cdb filter when you basically have to entrust
the device to the user anyway. Let's either
Il 23/05/2013 11:02, Tejun Heo ha scritto:
On Thu, May 23, 2013 at 09:45:42AM +0200, Paolo Bonzini wrote:
Il 23/05/2013 00:17, Tejun Heo ha scritto:
Then let's make it fit the use case better. I really can't see much
point in crafting the cdb filter when you basically have to entrust
the
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 filtering (of any form really)
has always been
On Thu, May 23, 2013 at 07:17:37AM +0900, Tejun Heo wrote:
> > No, it doesn't. You can use SCM_RIGHTS, and pass a file descriptor for
> > the device node to an unprivileged program. You can choose the
> > users/groups that are allowed to access the device. In either case, the
> > privileged
On Wed, May 22, 2013 at 11:18:05PM +0200, Paolo Bonzini wrote:
> Ok, so I can split it in 10 patches one per command, but at some point I
> wonder if it is overkill. For example, for disks:
>
> - WRITE AND VERIFY(16) is needed to support >2TB disks, and the
> corresponding 12-byte CDB is
Il 22/05/2013 21:30, Tejun Heo ha scritto:
> The thing is that the behavior change is now implemented in an
> inactive form by #2 and then flipped on by #3. #2 both change the
> format and the content of the table. This should have been like the
> following.
>
> #2: Convert to the new table for
Il 22/05/2013 22:39, Tejun Heo ha scritto:
> Hey,
>
> On Wed, May 22, 2013 at 05:53:34PM +0200, Paolo Bonzini wrote:
>> I do listen to review feedback, but I also expect the other side to
>> listen to me, ask me what is not clear, and possess some knowledge of
>> the domain that he's reviewing
Hey,
On Wed, May 22, 2013 at 05:53:34PM +0200, Paolo Bonzini wrote:
> I do listen to review feedback, but I also expect the other side to
> listen to me, ask me what is not clear, and possess some knowledge of
> the domain that he's reviewing patches for. All of which, quite
> frankly, I have
Il 22/05/2013 22:19, Theodore Ts'o ha scritto:
> On Wed, May 22, 2013 at 09:37:54PM +0200, Paolo Bonzini wrote:
>>> If it's not theoretical, how does the cloud service control who has
>>> access to the CD burner, and how are the disks loaded into the CD
>>> burner?
>>
>> CD burning would be used
On Wed, May 22, 2013 at 09:37:54PM +0200, Paolo Bonzini wrote:
> > If it's not theoretical, how does the cloud service control who has
> > access to the CD burner, and how are the disks loaded into the CD
> > burner?
>
> CD burning would be used in a VM that runs on your local workstation, so
>
Il 22/05/2013 20:11, Theodore Ts'o ha scritto:
> On Wed, May 22, 2013 at 07:00:14PM +0200, Paolo Bonzini wrote:
>> You have hardware providers selling cloud services that want to run
>> their own custom backup services from within a VM, which entails having
>> vendor-specific commands run from
On Wed, May 22, 2013 at 05:00:52PM +0200, Paolo Bonzini wrote:
> Il 22/05/2013 16:30, Tejun Heo ha scritto:
> > * Separate fixes from additions. Transform existing code so that the
> > visible behavior doesn't change but the required fix can be
> > implemented on top. Explicitly note what's
On Wed, May 22, 2013 at 07:00:14PM +0200, Paolo Bonzini wrote:
> You have hardware providers selling cloud services that want to run
> their own custom backup services from within a VM, which entails having
> vendor-specific commands run from within a VM. Or you have people that
> run clusters
Il 22/05/2013 18:32, Martin K. Petersen ha scritto:
>> "Paolo" == Paolo Bonzini writes:
>
> 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
> "Paolo" == Paolo Bonzini writes:
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 fidelity as
Il 22/05/2013 16:07, Paolo Bonzini ha scritto:
>> Finally, the patch for the feature I think you actually want, which is
>> 13/14, could have been implemented fairly simply as a single patch and
>> doesn't have to be part of this series.
>
> It was, and it was ignored. I sent it together because
Il 22/05/2013 17:03, Theodore Ts'o ha scritto:
> Paolo,
>
> I'll probably regret butting my head into this, but it might be
> helpful if you talk about your particular use case which is driving
> your desire to make these changes.
Ted,
thank you very much. I understand that my discussion with
Paolo,
I'll probably regret butting my head into this, but it might be
helpful if you talk about your particular use case which is driving
your desire to make these changes. For example, what do you think the
SG_IO whitelist _should_ be used, and why should it be made more
general? What's the
Il 22/05/2013 16:30, Tejun Heo ha scritto:
> * Separate fixes from additions. Transform existing code so that the
> visible behavior doesn't change but the required fix can be
> implemented on top. Explicitly note what's going on in the commit
> messages.
Been there, done that. Have you
On Wed, May 22, 2013 at 04:12:04PM +0200, Paolo Bonzini wrote:
> Il 22/05/2013 15:41, Tejun Heo ha scritto:
> > On Wed, May 22, 2013 at 12:23:56PM +0200, Paolo Bonzini wrote:
> >> Yes, because I have no idea what _your_ point is.
> >
> > Isolate the actual fixes and just submit them as it seems
Il 22/05/2013 15:41, Tejun Heo ha scritto:
> On Wed, May 22, 2013 at 12:23:56PM +0200, Paolo Bonzini wrote:
>> Yes, because I have no idea what _your_ point is.
>
> Isolate the actual fixes and just submit them as it seems impossible
> for you to provide proper justifications for the things you
> OK, let me try. I did draw straws with Jens at LSF to see who would
> look at this and he lost, but the complexity of the patch set probably
> makes it hard for him to find the time.
Thanks.
> The first problem, which Tejun already pointed out is that you've
> combined a "bug fix" with a
On Wed, May 22, 2013 at 12:23:56PM +0200, Paolo Bonzini wrote:
> Yes, because I have no idea what _your_ point is.
Isolate the actual fixes and just submit them as it seems impossible
for you to provide proper justifications for the things you want to
add.
--
tejun
--
To unsubscribe from this
On Wed, 2013-05-22 at 12:23 +0200, Paolo Bonzini wrote:
> Il 22/05/2013 12:02, Tejun Heo ha scritto:
> > On Wed, May 22, 2013 at 11:53:30AM +0200, Paolo Bonzini wrote:
> >> Il 22/05/2013 11:32, Tejun Heo ha scritto:
> >>> On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
> I'm
Il 22/05/2013 12:02, Tejun Heo ha scritto:
> On Wed, May 22, 2013 at 11:53:30AM +0200, Paolo Bonzini wrote:
>> Il 22/05/2013 11:32, Tejun Heo ha scritto:
>>> On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
I'm not sure what is more ridiculous, whether the seven pings or the
On Wed, May 22, 2013 at 11:53:30AM +0200, Paolo Bonzini wrote:
> Il 22/05/2013 11:32, Tejun Heo ha scritto:
> > On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
> >> I'm not sure what is more ridiculous, whether the seven pings or the
> >> lack of review...
> >
> > So, ummm, I don't
Il 22/05/2013 11:32, Tejun Heo ha scritto:
> On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
>> I'm not sure what is more ridiculous, whether the seven pings or the
>> lack of review...
>
> So, ummm, I don't know what Jens is thinking but at this point I'm
> basically waiting for
On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
> I'm not sure what is more ridiculous, whether the seven pings or the
> lack of review...
So, ummm, I don't know what Jens is thinking but at this point I'm
basically waiting for someone else to pick it up as review to return
ratio
I'm not sure what is more ridiculous, whether the seven pings or the
lack of review...
Paolo
Il 06/02/2013 16:15, Paolo Bonzini ha scritto:
> This series regards the whitelist that is used for the SG_IO ioctl. This
> whitelist has three problems:
>
> * the bitmap of allowed commands is
I'm not sure what is more ridiculous, whether the seven pings or the
lack of review...
Paolo
Il 06/02/2013 16:15, Paolo Bonzini ha scritto:
This series regards the whitelist that is used for the SG_IO ioctl. This
whitelist has three problems:
* the bitmap of allowed commands is designed
On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
I'm not sure what is more ridiculous, whether the seven pings or the
lack of review...
So, ummm, I don't know what Jens is thinking but at this point I'm
basically waiting for someone else to pick it up as review to return
ratio is
Il 22/05/2013 11:32, Tejun Heo ha scritto:
On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
I'm not sure what is more ridiculous, whether the seven pings or the
lack of review...
So, ummm, I don't know what Jens is thinking but at this point I'm
basically waiting for someone
On Wed, May 22, 2013 at 11:53:30AM +0200, Paolo Bonzini wrote:
Il 22/05/2013 11:32, Tejun Heo ha scritto:
On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
I'm not sure what is more ridiculous, whether the seven pings or the
lack of review...
So, ummm, I don't know what
Il 22/05/2013 12:02, Tejun Heo ha scritto:
On Wed, May 22, 2013 at 11:53:30AM +0200, Paolo Bonzini wrote:
Il 22/05/2013 11:32, Tejun Heo ha scritto:
On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
I'm not sure what is more ridiculous, whether the seven pings or the
lack of
On Wed, 2013-05-22 at 12:23 +0200, Paolo Bonzini wrote:
Il 22/05/2013 12:02, Tejun Heo ha scritto:
On Wed, May 22, 2013 at 11:53:30AM +0200, Paolo Bonzini wrote:
Il 22/05/2013 11:32, Tejun Heo ha scritto:
On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
I'm not sure what is
On Wed, May 22, 2013 at 12:23:56PM +0200, Paolo Bonzini wrote:
Yes, because I have no idea what _your_ point is.
Isolate the actual fixes and just submit them as it seems impossible
for you to provide proper justifications for the things you want to
add.
--
tejun
--
To unsubscribe from this
OK, let me try. I did draw straws with Jens at LSF to see who would
look at this and he lost, but the complexity of the patch set probably
makes it hard for him to find the time.
Thanks.
The first problem, which Tejun already pointed out is that you've
combined a bug fix with a large
Il 22/05/2013 15:41, Tejun Heo ha scritto:
On Wed, May 22, 2013 at 12:23:56PM +0200, Paolo Bonzini wrote:
Yes, because I have no idea what _your_ point is.
Isolate the actual fixes and just submit them as it seems impossible
for you to provide proper justifications for the things you want to
On Wed, May 22, 2013 at 04:12:04PM +0200, Paolo Bonzini wrote:
Il 22/05/2013 15:41, Tejun Heo ha scritto:
On Wed, May 22, 2013 at 12:23:56PM +0200, Paolo Bonzini wrote:
Yes, because I have no idea what _your_ point is.
Isolate the actual fixes and just submit them as it seems impossible
Il 22/05/2013 16:30, Tejun Heo ha scritto:
* Separate fixes from additions. Transform existing code so that the
visible behavior doesn't change but the required fix can be
implemented on top. Explicitly note what's going on in the commit
messages.
Been there, done that. Have you read
Paolo,
I'll probably regret butting my head into this, but it might be
helpful if you talk about your particular use case which is driving
your desire to make these changes. For example, what do you think the
SG_IO whitelist _should_ be used, and why should it be made more
general? What's the
Il 22/05/2013 17:03, Theodore Ts'o ha scritto:
Paolo,
I'll probably regret butting my head into this, but it might be
helpful if you talk about your particular use case which is driving
your desire to make these changes.
Ted,
thank you very much. I understand that my discussion with Tejun
Il 22/05/2013 16:07, Paolo Bonzini ha scritto:
Finally, the patch for the feature I think you actually want, which is
13/14, could have been implemented fairly simply as a single patch and
doesn't have to be part of this series.
It was, and it was ignored. I sent it together because of the
Paolo == Paolo Bonzini pbonz...@redhat.com writes:
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
Il 22/05/2013 18:32, Martin K. Petersen ha scritto:
Paolo == Paolo Bonzini pbonz...@redhat.com writes:
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
On Wed, May 22, 2013 at 07:00:14PM +0200, Paolo Bonzini wrote:
You have hardware providers selling cloud services that want to run
their own custom backup services from within a VM, which entails having
vendor-specific commands run from within a VM. Or you have people that
run clusters that
On Wed, May 22, 2013 at 05:00:52PM +0200, Paolo Bonzini wrote:
Il 22/05/2013 16:30, Tejun Heo ha scritto:
* Separate fixes from additions. Transform existing code so that the
visible behavior doesn't change but the required fix can be
implemented on top. Explicitly note what's going
Il 22/05/2013 20:11, Theodore Ts'o ha scritto:
On Wed, May 22, 2013 at 07:00:14PM +0200, Paolo Bonzini wrote:
You have hardware providers selling cloud services that want to run
their own custom backup services from within a VM, which entails having
vendor-specific commands run from within a
On Wed, May 22, 2013 at 09:37:54PM +0200, Paolo Bonzini wrote:
If it's not theoretical, how does the cloud service control who has
access to the CD burner, and how are the disks loaded into the CD
burner?
CD burning would be used in a VM that runs on your local workstation, so
the VM
Il 22/05/2013 22:19, Theodore Ts'o ha scritto:
On Wed, May 22, 2013 at 09:37:54PM +0200, Paolo Bonzini wrote:
If it's not theoretical, how does the cloud service control who has
access to the CD burner, and how are the disks loaded into the CD
burner?
CD burning would be used in a VM that
Hey,
On Wed, May 22, 2013 at 05:53:34PM +0200, Paolo Bonzini wrote:
I do listen to review feedback, but I also expect the other side to
listen to me, ask me what is not clear, and possess some knowledge of
the domain that he's reviewing patches for. All of which, quite
frankly, I have not
Il 22/05/2013 22:39, Tejun Heo ha scritto:
Hey,
On Wed, May 22, 2013 at 05:53:34PM +0200, Paolo Bonzini wrote:
I do listen to review feedback, but I also expect the other side to
listen to me, ask me what is not clear, and possess some knowledge of
the domain that he's reviewing patches
Il 22/05/2013 21:30, Tejun Heo ha scritto:
The thing is that the behavior change is now implemented in an
inactive form by #2 and then flipped on by #3. #2 both change the
format and the content of the table. This should have been like the
following.
#2: Convert to the new table for mat
On Wed, May 22, 2013 at 11:18:05PM +0200, Paolo Bonzini wrote:
Ok, so I can split it in 10 patches one per command, but at some point I
wonder if it is overkill. For example, for disks:
- WRITE AND VERIFY(16) is needed to support 2TB disks, and the
corresponding 12-byte CDB is whitelisted
On Thu, May 23, 2013 at 07:17:37AM +0900, Tejun Heo wrote:
No, it doesn't. You can use SCM_RIGHTS, and pass a file descriptor for
the device node to an unprivileged program. You can choose the
users/groups that are allowed to access the device. In either case, the
privileged action is
Il 20/02/2013 17:12, Paolo Bonzini ha scritto:
> Il 06/02/2013 16:15, Paolo Bonzini ha scritto:
>> This series regards the whitelist that is used for the SG_IO ioctl. This
>> whitelist has three problems:
>>
>> * the bitmap of allowed commands is designed for MMC devices (roughly,
>> "play/burn
Il 20/02/2013 17:12, Paolo Bonzini ha scritto:
Il 06/02/2013 16:15, Paolo Bonzini ha scritto:
This series regards the whitelist that is used for the SG_IO ioctl. This
whitelist has three problems:
* the bitmap of allowed commands is designed for MMC devices (roughly,
play/burn CDs without
1 - 100 of 118 matches
Mail list logo
