From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932126AbbBZMMN (ORCPT ); Thu, 26 Feb 2015 07:12:13 -0500 Received: from mail-qg0-f53.google.com ([209.85.192.53]:35403 "EHLO mail-qg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932075AbbBZMMK (ORCPT ); Thu, 26 Feb 2015 07:12:10 -0500 MIME-Version: 1.0 In-Reply-To: References: <1423778052-21038-1-git-send-email-dvlasenk@redhat.com> <1423778052-21038-2-git-send-email-dvlasenk@redhat.com> <54EE1799.2000602@redhat.com> <54EE3E94.7060208@redhat.com> From: Denys Vlasenko Date: Thu, 26 Feb 2015 13:11:48 +0100 Message-ID: Subject: Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete "struct pt_regs" To: Andy Lutomirski Cc: Denys Vlasenko , Andrey Wagin , Ingo Molnar , Linus Torvalds , Oleg Nesterov , Borislav Petkov , "H. Peter Anvin" , Frederic Weisbecker , X86 ML , Alexei Starovoitov , Will Drewry , Kees Cook , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 26, 2015 at 10:55 AM, Denys Vlasenko wrote: > On Wed, Feb 25, 2015 at 10:59 PM, Andy Lutomirski wrote: > In addition to my previous tests, I ran my home machine with > patched kernel. Unfortunately, it works for me :( > > Will try on yet another machine. And voila, it does happen on another machine :) I'm debugging it right now. Looks like 64-bit syscalls just stop working at some point in new processes. That is, existing process is alive and well, but children get SEGV after fork (most likely on any syscall64 they do, not after fork per se. They eventually manage to kill themselves - not trivial when exit syscall isn't working either - by tripping on HLT insn). 32-bit syscalls (int 80) continue to work. Fork, exec, whatever you want. I have static 32-bit busybox binary and everything works there. Also, any 64-bit process which was under strace continues to work correctly, including forks and execs. This points towards some bug on fast path sysret64 code. Looking for it.