netdev - Re: [net-next v6 PATCH 0/2] page_pool: NUMA node handling fixes

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] [day] [month] [year] [list]

Message-ID: <20200103112358.GA45778@apalos.home>
Date:   Fri, 3 Jan 2020 13:23:58 +0200
From:   Ilias Apalodimas <ilias.apalodimas@...aro.org>
To:     David Miller <davem@...emloft.net>
Cc:     brouer@...hat.com, netdev@...r.kernel.org, lirongqing@...du.com,
        linyunsheng@...wei.com, saeedm@...lanox.com, mhocko@...nel.org,
        peterz@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next v6 PATCH 0/2] page_pool: NUMA node handling fixes

Thanks David

On Thu, Jan 02, 2020 at 03:38:25PM -0800, David Miller wrote:
> From: Jesper Dangaard Brouer <brouer@...hat.com>
> Date: Fri, 27 Dec 2019 18:13:13 +0100
> 
> > The recently added NUMA changes (merged for v5.5) to page_pool, it both
> > contains a bug in handling NUMA_NO_NODE condition, and added code to
> > the fast-path.
> > 
> > This patchset fixes the bug and moves code out of fast-path. The first
> > patch contains a fix that should be considered for 5.5. The second
> > patch reduce code size and overhead in case CONFIG_NUMA is disabled.
> > 
> > Currently the NUMA_NO_NODE setting bug only affects driver 'ti_cpsw'
> > (drivers/net/ethernet/ti/), but after this patchset, we plan to move
> > other drivers (netsec and mvneta) to use NUMA_NO_NODE setting.
> 
> Series applied to net-next with the "fallthrough" misspelling fixed in
> patch #1.
> 
> Thank you.
I did review the patch and everything seemed fine, i was waiting Saeed to test
it

in any case you can add my reviewed by if it's not too late

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@...aro.org>