/proc/<pid>/maps API addition - seek to address

/proc/<pid>/maps API addition - seek to address

[Jeremy Fitzhardinge]

It would be terribly useful to have some way of
lseeking /proc/<pid>/maps to the entry of a particular address.  So, if
you want to find the information about a mapping containing address
0x12345678, it would set the file position to (say) the entry of
0x12000000-0x20000000.

I haven't looked at how /proc/<pid>/maps is implemented these days; is
this outright hard, or relatively straightforward?  This wouldn't be
very useful if it had to actually generate all the output up to the
desired point, but it would be a boon if it could short-circuit that.  I
guess the interactions with normal lseek might be tricky (but perhaps
that could be put off until you actually use lseek, if ever).

Alternatively, any other API for finding the properties of page X would
be useful, but this seemed like a nice incremental extension of the
existing interface.

	J

Re: /proc/<pid>/maps API addition - seek to address

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jeremy Fitzhardinge wrote:
> It would be terribly useful to have some way of
> lseeking /proc/<pid>/maps to the entry of a particular address.  So, if
> you want to find the information about a mapping containing address
> 0x12345678, it would set the file position to (say) the entry of
> 0x12000000-0x20000000.
> 
> I haven't looked at how /proc/<pid>/maps is implemented these days; is
> this outright hard, or relatively straightforward?  This wouldn't be
> very useful if it had to actually generate all the output up to the
> desired point, but it would be a boon if it could short-circuit that.  I
> guess the interactions with normal lseek might be tricky (but perhaps
> that could be put off until you actually use lseek, if ever).
> 

I'm fairly certain you can just return that the seek is done, and set
flags for the file descriptor, then on read() have it return the data
you want it to.


> Alternatively, any other API for finding the properties of page X would
> be useful, but this seemed like a nice incremental extension of the
> existing interface.
> 
> 	J
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB600dhDd4aOud5P8RAlvoAJsFi6ZUMTVhqQBWqZFkv8ubeJEyegCfYhhl
6Gy3TLn/ngSQDugT0CxOpnY=
=rR0f
-----END PGP SIGNATURE-----

Re: /proc/<pid>/maps API addition - seek to address

[Prasanna Meda]

Jeremy Fitzhardinge wrote:

> It would be terribly useful to have some way of
> lseeking /proc/<pid>/maps to the entry of a particular address.  So, if
> you want to find the information about a mapping containing address
> 0x12345678, it would set the file position to (say) the entry of
> 0x12000000-0x20000000.
>
> I haven't looked at how /proc/<pid>/maps is implemented these days; is
> this outright hard, or relatively straightforward?  This wouldn't be
> very useful if it had to actually generate all the output up to the
> desired point, but it would be a boon if it could short-circuit that.  I
> guess the interactions with normal lseek might be tricky (but perhaps
> that could be put off until you actually use lseek, if ever).

 We can do lseek to any position  with SEEK_CUR or SEEK_SET.
That position is byte position, not  map number or map address.
Changing byte position with lseek generates all the output upto the
desired point  inside the kernel using seq  traverse().  Moreover records
are not of fixed lengths.  But given the adress,   finding the page can be
short  circuited (find_vma()  finds it in O(log n) time).  There is no API
 from user.  Changing the semantics of lseek to  other  than byte position
does not look  right.

>
> Alternatively, any other API for finding the properties of page X would
> be useful, but this seemed like a nice incremental extension of the
> existing interface.

Yes, Proc files do not implement ioctl method.  I guess we can add
this feature as ioctl on  /proc/pid/maps file, if  everyone agrees  that is right.

One of the following methods.
ioctl (fd,  GET_MAP,  address,  buf)  -  Does not interfere with lseek
or read.  Find it and copy it.
   OR
ioctl (fd,   SET_FPOS,  address)  - Changes the file position to the
byte position of the map corresponding to address, and next read
returns the data from that position.  Once the adress is found,  this
needs generating all the data upto  that address similar to lseek. If
we convert maps to fixed length records,  it would be better, but
still  needs to find how many records were before this record.


Thanks,
Prasanna.