netdev - Re: the future of ethtool

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: <20101115233335.GB24292@canuck.infradead.org>
Date:	Mon, 15 Nov 2010 18:33:35 -0500
From:	Thomas Graf <tgraf@...radead.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Ben Hutchings <bhutchings@...arflare.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	NetDev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: the future of ethtool

On Mon, Nov 15, 2010 at 05:49:33PM -0500, Jeff Garzik wrote:
> s/only//   I don't think Stephen is suggesting sending _some_ ops
> through netlink and others through old-ioctl.  That's just silly.
> Any new netlink interface should transit all existing ETHTOOL_xxx
> commands/structures.
> 
> But presumably, one would have the ability to send multiple
> ETHTOOL_xxx bundled together into a single netlink transaction,
> facilitating the kernel's calling of struct ethtool_ops'
> 	->begin()
> 	... first operation specified by userspace via netlink ...
> 	... second operation specified by userspace via netlink ...
> 	... etc.
> 	->end()
> 
> The underlying struct ethtool_ops remains unchanged; you're only
> changing the transit method.
> 
> Thus, the ethtool userspace utility would switch entirely to
> netlink, while the ioctl processing code remains for binary
> compatibility.
> 
> Or... ethtool userspace utility could remain unchanged, and a new
> 'nictool' utility provides the same features but with (a) a new CLI
> and (b) exclusively uses netlink rather than ioctl.

I actually have code for this including userspace. I never submitted
it because I wasn't confident it is the way to go since it literally
duplicates all ethtool code in the kernel.

There is one major problem with bundling multiple requests though. If
one change request fails but other changes have been committed already
we can't really undo them without causing lots of races. We have to
leave the device in a somewhat inconsistent state. It's even difficult
to tell what has been comitted and what hasn't. It also makes error
reporting more difficult as a -ERANGE error code could apply to any
of the values to be changed.

I tried to solve this by splitting the validate/change operation and
thus be able to validate all requests before starting to commit
them. This would mean changing all drivers though which I wasn't
willing to do.

I can clean up what I have and submit it so we have something to
start with.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html