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]
Message-ID: <20240119150451.476d6ba2@device-28.home>
Date: Fri, 19 Jan 2024 15:04:51 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Jenishkumar Maheshbhai Patel <jpatel2@...vell.com>
Cc: <marcin.s.wojtas@...il.com>, <linux@...linux.org.uk>,
 <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
 <pabeni@...hat.com>, <netdev@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, Antoine Tenart <atenart@...nel.org>
Subject: Re: [net v4 PATCH 1/1] net: mvpp2: clear BM pool before
 initialization

Hello,

On Thu, 18 Jan 2024 19:59:14 -0800
Jenishkumar Maheshbhai Patel <jpatel2@...vell.com> wrote:

> Register value persist after booting the kernel using
> kexec which results in kernel panic. Thus clear the
> BM pool registers before initialisation to fix the issue.
> 
> Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
> Signed-off-by: Jenishkumar Maheshbhai Patel <jpatel2@...vell.com>
> ---
> v1-v2:
> -Move comments outside the loop
> -remove unrequired brances.
> v2-v3:
> -improve readability
> -correct register read API
> v3-v4:
> -optimize the code
> -improve readability

Thanks for taking the reviews into account, however ...

>  .../net/ethernet/marvell/mvpp2/mvpp2_main.c   | 27 ++++++++++++++++++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 820b1fabe297..23adf53c2aa1 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -614,12 +614,38 @@ static void mvpp23_bm_set_8pool_mode(struct mvpp2 *priv)
>  	mvpp2_write(priv, MVPP22_BM_POOL_BASE_ADDR_HIGH_REG, val);
>  }
>  
> +/* Cleanup pool before actual initialization in the OS */
> +static void mvpp2_bm_pool_cleanup(struct mvpp2 *priv, int pool_id)
> +{
> +	unsigned int thread = mvpp2_cpu_to_thread(priv, get_cpu());
> +	u32 val;
> +	int i;
> +
> +	/* Drain the BM from all possible residues left by firmware */
> +	for (i = 0; i < MVPP2_BM_POOL_SIZE_MAX; i++)
> +		mvpp2_thread_read(priv, thread, MVPP2_BM_PHY_ALLOC_REG(pool_id));

... I think you didn't answer Antoine's comment on that loop from the
V2, regarding what this does exactly. From the other sites this is
used, it seems to perform an allocation from the pool, can you clarify
how safe it is to do so here, if for example the BM was never configured
by the firmware beforehand and is therefore already in a Stopped state ?

And are we not risking any leak if there was something in the pool that
we don't release ?

Thanks,

Maxime


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ