linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>, X86 ML <x86@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sasha Levin <sasha.levin@oracle.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Dave Jones <davej@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [PATCH 3/4] x86,mm: Improve _install_special_mapping and fix x86 vdso naming
Date: Tue, 20 May 2014 11:38:52 -0700	[thread overview]
Message-ID: <CALCETrVbdWSxgSjNnmqjtDLYKpiah09VUGA56_abrPwUC6q=mA@mail.gmail.com> (raw)
In-Reply-To: <537B9EA6.3030103@zytor.com>

On Tue, May 20, 2014 at 11:27 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/20/2014 11:24 AM, Andy Lutomirski wrote:
>> On Tue, May 20, 2014 at 11:18 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 05/20/2014 11:01 AM, Cyrill Gorcunov wrote:
>>>>>
>>>>> This patch should fix this issue, at least.  If there's still a way to
>>>>> get a native vdso that doesn't say "[vdso]", please let me know/
>>>>
>>>> Yes, having a native procfs way to detect vdso is much preferred!
>>>>
>>>
>>> Is there any path by which we can end up with [vdso] without a leading
>>> slash in /proc/self/maps?  Otherwise, why is that not "native"?
>>
>> Dunno.  But before this patch the reverse was possible: we can end up
>> with a vdso that doesn't say [vdso].
>>
>
> That's a bug, which is being fixed.  We can't go back in time and create
> new interfaces on old kernels.
>
>>>
>>>>>>   The situation get worse when task was dumped on one kernel and
>>>>>> then restored on another kernel where vdso content is different
>>>>>> from one save in image -- is such case as I mentioned we need
>>>>>> that named vdso proxy which redirect calls to vdso of the system
>>>>>> where task is restoring. And when such "restored" task get checkpointed
>>>>>> second time we don't dump new living vdso but save only old vdso
>>>>>> proxy on disk (detecting it is a different story, in short we
>>>>>> inject a unique mark into elf header).
>>>>>
>>>>> Yuck.  But I don't know whether the kernel can help much here.
>>>>
>>>> Some prctl which would tell kernel to put vdso at specifed address.
>>>> We can live without it for now so not a big deal (yet ;)
>>>
>>> mremap() will do this for you.
>>
>> Except that it's buggy: it doesn't change mm->context.vdso.  For
>> 64-bit tasks, the only consumer outside exec was arch_vma_name, and
>> this patch removes even that.  For 32-bit tasks, though, it's needed
>> for signal delivery.
>>
>
> Again, a bug, let's fix it rather than saying we need a new interface.

What happens if someone remaps just part of the vdso?

Presumably we'd just track the position of the first page of the vdso,
but this might be hard to implement: I don't think there's any
callback from the core mm code for ths.

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-05-20 18:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-19 22:58 [PATCH 0/4] x86,mm: vdso fixes for an OOPS and /proc/PID/maps Andy Lutomirski
2014-05-19 22:58 ` [PATCH 1/4] x86,vdso: Fix an OOPS accessing the hpet mapping w/o an hpet Andy Lutomirski
2014-05-19 22:58 ` [PATCH 2/4] mm,fs: Add vm_ops->name as an alternative to arch_vma_name Andy Lutomirski
2014-05-19 22:58 ` [PATCH 3/4] x86,mm: Improve _install_special_mapping and fix x86 vdso naming Andy Lutomirski
2014-05-20 17:21   ` Cyrill Gorcunov
2014-05-20 17:24     ` Andy Lutomirski
2014-05-20 17:47       ` Cyrill Gorcunov
2014-05-20 17:52         ` Andy Lutomirski
2014-05-20 18:01           ` Cyrill Gorcunov
2014-05-20 18:18             ` H. Peter Anvin
2014-05-20 18:24               ` Andy Lutomirski
2014-05-20 18:27                 ` H. Peter Anvin
2014-05-20 18:38                   ` Andy Lutomirski [this message]
2014-05-20 18:39                 ` Cyrill Gorcunov
2014-05-20 18:37   ` H. Peter Anvin
2014-05-19 22:58 ` [PATCH 4/4] x86,mm: Replace arch_vma_name with vm_ops->name for vsyscalls 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='CALCETrVbdWSxgSjNnmqjtDLYKpiah09VUGA56_abrPwUC6q=mA@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sasha.levin@oracle.com \
    --cc=x86@kernel.org \
    --cc=xemul@parallels.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).