On Mon 22-06-15 00:36:00, OGAWA Hirofumi wrote:
Jan Kara j...@suse.cz writes:
So there are a few things to have in mind:
1) There is nothing like a writeable page. Page is always writeable (at
least on x86 architecture). When a page is mapped into some virtual address
space (or more
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 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.
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
-fsdevel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jan Kara j...@suse.cz
SUSE Labs, CR
___
Tux3 mailing list
Tux3@phunq.net
http://phunq.net/mailman/listinfo/tux3
in mmapped memory...
Honza
--
Jan Kara j...@suse.com
SUSE Labs, CR
___
Tux3 mailing list
Tux3@phunq.net
http://phunq.net/mailman/listinfo/tux3
On Sun 09-08-15 22:42:42, OGAWA Hirofumi wrote:
Jan Kara j...@suse.cz writes:
I'm not sure about which ENOSPC issue you are speaking BTW. Can you
please ellaborate?
1. GUP simulate page fault, and prepare to modify
2. writeback clear dirty, and make PTE read-only
3. snapshot/reflink
On Sun 05-07-15 21:54:45, OGAWA Hirofumi wrote:
Jan Kara j...@suse.cz writes:
I'm not sure I'm understanding your pseudocode logic correctly though.
This logic doesn't seems to be a page forking specific issue. And
this pseudocode logic seems to be missing the locking and revalidate
