linux-kernel - Re: [PATCH v7 07/22] Replace the XIP page fault handler with the DAX page fault handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 11 Aug 2014 17:25:01 +0200
From:	Jan Kara <jack@...e.cz>
To:	Matthew Wilcox <willy@...ux.intel.com>
Cc:	Jan Kara <jack@...e.cz>,
	Matthew Wilcox <matthew.r.wilcox@...el.com>,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 07/22] Replace the XIP page fault handler with the DAX
 page fault handler

On Mon 11-08-14 11:02:05, Matthew Wilcox wrote:
> On Mon, Aug 11, 2014 at 04:35:00PM +0200, Jan Kara wrote:
> > On Mon 11-08-14 10:13:08, Matthew Wilcox wrote:
> > > On Mon, Aug 11, 2014 at 10:51:47AM +0200, Jan Kara wrote:
> > > > So I'm afraid we'll have to find some other way to synchronize
> > > > page faults and truncate / punch hole in DAX.
> > > 
> > > What if we don't?  If we hit the race (which is vanishingly unlikely with
> > > real applications), the consequence is simply that after a truncate, a
> > > file may be left with one or two blocks allocated somewhere after i_size.
> > > As I understand it, that's not a real problem; they're temporarily
> > > unavailable for allocation but will be freed on file removal or the next
> > > truncation of that file.
> >   You mean if you won't have any locking between page fault and truncate?
> > You can have:
> > a) extending truncate making forgotten blocks with non-zeros visible
> > b) filesystem corruption due to doubly used blocks (block will be freed
> > from the truncated file and thus can be reallocated but it will still be
> > accessible via mmap from the truncated file).
> > 
> >   So not a good idea.
> 
> Not *no* locking ... just no locking around get_block, like in v7.
> So check i_size, call get_block, lock i_mmap_mutex, re-check i_size,
> insert mapping if i_size is OK, drop i_mmap_mutex.  As long as get_block()
> has enough locking of its own against set_size and concurrent calls
> to get_block(), I don't think we can get visible non-zeroes or double
> allocation.
  Ah, right. Now I remember. Yes, that solution will only occasionally
leave allocated blocks beyond EOF. That may be acceptable especially if we
mark the file with some flag and truncate those blocks after file is closed
in ext4_release_file().

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/