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
| ||
|
Message-ID: <CAKhg4tJs-6HGOtyHP7KWpPjAAQy6BkbRf5LQvDzCwmLAkJXOwQ@mail.gmail.com> Date: Fri, 11 Aug 2023 20:02:30 +0800 From: Liang Chen <liangchen.linux@...il.com> To: Jesper Dangaard Brouer <hawk@...nel.org> Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, linyunsheng@...wei.com, ilias.apalodimas@...aro.org, daniel@...earbox.net, ast@...nel.org, netdev@...r.kernel.org Subject: Re: [RFC PATCH net-next v2 1/2] net: veth: Page pool creation error handling for existing pools only On Wed, Aug 2, 2023 at 4:56 PM Jesper Dangaard Brouer <hawk@...nel.org> wrote: > > > > On 01/08/2023 08.19, Liang Chen wrote: > > The failure handling procedure destroys page pools for all queues, > > including those that haven't had their page pool created yet. this patch > > introduces necessary adjustments to prevent potential risks and > > inconsistency with the error handling behavior. > > > > Signed-off-by: Liang Chen <liangchen.linux@...il.com> > > --- > > drivers/net/veth.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/veth.c b/drivers/net/veth.c > > index 614f3e3efab0..509e901da41d 100644 > > --- a/drivers/net/veth.c > > +++ b/drivers/net/veth.c > > @@ -1081,8 +1081,9 @@ static int __veth_napi_enable_range(struct net_device *dev, int start, int end) > > err_xdp_ring: > > for (i--; i >= start; i--) > > ptr_ring_cleanup(&priv->rq[i].xdp_ring, veth_ptr_free); > > + i = end; > > err_page_pool: > > - for (i = start; i < end; i++) { > > + for (i--; i >= start; i--) { > > I'm not a fan of this coding style, that iterates backwards, but I can > see you just inherited the existing style in this function. > > > page_pool_destroy(priv->rq[i].page_pool); > > priv->rq[i].page_pool = NULL; > > } > > The page_pool_destroy() call handles(exits) if called with NULL. > So, I don't think this incorrect walking all (start to end) can trigger > an actual bug. > > Anyhow, I do think this is more correct, so you can append my ACK for > the real submission. > > Acked-by: Jesper Dangaard Brouer <hawk@...nel.org> > Thanks! I will separate this patch out and make a real submission, since it's a small fix and not really coupled with the optimization patch which still needs some further work after receiving feedback from Yunsheng. Thanks, Liang
Powered by blists - more mailing lists