Hi Cyrill,
Programmers don't (and the manual-page says they shouldn't even try)
call "sigreturn" directly.
If an interrupt happens, by bad luck, to occur while the process
is running vdso code, then eventually, once signal-processing is
complete, "sigreturn" (issued by glibc) will take the
On Mon, Nov 26, 2012 at 11:55:01PM +1100, Amnon Shiloh wrote:
>
> You could of course keep that old code and modify only the very
> first instruction of each routine into a jump instruction, but then
> the code to which the process returns may not be compatible with
> the new kernel and/or
Hi Andrey,
So what do you do if a catched interrupt occured inside vdso code?
You can easily detect that the task is currently in vdso code,
then delay its dump, but how do you detect whether a sigreturn()
or even a series of sigreturn()s won't bring it back to the middle
of some old vdso code?
2012/11/26 Cyrill Gorcunov :
> On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
>> On 11/22, Amnon Shiloh wrote:
>> >
>> > Now however, that "vsyscall" was effectively replaced by vdso, it
>> > creates a new problem for me and probably for anyone else who uses
>> > some form of
On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
> On 11/22, Amnon Shiloh wrote:
> >
> > Now however, that "vsyscall" was effectively replaced by vdso, it
> > creates a new problem for me and probably for anyone else who uses
> > some form of checkpoint/restore:
>
> Oh, sorry, I
On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I can't help here.
2012/11/26 Cyrill Gorcunov gorcu...@openvz.org:
On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of
Hi Andrey,
So what do you do if a catched interrupt occured inside vdso code?
You can easily detect that the task is currently in vdso code,
then delay its dump, but how do you detect whether a sigreturn()
or even a series of sigreturn()s won't bring it back to the middle
of some old vdso code?
On Mon, Nov 26, 2012 at 11:55:01PM +1100, Amnon Shiloh wrote:
You could of course keep that old code and modify only the very
first instruction of each routine into a jump instruction, but then
the code to which the process returns may not be compatible with
the new kernel and/or hardware
Hi Cyrill,
Programmers don't (and the manual-page says they shouldn't even try)
call sigreturn directly.
If an interrupt happens, by bad luck, to occur while the process
is running vdso code, then eventually, once signal-processing is
complete, sigreturn (issued by glibc) will take the process
Hi Oleg,
> Amnon,
>
> I am going to "ignore" this thread because this is not my area and
> I can't help anyway. Just one note:
>
> On 11/23, Amnon Shiloh wrote:
> >
> > The solution can be to hold all catched signals while in the VDSO page.
> > ...
> >
> > 1) + introduce a kernel feature to
Hi Oleg,
Amnon,
I am going to ignore this thread because this is not my area and
I can't help anyway. Just one note:
On 11/23, Amnon Shiloh wrote:
The solution can be to hold all catched signals while in the VDSO page.
...
1) + introduce a kernel feature to prevent
catching
Amnon,
I am going to "ignore" this thread because this is not my area and
I can't help anyway. Just one note:
On 11/23, Amnon Shiloh wrote:
>
> The solution can be to hold all catched signals while in the VDSO page.
> ...
>
> 1) + introduce a kernel feature to prevent
>catching signals
On 11/23, Pavel Emelyanov wrote:
>
> On 11/22/2012 08:12 PM, Oleg Nesterov wrote:
>
> > Sure. You shouldn't try to save/restore this page(s) directly. But
> > I do not really understand why do you need. IOW, I don't really
> > understand the problem, it depends on what c/r actually does.
>
> Think
On 11/23, Pavel Emelyanov wrote:
On 11/22/2012 08:12 PM, Oleg Nesterov wrote:
Sure. You shouldn't try to save/restore this page(s) directly. But
I do not really understand why do you need. IOW, I don't really
understand the problem, it depends on what c/r actually does.
Think about it
Amnon,
I am going to ignore this thread because this is not my area and
I can't help anyway. Just one note:
On 11/23, Amnon Shiloh wrote:
The solution can be to hold all catched signals while in the VDSO page.
...
1) + introduce a kernel feature to prevent
catching signals within the
Hi Pavel,
> >>
> >> Now however, that "vsyscall" was effectively replaced by vdso, it
> >> creates a new problem for me and probably for anyone else who uses
> >> some form of checkpoint/restore:
> >
> > Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they
> > seem to enjoy trying
On 11/22/2012 08:12 PM, Oleg Nesterov wrote:
> On 11/22, Amnon Shiloh wrote:
>>
>> Now however, that "vsyscall" was effectively replaced by vdso, it
>> creates a new problem for me and probably for anyone else who uses
>> some form of checkpoint/restore:
>
> Oh, sorry, I can't help here. I can
On 11/22, Amnon Shiloh wrote:
>
> Now however, that "vsyscall" was effectively replaced by vdso, it
> creates a new problem for me and probably for anyone else who uses
> some form of checkpoint/restore:
Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they
seem to enjoy trying to
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they
seem to enjoy trying to solve
On 11/22/2012 08:12 PM, Oleg Nesterov wrote:
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I can't help here. I can only add Cyrill
Hi Pavel,
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they
seem to enjoy trying to solve the c/r
22 matches
Mail list logo
