[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191203141239.GA30688@redhat.com>
Date: Tue, 3 Dec 2019 15:12:39 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...en8.de>,
Ingo Molnar <mingo@...nel.org>,
Jan Kratochvil <jan.kratochvil@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Pedro Alves <palves@...hat.com>, Peter Anvin <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org, x86@...nel.org
Subject: [PATCH v2 0/4] x86: fix get_nr_restart_syscall()
This version follows the latest recommendation from Linus,
arch_set_restart_data() just saves ti->status in restart->arch_data.
Andy, I can add another patch or change 4/4 to save the syscall number
instead, I am fine either way.
However, personally I dislike restart->arch_data, imo 3/4 is all we need.
I agree, set_restart_fn() is better than the ugly ERESTART_RESTARTBLOCK
check in syscall_return_slowpath() added by v1. But to me the x86-only
arch_data field in restart_block is much worse than the sticky TS_ flag.
To remind, there is another reason for the "transient" 3/4, 4/4 is not
easily backportable.
Oleg.
---
arch/x86/include/asm/processor.h | 9 ---------
arch/x86/include/asm/thread_info.h | 15 ++++++++++++++-
arch/x86/kernel/signal.c | 24 +-----------------------
fs/select.c | 10 ++++------
include/linux/restart_block.h | 1 +
include/linux/thread_info.h | 12 ++++++++++++
kernel/futex.c | 3 +--
kernel/time/alarmtimer.c | 2 +-
kernel/time/hrtimer.c | 2 +-
kernel/time/posix-cpu-timers.c | 2 +-
10 files changed, 36 insertions(+), 44 deletions(-)
Powered by blists - more mailing lists