linux-kernel - Re: [net-next PATCH] hsr: Simplify code for announcing HSR nodes timer setup

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: Tue, 30 Apr 2024 14:52:43 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>, Casper
 Andersson <casper.casan@...il.com>, Andrew Lunn <andrew@...n.ch>, Eric
 Dumazet <edumazet@...gle.com>, Vladimir Oltean <olteanv@...il.com>, "David
 S. Miller" <davem@...emloft.net>, Oleksij Rempel <o.rempel@...gutronix.de>,
 Tristram.Ha@...rochip.com, Sebastian Andrzej Siewior
 <bigeasy@...utronix.de>, Ravi Gunasekaran <r-gunasekaran@...com>, Simon
 Horman <horms@...nel.org>, Nikita Zhandarovich <n.zhandarovich@...tech.ru>,
 Murali Karicheri <m-karicheri2@...com>, Jiri Pirko <jiri@...nulli.us>, Dan
 Carpenter <dan.carpenter@...aro.org>, Ziyang Xuan
 <william.xuanziyang@...wei.com>, Shigeru Yoshida <syoshida@...hat.com>,
 "Ricardo B. Marliere" <ricardo@...liere.net>, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH] hsr: Simplify code for announcing HSR nodes
 timer setup

Hi Jakub,

> On Mon, 29 Apr 2024 12:09:04 +0200 Lukasz Majewski wrote:
> > > if the
> > > timer is already running we'll mess with the spacing of the
> > > frames, no?    
> > 
> > When NETDEV_CHANGE is trigger for reason different than carrier (or
> > port state) change and the netif_oper_up() returns true, the period
> > for HSR supervisory frames (i.e. HSR_ANNOUNCE_INTEVAL) would be
> > violated.
> > 
> > What are here the potential threads?  
> 
> Practically speaking I'm not sure if anyone uses any of the weird
> IFF_* flags, but they are defined in uAPI (enum net_device_flags) and
> I don't see much validation so presumably it's possible to flip them.

Ok, I see.

Then - what would you recommend instead? The approach with manual
checking the previous state has described drawbacks.

I've poked around kernel sources and it looks like the netif_oper_up()
is used in conjunction with netif_running():

netif_running(dev) && netif_oper_up(dev)

so, IMHO the netif_running(dev) shall be added to the condition.

In the uapi/include/linux/if.h there are serveral IF_OPER_* flags
defined. It looks to me that only for the IF_OPER_UP the HSR interface
shall send announcement supervisory frames. With other conditions it
shall be turned off.

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped