[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <555CE62C.5030202@redhat.com>
Date: Wed, 20 May 2015 15:53:16 -0400
From: Rik van Riel <riel@...hat.com>
To: Daniel Phillips <daniel@...nq.net>, Jan Kara <jack@...e.cz>,
David Lang <david@...g.hm>
CC: tux3@...3.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: [FYI] tux3: Core changes
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() ?
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?
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists