* 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 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 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 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: 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 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: [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: [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 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: [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] 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: 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 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: [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: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] 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 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 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: [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: [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: 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: 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
* [PATCH] e1000: fix race condition while driver unload/reset using kref count
From: prasanna.panchamukhi @ 2011-03-02 18:46 UTC (permalink / raw)
To: bruce.w.allan, jeffrey.t.kirsher, jesse.brandeburg,
jeffrey.e.pieper
Cc: e1000-devel, netdev, prasanna.panchamukhi
This race conditions occurs with reentrant e1000_down(), which gets
called by multiple threads while driver unload or reset.
This patch fixes the race condition when one thread tries to destroy
the memory allocated for tx buffer_info, while another thread still
happen to access tx buffer_info.
This patch fixes the above race condition using kref count.
Signed-off-by: Prasanna S. Panchamukhi <prasanna.panchamukhi@riverbed.com>
---
drivers/net/e1000/e1000.h | 2 +
drivers/net/e1000/e1000_main.c | 41 +++++++++++++++++++++++++++++++++++++--
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index a881dd0..36f55b3 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -168,6 +168,8 @@ struct e1000_tx_ring {
unsigned int next_to_clean;
/* array of buffer information structs */
struct e1000_buffer *buffer_info;
+ spinlock_t bufinfo_lock; /* protect access to buffer_info */
+ struct kref bufinfo_refcount; /* refcount access to buffer info */
u16 tdh;
u16 tdt;
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index beec573..336d3e1 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1531,6 +1531,8 @@ setup_tx_desc_die:
txdr->next_to_use = 0;
txdr->next_to_clean = 0;
+ spin_lock_init(&txdr->bufinfo_lock);
+ kref_init(&txdr->bufinfo_refcount);
return 0;
}
@@ -1880,6 +1882,22 @@ static void e1000_configure_rx(struct e1000_adapter *adapter)
ew32(RCTL, rctl);
}
+/*
+ * Free tx buffer info resources, only when no other thread is
+ * accessing it. Access to buffer_info is refcounted by bufinfo_refcount,
+ * hence memory allocated must be destroyed when bufinfo_refcount
+ * becomes zero. This routine gets executed when bufinfo_refcount
+ * becomes zero.
+ */
+static void e1000_free_tx_buffer_info(struct kref *ref)
+{
+ struct e1000_tx_ring *tx_ring =
+ container_of(ref, struct e1000_tx_ring, bufinfo_refcount);
+
+ vfree(tx_ring->buffer_info);
+ tx_ring->buffer_info = NULL;
+}
+
/**
* e1000_free_tx_resources - Free Tx Resources per Queue
* @adapter: board private structure
@@ -1895,8 +1913,9 @@ static void e1000_free_tx_resources(struct e1000_adapter *adapter,
e1000_clean_tx_ring(adapter, tx_ring);
- vfree(tx_ring->buffer_info);
- tx_ring->buffer_info = NULL;
+ spin_lock(&tx_ring->bufinfo_lock);
+ kref_put(&tx_ring->bufinfo_refcount, e1000_free_tx_buffer_info);
+ spin_unlock(&tx_ring->bufinfo_lock);
dma_free_coherent(&pdev->dev, tx_ring->size, tx_ring->desc,
tx_ring->dma);
@@ -1954,8 +1973,20 @@ static void e1000_clean_tx_ring(struct e1000_adapter *adapter,
unsigned long size;
unsigned int i;
- /* Free all the Tx ring sk_buffs */
+ spin_lock(&tx_ring->bufinfo_lock);
+ /*
+ * Check buffer_info is not NULL, and
+ * increment the refcount to prevent
+ * the buffer getting freed underneath.
+ */
+ if (tx_ring->buffer_info == NULL) {
+ spin_unlock(&tx_ring->bufinfo_lock);
+ return;
+ }
+ kref_get(&tx_ring->bufinfo_refcount);
+ spin_unlock(&tx_ring->bufinfo_lock);
+ /* Free all the Tx ring sk_buffs */
for (i = 0; i < tx_ring->count; i++) {
buffer_info = &tx_ring->buffer_info[i];
e1000_unmap_and_free_tx_resource(adapter, buffer_info);
@@ -1968,6 +1999,10 @@ static void e1000_clean_tx_ring(struct e1000_adapter *adapter,
memset(tx_ring->desc, 0, tx_ring->size);
+ spin_lock(&tx_ring->bufinfo_lock);
+ kref_put(&tx_ring->bufinfo_refcount, e1000_free_tx_buffer_info);
+ spin_unlock(&tx_ring->bufinfo_lock);
+
tx_ring->next_to_use = 0;
tx_ring->next_to_clean = 0;
tx_ring->last_tx_tso = 0;
--
1.7.0.4
^ permalink raw reply related
* Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy
From: Daniel Lezcano @ 2011-03-02 18:33 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Andrian Nord, lxc-users, Linux Netdev List
In-Reply-To: <4D6E8686.3000109@trash.net>
On 03/02/2011 07:03 PM, Patrick McHardy wrote:
> Am 02.03.2011 17:03, schrieb Daniel Lezcano:
>> On 03/02/2011 12:03 PM, Patrick McHardy wrote:
>>> Am 01.03.2011 21:04, schrieb Daniel Lezcano:
>>>> On 03/01/2011 05:51 PM, Patrick McHardy wrote:
>>>>>> Patrick, do you have any suggestions to fix this ?
>>>>> Since the frames are only looped back locally, I suppose the easiest
>>>>> fix would be to mark them with CHECKSUM_UNNECESSARY. Alternatively
>>>>> we need to complete the checksum manually, similar to what
>>>>> dev_hard_start_xmit() does.
>>>> That sounds very simple to fix, maybe too much simple :)
>>>>
>>>> I did the following change:
>>>>
>>>> --- linux-next.orig/drivers/net/macvlan.c
>>>> +++ linux-next/drivers/net/macvlan.c
>>>> @@ -222,6 +222,7 @@ static int macvlan_queue_xmit(struct sk_
>>>>
>>>> if (vlan->mode == MACVLAN_MODE_BRIDGE) {
>>>> const struct ethhdr *eth = (void *)skb->data;
>>>> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>>>>
>>>> /* send to other bridge ports directly */
>>>> if (is_multicast_ether_addr(eth->h_dest)) {
>>>>
>>>>
>>>> and that fixed the problem. Do you think it is acceptable ?
>>> The only problem I see is if the packets are bridged to a
>>> different networking device (or redirected using the mirred
>>> action), in this case the checksum will not be completed.
>>> This would be a very strange setup though and probably wouldn't
>>> be using dummy as lower device, so I'm not sure we have to
>>> worry about this case.
>> I am not sure to get it, do you say the patch is correct ?
> Its correct with a short-coming that doesn't seem to matter.
>
>> If my understanding is correct, the packet will be flagged
>> CHECKSUM_UNNECESSARY only for the macvlan devices, right ?
> Only for packets bridged between macvlan devices. A setup like
> the following would cause problems:
>
> br0
> |
> .----------.
> | |
> macvlan0 macvlan1 eth0
> | |
> -------.-------
> dummy0
>
> In this case packets sent from macvlan0 will show up on
> eth0 with incorrect setups. However this setup doesn't
> seem realistic to me, you would simply use eth0 instead
> of dummy0.
Ok, I understand. thanks for the clarification.
>> By the way, this problem occurs for any lower device with offloading
>> capabilities with a macvlan port in bridge mode.
> True. This doesn't affect outgoing packets since their checksum
> will be completed in dev_hard_start_xmit(), but it affects
> packets bridged between macvlans.
One last question. In the case of broadcast packets with maclvan in
bridge mode.
We will have the packets going through each macvlan port and also to the
lower-device, right ?
For the latter, don't we have a problem if the packet is flagged
CHECKSUM_UNNECESSARY ?
Shouldn't we restore the ip_summed field before sending through
dev_queue_xmit ?
---
drivers/net/macvlan.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-next/drivers/net/macvlan.c
===================================================================
--- linux-next.orig/drivers/net/macvlan.c
+++ linux-next/drivers/net/macvlan.c
@@ -222,10 +222,13 @@ static int macvlan_queue_xmit(struct sk_
if (vlan->mode == MACVLAN_MODE_BRIDGE) {
const struct ethhdr *eth = (void *)skb->data;
+ __u8 ip_summed = skb->ip_summed;
+ skb->ip_summed; = CHECKSUM_UNNECESSARY;
/* send to other bridge ports directly */
if (is_multicast_ether_addr(eth->h_dest)) {
macvlan_broadcast(skb, port, dev,
MACVLAN_MODE_BRIDGE);
+ skb->ip_summed = ip_summed;
goto xmit_world;
}
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Patrick McHardy @ 2011-03-02 18:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, Fabio Checconi, David Miller, Luigi Rizzo,
netdev
In-Reply-To: <1299087087.2920.27.camel@edumazet-laptop>
Am 02.03.2011 18:31, schrieb Eric Dumazet:
> Le mercredi 02 mars 2011 à 17:18 +0100, Eric Dumazet a écrit :
>> Le mercredi 02 mars 2011 à 08:11 -0800, Stephen Hemminger a écrit :
>>
>>> I put the iproute2 code into the repository in the experimental branch.
>>>
>>
>> Thanks
>>
>> It seems as soon as packets are dropped, qdisc is frozen (no more
>> packets dequeued)
>>
>> Hmm...
>>
>
> It seems class deletes are buggy.
>
> After one "tc class del dev $ETH classid 11:1 ..."
>
> a "tc -s -d qdisc show dev $ETH" triggers an Oops
What classes and filters did you have before issuing that command?
^ 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