[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <12e004b6-3f26-478b-953b-3b63a197479a@rbox.co>
Date: Wed, 2 Jul 2025 15:44:41 +0200
From: Michal Luczaj <mhal@...x.co>
To: Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Simon Horman <horms@...nel.org>,
Neal Cardwell <ncardwell@...gle.com>, Kuniyuki Iwashima <kuniyu@...gle.com>,
David Ahern <dsahern@...nel.org>, Boris Pismenny <borisp@...dia.com>,
John Fastabend <john.fastabend@...il.com>,
Ayush Sawal <ayush.sawal@...lsio.com>, Andrew Lunn <andrew+netdev@...n.ch>,
Wenjia Zhang <wenjia@...ux.ibm.com>, Jan Karcher <jaka@...ux.ibm.com>,
"D. Wythe" <alibuda@...ux.alibaba.com>, Tony Lu <tonylu@...ux.alibaba.com>,
Wen Gu <guwen@...ux.alibaba.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
linux-s390@...r.kernel.org
Subject: Re: [PATCH net-next v2 0/9] net: Remove unused function parameters in
skbuff.c
On 7/2/25 01:52, Jakub Kicinski wrote:
> On Tue, 1 Jul 2025 11:02:50 +0200 Paolo Abeni wrote:
>>>> I feel a little ambivalent about the removal of the flags arguments.
>>>> I understand that they are unused now, but theoretically the operation
>>>> as a whole has flags so it's not crazy to pass them along.. Dunno.
>>>
>>> I suspect you can say the same about @gfp. Even though they've both became
>>> irrelevant for the functions that define them. But I understand your
>>> hesitation. Should I post v3 without this/these changes?
>>
>> Yes please, I think it would make the series less controversial.
>>
>> Also I feel like the gfp flag removal is less controversial, as is IMHO
>> reasonable that skb_splice_from_iter() would not allocate any memory.
>
> +1, FWIW, gfp flags are more as need be the callee.
OK, here's v3 with @flags untouched:
https://lore.kernel.org/netdev/20250702-splice-drop-unused-v3-0-55f68b60d2b7@rbox.co/
>>> What's netdev's stance on using __always_unused in such cases?
>
> Subjectively, I find the unused argument warnings in the kernel
> to usually be counter-productive. If a maintainer of a piece of code
> wants to clean them up -- perfectly fine. But taking cleanup patches
> and annotating with __always_unused doesn't see very productive.
Go it, thanks.
Michal
Powered by blists - more mailing lists