netdev - Re: [PATCH net v2] net/sched: act_mirred: Don't zero blockid when net device is being deleted

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: <20240209094143.GT1435458@kernel.org>
Date: Fri, 9 Feb 2024 09:41:43 +0000
From: Simon Horman <horms@...nel.org>
To: Victor Nogueira <victor@...atatu.com>
Cc: jhs@...atatu.com, xiyou.wangcong@...il.com, jiri@...nulli.us,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, netdev@...r.kernel.org, kernel@...atatu.com,
	pctammela@...atatu.com
Subject: Re: [PATCH net v2] net/sched: act_mirred: Don't zero blockid when
 net device is being deleted

On Wed, Feb 07, 2024 at 07:29:02PM -0300, Victor Nogueira wrote:
> While testing tdc with parallel tests for mirred to block we caught an
> intermittent bug. The blockid was being zeroed out when a net device
> was deleted and, thus, giving us an incorrect blockid value whenever
> we tried to dump the mirred action. Since we don't increment the block
> refcount in the control path (and only use the ID), we don't need to
> zero the blockid field whenever a net device is going down.
> 
> Fixes: 42f39036cda8 ("net/sched: act_mirred: Allow mirred to block")
> Signed-off-by: Victor Nogueira <victor@...atatu.com>
> ---
> v1 -> v2:
> - Reword commit message to emphasise the bug is caused when a net
>   device is being deleted
> - Reword subject to emphasise the bug is caused when a net device is
>   being deleted. Original patch subject was:
>   "net/sched: act_mirred: Don't zero blockid when netns is going down"

Thanks for the update.

Reviewed-by: Simon Horman <horms@...nel.org>