Re: [FYI] tux3: Core changes

[Jan Kara <jack@suse.cz>]

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 <jack@suse.cz>
SUSE Labs, CR