How to identify a 'fresh' page from read_cache_page?

[Pranay Srivastava]

On 1/24/14, Zameer Manji <zmanji at gmail.com> wrote:
> Hey,
>
> My colleague Will and I are working on improving eCryptfs, an encrypted
> file system that ships with linux. We are trying to add a new cipher mode
> and we have run into a problem [1]. When the user calls `ftruncate` on a
> file and increases the file size, eCryptfs attempts fetch new pages for the
> file by calling `read_mapping_page` and which calls `read_cache_page`. This
> calls eCryptfs' `readpage` implementation. We believe `read_cache_page`
> calls `readpage` with a page that we have not written to before (since the
> user is increasing the file size via `ftruncate`).
>
> What function can we use to identify when we are given a page to our
> `readpage` implementation that is a page we have never written to before?

Why do you think that will happen? I mean why would you get a page in your
readpage implmentation that you already wrote? Unless you unlock the recently
written page calling thread would wait for it. Be it a thread or reclaim by VM.

As long as your readpage doesn't want to touch a page which is being
handled by another
readpage call already i think you are safe to assume that your
readpage is getting
only a NOT_UPTODATE page.



> We need to do this so we know if should check the integrity of the data in
> the page (if we wrote to it before) or just ignore the contents (because it
> is a fresh page with garbage data). For more information our
> ecryptfs_readpage implementation is available on github [2].
>
> Please note that I am not subscribed to kernelnewbies so please include me
> directly in any replies.
>
> [1]: http://marc.info/?l=ecryptfs-users&m=139007357027191&w=2
> [2]:
> https://github.com/zmanji/ecryptfs/blob/next-patch/fs/ecryptfs/mmap.c#L193
>
> --
> Zameer Manji
>


-- 
Pranay Srivastava