Protection of 'struct address_space'?

Protection of 'struct address_space'?

[Perez-Gonzalez, Inaky]

Hi All

Some days ago I came around with a question on how to get 
a 'struct page *' backed up by a 'struct inode *' and an offset.
Came up with:

01 int __vl_key_page_get_shared (struct page **ppage,
02                               struct inode *inode, unsigned pgoff)
03 {
04         int result;
05         struct page *page;
06         struct address_space *mapping = inode->i_mapping;
07 
08 #warning: FIXME: block/lock the mapping...I am not that sure of this
09         down (&mapping->i_shared_sem);
10         page = read_cache_page (mapping, pgoff, 
11                                 (filler_t *) mapping->a_ops->readpage, NULL);
12         result = PTR_ERR (page);
13         if (IS_ERR (page))
14                 goto out_up;
15         
16         wait_on_page_locked (page);
17         if (!PageUptodate (page)) {
18                 page_cache_release (page);
19                 page = ERR_PTR (-EIO);
20         }
21         *ppage = page;
22         return 0;
23 
24 out_up:
25         up (&mapping->i_shared_sem);
26         return result;
27 }

[this followed a put() kind of function that would release 
the page and the i_shared_sem semaphore].

Now in 2.6.7, i_shared_sem is gone and replaced by a i_mmap_lock,
what makes it impossible to use for this case as read_cache_page()
will sleep and so might wait_on_page_locked().

Then I realized I probably don't need to lock the struct 
address_space, but it strikes me as odd--it's a shared struct.
I need to maintain the address space in tight control while I am
accessing it. So the question is: what is the proper way? can't 
find any good examples in the kernel code that show it.

Thanks,

Inaky Perez-Gonzalez -- Not speaking for Intel -- all opinions are my own (and my fault)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>