On 12/17/2012 10:56 AM, Pavel Emelyanov wrote:
> On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
>> Because it is almost impossible to do right?
>
> In the generic case -- I tend to agree. But it's possible to describe
> how a library should communicate to crtools to make it possible.
>
> Anyway,
On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
> Because it is almost impossible to do right?
In the generic case -- I tend to agree. But it's possible to describe
how a library should communicate to crtools to make it possible.
Anyway, what I wanted to say -- we didn't have this scenario in our
Because it is almost impossible to do right?
Pavel Emelyanov wrote:
>On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
>> On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin
>wrote:
>>> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> On Thu,
On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
> On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin wrote:
>> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
>>> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
> Wouldn't the vdso get
On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
Because it is almost impossible to do right?
In the generic case -- I tend to agree. But it's possible to describe
how a library should communicate to crtools to make it possible.
Anyway, what I wanted to say -- we didn't have this scenario in our
On 12/17/2012 10:56 AM, Pavel Emelyanov wrote:
On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
Because it is almost impossible to do right?
In the generic case -- I tend to agree. But it's possible to describe
how a library should communicate to crtools to make it possible.
Anyway, what I
On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin h...@zytor.com wrote:
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com wrote:
Wouldn't
Because it is almost impossible to do right?
Pavel Emelyanov xe...@parallels.com wrote:
On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin h...@zytor.com
wrote:
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski
On 12/14/2012 03:48 PM, John Stultz wrote:
> On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
>> On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
>>> On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
>>>
>>>
>>> This won't help in case of scenario you've been pointing in
>>> previous
On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
This won't help in case of scenario you've been pointing in
previous email (where c/r happens in a middle of vdso),
would it? Because we
On 12/14/2012 03:09 PM, Stefani Seibold wrote:
>
> Sorry for not following the discussion, but im am currently trying to
> compile the vclocktime.c as a 32 bit object. Most of the (clever) work
> is done.
>
> After this the next step is to map the needed fixmaps into the 32 bit
> address space.
Am Freitag, den 14.12.2012, 14:46 -0800 schrieb H. Peter Anvin:
> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> > On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> >> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
> >>> Wouldn't the vdso get mapped already and could be mremap()'d. If
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
> On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
>> On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
>>>
>>> this would allow us to defer checkpoint until task finish vdso code. Peter,
>>> if I understand you correctly you propose we
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
>>> Wouldn't the vdso get mapped already and could be mremap()'d. If we
>> really need more control I'd almost push for a device/filesystem
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
> On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
> >
> > this would allow us to defer checkpoint until task finish vdso code. Peter,
> > if I understand you correctly you propose we provide some own proxy-vdso
> > which would
On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
>
> this would allow us to defer checkpoint until task finish vdso code. Peter,
> if I understand you correctly you propose we provide some own proxy-vdso
> which would redirect calls to real ones, right? But the main problem
> is that is exactly the
On Fri, Dec 14, 2012 at 02:00:17PM -0800, H. Peter Anvin wrote:
> On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
> >
> > I don't know all that much about the linux vm. Can we create a
> > special vdso address_space or struct inode or something so that a
> > single vma can contain pages with
On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
>
> I don't know all that much about the linux vm. Can we create a
> special vdso address_space or struct inode or something so that a
> single vma can contain pages with different flags?
>
No, that is still different vmas, but it probably isn't a
On Fri, Dec 14, 2012 at 1:08 PM, H. Peter Anvin wrote:
> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>>> The real issue is that happens if the process is checkpointed while
>>> inside the vdso and now eip/rip or a stack frame points into the vdso.
>>> This is not impossible or even
On 12/14/2012 01:20 PM, Cyrill Gorcunov wrote:
> On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
>> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame
On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
> >>>
> >> The real issue is that happens if the process is checkpointed while
> >> inside the vdso and now eip/rip or a stack frame points into the vdso.
> >> This is not impossible or
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>>>
>> The real issue is that happens if the process is checkpointed while
>> inside the vdso and now eip/rip or a stack frame points into the vdso.
>> This is not impossible or even unlikely, especially on 32 bits it is
>> downright likely.
>
> I
On Fri, Dec 14, 2012 at 10:47:53AM -0800, H. Peter Anvin wrote:
> On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
> >>
> >> mremap() should work. At the same time, the code itself is not going to
> >> have any stability guarantees between kernel versions -- it obviously
> >> cannot.
> >
> > We
On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
>>
>> mremap() should work. At the same time, the code itself is not going to
>> have any stability guarantees between kernel versions -- it obviously
>> cannot.
>
> We could guarantee that the symbols in the vdso resolve to particular
> offsets
On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin wrote:
> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
>> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>>> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
Wouldn't the vdso get mapped already and could be mremap()'d. If we
>>>
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
>>> Wouldn't the vdso get mapped already and could be mremap()'d. If we
>> really need more control I'd almost push for a device/filesystem
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
>> Wouldn't the vdso get mapped already and could be mremap()'d. If we
> really need more control I'd almost push for a device/filesystem node
> that could be mmapped the usual way.
>
> Hmm.
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com wrote:
Wouldn't the vdso get mapped already and could be mremap()'d. If we
really need more control I'd almost push for a device/filesystem node
that could be mmapped the usual way.
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com wrote:
Wouldn't the vdso get mapped already and could be mremap()'d. If we
really need more control I'd almost push for a
On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin h...@zytor.com wrote:
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com wrote:
Wouldn't the vdso get mapped already and could be
On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
mremap() should work. At the same time, the code itself is not going to
have any stability guarantees between kernel versions -- it obviously
cannot.
We could guarantee that the symbols in the vdso resolve to particular
offsets within the
On Fri, Dec 14, 2012 at 10:47:53AM -0800, H. Peter Anvin wrote:
On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
mremap() should work. At the same time, the code itself is not going to
have any stability guarantees between kernel versions -- it obviously
cannot.
We could guarantee
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame points into the vdso.
This is not impossible or even unlikely, especially on 32 bits it is
downright likely.
I fear if there
On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame points into the vdso.
This is not impossible or even
On 12/14/2012 01:20 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame points into the
On Fri, Dec 14, 2012 at 1:08 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame points into the vdso.
This is not impossible or even
On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
I don't know all that much about the linux vm. Can we create a
special vdso address_space or struct inode or something so that a
single vma can contain pages with different flags?
No, that is still different vmas, but it probably isn't a big
On Fri, Dec 14, 2012 at 02:00:17PM -0800, H. Peter Anvin wrote:
On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
I don't know all that much about the linux vm. Can we create a
special vdso address_space or struct inode or something so that a
single vma can contain pages with different
On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
this would allow us to defer checkpoint until task finish vdso code. Peter,
if I understand you correctly you propose we provide some own proxy-vdso
which would redirect calls to real ones, right? But the main problem
is that is exactly the idea
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
this would allow us to defer checkpoint until task finish vdso code. Peter,
if I understand you correctly you propose we provide some own proxy-vdso
which would redirect calls
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com wrote:
Wouldn't the vdso get mapped already and could be mremap()'d. If we
really need more control I'd almost push for a
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
this would allow us to defer checkpoint until task finish vdso code. Peter,
if I understand you correctly you propose we provide some
Am Freitag, den 14.12.2012, 14:46 -0800 schrieb H. Peter Anvin:
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com wrote:
Wouldn't the vdso get mapped already and could be mremap()'d.
On 12/14/2012 03:09 PM, Stefani Seibold wrote:
Sorry for not following the discussion, but im am currently trying to
compile the vclocktime.c as a 32 bit object. Most of the (clever) work
is done.
After this the next step is to map the needed fixmaps into the 32 bit
address space. Maybe
On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
This won't help in case of scenario you've been pointing in
previous email (where c/r happens in a middle of vdso),
would it? Because we
On 12/14/2012 03:48 PM, John Stultz wrote:
On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
This won't help in case of scenario you've been pointing in
previous email (where c/r
46 matches
Mail list logo
