On 1/24/14, Zameer Manji <zmanji@xxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
