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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10876C388F9 for ; Fri, 23 Oct 2020 09:23:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 97ABB24248 for ; Fri, 23 Oct 2020 09:23:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="SntEyj6R" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S461314AbgJWJXs (ORCPT ); Fri, 23 Oct 2020 05:23:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S461296AbgJWJXs (ORCPT ); Fri, 23 Oct 2020 05:23:48 -0400 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3BAD9C0613CE; Fri, 23 Oct 2020 02:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=FhPQVYPKzjZ8/oy407X+/jEjQ3F6X7vjeMfGUTwb1/s=; b=SntEyj6RUzJKiVSNK0R8fP7o43 lFHAFYQdWYluGPCpfeHIr8gcpC32+mdL5UhfBktIJXnwKNt/5YpDc1LkN0ugKka6FzDJhUH/Owj6x xzcnRXLobLR0DZMnAU+xqiX8YEsQFa0PCNns7XMiDthnzQiJG8J6MfR+TtxYPiBzHHJyYy89u+HWZ KFUz13zm/T9vajibb2OZPSvWWjc823NEHrxNKeJzGZTSPfTHUfkWKsEMoDcXmCjlRaYNrOceYw5TJ 6HQogX7xruk/ArxsCMU6YPhcxkfj/1TzooiR7AqiLWeM8pPDVkYhsx0UY/RoB+SzS1E+GilQoxFbA T8XIW/Ew==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVtIR-0000wo-Ct; Fri, 23 Oct 2020 09:23:39 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id D2489302753; Fri, 23 Oct 2020 11:23:37 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id A4655209DE6E2; Fri, 23 Oct 2020 11:23:37 +0200 (CEST) Date: Fri, 23 Oct 2020 11:23:37 +0200 From: Peter Zijlstra To: Suzuki Poulose Cc: Mathieu Poirier , Sai Prakash Ranjan , Mike Leach , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , coresight@lists.linaro.org, Stephen Boyd , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCHv2 2/4] coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf() Message-ID: <20201023092337.GQ2611@hirez.programming.kicks-ass.net> References: <20201022113214.GD2611@hirez.programming.kicks-ass.net> <20201022150609.GI2611@hirez.programming.kicks-ass.net> <788706f2-0670-b7b6-a153-3ec6f16e0f2e@arm.com> <20201022212033.GA646497@xps15> <20201023073905.GM2611@hirez.programming.kicks-ass.net> <174e6461-4d46-cb65-c094-c06ee3b21568@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <174e6461-4d46-cb65-c094-c06ee3b21568@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Fri, Oct 23, 2020 at 09:49:53AM +0100, Suzuki Poulose wrote: > On 10/23/20 8:39 AM, Peter Zijlstra wrote: > > So then I don't understand the !->owner issue, that only happens when > > the task dies, which cannot be concurrent with event creation. Are you > > Part of the patch from Sai, fixes this by avoiding the dereferencing > after event creation (by caching it). But the kernel events needs > fixing. > > One follow up question on the !->owner issue. Given the ->owner is > dying, does it prevent events from being scheduled ? Or is there a delay > between that and eventually stopping the events. In this case, we hit > the issue when : > > A A or B ? > > event_start() > ... event->owner = NULL > > READ_ONCE(event->owner); > > Is this expected ? Yeah, teardown is a bit of an effort. Also, you can pass an fd over a unix socket to another process, so this isn't something you can rely on in any case. The perf tool doesn't do it, but the kernel infra should be able to deal with someone doing a perf-deamon of sorts, where you can request a perf event and recieve a fd from it. Imagine the fun ;-) > > As for the kernel events.. why do you care about the actual task_struct > > * in there? I see you're using it to grab the task-pid, but how is that > > useful? > > Correct, kernel events are something that the driver didn't account for. > May be we could handle this case with a "special pid" and simply > disallow sharing (which is fine I believe, given there are not grouping > for the kernel created events). Why do you need a pid in the first place? Can't you use the "task_struct *" as a value? 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C96DDC55178 for ; Fri, 23 Oct 2020 09:24:54 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 64FB72192A for ; Fri, 23 Oct 2020 09:24:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bH8JnPBH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64FB72192A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7Sw98X8DltYXiTsQ4yrSgJeHGOUqS4TsZ3CoaSLP+xA=; b=bH8JnPBHNt6y7r0KkXgoZ4ad6 IF+pN0ibxyJ0x4rgFLQQkfwJegywSKejImceVmsjHHlx7Pq41PxiScy3G1CwPlh0Zd1cLdtz/GXnX Wghl5MJNgfYvc1yAQZUSq7VWOhjHKaryUjBEcHlXLzwJfrAGDKR61nRyaIeJ8FezG0R9PyQI+dIzi ry2FHVKkMDshasBUO+pJY4HLu5em7V9/Soq8bzMUYbMjIOa5LXvGBY+7dxXtwyPXMHBvGEy6/qv2R bupGkanoC0ey+TTWNXrd7nBkt7NJzFuKuwlbHUFHRSG4MLZCRIHa7ntY+vOb9ioBO8Mcf65DpdS8Q 9AB1J4sFA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVtIT-0000x6-Sc; Fri, 23 Oct 2020 09:23:41 +0000 Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVtIR-0000wo-Ct; Fri, 23 Oct 2020 09:23:39 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id D2489302753; Fri, 23 Oct 2020 11:23:37 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id A4655209DE6E2; Fri, 23 Oct 2020 11:23:37 +0200 (CEST) Date: Fri, 23 Oct 2020 11:23:37 +0200 From: Peter Zijlstra To: Suzuki Poulose Subject: Re: [PATCHv2 2/4] coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf() Message-ID: <20201023092337.GQ2611@hirez.programming.kicks-ass.net> References: <20201022113214.GD2611@hirez.programming.kicks-ass.net> <20201022150609.GI2611@hirez.programming.kicks-ass.net> <788706f2-0670-b7b6-a153-3ec6f16e0f2e@arm.com> <20201022212033.GA646497@xps15> <20201023073905.GM2611@hirez.programming.kicks-ass.net> <174e6461-4d46-cb65-c094-c06ee3b21568@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <174e6461-4d46-cb65-c094-c06ee3b21568@arm.com> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Sai Prakash Ranjan , Mathieu Poirier , Alexander Shishkin , linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org, linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , Stephen Boyd , Ingo Molnar , Namhyung Kim , Jiri Olsa , linux-arm-kernel@lists.infradead.org, Mike Leach Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 23, 2020 at 09:49:53AM +0100, Suzuki Poulose wrote: > On 10/23/20 8:39 AM, Peter Zijlstra wrote: > > So then I don't understand the !->owner issue, that only happens when > > the task dies, which cannot be concurrent with event creation. Are you > > Part of the patch from Sai, fixes this by avoiding the dereferencing > after event creation (by caching it). But the kernel events needs > fixing. > > One follow up question on the !->owner issue. Given the ->owner is > dying, does it prevent events from being scheduled ? Or is there a delay > between that and eventually stopping the events. In this case, we hit > the issue when : > > A A or B ? > > event_start() > ... event->owner = NULL > > READ_ONCE(event->owner); > > Is this expected ? Yeah, teardown is a bit of an effort. Also, you can pass an fd over a unix socket to another process, so this isn't something you can rely on in any case. The perf tool doesn't do it, but the kernel infra should be able to deal with someone doing a perf-deamon of sorts, where you can request a perf event and recieve a fd from it. Imagine the fun ;-) > > As for the kernel events.. why do you care about the actual task_struct > > * in there? I see you're using it to grab the task-pid, but how is that > > useful? > > Correct, kernel events are something that the driver didn't account for. > May be we could handle this case with a "special pid" and simply > disallow sharing (which is fine I believe, given there are not grouping > for the kernel created events). Why do you need a pid in the first place? Can't you use the "task_struct *" as a value? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel