From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D38CC433EF for ; Mon, 31 Jan 2022 14:28:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235995AbiAaO2R (ORCPT ); Mon, 31 Jan 2022 09:28:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235914AbiAaO2R (ORCPT ); Mon, 31 Jan 2022 09:28:17 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 220A5C06173D; Mon, 31 Jan 2022 06:28:17 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 145FAB82A59; Mon, 31 Jan 2022 14:28:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFA86C340EE; Mon, 31 Jan 2022 14:28:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643639293; bh=kfrJnOWubtdfm2g34bwjILcCqrYytFdSVBRfPr7yUeo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E2McGu4C0bL0QtV9F/Jot/YKHUVSwMZCClcHCeHDl56FGPaJhby6eSBTZSV4sFn+0 OHfN/IxiZFZWzVSBRT8Pf1hYg+9edwSkQ7oK7dcxMyVmDU6ZPRANeWCk235SBW37cx iyjsehsNJJiAxKHEx55YlCc3qxZzSKg5xIZ7PnxAeCH9ZzYD+l5VAeARbwead3+2ky xIogem6BkN3rrl1YitxCimj/9Us15H7zFD65oq0sCJVo+CITzYbYXKcakX8fPkgapo ltTcpNP/GYUe2UUleJvicESPeQmtj32MZzu8XcpMaNjHiH09d5HTn+ppxUuWB4pGX5 fezXWEGYUs5xA== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 1B13A40466; Mon, 31 Jan 2022 11:28:11 -0300 (-03) Date: Mon, 31 Jan 2022 11:28:11 -0300 From: Arnaldo Carvalho de Melo To: Masami Hiramatsu Cc: Ian Rogers , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Thomas Gleixner , Darren Hart , Davidlohr Bueso , =?iso-8859-1?Q?Andr=E9?= Almeida , James Clark , John Garry , Riccardo Mancini , Yury Norov , Andy Shevchenko , Andrew Morton , Jin Yao , Adrian Hunter , Leo Yan , Andi Kleen , Thomas Richter , Kan Liang , Madhavan Srinivasan , Shunsuke Nakamura , Song Liu , Steven Rostedt , Miaoqian Lin , Stephen Brennan , Kajol Jain , Alexey Bayduraev , German Gomez , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Dumazet , Dmitry Vyukov , masami.hiramatsu.pt@hitachi.com, eranian@google.com Subject: Re: [PATCH v2 0/4] Reference count checker and related fixes Message-ID: References: <20220125204602.4137477-1-irogers@google.com> <20220128142348.17d51894dbdb35c9a9449567@kernel.org> <20220129003450.77116209763f7e06d285e654@kernel.org> <20220130170418.40d812169bcae1323f8b20bf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220130170418.40d812169bcae1323f8b20bf@kernel.org> X-Url: http://acmel.wordpress.com Precedence: bulk List-ID: X-Mailing-List: linux-perf-users@vger.kernel.org Em Sun, Jan 30, 2022 at 05:04:18PM +0900, Masami Hiramatsu escreveu: > On Fri, 28 Jan 2022 16:59:13 -0300 Arnaldo Carvalho de Melo wrote: > > I went back to that discussion and saw this part where I brainstormed > > about doing all this in unmodified binaries: > > https://lore.kernel.org/all/20151209134138.GB15864@kernel.org/ > > Even Alexei chimed in and replied to that thinking it was doable: > > https://lore.kernel.org/all/20151210033139.GA10056@ast-mbp.thefacebook.com/#t > > And nowadays we have much better BPF infrastructure, much faster probes, > > etc. > Yeah I think now we (will) have faster user-event[1] too. :) > [1] https://lore.kernel.org/all/20220118204326.2169-1-beaub@linux.microsoft.com/T/#u > So instead of allocating an indirect object on get(), we also can define > an event and send it to the kernel, and run a BPF to analyze it. > Note that this will *NOT* be able to detect the "use-after-put" unless > we automatically trace the all object field access ;-) Humm, reading https://blog.janestreet.com/magic-trace/: "I spent a bunch of time looking for a better solution and eventually I found a really satisfying one in the perf_event_open docs. It turns out that perf_event_open can use hardware breakpoints and notify you when a memory address is executed or accessed." I.e. after the last put we could automagically add a: mem:[/len][:access] [Hardware breakpoint] But there are only HBP_NUM hardware breakpoints (4 on x86)... So some sort of scheduling would be needed, or after last put add it then, leave it there for some time, then stop tracking it, reusing it for some other object, etc. We would be able to catch some of the problems sometimes. For things that do use-after-free straight away we would get some of these and fix it, making this tunable (the time to track a object after it is last put) should be possible. > Hm, apart from this topic, isn't it good to introduce user-space trace > event( macro)s in perf tools? :-) Yeah, this seems to be an interesting case for that. - Arnaldo