From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754101AbcJPHBl (ORCPT ); Sun, 16 Oct 2016 03:01:41 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36148 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752167AbcJPHBf (ORCPT ); Sun, 16 Oct 2016 03:01:35 -0400 Date: Sun, 16 Oct 2016 09:01:30 +0200 From: Ingo Molnar To: Dmitry Vyukov Cc: Steven Rostedt , Ingo Molnar , Andrew Morton , LKML , Andrey Ryabinin , Eugene Surovegin , Mark Rutland , Catalin Marinas , Lorenzo Pieralisi , Alexander Potapenko , Will Deacon , Thomas Gleixner , "H. Peter Anvin" , Ananth N Mavinakayanahalli , Anil S Keshavamurthy , "David S. Miller" , Masami Hiramatsu , "x86@kernel.org" , kasan-dev Subject: Re: [PATCH v5] kprobes: unpoison stack in jprobe_return() for KASAN Message-ID: <20161016070130.GA2569@gmail.com> References: <1476454043-101898-1-git-send-email-dvyukov@google.com> <20161015063043.GA22225@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Dmitry Vyukov wrote: > On Sat, Oct 15, 2016 at 8:30 AM, Ingo Molnar wrote: > > > > * Dmitry Vyukov wrote: > > > >> KASAN stack instrumentation poisons stack redzones on function entry > >> and unpoisons them on function exit. If a function exits abnormally > >> (e.g. with a longjmp like jprobe_return()), stack redzones are left > >> poisoned. Later this leads to random KASAN false reports. > >> > >> Unpoison stack redzones in the frames we are going to jump over > >> before doing actual longjmp in jprobe_return(). > > > > Does this affect any other architecture besides arm64? If not then it might make > > the most sense to merge this via the arm64 tree. > > > This is mostly for x86_64. This patch fixes KASAN false positives > related to jprobe on x86_64. Indeed: I should have read the patch beyond the diffstat. > Arm64 related part is only a function rename. As I introduce a > function similar to an existing one, Mark asked to me rename the > existing function to clarify the difference between the two. Fair enough! Thanks, Ingo