Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751806AbbEZJBH (ORCPT ); Tue, 26 May 2015 05:01:07 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47601 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751630AbbEZJBE (ORCPT ); Tue, 26 May 2015 05:01:04 -0400 Date: Tue, 26 May 2015 11:00:58 +0200 From: Jan Kara To: Daniel Phillips Cc: Jan Kara , David Lang , Rik van Riel , linux-fsdevel@vger.kernel.org, tux3@tux3.org, linux-kernel@vger.kernel.org, OGAWA Hirofumi Subject: Re: [FYI] tux3: Core changes Message-ID: <20150526090058.GA8024@quack.suse.cz> References: <555D0FDF.3070303@phunq.net> <555D500B.4080901@phunq.net> <13c8bcdf-70e8-43d5-a05f-58ad839dbfd0@phunq.net> <5563F5C8.2040806@redhat.com> <67294911-1776-46b8-916d-0e5642a38725@phunq.net> <20150526070910.GA3307@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1844 Lines: 41 On Tue 26-05-15 01:08:56, Daniel Phillips wrote: > On Tuesday, May 26, 2015 12:09:10 AM PDT, Jan Kara wrote: > > E.g. video drivers (or infiniband or direct IO for that matter) which > >have buffers in user memory (may be mmapped file), grab references to pages > >and hand out PFNs of those pages to the hardware to store data in them... > >If you fork a page after the driver has handed PFNs to the hardware, you've > >just lost all the writes hardware will do. > > Hi Jan, > > The page forked because somebody wrote to it with write(2) or mmap write at > the same time as a video driver (or infiniband or direct IO) was > doing io to > it. Isn't the application trying hard to lose data in that case? It > would not need page fork to lose data that way. So I can think of two valid uses: 1) You setup IO to part of a page and modify from userspace a different part of a page. 2) At least for video drivers there is one ioctl() which creates object with buffers in memory and another ioctl() to actually ship it to hardware (may be called repeatedly). So in theory app could validly dirty the pages before it ships them to hardware. If this happens repeatedly and interacts badly with background writeback, you will end up with a forked page in a buffer and from that point on things are broken. So my opinion is: Don't fork the page if page_count is elevated. You can just wait for the IO if you need stable pages in that case. It's slow but it's safe and it should be pretty rare. Is there any problem with that? Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/