Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1987038pxb; Fri, 29 Jan 2021 10:00:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJzGQMIWXulCn8S0CErhkoJc6aGFSYvHjyLDJekNTAhGxDNxFobEhpMssEwjWPvbnYNc9hAi X-Received: by 2002:a2e:9d96:: with SMTP id c22mr3050240ljj.109.1611943255391; Fri, 29 Jan 2021 10:00:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611943255; cv=none; d=google.com; s=arc-20160816; b=EY3oM91nTzEgVAuKhc2sTfoK+tPHeqWx42O4+QumQj7QQCOR+aRc5MX6iciZ9WIJ6l wSAh6kFSnw6vifQ4LASipone7Hr2VH8K8FKoRHPNA10Y5B1pXrunoOflbBp4FeT2uUBb AfiqjUn80v/VG3P+XG9Fz5h9ofrDabVci/SOCLytMqMAn7+8WC6laEzHWaYs5tqF3n2d tersvFAkqdMpmEAgWydZL2Zi+cQdPfVtEL8hXHAYiqaOoyHXQHaer9v+FktiXVb4M8km R+kHu6srbTzcLtWeqpAFpqm2S/1o46gk4rKyEP6Cqpe2hQ4rAzklLKKwijHuWQSZlrXv v+UQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=2+rY0D6G4rokJpdcd7Xvg6RaLf7nDP1XYOtHE3OlDW8=; b=0BezLeB3/xqCMYjTGsTyaFHwwe2KfKEn7T8BBvFVhRXow6gIo2XzA9ARNZGBkf0H7y dJ6ccM4td2T0iTvoXub4pDSMq6aTNFeCHUwRzX8/V8gHnfDKudg6s6dfbB9VO7egdHoO 8qXUiaZhcF0N3N6YD8Tbo47X594iSUdm+FKJ3Bnke47FRgDltiKJIWdjkKvQrpQhk9VJ DRPCo8AK58IbkbDpT+hjMgjopBxMdn871Btk4Qm5o42jvYPQQnh5cfgQSbnl2GLnZ7oE vVN+xdXfevwQMqSoYVdNHcyRasSfcPkIpQX/zaRuQWG7UuEJUqkUPNb0yB4+J+UbVZAY YOAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qfSLujWQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id j17si5183953ejt.189.2021.01.29.10.00.29; Fri, 29 Jan 2021 10:00:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qfSLujWQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S232498AbhA2R6u (ORCPT + 99 others); Fri, 29 Jan 2021 12:58:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:41974 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229683AbhA2R6t (ORCPT ); Fri, 29 Jan 2021 12:58:49 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id BBFAF64E07; Fri, 29 Jan 2021 17:58:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611943088; bh=O1kMHmCIAMtpNgKBwX1ZGNj9omrf1C81ck/T7oQqjZg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qfSLujWQ06P9+v81FqjHGaSx7Lt7wkwNrnymvUjYdQ3t4Vd6ii1yJuCZbuoL2W5Qb H4GdTTsCVbf6ZFyPbSJXrYPD8yFGmj6xL07YaU1O2HypX8VSgEq7E8Dd7wqL6mSZ/m TjVDuLEzlAoJswCMpCK/yqd0xYau+l5z+9zjOdcv76+FNXpM2rDD+AiWsQSG8nKlWr ugtbffZtfkuLQGhZH+ebGd+BdvNKJvKd8Lo6wdmm3sx6pTSRbea7ZplNyO3fAKlwmT eJolwE8Wa2KLMeh5eC3yRs9VPaRkTyGfky3F/bFoqnu0SGLaCXULbVoiDOlM96GCYS OFAENuEc6S7GA== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 8DF4540513; Fri, 29 Jan 2021 14:58:05 -0300 (-03) Date: Fri, 29 Jan 2021 14:58:05 -0300 From: Arnaldo Carvalho de Melo To: Thomas Bogendoerfer Cc: Peter Zijlstra , Jiaxun Yang , Tiezhu Yang , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, Xuefeng Li , David Daney , Ralf Baechle , Archer Yan , x86@kernel.org Subject: Re: [PATCH 1/3] MIPS: kernel: Support extracting off-line stack traces from user-space with perf Message-ID: <20210129175805.GD794568@kernel.org> References: <1609246561-5474-1-git-send-email-yangtiezhu@loongson.cn> <1609246561-5474-2-git-send-email-yangtiezhu@loongson.cn> <20210104105904.GK3021@hirez.programming.kicks-ass.net> <0712b131-715a-a83a-bc9e-61405824ff0e@flygoat.com> <20210105101806.GG3040@hirez.programming.kicks-ass.net> <20210127211506.GA21163@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210127211506.GA21163@alpha.franken.de> X-Url: http://acmel.wordpress.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Wed, Jan 27, 2021 at 10:15:06PM +0100, Thomas Bogendoerfer escreveu: > On Tue, Jan 05, 2021 at 11:18:06AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 05, 2021 at 11:45:37AM +0800, Jiaxun Yang wrote: > > > 在 2021/1/4 下午6:59, Peter Zijlstra 写道: > > > > On Tue, Dec 29, 2020 at 08:55:59PM +0800, Tiezhu Yang wrote: > > > > > +u64 perf_reg_abi(struct task_struct *tsk) > > > > > +{ > > > > > + if (test_tsk_thread_flag(tsk, TIF_32BIT_REGS)) > > > > > + return PERF_SAMPLE_REGS_ABI_32; > > > > > + else > > > > > + return PERF_SAMPLE_REGS_ABI_64; > > > > > +} > > > > So we recently changed this on x86 to not rely on TIF flags. IIRC the > > > > problem is that on x86 you can change the mode of a task without the > > > > kernel being aware of it. Is something like that possible on MIPS as > > > > well? > > > > > > Hi all, > > > > > > In MIPS world it's impossible to raise a thread to 64bit without kernel > > > aware. > > > Without STATUS.UX set it will trigger reserved instruction exception when > > > trying > > > to run 64bit instructions. > > > > The other way around is the case on x86, a 64bit program can create and > > execute 32bit code sections without the kernel being aware. But if > > clearing STATUS.UX has the same issue as setting it, that should not be > > a problem for you. > > > > > However it may be possible to run with 32bit ABI without > > > TIF_32BIT_REGS if user program didn't get ELF ABI right. I think > > > that's out of our current consideration. > > > > Fair enough. > > > > > > The thing x86 does today is look at it's pt_regs state to determine the > > > > actual state. > > > It is possible to look at pt_regs Status.UX bit on MIPS. But it seems > > > unnecessary > > > as user can't change it. > > > > Ok, good. Then no objection, proceed! :-) > > this patch aims more to mips-next, while patch 2 and 3 are targeting > tools/perf. Should I take them into mips-next, too ? I'll process the tools/perf ones, if you took the time to actually review them, please say so and I'll add a Reviewed-by tag stating that. I've replied to another message in this thread with reasoning about the value of processing kernel bits in the relevant arch tree while the tooling one via my perf/core branch. - Arnaldo