Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1471668 > unrolled thread

Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping Andy Lutomirski <luto@amacapital.net> - 2016-08-29 11:30 +0200
    Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping Andy Lutomirski <luto@amacapital.net> - 2016-08-30 17:00 +0200
    Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping Al Viro <viro@ZenIV.linux.org.uk> - 2016-09-03 02:10 +0200

#1471668 — Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

On Thu, Aug 25, 2016 at 8:21 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
> I added here a new in-kernel fs with ramfs-like options.
> Created vdso file in this fs (yet for testing, only 64-bit vdso).
> Mapped this file to process's mm on setup_additional_pages.
> Just for testing purpose it's done only for specific UID.

I'm wondering whether all this code could be easily moved into the
core special mapping helpers so that all special mappings get the same
benefit.  We could embed a struct file * (or struct inode or whatever)
in special_mapping if needed.

Also, could this be simplified to use anon_inode?

(I'm not a VFS expert at all, so I could be way off base.)

[toc] | [next] | [standalone]

#1472531

On Mon, Aug 29, 2016 at 2:50 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
> On 08/29/2016 12:28 PM, Andy Lutomirski wrote:
>>
>> On Thu, Aug 25, 2016 at 8:21 AM, Dmitry Safonov <dsafonov@virtuozzo.com>
>> wrote:
>>>
>>> I added here a new in-kernel fs with ramfs-like options.
>>> Created vdso file in this fs (yet for testing, only 64-bit vdso).
>>> Mapped this file to process's mm on setup_additional_pages.
>>> Just for testing purpose it's done only for specific UID.
>>
>>
>> I'm wondering whether all this code could be easily moved into the
>> core special mapping helpers so that all special mappings get the same
>> benefit.  We could embed a struct file * (or struct inode or whatever)
>> in special_mapping if needed.
>
>
> Hmm, yes, I guess. The only thing -- we'll still need per-arch changes
> to initialize those files on booting. But that looks like the proper
> generic place to move this code.

You might be able to get away with initializing on first use.

--Andy

[toc] | [prev] | [next] | [standalone]

#1475504

On Mon, Aug 29, 2016 at 02:28:08AM -0700, Andy Lutomirski wrote:
> On Thu, Aug 25, 2016 at 8:21 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
> > I added here a new in-kernel fs with ramfs-like options.
> > Created vdso file in this fs (yet for testing, only 64-bit vdso).
> > Mapped this file to process's mm on setup_additional_pages.
> > Just for testing purpose it's done only for specific UID.
> 
> I'm wondering whether all this code could be easily moved into the
> core special mapping helpers so that all special mappings get the same
> benefit.  We could embed a struct file * (or struct inode or whatever)
> in special_mapping if needed.
> 
> Also, could this be simplified to use anon_inode?

Please, don't.  anon_inode is for situations when you don't mind sharing
the _same_ inode for different things.  This one very clearly isn't that.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web