Messages in this thread | | | Date | Wed, 20 May 2015 15:51:11 -0700 | From | Daniel Phillips <> | Subject | Re: [FYI] tux3: Core changes |
| |
On 05/20/2015 12:53 PM, Rik van Riel wrote: > On 05/20/2015 12:22 PM, Daniel Phillips wrote: >> On 05/20/2015 07:44 AM, Jan Kara wrote: >>> On Tue 19-05-15 13:33:31, David Lang wrote: > >>> Yeah, that's what I meant. If you create a function which manipulates >>> page cache, you better make it work with other functions manipulating page >>> cache. Otherwise it's a landmine waiting to be tripped by some unsuspecting >>> developer. Sure you can document all the conditions under which the >>> function is safe to use but a function that has several paragraphs in front >>> of it explaning when it is safe to use isn't very good API... >> >> Violent agreement, of course. To put it in concrete terms, each of >> the page fork support functions must be examined and determined >> sane. They are: >> >> * cow_replace_page_cache >> * cow_delete_from_page_cache >> * cow_clone_page >> * page_cow_one >> * page_cow_file >> >> Would it be useful to drill down into those, starting from the top >> of the list? > > How do these interact with other page cache functions, like > find_get_page() ?
Nicely:
https://github.com/OGAWAHirofumi/linux-tux3/blob/hirofumi/fs/tux3/filemap_mmap.c#L182
> How does tux3 prevent a user of find_get_page() from reading from > or writing into the pre-COW page, instead of the current page?
Careful control of the dirty bits (we have two of them, one each for front and back). That is what pagefork_for_blockdirty is about.
Regards,
Daniel
| |