On Fri, Sep 19, 2014 at 12:27 PM, Andy Lutomirski wrote:
> On Wed, Sep 17, 2014 at 7:28 AM, Andy Lutomirski wrote:
>> On Sep 17, 2014 1:46 AM, "H. Peter Anvin" wrote:
>>>
>>> On 09/16/2014 11:21 PM, Filipe Brandenburger wrote:
>>> > Hi Andy,
>>> >
>>> > On Tue, Sep 16, 2014 at 10:00 PM, Andy
On Fri, Sep 19, 2014 at 12:27 PM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Sep 17, 2014 at 7:28 AM, Andy Lutomirski l...@amacapital.net wrote:
On Sep 17, 2014 1:46 AM, H. Peter Anvin h...@zytor.com wrote:
On 09/16/2014 11:21 PM, Filipe Brandenburger wrote:
Hi Andy,
On Tue, Sep
On Tue, Sep 16, 2014 at 5:27 PM, Andy Lutomirski wrote:
> On Tue, Sep 16, 2014 at 5:05 PM, Richard Larocque
> wrote:
>> Adds new prctl calls to enable or disable VDSO loading for a process
>> and its children.
>>
>> The PR_SET_DISABLE_VDSO call takes one
On Tue, Sep 16, 2014 at 5:13 PM, Andi Kleen wrote:
> Richard Larocque writes:
>
> Perhaps I'm missing something, but how do you modify the AUX vector
> for the children?
>
>> +config VDSO_DISABLE_PRCTL
>> + depends on X86
>> + bool "prctl to
. This feature is available only on x86.
The command line option vdso=0 overrides the behavior of
PR_SET_DISABLE_VDSO, however, PR_GET_DISABLE_VDSO will coninue to return
whetever setting was last set with PR_SET_DISABLE_VDSO.
Signed-off-by: Richard Larocque
---
This patch is part of some work
. This feature is available only on x86.
The command line option vdso=0 overrides the behavior of
PR_SET_DISABLE_VDSO, however, PR_GET_DISABLE_VDSO will coninue to return
whetever setting was last set with PR_SET_DISABLE_VDSO.
Signed-off-by: Richard Larocque rlaroc...@google.com
---
This patch is part
On Tue, Sep 16, 2014 at 5:13 PM, Andi Kleen a...@firstfloor.org wrote:
Richard Larocque rlaroc...@google.com writes:
Perhaps I'm missing something, but how do you modify the AUX vector
for the children?
+config VDSO_DISABLE_PRCTL
+ depends on X86
+ bool prctl to disable VDSO
On Tue, Sep 16, 2014 at 5:27 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Sep 16, 2014 at 5:05 PM, Richard Larocque rlaroc...@google.com
wrote:
Adds new prctl calls to enable or disable VDSO loading for a process
and its children.
The PR_SET_DISABLE_VDSO call takes one argument
On Tue, Sep 9, 2014 at 8:33 PM, John Stultz wrote:
> On Tue, Sep 9, 2014 at 6:31 PM, Richard Larocque wrote:
>> I've been working on some changes to posix-timers.c in an attempt to better
>> support CRIU. Along the way, I've discovered some issues with the posix
>> alarm
On Tue, Sep 9, 2014 at 8:33 PM, John Stultz john.stu...@linaro.org wrote:
On Tue, Sep 9, 2014 at 6:31 PM, Richard Larocque rlaroc...@google.com wrote:
I've been working on some changes to posix-timers.c in an attempt to better
support CRIU. Along the way, I've discovered some issues
they
ought to grab the lock somewhere else.
Signed-off-by: Richard Larocque
---
I'm not at all sure this makes sense. Feel free to drop this patch if the
extra locking is wrong or unnecessary. It's here for discussion purposes only.
It's not entirely clear to me what the it_lock is supposed to protect
is skipped when SIGEV_NONE was
specified, so the signal number could be bogus. If sigev_signo was an
unitialized value (as it often would be if SIGEV_NONE is used), then
it's hard to predict which signal will be sent.
Signed-off-by: Richard Larocque
---
kernel/time/alarmtimer.c | 6 --
1 file
.
This is a change in user-visible behavior, and may break existing
applications. Hopefully, few users rely on the old incorrect behavior.
Signed-off-by: Richard Larocque
---
kernel/time/alarmtimer.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/kernel
not quite related to the first two, but it does conflict with one of them,
so I figured I should include it in this patch stack.
PS: This is my first upstream patch, so please excuse any etiquette violations.
Richard Larocque (3):
alarmtimer: Return relative times in timer_gettime
alar
related to the first two, but it does conflict with one of them,
so I figured I should include it in this patch stack.
PS: This is my first upstream patch, so please excuse any etiquette violations.
Richard Larocque (3):
alarmtimer: Return relative times in timer_gettime
alarmtimer: Do not signal
they
ought to grab the lock somewhere else.
Signed-off-by: Richard Larocque rlaroc...@google.com
---
I'm not at all sure this makes sense. Feel free to drop this patch if the
extra locking is wrong or unnecessary. It's here for discussion purposes only.
It's not entirely clear to me what the it_lock
is skipped when SIGEV_NONE was
specified, so the signal number could be bogus. If sigev_signo was an
unitialized value (as it often would be if SIGEV_NONE is used), then
it's hard to predict which signal will be sent.
Signed-off-by: Richard Larocque rlaroc...@google.com
---
kernel/time/alarmtimer.c | 6
.
This is a change in user-visible behavior, and may break existing
applications. Hopefully, few users rely on the old incorrect behavior.
Signed-off-by: Richard Larocque rlaroc...@google.com
---
kernel/time/alarmtimer.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions
18 matches
Mail list logo
