Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 10:18:19PM -0700, Gregory Farnum wrote: > would've been nice if they were upstream. What *is* a big deal for > FileStore (and would be easy to take advantage of) is the thematically > similar O_NOMTIME flag, which is also about reducing metadata updates > and got blocked on

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 10:18:19PM -0700, Gregory Farnum wrote: > would've been nice if they were upstream. What *is* a big deal for > FileStore (and would be easy to take advantage of) is the thematically > similar O_NOMTIME flag, which is also about reducing metadata updates > and got blocked on

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

> "Jeff" == Jeff Moyer writes: Jeff> TRIM/UNMAP isn't just supported on solid state devices, though. I Jeff> do recall some enterprise thinly provisioned storage that would Jeff> take ages to discard large regions. I think that caused us to Jeff> change the defaults for

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

> "Jeff" == Jeff Moyer writes: Jeff> TRIM/UNMAP isn't just supported on solid state devices, though. I Jeff> do recall some enterprise thinly provisioned storage that would Jeff> take ages to discard large regions. I think that caused us to Jeff> change the defaults for mkfs, right? I

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 5:33 PM, Eric Sandeen wrote: > I may have lost the thread at this point, with poor Darrick's original > patch submission devolving into a long thread about a NO_HIDE_STALE patch > used at Google, but I don't *think* Ceph ever asked for NO_HIDE_STALE. >

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 5:33 PM, Eric Sandeen wrote: > I may have lost the thread at this point, with poor Darrick's original > patch submission devolving into a long thread about a NO_HIDE_STALE patch > used at Google, but I don't *think* Ceph ever asked for NO_HIDE_STALE. > > At least I can't

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 02:00:18PM -0700, Chris Mason wrote: > > Thinking more, my guess is that google will just keep doing what they > are already doing ;) But there could be a flag in sysfs dedicated to > trim-for-fallocate so admins can see what their devices are reporting. > readonly in

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 02:00:18PM -0700, Chris Mason wrote: > > Thinking more, my guess is that google will just keep doing what they > are already doing ;) But there could be a flag in sysfs dedicated to > trim-for-fallocate so admins can see what their devices are reporting. > readonly in

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16 2016, Theodore Ts'o wrote: > On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: >> >> Stale data escaping containment is a security issue. Enabling >> generic kernel mechanisms to *enable containment escape* is >> fundamentally wrong, and relying on userspace to Do The

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16 2016, Theodore Ts'o wrote: > On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: >> >> Stale data escaping containment is a security issue. Enabling >> generic kernel mechanisms to *enable containment escape* is >> fundamentally wrong, and relying on userspace to Do The

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 02:49:06PM -0600, Andreas Dilger wrote: > On Mar 17, 2016, at 12:35 PM, Chris Mason wrote: > > > > On Thu, Mar 17, 2016 at 10:47:29AM -0700, Linus Torvalds wrote: > >> On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: > >>> > >>> So

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 02:49:06PM -0600, Andreas Dilger wrote: > On Mar 17, 2016, at 12:35 PM, Chris Mason wrote: > > > > On Thu, Mar 17, 2016 at 10:47:29AM -0700, Linus Torvalds wrote: > >> On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: > >>> > >>> So we've not asked for

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: > > So we've not asked for NO_HIDE_STALE on the mailing lists, but I think > it was one of the problems Sage had using xfs in his BlueStore > implementation and was a big part of why it moved to pure userspace. > FileStore

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: > > So we've not asked for NO_HIDE_STALE on the mailing lists, but I think > it was one of the problems Sage had using xfs in his BlueStore > implementation and was a big part of why it moved to pure userspace. > FileStore might use

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

"Theodore Ts'o" writes: > I do think that using TRIM in various causes where we are doing an > fallocate does make sense for non-rotational devices. In general TRIM > should be fast enough that that I'd be surprised that people would be > complaining --- especially since most of

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

"Theodore Ts'o" writes: > I do think that using TRIM in various causes where we are doing an > fallocate does make sense for non-rotational devices. In general TRIM > should be fast enough that that I'd be surprised that people would be > complaining --- especially since most of the time,

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 03:45:49PM -0600, Andreas Dilger wrote: > > Clearly, the performance hit of unwritten extent conversion is large > > enough to tempt people to ask for no-hide-stale. But I'd rather hear > > that directly from a developer, Ceph or otherwise. > > I suspect that this gets

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 03:45:49PM -0600, Andreas Dilger wrote: > > Clearly, the performance hit of unwritten extent conversion is large > > enough to tempt people to ask for no-hide-stale. But I'd rather hear > > that directly from a developer, Ceph or otherwise. > > I suspect that this gets

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 10:50 AM, Ric Wheeler wrote: >> >> That argues against worrying about this all in the kernel unless there >> are other users. > > Just a note, when Greg says "user space solution", Ceph is looking at > writing directly to raw block devices which is

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 10:50 AM, Ric Wheeler wrote: >> >> That argues against worrying about this all in the kernel unless there >> are other users. > > Just a note, when Greg says "user space solution", Ceph is looking at > writing directly to raw block devices which is kind of a through back

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 05:51:17PM -0700, Chris Mason wrote: > On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: > > On 3/15/16 7:06 PM, Linus Torvalds wrote: > > > On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: > > >> > > > >> > It is pretty clear that the

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 05:51:17PM -0700, Chris Mason wrote: > On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: > > On 3/15/16 7:06 PM, Linus Torvalds wrote: > > > On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: > > >> > > > >> > It is pretty clear that the onus is on the patch

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 10:47:29AM -0700, Linus Torvalds wrote: > On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: > > > > So we've not asked for NO_HIDE_STALE on the mailing lists, but I think > > it was one of the problems Sage had using xfs in his BlueStore > >

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 10:47:29AM -0700, Linus Torvalds wrote: > On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: > > > > So we've not asked for NO_HIDE_STALE on the mailing lists, but I think > > it was one of the problems Sage had using xfs in his BlueStore > > implementation and was a

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 06:51:39PM -0700, Darrick J. Wong wrote: > On Tue, Mar 15, 2016 at 06:52:24PM -0400, Theodore Ts'o wrote: > > On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: > > > > > > Stale data escaping containment is a security issue. Enabling > > > generic kernel

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 06:51:39PM -0700, Darrick J. Wong wrote: > On Tue, Mar 15, 2016 at 06:52:24PM -0400, Theodore Ts'o wrote: > > On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: > > > > > > Stale data escaping containment is a security issue. Enabling > > > generic kernel

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mar 15, 2016, at 7:51 PM, Darrick J. Wong wrote: > > On Tue, Mar 15, 2016 at 06:52:24PM -0400, Theodore Ts'o wrote: >> On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: >>> >>> Stale data escaping containment is a security issue. Enabling >>> generic

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mar 15, 2016, at 7:51 PM, Darrick J. Wong wrote: > > On Tue, Mar 15, 2016 at 06:52:24PM -0400, Theodore Ts'o wrote: >> On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: >>> >>> Stale data escaping containment is a security issue. Enabling >>> generic kernel mechanisms to *enable

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 11:52 PM, Gregory Farnum wrote: > > I wasn't really involved in this stuff but I gather from looking at > http://www.spinics.net/lists/xfs/msg36869.html that any durability > command other than fdatasync is going to write out the mtime updates > to the

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 11:52 PM, Gregory Farnum wrote: > > I wasn't really involved in this stuff but I gather from looking at > http://www.spinics.net/lists/xfs/msg36869.html that any durability > command other than fdatasync is going to write out the mtime updates > to the inodes on disk.

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 12:01:16PM +1100, Dave Chinner wrote: > On Tue, Mar 15, 2016 at 06:51:39PM -0700, Darrick J. Wong wrote: > > On Tue, Mar 15, 2016 at 06:52:24PM -0400, Theodore Ts'o wrote: > > > On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: > > > > > > > > Stale data

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 12:01:16PM +1100, Dave Chinner wrote: > On Tue, Mar 15, 2016 at 06:51:39PM -0700, Darrick J. Wong wrote: > > On Tue, Mar 15, 2016 at 06:52:24PM -0400, Theodore Ts'o wrote: > > > On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: > > > > > > > > Stale data

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mar 17, 2016, at 12:35 PM, Chris Mason wrote: > > On Thu, Mar 17, 2016 at 10:47:29AM -0700, Linus Torvalds wrote: >> On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: >>> >>> So we've not asked for NO_HIDE_STALE on the mailing lists, but I think >>> it

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mar 17, 2016, at 12:35 PM, Chris Mason wrote: > > On Thu, Mar 17, 2016 at 10:47:29AM -0700, Linus Torvalds wrote: >> On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: >>> >>> So we've not asked for NO_HIDE_STALE on the mailing lists, but I think >>> it was one of the problems Sage had

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 07:33:55PM -0500, Eric Sandeen wrote: > I may have lost the thread at this point, with poor Darrick's original > patch submission devolving into a long thread about a NO_HIDE_STALE patch > used at Google, but I don't *think* Ceph ever asked for NO_HIDE_STALE. > > At least

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 07:33:55PM -0500, Eric Sandeen wrote: > I may have lost the thread at this point, with poor Darrick's original > patch submission devolving into a long thread about a NO_HIDE_STALE patch > used at Google, but I don't *think* Ceph ever asked for NO_HIDE_STALE. > > At least

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/16/2016 06:23 PM, Chris Mason wrote: On Tue, Mar 15, 2016 at 05:51:17PM -0700, Chris Mason wrote: On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: On 3/15/16 7:06 PM, Linus Torvalds wrote: On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: It is

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/16/2016 06:23 PM, Chris Mason wrote: On Tue, Mar 15, 2016 at 05:51:17PM -0700, Chris Mason wrote: On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: On 3/15/16 7:06 PM, Linus Torvalds wrote: On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: It is pretty clear that the

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 3/16/16 7:15 PM, Theodore Ts'o wrote: > On Wed, Mar 16, 2016 at 03:45:49PM -0600, Andreas Dilger wrote: >>> Clearly, the performance hit of unwritten extent conversion is large >>> enough to tempt people to ask for no-hide-stale. But I'd rather hear >>> that directly from a developer, Ceph or

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 3/16/16 7:15 PM, Theodore Ts'o wrote: > On Wed, Mar 16, 2016 at 03:45:49PM -0600, Andreas Dilger wrote: >>> Clearly, the performance hit of unwritten extent conversion is large >>> enough to tempt people to ask for no-hide-stale. But I'd rather hear >>> that directly from a developer, Ceph or

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/17/2016 01:47 PM, Linus Torvalds wrote: On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: So we've not asked for NO_HIDE_STALE on the mailing lists, but I think it was one of the problems Sage had using xfs in his BlueStore implementation and was a big part of why

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/17/2016 01:47 PM, Linus Torvalds wrote: On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: So we've not asked for NO_HIDE_STALE on the mailing lists, but I think it was one of the problems Sage had using xfs in his BlueStore implementation and was a big part of why it moved to pure

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 10:47 AM, Linus Torvalds wrote: > On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: >> >> So we've not asked for NO_HIDE_STALE on the mailing lists, but I think >> it was one of the problems Sage had using xfs in his

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 10:47 AM, Linus Torvalds wrote: > On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: >> >> So we've not asked for NO_HIDE_STALE on the mailing lists, but I think >> it was one of the problems Sage had using xfs in his BlueStore >> implementation and was a big part of

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 06:52:24PM -0400, Theodore Ts'o wrote: > On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: > > > > Stale data escaping containment is a security issue. Enabling > > generic kernel mechanisms to *enable containment escape* is > > fundamentally wrong, and relying

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 06:52:24PM -0400, Theodore Ts'o wrote: > On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: > > > > Stale data escaping containment is a security issue. Enabling > > generic kernel mechanisms to *enable containment escape* is > > fundamentally wrong, and relying

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: > On 3/15/16 7:06 PM, Linus Torvalds wrote: > > On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: > >> > > >> > It is pretty clear that the onus is on the patch submitter to > >> > provide justification for

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 07:30:14PM -0500, Eric Sandeen wrote: > On 3/15/16 7:06 PM, Linus Torvalds wrote: > > On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: > >> > > >> > It is pretty clear that the onus is on the patch submitter to > >> > provide justification for inclusion, not for the

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 3/15/16 7:06 PM, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: >> > >> > It is pretty clear that the onus is on the patch submitter to >> > provide justification for inclusion, not for the reviewer/Maintainer >> > to have to prove that the

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 3/15/16 7:06 PM, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: >> > >> > It is pretty clear that the onus is on the patch submitter to >> > provide justification for inclusion, not for the reviewer/Maintainer >> > to have to prove that the solution is unworkable.

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 04:14:32PM -0700, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 4:06 PM, Linus Torvalds > wrote: > > > > And yes, "keep the patch entirely inside google" is obviously one good > > way to limit the interface. But if there are really other

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 04:14:32PM -0700, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 4:06 PM, Linus Torvalds > wrote: > > > > And yes, "keep the patch entirely inside google" is obviously one good > > way to limit the interface. But if there are really other groups that > > want to explore

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: > > It is pretty clear that the onus is on the patch submitter to > provide justification for inclusion, not for the reviewer/Maintainer > to have to prove that the solution is unworkable. I agree, but quite frankly,

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote: > > It is pretty clear that the onus is on the patch submitter to > provide justification for inclusion, not for the reviewer/Maintainer > to have to prove that the solution is unworkable. I agree, but quite frankly, performance is a good

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 04:06:10PM -0700, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 3:33 PM, Dave Chinner wrote: > > > >> There's no "group based containment wall" that is some kind of > >> absolute protection border. > > > > Precisely my point - it's being pitched as a

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 04:06:10PM -0700, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 3:33 PM, Dave Chinner wrote: > > > >> There's no "group based containment wall" that is some kind of > >> absolute protection border. > > > > Precisely my point - it's being pitched as a generic containment

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 4:06 PM, Linus Torvalds wrote: > > And yes, "keep the patch entirely inside google" is obviously one good > way to limit the interface. But if there are really other groups that > want to explore this, then that sounds like a pretty horrible

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 4:06 PM, Linus Torvalds wrote: > > And yes, "keep the patch entirely inside google" is obviously one good > way to limit the interface. But if there are really other groups that > want to explore this, then that sounds like a pretty horrible model > too. Side note: I

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 3:33 PM, Dave Chinner wrote: > >> There's no "group based containment wall" that is some kind of >> absolute protection border. > > Precisely my point - it's being pitched as a generic containment > mechanism, but it really isn't. No it hasn't. It

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 3:33 PM, Dave Chinner wrote: > >> There's no "group based containment wall" that is some kind of >> absolute protection border. > > Precisely my point - it's being pitched as a generic containment > mechanism, but it really isn't. No it hasn't. It has been pitched as

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: > > Stale data escaping containment is a security issue. Enabling > generic kernel mechanisms to *enable containment escape* is > fundamentally wrong, and relying on userspace to Do The Right Thing > is even more of a gamble, IMO. We

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: > > Stale data escaping containment is a security issue. Enabling > generic kernel mechanisms to *enable containment escape* is > fundamentally wrong, and relying on userspace to Do The Right Thing > is even more of a gamble, IMO. We

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 3/15/16 3:14 PM, Dave Chinner wrote: > What we are missing is actual numbers that show that exposing stale > data is a /significant/ win for these applications that are > demanding it. And then we need evidence proving that the problem is > actually systemic and not just a hack around a bad

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 3/15/16 3:14 PM, Dave Chinner wrote: > What we are missing is actual numbers that show that exposing stale > data is a /significant/ win for these applications that are > demanding it. And then we need evidence proving that the problem is > actually systemic and not just a hack around a bad

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 01:43:01PM -0700, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 1:14 PM, Dave Chinner wrote: > > > > Root can still change the group id of a file that has exposed stale > > data and hence make it visible outside of the group based > > containment

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 01:43:01PM -0700, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 1:14 PM, Dave Chinner wrote: > > > > Root can still change the group id of a file that has exposed stale > > data and hence make it visible outside of the group based > > containment wall. > > Ok, Dave, now

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 01:43:01PM -0700, Linus Torvalds wrote: > Put another way: this is not about theoretical leaks - because those > are totally irrelevant (in theory, the original discard writer had > access to all that stale data anyway). This is about making it a > practical interface that

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 01:43:01PM -0700, Linus Torvalds wrote: > Put another way: this is not about theoretical leaks - because those > are totally irrelevant (in theory, the original discard writer had > access to all that stale data anyway). This is about making it a > practical interface that

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 1:14 PM, Dave Chinner wrote: > > Root can still change the group id of a file that has exposed stale > data and hence make it visible outside of the group based > containment wall. Ok, Dave, now you're just being ridiculous. The issue has never been

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 1:14 PM, Dave Chinner wrote: > > Root can still change the group id of a file that has exposed stale > data and hence make it visible outside of the group based > containment wall. Ok, Dave, now you're just being ridiculous. The issue has never been - and *should* never

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mon, Mar 14, 2016 at 10:46:03AM -0400, Theodore Ts'o wrote: > On Mon, Mar 14, 2016 at 06:34:00AM -0400, Ric Wheeler wrote: > > I think that once we enter this mode, the local file system has effectively > > ceded its role to prevent stale data exposure to the upper layer. In effect, > > this

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mon, Mar 14, 2016 at 10:46:03AM -0400, Theodore Ts'o wrote: > On Mon, Mar 14, 2016 at 06:34:00AM -0400, Ric Wheeler wrote: > > I think that once we enter this mode, the local file system has effectively > > ceded its role to prevent stale data exposure to the upper layer. In effect, > > this

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mon, Mar 14, 2016 at 06:34:00AM -0400, Ric Wheeler wrote: > I think that once we enter this mode, the local file system has effectively > ceded its role to prevent stale data exposure to the upper layer. In effect, > this ceases to become a normal file system for any enabled process if we >

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mon, Mar 14, 2016 at 06:34:00AM -0400, Ric Wheeler wrote: > I think that once we enter this mode, the local file system has effectively > ceded its role to prevent stale data exposure to the upper layer. In effect, > this ceases to become a normal file system for any enabled process if we >

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/13/2016 07:30 PM, Dave Chinner wrote: On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: At the end of the day it's about whether you trust the userspace program or not. There's a big difference between

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/13/2016 07:30 PM, Dave Chinner wrote: On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: At the end of the day it's about whether you trust the userspace program or not. There's a big difference between "give the user

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: > > > > At the end of the day it's about whether you trust the userspace > > program or not. > > There's a big difference between "give the user rope", and "tie

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: > > > > At the end of the day it's about whether you trust the userspace > > program or not. > > There's a big difference between "give the user rope", and "tie the > rope in a

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/12/2016 08:19 AM, Theodore Ts'o wrote: On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: There's a big difference between "give the user rope", and "tie the rope in a noose and put a banana peel so that the user might stumble into the rope and hang himself", though. [...]

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On 03/12/2016 08:19 AM, Theodore Ts'o wrote: On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: There's a big difference between "give the user rope", and "tie the rope in a noose and put a banana peel so that the user might stumble into the rope and hang himself", though. [...]

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: > > > > At the end of the day it's about whether you trust the userspace > > program or not. > > There's a big difference between "give the user rope", and "tie

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 04:44:16PM -0800, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: > > > > At the end of the day it's about whether you trust the userspace > > program or not. > > There's a big difference between "give the user rope", and "tie the > rope in a

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: > > At the end of the day it's about whether you trust the userspace > program or not. There's a big difference between "give the user rope", and "tie the rope in a noose and put a banana peel so that the user might stumble

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 4:35 PM, Theodore Ts'o wrote: > > At the end of the day it's about whether you trust the userspace > program or not. There's a big difference between "give the user rope", and "tie the rope in a noose and put a banana peel so that the user might stumble into the rope and

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Sat, Mar 12, 2016 at 09:30:47AM +1100, Dave Chinner wrote: > It's all well and good to restrict access to the fallocate() call to > limit who can expose stale data, but it doesn't remove the fact it > is easy for stale data to unintentionally escape the privileged > group once it has been

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Sat, Mar 12, 2016 at 09:30:47AM +1100, Dave Chinner wrote: > It's all well and good to restrict access to the fallocate() call to > limit who can expose stale data, but it doesn't remove the fact it > is easy for stale data to unintentionally escape the privileged > group once it has been

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 2:30 PM, Dave Chinner wrote: > On Fri, Mar 11, 2016 at 10:25:30AM -0800, Linus Torvalds wrote: >> >> So you'd have to explicitly say "my setup is ok with hole punching". > > Except it's not hole punching that is the problem. [..] > The problem here is

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 2:30 PM, Dave Chinner wrote: > On Fri, Mar 11, 2016 at 10:25:30AM -0800, Linus Torvalds wrote: >> >> So you'd have to explicitly say "my setup is ok with hole punching". > > Except it's not hole punching that is the problem. [..] > The problem here is > preallocation of

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 10:25:30AM -0800, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 9:30 AM, Andy Lutomirski wrote: > > > > What if we had an ioctl to do these data-leaking operations that took, > > as an extra parameter, an fd to the block device node. They allow > >

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 10:25:30AM -0800, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 9:30 AM, Andy Lutomirski wrote: > > > > What if we had an ioctl to do these data-leaking operations that took, > > as an extra parameter, an fd to the block device node. They allow > > access if the fd

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 9:30 AM, Andy Lutomirski wrote: > > What if we had an ioctl to do these data-leaking operations that took, > as an extra parameter, an fd to the block device node. They allow > access if the fd points to the right inode and has FMODE_READ (and LSM >

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 9:30 AM, Andy Lutomirski wrote: > > What if we had an ioctl to do these data-leaking operations that took, > as an extra parameter, an fd to the block device node. They allow > access if the fd points to the right inode and has FMODE_READ (and LSM > checks say it's okay).

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 9:23 AM, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 5:59 AM, One Thousand Gnomes > wrote: >> >> > > We can do the security check at the filesystem level, because we have >> > > sb->s_bdev->bd_inode, and if

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 9:23 AM, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 5:59 AM, One Thousand Gnomes > wrote: >> >> > > We can do the security check at the filesystem level, because we have >> > > sb->s_bdev->bd_inode, and if you have read and write permissions to >> > > that inode, you

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 5:59 AM, One Thousand Gnomes wrote: > > > > We can do the security check at the filesystem level, because we have > > > sb->s_bdev->bd_inode, and if you have read and write permissions to > > > that inode, you might as well have permission to

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 5:59 AM, One Thousand Gnomes wrote: > > > > We can do the security check at the filesystem level, because we have > > > sb->s_bdev->bd_inode, and if you have read and write permissions to > > > that inode, you might as well have permission to create a unsafe hole. > > Not

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 01:59:52PM +, One Thousand Gnomes wrote: > > > We can do the security check at the filesystem level, because we have > > > sb->s_bdev->bd_inode, and if you have read and write permissions to > > > that inode, you might as well have permission to create a unsafe hole. >

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Fri, Mar 11, 2016 at 01:59:52PM +, One Thousand Gnomes wrote: > > > We can do the security check at the filesystem level, because we have > > > sb->s_bdev->bd_inode, and if you have read and write permissions to > > > that inode, you might as well have permission to create a unsafe hole. >

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

> > We can do the security check at the filesystem level, because we have > > sb->s_bdev->bd_inode, and if you have read and write permissions to > > that inode, you might as well have permission to create a unsafe hole. Not if you don't have access to a block device node to open it, or there are

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

> > We can do the security check at the filesystem level, because we have > > sb->s_bdev->bd_inode, and if you have read and write permissions to > > that inode, you might as well have permission to create a unsafe hole. Not if you don't have access to a block device node to open it, or there are

  1   2   >