How to safely access inode/dentry obtained from struct page *?
I am trying to obtain file name at block layer level (above IO scheduler). At this level I receive bio structure, within which page pointers are kept. Thereby I do following to obtain the inode and dentry - struct inode *inode_ptr = page->mapping->host; if (inode_ptr != NULL) /* Access dentry i.e. i_dentry in the inode */ This works usually. But problem is, inode and dentry may get released from inode and dentry cache at any time. While accessing inode/dentry I need to ensure that till the time I am accessing'em these structure remain valid in memory. Is it possible to ensure that? Which structures/locks I need to check for the purpose. Appreciate any help. Thanks! -- Joshi
On Sat, 30 Aug 2014 10:41:16 +0530, Joshi said:
I am trying to obtain file name at block layer level (above IO scheduler).
Nope. Won't work. There is no single unique name for a file. Consider: touch a ln a b There's now 2 names for the same inode. And why should the block level care about the file name, anyhow? It doesn't even know if it's a file or metadata... or even if there's a filesystem on the partition at all.....
On Mon, Sep 1, 2014 at 9:40 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Sat, 30 Aug 2014 10:41:16 +0530, Joshi said:
I am trying to obtain file name at block layer level (above IO scheduler).
Nope. Won't work. There is no single unique name for a file.
Consider:
touch a ln a b
There's now 2 names for the same inode.
Yes, I ignore hard-link case. No harm.
And why should the block level care about the file name, anyhow? It doesn't even know if it's a file or metadata... or even if there's a filesystem on the partition at all.....
I do this only when I know that I am working on a partition which has filesystem If it's metadata, file name is not associated with it. Either I would find inode or dentry as NULL, that's all. I just want to eliminate the possibility of crash while accessing inode/dentry if it exists. -- Joshi
On Wed, 03 Sep 2014 22:37:26 +0530, Joshi said:
I do this only when I know that I am working on a partition which has filesystem
The problem is that the block layer has no way of knowing that. What problem are you trying to solve here, and why are you trying to do it from the block layer? The *proper* design here would probably involve doing VFS hooking of some sort to *tell* the block layer what to do (for instance, if you're trying to do some sort of "secure erase", you would have the VFS schedule a bunch of I/Os to the block layer).
On 30-Aug-2014 10:49 AM, "Joshi" <joshiiitr@gmail.com> wrote:
I am trying to obtain file name at block layer level (above IO scheduler). At this level I receive bio structure, within which page pointers are
kept.
Thereby I do following to obtain the inode and dentry -
struct inode *inode_ptr = page->mapping->host; if (inode_ptr != NULL) /* Access dentry i.e. i_dentry in the inode */
Are you doing this in readpage(s) or writepage(s) callback? If that's the case your page would be locked and dentry/inode wouldn't go away. If you are doing something else then first make sure you do lock_page and proceed only if you get that page lock. Second you can try dget and dput before you start working with dentry.
This works usually. But problem is, inode and dentry may get released from inode and dentry cache at any time. While accessing inode/dentry I need to ensure that till the time I am accessing'em these structure remain valid in memory. Is it possible to ensure that? Which structures/locks I need to check for the purpose.
is this your observation from your test case? Can you explain your test case a bit.
Appreciate any help.
Thanks!
-- Joshi
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On 01-Sep-2014 10:18 AM, "Pranay Srivastava" <pranjas@gmail.com> wrote:
On 30-Aug-2014 10:49 AM, "Joshi" <joshiiitr@gmail.com> wrote:
I am trying to obtain file name at block layer level (above IO
scheduler).
At this level I receive bio structure, within which page pointers are kept.
Thereby I do following to obtain the inode and dentry -
struct inode *inode_ptr = page->mapping->host; if (inode_ptr != NULL) /* Access dentry i.e. i_dentry in the inode */
Are you doing this in readpage(s) or writepage(s) callback? If that's the case your page would be locked and dentry/inode wouldn't go away.
If you are doing something else then first make sure you do lock_page and proceed only if you get that page lock.
Second you can try dget and dput before you start working with dentry.
This works usually. But problem is, inode and dentry may get released from inode and dentry cache at any time. While accessing inode/dentry I need to ensure that till the time I am accessing'em these structure remain valid in memory. Is it possible to ensure that? Which structures/locks I need to check for the purpose.
is this your observation from your test case? Can you explain your test case a bit.
Have you seen d_alias and see if that can help you with filename?
Appreciate any help.
Thanks!
-- Joshi
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Thanks Pranay. Please see below- On Mon, Sep 1, 2014 at 10:19 AM, Pranay Srivastava <pranjas@gmail.com> wrote:
On 01-Sep-2014 10:18 AM, "Pranay Srivastava" <pranjas@gmail.com> wrote:
On 30-Aug-2014 10:49 AM, "Joshi" <joshiiitr@gmail.com> wrote:
I am trying to obtain file name at block layer level (above IO scheduler). At this level I receive bio structure, within which page pointers are kept.
Thereby I do following to obtain the inode and dentry -
struct inode *inode_ptr = page->mapping->host; if (inode_ptr != NULL) /* Access dentry i.e. i_dentry in the inode */
Are you doing this in readpage(s) or writepage(s) callback? If that's the case your page would be locked and dentry/inode wouldn't go away.
If you are doing something else then first make sure you do lock_page and proceed only if you get that page lock.
I am not operating at file-system level. I am operating on the bio that file-system(or any other component above IO scheduler) might have sent. Do you think that page descriptor kept in bio (for write) is going to vanish? I am not accessing the data of the page, just the page->mapping pointer.
Second you can try dget and dput before you start working with dentry.
I will try that.
This works usually. But problem is, inode and dentry may get released from inode and dentry cache at any time. While accessing inode/dentry I need to ensure that till the time I am accessing'em these structure remain valid in memory. Is it possible to ensure that? Which structures/locks I need to check for the purpose.
is this your observation from your test case? Can you explain your test case a bit.
No, normally I obtain file name. But with fsstress, this causes crash.
Have you seen d_alias and see if that can help you with filename?
I do get filename from dentry. But while I am accessing that, it can be freed by vfs.
Appreciate any help.
Thanks!
-- Joshi
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Joshi
On Wed, Sep 3, 2014 at 10:50 PM, Joshi <joshiiitr@gmail.com> wrote:
Thanks Pranay. Please see below-
On Mon, Sep 1, 2014 at 10:19 AM, Pranay Srivastava <pranjas@gmail.com> wrote:
On 01-Sep-2014 10:18 AM, "Pranay Srivastava" <pranjas@gmail.com> wrote:
On 30-Aug-2014 10:49 AM, "Joshi" <joshiiitr@gmail.com> wrote:
I am trying to obtain file name at block layer level (above IO scheduler). At this level I receive bio structure, within which page pointers are kept.
Thereby I do following to obtain the inode and dentry -
struct inode *inode_ptr = page->mapping->host; if (inode_ptr != NULL) /* Access dentry i.e. i_dentry in the inode */
Are you doing this in readpage(s) or writepage(s) callback? If that's the case your page would be locked and dentry/inode wouldn't go away.
If you are doing something else then first make sure you do lock_page and proceed only if you get that page lock.
I am not operating at file-system level. I am operating on the bio that file-system(or any other component above IO scheduler) might have sent. Do you think that page descriptor kept in bio (for write) is going to vanish? I am not accessing the data of the page, just the page->mapping pointer.
Yes, it can happen. Race condition for your case can happen either due to page mapping removed or dentry removed from cache.Cases that I can think of are invalidations/truncation of page mapping happening (truncate, file delete, file hole punching) & as default IO is async so dentry can be evicted due to load as in fsstress by the time you print filename.
Second you can try dget and dput before you start working with dentry.
I will try that.
This works usually. But problem is, inode and dentry may get released from inode and dentry cache at any time. While accessing inode/dentry I need to ensure that till the time I am accessing'em these structure remain valid in memory. Is it possible to ensure that? Which structures/locks I need to check for the purpose.
is this your observation from your test case? Can you explain your test case a bit.
No, normally I obtain file name. But with fsstress, this causes crash.
Have you seen d_alias and see if that can help you with filename?
I do get filename from dentry. But while I am accessing that, it can be freed by vfs.
Appreciate any help.
Thanks!
-- Joshi
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Joshi
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Make use of proper synchronization stuff as Pranay pointed out. Btw, what is the use case you need this for ? (just curious to know) - Rohan
On Thu, Sep 4, 2014 at 1:33 AM, Rohan Puri <rohan.puri15@gmail.com> wrote:
On Wed, Sep 3, 2014 at 10:50 PM, Joshi <joshiiitr@gmail.com> wrote:
Thanks Pranay. Please see below-
On Mon, Sep 1, 2014 at 10:19 AM, Pranay Srivastava <pranjas@gmail.com> wrote:
On 01-Sep-2014 10:18 AM, "Pranay Srivastava" <pranjas@gmail.com> wrote:
On 30-Aug-2014 10:49 AM, "Joshi" <joshiiitr@gmail.com> wrote:
I am trying to obtain file name at block layer level (above IO scheduler). At this level I receive bio structure, within which page pointers are kept.
Thereby I do following to obtain the inode and dentry -
struct inode *inode_ptr = page->mapping->host; if (inode_ptr != NULL) /* Access dentry i.e. i_dentry in the inode */
Are you doing this in readpage(s) or writepage(s) callback? If that's the case your page would be locked and dentry/inode wouldn't go away.
If you are doing something else then first make sure you do lock_page and proceed only if you get that page lock.
I am not operating at file-system level. I am operating on the bio that file-system(or any other component above IO scheduler) might have sent. Do you think that page descriptor kept in bio (for write) is going to vanish? I am not accessing the data of the page, just the page->mapping pointer.
Yes, it can happen. Race condition for your case can happen either due to page mapping removed or dentry removed from cache.Cases that I can think of are invalidations/truncation of page mapping happening (truncate, file delete, file hole punching) & as default IO is async so dentry can be evicted due to load as in fsstress by the time you print filename.
Second you can try dget and dput before you start working with dentry.
I will try that.
This works usually. But problem is, inode and dentry may get released from inode and dentry cache at any time. While accessing inode/dentry I need to ensure that till the time I am accessing'em these structure remain valid in memory. Is it possible to ensure that? Which structures/locks I need to check for the purpose.
is this your observation from your test case? Can you explain your test case a bit.
No, normally I obtain file name. But with fsstress, this causes crash.
Have you seen d_alias and see if that can help you with filename?
I do get filename from dentry. But while I am accessing that, it can be freed by vfs.
Appreciate any help.
Thanks!
-- Joshi
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Joshi
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Make use of proper synchronization stuff as Pranay pointed out. Btw, what is the use case you need this for ? (just curious to know) - Rohan
participants (4)
-
Joshi -
Pranay Srivastava -
Rohan Puri -
Valdis.Kletnieks＠vt.edu