From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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 87FB42E62C4 for ; Wed, 11 Mar 2026 19:05:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773255951; cv=none; b=nPgC12XGB0d7Ng+ThhdvmszWpMvYWlumSxhoVExjCBez9QUkW/Nam6GJKd6pZkSsmjpNE3eVV3XMYCCArahenho7Zq9s06a0Bh5UvUPYSLxYAy0kqL/fGY6q/O+HfMnFWPXW/gdCsbTMGqHijbZRONifO/Bzc10/Pd8VBk2B5CA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773255951; c=relaxed/simple; bh=Wcqdehh141n/4jSMvJy7vOovoaJnhCiw6gtuN3sUVJY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qZsdMnHS2cy0UIh+moGl1YE7Cfth+CwGZ5eiYBquq2l8b+DodjnelmiLIpMtC/ZOoFMGfoU8NFomgVqZPAjntpFtLrUFYlivbDzm+h/eXKG0mIIGtZLbzr3XaDSE49QWTSffEWMXdBXRBXXXAnjV41l+1sl3al5u2ADbYkQFl8I= 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=hMjjFfKp; arc=none smtp.client-ip=209.85.221.50 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="hMjjFfKp" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-439c6fc2910so169858f8f.0 for ; Wed, 11 Mar 2026 12:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773255949; x=1773860749; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=4tPGB/NoSev18959WrnG45L3aRxkho8LPMhdN0AV+F8=; b=hMjjFfKpOjXBoldqA1lRTtqtzhg78pUpDhEs9XjFY+aFc1LQ1x55Dj7+d04JrGYbzF 5t518ToL8WU/RKAU4YpJU0H/mhiBGruba3uJawulN9ESOFfTd6h7em2a9F8brXZQltSx kxDYmXGOy2FImqy9YmsIqt/025TiF/d9UIZLXEUgBv8ENNGY1e8F6K4pOSdjj3eZVcSl hT5a5VkmVSoqK+P4cYLM6HsVffy5RSkioKGG5pMjl32BfWhs/5TK/MqtaSXMdxaNxNb/ Kh0D8475/bh8vEuF8psUIjMYj55a9zdh2Q2Jft+vA9r+IFEkBmVvJU07zx2FsGCEqd4A GQSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773255949; x=1773860749; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=4tPGB/NoSev18959WrnG45L3aRxkho8LPMhdN0AV+F8=; b=XniY6EwAAvX4+26kby4IgPJX8G8V646RIkB1q1GZP6jnmzAmPqdeYm9j59rg3xq2t0 ROSiAcVNE6aJiBGS1h+FphYxS1AVA53xfVGe7z6g23timnDimU0Jdv+DjJnjwW8hQ+GR mUtxVQpXaKVtoF7Dl72B+EUUJyff2hohhCLQhc/05xZL0YNmj+nhaftmxyM29jwz3AKu 5l8sCScTCN4Ms7WcyqcdRBHKKwih8rv+bEHQHufshQfeYlIOWuG7BOdVNIeLkORnci5o 4JWp50CNIgxOPe8K4Yl4wYEjXOCl8C4bW7PixCzvNa9Vb3mFTgVzOjmmrC8V1HhcIQLx /B0g== X-Forwarded-Encrypted: i=1; AJvYcCUQpYfIK1quKhlyGZVIBCt+AUOPcsdPTkXN+UZb5RHoXfSfi7LbROkTxCgphXZnyQQuK43M7L8cNm9X3y4=@vger.kernel.org X-Gm-Message-State: AOJu0Yyy/6GiGf0VGI/uIveuhkSi1yiUty5xTBi9RvxCYtfjTFWJhFiM KWvlilVeHXQsMjYjgayF/zoAwevGuLuiD5qc+tvu8lz8akuV52I/iR0t X-Gm-Gg: ATEYQzxlX8+ONiEld1XpQuy/cS5vYgWQLwELj5/dgkECt3Q2ShydUrIGD7Oy0BwOfBC 8glbvLZP+nZgD3g2ZhM5JLBwIeEqGlmY04HkIsJX8YBvI9AJOmZ07Z3MZZTPTUXkyyIpcLnfh28 bNYroouF2aWiVw84UM7jNvsj2H5jcjSvuxbU0W1bN1Sn6JrMPaVxHEqKvwGem3O8nStttc2DvE2 gh+DUAV0vu4f3Vw2K4Vx9vsXuXdQtwJLPiOQidyjx3PIf5XHTr7a0evRbJUx8Wb93zGM9mxfdZQ 6QNTx++L0lCgCDiw1beL5iFh/qI2Llw0PsSv6CbJbxhDQPaOtHJ70VyLmTDEesoY0rgT4l3nOUo Jd9b9QphwoDqxoycSDT57h4VQzQsZ0N8ijyOcEu1VrTalbTtBFPRu0xKaPaBjogmB31hAcuDTdD bOjYJQ3SMpuDu3K9ok2FEF92aa4DbrRCBphJ0KnJaV8HHB3w8QcRLdUKrlG8MT6o78iqhVHSfLP B8= X-Received: by 2002:a05:6000:310b:b0:439:bc2b:cb57 with SMTP id ffacd0b85a97d-439f81f168fmr6921963f8f.6.1773255948650; Wed, 11 Mar 2026 12:05:48 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439fe1b287dsm1448117f8f.17.2026.03.11.12.05.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2026 12:05:48 -0700 (PDT) Date: Wed, 11 Mar 2026 19:05:46 +0000 From: David Laight To: Steven Rostedt Cc: Yafang Shao , Peter Zijlstra , mingo@redhat.com, will@kernel.org, boqun@kernel.org, longman@redhat.com, mhiramat@kernel.org, mark.rutland@arm.com, mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 0/3] disable optimistic spinning for ftrace_lock Message-ID: <20260311190546.1340bcc9@pumpkin> In-Reply-To: <20260311130743.63c997ec@gandalf.local.home> References: <20260311115250.78488-1-laoar.shao@gmail.com> <20260311115426.GN606826@noisy.programming.kicks-ass.net> <20260311125350.1d89341f@pumpkin> <20260311130743.63c997ec@gandalf.local.home> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 11 Mar 2026 13:07:43 -0400 Steven Rostedt wrote: > On Wed, 11 Mar 2026 21:40:32 +0800 > Yafang Shao wrote: >=20 > > > The code needs to drop the ftrace_lock across t_show. =20 > >=20 > > It's unclear whether we can safely release ftrace_lock within t_show = =E2=80=94 > > doing so would probably necessitate a major redesign of the current > > implementation. =20 >=20 > The issue isn't t_show, it's the calls between t_start and t_next and > subsequent t_next calls, which needs to keep a consistent state. t_show > just happens to be called in between them. >=20 > > =20 > > > > > > Although there is a bigger issue of why on earth the code is reading = the > > > list of filter functions at all - never mind all the time. =20 > >=20 > > bpftrace reads the complete list of available functions into > > userspace, then performs matching against the target function to > > determine if it is traceable. =20 >=20 > Could it parse it in smaller bits? That is, the lock is held only during = an > individual read system call. If it reads the available_filter_functions > file via smaller buffers, it would not hold the lock for as long. But the expensive part is probably looking up the symbol name. Shorter reads would hand the lock off to the other process, but overall the lock would still be held for the same length of time. How does the code work out where to start from for each read system call? Couldn't you (effectively) do one symbol at a time the same way? Another option would be to put a 'generation number' on the list of functio= ns (after all it doesn't change that often). Then you can release the lock, generate the data, re-acquire the lock and check the generation number hasn't changed. If it hasn't changed you can carry on processing the list using the same pointer. If the generation number has changed terminate the read and worry about locating the correct start position for the next read. David >=20 > -- Steve >=20