From mboxrd@z Thu Jan 1 00:00:00 1970 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 E93E0C8FF for ; Sun, 10 Nov 2024 14:00:22 +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=1731247223; cv=none; b=Lovt8cap5FP6xLpO4kFcQmAKZ39ouIYPv24Omwy2JbvpISETPV8md7I/Eyhzs9B7tWsCy30xlCZrK64ysZIrLxFH4x29GM7DcqBOUEfShlrR5Y/woNmSSdbQJ454tsamKpZ2EYLKFvD2XJ7aY3QAtv9HdBYiRnfmxEUMigxSRLA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731247223; c=relaxed/simple; bh=R89LLNcZc87UAVkdS+7soEbp9X/milyLofWyjfHefAo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=m2kEWV9o0YG+3p8HEccDmS9CXo/QKYLEb/C7LzNNtbJ+KmnJIWvDBhfK79pUnM6vClfc3I4bHXPj7HQQt2w3eoazt3KToA6z9W20fQjFpJsMHLDIdW+3MW3g2/hdDDnIAWF0zZq/GI6HGRGx+jm019uv9Kiy8xwDpDul7EaUe3I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M3KIk+Gu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M3KIk+Gu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67B36C4CECD; Sun, 10 Nov 2024 14:00:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1731247222; bh=R89LLNcZc87UAVkdS+7soEbp9X/milyLofWyjfHefAo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M3KIk+GuYw+vVVd5fTvpEf/TW+tc2ac53sFjvl8ObcMAG4ibp1t3NgCNmuAyEwPyo eQNUnSdU8cz4w4Sa9kW50OAoy9WrcqVMN9YRGctp4+UK2OadtOXT8vQNWW8o0Dqsiz dkMHbNP5URXMtna5HNiE091QLBub0acMDg9B3/pCXrSqFGmSiwMeu3vQndy85Su4mf 2aC1T/lgfqxnFaPL5NCxR1kXMhAufkqem6aJyTXqk0wuaio2PgQsGr6WfNftRaIAuI 0OVr9+JDkZavcDgWWganvgP9xc6CR6GsmWnDQHGVkX11RckhhhG6aiETGjtoT/Dn8g hoaeObnI7O9uQ== Date: Sun, 10 Nov 2024 14:00:17 +0000 From: Simon Horman To: Alexandre Ferrieux Cc: Vadim Fedorenko , Pedro Tammela , edumazet@google.com, jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us, netdev@vger.kernel.org Subject: Re: [PATCH net] Fix u32's systematic failure to free IDR entries for hnodes. Message-ID: <20241110140017.GS4507@kernel.org> References: <20241104102615.257784-1-alexandre.ferrieux@orange.com> <433f99bd-5f68-4f4a-87c4-f8fd22bea95f@mojatatu.com> <27042bd2-0b71-4001-acf8-19a0fa4a467b@linux.dev> <46ddc6aa-486e-4080-a89b-365340ef7c54@gmail.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46ddc6aa-486e-4080-a89b-365340ef7c54@gmail.com> On Mon, Nov 04, 2024 at 10:51:01PM +0100, Alexandre Ferrieux wrote: > On 04/11/2024 22:33, Vadim Fedorenko wrote: > > On 04/11/2024 20:26, Alexandre Ferrieux wrote: > >> On 04/11/2024 18:00, Pedro Tammela wrote: > >>>> > >>>> Signed-off-by: Alexandre Ferrieux > >>> > >>> SoB does not match sender, probably missing 'From:' tag > >> > >> Due to dumb administrativia at my organization, I am compelled to post from my > >> personal gmail accout in order for my posts to be acceptable on this mailing > >> list; while I'd like to keep my official address in commit logs. Is it possible ? > > > > Yes, it's possible, the author of commit in your local git should use > > email account of company, then git format-patch will generate proper header. > > That's exactly what I did, and the file generated by format-patch does have the > proper From:, but it gets overridden by Gmail when sending. That's why, as a > last resort, I tried Signed-off-by... Any hope ? > > > you can add > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > > Ok. > > >>> 'static inline' is discouraged in .c files > >> > >> Why ? > >> > >> It could have been a local macro, but an inline has (a bit) better type > >> checking. And I didn't want to add it to a .h that is included by many other > >> unrelated components, as it makes no sense to them. So, what is the recommendation ? > > > > Either move it to some local header file, or use 'static u32 > > handle2id(u32 h)' > > and let compiler decide whether to include it or not. > > I believe you mean "let the compiler decide whether to _inline_ it or not". > Sure, with a sufficiently modern Gcc this will do. However, what about more > exotic environments ? Wouldn't it risk a perf regression for style reasons ? > > And speaking of style, what about the dozens of instances of "static inline" in > net/sched/*.c alone ? Why is it a concern suddenly ? Hi Alexandre, It's not suddenly a concern. It is a long standing style guideline for Networking code, even if not always followed. Possibly some of the code you have found in net/sched/*.c is even longer standing than the guideline. Please don't add new instances of inline to .c files unless there is a demonstrable - usually performance - reason to do so. Thanks!