How to safely access inode/dentry obtained from struct page *?

How to safely access inode/dentry obtained from struct page *?

[Joshi]

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

How to safely access inode/dentry obtained from struct page *?

[Valdis.Kletnieks at vt.edu]

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.....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140901/ca5c6837/attachment.bin 

How to safely access inode/dentry obtained from struct page *?

[Pranay Srivastava]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140901/68a0c656/attachment.html 

How to safely access inode/dentry obtained from struct page *?

[Pranay Srivastava]

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 at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140901/10b088ef/attachment.html 

How to safely access inode/dentry obtained from struct page *?

[Joshi]

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

How to safely access inode/dentry obtained from struct page *?

[Valdis.Kletnieks at vt.edu]

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).



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140903/ebfcf0cc/attachment.bin 

How to safely access inode/dentry obtained from struct page *?

[Joshi]

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 at kernelnewbies.org
>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
Joshi

How to safely access inode/dentry obtained from struct page *?

[Rohan Puri]

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 at kernelnewbies.org
> >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> --
> Joshi
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at 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

How to safely access inode/dentry obtained from struct page *?

[Rohan Puri]

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 at kernelnewbies.org
>> >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>>
>> --
>> Joshi
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at 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