From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [FYI] tux3: Core changes Date: Tue, 26 May 2015 11:00:58 +0200 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-Transfer-Encoding: 7bit Cc: David Lang , Rik van Riel , Jan Kara , tux3@tux3.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, OGAWA Hirofumi To: Daniel Phillips Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tux3-bounces@phunq.net Sender: "Tux3" List-Id: linux-fsdevel.vger.kernel.org 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