Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934493AbcCNOq3 (ORCPT ); Mon, 14 Mar 2016 10:46:29 -0400 Received: from imap.thunk.org ([74.207.234.97]:41912 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932705AbcCNOq0 (ORCPT ); Mon, 14 Mar 2016 10:46:26 -0400 Date: Mon, 14 Mar 2016 10:46:03 -0400 From: "Theodore Ts'o" To: Ric Wheeler Cc: Dave Chinner , Linus Torvalds , Andy Lutomirski , One Thousand Gnomes , Gregory Farnum , "Martin K. Petersen" , Christoph Hellwig , "Darrick J. Wong" , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton , Eric Sandeen Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Message-ID: <20160314144603.GO29218@thunk.org> Mail-Followup-To: Theodore Ts'o , Ric Wheeler , Dave Chinner , Linus Torvalds , Andy Lutomirski , One Thousand Gnomes , Gregory Farnum , "Martin K. Petersen" , Christoph Hellwig , "Darrick J. Wong" , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton , Eric Sandeen References: <56E24CA5.3030702@redhat.com> <20160311135952.57a44931@lxorguk.ukuu.org.uk>

<20160311223047.GZ30721@dastard> <20160312003556.GF32214@thunk.org> <20160313233049.GA30721@dastard> <56E69398.7030508@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E69398.7030508@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1076 Lines: 22 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 > control this through fallocate() or for all processes if we do the brute > force mount option that would be file system wide. Or we do this via group id, such that we are ceding responsibility for proventing stale data exposure to the processes running under that group id. That process has the responsibility for making sure that it doesn't return any data from that file unless it has been written, and also to make sure the permissions of that file are not readable by processes that aren't in that group. (For example, owned by user ceph, group ceph, with premissions 640). > In the end, that is the actual goal - move this enforcement up a layer for > overlay/user space file systems that are then responsible for policing this > ind of thing. Yes, exactly. - Ted