netdev - Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: Make VTU miss violations less spammy

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:   Wed, 28 Mar 2018 11:11:07 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>, David Miller <davem@...emloft.net>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: Make VTU miss
 violations less spammy

On 03/27/2018 02:59 PM, Andrew Lunn wrote:
> VTU miss violations can happen under normal conditions. Don't spam the
> kernel log. The statistics counter will indicate it is happening, if
> anybody is interested.
> 
> Signed-off-by: Andrew Lunn <andrew@...n.ch>

Reported-by: Florian Fainelli <f.fainelli@...il.com>

> ---
>  drivers/net/dsa/mv88e6xxx/global1_vtu.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx/global1_vtu.c b/drivers/net/dsa/mv88e6xxx/global1_vtu.c
> index 2cbaf946e7ed..e0f1b4f6e29f 100644
> --- a/drivers/net/dsa/mv88e6xxx/global1_vtu.c
> +++ b/drivers/net/dsa/mv88e6xxx/global1_vtu.c
> @@ -547,11 +547,9 @@ static irqreturn_t mv88e6xxx_g1_vtu_prob_irq_thread_fn(int irq, void *dev_id)
>  		chip->ports[spid].vtu_member_violation++;
>  	}
>  
> -	if (val & MV88E6XXX_G1_VTU_OP_MISS_VIOLATION) {
> -		dev_err_ratelimited(chip->dev, "VTU miss violation for vid %d, source port %d\n",
> -				    entry.vid, spid);

Why not keep it as a dev_dbg() message? Ideally we would want to keep
those message around when the port is enslaved to a bridge, and vlan
filtering is enabled. In other cases, I agree this is just spam with the
current error level.

> +	if (val & MV88E6XXX_G1_VTU_OP_MISS_VIOLATION)
>  		chip->ports[spid].vtu_miss_violation++;
> -	}
> +
>  	mutex_unlock(&chip->reg_lock);
>  
>  	return IRQ_HANDLED;
> 


-- 
Florian