From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 8CAF44582F9 for ; Fri, 14 Aug 2026 09:09:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786698546; cv=none; b=ehD/cZVzNCvyimvUv7r3pEQu2KZ16jzitKtfjKj9JQ+q8ZijhIM/3NecGAHh3OOL3SBqN03J2KGg2gV4Vr5FMcCf7CqigkAgf5TkFMgZdkgxQCdbcxx7xyz8iwL5LYtJN8Adc+i1o9IuYgSuFfNkq9Gpq+alJUa82yWjya3FChY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786698546; c=relaxed/simple; bh=Iu3nqX+5eqDwG9zLQeVIbWMzDG8vwbCwcT4+gqm46EI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mqBZfTJ1Yy6qh0yJNvPIdpMjZym3QUqyrVTv+iOmNfZ6cEsi+/eI7dUcI37dwolGmK43Wa5D4PhWG45bjrI3X2RjDwNhNq6NCc3Kqqk03KHiESQLLvSq2Z1+hgNvEIFnOv0DErTdWNoDVKxI4qo/g+Js3TmcjPq15lYriZSb9WE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=YzM2WO7L; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="YzM2WO7L" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49554ebb87dso7723125e9.3 for ; Fri, 14 Aug 2026 02:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1786698542; x=1787303342; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=4WTZwbHgMA/G7V8SEEozrrVbUbsFcp4zLLIj1B5X1kE=; b=YzM2WO7LpKwZGASv9ACgIqql+lvF8sKJ+xdlB2FVkEkUg2ZEXlUqKj52DkOdVmCLsg J5W1hfPSxY+R8NQ3RWXr2nEH4IMkOYX9vuJmHpJu0gQ0KazldcVauv9HdO2qzWus7ZXs RYUt6FaqBWSRjwFf4pPJtfBlQQhvpIz08oyTxuKrpnuOdSdw3njin9FNp3bfdGWxHoB2 DM+hn2x/UP3/819FIrI+1UZF4ruSLw6aU81bsxvIooNPeICCMBYMCl5bZjBkskexANCK IUuLfot7/cTbesNnkz41rhNqQOyUyexTGJrizEQsCSw4U+hC2/oE6O+soyxcDy2IIOo3 NzSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786698542; x=1787303342; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4WTZwbHgMA/G7V8SEEozrrVbUbsFcp4zLLIj1B5X1kE=; b=PSCmWlNFBiwqysyzX5FNWb+aTObeTNAR7UURFCWhHrCJ+g/Go5P1QQ/mOwFbaJ/wfK AsuY4NNe2K8sFc0NzJxxOLVaSW6lMh6S/9doYgXggv64/ERSpHiuGAIWjOTbZ25DdOji NwBztQQnGCK9EAZHFU6U8HGfYlGPg4IaXrv1WOoSVbCnhcGuP8MJm1ByjgnsKsIg3bl8 5F9NZC015UPa/6t8PgVgreyRhRWkjjblNc6MSDRL9msjffy5fA/Nou9vJyKVBx8Wm3h1 mQg9A3lJE2TqpIEiJkb7vRWHetfpXFQJ/Y0sivCgCvq/vuHYGdscvqJ/sjuh4Vx2zwYv SjxQ== X-Forwarded-Encrypted: i=1; AHgh+RqaL6BdWxBjAmqUJOy+m+OtpPP9PWqAq/9rTWXzp3WY/x7au56mZrRtXckEheEfrt/UFdctNogc6aEmaIg=@vger.kernel.org X-Gm-Message-State: AOJu0YzPrYDtjVzIEi/flUni8UpcPgIxFNa9HCrP20S28YyPMfixoftW WSC4hEZizn1mis7xD4+2/Qm2FF2pRryM0BTi0iPdBUc6rVRQ39ZmJ/TOY7cPotHqCYw= X-Gm-Gg: AR+sD11FwOoKT6tTArVrLyVOtK+zUCuyyqFsxMVJ7pPjNjBsZTU9tICc4Oa70eH/mMX ZLiw63TLjI83qo1pGyIlASelG/zQ6WQoJmgjESrNvVLtdQIwdDK3urjVDedzjNPis++dGkiG6te IIaDQ9Zu7q+5AQV7T1sFbU2rw3tNtL2kJch6k6jJpD7a6YTMj04AKTKZKhdRT2e2/PRH4rFs/gb XldDYllIxTXLreMmstYVOITFVE7E0UA01+CKXkdptYH2dfhreQfC9aT5JcX/2+uGezTwIr0vvEQ 6C6qlUhpz4CIe2vY8sIcQIizxkQ9zBt8Qm4VP1VtvHlh679xklWDJGjUJGkHdgv0p51T85Mdldp VtHmICDB97GbDg/AtIu1hSAO+q/IBPeOvWPvPj1/nYL8hn+Q30JnKUfhZtkClJr67qbThgW7Hoe X+ZKausg9M3HdBKKAFi2lqXf9nP4cSNj8nPFJOQ16Z+Yy7uJmweyH+BC/dhPTs2KpMbA== X-Received: by 2002:a05:600c:5715:b0:499:5e50:5be9 with SMTP id 5b1f17b1804b1-499879af71emr44054715e9.16.1786698542541; Fri, 14 Aug 2026 02:09:02 -0700 (PDT) Received: from [192.168.1.3] ([37.18.141.193]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49988b24746sm58966465e9.12.2026.08.14.02.09.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Aug 2026 02:09:02 -0700 (PDT) Message-ID: Date: Fri, 14 Aug 2026 10:09:01 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/8] coresight: tmc-etr: Prevent per-thread events from sharing a sink To: Leo Yan Cc: Suzuki K Poulose , Mike Leach , Suyash Mahar , Yeoreum Yun , Greg Kroah-Hartman , Qi Liu , Junhao He , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jonathan Cameron References: <20260728-james-cs-multiple-per-threads-v3-0-6aee7579f1dc@linaro.org> <20260728-james-cs-multiple-per-threads-v3-4-6aee7579f1dc@linaro.org> <20260813160504.GC8904@e132581.arm.com> Content-Language: en-US From: James Clark In-Reply-To: <20260813160504.GC8904@e132581.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 13/08/2026 17:05, Leo Yan wrote: > On Tue, Jul 28, 2026 at 04:00:16PM +0100, James Clark wrote: > > [...] > >> The identity and compatibility of a session are determined by the owning >> process, the target process, and the inheritance settings together. > > Could you elaborate a bit on the session model you are trying to support > here? > > My understanding of a legacy sink such as ETR/ETF is that it can be > owned by only one perf session at a time. Multiple events belonging to > that session may use the sink, but an attempt from another perf session > should be rejected with -EBUSY. > > For per-thread mode, I wonder if we could support _only_ non-inherited non-inheritance is enforced for per-thread mode in the perf core. So we already don't support it. > events. In that case, we would not need to determine compatibility based > on the target process and inheritance settings. > > From the patch, it seems trying to support a more flexible model, where I don't think so. It's actually less flexible than what exists currently. Currently we only check the PID of the owner, and all sharing is allowed. That means there are a lot of combinations of things that result in sharing that are invalid. For example PID re-use and incompatible per-thread events, like the original bug. > an already active legacy sink can also be shared by another perf session There isn't any sharing with "another perf session", unless there is a mistake somewhere? Checking that the owners are equivalent enforces this. Or do you mean another event owned by the same process? > and also support inherit mode for child events? > > Thanks, > Leo We need to fix the bugs but still support one process owning multiple PERF_ATTACH_TASK events, because that's what you get when you do this: perf record -e cs_etm// -- my_task Perf doesn't do one per-thread event here, it's is still PERF_ATTACH_TASK, but with a separate event opened for each CPU. So we need a model that still supports this to not cause a regression, but doesn't have any sharing bugs. I'm not sure the exact model you had in mind was that still supports this and fixes the bugs? The one in this change is pretty complete and only does 4 comparisons, which seems quite simple to me. It only has one shortcoming that I'm aware of, that it doesn't take into account the cgroup settings, but I don't see a use case where that needs to be solved. Even if different events with different cgroup settings should would follow different processes, the owning process would have to do something quite crazy to get there.