[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXzGb+5sBNhoD+mC7mYGBiAmtzj=jMo7R=gdsThuPHPUg@mail.gmail.com>
Date: Wed, 18 Mar 2015 14:26:40 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Andrey Wagin <avagin@...il.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Andy Lutomirski <luto@...nel.org>,
Ingo Molnar <mingo@...nel.org>,
Andi Kleen <andi@...stfloor.org>,
"H. Peter Anvin" <hpa@...or.com>,
Al Viro <viro@...iv.linux.org.uk>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Borislav Petkov <bp@...en8.de>,
Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals
delivered to 64-bit programs
On Wed, Mar 18, 2015 at 1:02 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> On 03/18, Andrey Wagin wrote:
>>
>> This patch fixes the problem. Oleg, could you send this path in the
>> criu maillist?
>
> Sure, will do.
We still haven't answered one question: what's the kernel's position
on ABI stability wrt CRIU? We clearly shouldn't make changes that
break the principle of CRIU, but CRIU encodes so many tricky
assumptions about the inner workings of the kernel that it's really
tough to avoid breaking old CRIU versions.
So... do we introduce somewhat nasty code into the kernel to keep old
CRIU versions working, or do we require that users who want to restore
onto new kernels use new CRIU?
(It seems clear to me that CRIU should apply the patch regardless of
what the kernel does. It will enable CRIU to work on the same class
of programs that are fixed by the kernel change that started this
thread.)
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists