Received: by 2002:ab2:6c55:0:b0:1fd:c486:4f03 with SMTP id v21csp557523lqp; Wed, 12 Jun 2024 09:17:53 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCU7u/QhOkQWK5WtKWsU7Cn+qf2lPSmLjzR8mrGGvffsJYFxgxziRL6iAGrnZxZFfBOJtz8ltM17gvt/sJSRjpLZ6Zkf+h/BEb4YfqEKzw== X-Google-Smtp-Source: AGHT+IGwPaOdwUfkl26N39J+JBH6jj8+paou+Ic9calt9dyAT40XTS7ic8msgsw0DwGEcy3uhDqI X-Received: by 2002:a17:902:f70b:b0:1f8:3d1d:b3a5 with SMTP id d9443c01a7336-1f83d1db711mr24129335ad.23.1718209072971; Wed, 12 Jun 2024 09:17:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718209072; cv=pass; d=google.com; s=arc-20160816; b=CGonsnSbmlca8gI1HEfM602a6xWhhnC7H3Ts7nmb8TJ+fYtf5DEDbfEGGNNPZuxbe2 aJNtpPp1aoXtf/PaUuyTGWKGxGg3IDokkOdxRBgklh/1LbgVFjPvXGnN2yApY9G4mPHQ Sg7VaVk175v11ZBmG/WSTSEmMkd2f8G3KrG7VWgZlMXI4UpIqE5h7pFgB7JuYHcvJjc2 OHII5iPWuNOk1XJm2KJdVJza0DAVAb/0W97C5fxvJ3yeDdQkyFTZjzbu5/OmdLqeqTvo jETIQ4/hQmstmatSym36NEFgJHvvtQcDwjbzqizO+vmygHEI6hBqPMHJizDdKQ6HjfqM 0HXg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date; bh=m9GZUAkej0w9jDcC4L/B1bK38A84r0CV2z8hymLIsAo=; fh=eRSuz9j+jVqiNvfXBcQmt1PcaI9Hw7WxcuqW0sy2zjo=; b=VCD+CnQwc0cpGNCl+X+1NfJH36pk7qptZKg4dfKlD+Mi76G9GdZzs2P61DcAXnh6Iq GMMIOFmU7ttKU7hQXaxVDDjxREzFvFavhIzFUKCnAACqFeXGYLzfUbTtqjjemzXmaHDb vrAOHVPwBCzOB9i9jVXRB/nAq+Spi7i4BO3fXl4GpB3MokmAJuoLmZE23Zh1P6AmvjsE b3mUgkXiITg9pW9F2PhG9TWOQKeH2d2j0SZQvxyqOCtsUIPZkml44XN/7LsBVz7ZsXiw l5acxU5ayuCQH+Q0nTn6igFKqM/bPVpaSiXWWLs2aQcDB3vPx6Db1ok482bgkoEaBMBM TMHQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-211866-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-211866-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id d9443c01a7336-1f6ec2200a8si89340485ad.617.2024.06.12.09.17.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jun 2024 09:17:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-211866-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-211866-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-211866-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 9B5BF284564 for ; Wed, 12 Jun 2024 16:07:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C1510181BB7; Wed, 12 Jun 2024 16:05:01 +0000 (UTC) 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 33AD617FAA4; Wed, 12 Jun 2024 16:05:00 +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=1718208301; cv=none; b=uQJFnR6iK67YS/kSHW0kEXXxc5JAd3DAtSL+CznFRlW64oUZtfqdTWF4BTrvTXRHYJmMapa44ZLr8h+Dh6I2tKzg6lvcNTcpeJO0WAm3pGfypumouxxS611uLNWdWm2tmrs7Xy5jHqJRA04ifWXj4/PEALwd1dMlch3mlx77TBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718208301; c=relaxed/simple; bh=RWJAxgMTq0703GeW99QCv1Ot2/tX/YqzAh2KeOG06tI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=C847Tz/x1t737Rb81A/ZdS60SLpZA6XrwIv1SkdRwv0qB1A+geym9m9BsOYwh6nAbFTiB+qJQVdnfJF/AjFa/GUBuTCF4jGFRf/PSqiFir0SeeTTrjXFdkZzgdEMGeXXLM0jp1IzATH+T0O+PGCbjFE3DN0Nn6/IFrHcLiAg8Ic= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E39BC32786; Wed, 12 Jun 2024 16:04:59 +0000 (UTC) Date: Wed, 12 Jun 2024 12:04:57 -0400 From: Steven Rostedt To: "Jason A. Donenfeld" Cc: Vlastimil Babka , Greg KH , "Paul E. McKenney" , Julia Lawall , kernel-janitors@vger.kernel.org, Masami Hiramatsu , Mathieu Desnoyers , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, "workflows@vger.kernel.org" , Thorsten Leemhuis Subject: Re: [PATCH 05/14] tracefs: replace call_rcu by kfree_rcu for simple kmem_cache_free callback Message-ID: <20240612120457.5329934c@rorschach.local.home> In-Reply-To: References: <20240609082726.32742-1-Julia.Lawall@inria.fr> <20240609082726.32742-6-Julia.Lawall@inria.fr> <20240610112223.151faf65@rorschach.local.home> <20240610163606.069d552a@gandalf.local.home> <70c093a5-df9c-4665-b9c9-90345c7f2139@suse.cz> <2024061143-transfer-jalapeno-afa0@gregkh> <05ec743a-c4e9-4c66-b2cd-4e89c858d7d4@suse.cz> <20240611101458.7fa78da8@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 12 Jun 2024 16:09:40 +0200 "Jason A. Donenfeld" wrote: > > > > I think "Depends-on" is the way to go, as it is *not* a stable thing, and > > what is in stable rules is only about stable patches. > > How does "Depends-on" not spiral out of control? There's a *lot* of > "Depends-on" relations one could express in commit series and such. Of > course a lot of git itself is designed to show some subset of these > relationships. If a change occurs because a recent change happened that allows the current change to work, then I think a Depends-on is appropriate. Like in this example. I thought this change was broken, and it would have been except for a recent change. Having the dependency listed is useful, especially if the dependency is subtle (doesn't break the build and may not show the bug immediately). > > It seems like in most cases, the "Cc: stable@v.g.o # x.y.z+" notation > expresses the backporting safety correctly. What is the purpose of > saying, "if you need this patch for any reason, you also need patch X"? > Who is the intended audience, and are you sure they need this? The intended audience is someone backporting features and not fixes. > > I ask these questions because I wind up doing a lot of work backporting > patches to stable and marking things properly for that or submitting > manually backported stable patches and so forth, and in general, patch > applicability for stable things is something I wind up devoting a lot of > time to. If I have to *additionally* start caring about the theoretical > possibility that somebody in the future, outside of the stable flow, > might not understand the context of a given patch and blindly apply it > to some random tree here or there, that sounds like a lot of extra brain > cycles to consider. > > So, is this actually necessary, and how does it not spiral out of > control? How would you see it going out of control? And "Depends-on" would only be used for non stable relationships. If stable backports, we can keep with the current method. -- Steve