netdev - Re: [RFC net-next v2 1/8] net: sched: register callbacks for indirect tc block binds

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ3xEMh-7FUnXRJks11cmvwjfrSsYG_O0pGEew-VmefWFJ5R_g@mail.gmail.com>
Date:   Mon, 29 Oct 2018 17:12:27 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     John Hurley <john.hurley@...ronome.com>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com, Jiri Pirko <jiri@...nulli.us>,
        Oz Shlomo <ozsh@...lanox.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Aviv Heller <avivh@...lanox.com>
Subject: Re: [RFC net-next v2 1/8] net: sched: register callbacks for indirect
 tc block binds

On Mon, Oct 29, 2018 at 2:54 PM John Hurley <john.hurley@...ronome.com> wrote:
> On Sun, Oct 28, 2018 at 11:10 AM Or Gerlitz <gerlitz.or@...il.com> wrote:
> >
> > On Thu, Oct 25, 2018 at 3:28 PM John Hurley <john.hurley@...ronome.com> wrote:
> > > Currently drivers can register to receive TC block bind/unbind callbacks
> > > by implementing the setup_tc ndo in any of their given netdevs. However,
> > > drivers may also be interested in binds to higher level devices (e.g.
> > > tunnel drivers) to potentially offload filters applied to them.
> >
> > > Introduce indirect block devs which allows drivers to register callbacks
> > > for block binds on other devices. The calling driver is expected to
> > > reference an 'owner' struct that it will pass to all block registrations.
> > > This is used to track the callbacks from a given driver and free them if
> > > the driver is removed while the upper level device is still active.

>> Maybe it would be better to follow the trusted environment model of the kernel
>> and not protect the core from driver bugs? If the driver does things right they
>> will unregister before bailing out and if not, they will have to fix..

> The owner stuff just makes it easier for a driver to track the blocks
> it has registered for and, in turn, release these when exiting.
> We could just leave this up to the driver to ensure it properly cleans
> up after itself.

If it makes the life of the driver easier and doesn't add notable complexity,
then I think I am good to leave it

> I don't feel that strongly either way.

m2

So lets see if other comment here, if not, we can just leave it, I guess

> > > Allow registering an indirect block dev callback for a device that is
> > > already bound to a block. In this case (if it is an ingress block),
> > > register and also trigger the callback meaning that any already installed
> > > rules can be replayed to the calling driver.

> > not just can be replayed.. they will be replayed, but through an
> > existing (tc re-offload?) facility, correct?

> Yes, currently in TC, when you register for rule callbacks to a block
> that already has rules, these rules are replayed.
> With the indirect block approach we still use the same mechanism for
> requesting rule callbacks,

sounds good