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:   Fri, 19 Aug 2022 00:35:07 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC PATCH net-next 00/10] Use robust notifiers in DSA

On Fri, Aug 19, 2022 at 01:28:50AM +0300, Vladimir Oltean wrote:
> On Thu, Aug 18, 2022 at 11:49:24PM +0200, Andrew Lunn wrote:
> > I would split it into two classes of errors:
> > 
> > Bus transactions fail. This very likely means the hardware design is
> > bad, connectors are loose, etc. There is not much we can do about
> > this, bad things are going to happen no what.
> > 
> > We have consumed all of some sort of resource. Out of memory, the ATU
> > is full, too many LAGs, etc. We try to roll back in order to get out
> > of this resource problem.
> > 
> > So i would say -EIO, -ETIMEDOUT, we don't care about too
> > much. -ENOMEM, -ENOBUF, -EOPNOTSUPP or whatever, we should try to do a
> > robust rollback.
> > 
> > The original design of switchdev was two phase:
> > 
> > 1) Allocate whatever resources are needed, can fail
> > 2) Put those resources into use, must not fail
> > 
> > At some point that all got thrown away.
> 
> So you think that rollback at the cross-chip notifier layer is a new
> problem we need to tackle, because we don't have enough transactional
> layering in the code?

No, i don't think it is a new problem, but it might help explain why
you don't feel quite right about it. Some errors we simply don't care
about because we cannot do anything about it. Other errors we should
try to rollback, and hence need robust notifiers for those errors.

    Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ