From patchwork Fri Apr 9 20:27:32 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12195031 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F46AC43461 for ; Fri, 9 Apr 2021 20:27:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D29826113A for ; Fri, 9 Apr 2021 20:27:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D29826113A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 70BB26B007E; Fri, 9 Apr 2021 16:27:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E16F6B0080; Fri, 9 Apr 2021 16:27:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A8806B0081; Fri, 9 Apr 2021 16:27:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by kanga.kvack.org (Postfix) with ESMTP id 3D3796B007E for ; Fri, 9 Apr 2021 16:27:34 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 03217BBC1 for ; Fri, 9 Apr 2021 20:27:34 +0000 (UTC) X-FDA: 78013964028.01.81988EC Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf15.hostedemail.com (Postfix) with ESMTP id 8E1BBA000141 for ; Fri, 9 Apr 2021 20:27:32 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id B2A5D61108; Fri, 9 Apr 2021 20:27:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1618000053; bh=GyDd6shQy+0GGKIffU2lBkfQpFpuF6+LkS3D5mc8hjs=; h=Date:From:To:Subject:In-Reply-To:From; b=y36W/cVw4OkkykfTcG6K2EzZ7eeqXx4U1FQ4G1xVA4j12k9n7o5n0cFGTp9U9mVck onC49f16pwVz9NQcr267hGcwDhYINdu8vXRidW6SwTrM8RsPzdnljsxsu8fKFUDSGr /QLD0jKtYTuCPWmdxtMfRQZ74smPmWgomZTG62hY= Date: Fri, 09 Apr 2021 13:27:32 -0700 From: Andrew Morton To: akpm@linux-foundation.org, ldv@altlinux.org, linux-mm@kvack.org, mm-commits@vger.kernel.org, oleg@redhat.com, slyfox@gentoo.org, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 11/16] ia64: fix user_stack_pointer() for ptrace() Message-ID: <20210409202732.BFWhCou9S%akpm@linux-foundation.org> In-Reply-To: <20210409132633.6855fc8fea1b3905ea1bb4be@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 8E1BBA000141 X-Stat-Signature: kfshwbud5okhdmzuzzuqs1mzxw6yii68 Received-SPF: none (linux-foundation.org>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618000052-692397 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Sergei Trofimovich Subject: ia64: fix user_stack_pointer() for ptrace() ia64 has two stacks: - memory stack (or stack), pointed at by by r12 - register backing store (register stack), pointed at ar.bsp/ar.bspstore with complications around dirty register frame on CPU. In https://bugs.gentoo.org/769614 Dmitry noticed that PTRACE_GET_SYSCALL_INFO returns register stack instead memory stack. The bug comes from the fact that user_stack_pointer() and current_user_stack_pointer() don't return the same register: ulong user_stack_pointer(struct pt_regs *regs) { return regs->ar_bspstore; } #define current_user_stack_pointer() (current_pt_regs()->r12) The change gets both back in sync. I think ptrace(PTRACE_GET_SYSCALL_INFO) is the only affected user by this bug on ia64. The change fixes 'rt_sigreturn.gen.test' strace test where it was observed initially. Link: https://lkml.kernel.org/r/20210331084447.2561532-1-slyfox@gentoo.org Link: https://bugs.gentoo.org/769614 Signed-off-by: Sergei Trofimovich Reported-by: Dmitry V. Levin Cc: Oleg Nesterov Cc: Signed-off-by: Andrew Morton --- arch/ia64/include/asm/ptrace.h | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/arch/ia64/include/asm/ptrace.h~ia64-fix-user_stack_pointer-for-ptrace +++ a/arch/ia64/include/asm/ptrace.h @@ -54,8 +54,7 @@ static inline unsigned long user_stack_pointer(struct pt_regs *regs) { - /* FIXME: should this be bspstore + nr_dirty regs? */ - return regs->ar_bspstore; + return regs->r12; } static inline int is_syscall_success(struct pt_regs *regs) @@ -79,11 +78,6 @@ static inline long regs_return_value(str unsigned long __ip = instruction_pointer(regs); \ (__ip & ~3UL) + ((__ip & 3UL) << 2); \ }) -/* - * Why not default? Because user_stack_pointer() on ia64 gives register - * stack backing store instead... - */ -#define current_user_stack_pointer() (current_pt_regs()->r12) /* given a pointer to a task_struct, return the user's pt_regs */ # define task_pt_regs(t) (((struct pt_regs *) ((char *) (t) + IA64_STK_OFFSET)) - 1)