From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43A6E41C6E for ; Wed, 13 Mar 2024 14:37:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710340665; cv=none; b=Dar0sCi8cIUpVDazFUpXuMSVIGdIDJphYEZwXHttpWOSkzRfhe/4J7g+rx8FwreJuO8W6P3OgrHCBraPdKMXgiTxzmbfxefvqL0RgeOASeszqq9Rr9L3NK3AtbrC6ap7uguiWKtQa348u9ZmoGoth0LDtbKXRBCGKnVHuQYFB+M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710340665; c=relaxed/simple; bh=w13LjeuOVBT9HqLgtVGBsfGgD/+0VlKitvrUUb6ZGP8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=HZsekLiwuOyvQt25kdB9NDxexLHgHPK9Zh2H5f3M5axNMp9ESnjRQDpUU2ZOHNIekBDlWsXyivcKl1ctSmhvvRMw/yCCR+Jb8r5dbgIcJx1JNcOw9DqTxc4XiPChTrsZWYvc4Hq8fUrLG2lBro/g0ZZjsmFJ+xYYKpQCSKqhd+M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=kW8Cid6K; arc=none smtp.client-ip=209.85.214.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kW8Cid6K" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-1dd6dbcc622so16515845ad.1 for ; Wed, 13 Mar 2024 07:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710340663; x=1710945463; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=py1G0pjo/GR6nfb4eMjiczgTkldHsy3Ru8SiDoDLmVY=; b=kW8Cid6KPRXklUPlG4+9/xk4dOU52J/SvPRdoPqclRFdxYRc4G7cZkJreRo83blPGi 0e46k5XWgjYINkZQQRIES3CZS4Hxhi1FwNereRosQBszih48nTrUvIim59Ki6nLf+YXZ wHsll5UA62XUi/aof5UDO7WG4nTmfUDxH4tPDWcywBh57Pbo3StVNEGebp0ldeUgoB2U FrPB/T6KQMwtLawebaiPGDKvUvuQZQO6/clpVl6Ujdwo0ttlzBS+R2zzgI83JmzEIImM IGevu51usG3rjatOYeiPJXJMJuZxXQI9/w2tzLN7bYuOPI/JOq9EEbOd4hTcnbmi7jZv fIRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710340663; x=1710945463; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=py1G0pjo/GR6nfb4eMjiczgTkldHsy3Ru8SiDoDLmVY=; b=AZAblW2LMcEf8/oGz2y0sBZzZc/3IJCBSAsuJp+DjzQ+fCcyrpQapN4CgyYYAfHog7 EKgXZRV8eXdo/3azM63ON0+y9788BzZryvCtGgbuMyCPAqeZW2h7RXK0Mxddd+P+Bjeb /0//QXrjvKvz7xWS824+wnRh2+/nGWUTottOCmgHhW5Szq0bzBlKzXNKrMaEpKy13BLe zB5NB1HjGyU8mNWMUjT7nrPpF5aQ1FW+SNYlkTgDEHEtUc3FB3LbbPjje/me5c1lFNXN uiu1fDkomullW8rIs3W3RBO/eHRdAmCdLtaeC1WPkzx2zkfiCLV1cs05veeQ9MxnZNIK ngFw== X-Forwarded-Encrypted: i=1; AJvYcCV/yqI9p1dKXjKDgtoSksqXfqu8v9P2RjtLmIqzqp75xJZLkoGAU7bWgT5TLoZegihRcol3cBe3LYZpVEi2NnJ/Zdg/40SXtmaudBck17/QaQ== X-Gm-Message-State: AOJu0YxG3gF+I5JCX9pAopAlZR6OWwpNxBSXapoKRSzuBhz+6ty9MOKl BS4buoeYgbdEaE75Gr7BAxF4xJoD2KbH4jYx8SSq41EkGfs7XDhk X-Google-Smtp-Source: AGHT+IHMa8dVrA90OCm/zHzHqax4EcJuRTEPbui9ixJNJd+47mT1cnciZcl3SS/22R7VUlSGUDMWTg== X-Received: by 2002:a17:902:ec90:b0:1dd:da28:e5ca with SMTP id x16-20020a170902ec9000b001ddda28e5camr569070plg.0.1710340663336; Wed, 13 Mar 2024 07:37:43 -0700 (PDT) Received: from smtpclient.apple (os3-330-54943.vs.sakura.ne.jp. [49.212.189.197]) by smtp.gmail.com with ESMTPSA id q17-20020a170902dad100b001dd8360df9asm7990226plx.76.2024.03.13.07.37.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Mar 2024 07:37:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: [POC 5/5] x86_64: invoke SFrame based stack tracer for user space From: Tatsuyuki Ishi In-Reply-To: <20230502112720.0c0d011b@gandalf.local.home> Date: Wed, 13 Mar 2024 22:37:26 +0800 Cc: Peter Zijlstra , Indu Bhagat , linux-toolchains@vger.kernel.org, daandemeyer@meta.com, andrii@kernel.org, kris.van.hees@oracle.com, elena.zannoni@oracle.com, nick.alcock@oracle.com Content-Transfer-Encoding: quoted-printable Message-Id: <4CDF4EB4-C8AF-43DB-88AB-DB4BB76995F2@gmail.com> References: <20230501200410.3973453-1-indu.bhagat@oracle.com> <20230501200410.3973453-6-indu.bhagat@oracle.com> <20230502105353.GO1597476@hirez.programming.kicks-ass.net> <20230502112720.0c0d011b@gandalf.local.home> To: Steven Rostedt X-Mailer: Apple Mail (2.3774.500.171.1.1) > On May 2, 2023, at 23:27, Steven Rostedt wrote: >=20 > On Tue, 2 May 2023 12:53:53 +0200 > Peter Zijlstra wrote: >=20 >>> while (entry->nr < entry->max_stack) { >>> if (!valid_user_frame(fp, sizeof(frame))) >>> break; =20 >>=20 >> This is broken, the sframe stuff is not NMI safe. First you need to >> change perf to emit a forward reference to a 'next' user trace and = then >> emit the user trace on return-to-user. >>=20 >> As is, perf does everything in-place from NMI context. >=20 > Exactly. What I would like to see with the new sframe infrastructure = is > just a way to tell it "I want a user stack trace before going back to = user > space". Then all the work can be done in the ptrace path, where it's = safe > to memory map in the sframe section. It's not like the user space = stack > frame will change before going back to user space. >=20 Hi, just discovered this idea while looking for options to implement = in-kernel unwinding, and in our case, for Wine applications where = recompiling existing proprietary applications with frame pointers is not = feasible. I looked a bit more into how deferring work from NMI could work, but it = looks like this might not be easy for now. For normal IRQs, we can call = task_work_add and irqentry_exit will handle it for us. But task works = are not triggered for NMI, and that=E2=80=99s likely because unmasking = NMI requires IRET on x86, so if the NMI comes in during user mode, then = we need to forge a kernel IRET frame to do non-NMI work. Does the forging stuff sound feasible? Suggestions are also welcome. Tatsuyuki.