[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250520180552.GP365796@horms.kernel.org>
Date: Tue, 20 May 2025 19:05:52 +0100
From: Simon Horman <horms@...nel.org>
To: jiang.kun2@....com.cn
Cc: kuniyu@...zon.com, davem@...emloft.net, edumazet@...gle.com,
fan.yu9@....com.cn, gnaaman@...venets.com, he.peilin@....com.cn,
kuba@...nel.org, leitao@...ian.org, linux-kernel@...r.kernel.org,
lizetao1@...wei.com, netdev@...r.kernel.org, pabeni@...hat.com,
qiu.yutan@....com.cn, tu.qiang35@....com.cn, wang.yaxin@....com.cn,
xu.xin16@....com.cn, yang.yang29@....com.cn, ye.xingchen@....com.cn,
zhang.yunkai@....com.cn
Subject: Re: [PATCH linux next] net: neigh: use kfree_skb_reason() in
neigh_resolve_output()
On Tue, May 20, 2025 at 06:40:32PM +0800, jiang.kun2@....com.cn wrote:
> >Is there any reason you don't change neigh_connected_output() ?
> >
> >
> >If you respin, please specify net-next and the patch version in
> >
> >Subject: [PATCH v2 net-next] net: neighbour: ...
> >
>
> Thank you for your feedback.
> I notice that most commits related to kfree_skb_reason() involve changes
> within the scope of a single function, which aligns with the meaning of
> the commit titles. I consider this approach appropriate as it facilitates
> both modification and traceability. Following this approach, I will submit
> another new patch to specifically modify neigh_connected_output().
I think it makes sense to make changes that are closely related,
as seems to be the case here, in a single patch.
--
pw-bot: changes-requested
Powered by blists - more mailing lists