* Re: 2.6.39-rc7-git11, x86/32, failed on ppp2897'th interface, PERCPU: allocation failed
From: Eric Dumazet @ 2011-05-19 6:55 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <1305787158.3019.12.camel@edumazet-laptop>
Le jeudi 19 mai 2011 à 08:39 +0200, Eric Dumazet a écrit :
> Its a known problem : When ipv6 is enabled, we allocate percpu memory to
> hold per device snmp counters.
>
> make sure kernel idea of max possible cpus matches real number of cpus.
>
> And yes, switching to 64bit kernel helps a lot.
>
>
Looking at snmp6_alloc_dev(), we allocate three mib per device :
ipstats_mib (30 * sizeof(u64) * number_of_possible_cpus)
icmpv6_mib (4 * sizeof(long) * number_of_possible_cpus)
icmpv6msg_mib (26 * sizeof(long))
For sure icmp ones dont need percpu counter. Plain atomic_long_t
(shared) would be enough, since ICMP messages are rare enough.
^ permalink raw reply
* Re: [PATCH] tcp: Implement a two-level initial RTO as per draft RFC 2988bis-02.
From: tsuna @ 2011-05-19 7:07 UTC (permalink / raw)
To: Alexander Zimmermann
Cc: David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber, hagen,
eric.dumazet, netdev, linux-kernel
In-Reply-To: <8C5DF277-320D-4DEB-A133-EEC301DE58DC@comsys.rwth-aachen.de>
On Wed, May 18, 2011 at 11:52 PM, Alexander Zimmermann
<alexander.zimmermann@comsys.rwth-aachen.de> wrote:
>> So we're talking about a [200ms ; 120s] range no matter what.
>
> Why is 200ms a valid lower bound for initRTO? I'm aware of
> measurements that 1s is save for Internet, but I don't know of any
> studies that 200ms is save...
The constants that are quoted aren't specific to the initRTO. They're
used to bound the RTO as it gets adjusted during the TCP session. See
`tcp_set_rto' in tcp_input.c for reference.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
^ permalink raw reply
* [PATCH 1/2] net: ping: make local functions static
From: Changli Gao @ 2011-05-19 7:16 UTC (permalink / raw)
To: David S. Miller
Cc: Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, Changli Gao
As these functions are only used in this file.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/ipv4/ping.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 6a21da9..5f9e2d1 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -449,8 +449,8 @@ static int ping_push_pending_frames(struct sock *sk, struct pingfakehdr *pfh, st
return ip_push_pending_frames(sk, fl4);
}
-int ping_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
- size_t len)
+static int ping_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
+ size_t len)
{
struct net *net = sock_net(sk);
struct flowi4 fl4;
@@ -621,8 +621,8 @@ do_confirm:
goto out;
}
-int ping_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
- size_t len, int noblock, int flags, int *addr_len)
+static int ping_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
+ size_t len, int noblock, int flags, int *addr_len)
{
struct inet_sock *isk = inet_sk(sk);
struct sockaddr_in *sin = (struct sockaddr_in *)msg->msg_name;
^ permalink raw reply related
* [PATCH 2/2] net: ping: fix the coding style
From: Changli Gao @ 2011-05-19 7:16 UTC (permalink / raw)
To: David S. Miller
Cc: Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, Changli Gao
In-Reply-To: <1305789361-5366-1-git-send-email-xiaosuo@gmail.com>
The characters in a line should be no more than 80.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/ipv4/ping.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 5f9e2d1..1f3bb11 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -187,7 +187,8 @@ exit:
return sk;
}
-static void inet_get_ping_group_range_net(struct net *net, gid_t *low, gid_t *high)
+static void inet_get_ping_group_range_net(struct net *net, gid_t *low,
+ gid_t *high)
{
gid_t *data = net->ipv4.sysctl_ping_group_range;
unsigned seq;
@@ -437,7 +438,8 @@ static int ping_getfrag(void *from, char * to,
return 0;
}
-static int ping_push_pending_frames(struct sock *sk, struct pingfakehdr *pfh, struct flowi4 *fl4)
+static int ping_push_pending_frames(struct sock *sk, struct pingfakehdr *pfh,
+ struct flowi4 *fl4)
{
struct sk_buff *skb = skb_peek(&sk->sk_write_queue);
@@ -754,7 +756,9 @@ static struct sock *ping_get_first(struct seq_file *seq, int start)
for (state->bucket = start; state->bucket < PING_HTABLE_SIZE;
++state->bucket) {
struct hlist_nulls_node *node;
- struct hlist_nulls_head *hslot = &ping_table.hash[state->bucket];
+ struct hlist_nulls_head *hslot;
+
+ hslot = &ping_table.hash[state->bucket];
if (hlist_nulls_empty(hslot))
continue;
^ permalink raw reply related
* Re: [PATCH 14/18] virtio: add api for delayed callbacks
From: Michael S. Tsirkin @ 2011-05-19 7:24 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <87boz3dsoe.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
On Mon, May 16, 2011 at 04:43:21PM +0930, Rusty Russell wrote:
> On Sun, 15 May 2011 15:48:18 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Mon, May 09, 2011 at 03:27:33PM +0930, Rusty Russell wrote:
> > > On Wed, 4 May 2011 23:52:33 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > > Add an API that tells the other side that callbacks
> > > > should be delayed until a lot of work has been done.
> > > > Implement using the new used_event feature.
> > >
> > > Since you're going to add a capacity query anyway, why not add the
> > > threshold argument here?
> >
> > I thought that if we keep the API kind of generic
> > there might be more of a chance that future transports
> > will be able to implement it. For example, with an
> > old host we can't commit to a specific index.
>
> No, it's always a hint anyway: you can be notified before the threshold
> is reached. But best make it explicit I think.
>
> Cheers,
> Rusty.
I tried doing that and remembered the real reason I went for this API:
capacity is limited by descriptor table space, not
used ring space: each entry in the used ring frees up multiple entries
in the descriptor ring. Thus the ring can't provide
callback after capacity is N: capacity is only available
after we get bufs.
We could try and make the API pass in the number of freed bufs, however:
- this is not really what virtio-net cares about (it cares about
capacity)
- if the driver passes a number > number of outstanding bufs, it will
never get a callback. So to stay correct the driver will need to
track number of outstanding requests. The simpler API avoids that.
APIs are easy to change so I'm guessing it's not a major blocker:
we can change later when e.g. block tries to
pass in some kind of extra hint: we'll be smarter
about how this API can change then.
Right?
--
MST
^ permalink raw reply
* Re: [PATCH 09/18] virtio: use avail_event index
From: Michael S. Tsirkin @ 2011-05-19 7:27 UTC (permalink / raw)
To: Rusty Russell
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <87tycsn9lt.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
On Wed, May 18, 2011 at 09:49:42AM +0930, Rusty Russell wrote:
> On Tue, 17 May 2011 09:10:31 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > Well one can imagine a driver doing:
> >
> > while (virtqueue_get_buf()) {
> > virtqueue_add_buf()
> > }
> > virtqueue_kick()
> >
> > which looks sensible (batch kicks) but might
> > process any number of bufs between kicks.
>
> No, we currently only expose the buffers in the kick, so it can only
> fill the ring doing that.
>
> We could change that (and maybe that's worth looking at)...
That's actually what one of the early patches in the series did.
I guess I can try and reorder the patches, I do believe
it makes sense to publish immediately as this way
host can work in parallel with the guest.
> > If we look at drivers closely enough, I think none
> > of them do the equivalent of the above, but not 100% sure.
>
> I'm pretty sure we don't have this kind of 'echo' driver yet. Drivers
> tend to take OS requests and queue them. The only one which does
> anything even partially sophisticated is the net driver...
>
> Thanks,
> Rusty.
I guess I'll just need to do the legwork and check then.
--
MST
^ permalink raw reply
* Re: 2.6.39-rc7-git11, x86/32, failed on ppp2897'th interface, PERCPU: allocation failed
From: Denys Fedoryshchenko @ 2011-05-19 7:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1305788113.3019.19.camel@edumazet-laptop>
On Thu, 19 May 2011 08:55:13 +0200, Eric Dumazet wrote:
> Le jeudi 19 mai 2011 à 08:39 +0200, Eric Dumazet a écrit :
>
>> Its a known problem : When ipv6 is enabled, we allocate percpu
>> memory to
>> hold per device snmp counters.
>>
>> make sure kernel idea of max possible cpus matches real number of
>> cpus.
>>
>> And yes, switching to 64bit kernel helps a lot.
>>
>>
>
> Looking at snmp6_alloc_dev(), we allocate three mib per device :
>
> ipstats_mib (30 * sizeof(u64) * number_of_possible_cpus)
> icmpv6_mib (4 * sizeof(long) * number_of_possible_cpus)
> icmpv6msg_mib (26 * sizeof(long))
1920 +
256 +
208 = 2386 * 3000ppp's = 7152000, i think it is not that much at any
case, if i am not wrong.
But at any case i will try 64bit.
>
> For sure icmp ones dont need percpu counter. Plain atomic_long_t
> (shared) would be enough, since ICMP messages are rare enough.
^ permalink raw reply
* Re: [PATCH RFC] virtio_net: fix patch: virtio_net: limit xmit polling
From: Rusty Russell @ 2011-05-19 7:30 UTC (permalink / raw)
To: Michael S. Tsirkin, habanero, Shirley Ma, Krishna Kumar2, kvm,
steved, Tom
Cc: Michael S. Tsirkin, virtualization, netdev, linux-kernel
In-Reply-To: <20110518220125.GA26835@redhat.com>
On Thu, 19 May 2011 01:01:25 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> The patch virtio_net: limit xmit polling
> got the logic reversed: it polled while we had
> capacity not while ring was empty.
>
> Fix it up and clean up a bit by using a for loop.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> OK, turns out that patch was borken. Here's
> a fix that survived stress test on my box.
> Pushed on my branch, I'll send a rebased series
> with Rusty's comments addressed ASAP.
Normally you would have missed the merge window by now, but I'd really
like this stuff in, so I'm holding it open for this. I want these patches
in linux-next for at least a few days before I push them.
If you think we're not close enough, please tell me and I'll push
the rest of the virtio patches to Linus now.
Thanks,
Rusty.
^ permalink raw reply
* Re: 2.6.39-rc7-git11, x86/32, failed on ppp2897'th interface, PERCPU: allocation failed
From: Eric Dumazet @ 2011-05-19 7:44 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <10f61af229a48d77d06d154b4647cdde@visp.net.lb>
Le jeudi 19 mai 2011 à 10:28 +0300, Denys Fedoryshchenko a écrit :
> On Thu, 19 May 2011 08:55:13 +0200, Eric Dumazet wrote:
> > Le jeudi 19 mai 2011 à 08:39 +0200, Eric Dumazet a écrit :
> >
> >> Its a known problem : When ipv6 is enabled, we allocate percpu
> >> memory to
> >> hold per device snmp counters.
> >>
> >> make sure kernel idea of max possible cpus matches real number of
> >> cpus.
> >>
> >> And yes, switching to 64bit kernel helps a lot.
> >>
> >>
> >
> > Looking at snmp6_alloc_dev(), we allocate three mib per device :
> >
> > ipstats_mib (30 * sizeof(u64) * number_of_possible_cpus)
> > icmpv6_mib (4 * sizeof(long) * number_of_possible_cpus)
> > icmpv6msg_mib (26 * sizeof(long))
> 1920 +
> 256 +
> 208 = 2386 * 3000ppp's = 7152000, i think it is not that much at any
> case, if i am not wrong.
>
> But at any case i will try 64bit.
If you really want to stay 32bit, you might try to enlarge vmalloc aread
(128 Mbytes default) to get room for pcpu data :
grep pcpu /proc/vmallocinfo
boot param : vmalloc=256M
^ permalink raw reply
* Re: 2.6.39-rc7-git11, x86/32, failed on ppp2897'th interface, PERCPU: allocation failed
From: David Miller @ 2011-05-19 7:51 UTC (permalink / raw)
To: denys; +Cc: netdev
In-Reply-To: <f9797bb034f650a24e927629d1ab77d8@visp.net.lb>
From: Denys Fedoryshchenko <denys@visp.net.lb>
Date: Thu, 19 May 2011 09:35:29 +0300
> I am not sure it is a bug, but it looks i had free memory(the box had
> 8GB free), and lowmem too, also i will try to enable there 64bit
> kernel at evening.
It's not free memory, you ran out of per-cpu chunks which are allocated
in fixed virtual region(s).
^ permalink raw reply
* Re: ip_vs_ftp causing ip_vs oops on module load.
From: Hans Schillstrom @ 2011-05-19 7:52 UTC (permalink / raw)
To: Simon Horman, Dave Jones, Julian Anastasov
Cc: netdev@vger.kernel.org, Wensong Zhang
In-Reply-To: <20110519032611.GG16688@verge.net.au>
Hello
On Thursday 19 May 2011 05:26:14 Simon Horman wrote:
> On Thu, May 19, 2011 at 10:10:46AM +0900, Simon Horman wrote:
> > On Wed, May 18, 2011 at 04:19:15PM -0400, Dave Jones wrote:
> > > I get this oops from ip_vs_ftp..
> > >
> > > general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > > last sysfs file: /sys/module/nf_nat/refcnt
> > > CPU 3
> > > Modules linked in: ip_vs(+) libcrc32c nf_nat nfsd lockd nfs_acl auth_rpcgss sunrpc cpufreq_ondemand powernow_k8 freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek ppdev snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm microcode edac_core snd_timer k10temp snd pcspkr usb_debug edac_mce_amd soundcore snd_page_alloc sp5100_tco i2c_piix4 parport_pc parport wmi r8169 mii lm63 ipv6 pata_acpi firewire_ohci ata_generic firewire_core crc_itu_t pata_atiixp floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: nf_nat]
> > >
> > > Pid: 1366, comm: modprobe Not tainted 2.6.39-rc7+ #15 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
> > > RIP: 0010:[<ffffffff8107bddb>] [<ffffffff8107bddb>] notifier_chain_register+0xb/0x2a
> > > RSP: 0018:ffff880114139e68 EFLAGS: 00010206
> > > RAX: 2f736e74656e2f74 RBX: ffffffffa04265d0 RCX: 0000000000000003
> > > RDX: 00000000656e6567 RSI: ffffffffa04265d0 RDI: ffffffffa04235d8
> > > RBP: ffff880114139e68 R08: ffff880114139df8 R09: 0000000000000001
> > > R10: 0000000000000001 R11: 00000000000001cc R12: ffffffffa0432106
> > > R13: 0000000000000000 R14: 0000000000007f0d R15: 0000000000410e40
> > > FS: 00007f2aaf242720(0000) GS:ffff88012a800000(0000) knlGS:0000000000000000
> > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > CR2: 00007f2aaea0100f CR3: 000000011424f000 CR4: 00000000000006e0
> > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > Process modprobe (pid: 1366, threadinfo ffff880114138000, task ffff8801146cc7a0)
> > > Stack:
> > > ffff880114139e78 ffffffff8107be36 ffff880114139ec8 ffffffff81403058
> > > 0000000000000000 0000000000000000 ffff880114139ea8 0000000000000000
> > > ffffffffa0432106 0000000000000000 0000000000007f0d 0000000000410e40
> > > Call Trace:
> > > [<ffffffff8107be36>] raw_notifier_chain_register+0xe/0x10
> > > [<ffffffff81403058>] register_netdevice_notifier+0x2d/0x1b6
> > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > [<ffffffffa04322c7>] ip_vs_control_init+0xa5/0xce [ip_vs]
> > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > [<ffffffffa0432116>] ip_vs_init+0x10/0x11c [ip_vs]
> > > [<ffffffff81002099>] do_one_initcall+0x7f/0x13a
> > > [<ffffffff81096524>] sys_init_module+0x132/0x281
> > > [<ffffffff814cc702>] system_call_fastpath+0x16/0x1b
> > > Code: 07 ff c8 89 43 48 eb 08 48 89 df e8 dc 95 44 00 4c 89 e6 48 89 df e8 a7 a5 44 00 5b 41 5c 5d c3 55 48 89 e5 66 66 66 66 90 eb 0c <8b> 50 10 39 56 10 7f 0c 48 8d 78 08 48 8b 07 48 85 c0 75 ec 48
> > > RIP [<ffffffff8107bddb>] notifier_chain_register+0xb/0x2a
> > > RSP <ffff880114139e68>
> > > ---[ end trace e90d7053ad1a7a5b ]---
> > >
> > >
> > > This script replicates the bug.
> > > (it usually oopses after just a few loops)
> > >
> > > #!/bin/sh
> > > while [ 1 ];
> > > do
> > > modprobe ip_vs_ftp
> > > modprobe -r ip_vs_ftp
> > > done
> > >
> > > Looks like something isn't getting cleaned up on module exit
> > > that we fall over when we encounter it next time it gets loaded ?
It's a bug in ip_vs_ftp related to netns.
> >
> > Thanks Dave, I will look into this.
>
> Hi Dave,
>
> I'm not having much luck reproducing this in KVM.
> I will try this evening on real hardware.
>
> Just to make sure we are testing the same thing, are you using Linus's tree?
> --
I can reproduce the source of the problem,
use multiple netns and then unload the ftp module...
i.e. same list head used in multiple netns
This brings up a question:
- How should ftp be handled in a netns ?
You might want to have it in one netns but not in another,
this requires changes to ipvsadm
A way of doing it could be a disable switch like --noftp [port,port]
i.e. do not break old apps.
Any other ideas ?
This patch solves the root problem, I'm not sure if this is the way to go
or if we should split the ip_vs_app struct ?
If it's the way to go I can send it as a proper formated patch ...
(after some testing)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 4fff432..481f856 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -797,7 +797,8 @@ struct netns_ipvs {
struct list_head rs_table[IP_VS_RTAB_SIZE];
/* ip_vs_app */
struct list_head app_list;
-
+ /* ip_vs_ftp */
+ struct ip_vs_app *ftp_app;
/* ip_vs_proto */
#define IP_VS_PROTO_TAB_SIZE 32 /* must be power of 2 */
struct ip_vs_proto_data *proto_data_table[IP_VS_PROTO_TAB_SIZE];
diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
index 6b5dd6d..17afb09 100644
--- a/net/netfilter/ipvs/ip_vs_ftp.c
+++ b/net/netfilter/ipvs/ip_vs_ftp.c
@@ -411,25 +411,36 @@ static struct ip_vs_app ip_vs_ftp = {
static int __net_init __ip_vs_ftp_init(struct net *net)
{
int i, ret;
- struct ip_vs_app *app = &ip_vs_ftp;
+ struct ip_vs_app *app;
+ struct netns_ipvs *ipvs = net_ipvs(net);
+
+ app = kmemdup(&ip_vs_ftp, sizeof(struct ip_vs_app), GFP_KERNEL);
+ if (!app)
+ return -ENOMEM;
+ INIT_LIST_HEAD(&app->a_list);
+ INIT_LIST_HEAD(&app->incs_list);
+ INIT_LIST_HEAD(&app->p_list);
+ ipvs->ftp_app = app;
ret = register_ip_vs_app(net, app);
if (ret)
- return ret;
+ goto err_exit;
for (i=0; i<IP_VS_APP_MAX_PORTS; i++) {
if (!ports[i])
continue;
ret = register_ip_vs_app_inc(net, app, app->protocol, ports[i]);
if (ret)
- break;
+ goto err_unreg;
pr_info("%s: loaded support on port[%d] = %d\n",
app->name, i, ports[i]);
}
+ return 0;
- if (ret)
- unregister_ip_vs_app(net, app);
-
+err_unreg:
+ unregister_ip_vs_app(net, app);
+err_exit:
+ kfree(ipvs->ftp_app);
return ret;
}
/*
@@ -437,9 +448,7 @@ static int __net_init __ip_vs_ftp_init(struct net *net)
*/
static void __ip_vs_ftp_exit(struct net *net)
{
- struct ip_vs_app *app = &ip_vs_ftp;
-
- unregister_ip_vs_app(net, app);
+ unregister_ip_vs_app(net, net_ipvs(net)->ftp_app);
}
static struct pernet_operations ip_vs_ftp_ops = {
--
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ permalink raw reply related
* Re: ip_vs_ftp causing ip_vs oops on module load.
From: Simon Horman @ 2011-05-19 7:55 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev, Wensong Zhang, Hans Schillstrom
In-Reply-To: <alpine.LFD.2.00.1105190930480.1993@ja.ssi.bg>
On Thu, May 19, 2011 at 09:33:55AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 19 May 2011, Simon Horman wrote:
>
> > > > Call Trace:
> > > > [<ffffffff8107be36>] raw_notifier_chain_register+0xe/0x10
> > > > [<ffffffff81403058>] register_netdevice_notifier+0x2d/0x1b6
> > > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > > [<ffffffffa04322c7>] ip_vs_control_init+0xa5/0xce [ip_vs]
> > > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > > [<ffffffffa0432116>] ip_vs_init+0x10/0x11c [ip_vs]
> > > > [<ffffffff81002099>] do_one_initcall+0x7f/0x13a
> > > > [<ffffffff81096524>] sys_init_module+0x132/0x281
> > > > [<ffffffff814cc702>] system_call_fastpath+0x16/0x1b
> > > > Code: 07 ff c8 89 43 48 eb 08 48 89 df e8 dc 95 44 00 4c 89 e6 48 89 df e8 a7 a5 44 00 5b 41 5c 5d c3 55 48 89 e5 66 66 66 66 90 eb 0c <8b> 50 10 39 56 10 7f 0c 48 8d 78 08 48 8b 07 48 85 c0 75 ec 48
> > > > RIP [<ffffffff8107bddb>] notifier_chain_register+0xb/0x2a
> > > > RSP <ffff880114139e68>
> > > > ---[ end trace e90d7053ad1a7a5b ]---
> > > >
> > > >
> > > > This script replicates the bug.
> > > > (it usually oopses after just a few loops)
> > > >
> > > > #!/bin/sh
> > > > while [ 1 ];
> > > > do
> > > > modprobe ip_vs_ftp
> > > > modprobe -r ip_vs_ftp
> > > > done
> > > >
> > > > Looks like something isn't getting cleaned up on module exit
> > > > that we fall over when we encounter it next time it gets loaded ?
> > >
> > > Thanks Dave, I will look into this.
> >
> > Hi Dave,
> >
> > I'm not having much luck reproducing this in KVM.
> > I will try this evening on real hardware.
> >
> > Just to make sure we are testing the same thing, are you using Linus's tree?
>
> One unregister_netdevice_notifier(&ip_vs_dst_notifier);
> is missing in ip_vs_control_cleanup for sure.
Like this?
>From 840edfcc48e5b98d928ee9d66def761a808945b3 Mon Sep 17 00:00:00 2001
From: Simon Horman <horms@verge.net.au>
Date: Thu, 19 May 2011 16:54:26 +0900
Subject: [PATCH] IPVS: Free resources on module removal
Cc: Julian Anastasov <ja@ssi.bg>
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_ctl.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 37890f2..9b9039b 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3774,6 +3774,7 @@ err_sock:
void ip_vs_control_cleanup(void)
{
EnterFunction(2);
+ unregister_netdevice_notifier(&ip_vs_dst_notifier);
ip_vs_genl_unregister();
nf_unregister_sockopt(&ip_vs_sockopts);
LeaveFunction(2);
--
1.7.4.4
^ permalink raw reply related
* Re: ip_vs_ftp causing ip_vs oops on module load.
From: Hans Schillstrom @ 2011-05-19 7:58 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman, Dave Jones, netdev@vger.kernel.org, Wensong Zhang,
Hans Schillstrom
In-Reply-To: <alpine.LFD.2.00.1105190930480.1993@ja.ssi.bg>
On Thursday 19 May 2011 08:33:55 Julian Anastasov wrote:
>
> Hello,
>
[snip]
>
> One unregister_netdevice_notifier(&ip_vs_dst_notifier);
> is missing in ip_vs_control_cleanup for sure.
>
Oops,
Should I prepare a patch for that one ?
--
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ permalink raw reply
* Re: [PATCH] tcp: Implement a two-level initial RTO as per draft RFC 2988bis-02.
From: Hagen Paul Pfeifer @ 2011-05-19 8:02 UTC (permalink / raw)
To: Alexander Zimmermann
Cc: tsuna, David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, netdev, linux-kernel
In-Reply-To: <8C5DF277-320D-4DEB-A133-EEC301DE58DC@comsys.rwth-aachen.de>
On Thu, 19 May 2011 08:52:10 +0200, Alexander Zimmermann wrote:
>> #define TCP_RTO_MAX ((unsigned)(120*HZ))
>> #define TCP_RTO_MIN ((unsigned)(HZ/5))
>>
>> So we're talking about a [200ms ; 120s] range no matter what.
>
> Why is 200ms a valid lower bound for initRTO? I'm aware of
> measurements that 1s is save for Internet, but I don't know of any
> studies that 200ms is save...
TCP_RTO_MAX and TCP_RTO_MIN is the lower/upper bound for the RTO in
general, not for the initial RTO. RFC 2988 specify a lower bound of 1
second but all operating system choose a lower one because at the time
where RFC 2988 was written the clock granularity was not that accurate. The
minimum RTO for FreeBSD is even 30ms! Furthermore, analysis had
demonstrated that a minimum RTO of 1 second badly breaks throughput in
environments faster then 33kB with minor packet loss rate (e.g. 1%).
So yes, it CAN be wise to choose other lower/upper bounds. But keep in
mind that we should NOT artificial limit ourself. I can image data center
scenarios where a initial RTO of <1 match perfectly.
Hagen
^ permalink raw reply
* Re: ip_vs_ftp causing ip_vs oops on module load.
From: Simon Horman @ 2011-05-19 8:07 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Dave Jones, Julian Anastasov, netdev@vger.kernel.org,
Wensong Zhang
In-Reply-To: <201105190952.49006.hans.schillstrom@ericsson.com>
On Thu, May 19, 2011 at 09:52:47AM +0200, Hans Schillstrom wrote:
> Hello
> On Thursday 19 May 2011 05:26:14 Simon Horman wrote:
> > On Thu, May 19, 2011 at 10:10:46AM +0900, Simon Horman wrote:
> > > On Wed, May 18, 2011 at 04:19:15PM -0400, Dave Jones wrote:
> > > > I get this oops from ip_vs_ftp..
> > > >
> > > > general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > > > last sysfs file: /sys/module/nf_nat/refcnt
> > > > CPU 3
> > > > Modules linked in: ip_vs(+) libcrc32c nf_nat nfsd lockd nfs_acl auth_rpcgss sunrpc cpufreq_ondemand powernow_k8 freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_hda_codec_realtek ppdev snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm microcode edac_core snd_timer k10temp snd pcspkr usb_debug edac_mce_amd soundcore snd_page_alloc sp5100_tco i2c_piix4 parport_pc parport wmi r8169 mii lm63 ipv6 pata_acpi firewire_ohci ata_generic firewire_core crc_itu_t pata_atiixp floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: nf_nat]
> > > >
> > > > Pid: 1366, comm: modprobe Not tainted 2.6.39-rc7+ #15 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
> > > > RIP: 0010:[<ffffffff8107bddb>] [<ffffffff8107bddb>] notifier_chain_register+0xb/0x2a
> > > > RSP: 0018:ffff880114139e68 EFLAGS: 00010206
> > > > RAX: 2f736e74656e2f74 RBX: ffffffffa04265d0 RCX: 0000000000000003
> > > > RDX: 00000000656e6567 RSI: ffffffffa04265d0 RDI: ffffffffa04235d8
> > > > RBP: ffff880114139e68 R08: ffff880114139df8 R09: 0000000000000001
> > > > R10: 0000000000000001 R11: 00000000000001cc R12: ffffffffa0432106
> > > > R13: 0000000000000000 R14: 0000000000007f0d R15: 0000000000410e40
> > > > FS: 00007f2aaf242720(0000) GS:ffff88012a800000(0000) knlGS:0000000000000000
> > > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > > CR2: 00007f2aaea0100f CR3: 000000011424f000 CR4: 00000000000006e0
> > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > > Process modprobe (pid: 1366, threadinfo ffff880114138000, task ffff8801146cc7a0)
> > > > Stack:
> > > > ffff880114139e78 ffffffff8107be36 ffff880114139ec8 ffffffff81403058
> > > > 0000000000000000 0000000000000000 ffff880114139ea8 0000000000000000
> > > > ffffffffa0432106 0000000000000000 0000000000007f0d 0000000000410e40
> > > > Call Trace:
> > > > [<ffffffff8107be36>] raw_notifier_chain_register+0xe/0x10
> > > > [<ffffffff81403058>] register_netdevice_notifier+0x2d/0x1b6
> > > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > > [<ffffffffa04322c7>] ip_vs_control_init+0xa5/0xce [ip_vs]
> > > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > > [<ffffffffa0432116>] ip_vs_init+0x10/0x11c [ip_vs]
> > > > [<ffffffff81002099>] do_one_initcall+0x7f/0x13a
> > > > [<ffffffff81096524>] sys_init_module+0x132/0x281
> > > > [<ffffffff814cc702>] system_call_fastpath+0x16/0x1b
> > > > Code: 07 ff c8 89 43 48 eb 08 48 89 df e8 dc 95 44 00 4c 89 e6 48 89 df e8 a7 a5 44 00 5b 41 5c 5d c3 55 48 89 e5 66 66 66 66 90 eb 0c <8b> 50 10 39 56 10 7f 0c 48 8d 78 08 48 8b 07 48 85 c0 75 ec 48
> > > > RIP [<ffffffff8107bddb>] notifier_chain_register+0xb/0x2a
> > > > RSP <ffff880114139e68>
> > > > ---[ end trace e90d7053ad1a7a5b ]---
> > > >
> > > >
> > > > This script replicates the bug.
> > > > (it usually oopses after just a few loops)
> > > >
> > > > #!/bin/sh
> > > > while [ 1 ];
> > > > do
> > > > modprobe ip_vs_ftp
> > > > modprobe -r ip_vs_ftp
> > > > done
> > > >
> > > > Looks like something isn't getting cleaned up on module exit
> > > > that we fall over when we encounter it next time it gets loaded ?
>
> It's a bug in ip_vs_ftp related to netns.
>
> > >
> > > Thanks Dave, I will look into this.
> >
> > Hi Dave,
> >
> > I'm not having much luck reproducing this in KVM.
> > I will try this evening on real hardware.
> >
> > Just to make sure we are testing the same thing, are you using Linus's tree?
> > --
> I can reproduce the source of the problem,
> use multiple netns and then unload the ftp module...
> i.e. same list head used in multiple netns
>
> This brings up a question:
> - How should ftp be handled in a netns ?
> You might want to have it in one netns but not in another,
> this requires changes to ipvsadm
>
> A way of doing it could be a disable switch like --noftp [port,port]
> i.e. do not break old apps.
>
> Any other ideas ?
>
> This patch solves the root problem, I'm not sure if this is the way to go
> or if we should split the ip_vs_app struct ?
>
> If it's the way to go I can send it as a proper formated patch ...
> (after some testing)
I'm also unsure what a good solution in the longer term is.
But in the immediate future I think that the best idea is as
simple a fix as possible that can go 2.6.39 or -stable.
> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> index 4fff432..481f856 100644
> --- a/include/net/ip_vs.h
> +++ b/include/net/ip_vs.h
> @@ -797,7 +797,8 @@ struct netns_ipvs {
> struct list_head rs_table[IP_VS_RTAB_SIZE];
> /* ip_vs_app */
> struct list_head app_list;
> -
> + /* ip_vs_ftp */
> + struct ip_vs_app *ftp_app;
> /* ip_vs_proto */
> #define IP_VS_PROTO_TAB_SIZE 32 /* must be power of 2 */
> struct ip_vs_proto_data *proto_data_table[IP_VS_PROTO_TAB_SIZE];
> diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
> index 6b5dd6d..17afb09 100644
> --- a/net/netfilter/ipvs/ip_vs_ftp.c
> +++ b/net/netfilter/ipvs/ip_vs_ftp.c
> @@ -411,25 +411,36 @@ static struct ip_vs_app ip_vs_ftp = {
> static int __net_init __ip_vs_ftp_init(struct net *net)
> {
> int i, ret;
> - struct ip_vs_app *app = &ip_vs_ftp;
> + struct ip_vs_app *app;
> + struct netns_ipvs *ipvs = net_ipvs(net);
> +
> + app = kmemdup(&ip_vs_ftp, sizeof(struct ip_vs_app), GFP_KERNEL);
> + if (!app)
> + return -ENOMEM;
> + INIT_LIST_HEAD(&app->a_list);
> + INIT_LIST_HEAD(&app->incs_list);
> + INIT_LIST_HEAD(&app->p_list);
> + ipvs->ftp_app = app;
>
> ret = register_ip_vs_app(net, app);
> if (ret)
> - return ret;
> + goto err_exit;
>
> for (i=0; i<IP_VS_APP_MAX_PORTS; i++) {
> if (!ports[i])
> continue;
> ret = register_ip_vs_app_inc(net, app, app->protocol, ports[i]);
> if (ret)
> - break;
> + goto err_unreg;
> pr_info("%s: loaded support on port[%d] = %d\n",
> app->name, i, ports[i]);
> }
> + return 0;
>
> - if (ret)
> - unregister_ip_vs_app(net, app);
> -
> +err_unreg:
> + unregister_ip_vs_app(net, app);
> +err_exit:
> + kfree(ipvs->ftp_app);
> return ret;
> }
> /*
> @@ -437,9 +448,7 @@ static int __net_init __ip_vs_ftp_init(struct net *net)
> */
> static void __ip_vs_ftp_exit(struct net *net)
> {
> - struct ip_vs_app *app = &ip_vs_ftp;
> -
> - unregister_ip_vs_app(net, app);
> + unregister_ip_vs_app(net, net_ipvs(net)->ftp_app);
> }
>
> static struct pernet_operations ip_vs_ftp_ops = {
>
>
> --
> Regards
> Hans Schillstrom <hans.schillstrom@ericsson.com>
> --
> 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
>
^ permalink raw reply
* Re: ip_vs_ftp causing ip_vs oops on module load.
From: Julian Anastasov @ 2011-05-19 8:15 UTC (permalink / raw)
To: Simon Horman; +Cc: Dave Jones, netdev, Wensong Zhang, Hans Schillstrom
In-Reply-To: <20110519075557.GB3922@verge.net.au>
Hello,
On Thu, 19 May 2011, Simon Horman wrote:
> On Thu, May 19, 2011 at 09:33:55AM +0300, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Thu, 19 May 2011, Simon Horman wrote:
> >
> > > > > Call Trace:
> > > > > [<ffffffff8107be36>] raw_notifier_chain_register+0xe/0x10
> > > > > [<ffffffff81403058>] register_netdevice_notifier+0x2d/0x1b6
> > > > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > > > [<ffffffffa04322c7>] ip_vs_control_init+0xa5/0xce [ip_vs]
> > > > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > > > [<ffffffffa0432116>] ip_vs_init+0x10/0x11c [ip_vs]
> > > > > [<ffffffff81002099>] do_one_initcall+0x7f/0x13a
> > > > > [<ffffffff81096524>] sys_init_module+0x132/0x281
> > > > > [<ffffffff814cc702>] system_call_fastpath+0x16/0x1b
> > > > > Code: 07 ff c8 89 43 48 eb 08 48 89 df e8 dc 95 44 00 4c 89 e6 48 89 df e8 a7 a5 44 00 5b 41 5c 5d c3 55 48 89 e5 66 66 66 66 90 eb 0c <8b> 50 10 39 56 10 7f 0c 48 8d 78 08 48 8b 07 48 85 c0 75 ec 48
> > > > > RIP [<ffffffff8107bddb>] notifier_chain_register+0xb/0x2a
> > > > > RSP <ffff880114139e68>
> > > > > ---[ end trace e90d7053ad1a7a5b ]---
> > > > >
> > > > >
> > > > > This script replicates the bug.
> > > > > (it usually oopses after just a few loops)
> > > > >
> > > > > #!/bin/sh
> > > > > while [ 1 ];
> > > > > do
> > > > > modprobe ip_vs_ftp
> > > > > modprobe -r ip_vs_ftp
> > > > > done
> > > > >
> > > > > Looks like something isn't getting cleaned up on module exit
> > > > > that we fall over when we encounter it next time it gets loaded ?
> > > >
> > > > Thanks Dave, I will look into this.
> > >
> > > Hi Dave,
> > >
> > > I'm not having much luck reproducing this in KVM.
> > > I will try this evening on real hardware.
> > >
> > > Just to make sure we are testing the same thing, are you using Linus's tree?
> >
> > One unregister_netdevice_notifier(&ip_vs_dst_notifier);
> > is missing in ip_vs_control_cleanup for sure.
>
> Like this?
Yes, I think oops is for 2nd or next module load after
first unload forgets entry in notifier list.
> >From 840edfcc48e5b98d928ee9d66def761a808945b3 Mon Sep 17 00:00:00 2001
> From: Simon Horman <horms@verge.net.au>
> Date: Thu, 19 May 2011 16:54:26 +0900
> Subject: [PATCH] IPVS: Free resources on module removal
>
> Cc: Julian Anastasov <ja@ssi.bg>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Julian Anastasov <ja@ssi.bg>
> ---
> net/netfilter/ipvs/ip_vs_ctl.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 37890f2..9b9039b 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -3774,6 +3774,7 @@ err_sock:
> void ip_vs_control_cleanup(void)
> {
> EnterFunction(2);
> + unregister_netdevice_notifier(&ip_vs_dst_notifier);
> ip_vs_genl_unregister();
> nf_unregister_sockopt(&ip_vs_sockopts);
> LeaveFunction(2);
> --
> 1.7.4.4
^ permalink raw reply
* Re: ip_vs_ftp causing ip_vs oops on module load.
From: Hans Schillstrom @ 2011-05-19 8:14 UTC (permalink / raw)
To: Simon Horman
Cc: Julian Anastasov, Dave Jones, netdev@vger.kernel.org,
Wensong Zhang, Hans Schillstrom
In-Reply-To: <20110519075557.GB3922@verge.net.au>
Hello, Simon
On Thursday 19 May 2011 09:55:57 Simon Horman wrote:
> On Thu, May 19, 2011 at 09:33:55AM +0300, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Thu, 19 May 2011, Simon Horman wrote:
> >
> > > > > Call Trace:
> > > > > [<ffffffff8107be36>] raw_notifier_chain_register+0xe/0x10
> > > > > [<ffffffff81403058>] register_netdevice_notifier+0x2d/0x1b6
> > > > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > > > [<ffffffffa04322c7>] ip_vs_control_init+0xa5/0xce [ip_vs]
> > > > > [<ffffffffa0432106>] ? ip_vs_conn_init+0x106/0x106 [ip_vs]
> > > > > [<ffffffffa0432116>] ip_vs_init+0x10/0x11c [ip_vs]
> > > > > [<ffffffff81002099>] do_one_initcall+0x7f/0x13a
> > > > > [<ffffffff81096524>] sys_init_module+0x132/0x281
> > > > > [<ffffffff814cc702>] system_call_fastpath+0x16/0x1b
> > > > > Code: 07 ff c8 89 43 48 eb 08 48 89 df e8 dc 95 44 00 4c 89 e6 48 89 df e8 a7 a5 44 00 5b 41 5c 5d c3 55 48 89 e5 66 66 66 66 90 eb 0c <8b> 50 10 39 56 10 7f 0c 48 8d 78 08 48 8b 07 48 85 c0 75 ec 48
> > > > > RIP [<ffffffff8107bddb>] notifier_chain_register+0xb/0x2a
> > > > > RSP <ffff880114139e68>
> > > > > ---[ end trace e90d7053ad1a7a5b ]---
> > > > >
> > > > >
> > > > > This script replicates the bug.
> > > > > (it usually oopses after just a few loops)
> > > > >
> > > > > #!/bin/sh
> > > > > while [ 1 ];
> > > > > do
> > > > > modprobe ip_vs_ftp
> > > > > modprobe -r ip_vs_ftp
> > > > > done
> > > > >
> > > > > Looks like something isn't getting cleaned up on module exit
> > > > > that we fall over when we encounter it next time it gets loaded ?
> > > >
> > > > Thanks Dave, I will look into this.
> > >
> > > Hi Dave,
> > >
> > > I'm not having much luck reproducing this in KVM.
> > > I will try this evening on real hardware.
> > >
> > > Just to make sure we are testing the same thing, are you using Linus's tree?
> >
> > One unregister_netdevice_notifier(&ip_vs_dst_notifier);
> > is missing in ip_vs_control_cleanup for sure.
>
> Like this?
Yes,
we need this patch and the ip_vs_ftp patch in some format.
>
> From 840edfcc48e5b98d928ee9d66def761a808945b3 Mon Sep 17 00:00:00 2001
> From: Simon Horman <horms@verge.net.au>
> Date: Thu, 19 May 2011 16:54:26 +0900
> Subject: [PATCH] IPVS: Free resources on module removal
>
> Cc: Julian Anastasov <ja@ssi.bg>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
> ---
> net/netfilter/ipvs/ip_vs_ctl.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 37890f2..9b9039b 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -3774,6 +3774,7 @@ err_sock:
> void ip_vs_control_cleanup(void)
> {
> EnterFunction(2);
> + unregister_netdevice_notifier(&ip_vs_dst_notifier);
> ip_vs_genl_unregister();
> nf_unregister_sockopt(&ip_vs_sockopts);
> LeaveFunction(2);
--
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ permalink raw reply
* Re: ip_vs_ftp causing ip_vs oops on module load.
From: Simon Horman @ 2011-05-19 8:17 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Julian Anastasov, Dave Jones, netdev@vger.kernel.org,
Wensong Zhang, Hans Schillstrom
In-Reply-To: <201105190958.56185.hans.schillstrom@ericsson.com>
On Thu, May 19, 2011 at 09:58:55AM +0200, Hans Schillstrom wrote:
> On Thursday 19 May 2011 08:33:55 Julian Anastasov wrote:
> >
> > Hello,
> >
> [snip]
> >
> > One unregister_netdevice_notifier(&ip_vs_dst_notifier);
> > is missing in ip_vs_control_cleanup for sure.
> >
> Oops,
> Should I prepare a patch for that one ?
Could you test the one I posted?
(Or send another one if I got it wrong? :-)
^ permalink raw reply
* [V2 Patch net-next-2.6] netpoll: disable netpoll when enslave a device
From: Amerigo Wang @ 2011-05-19 8:39 UTC (permalink / raw)
To: linux-kernel
Cc: akpm, WANG Cong, Neil Horman, Jay Vosburgh, David S. Miller,
Ian Campbell, Paul E. McKenney, Josh Triplett, netdev
In-Reply-To: <20110518105558.GA3203@hmsreliant.think-freely.org>
Currently we do nothing when we enslave a net device which is running netconsole.
Neil pointed out that we may get weird results in such case, so let's disable
netpoll on the device being enslaved. I think it is too harsh to prevent
the device being ensalved if it is running netconsole.
By the way, this patch also removes the NETDEV_GOING_DOWN from netconsole
netdev notifier, because netpoll will check if the device is running or not
and we don't handle NETDEV_PRE_UP neither.
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: Neil Horman <nhorman@redhat.com>
---
drivers/net/bonding/bond_main.c | 2 ++
drivers/net/netconsole.c | 26 +++++++++++++++++---------
include/linux/notifier.h | 1 +
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 088fd84..b9c70c5 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1640,6 +1640,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
}
}
+ netdev_bonding_change(slave_dev, NETDEV_ENSLAVE);
+
/* If this is the first slave, then we need to set the master's hardware
* address to be the same as the slave's. */
if (is_zero_ether_addr(bond->dev->dev_addr))
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index a83e101..c2a8230 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -621,11 +621,10 @@ static int netconsole_netdev_event(struct notifier_block *this,
bool stopped = false;
if (!(event == NETDEV_CHANGENAME || event == NETDEV_UNREGISTER ||
- event == NETDEV_BONDING_DESLAVE || event == NETDEV_GOING_DOWN))
+ event == NETDEV_BONDING_DESLAVE || event == NETDEV_ENSLAVE))
goto done;
spin_lock_irqsave(&target_list_lock, flags);
-restart:
list_for_each_entry(nt, &target_list, list) {
netconsole_target_get(nt);
if (nt->np.dev == dev) {
@@ -633,6 +632,8 @@ restart:
case NETDEV_CHANGENAME:
strlcpy(nt->np.dev_name, dev->name, IFNAMSIZ);
break;
+ case NETDEV_BONDING_DESLAVE:
+ case NETDEV_ENSLAVE:
case NETDEV_UNREGISTER:
/*
* rtnl_lock already held
@@ -647,11 +648,7 @@ restart:
dev_put(nt->np.dev);
nt->np.dev = NULL;
netconsole_target_put(nt);
- goto restart;
}
- /* Fall through */
- case NETDEV_GOING_DOWN:
- case NETDEV_BONDING_DESLAVE:
nt->enabled = 0;
stopped = true;
break;
@@ -660,10 +657,21 @@ restart:
netconsole_target_put(nt);
}
spin_unlock_irqrestore(&target_list_lock, flags);
- if (stopped && (event == NETDEV_UNREGISTER || event == NETDEV_BONDING_DESLAVE))
+ if (stopped) {
printk(KERN_INFO "netconsole: network logging stopped on "
- "interface %s as it %s\n", dev->name,
- event == NETDEV_UNREGISTER ? "unregistered" : "released slaves");
+ "interface %s as it ", dev->name);
+ switch (event) {
+ case NETDEV_UNREGISTER:
+ printk(KERN_CONT "unregistered\n");
+ break;
+ case NETDEV_BONDING_DESLAVE:
+ printk(KERN_CONT "released slaves\n");
+ break;
+ case NETDEV_ENSLAVE:
+ printk(KERN_CONT "is enslaved\n");
+ break;
+ }
+ }
done:
return NOTIFY_DONE;
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 621dfa1..3d82867 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -211,6 +211,7 @@ static inline int notifier_to_errno(int ret)
#define NETDEV_UNREGISTER_BATCH 0x0011
#define NETDEV_BONDING_DESLAVE 0x0012
#define NETDEV_NOTIFY_PEERS 0x0013
+#define NETDEV_ENSLAVE 0x0014
#define SYS_DOWN 0x0001 /* Notify of system down */
#define SYS_RESTART SYS_DOWN
^ permalink raw reply related
* Re: ip_vs_ftp causing ip_vs oops on module load.
From: Hans Schillstrom @ 2011-05-19 8:52 UTC (permalink / raw)
To: Simon Horman
Cc: Julian Anastasov, Dave Jones, netdev@vger.kernel.org,
Wensong Zhang, Hans Schillstrom
In-Reply-To: <20110519081706.GE3922@verge.net.au>
On Thursday 19 May 2011 10:17:07 Simon Horman wrote:
> On Thu, May 19, 2011 at 09:58:55AM +0200, Hans Schillstrom wrote:
> > On Thursday 19 May 2011 08:33:55 Julian Anastasov wrote:
> > >
> > > Hello,
> > >
> > [snip]
> > >
> > > One unregister_netdevice_notifier(&ip_vs_dst_notifier);
> > > is missing in ip_vs_control_cleanup for sure.
> > >
> > Oops,
> > Should I prepare a patch for that one ?
>
> Could you test the one I posted?
> (Or send another one if I got it wrong? :-)
>
Tested,
it works fine :-)
--
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ permalink raw reply
* Re: ip_vs_ftp causing ip_vs oops on module load.
From: Julian Anastasov @ 2011-05-19 8:55 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Simon Horman, Dave Jones, netdev@vger.kernel.org, Wensong Zhang
In-Reply-To: <201105190952.49006.hans.schillstrom@ericsson.com>
Hello,
On Thu, 19 May 2011, Hans Schillstrom wrote:
> I can reproduce the source of the problem,
> use multiple netns and then unload the ftp module...
> i.e. same list head used in multiple netns
>
> This brings up a question:
> - How should ftp be handled in a netns ?
> You might want to have it in one netns but not in another,
> this requires changes to ipvsadm
>
> A way of doing it could be a disable switch like --noftp [port,port]
> i.e. do not break old apps.
>
> Any other ideas ?
>
> This patch solves the root problem, I'm not sure if this is the way to go
> or if we should split the ip_vs_app struct ?
This patch is a fast fix but may be it is too late for it,
after 2.6.39 is out. It seems we overlooked the apps when
migrating to netns. I think, the apps do not need to be pernet.
If one day application needs pernet context we can add such
fields in the ipvs structure.
While the protocols have controls that manipulate pernet
timeouts, the apps do not have such controls about app->timeouts.
May be we can remove app->timeouts to avoid confusion because
it was never implemented in user space. May be instead of this
fix we should restore the global ip_vs_app_list and all things in
ip_vs_app.c and ip_vs_ftp.c as before the netns changes?
> If it's the way to go I can send it as a proper formated patch ...
> (after some testing)
>
> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> index 4fff432..481f856 100644
> --- a/include/net/ip_vs.h
> +++ b/include/net/ip_vs.h
> @@ -797,7 +797,8 @@ struct netns_ipvs {
> struct list_head rs_table[IP_VS_RTAB_SIZE];
> /* ip_vs_app */
> struct list_head app_list;
> -
> + /* ip_vs_ftp */
> + struct ip_vs_app *ftp_app;
> /* ip_vs_proto */
> #define IP_VS_PROTO_TAB_SIZE 32 /* must be power of 2 */
> struct ip_vs_proto_data *proto_data_table[IP_VS_PROTO_TAB_SIZE];
> diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
> index 6b5dd6d..17afb09 100644
> --- a/net/netfilter/ipvs/ip_vs_ftp.c
> +++ b/net/netfilter/ipvs/ip_vs_ftp.c
> @@ -411,25 +411,36 @@ static struct ip_vs_app ip_vs_ftp = {
> static int __net_init __ip_vs_ftp_init(struct net *net)
> {
> int i, ret;
> - struct ip_vs_app *app = &ip_vs_ftp;
> + struct ip_vs_app *app;
> + struct netns_ipvs *ipvs = net_ipvs(net);
> +
> + app = kmemdup(&ip_vs_ftp, sizeof(struct ip_vs_app), GFP_KERNEL);
> + if (!app)
> + return -ENOMEM;
> + INIT_LIST_HEAD(&app->a_list);
> + INIT_LIST_HEAD(&app->incs_list);
> + INIT_LIST_HEAD(&app->p_list);
> + ipvs->ftp_app = app;
>
> ret = register_ip_vs_app(net, app);
> if (ret)
> - return ret;
> + goto err_exit;
>
> for (i=0; i<IP_VS_APP_MAX_PORTS; i++) {
> if (!ports[i])
> continue;
> ret = register_ip_vs_app_inc(net, app, app->protocol, ports[i]);
> if (ret)
> - break;
> + goto err_unreg;
> pr_info("%s: loaded support on port[%d] = %d\n",
> app->name, i, ports[i]);
> }
> + return 0;
>
> - if (ret)
> - unregister_ip_vs_app(net, app);
> -
> +err_unreg:
> + unregister_ip_vs_app(net, app);
> +err_exit:
> + kfree(ipvs->ftp_app);
> return ret;
> }
> /*
> @@ -437,9 +448,7 @@ static int __net_init __ip_vs_ftp_init(struct net *net)
> */
> static void __ip_vs_ftp_exit(struct net *net)
> {
> - struct ip_vs_app *app = &ip_vs_ftp;
> -
> - unregister_ip_vs_app(net, app);
> + unregister_ip_vs_app(net, net_ipvs(net)->ftp_app);
> }
>
> static struct pernet_operations ip_vs_ftp_ops = {
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: net: add seq_before/seq_after functions
From: Sven Eckelmann @ 2011-05-19 8:54 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-kernel, netdev, davem, Paul Mackerras, linux-ppp
In-Reply-To: <1305722319-8315-1-git-send-email-ordex@autistici.org>
[-- Attachment #1: Type: Text/Plain, Size: 4595 bytes --]
On Wednesday 18 May 2011 14:38:39 Antonio Quartulli wrote:
> Introduce two operations to handle comparison between packet sequence
> numbers taking into account overflow/wraparound. Batman-adv uses
> these functions already to check for successor packet even in case of
> overflow.
Thanks for your efforts to bring that to the kernel. But when you prepare a
patch then you have to add a signoff. And also David S. Miller is the
maintainer for this header - it would be interesting to ask him first when we
want to change that file.
> ---
> I added this two functions in net.h because I didn't really know where
> best placement is. I saw several modules that redefine their own functions
> for the same purpose.
>
> include/linux/net.h | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/net.h b/include/linux/net.h
> index 94de83c..c7bc9bf 100644
> --- a/include/linux/net.h
> +++ b/include/linux/net.h
> @@ -295,4 +295,21 @@ extern struct ratelimit_state net_ratelimit_state;
> #endif
>
> #endif /* __KERNEL__ */
> +
> +/* Returns the smallest signed integer in two's complement with the sizeof
> x */ +#define smallest_signed_int(x) (1u << (7u + 8u * (sizeof(x) - 1u)))
> +
> +/* Checks if a sequence number x is a predecessor/successor of y.
> + * they handle overflows/underflows and can correctly check for a
> + * predecessor/successor unless the variable sequence number has grown by
> + * more then 2**(bitwidth(x)-1)-1.
> + * This means that for a uint8_t with the maximum value 255, it would
> think: + * - when adding nothing - it is neither a predecessor nor a
> successor + * - before adding more than 127 to the starting value - it is
> a predecessor, + * - when adding 128 - it is neither a predecessor nor a
> successor, + * - after adding more than 127 to the starting value - it is
> a successor */ +#define seq_before(x, y) ({typeof(x) _dummy = (x - y); \
> + _dummy > smallest_signed_int(_dummy); })
> +#define seq_after(x, y) seq_before(y, x)
> +
> #endif /* _LINUX_NET_H */
I suggested yesterday (probably too late) that it would be good to check the
type of both parameters (similar to the min and max functions in
include/linux/kernel.h
#define seq_before(x, y) ({typeof(x) _d1 = (x); \
typeof(y) _d2 = (y); \
(void) (&_d1 == &_d2); \
typeof(x) _dummy = (_d1 - _d2); \
_dummy > smallest_signed_int(_dummy); })
And your seq_before/after conflicts with the one defined in ppp_generic.c
drivers/net/ppp_generic.c:232:0: warning: "seq_before" redefined [enabled by
default]
include/linux/net.h:312:0: note: this is the location of the previous
definition
drivers/net/ppp_generic.c:233:0: warning: "seq_after" redefined [enabled by
default]
include/linux/net.h:314:0: note: this is the location of the previous
definition
The definition there is only for u32 - thus you would have to remove it and
check that it always gives the same result:
#define seq_before(a, b) ((s32)((a) - (b)) < 0)
#define seq_after(a, b) ((s32)((a) - (b)) > 0)
But I would say that they have a different definition of seq_before. Changing
that behaviour for batman-adv would not be that problematic, but maybe for
ppp.
A defintion which should fulfil the requirements for ppp could be:
#define seq_after(x, y) ({typeof(x) _d1 = (x); \
typeof(y) _d2 = (y); \
(void) (&_d1 == &_d2); \
typeof(x) _dummy = (_d2 - _d1); \
_dummy > smallest_signed_int(_dummy); })
#define seq_before(x, y) ({typeof(x) _d1 = (x); \
typeof(y) _d2 = (y); \
(void) (&_d1 == &_d2); \
typeof(x) _dummy = (_d1 - _d2); \
_dummy >= smallest_signed_int(_dummy); })
Of course the comment above the seq_before/seq_after would be wrong.
/* Checks if a sequence number x is a predecessor/successor of y.
* they handle overflows/underflows and can correctly check for a
* predecessor/successor unless the variable sequence number has grown by
* more then 2**(bitwidth(x)-1).
* This means that for a uint8_t with the maximum value 255, it would think:
* - when adding nothing - it is neither a predecessor nor a successor
* - before adding more than 128 to the starting value - it is a predecessor,
* - after adding more than 127 to the starting value - it is a successor */
I think there could be more candidates which would like to use this abstract
functionality. Maybe some one else on linux-kernel or netdev has a suggestion.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: net: add seq_before/seq_after functions
From: David Miller @ 2011-05-19 9:08 UTC (permalink / raw)
To: sven; +Cc: ordex, linux-kernel, netdev, paulus, linux-ppp
In-Reply-To: <201105191054.34912.sven@narfation.org>
From: Sven Eckelmann <sven@narfation.org>
Date: Thu, 19 May 2011 10:54:32 +0200
> On Wednesday 18 May 2011 14:38:39 Antonio Quartulli wrote:
>> Introduce two operations to handle comparison between packet sequence
>> numbers taking into account overflow/wraparound. Batman-adv uses
>> these functions already to check for successor packet even in case of
>> overflow.
>
> Thanks for your efforts to bring that to the kernel. But when you prepare a
> patch then you have to add a signoff. And also David S. Miller is the
> maintainer for this header - it would be interesting to ask him first when we
> want to change that file.
Well it makes no sense to add these interfaces until we see an
upstream submission of code which will actually use it.
Also I'm skeptical that such generic sounding interfaces make
sense when it appears to me that these are protocol specific
sequence number tests so probably belong in whatever protocol
is upcoming which will use these interfaces.
Again, this is why we want to see the code that's going to use
these new routines before we can seriously consider adding them
at all.
^ permalink raw reply
* Re: [PATCH] ethtool: ETHTOOL_SFEATURES: remove NETIF_F_COMPAT return
From: Michał Mirosław @ 2011-05-19 9:18 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Miller
In-Reply-To: <1305745379.2929.9.camel@bwh-desktop>
On Wed, May 18, 2011 at 08:02:59PM +0100, Ben Hutchings wrote:
> On Mon, 2011-05-16 at 23:09 +0100, Ben Hutchings wrote:
> > On Mon, 2011-05-16 at 23:50 +0200, Michał Mirosław wrote:
> > > On Mon, May 16, 2011 at 10:08:59PM +0100, Ben Hutchings wrote:
> > > > I've explained before that I do not want to add new options to do
> > > > (mostly) the same thing. Users should have not have to use a different
> > > > command depending on the kernel version.
> > > We can avoid new option by checking feature-strings for unrecognised
> > > arguments to -K. This way, we will have the old options which work
> > > regardless of kernel version ('tx', 'rx', 'sg', etc.) and new options
> > > which need recent kernel anyway (separated 'tx-checksum-*', 'loopback',
> > > others coming in for 2.6.40).
> > This is just too subtle a distinction. It will mostly confuse users.
> Sorry, I think I misunderstood you here. I agree that new feature names
> that do not correspond exactly to existing keywords should be supported
> as keywords after the -K option. I think those that do (e.g.
> "tx-udp-fragmentation" vs "ufo") should not be, as adding a
> kernel-version-dependent *alias* would be confusing.
The alias can be marked as such in the documentation. Shouldn't it be
that hard for a user to read the manpage to know what the new options
are for when he sees them. I don't like the idea of translating strings,
either, because if e.g. ufo becomes split in the feature to ufo4+ufo6
or new checksum offloads are implemented, it will break.
> I also want users to benefit from your improvements (as I explained
> above) even when they use the old names, if they are using a new kernel
> version. That is why I want ethtool to try using ETHTOOL_SFEATURES
> first, and why the fallback in the kernel is problematic.
Which benefits do you want to have? If checking what other features
changed with selected one, it's easily done by rereading the state -
possibly with GFEATURES.
I'll cook another PoC patch over those I sent to show the idea.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: net: add seq_before/seq_after functions
From: Sven Eckelmann @ 2011-05-19 9:21 UTC (permalink / raw)
To: David Miller; +Cc: ordex, linux-kernel, netdev, paulus, linux-ppp
In-Reply-To: <20110519.050824.838971689287732822.davem@davemloft.net>
[-- Attachment #1: Type: Text/Plain, Size: 1736 bytes --]
On Thursday 19 May 2011 11:08:24 David Miller wrote:
> From: Sven Eckelmann <sven@narfation.org>
> Date: Thu, 19 May 2011 10:54:32 +0200
>
> > On Wednesday 18 May 2011 14:38:39 Antonio Quartulli wrote:
> >> Introduce two operations to handle comparison between packet sequence
> >> numbers taking into account overflow/wraparound. Batman-adv uses
> >> these functions already to check for successor packet even in case of
> >> overflow.
> >
> > Thanks for your efforts to bring that to the kernel. But when you prepare
> > a patch then you have to add a signoff. And also David S. Miller is the
> > maintainer for this header - it would be interesting to ask him first
> > when we want to change that file.
>
> Well it makes no sense to add these interfaces until we see an
> upstream submission of code which will actually use it.
>
> Also I'm skeptical that such generic sounding interfaces make
> sense when it appears to me that these are protocol specific
> sequence number tests so probably belong in whatever protocol
> is upcoming which will use these interfaces.
>
> Again, this is why we want to see the code that's going to use
> these new routines before we can seriously consider adding them
> at all.
This is currently used by vis.c in net/batman-adv and could also be used by
ppp-generic.c (with my changes of course). And it is planned to be used by
transtable.c in net/batman-adv. The idea was to propose this to linux-
kernel/netdev before we move it to a place were only batman-adv can use it
(the current situation is that vis.c in batman-adv can only use it).
It is ok that you say that it should be batman-adv specific - we only wanted
to ask first.
Thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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