Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4067136imu; Mon, 10 Dec 2018 12:31:32 -0800 (PST) X-Google-Smtp-Source: AFSGD/VpSMsI5r/rxuijmeSNBTlZnViOltdHA9ZB2crQNVYCK2D9LLkJhU1kkkOu6XUwwRtDRRqC X-Received: by 2002:a17:902:2904:: with SMTP id g4mr13371868plb.39.1544473892283; Mon, 10 Dec 2018 12:31:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544473892; cv=none; d=google.com; s=arc-20160816; b=EE3h+tDcKNw7zqJOknPOza3q+48q3PGuWVud1HpiYeWg1E12bR1gWoJqDOyWYUcOA7 jKkh6JEvbHi46EHwDeBTaNvIWQes/rGv69raqXruLHafdmqg+uwm16objbqfhnaxzajm Xgje3CsAnUWfy1IIwEGMVv1Xn/hH05/+oEuVIVOWggDYpFaTzULFOdnMlq4x7a0Gb95L yF2uVh1iXt98+vZ1w/2ECFtUCheOX6AXIhAIfP3JwHoP2T0SEonQ8aVnnSdU3SPvxX2t rVMCSzbzf4eNI3ou6DqtO0X93CIr8K/jixs3/ii+mhB0USSSTQCalqoBVxABTug2btvy rSwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=1alAhydYYYuTbmzH97NyL11PE/7toZc/Yv5lrQoj0po=; b=rm6xwZ0qoXI2P0+QQImS2ItNcBi+jsKQtJ1zxP3tav/ISsmQmYzMHJUDcD5PVk/j33 XJon/GnVQ/I+VbZAgsE4rNy+u7KewMTvjmL+hLj4aX+vHKXjtB9Cij6J98lQfftG0SIG C7LaTHqklfoTI2DxTq1PZEsosDi6O9wK1QWjKfBLBrwTqzUuER6XMPfiaZvXFqa+SVmK +S+uY3ffTixdOQtAji00ZiNCqUi/zMlHnjMhHH4bljT4wrOpIprSluG4Q/ZFF+kwPFYN +i5fYIuZ2Ody0zT2+d2Nk74stFFDcfB/iWxlAnS9pOHoQMbZRGHGlmAGU92hTf6qkBRh Qw+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=kCguRRkK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j14si10799217pgg.44.2018.12.10.12.31.16; Mon, 10 Dec 2018 12:31:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=kCguRRkK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728920AbeLJTid (ORCPT + 99 others); Mon, 10 Dec 2018 14:38:33 -0500 Received: from mail.kernel.org ([198.145.29.99]:51906 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728599AbeLJTid (ORCPT ); Mon, 10 Dec 2018 14:38:33 -0500 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 514CC20672 for ; Mon, 10 Dec 2018 19:38:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1544470711; bh=O15yZ5VkjaDOPI3ZTPBJ7BoKGzciiD4ftgdGZmJMeKA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kCguRRkKtTdZnVgGlbn8AK4mY1qWnLaIyA3yKT+YAnIdfq+OR8CM6Aq5TFZWAObVA vIajpIuaIyiUPHOeon6tQ3Jstc01AfTMxrq/4AGyfmUAUScQDvC/h2xpZxzlIJGnxf +JFwOs4R1vJlnssLHbi+KtUsWeuuXg1eKWapkUxk= Received: by mail-wm1-f43.google.com with SMTP id y139so12126945wmc.5 for ; Mon, 10 Dec 2018 11:38:31 -0800 (PST) X-Gm-Message-State: AA+aEWbH7gNQ6EPFJQaBZseNL3wj9jqNUCN0aQRBCVeB6a1rO7GS68M+ uXBQwbVLV5PeHyB+0iBWnCqD88NF8B9c2Kp/EkJp8w== X-Received: by 2002:a1c:aa0f:: with SMTP id t15mr11446080wme.108.1544470709792; Mon, 10 Dec 2018 11:38:29 -0800 (PST) MIME-Version: 1.0 References: <20181210043126.GX6131@altlinux.org> <201812102200.snodXJSH%fengguang.wu@intel.com> <20181210160940.GF14149@altlinux.org> In-Reply-To: <20181210160940.GF14149@altlinux.org> From: Andy Lutomirski Date: Mon, 10 Dec 2018 11:38:17 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 24/25] ptrace: add PTRACE_GET_SYSCALL_INFO request To: "Dmitry V. Levin" Cc: paul.burton@mips.com, Ralf Baechle , jhogan@kernel.org, Oleg Nesterov , Andrew Lutomirski , Elvira Khabirova , Eugene Syromiatnikov , Kees Cook , Jann Horn , Linux API , strace-devel@lists.strace.io, LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Dec 10, 2018, at 8:09 AM, Dmitry V. Levin wrote: > > Hi, things are getting too complicated and we need some advice how to deal > with this frame_pointer issue. > >> On Mon, Dec 10, 2018 at 10:26:50PM +0800, kbuild test robot wrote: >> Hi Elvira, >> >> Thank you for the patch! Yet something to improve: >> >> [auto build test ERROR on linus/master] >> [also build test ERROR on v4.20-rc6] >> [cannot apply to next-20181207] >> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] >> >> url: https://github.com/0day-ci/linux/commits/Dmitry-V-Levin/ptrace-add-PTRACE_GET_SYSCALL_INFO-request/20181210-174745 >> config: mips-malta_kvm_defconfig (attached as .config) >> compiler: mipsel-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 >> reproduce: >> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross >> chmod +x ~/bin/make.cross >> # save the attached .config to linux build tree >> GCC_VERSION=7.2.0 make.cross ARCH=mips >> >> All errors (new ones prefixed by >>): >> >> kernel/ptrace.c: In function 'ptrace_get_syscall_info': >>>> kernel/ptrace.c:942:20: error: implicit declaration of function 'frame_pointer'; did you mean 'trace_printk'? [-Werror=implicit-function-declaration] >> .frame_pointer = frame_pointer(regs) >> ^~~~~~~~~~~~~ >> trace_printk >> cc1: some warnings being treated as errors >> >> vim +942 kernel/ptrace.c >> >> 931 >> 932 static int >> 933 ptrace_get_syscall_info(struct task_struct *child, unsigned long user_size, >> 934 void __user *datavp) >> 935 { >> 936 struct pt_regs *regs = task_pt_regs(child); >> 937 struct ptrace_syscall_info info = { >> 938 .op = PTRACE_SYSCALL_INFO_NONE, >> 939 .arch = syscall_get_arch(child), >> 940 .instruction_pointer = instruction_pointer(regs), >> 941 .stack_pointer = user_stack_pointer(regs), >>> 942 .frame_pointer = frame_pointer(regs) >> 943 }; >> 944 unsigned long actual_size = offsetof(struct ptrace_syscall_info, entry); >> 945 unsigned long write_size; >> 946 >> 947 /* >> 948 * This does not need lock_task_sighand() to access >> 949 * child->last_siginfo because ptrace_freeze_traced() >> 950 * called earlier by ptrace_check_attach() ensures that >> 951 * the tracee cannot go away and clear its last_siginfo. >> 952 */ >> 953 switch (child->last_siginfo ? child->last_siginfo->si_code : 0) { >> 954 case SIGTRAP | 0x80: >> 955 switch (child->ptrace_message) { >> 956 case PTRACE_EVENTMSG_SYSCALL_ENTRY: >> 957 actual_size = ptrace_get_syscall_info_entry(child, regs, >> 958 &info); >> 959 break; >> 960 case PTRACE_EVENTMSG_SYSCALL_EXIT: >> 961 actual_size = ptrace_get_syscall_info_exit(child, regs, >> 962 &info); >> 963 break; >> 964 } >> 965 break; >> 966 case SIGTRAP | (PTRACE_EVENT_SECCOMP << 8): >> 967 actual_size = ptrace_get_syscall_info_seccomp(child, regs, >> 968 &info); >> 969 break; >> 970 } >> 971 >> 972 write_size = min(actual_size, user_size); >> 973 return copy_to_user(datavp, &info, write_size) ? -EFAULT : actual_size; >> 974 } >> 975 > > We decided to add .frame_pointer to struct ptrace_syscall_info just for > consistency with .instruction_pointer and .stack_pointer; I must have been > misled by comments in asm-generic/ptrace.h into thinking that > frame_pointer() is universally available across architectures. > > Unlike .instruction_pointer and .stack_pointer that are actually needed > in strace, .frame_pointer is not used, so from strace PoV we don't really > need it. > > So the question is, does anybody need a > struct ptrace_syscall_info.frame_pointer? > > If yes, how can frame_pointer() be defined on MIPS? > Or should we just forget about making sense of frame_pointer() and remove > struct ptrace_syscall_info.frame_pointer from the proposed API? > I would suggest getting rid of frame_pointer. Anyone who needs that degree of debugging can use existing ptrace APIs for it. > > -- > ldv