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: <20210519135603.585a5169@kicinski-fedora-PC1C0HJN>
Date:   Wed, 19 May 2021 13:56:03 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     Lijun Pan <ljp@...ux.vnet.ibm.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] mlx5: count all link events

On Wed, 19 May 2021 13:18:36 -0700 Saeed Mahameed wrote:
> On Wed, 2021-05-19 at 12:51 -0700, Jakub Kicinski wrote:
> > On Wed, 19 May 2021 14:34:34 -0500 Lijun Pan wrote:  
> > > Is it possible to integrate netif_carrier_event into
> > > netif_carrier_on? like,
> > > 
> > > void netif_carrier_on(struct net_device *dev)
> > > {
> > >         if (test_and_clear_bit(__LINK_STATE_NOCARRIER, &dev->state))
> > > {
> > >                 if (dev->reg_state == NETREG_UNINITIALIZED)
> > >                         return;
> > >                 atomic_inc(&dev->carrier_up_count);
> > >                 linkwatch_fire_event(dev);
> > >                 if (netif_running(dev))
> > >                         __netdev_watchdog_up(dev);
> > >         } else {
> > >                 if (dev->reg_state == NETREG_UNINITIALIZED)
> > >                         return;
> > >                 atomic_inc(&dev->carrier_down_count);
> > >                 atomic_inc(&dev->carrier_up_count);
> > >         }
> > > }
> > > EXPORT_SYMBOL(netif_carrier_on);  
> > 
> > Ah, I meant to address that in the commit message, thanks for bringing
> > this up. I suspect drivers may depend on the current behavior of
> > netif_carrier_on()/off() being idempotent. We have no real reason for
> > removing that assumption.
> > 
> > I assumed netif_carrier_event() would be used specifically in places
> > driver is actually servicing a link event from the device, and
> > therefore is relatively certain that _something_ has happened.  
> 
> then according to the above assumption it is safe to make
> netif_carrier_event() do everything.
> 
> netif_carrier_event(netdev, up) {
> 	if (dev->reg_state == NETREG_UNINITIALIZED)
> 		return;
> 
> 	if (up == netif_carrier_ok(netdev) {
> 		atomic_inc(&netdev->carrier_up_count);
> 		atomic_inc(&netdev->carrier_down_count);
> 		linkwatch_fire_event(netdev);
> 	}
> 
> 	if (up) {
> 		netdev_info(netdev, "Link up\n");
> 		netif_carrier_on(netdev);
> 	} else {
> 		netdev_info(netdev, "Link down\n");
> 		netif_carrier_off(netdev);
> 	}
> }

Two things to consider are:
 - some drivers print more info than just "link up/link down" so they'd
   have to drop that extra stuff (as much as I'd like the consistency)
 - again with the unnecessary events I was afraid that drivers reuse 
   the same handler for device events and to read the state in which
   case we may do something like:

	if (from_event && up == netif_carrier_ok(netdev)

Maybe we can revisit when there's more users?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ