All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Dmitry Safonov <0x7f454c46@gmail.com>,
	Dmitry Safonov <dsafonov@virtuozzo.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs)
Date: Tue, 20 Sep 2016 18:07:21 -0700	[thread overview]
Message-ID: <6de39359-511e-1ce9-9201-85bd3425a05d@zytor.com> (raw)
In-Reply-To: <CALCETrVGouJVpCNdioDGt551twHpcZEqvr-GiMrEW1=FozA7VQ@mail.gmail.com>

On 09/20/16 17:54, Andy Lutomirski wrote:
>  - If vvar is in the same inode, then that inode won't be a valid ELF
> image, because the ELF header won't be in the right place.

So the vvar ought to move into an actual ELF segment, which is probably
The Right Thing anyway.

>  - vvar is highly magical.  IMO letting it get mapped with VM_MAYWRITE
> is asking for trouble, as anything that writes it will COW it, leading
> to strange malfunctions.
> 
>  - vvar can, and has, had IO pages in it.  This means that the actual
> cache types can vary page-to-page in the vvar area, which is not
> something that ordinary files do.

Neither of these are any different than many devices, or various files
in procfs.

> My personal preference is to let them both be real struct file *
> objects (possibly shared between all processes of the same vdso ABI)
> but to prevent user code from ever creating an fd referring to one of
> these files.

Why?  It would help people doing weird things like process snapshotting
or bimodal execution enormously.  We want to share an inode, obviously;
the pointer is another issue.

> Also, if we let the users get an fd pointing to the vdso, then we're
> more or less committing to never having contents in the vdso text that
> vary per-process.  Are we okay with that.

This might be a reason to put these objects in procfs rather than sysfs,
but I have to admit that this seems *extremely* far fetched to me.
Obviously they vary per process in the sense that there are already
several to choose from.  In the case of process-unique vdsos there would
be a large number of them, of course.

	-hpa

  reply	other threads:[~2016-09-21  1:07 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-25 15:21 [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs) Dmitry Safonov
2016-08-25 15:21 ` [RFC 1/3] x86/vdso: create vdso file, use it for mapping Dmitry Safonov
2016-08-25 19:49   ` Dmitry Safonov
2016-08-25 20:05     ` Dmitry Safonov
2016-08-28 20:14   ` Cyrill Gorcunov
2016-08-29  9:18     ` Dmitry Safonov
2016-08-29  9:28   ` Andy Lutomirski
2016-08-29  9:50     ` Dmitry Safonov
2016-08-30 14:58       ` Andy Lutomirski
2016-09-03  0:08     ` Al Viro
2016-08-30 14:33   ` Oleg Nesterov
2016-08-30 14:53     ` Dmitry Safonov
2016-09-03  0:13     ` Al Viro
2016-09-03  0:20   ` Al Viro
2016-09-03  7:32     ` Dmitry Safonov
2016-08-25 15:21 ` [RFC 2/3] uprobe: drop isdigit() check in create_trace_uprobe Dmitry Safonov
2016-08-29 22:58   ` Steven Rostedt
2016-08-29 22:59     ` Steven Rostedt
2016-08-29 23:01       ` Dmitry Safonov
2016-08-30 14:37       ` Oleg Nesterov
2016-08-30 21:15         ` Steven Rostedt
2016-08-31 12:07           ` Oleg Nesterov
2016-08-30 14:57     ` Srikar Dronamraju
2016-08-25 15:21 ` [RFC 3/3] uprobe: add vdso support Dmitry Safonov
2016-08-25 20:49 ` [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs) H. Peter Anvin
2016-08-25 22:53   ` Dmitry Safonov
2016-08-25 23:00     ` H. Peter Anvin
2016-08-26 11:16       ` Dmitry Safonov
2016-08-26 14:32         ` Andy Lutomirski
2016-08-26 14:42           ` Dmitry Safonov
2016-08-26 14:44             ` Dmitry Safonov
2016-09-21  0:22     ` H. Peter Anvin
2016-09-21  0:32       ` H. Peter Anvin
2016-09-21  0:54         ` Andy Lutomirski
2016-09-21  1:07           ` H. Peter Anvin [this message]
2016-09-21  1:17             ` H. Peter Anvin
2016-09-21  6:39               ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6de39359-511e-1ce9-9201-85bd3425a05d@zytor.com \
    --to=hpa@zytor.com \
    --cc=0x7f454c46@gmail.com \
    --cc=dsafonov@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.