* Re: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier
From: Ben Hutchings @ 2011-03-02 18:50 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Alexander Duyck, davem, jeffrey.t.kirsher, netdev
In-Reply-To: <AANLkTi=P0v1+h=TjC2j5k0zM-2BF22tbaoGpKBAjNd7-@mail.gmail.com>
On Fri, 2011-02-25 at 21:30 -0800, Alexander Duyck wrote:
> On Fri, Feb 25, 2011 at 5:00 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> > On Fri, 2011-02-25 at 15:32 -0800, Alexander Duyck wrote:
[...]
> >> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> >> index aac3e2e..3d1f8e0 100644
> >> --- a/include/linux/ethtool.h
> >> +++ b/include/linux/ethtool.h
> >> @@ -378,10 +378,25 @@ struct ethtool_usrip4_spec {
> >> };
> >>
> >> /**
> >> + * struct ethtool_ntuple_spec_ext - flow spec extension for ntuple in nfc
> >> + * @unused: space unused by extension
> >> + * @vlan_etype: EtherType for vlan tagged packet to match
> >> + * @vlan_tci: VLAN tag to match
> >> + * @data: Driver-dependent data to match
> >> + */
> >> +struct ethtool_ntuple_spec_ext {
> >> + __be32 unused[15];
> >> + __be16 vlan_etype;
> >> + __be16 vlan_tci;
> >> + __be32 data[2];
> >> +};
> > [...]
> >
> > This is a really nasty way to reclaim space in the union.
> >
> > Let's name the union, shrink it and insert the extra fields that way:
> >
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -377,27 +377,43 @@ struct ethtool_usrip4_spec {
> > __u8 proto;
> > };
> >
> > +union ethtool_flow_union {
> > + struct ethtool_tcpip4_spec tcp_ip4_spec;
> > + struct ethtool_tcpip4_spec udp_ip4_spec;
> > + struct ethtool_tcpip4_spec sctp_ip4_spec;
> > + struct ethtool_ah_espip4_spec ah_ip4_spec;
> > + struct ethtool_ah_espip4_spec esp_ip4_spec;
> > + struct ethtool_usrip4_spec usr_ip4_spec;
> > + struct ethhdr ether_spec;
> > + __u8 hdata[52];
> > +};
> > +
> > +struct ethtool_flow_ext {
> > + __be16 vlan_etype;
> > + __be16 vlan_tci;
> > + __be32 data[2];
> > + __u32 reserved[2];
> > +};
> > +
>
> Any chance of getting the reserved fields moved to the top of the
> structure? My only concern is that we might end up with a flow spec
> larger than 52 bytes at some point and moving the reserved fields to
> the front might give us a little more wiggle room future
> compatibility.
[...]
OK, so how about this:
/**
* union ethtool_flow_union - flow spec type-specific fields
* @tcp_ip4_spec: TCP/IPv4 fields to match
* @udp_ip4_spec: UDP/IPv4 fields to match
* @sctp_ip4_spec: SCTP/IPv4 fields to match
* @ah_ip4_spec: AH/IPv4 fields to match
* @esp_ip4_spec: ESP/IPv4 fields to match
* @usr_ip4_spec: User-defined IPv4 fields to match
* @ether_spec: Ethernet fields to match
*
* Note: The size of this union may shrink in future to allow for
* expansion in &struct ethtool_flow_ext.
*/
union ethtool_flow_union {
struct ethtool_tcpip4_spec tcp_ip4_spec;
struct ethtool_tcpip4_spec udp_ip4_spec;
struct ethtool_tcpip4_spec sctp_ip4_spec;
struct ethtool_ah_espip4_spec ah_ip4_spec;
struct ethtool_ah_espip4_spec esp_ip4_spec;
struct ethtool_usrip4_spec usr_ip4_spec;
struct ethhdr ether_spec;
__u8 hdata[60];
};
/**
* struct ethtool_flow_ext - flow spec common extension fields
* @vlan_etype: EtherType for vlan tagged packet to match
* @vlan_tci: VLAN tag to match
* @data: Driver-dependent data to match
*
* Note: Additional fields may be inserted before @vlan_etype in future,
* but the offset of the existing fields within the containing structure
* (&struct ethtool_rx_flow_spec) will be stable.
*/
struct ethtool_flow_ext {
__be16 vlan_etype;
__be16 vlan_tci;
__be32 data[2];
};
Please can you check that these definitions won't affect the size of
struct ethtool_rx_flow_spec on i386 or x86-64?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: source route ignored in favor of local interface
From: Ben Greear @ 2011-03-02 18:55 UTC (permalink / raw)
To: Joe Buehler; +Cc: Chris Friesen, netdev
In-Reply-To: <4D6D49AE.2030303@cox.net>
On 03/01/2011 11:31 AM, Joe Buehler wrote:
>> If you really want to modify things, have you looked at your ip rules?
>> "ip ru" will dump them. Typically it looks something like
>>
>> 0: from all lookup local
>> 32766: from all lookup main
>> 32767: from all lookup default
>>
>> The last item in each row is the name of the routing table. As you can
>> see, the first rule is for local interfaces, and a later rule deals with
>> the main and default routing tables.
>>
>> You could move the local lookup to rule 1 and add in a new rule 0
>> specifically dealing with your situation.
>
> We have tried some variations on modifications to ip rules, but the
> kernel appears to treat rule 0 specially -- it cannot be deleted, for
> example. This results in the enforcing of local interfaces before
> source routes -- surely something that should be a policy decision, not
> hard-coded.
>
> Let me rephrase and ask: Does anyone know how to replace the priority 0
> rule?
You can do this on more modern kernels (2.6.36 and later definately works..not sure
about earlier).
ip rule add pref 512 lookup local
ip rule del pref 0 lookup local
Thanks,
Ben
>
> Joe Buehler
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier
From: Dimitrios Michailidis @ 2011-03-02 19:11 UTC (permalink / raw)
To: Ben Hutchings, Alexander Duyck
Cc: Alexander Duyck, davem, jeffrey.t.kirsher, netdev
In-Reply-To: <1299091805.2664.16.camel@bwh-desktop>
Ben Hutchings wrote:
> /**
> * struct ethtool_flow_ext - flow spec common extension fields
> * @vlan_etype: EtherType for vlan tagged packet to match
> * @vlan_tci: VLAN tag to match
> * @data: Driver-dependent data to match
> *
> * Note: Additional fields may be inserted before @vlan_etype in future,
> * but the offset of the existing fields within the containing structure
> * (&struct ethtool_rx_flow_spec) will be stable.
> */
> struct ethtool_flow_ext {
> __be16 vlan_etype;
> __be16 vlan_tci;
> __be32 data[2];
> };
I am wondering about the semantics of these vlan_* fields. Is vlan_etype the
Ethertype in the VLAN header or the type after it? Specifically, I am wondering
whether these fields are limited to VLANs or can work with general Ethertypes and the
2 bytes after them.
^ permalink raw reply
* RE: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier
From: Ben Hutchings @ 2011-03-02 19:27 UTC (permalink / raw)
To: Dimitrios Michailidis
Cc: Alexander Duyck, Alexander Duyck, davem, jeffrey.t.kirsher,
netdev
In-Reply-To: <8A71B368A89016469F72CD08050AD334091C1FAB@maui.asicdesigners.com>
On Wed, 2011-03-02 at 11:11 -0800, Dimitrios Michailidis wrote:
> Ben Hutchings wrote:
> > /**
> > * struct ethtool_flow_ext - flow spec common extension fields
> > * @vlan_etype: EtherType for vlan tagged packet to match
> > * @vlan_tci: VLAN tag to match
> > * @data: Driver-dependent data to match
> > *
> > * Note: Additional fields may be inserted before @vlan_etype in future,
> > * but the offset of the existing fields within the containing structure
> > * (&struct ethtool_rx_flow_spec) will be stable.
> > */
> > struct ethtool_flow_ext {
> > __be16 vlan_etype;
> > __be16 vlan_tci;
> > __be32 data[2];
> > };
>
> I am wondering about the semantics of these vlan_* fields. Is vlan_etype the
> Ethertype in the VLAN header or the type after it?
It would be the the type in the VLAN tag. The nested ethertype is
normally implied by flow_type to be ETH_P_IP.
This does leave the question of what this would mean:
struct ethtool_rx_flow_spec fs = {
.flow_type = ... | FLOW_EXT,
...
.h_ext.vlan_tci = htons(0x1234),
.m_ext.vlan_etype = 0xffff,
};
This says the TCI must be == 0x1234 but the type can be anything. But
the type surely has to be be one assigned for use in VLAN tags. Should
we leave it to the driver/hardware to determine what those valid types
are, or should we reject this as valid?
> Specifically, I am wondering
> whether these fields are limited to VLANs or can work with general Ethertypes and the
> 2 bytes after them.
If you set flow_type = ETHER_FLOW you can then specify any combination
of Ethernet header fields to match in {h_u,m_u}.ether_spec. However, so
far only sfc implements it and it only allows matching on the
destination MAC address.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 0/2] netfilter: netfilter fixes for 2.6.38
From: David Miller @ 2011-03-02 19:29 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1299066981-14058-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Wed, 2 Mar 2011 12:56:19 +0100
> the following patches fix two IPVS/netfilter bugs:
>
> - incorrect locking in __ip_vs_update_dest(), from Julian
>
> - a potential oops when binding or unbinding an invalid address family
> through nfnetlink_log, from Jan
>
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks a lot Patrick.
^ permalink raw reply
* Re: [PATCH 00/13] netfilter: netfilter update
From: David Miller @ 2011-03-02 19:30 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1299067973-15977-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Wed, 2 Mar 2011 13:12:40 +0100
> following is a netfilter update for net-next, containing:
>
> - minor cleanups and bugfixes
>
> - a fix for a bridge netfilter information leak, from Vasiliy Kulikov
>
> - IPVS timer fixes, from Tinggong Wang
>
> - conversion of the IPVS hash table to hlists, from Changli
>
> - TCP conntrack improvements, from Pablo
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Also pulled, thanks!
^ permalink raw reply
* Re: [PATCH] via-rhine: do not abort due to invalid MAC address
From: David Miller @ 2011-03-02 19:36 UTC (permalink / raw)
To: mr.nuke.me; +Cc: florian, rl, netdev
In-Reply-To: <4D6E883C.2000800@gmail.com>
From: "Alex G." <mr.nuke.me@gmail.com>
Date: Wed, 02 Mar 2011 20:11:08 +0200
> On 03/02/2011 08:01 PM, Florian Fainelli wrote:
>>
>> Why not generate a valid random ethernet address using random_ether_addr()
>> instead?
>
> That would confuse ifcfg-* scripts that specify HWETHER, and probably
> users as well. It might even stump udev.
If the ethernet address reported by the card is garbage, every single
ethernet driver that tried to handle this case uses a random ethernet
address.
There is no reason to choose a different strategy for this driver.
Also registering a network device with an invalid ethernet address can
cause all kinds of serious issues, let's say dhcp brings the device
up and emits DHCP requests with illegal MAC addresses in the header
because of this problem.
You therefore simply cannot leave crap in there.
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Jake Edge @ 2011-03-02 19:39 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm
In-Reply-To: <20110301213313.GA6507@albatros>
I am probably missing something, but shouldn't the existing
MODULE_ALIASes stay?
Vasiliy Kulikov <segoon@openwall.com> writes:
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 6613edf..d1d0e2c 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -1765,4 +1765,4 @@ module_exit(ipgre_fini);
> MODULE_LICENSE("GPL");
> MODULE_ALIAS_RTNL_LINK("gre");
> MODULE_ALIAS_RTNL_LINK("gretap");
> -MODULE_ALIAS("gre0");
> +MODULE_ALIAS_NETDEV("gre0");
that is, instead of replacing MODULE_ALIAS("gre0") with the NETDEV
version, don't you want both for backward compatibility?
(if so, same goes for the other two)
jake
--
Jake Edge - jake@lwn.net - http://lwn.net
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Vasiliy Kulikov @ 2011-03-02 19:43 UTC (permalink / raw)
To: Jake Edge
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm
In-Reply-To: <m34o7ltipi.fsf@lwn.net>
On Wed, Mar 02, 2011 at 12:39 -0700, Jake Edge wrote:
> > @@ -1765,4 +1765,4 @@ module_exit(ipgre_fini);
> > MODULE_LICENSE("GPL");
> > MODULE_ALIAS_RTNL_LINK("gre");
> > MODULE_ALIAS_RTNL_LINK("gretap");
> > -MODULE_ALIAS("gre0");
> > +MODULE_ALIAS_NETDEV("gre0");
>
> that is, instead of replacing MODULE_ALIAS("gre0") with the NETDEV
> version, don't you want both for backward compatibility?
The networking script will run with CAP_NET_ADMIN, this would request
netdev-gre0 and load ip_gre.
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Jake Edge @ 2011-03-02 19:49 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm
In-Reply-To: <20110302194354.GA31043@albatros>
On Wed, 2 Mar 2011 22:43:54 +0300 Vasiliy Kulikov wrote:
> On Wed, Mar 02, 2011 at 12:39 -0700, Jake Edge wrote:
> > > @@ -1765,4 +1765,4 @@ module_exit(ipgre_fini);
> > > MODULE_LICENSE("GPL");
> > > MODULE_ALIAS_RTNL_LINK("gre");
> > > MODULE_ALIAS_RTNL_LINK("gretap");
> > > -MODULE_ALIAS("gre0");
> > > +MODULE_ALIAS_NETDEV("gre0");
> >
> > that is, instead of replacing MODULE_ALIAS("gre0") with the NETDEV
> > version, don't you want both for backward compatibility?
>
> The networking script will run with CAP_NET_ADMIN, this would request
> netdev-gre0 and load ip_gre.
and on systems that today use CAP_SYS_MODULE (or really the full set of
capabilities cuz they are running as root)? won't those try to load
gre0 and fail because that alias doesn't exist?
jake
--
Jake Edge - LWN - jake@lwn.net - http://lwn.net
^ permalink raw reply
* Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
From: "Oleg A. Arkhangelsky" @ 2011-03-02 19:50 UTC (permalink / raw)
To: Changli Gao; +Cc: Patrick McHardy, netfilter-devel, netdev, Paul E McKenney
In-Reply-To: <AANLkTikkz23221ZSiat8N5tnE_bkHN=1EUNQTDdnC30L@mail.gmail.com>
02.03.2011, 17:37, "Changli Gao" <xiaosuo@gmail.com>:
> t should be NULL here, as offsetof(struct nf_conn, dst.protonum) == 0x36.
> We should free the nf_ct_extend with call_rcu(), since nat ext is
> referenced in the rcu read context.
Yes, I think the problem is triggered when nf_conntrack_free() is called by
different CPU during net->ipv4.nat_bysource hash traversal. Extensions
framework doesn't have any SLAB_DESTROY_BY_RCU magic.
I'm not sure, but couldn't this problem be introduced by:
ea781f197d6a835cbb93a0bf88ee1696296ed8aa
netfilter: nf_conntrack: use SLAB_DESTROY_BY_RCU and get rid of call_rcu()
?
--
wbr, Oleg.
^ permalink raw reply
* Re: [PATCH] iproute2: add support of flag XFRM_STATE_ALIGN4
From: Stephen Hemminger @ 2011-03-02 19:50 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4D6E87AF.8090204@6wind.com>
On Wed, 02 Mar 2011 19:08:47 +0100
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Hi,
>
> please find the patch enclosed.
>
>
> Regards,
> Nicolas
applied to net-next branch.
--
^ permalink raw reply
* Re: [PATCH] via-rhine: do not abort due to invalid MAC address
From: Roger Luethi @ 2011-03-02 19:52 UTC (permalink / raw)
To: David Miller; +Cc: mr.nuke.me, florian, netdev
In-Reply-To: <20110302.113610.71137356.davem@davemloft.net>
On Wed, 02 Mar 2011 11:36:10 -0800, David Miller wrote:
> From: "Alex G." <mr.nuke.me@gmail.com>
> Date: Wed, 02 Mar 2011 20:11:08 +0200
>
> > On 03/02/2011 08:01 PM, Florian Fainelli wrote:
> >>
> >> Why not generate a valid random ethernet address using random_ether_addr()
> >> instead?
> >
> > That would confuse ifcfg-* scripts that specify HWETHER, and probably
> > users as well. It might even stump udev.
>
> If the ethernet address reported by the card is garbage, every single
> ethernet driver that tried to handle this case uses a random ethernet
> address.
>
> There is no reason to choose a different strategy for this driver.
Fair enough. I did not know other drivers had already dealt with the same
problem. My bad. Alex, can you redo the patch accordingly?
^ permalink raw reply
* Re: [PATCH] via-rhine: do not abort due to invalid MAC address
From: Alex G. @ 2011-03-02 19:49 UTC (permalink / raw)
To: Roger Luethi; +Cc: David Miller, florian, netdev
In-Reply-To: <20110302195205.GA15190@core.hellgate.ch>
On 03/02/2011 09:52 PM, Roger Luethi wrote:
> On Wed, 02 Mar 2011 11:36:10 -0800, David Miller wrote:
>> There is no reason to choose a different strategy for this driver.
>
> Fair enough. I did not know other drivers had already dealt with the same
> problem. My bad. Alex, can you redo the patch accordingly?
Yes, no problem.
Alex
^ permalink raw reply
* RE: [net-next-2.6 PATCH 02/10] ethtool: add ntuple flow specifier to network flow classifier
From: Dimitrios Michailidis @ 2011-03-02 20:03 UTC (permalink / raw)
To: Ben Hutchings
Cc: Alexander Duyck, Alexander Duyck, davem, jeffrey.t.kirsher,
netdev
In-Reply-To: <1299094046.2664.31.camel@bwh-desktop>
Ben Hutchings wrote:
> On Wed, 2011-03-02 at 11:11 -0800, Dimitrios Michailidis wrote:
> > Ben Hutchings wrote:
> > > /**
> > > * struct ethtool_flow_ext - flow spec common extension fields
> > > * @vlan_etype: EtherType for vlan tagged packet to match
> > > * @vlan_tci: VLAN tag to match
> > > * @data: Driver-dependent data to match
> > > *
> > > * Note: Additional fields may be inserted before @vlan_etype in future,
> > > * but the offset of the existing fields within the containing structure
> > > * (&struct ethtool_rx_flow_spec) will be stable.
> > > */
> > > struct ethtool_flow_ext {
> > > __be16 vlan_etype;
> > > __be16 vlan_tci;
> > > __be32 data[2];
> > > };
> >
> > I am wondering about the semantics of these vlan_* fields. Is vlan_etype the
> > Ethertype in the VLAN header or the type after it?
>
> It would be the the type in the VLAN tag. The nested ethertype is
> normally implied by flow_type to be ETH_P_IP.
>
> This does leave the question of what this would mean:
>
> struct ethtool_rx_flow_spec fs = {
> .flow_type = ... | FLOW_EXT,
> ...
> .h_ext.vlan_tci = htons(0x1234),
> .m_ext.vlan_etype = 0xffff,
> };
>
> This says the TCI must be == 0x1234 but the type can be anything. But
> the type surely has to be be one assigned for use in VLAN tags. Should
> we leave it to the driver/hardware to determine what those valid types
> are, or should we reject this as valid?
Right. Devices have some internal rules for what qualifies as a VLAN frame.
If users are given the option to specify vlan_etype what do they get?
At least we need to specify what is expected so drivers can decide if they can support it.
^ permalink raw reply
* Re: [PATCH] via-rhine: do not abort due to invalid MAC address
From: Alex G. @ 2011-03-02 20:06 UTC (permalink / raw)
To: Roger Luethi; +Cc: David Miller, florian, netdev
In-Reply-To: <20110302195205.GA15190@core.hellgate.ch>
[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
---
On 03/02/2011 09:52 PM, Roger Luethi wrote:
> Alex, can you redo the patch accordingly?
Done and tested.
[root@nukeserv2 mrnuke]# rmmod via-rhine
[root@nukeserv2 mrnuke]# insmod via-rhine.ko
[28234.938404] via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
[28234.945186] via-rhine: Invalid MAC address: ef:9f:e9:f7:f7:f7.
[28234.945518] via-rhine: Using randomly generated address:
02:0f:c4:98:a6:fd instead.
[28234.948793] eth1: VIA Rhine II at 0xfaa00000, 02:0f:c4:98:a6:fd, IRQ 23.
[28234.950223] eth1: MII PHY found at address 1, status 0x7849
advertising 01e1 Link 0000.
[root@nukeserv2 mrnuke]# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 02:0F:C4:98:A6:FD
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:23
[-- Attachment #2: rhine.patch --]
[-- Type: text/x-patch, Size: 987 bytes --]
diff --git a/linux-2.6.35.11/drivers/net/via-rhine.c b/via-rhine.c
index 4930f9d..4c1b9e7 100644
--- a/linux-2.6.35.11/drivers/net/via-rhine.c
+++ b/via-rhine.c
@@ -762,13 +762,16 @@ static int __devinit rhine_init_one(struct pci_dev *pdev,
for (i = 0; i < 6; i++)
dev->dev_addr[i] = ioread8(ioaddr + StationAddr + i);
- memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
- if (!is_valid_ether_addr(dev->perm_addr)) {
- rc = -EIO;
- printk(KERN_ERR "Invalid MAC address\n");
- goto err_out_unmap;
+ if (!is_valid_ether_addr(dev->dev_addr)) {
+ printk(KERN_ERR "via-rhine: Invalid MAC address: %pM. \n",
+ dev->dev_addr);
+ /* The device may still be used normally if a valid MAC is configured */
+ random_ether_addr(dev->dev_addr);
+ printk(KERN_ERR "via-rhine: Using randomly generated address: %pM instead. \n",
+ dev->dev_addr);
}
+ memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
/* For Rhine-I/II, phy_id is loaded from EEPROM */
if (!phy_id)
^ permalink raw reply related
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Vasiliy Kulikov @ 2011-03-02 20:18 UTC (permalink / raw)
To: Jake Edge
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm
In-Reply-To: <20110302124936.289a1915@chukar>
On Wed, Mar 02, 2011 at 12:49 -0700, Jake Edge wrote:
> On Wed, 2 Mar 2011 22:43:54 +0300 Vasiliy Kulikov wrote:
> > On Wed, Mar 02, 2011 at 12:39 -0700, Jake Edge wrote:
> > > > @@ -1765,4 +1765,4 @@ module_exit(ipgre_fini);
> > > > MODULE_LICENSE("GPL");
> > > > MODULE_ALIAS_RTNL_LINK("gre");
> > > > MODULE_ALIAS_RTNL_LINK("gretap");
> > > > -MODULE_ALIAS("gre0");
> > > > +MODULE_ALIAS_NETDEV("gre0");
> > >
> > > that is, instead of replacing MODULE_ALIAS("gre0") with the NETDEV
> > > version, don't you want both for backward compatibility?
> >
> > The networking script will run with CAP_NET_ADMIN, this would request
> > netdev-gre0 and load ip_gre.
>
> and on systems that today use CAP_SYS_MODULE
Since Linux 2.6.32 CAP_SYS_MODULE may not load modules via "ifconfig
gre0". It was changed to CAP_NET_ADMIN. So nothing is broken here.
> (or really the full set of
> capabilities cuz they are running as root)?
As root has CAP_NET_ADMIN, the alias netdev-gre0 is tried and it succeeds.
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Chris Friesen @ 2011-03-02 20:25 UTC (permalink / raw)
To: Mikael Abrahamsson
Cc: Eric Dumazet, Albert Cahalan, David Miller, johnwheffner,
linville, jussi.kivilinna, linux-kernel, netdev
In-Reply-To: <alpine.DEB.1.10.1103020358010.7942@uplift.swm.pp.se>
On 03/01/2011 09:10 PM, Mikael Abrahamsson wrote:
> For the case when we're ourselves originating the traffic (for instance to
> a wifi card with varying speed and jitter due to retransmits on the wifi
> layer), I think it's taking the too easy way out to use the same
> mechanisms (dropping packets or marking ECN for our own originated packets
> seems really weird), here we should be able to pushback information to the
> applications somehow and do prioritization between flows since we're
> sitting on all information ourselves including the application.
Doesn't the socket tx buffer give all the app pushback necessary?
(Assuming it's set to a sane value.)
We should certainly do prioritization between flows. Perhaps if no
other information is available the scheduler priority could be used?
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: [PATCH net-2.6] bonding: drop frames received with master's source MAC
From: Nicolas de Pesloüan @ 2011-03-02 20:26 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Andy Gospodarek, netdev, David Miller, Herbert Xu, Jiri Pirko
In-Reply-To: <4D6D7C66.6050205@gmail.com>
Le 02/03/2011 00:08, Nicolas de Pesloüan a écrit :
[snip]
> Can we imagine that, at the time we change the bonding mode to -rr or
> -xor, we simply brodcast or multicast one or two frames with some random
> data and wait to see whether we receive the frame back? If we receive at
> least one frame with the same random data, in one of the slaves
> interface for this bonding, we know for sure the switch configuration is
> not "multicast loop safe". Bonding already send ARP requests/replies in
> many situations. Adding one broadcast/multicast frame at bond setup time
> is probably acceptable.
>
> And to ensure consistent results, we need to send such
> broadcast/multicast every time the link goes up for an already enslaved
> slave. This is not perfect, as the switch topology may change in a way
> that won't be detected by bonding, but still cause a new multicast loop,
> but...
>
> Knowing the switch configuration is not "multicast loop safe", we can,
> at a minimum, issue a warning, telling the user she should expect
> strange behaviors, like false duplicate address detection.
>
> And we can probably use this information into the should-drop logic, for
> mode that lack "inactive" slaves.
>
Still thinking about it:
We should drop the frame if :
the bonding interface is in -rr or -xor mode,
and we know the switch topology in front of our slaves is not "multicast
loop safe" (see above).
and the source MAC is the MAC of the bonding interface
and the destination MAC is a multicast one.
That being said, I wonder if this is only bonding related.
If one decide to configure two interfaces with the same MAC and connect
them to the same LAN, then we get the exact same situation. Having eth0
and eth1 share a single MAC and a single IP address, connected to a
switch in Etherchannel mode is a perfectly valid setup, while
suboptimal. And if the Etherchannel mode happens to be improperly
configured, we end up with the same problem as reported by Andy.
Nicolas.
[ Resent, because netdev ML didn't get it the first time ]
^ permalink raw reply
* Re: [PATCH net-2.6] bonding: drop frames received with master's source MAC
From: Nicolas de Pesloüan @ 2011-03-02 20:30 UTC (permalink / raw)
To: Herbert Xu
Cc: Jay Vosburgh, Andy Gospodarek, netdev, David Miller, Jiri Pirko
In-Reply-To: <20110302123004.GA21002@gondor.apana.org.au>
Le 02/03/2011 13:30, Herbert Xu a écrit :
> On Wed, Mar 02, 2011 at 11:10:07AM +0100, Nicolas de Pesloüan wrote:
>>
>> If one decide to configure two interfaces with the same MAC and connect them
>> to the same LAN, then we get the exact same situation. Having eth0 and eth1
>> share a single MAC and a single IP address, connected to a switch in
>> Etherchannel mode is a perfectly valid setup, while suboptimal. And if the
>> Etherchannel mode happens to be improperly configured, we end up with the
>> same problem as reported by Andy.
>
> Right. There's also the case where you have other MAC addresses
> sitting behind the bonding device, e.g., virtualisation. So basing
> it purely on the bonding device's MAC address is probably not worth
> the trouble.
>
> Cheers,
I'm afraid we miss a general way to fix the general problem. We probably need to handle the problem
at every places that can suffer from the multicast loop, until we find a general fix, if ever.
Nicolas.
^ permalink raw reply
* Re: [PATCH 0/7] Final BKL removal, take 2
From: Mauro Carvalho Chehab @ 2011-03-02 20:32 UTC (permalink / raw)
To: Greg KH
Cc: Arnd Bergmann, linux-kernel, Andi Kleen, Andrew Hendry,
Arnaldo Carvalho de Melo, David Miller, Eric Dumazet,
Evgeniy Dushistov, linux-fsdevel, linux-x25, Max Vozeler,
Mikulas Patocka, netdev, Nick Bowler, Nick Piggin,
Palash Bandyopadhyay, Takahiro Hirofuchi
In-Reply-To: <20110302140428.GA630@suse.de>
Em 02-03-2011 11:04, Greg KH escreveu:
> On Wed, Mar 02, 2011 at 08:32:15AM -0300, Mauro Carvalho Chehab wrote:
>> Em 02-03-2011 01:59, Greg KH escreveu:
>>> On Wed, Mar 02, 2011 at 12:13:04AM +0100, Arnd Bergmann wrote:
>>>> This is the set of patches that remain from
>>>> my previous submission one month ago. I've
>>>> dropped the ones that have either gone into
>>>> linux-next or got a sufficient number of
>>>> Acked-by:s so I put them into my own tree.
>>>>
>>>> I've updated the usbip, hpfs, ufs and appletalk
>>>> patches according to the feedback I got.
>>>>
>>>> If possible, I'd like the three networking patches
>>>> to go through the net-next tree, and the two
>>>> staging patches through the staging tree. I'll
>>>> add the other ones to my own series if I hear
>>>> no objections.
>>>
>>> I'll queue up the staging patches in the staging-next tree in a day or
>>> so, thanks for digging them up.
>>
>> Greg,
>>
>> It is probably better to queue the staging/cx25821 patch via my tree, as this is one
>> of those staging files that it is handled via media tree. So, if it is ok
>> for you both, I'll get patch 2/7.
>
> Yes, you are right, please take it through your tree.
Patch applied on my tree, thanks!
Mauro
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Jake Edge @ 2011-03-02 20:38 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm
In-Reply-To: <20110302201807.GA31965@albatros>
On Wed, 2 Mar 2011 23:18:07 +0300 Vasiliy Kulikov wrote:
> > and on systems that today use CAP_SYS_MODULE
>
> Since Linux 2.6.32 CAP_SYS_MODULE may not load modules via "ifconfig
> gre0". It was changed to CAP_NET_ADMIN. So nothing is broken here.
>
> > (or really the full set of
> > capabilities cuz they are running as root)?
>
> As root has CAP_NET_ADMIN, the alias netdev-gre0 is tried and it
> succeeds.
(I feel like I'm beating a dead horse here, sorry if so ...)
If I have a setuid-root program today that loads ip_gre by using the
alias "gre0", and I run that program on a kernel with this change,
won't it fail because the "gre0" alias is missing? That program
doesn't know to try "netdev-gre0". i.e. won't backward compatibility be
affected by this change?
jake
--
Jake Edge - LWN - jake@lwn.net - http://lwn.net
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Jake Edge @ 2011-03-02 20:40 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, kees.cook, eugene,
dan.j.rosenberg, akpm
In-Reply-To: <20110302201807.GA31965@albatros>
On Wed, 2 Mar 2011 23:18:07 +0300 Vasiliy Kulikov wrote:
> As root has CAP_NET_ADMIN, the alias netdev-gre0 is tried and it
> succeeds.
Never mind, my apologies for the noise ... one always reads replies
most carefully just *after* hitting send ...
jake
--
Jake Edge - LWN - jake@lwn.net - http://lwn.net
^ permalink raw reply
* [net-2.6 PATCH] net: dcbnl: check correct ops in dcbnl_ieee_set()
From: John Fastabend @ 2011-03-02 20:35 UTC (permalink / raw)
To: netdev; +Cc: john.r.fastabend, davem, shmulikr
The incorrect ops routine was being tested for in
DCB_ATTR_IEEE_PFC attributes. This patch corrects
it.
Currently, every driver implementing ieee_setets also
implements ieee_setpfc so this bug is not actualized
yet.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/dcb/dcbnl.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index d5074a5..c44348a 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1193,7 +1193,7 @@ static int dcbnl_ieee_set(struct net_device *netdev, struct nlattr **tb,
goto err;
}
- if (ieee[DCB_ATTR_IEEE_PFC] && ops->ieee_setets) {
+ if (ieee[DCB_ATTR_IEEE_PFC] && ops->ieee_setpfc) {
struct ieee_pfc *pfc = nla_data(ieee[DCB_ATTR_IEEE_PFC]);
err = ops->ieee_setpfc(netdev, pfc);
if (err)
^ permalink raw reply related
* Re: [patch net-next-2.6] bonding: remove skb_share_check in handle_frame
From: Nicolas de Pesloüan @ 2011-03-02 20:47 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Andy Gospodarek, netdev, davem, fubar, eric.dumazet
In-Reply-To: <20110302100354.GB2858@psychotron.brq.redhat.com>
Le 02/03/2011 11:03, Jiri Pirko a écrit :
> Tue, Mar 01, 2011 at 09:38:43PM CET, andy@greyhouse.net wrote:
>> On Tue, Mar 01, 2011 at 10:29:07AM +0100, Jiri Pirko wrote:
>>> Unapplicable, sorry (wrong branch :(). Here's corrected patch:
>>>
>>> Subject: [PATCH net-next-2.6 v2] bonding: remove skb_share_check in handle_frame
>>>
>>> No need to do share check here.
>>>
>>> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
>>> ---
>>> drivers/net/bonding/bond_main.c | 3 ---
>>> 1 files changed, 0 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>>> index 584f97b..367ea60 100644
>>> --- a/drivers/net/bonding/bond_main.c
>>> +++ b/drivers/net/bonding/bond_main.c
>>> @@ -1498,9 +1498,6 @@ static struct sk_buff *bond_handle_frame(struct sk_buff *skb)
>>> struct net_device *slave_dev;
>>> struct net_device *bond_dev;
>>>
>>> - skb = skb_share_check(skb, GFP_ATOMIC);
>>> - if (unlikely(!skb))
>>> - return NULL;
>>> slave_dev = skb->dev;
>>> bond_dev = ACCESS_ONCE(slave_dev->master);
>>> if (unlikely(!bond_dev))
>>> --
>>> 1.7.3.4
>>>
>>
>> Why did you decide to get rid of it here rather than the 3 places in the
>> bonding driver where it is currently needed? I think this can cover
>> those cases since bond_handle_frame will be called after the ptype_all
>> handlers before any of the ptype handlers.
>
> I have already a patch prepared which converts bond ptype handlers into
> being called from bond_handle_frame. You are propably right that this
> should probably stay here.
Hi Jiri,
Do you plan to call the bonding ARP handler from inside bond_handle_frame()?
A few days ago (http://marc.info/?l=linux-netdev&m=129883949022340&w=2), I noticed that it is not
possible to call the bonding ARP handler from inside the bonding rx_handler, because some frame
processing may be required after the bonding rx_handler call, to put the frame in a suitable state
for the bonding ARP handler.
This is at least true with the following setup, eth0 -> bond0 -> bond0.100, where the ARP frames are
VLAN tagged at the time the bonding rx_handler process them.
Nicolas.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox