From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imap.thunk.org ([74.207.234.97]:56354 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754124AbeBBCkI (ORCPT ); Thu, 1 Feb 2018 21:40:08 -0500 Date: Thu, 1 Feb 2018 21:40:03 -0500 From: Theodore Ts'o To: Dave Chinner Cc: James Bottomley , Mimi Zohar , Andreas Dilger , linux-fsdevel , lsf-pc@lists.linux-foundation.org Subject: Re: [Lsf-pc] [LSF/MM TOPIC] fs-verity: file system-level integrity protection Message-ID: <20180202024003.GA21242@thunk.org> References: <20180129045012.GB9516@thunk.org> <1517227741.29187.515.camel@linux.vnet.ibm.com> <20180129230209.GA30762@thunk.org> <1517354702.3469.60.camel@linux.vnet.ibm.com> <20180131160510.GA18615@thunk.org> <1517418768.3937.59.camel@HansenPartnership.com> <20180131184647.GA29819@thunk.org> <1517431273.3344.28.camel@HansenPartnership.com> <20180201000315.GB3375@thunk.org> <20180201230415.7cyxhwq234vd3in4@destitution> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180201230415.7cyxhwq234vd3in4@destitution> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Feb 02, 2018 at 10:04:15AM +1100, Dave Chinner wrote: > I think putting valid data beyond EOF is going to be problematic for > many filesystems. Getting things like truncate right are hard enough > without having to special case a bunch of new functionality that > specifically allows IO access beyond EOF. Indeed, how does "truncate > isize but leave special data behind" work and what's the userspace > API to drive it? And how does it interact with all the page cache > code that checks for page->index beyond EOF to detect a truncated > page that should not be accessed? This isn't an issue because once fs-verity protection is enabled, the file becomes immutable. That is, you can delete the file, but you can't modify it afterwards --- so you don't have to truncate it. We don't actually want userspace to be able to access pages beyond i_size via read(2) or mmap(2), so I don't believe this to be a problem. It's only kernel code that needs to access the pages via find_get_page. Regards, - Ted