netdev - Re: [ethtool PATCH] ethtool: Support n-tuple filter programming

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: <Pine.WNT.4.64.1002251739130.51452@ppwaskie-MOBL2.amr.corp.intel.com>
Date:	Thu, 25 Feb 2010 17:49:39 -0800 (Pacific Standard Time)
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	Jeff Garzik <jeff@...zik.org>, davem@...emloft.net
cc:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Subject: Re: [ethtool PATCH] ethtool: Support n-tuple filter programming

On Wed, 24 Feb 2010, Jeff Garzik wrote:

> On 02/04/2010 02:51 AM, Jeff Kirsher wrote:
> > From: Peter Waskiewicz<peter.p.waskiewicz.jr@...el.com>
> >
> > Program underlying ethernet devices with n-tuple flow classification
> > filters.
> >
> > This also adds a new flag to ethtool_flags, allowing n-tuple
> > programming to be toggled using the set_flags call.
> >
> > Signed-off-by: Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@...el.com>
> > Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@...el.com>
> > ---
> >
> >   ethtool-copy.h |   35 +++++++++++++
> >   ethtool.c      |  156 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> >   2 files changed, 186 insertions(+), 5 deletions(-)
> 
> applied, but two problems remain:
> 
> 1) you failed to document this in the man page.  I will expect a patch 
> to ethtool.8.
> 
> 2) you introduced a deviation from the upstream kernel ethtool.h:

The way I've come up with to fix this is less intrusive than I want, but I 
think it's right way to do it.  The intent wasn't to have ethtool 
(userspace) enforce how many filters could be returned.  What it should do 
is get the number of strings through drvinfo to make the proper memory 
allocation.

What I need to change is the drvinfo struct in the kernel to include the 
ethtool strings field, returned from get_sset_count().  Then I can pull 
that into userspace and make the correct memory allocation, then call 
get_rx_ntuple().

This will require a small kernel change.  Will something like this be 
pulled in at this point, given that 2.6.33 just released?

-PJ
--
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