* Re: [PATCH] atl1c: Add support for Atheros AR8152 and AR8152
From: David Miller @ 2010-02-16 23:16 UTC (permalink / raw)
To: lrodriguez
Cc: netdev, linux-kernel, espy, ken.wu, graham.richards, scott.tan,
mcgrof, chris.snook
In-Reply-To: <1265934812-14157-1-git-send-email-lrodriguez@atheros.com>
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
Date: Thu, 11 Feb 2010 19:33:32 -0500
> AR8151 is a Gigabit Ethernet device. AR8152 devices are
> Fast Ethernet devices, there are two revisions, a 1.0
> and a 2.0 revision.
>
> This has been tested against these devices:
>
> Driver Model-name vendor:device Type
> atl1c AR8131 1969:1063 Gigabit Ethernet
> atl1c AR8132 1969:1062 Fast Ethernet
> atl1c AR8151(v1.0) 1969:1073 Gigabit Ethernet
> atl1c AR8152(v1.1) 1969:2060 Fast Ethernet
>
> This device has no hardware available yet so it goes untested,
> but it should work:
>
> atl1c AR8152(v2.0) 1969:2062 Fast Ethernet
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] ethtool: allow non-admin user to read GRO settings.
From: David Miller @ 2010-02-16 23:15 UTC (permalink / raw)
To: shemminger; +Cc: herbert, netdev
In-Reply-To: <20100211154829.1b1a2039@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 11 Feb 2010 15:48:29 -0800
> Looks like an oversight in GRO design.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] be2net: set proper value to version field in req hdr
From: David Miller @ 2010-02-16 23:15 UTC (permalink / raw)
To: ajitk, ajitkhaparde; +Cc: netdev
In-Reply-To: <20100216101749.GA9465@serverengines.com>
From: Ajit Khaparde <ajitkhaparde@gmail.com>
Date: Tue, 16 Feb 2010 15:48:46 +0530
> Before sending a command to the ASIC, set version properly.
> This is necessary for the ARM firmware to send correct data to the driver.
> This also fixes a bug in certain skews of the ASIC where the statistics
> are misreported.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipcomp: double free at ipcomp_destroy()
From: David Miller @ 2010-02-16 23:14 UTC (permalink / raw)
To: herbert; +Cc: adobriyan, netdev
In-Reply-To: <20100216060051.GA27804@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 16 Feb 2010 14:00:51 +0800
> On Mon, Feb 15, 2010 at 04:08:46PM +0800, Herbert Xu wrote:
>>
>> Doh, I was looking at the buggy xfrm_state_clone path (which
>> incidently needs to be fixed to use xfrm_state_put).
>
> Here's a fix for that problem.
>
> xfrm: Fix xfrm_state_clone leak
>
> xfrm_state_clone calls kfree instead of xfrm_state_put to free
> a failed state. Depending on the state of the failed state, it
> can cause leaks to things like module references.
>
> All states should be freed by xfrm_state_put past the point of
> xfrm_init_state.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH] ipcomp: double free at ipcomp_destroy()
From: David Miller @ 2010-02-16 23:14 UTC (permalink / raw)
To: herbert; +Cc: adobriyan, netdev
In-Reply-To: <20100216052430.GA27643@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 16 Feb 2010 13:24:30 +0800
> On Mon, Feb 15, 2010 at 07:28:10PM +0200, Alexey Dobriyan wrote:
>>
>> OK, it survives beating here.
>
> Thanks a lot for testing! I'll do the clean-up you suggested in
> another patch. Let's get this fixed first.
>
> ipcomp: Avoid duplicate calls to ipcomp_destroy
>
> When ipcomp_tunnel_attach fails we will call ipcomp_destroy twice.
> This may lead to double-frees on certain structures.
>
> As there is no reason to explicitly call ipcomp_destroy, this patch
> removes it from ipcomp*.c and lets the standard xfrm_state destruction
> take place.
>
> This is based on the discovery and patch by Alexey Dobriyan.
>
> Tested-by: Alexey Dobriyan <adobriyan@gmail.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH] tunnels: fix netns vs proto registration ordering
From: David Miller @ 2010-02-16 23:14 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, security
In-Reply-To: <20100216190504.GA4801@x200>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Tue, 16 Feb 2010 21:05:04 +0200
> Same stuff as in ip_gre patch: receive hook can be called before netns
> setup is done, oopsing in net_generic().
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] gre: fix netns vs proto registration ordering
From: David Miller @ 2010-02-16 23:14 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, security
In-Reply-To: <20100216175744.GA4685@x200>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Tue, 16 Feb 2010 19:57:44 +0200
> GRE protocol receive hook can be called right after protocol addition is done.
> If netns stuff is not yet initialized, we're going to oops in
> net_generic().
>
> This is remotely oopsable if ip_gre is compiled as module and packet
> comes at unfortunate moment of module loading.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] SiS190/191 half-duplex initialization fix
From: David Miller @ 2010-02-16 22:47 UTC (permalink / raw)
To: birrachiara; +Cc: romieu, netdev
In-Reply-To: <1266265140-20196-1-git-send-email-birrachiara@tin.it>
From: Riccardo Ghetta <birrachiara@tin.it>
Date: Mon, 15 Feb 2010 21:19:00 +0100
> + u32 negotiated_lpa;
Uses spaces instead of tabs.
> + tp->negotiated_lpa = p->val;
Has a space then tabs, should be all tab characters.
> + if (tp->negotiated_lpa & (LPA_1000HALF | LPA_100HALF | LPA_10HALF))
> + {
Should be:
if (condition) {
ie. the openning brace need to be on the same line as the if
statement.
Please fix these issues up and resubmit your patch, thanks.
^ permalink raw reply
* Re: IPv6 autoconf/accept_ra default values - revisited
From: Kolbjørn Barmen @ 2010-02-16 21:58 UTC (permalink / raw)
To: Brian Haley; +Cc: Kolbjørn Barmen, Vlad Yasevich, davem, yoshfuji, netdev
In-Reply-To: <4B57359D.8090205@hp.com>
On Wed, 20 Jan 2010, Brian Haley wrote:
> Hi Kolbjorn,
Hello, thanks for answering, and I'm sorry that I havent replied earlier.
> Kolbjørn Barmen wrote:
> > Cheers, remember me? :)
> >
> > Regarding the autoconf parameter for the ipv6 module, was it not the
> > intention that it should cover accept_ra as well?
>
> It wasn't my intention, but I see how there's a bit of a mess here.
>
> > I ask since I have used this paramater in the belief that it also did
> > cover accept_ra, however on a couple of systems that are using bridge
> > interface, I noticed that they "fall off" ipv6-wise, unless I
> > explisitly ping them.
> >
> > So I finally got around to find out what was going on, and to my
> > surprise I see that they both have autoconfigured routes on eth0
> > (using link local) that they want to use instead of what I have
> > statically configured for br0.
>
> So I re-read RFCs 4861 and 4862 to see what the recommendation was here,
> and found this paragraph which I think explains what the Linux kernel is
> doing:
>
> [RFC 4861, Section 6.3.4]
>
> Note: Implementations can choose to process the on-link aspects of
> the prefixes separately from the stateless address
> autoconfiguration aspects of the prefixes by, e.g., passing a copy
> of each valid Router Advertisement message to both an "on-link"
> and an "addrconf" function. Each function can then operate
> independently on the prefixes that have the appropriate flag set.
>
> I'm guessing whoever wrote this code followed this suggestion for a
> reason.
>
> For a test, can you turno-off accept_ra/accept_ra_defrtr/accept_ra_pinfo
What are they, documented anywhere?
> and see if you can get the behavior you want?
I must admit that I havent tried using those yet, but still
I somehow managed to get what I want like this:
~ # cat /etc/modprobe.d/ipv6.conf
options ipv6 disable_ipv6=1 autoconf=0
~ # cat /etc/sysctl.d/ipv6.conf
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.lo.disable_ipv6=0
I'm still not convinced it really works, but it looks good so far.
> > So, could "autoconf" also please turn off accept_ra?
> > Or, if you like, add another parameter for it :P
>
> There are other things in the RA that are useful, like MTU, turning-off
> accept_ra would miss that
So what is one supposed to do when one wants fully statically configured
IPv6 addresses and routes? Or is that not supposed to be possible?
> I think maybe ignoring the prefix info options when autoconf=0 might be
> what you want. I guess we could do another module parameter if we had
> to.
Yes - all I want is ignore prefix and router announcements, they are not
to be trusted.
> > I tried using disable_ipv6 in all kinds of tricky ways to get what I want,
> > but it's close to impossble, with interfaces coming and going in the
> > bridge I always end up with autoconfigured addresses where I dont want
> > them, strange routing issues etc. I cannot just add entries in sysctl.conf
> > for bridge interfaces, since the bridge interfaces (and others for that
> > matter) are not there when sysctl is run on bootup.
>
> If you set "default.disable_ipv6=1" that should be inherited when a new
> interface is configured.
Right.
> > And the entire "all" vs. "default" still confuses me.
> >
> > * "default" is supposed to cover _all future_ interfaces?
> > * "all" is supposed to cover _all existing_ interfaces, and change them?
> > If not, then what is its function?
>
> Yes, "default" covers future interfaces, but "all" behavior depends on
> the option - "all->forwarding" and "all->disable_ipv6" will reset
> interfaces and "all->proxy_ndp" affects all interfaces. Other than
> that, the "all" variables seem not to be used. Making it more like the
> IPv4 code sooner than later might be a good thing, maybe others have
> thoughts on that?
I'd say yes, and the sooner the better.
(I've noticed the Debian has "Full IPv6 support" in their feature list for
next release this summer, it would be nice to have something ready for that.)
> > And lastly - all this would be a non-issue if the defaults values were so
> > that all autoconf/accept_ra were 0 - it's _so_ easy to turn on, but
> > incredibly complicated to turn off. The harder it is to make sense out of
> > things like this, the harder it is to have people start with IPv6.
>
> I don't think that default is going to change since it would effectively
> disable IPv6 for 99.9% of users, my grandmother would wonder why nothing works
> any more and not know how to fix it :) In other words, people not doing
> autoconfiguration are in the minority, and might need to change all these
> default settings, but we should make it easier to use.
Right, here it comes, the "most users" argument.
Sorry, but I just want to rant a little over this ;)
Your grandmother will be pretty fed up anyways since some random wifi
stumbler with 6to4 accidently turned on, jumps on her weakly configured
access point, announcing routes so that her computer now routes all
traffic through the stumblers laptop, which works fine till the stumbler
vanishes, leaving your grandmother's computer with lots of stalled TCP
sessions and a broken default gateway. Not to mention all the timeouts she
will have to wait for as her computer attempts to contact all the ipv6
addresses it resolves before finally, maybe, trying ipv4 instead.
I have worked with ipv6 in "production" long enough to know that the
overly optimistic view on how things are supposed to work is one of the
big obstacles for deployment of IPv6, it's just too fragile...
6to4 accidently activated on a machine on the LAN? Boom!
Loop between LANs as resault of accident plugging on switch? Boom!
Multihomed machine accidently forwards between interfaces? Boom!
And what do you do when suddenly you have heaploads of machiens with
nonworking IPv6 configurations? DHCPv6 to the rescue? Or not? :)
Not to mention all the IPv6 related bugs that exist in network gear
like controllers and gateways/bridges (wifi, VPN, whatever).
Ooops, I guess I just did. :)
Cheers!
-- kolla
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/7] xfrm: introduce basic mark infrastructure
From: Benny Amorsen @ 2010-02-16 21:56 UTC (permalink / raw)
To: hadi; +Cc: Patrick McHardy, timo.teras, herbert, davem, netdev
In-Reply-To: <1266326164.6776.263.camel@bigi>
jamal <hadi@cyberus.ca> writes:
> This is actually an interesting idea and is not far-fetched (and would
> certainly get rid of the replication problem). If i understood
> correctly, you would have:
> ip route add blah blah mark 0x10
Exactly.
> and that the routing core will use the mark to (as it does for example
> with ifindex) to pick the route? I like the idea for the simple fact it
> will reduce immensely configuration in some cases..
It would certainly be handy for me...
/Benny
^ permalink raw reply
* Re: [net-next PATCH v4 0/3] net: reserve ports for applications using fixed port
From: Octavian Purdila @ 2010-02-16 21:22 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Amerigo Wang, Eric Dumazet
In-Reply-To: <m1mxz93pw2.fsf@fess.ebiederm.org>
On Tuesday 16 February 2010 22:08:13 you wrote:
> > Something like bellow?
> >
> > # set bits 8080 and 1666
> > $echo 8080 1666-1666 > /proc
> >
> > #reset bit 1666
> > $echo 8080 > /proc
> >
> > #reset whole bitmap
> > $echo > /proc
>
> Yes. So something like that.
>
> I think I would use commas instead of spaces as that is more traditional.
>
OK, I was trying to reuse the existing skip whitespace code :) but if you
think its cleaner with commas I can do that.
> > Note that this new proc entry will work in conjunction with the existing
> > ip_local_port_range option, so the default bitmap can (and should be)
> > empty.
>
> Do we want userspace to see this implementation detail? Two data structures
> doing the almost the same thing could get confusing in a hurry. It feels
> like a recipe for changing one and not the other and then running around
> trying to figure out why the change did not work.
>
Yes, I believe we want to have reserved_ports contain just those special ports
that the user wants to reserve. After all we add this entry for this specific
purpose.
^ permalink raw reply
* Re: [net-next PATCH v4 0/3] net: reserve ports for applications using fixed port
From: Eric W. Biederman @ 2010-02-16 20:08 UTC (permalink / raw)
To: Octavian Purdila
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Amerigo Wang
In-Reply-To: <201002162151.04861.opurdila@ixiacom.com>
Octavian Purdila <opurdila@ixiacom.com> writes:
> On Tuesday 16 February 2010 20:49:37 you wrote:
>
>> > The use case (large bitmaps/lists) is different enough from what we have
>> > today (small bitmaps) and that is why I think that we need this new
>> > interface.
>> >
>> > If I get bitmap_parse_user correctly, for a 64k bitmap it expects a 2K
>> > comma separated values. That is not the most intuitively way for the
>> > user to set a list of ports he wants to reserve.
>>
>> In this case I expect an interface of comma separated ranges would be
>> ideal. Typically compact, and modifiable by writing the new value to
>> the file.
>>
>
> Something like bellow?
>
> # set bits 8080 and 1666
> $echo 8080 1666-1666 > /proc
>
> #reset bit 1666
> $echo 8080 > /proc
>
> #reset whole bitmap
> $echo > /proc
Yes. So something like that.
I think I would use commas instead of spaces as that is more traditional.
>> I think the default value would be something like 32768-61000.
>
> Note that this new proc entry will work in conjunction with the existing
> ip_local_port_range option, so the default bitmap can (and should be) empty.
Do we want userspace to see this implementation detail? Two data structures doing
the almost the same thing could get confusing in a hurry. It feels like
a recipe for changing one and not the other and then running around trying to
figure out why the change did not work.
Eric
^ permalink raw reply
* Re: [net-next PATCH v4 0/3] net: reserve ports for applications using fixed port
From: Octavian Purdila @ 2010-02-16 19:51 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Amerigo Wang
In-Reply-To: <m17hqd583i.fsf@fess.ebiederm.org>
On Tuesday 16 February 2010 20:49:37 you wrote:
> > The use case (large bitmaps/lists) is different enough from what we have
> > today (small bitmaps) and that is why I think that we need this new
> > interface.
> >
> > If I get bitmap_parse_user correctly, for a 64k bitmap it expects a 2K
> > comma separated values. That is not the most intuitively way for the
> > user to set a list of ports he wants to reserve.
>
> In this case I expect an interface of comma separated ranges would be
> ideal. Typically compact, and modifiable by writing the new value to
> the file.
>
Something like bellow?
# set bits 8080 and 1666
$echo 8080 1666-1666 > /proc
#reset bit 1666
$echo 8080 > /proc
#reset whole bitmap
$echo > /proc
> I think the default value would be something like 32768-61000.
Note that this new proc entry will work in conjunction with the existing
ip_local_port_range option, so the default bitmap can (and should be) empty.
^ permalink raw reply
* Re: netfilter 00/62: netfilter update
From: David Miller @ 2010-02-16 19:21 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel
In-Reply-To: <20100216145517.2796.40634.sendpatchset@x2.localnet>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 16 Feb 2010 15:55:19 +0100 (MET)
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Pulled, I'll push this out to net-next-2.6 after some build
tests.
Thanks!
^ permalink raw reply
* Re: [PATCH -mm] ssb: open-code dma_alloc_coherent
From: Larry Finger @ 2010-02-16 19:12 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: linux-kernel, netdev, mb, davem, stefano.brivio, akpm
In-Reply-To: <20100216110422O.fujita.tomonori@lab.ntt.co.jp>
On 02/15/2010 08:05 PM, FUJITA Tomonori wrote:
> On Mon, 15 Feb 2010 18:09:53 -0600
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> On 02/15/2010 01:25 AM, FUJITA Tomonori wrote:
>>> 2.6.33-rc8:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git pending
>>>
>>> The ssb patch depends on the latest eight patches in the tree:
>>>
>>> http://marc.info/?l=linux-kernel&m=126596737604808&w=2
>>
>> The DMA changes work on i386 architecture with wireless devices in Cardbus (PCI)
>> format. Both b43legacy and b43 were tested.
>
> Great, thanks a lot!
>
> I've posted the second version:
>
> http://marc.info/?l=linux-kernel&m=126624677226865&w=2
>
> It's also available via the git tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git pending
>
> Can I get your ack on b43 stuff?
>
Both b43 and b43legacy changes are
ACKed-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry
^ permalink raw reply
* [PATCH] tunnels: fix netns vs proto registration ordering
From: Alexey Dobriyan @ 2010-02-16 19:05 UTC (permalink / raw)
To: davem; +Cc: netdev, security
Same stuff as in ip_gre patch: receive hook can be called before netns
setup is done, oopsing in net_generic().
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
net/ipv4/ipip.c | 13 +++++------
net/ipv6/ip6_tunnel.c | 28 +++++++++++++-----------
net/ipv6/sit.c | 13 +++++------
net/ipv6/xfrm6_tunnel.c | 55 +++++++++++++++++-------------------------------
4 files changed, 47 insertions(+), 62 deletions(-)
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -830,15 +830,14 @@ static int __init ipip_init(void)
printk(banner);
- if (xfrm4_tunnel_register(&ipip_handler, AF_INET)) {
+ err = register_pernet_device(&ipip_net_ops);
+ if (err < 0)
+ return err;
+ err = xfrm4_tunnel_register(&ipip_handler, AF_INET);
+ if (err < 0) {
+ unregister_pernet_device(&ipip_net_ops);
printk(KERN_INFO "ipip init: can't register tunnel\n");
- return -EAGAIN;
}
-
- err = register_pernet_device(&ipip_net_ops);
- if (err)
- xfrm4_tunnel_deregister(&ipip_handler, AF_INET);
-
return err;
}
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1461,27 +1461,29 @@ static int __init ip6_tunnel_init(void)
{
int err;
- if (xfrm6_tunnel_register(&ip4ip6_handler, AF_INET)) {
+ err = register_pernet_device(&ip6_tnl_net_ops);
+ if (err < 0)
+ goto out_pernet;
+
+ err = xfrm6_tunnel_register(&ip4ip6_handler, AF_INET);
+ if (err < 0) {
printk(KERN_ERR "ip6_tunnel init: can't register ip4ip6\n");
- err = -EAGAIN;
- goto out;
+ goto out_ip4ip6;
}
- if (xfrm6_tunnel_register(&ip6ip6_handler, AF_INET6)) {
+ err = xfrm6_tunnel_register(&ip6ip6_handler, AF_INET6);
+ if (err < 0) {
printk(KERN_ERR "ip6_tunnel init: can't register ip6ip6\n");
- err = -EAGAIN;
- goto unreg_ip4ip6;
+ goto out_ip6ip6;
}
- err = register_pernet_device(&ip6_tnl_net_ops);
- if (err < 0)
- goto err_pernet;
return 0;
-err_pernet:
- xfrm6_tunnel_deregister(&ip6ip6_handler, AF_INET6);
-unreg_ip4ip6:
+
+out_ip6ip6:
xfrm6_tunnel_deregister(&ip4ip6_handler, AF_INET);
-out:
+out_ip4ip6:
+ unregister_pernet_device(&ip6_tnl_net_ops);
+out_pernet:
return err;
}
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1227,15 +1227,14 @@ static int __init sit_init(void)
printk(KERN_INFO "IPv6 over IPv4 tunneling driver\n");
- if (xfrm4_tunnel_register(&sit_handler, AF_INET6) < 0) {
- printk(KERN_INFO "sit init: Can't add protocol\n");
- return -EAGAIN;
- }
-
err = register_pernet_device(&sit_net_ops);
if (err < 0)
- xfrm4_tunnel_deregister(&sit_handler, AF_INET6);
-
+ return err;
+ err = xfrm4_tunnel_register(&sit_handler, AF_INET6);
+ if (err < 0) {
+ unregister_pernet_device(&sit_net_ops);
+ printk(KERN_INFO "sit init: Can't add protocol\n");
+ }
return err;
}
--- a/net/ipv6/xfrm6_tunnel.c
+++ b/net/ipv6/xfrm6_tunnel.c
@@ -84,23 +84,6 @@ static inline unsigned xfrm6_tunnel_spi_hash_byspi(u32 spi)
return spi % XFRM6_TUNNEL_SPI_BYSPI_HSIZE;
}
-
-static int __init xfrm6_tunnel_spi_init(void)
-{
- xfrm6_tunnel_spi_kmem = kmem_cache_create("xfrm6_tunnel_spi",
- sizeof(struct xfrm6_tunnel_spi),
- 0, SLAB_HWCACHE_ALIGN,
- NULL);
- if (!xfrm6_tunnel_spi_kmem)
- return -ENOMEM;
- return 0;
-}
-
-static void xfrm6_tunnel_spi_fini(void)
-{
- kmem_cache_destroy(xfrm6_tunnel_spi_kmem);
-}
-
static struct xfrm6_tunnel_spi *__xfrm6_tunnel_spi_lookup(struct net *net, xfrm_address_t *saddr)
{
struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net);
@@ -375,42 +358,44 @@ static int __init xfrm6_tunnel_init(void)
{
int rv;
+ xfrm6_tunnel_spi_kmem = kmem_cache_create("xfrm6_tunnel_spi",
+ sizeof(struct xfrm6_tunnel_spi),
+ 0, SLAB_HWCACHE_ALIGN,
+ NULL);
+ if (!xfrm6_tunnel_spi_kmem)
+ return -ENOMEM;
+ rv = register_pernet_subsys(&xfrm6_tunnel_net_ops);
+ if (rv < 0)
+ goto out_pernet;
rv = xfrm_register_type(&xfrm6_tunnel_type, AF_INET6);
if (rv < 0)
- goto err;
+ goto out_type;
rv = xfrm6_tunnel_register(&xfrm6_tunnel_handler, AF_INET6);
if (rv < 0)
- goto unreg;
+ goto out_xfrm6;
rv = xfrm6_tunnel_register(&xfrm46_tunnel_handler, AF_INET);
if (rv < 0)
- goto dereg6;
- rv = xfrm6_tunnel_spi_init();
- if (rv < 0)
- goto dereg46;
- rv = register_pernet_subsys(&xfrm6_tunnel_net_ops);
- if (rv < 0)
- goto deregspi;
+ goto out_xfrm46;
return 0;
-deregspi:
- xfrm6_tunnel_spi_fini();
-dereg46:
- xfrm6_tunnel_deregister(&xfrm46_tunnel_handler, AF_INET);
-dereg6:
+out_xfrm46:
xfrm6_tunnel_deregister(&xfrm6_tunnel_handler, AF_INET6);
-unreg:
+out_xfrm6:
xfrm_unregister_type(&xfrm6_tunnel_type, AF_INET6);
-err:
+out_type:
+ unregister_pernet_subsys(&xfrm6_tunnel_net_ops);
+out_pernet:
+ kmem_cache_destroy(xfrm6_tunnel_spi_kmem);
return rv;
}
static void __exit xfrm6_tunnel_fini(void)
{
- unregister_pernet_subsys(&xfrm6_tunnel_net_ops);
- xfrm6_tunnel_spi_fini();
xfrm6_tunnel_deregister(&xfrm46_tunnel_handler, AF_INET);
xfrm6_tunnel_deregister(&xfrm6_tunnel_handler, AF_INET6);
xfrm_unregister_type(&xfrm6_tunnel_type, AF_INET6);
+ unregister_pernet_subsys(&xfrm6_tunnel_net_ops);
+ kmem_cache_destroy(xfrm6_tunnel_spi_kmem);
}
module_init(xfrm6_tunnel_init);
^ permalink raw reply
* Re: [net-next PATCH v4 0/3] net: reserve ports for applications using fixed port
From: Eric W. Biederman @ 2010-02-16 18:49 UTC (permalink / raw)
To: Octavian Purdila
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Amerigo Wang
In-Reply-To: <201002162004.33533.opurdila@ixiacom.com>
Octavian Purdila <opurdila@ixiacom.com> writes:
> Hi Eric, thanks for going over this.
>
> The use case (large bitmaps/lists) is different enough from what we have today
> (small bitmaps) and that is why I think that we need this new interface.
>
> If I get bitmap_parse_user correctly, for a 64k bitmap it expects a 2K comma
> separated values. That is not the most intuitively way for the user to set a
> list of ports he wants to reserve.
In this case I expect an interface of comma separated ranges would be
ideal. Typically compact, and modifiable by writing the new value to
the file.
I think the default value would be something like 32768-61000.
> Using 64K files has the same practical issues (the user would have to cat all
> 64K files to determine which ports are reserved) plus it has issues caused by
> the large number of files: significant memory overhead and also significant time
> for registering those files.
"grep -l 1 *" isn't particularly difficult, and it would be one sysctl registration
call. It is true that the sysctl memory footprint would be a pain in that case.
Eric
^ permalink raw reply
* Re: [net-next PATCH v4 0/3] net: reserve ports for applications using fixed port
From: Octavian Purdila @ 2010-02-16 18:04 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Amerigo Wang
In-Reply-To: <m1sk916qkv.fsf@fess.ebiederm.org>
On Tuesday 16 February 2010 19:25:04 you wrote:
> I don't like the /proc interface for this. That is certainly not the
> format I would choose for a bitmap. The way you have described this
> it looks like you are a set of different individual values instead of
> one large value. History says one value per file is the ideal in a
> user space facing interface. Intuitively I would not know how to
> change your new proc interface after catting the file. The classic
> read the file tweak the value and write the new value back will not
> work.
>
> Also we already have a common function for dealing with bitmaps
> in /proc. bitmap_parse_user. Used in /proc/irq/NNN/smp_affinity
> among other places.
>
> So can you please use bitmap_parse_user, or break this up into
> 64k individual files that we can set individually?
>
Hi Eric, thanks for going over this.
The use case (large bitmaps/lists) is different enough from what we have today
(small bitmaps) and that is why I think that we need this new interface.
If I get bitmap_parse_user correctly, for a 64k bitmap it expects a 2K comma
separated values. That is not the most intuitively way for the user to set a
list of ports he wants to reserve.
Using 64K files has the same practical issues (the user would have to cat all
64K files to determine which ports are reserved) plus it has issues caused by
the large number of files: significant memory overhead and also significant time
for registering those files.
If this new interface is unacceptable I would rather go with a setsockopt
approach, since either of the above approaches are more like machine friendly
instead of user friendly.
^ permalink raw reply
* [PATCH] gre: fix netns vs proto registration ordering
From: Alexey Dobriyan @ 2010-02-16 17:57 UTC (permalink / raw)
To: davem; +Cc: netdev, security
GRE protocol receive hook can be called right after protocol addition is done.
If netns stuff is not yet initialized, we're going to oops in
net_generic().
This is remotely oopsable if ip_gre is compiled as module and packet
comes at unfortunate moment of module loading.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
net/ipv4/ip_gre.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1665,14 +1665,15 @@ static int __init ipgre_init(void)
printk(KERN_INFO "GRE over IPv4 tunneling driver\n");
- if (inet_add_protocol(&ipgre_protocol, IPPROTO_GRE) < 0) {
- printk(KERN_INFO "ipgre init: can't add protocol\n");
- return -EAGAIN;
- }
-
err = register_pernet_device(&ipgre_net_ops);
if (err < 0)
- goto gen_device_failed;
+ return err;
+
+ err = inet_add_protocol(&ipgre_protocol, IPPROTO_GRE);
+ if (err < 0) {
+ printk(KERN_INFO "ipgre init: can't add protocol\n");
+ goto add_proto_failed;
+ }
err = rtnl_link_register(&ipgre_link_ops);
if (err < 0)
@@ -1688,9 +1689,9 @@ out:
tap_ops_failed:
rtnl_link_unregister(&ipgre_link_ops);
rtnl_link_failed:
- unregister_pernet_device(&ipgre_net_ops);
-gen_device_failed:
inet_del_protocol(&ipgre_protocol, IPPROTO_GRE);
+add_proto_failed:
+ unregister_pernet_device(&ipgre_net_ops);
goto out;
}
@@ -1698,9 +1699,9 @@ static void __exit ipgre_fini(void)
{
rtnl_link_unregister(&ipgre_tap_ops);
rtnl_link_unregister(&ipgre_link_ops);
- unregister_pernet_device(&ipgre_net_ops);
if (inet_del_protocol(&ipgre_protocol, IPPROTO_GRE) < 0)
printk(KERN_INFO "ipgre close: can't remove protocol\n");
+ unregister_pernet_device(&ipgre_net_ops);
}
module_init(ipgre_init);
^ permalink raw reply
* If you're looking for a decent marketing list we probably have it
From: Guthrie fragment @ 2010-02-16 17:24 UTC (permalink / raw)
To: info, webmasterpacrhq, wine
I have many good quality lists at decent prices. Drop me a line here: Coleman.Mock@bestdatamart.Co.CC
I'll get you all the details and samples.
to access our discard list please send an email to disappear@bestdatamart.Co.CC
^ permalink raw reply
* Re: [net-next PATCH v4 0/3] net: reserve ports for applications using fixed port
From: Eric W. Biederman @ 2010-02-16 17:25 UTC (permalink / raw)
To: Octavian Purdila
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Amerigo Wang
In-Reply-To: <1266271241-6293-1-git-send-email-opurdila@ixiacom.com>
Octavian Purdila <opurdila@ixiacom.com> writes:
> This iteration makes the bitmap dynamically allocated since it is
> quite big (8192 bytes) and adding that much in BSS may still,
> apparently, cause problems on some architectures.
>
>
> Octavian Purdila (3):
> sysctl: refactor integer handling proc code
> sysctl: add proc_dobitmap
> net: reserve ports for applications using fixed port numbers
>
I don't like the /proc interface for this. That is certainly not the
format I would choose for a bitmap. The way you have described this
it looks like you are a set of different individual values instead of
one large value. History says one value per file is the ideal in a
user space facing interface. Intuitively I would not know how to
change your new proc interface after catting the file. The classic
read the file tweak the value and write the new value back will not
work.
Also we already have a common function for dealing with bitmaps
in /proc. bitmap_parse_user. Used in /proc/irq/NNN/smp_affinity
among other places.
So can you please use bitmap_parse_user, or break this up into
64k individual files that we can set individually?
Eric
^ permalink raw reply
* Re: [PATCH 4/5] Add loopback checkpoint support
From: Dan Smith @ 2010-02-16 16:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: containers, netdev
In-Reply-To: <1266336555.3045.57.camel@edumazet-laptop>
ED> Dont you have a #ifdef CONFIG_CHECKPOINT or something to avoid
ED> this for small machines ?
Yes, and the veth patch used it appropriately. It should look like
this:
Add loopback checkpoint support (v2)
Adds a small ndo_checkpoint() handler for loopback devices to write the
name and addresses like other interfaces.
Changes in v2:
- Add CONFIG_CHECKPOINT around the handler
Signed-off-by: Dan Smith <danms@us.ibm.com>
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index b9fcc98..77023a7 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -57,6 +57,8 @@
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/percpu.h>
+#include <linux/checkpoint.h>
+#include <linux/checkpoint_hdr.h>
#include <net/net_namespace.h>
struct pcpu_lstats {
@@ -153,10 +155,46 @@ static void loopback_dev_free(struct net_device *dev)
free_netdev(dev);
}
+#ifdef CONFIG_CHECKPOINT
+static int loopback_checkpoint(struct ckpt_ctx *ctx, struct net_device *dev)
+{
+ struct ckpt_hdr_netdev *h;
+ struct ckpt_netdev_addr *addrs;
+ int ret;
+
+ h = ckpt_netdev_base(ctx, dev, &addrs);
+ if (IS_ERR(h))
+ return PTR_ERR(h);
+
+ h->type = CKPT_NETDEV_LO;
+
+ ret = ckpt_write_obj(ctx, (struct ckpt_hdr *)h);
+ if (ret < 0)
+ goto out;
+
+ ret = ckpt_write_buffer(ctx, dev->name, IFNAMSIZ);
+ if (ret < 0)
+ goto out;
+
+ if (h->inet_addrs > 0) {
+ int len = (sizeof(struct ckpt_netdev_addr) * h->inet_addrs);
+ ret = ckpt_write_buffer(ctx, addrs, len);
+ }
+
+ out:
+ ckpt_hdr_put(ctx, h);
+ kfree(addrs);
+
+ return ret;
+}
+#endif
static const struct net_device_ops loopback_ops = {
- .ndo_init = loopback_dev_init,
- .ndo_start_xmit= loopback_xmit,
- .ndo_get_stats = loopback_get_stats,
+ .ndo_init = loopback_dev_init,
+ .ndo_start_xmit = loopback_xmit,
+ .ndo_get_stats = loopback_get_stats,
+#ifdef CONFIG_CHECKPOINT
+ .ndo_checkpoint = loopback_checkpoint,
+#endif
};
/*
--
Dan Smith
IBM Linux Technology Center
email: danms@us.ibm.com
^ permalink raw reply related
* Re: [PATCH 4/5] Add loopback checkpoint support
From: Eric Dumazet @ 2010-02-16 16:09 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, netdev
In-Reply-To: <1266336187-19105-5-git-send-email-danms@us.ibm.com>
Le mardi 16 février 2010 à 08:03 -0800, Dan Smith a écrit :
> Adds a small ndo_checkpoint() handler for loopback devices to write the
> name and addresses like other interfaces.
>
> Signed-off-by: Dan Smith <danms@us.ibm.com>
> ---
> drivers/net/loopback.c | 41 ++++++++++++++++++++++++++++++++++++++---
> 1 files changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
> index b9fcc98..816a527 100644
> --- a/drivers/net/loopback.c
> +++ b/drivers/net/loopback.c
> @@ -57,6 +57,8 @@
> #include <linux/ip.h>
> #include <linux/tcp.h>
> #include <linux/percpu.h>
> +#include <linux/checkpoint.h>
> +#include <linux/checkpoint_hdr.h>
> #include <net/net_namespace.h>
>
> struct pcpu_lstats {
> @@ -153,10 +155,43 @@ static void loopback_dev_free(struct net_device *dev)
> free_netdev(dev);
> }
>
Dont you have a #ifdef CONFIG_CHECKPOINT or something to avoid this for
small machines ?
> +static int loopback_checkpoint(struct ckpt_ctx *ctx, struct net_device *dev)
> +{
> + struct ckpt_hdr_netdev *h;
> + struct ckpt_netdev_addr *addrs;
> + int ret;
> +
> + h = ckpt_netdev_base(ctx, dev, &addrs);
> + if (IS_ERR(h))
> + return PTR_ERR(h);
> +
> + h->type = CKPT_NETDEV_LO;
> +
> + ret = ckpt_write_obj(ctx, (struct ckpt_hdr *)h);
> + if (ret < 0)
> + goto out;
> +
> + ret = ckpt_write_buffer(ctx, dev->name, IFNAMSIZ);
> + if (ret < 0)
> + goto out;
> +
> + if (h->inet_addrs > 0) {
> + int len = (sizeof(struct ckpt_netdev_addr) * h->inet_addrs);
> + ret = ckpt_write_buffer(ctx, addrs, len);
> + }
> +
> + out:
> + ckpt_hdr_put(ctx, h);
> + kfree(addrs);
> +
> + return ret;
> +}
> +
> static const struct net_device_ops loopback_ops = {
> - .ndo_init = loopback_dev_init,
> - .ndo_start_xmit= loopback_xmit,
> - .ndo_get_stats = loopback_get_stats,
> + .ndo_init = loopback_dev_init,
> + .ndo_start_xmit = loopback_xmit,
> + .ndo_get_stats = loopback_get_stats,
> + .ndo_checkpoint = loopback_checkpoint,
> };
>
> /*
^ permalink raw reply
* [PATCH 5/5] Add a checkpoint handler to the 'sit' device
From: Dan Smith @ 2010-02-16 16:03 UTC (permalink / raw)
To: containers, netdev
In-Reply-To: <1266336187-19105-1-git-send-email-danms@us.ibm.com>
This handler doesn't really do much to checkpoint the device, other
than the minimum required to support the restart process. When we
add IPv6 support to this, then we can fill this out.
This allows us to avoid skipping unsupported interfaces on a normal
system.
Signed-off-by: Dan Smith <danms@us.ibm.com>
---
net/ipv6/sit.c | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 976e682..a9fc331 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -32,6 +32,8 @@
#include <linux/init.h>
#include <linux/netfilter_ipv4.h>
#include <linux/if_ether.h>
+#include <linux/checkpoint.h>
+#include <linux/checkpoint_hdr.h>
#include <net/sock.h>
#include <net/snmp.h>
@@ -1085,11 +1087,39 @@ static int ipip6_tunnel_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
+static int ipip6_checkpoint(struct ckpt_ctx *ctx, struct net_device *dev)
+{
+ struct ckpt_hdr_netdev *h;
+ struct ckpt_netdev_addr *addrs;
+ int ret;
+
+ h = ckpt_netdev_base(ctx, dev, &addrs);
+ if (IS_ERR(h))
+ return PTR_ERR(h);
+
+ h->type = CKPT_NETDEV_SIT;
+
+ ret = ckpt_write_obj(ctx, (struct ckpt_hdr *) h);
+ if (ret < 0)
+ goto out;
+
+ if (h->inet_addrs > 0) {
+ int len = (sizeof(struct ckpt_netdev_addr) * h->inet_addrs);
+ ret = ckpt_write_buffer(ctx, addrs, len);
+ }
+ out:
+ ckpt_hdr_put(ctx, h);
+ kfree(addrs);
+
+ return ret;
+}
+
static const struct net_device_ops ipip6_netdev_ops = {
.ndo_uninit = ipip6_tunnel_uninit,
.ndo_start_xmit = ipip6_tunnel_xmit,
.ndo_do_ioctl = ipip6_tunnel_ioctl,
.ndo_change_mtu = ipip6_tunnel_change_mtu,
+ .ndo_checkpoint = ipip6_checkpoint,
};
static void ipip6_tunnel_setup(struct net_device *dev)
--
1.6.2.5
^ permalink raw reply related
* [PATCH 4/5] Add loopback checkpoint support
From: Dan Smith @ 2010-02-16 16:03 UTC (permalink / raw)
To: containers, netdev
In-Reply-To: <1266336187-19105-1-git-send-email-danms@us.ibm.com>
Adds a small ndo_checkpoint() handler for loopback devices to write the
name and addresses like other interfaces.
Signed-off-by: Dan Smith <danms@us.ibm.com>
---
drivers/net/loopback.c | 41 ++++++++++++++++++++++++++++++++++++++---
1 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index b9fcc98..816a527 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -57,6 +57,8 @@
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/percpu.h>
+#include <linux/checkpoint.h>
+#include <linux/checkpoint_hdr.h>
#include <net/net_namespace.h>
struct pcpu_lstats {
@@ -153,10 +155,43 @@ static void loopback_dev_free(struct net_device *dev)
free_netdev(dev);
}
+static int loopback_checkpoint(struct ckpt_ctx *ctx, struct net_device *dev)
+{
+ struct ckpt_hdr_netdev *h;
+ struct ckpt_netdev_addr *addrs;
+ int ret;
+
+ h = ckpt_netdev_base(ctx, dev, &addrs);
+ if (IS_ERR(h))
+ return PTR_ERR(h);
+
+ h->type = CKPT_NETDEV_LO;
+
+ ret = ckpt_write_obj(ctx, (struct ckpt_hdr *)h);
+ if (ret < 0)
+ goto out;
+
+ ret = ckpt_write_buffer(ctx, dev->name, IFNAMSIZ);
+ if (ret < 0)
+ goto out;
+
+ if (h->inet_addrs > 0) {
+ int len = (sizeof(struct ckpt_netdev_addr) * h->inet_addrs);
+ ret = ckpt_write_buffer(ctx, addrs, len);
+ }
+
+ out:
+ ckpt_hdr_put(ctx, h);
+ kfree(addrs);
+
+ return ret;
+}
+
static const struct net_device_ops loopback_ops = {
- .ndo_init = loopback_dev_init,
- .ndo_start_xmit= loopback_xmit,
- .ndo_get_stats = loopback_get_stats,
+ .ndo_init = loopback_dev_init,
+ .ndo_start_xmit = loopback_xmit,
+ .ndo_get_stats = loopback_get_stats,
+ .ndo_checkpoint = loopback_checkpoint,
};
/*
--
1.6.2.5
^ permalink raw reply related
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