linux-kernel - Re: [PATCH 1/1] [RFC] ethernet: Convert from tasklet to BH workqueue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 09 May 2024 09:59:22 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Simon Horman <horms@...nel.org>, Allen <allen.lkml@...il.com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, Allen Pais
 <apais@...ux.microsoft.com>, netdev@...r.kernel.org,
 jes@...ined-monkey.org,  davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, kda@...ux-powerpc.org,  cai.huoqing@...ux.dev,
 dougmill@...ux.ibm.com, npiggin@...il.com,  christophe.leroy@...roup.eu,
 aneesh.kumar@...nel.org, naveen.n.rao@...ux.ibm.com, 
 nnac123@...ux.ibm.com, tlfalcon@...ux.ibm.com, cooldavid@...ldavid.org, 
 marcin.s.wojtas@...il.com, mlindner@...vell.com,
 stephen@...workplumber.org,  nbd@....name, sean.wang@...iatek.com,
 Mark-MC.Lee@...iatek.com, lorenzo@...nel.org,  matthias.bgg@...il.com,
 angelogioacchino.delregno@...labora.com,  borisp@...dia.com,
 bryan.whitehead@...rochip.com, UNGLinuxDriver@...rochip.com, 
 louis.peens@...igine.com, richardcochran@...il.com,
 linux-rdma@...r.kernel.org,  linux-kernel@...r.kernel.org,
 linux-acenic@...site.dk,  linux-arm-kernel@...ts.infradead.org,
 linuxppc-dev@...ts.ozlabs.org,  linux-mediatek@...ts.infradead.org,
 oss-drivers@...igine.com,  linux-net-drivers@....com
Subject: Re: [PATCH 1/1] [RFC] ethernet: Convert from tasklet to BH workqueue

On Wed, 2024-05-08 at 21:16 +0100, Simon Horman wrote:
> * As this patch seems to involve many non-trivial changes
>   it seems to me that it would be best to break it up somehow.
>   To allow proper review.

I would like to stress this latest point: it looks like the changes to
all the drivers are completely independent. If so, you have to break
the series on a per driver basis. Since the total number of patch will
be higher then 15 (maximum size allowed on netdev) you will have to
split this in several smaller series.

Beyond making the change reviewable, it will allow eventually reverting
the changes individually, should that cause any regressions.

Thanks,

Paolo