From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 224576A8D2; Mon, 21 Oct 2024 15:15:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729523744; cv=none; b=QMgPg1DLETwUtOj7lF7xkqdhCDihBlL81bntJkzLscoKEih1/p44fONu+XTQWEz7XL1k/7qIgMIzmjckCZI1wY792GLxnQCDsVm2g05EZFR+fwtOqgO/Tf21NIayuGPBVuc+ColHzteJECKKM8Sv+PHC/DHPLnefE1j29k/Ogsg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729523744; c=relaxed/simple; bh=3Ie81PJaB3Z2D/AicTp4yUNXRV46tqz0pVjMH/bKZBU=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=Dunf1B/pOdTRN1DOPbliJ02XjZDBUJ/sNJWYIU7Wbfr69MyHCzvZE3GqPfynXH5ezPLOTnHYnMWUCsSKx3vMhuJNucQCqtz16X8x3lg8ezNZ9w0GvXI2nIwY1tbcg5uTd2iMnjwQvYp63DvLZgFZYtiiNAZICRsTI50h9RWTDYo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O6hB2/iB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O6hB2/iB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93016C4CECD; Mon, 21 Oct 2024 15:15:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729523743; bh=3Ie81PJaB3Z2D/AicTp4yUNXRV46tqz0pVjMH/bKZBU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=O6hB2/iB4wLSkH+h4kqg9A82MI6C6IV/Jv5g90mM8cP4PlUevnewputwtJBeguYBB ltrz1sjQxRpcFOYGuHOL+ughjbvCW5qRRlIMGoY4EPHgHL1Qo8XZZIV1jlQuaY52rb p2NjWr0hYlHUeJinima3br77dEtuQysAuE4hhjcgNJWKraMq83QbOSNYYFcK+Es1D4 OuwPPrE5Dp0Y7rba+PMbIYfJRQ+I2XEfIgX8mwI+09jxh7MW62PR3NBhgnoDqRcAaL V1WlHRu/ywpY2YElacTzveP2eCaR6BS0b5dinhgMAnhkpRhkcGdqZei7LtAua/+j9p GZwVnrgH2NZrA== Date: Tue, 22 Oct 2024 00:15:34 +0900 From: Masami Hiramatsu (Google) To: Heiko Carstens Cc: Steven Rostedt , Sven Schnelle , "Masami Hiramatsu (Google)" , Alexei Starovoitov , Florent Revest , linux-trace-kernel@vger.kernel.org, LKML , Martin KaFai Lau , bpf , Alexei Starovoitov , Jiri Olsa , Alan Maguire , Mark Rutland , linux-arch@vger.kernel.org, Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Madhavan Srinivasan , Paul Walmsley , Palmer Dabbelt , Albert Ou , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Mathieu Desnoyers , Andrew Morton Subject: Re: [PATCH v17 11/16] fprobe: Rewrite fprobe on function-graph tracer Message-Id: <20241022001534.96c0d1813d8f4a26563d4663@kernel.org> In-Reply-To: <20241018124952.17670-E-hca@linux.ibm.com> References: <172904026427.36809.516716204730117800.stgit@devnote2> <172904040206.36809.2263909331707439743.stgit@devnote2> <20241016101022.185f741b@gandalf.local.home> <20241018124952.17670-E-hca@linux.ibm.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 18 Oct 2024 14:49:52 +0200 Heiko Carstens wrote: > On Wed, Oct 16, 2024 at 10:10:22AM -0400, Steven Rostedt wrote: > > On Wed, 16 Oct 2024 14:07:31 +0200 > > Sven Schnelle wrote: > > > I haven't yet fully understood why this logic is needed, but the > > > WARN_ON_ONCE triggers on s390. I'm assuming this fails because fp always > > > has the upper bits of the address set on x86 (and likely others). As an > > > example, in my test setup, fp is 0x8feec218 on s390, while it is > > > 0xffff888100add118 in x86-kvm. > > > > Since we only need to save 4 bits for size, we could have what it is > > replacing always be zero or always be f, depending on the arch. The > > question then is, is s390's 4 MSBs always zero? > > > > Thus we could make it be: > > > > static inline int decode_fprobe_header(unsigned long val, struct fprobe **fp) > > { > > unsigned long ptr; > > > > ptr = (val & FPROBE_HEADER_PTR_MASK) | FPROBE_HEADER_MSB_MASK; > > if (fp) > > *fp = (struct fprobe *)ptr; > > return val >> FPROBE_HEADER_PTR_BITS; > > } > > > > And define FPROBE_HEADER_MSB_MASK to be either: > > > > For most archs: > > > > #define FPROBE_HEADER_MSB_MASK (0xf << FPROBE_HEADER_PTR_BITS) > > > > or on s390: > > > > #define FPROBE_HEADER_MSB_MASK (0x0) > > > > Would this work? > > This would work for s390. Right now we don't make any use of the four > MSBs, and they are always zero. If for some reason this would ever > change, we would need to come up with a different solution. Ah, so fill with zero works for s390 kernel. Thanks for the info. > Please note that this only works for addresses in the kernel address > space. For user space the full 64 bit address range (minus the top > page) can be used for user space applications. I wonder what is the unsigned long size (stack entry size) of the s390? is it 64bit? > I'm just writing this > here, just in case something like this comes up for uprobes or > something similar as well. I'm considering another solution if it doesn't work. Of course if above works, it is the best compression ratio. This is only if it doesn't work, we can consolidate a set of fprobe header in N + 1 entries as 0: [# of fprobes(4bit)|4bit array of sizes] 1: [fp 1] 2: [fp 1 data] ... So if we have 3 fprobes on the same entry and has 0, 3, 2 data size, then 0:[3|0|3|2|0...0] 1:[fp1] 2:[fp2] 3:[fp2 data 1] 4:[fp2 data 2] 5:[fp2 data 3] 6:[fp3] 7:[fp3 data 1] 8:[fp3 data 2] Thank you, -- Masami Hiramatsu (Google)