* Re: [PATCH net-next] net: dsa: fix mii_bus to host_dev replacement
From: David Miller @ 2014-09-15 21:53 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, alexander.h.duyck
In-Reply-To: <1410817688-19397-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 15 Sep 2014 14:48:08 -0700
> dsa_of_probe() still used cd->mii_bus instead of cd->host_dev when
> building with CONFIG_OF=y. Fix this by making the replacement here as
> well.
>
> Fixes: b4d2394d01b ("dsa: Replace mii_bus with a generic host device")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks for catching this.
^ permalink raw reply
* Re: [Patch net-next 2/5] net_sched: fix memory leak in cls_tcindex
From: Cong Wang @ 2014-09-15 22:15 UTC (permalink / raw)
To: John Fastabend
Cc: Linux Kernel Network Developers, john fastabend, David S. Miller
In-Reply-To: <54175D17.6030109@intel.com>
On Mon, Sep 15, 2014 at 2:41 PM, John Fastabend
<john.r.fastabend@intel.com> wrote:
> On 09/15/2014 02:06 PM, Cong Wang wrote:
>> Fixes: commit 331b72922c5f58d48fd ("net: sched: RCU cls_tcindex")
>> Cc: John Fastabend <john.fastabend@gmail.com>
>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>> ---
>> net/sched/cls_tcindex.c | 13 +++++++------
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
>> index a02ca72..16ec1ed 100644
>> --- a/net/sched/cls_tcindex.c
>> +++ b/net/sched/cls_tcindex.c
>> @@ -243,7 +243,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
>> */
>> cp = kzalloc(sizeof(*cp), GFP_KERNEL);
>> if (!cp)
>> - return -ENOMEM;
>> + goto errout;
>
> but you need to set 'err = -ENOMEM' then.
Yeah, I thought err is initialized to ENOMEM.
>
>>
>> cp->mask = p->mask;
>> cp->shift = p->shift;
>> @@ -257,6 +257,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
>> sizeof(*r) * cp->hash, GFP_KERNEL);
>> if (!cp->perfect)
>> goto errout;
>> + balloc = 1;
>
> Actually can we just get rid of the balloc here altogether and
> remove the checks in errout_alloc so that cp->perfect and cp->h
> are freed unconditionally? They should be NULL if they are not
> being used because of the kzalloc.
>
Hmm, but for cp->h which you don't duplicate if we free it we
free p->h too, which seems not expected. I think we probably
need to cp->h = kmemdup(p->h) as well.
^ permalink raw reply
* Re: [Patch net-next 5/5] net_sched: clean up tcindex_set_parms()
From: John Fastabend @ 2014-09-15 22:09 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: john.fastabend, David S. Miller
In-Reply-To: <1410815210-6693-6-git-send-email-xiyou.wangcong@gmail.com>
On 09/15/2014 02:06 PM, Cong Wang wrote:
> We can move the allocation down.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/sched/cls_tcindex.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
> index 4ec99a6..688ab75 100644
> --- a/net/sched/cls_tcindex.c
> +++ b/net/sched/cls_tcindex.c
> @@ -229,7 +229,6 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
> struct tcindex_filter_result new_filter_result, *old_r = r;
> struct tcindex_filter_result cr;
> struct tcindex_data *cp, *oldp;
> - struct tcindex_filter *f = NULL; /* make gcc behave */
> struct tcf_exts e;
>
> tcf_exts_init(&e, TCA_TCINDEX_ACT, TCA_TCINDEX_POLICE);
> @@ -348,12 +347,6 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
> else
> r = tcindex_lookup(cp, handle) ? : &new_filter_result;
>
> - if (r == &new_filter_result) {
> - f = kzalloc(sizeof(*f), GFP_KERNEL);
> - if (!f)
> - goto errout_alloc;
> - }
> -
It was put here to avoid having logic to unwind the state when/if the
malloc fails.
> if (tb[TCA_TCINDEX_CLASSID]) {
> cr.res.classid = nla_get_u32(tb[TCA_TCINDEX_CLASSID]);
> tcf_bind_filter(tp, &cr.res, base);
> @@ -374,6 +367,11 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
> if (r == &new_filter_result) {
> struct tcindex_filter *nfp;
> struct tcindex_filter __rcu **fp;
> + struct tcindex_filter *f;
> +
> + f = kzalloc(sizeof(*f), GFP_KERNEL);
> + if (!f)
> + goto errout_alloc;
I don't think its safe to bail out here, you've already done
the tcf_exts_change and rcu_assign_pointer() then you free it
down below leaving tp->root corrupted?
Thanks,
John
>
> f->key = handle;
> f->result = new_filter_result;
>
^ permalink raw reply
* Re: [Patch net-next 2/5] net_sched: fix memory leak in cls_tcindex
From: Cong Wang @ 2014-09-15 22:46 UTC (permalink / raw)
To: John Fastabend
Cc: Linux Kernel Network Developers, john fastabend, David S. Miller
In-Reply-To: <CAM_iQpVCJ9Hge4c3o-jzwWD+8cryoZFC49wHJH14-r9HYzzRVw@mail.gmail.com>
On Mon, Sep 15, 2014 at 3:15 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Sep 15, 2014 at 2:41 PM, John Fastabend
> <john.r.fastabend@intel.com> wrote:
>> Actually can we just get rid of the balloc here altogether and
>> remove the checks in errout_alloc so that cp->perfect and cp->h
>> are freed unconditionally? They should be NULL if they are not
>> being used because of the kzalloc.
>>
>
> Hmm, but for cp->h which you don't duplicate if we free it we
> free p->h too, which seems not expected. I think we probably
> need to cp->h = kmemdup(p->h) as well.
I can see why you didn't use kmemdup() there, because p->h
is accessible for readers since we now use RCU read lock.
I think that means we probably have to duplicate the whole
hash table including the chained elements. But it deserves
another patch, to fix this memory leak I think we should just keep
the balloc logic.
I will just fix the missing err = -ENOMEM.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Jesse Gross @ 2014-09-15 22:44 UTC (permalink / raw)
To: Tom Herbert; +Cc: Or Gerlitz, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx_+JxUn4zT+XN8DpQcCoz5Du+QtF1xzLno2m1yCwbr6ow@mail.gmail.com>
On Mon, Sep 15, 2014 at 12:15 PM, Tom Herbert <therbert@google.com> wrote:
> On Mon, Sep 15, 2014 at 11:08 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Mon, Sep 15, 2014 at 6:07 AM, Tom Herbert <therbert@google.com> wrote:
>> [...]
>>> * Notes
>>> - This patch set does not implement GSO for FOU. The UDP encapsulation
>>> code assumes TEB, so that will need to be reimplemented.
>>
>> Can you please clarify this point little further? Specifically, today
>> few NICs are
>> advertizing NETIF_F_GSO_UDP_TUNNEL when they are practically GSO
>> capable only w.r.t to VXLAN. What happens when such NIC expose this
>> cap and a large guest frame goes through GRE over UDP or alike tunneling?
>>
> My interpretation is that NETIF_F_GSO_UDP_TUNNEL means L3/L4
> encapsulation over UDP, not VXLAN. If the NIC implements things
> properly following the generic interface then I believe it should work
> with various flavors of UDP encapsulation (FOU, GUE, VXLAN, VXLAN-gpe,
> geneve, LISP, L2TP, nvgre, or whatever else people might dream up).
> This presumes that any encapsulation headers doesn't require any per
> segment update (so no GRE csum for instance). The stack will set up
> inner headers as needed, which should enough to provide to devices the
> offsets inner IP and TCP header which are needed for the the TSO
> operation (outer IP and UDP can be deduced also).
>From the NICs that I am familiar with this is mostly true. The main
part that is missing from the current implementation is a length
limit: just because the hardware can skip over headers to an offset
doesn't mean that it can do so to an arbitrary depth. For example, in
the NICs that are exposing VXLAN as NETIF_F_GSO_UDP_TUNNEL we can
probably assume that this is limited to 8 bytes. With the Intel NICs
that were just announced with Geneve support, this limit has been
increased to 64. If we add a parameter to the driver interface to
expose this then it should be generic across tunnels.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Tom Herbert @ 2014-09-15 22:59 UTC (permalink / raw)
To: Jesse Gross; +Cc: Or Gerlitz, David Miller, Linux Netdev List
In-Reply-To: <CAEP_g=_bnr94YHKd40qipmniYs80CH4g3iFiHOgZHOnDQ82Epw@mail.gmail.com>
On Mon, Sep 15, 2014 at 3:44 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Mon, Sep 15, 2014 at 12:15 PM, Tom Herbert <therbert@google.com> wrote:
>> On Mon, Sep 15, 2014 at 11:08 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>> On Mon, Sep 15, 2014 at 6:07 AM, Tom Herbert <therbert@google.com> wrote:
>>> [...]
>>>> * Notes
>>>> - This patch set does not implement GSO for FOU. The UDP encapsulation
>>>> code assumes TEB, so that will need to be reimplemented.
>>>
>>> Can you please clarify this point little further? Specifically, today
>>> few NICs are
>>> advertizing NETIF_F_GSO_UDP_TUNNEL when they are practically GSO
>>> capable only w.r.t to VXLAN. What happens when such NIC expose this
>>> cap and a large guest frame goes through GRE over UDP or alike tunneling?
>>>
>> My interpretation is that NETIF_F_GSO_UDP_TUNNEL means L3/L4
>> encapsulation over UDP, not VXLAN. If the NIC implements things
>> properly following the generic interface then I believe it should work
>> with various flavors of UDP encapsulation (FOU, GUE, VXLAN, VXLAN-gpe,
>> geneve, LISP, L2TP, nvgre, or whatever else people might dream up).
>> This presumes that any encapsulation headers doesn't require any per
>> segment update (so no GRE csum for instance). The stack will set up
>> inner headers as needed, which should enough to provide to devices the
>> offsets inner IP and TCP header which are needed for the the TSO
>> operation (outer IP and UDP can be deduced also).
>
> From the NICs that I am familiar with this is mostly true. The main
> part that is missing from the current implementation is a length
> limit: just because the hardware can skip over headers to an offset
> doesn't mean that it can do so to an arbitrary depth. For example, in
> the NICs that are exposing VXLAN as NETIF_F_GSO_UDP_TUNNEL we can
> probably assume that this is limited to 8 bytes. With the Intel NICs
> that were just announced with Geneve support, this limit has been
> increased to 64. If we add a parameter to the driver interface to
> expose this then it should be generic across tunnels.
Sounds reasonable, although I think you'll need to define precisely
what length refers to.
Tom
^ permalink raw reply
* bisected regression: 3c59x corrupts packets in 3.17-rc5
From: Meelis Roos @ 2014-09-15 23:14 UTC (permalink / raw)
To: Neil Horman; +Cc: Steffen Klassert, netdev, Linux Kernel list
Somewhere between 3.17.0-rc3 and 3.17.0-rc5 I started seeing dropped ssh
connections to a couple of test servers with dual AthlonMP (32-bit) and
3C90x family of NICs (3Com Corporation 3c980-C 10/100baseTX NIC
[Python-T] (rev 78) in one server and 3Com Corporation 3c905C-TX/TX-M
[Tornado] (rev 78) in the other server). Bisect leads to the following
commit:
98ea232cf63961fad734cc8c5e07e8915ec73073 is the first bad commit
commit 98ea232cf63961fad734cc8c5e07e8915ec73073
Author: Neil Horman <nhorman@tuxdriver.com>
Date: Thu Sep 4 06:13:38 2014 -0400
3c59x: avoid panic in boomerang_start_xmit when finding page address:
...
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised
From: Hannes Frederic Sowa @ 2014-09-15 23:15 UTC (permalink / raw)
To: Andrey Dmitrov; +Cc: netdev, Alexandra N. Kossovsky, Konstantin Ushakov
In-Reply-To: <54170FC0.6020907@oktetlabs.ru>
On Mo, 2014-09-15 at 20:11 +0400, Andrey Dmitrov wrote:
> Greetings,
>
> there is possible vulnerability in the TCP stack. Closing a socket after
> the TCP zero window advertising by peer leads to the socket stuck in
> FIN_WAIT1 state. FIN-ACK packet is not sent and not retransmitted. So
> the connection remains alive and without relation to any socket while
> the peer sends replies to the zero probe packets. It is possible to
> create a lot of connections in the same manner which will be in
> FIN_WAIT1 state forever.
>
> Linux version 3.13-1-amd64 (debian-kernel@lists.debian.org) (gcc version
> 4.8.2 (Debian 4.8.2-16) ) #1 SMP Debian 3.13.10-1 (2014-04-15)
>
> I've written a script on Lua to reproduce this issue, find it in
> attachment please. I've used it with two hosts host_A (victim) and
> host_B (attacker), which are directly connected to each other. host_A
> has lighttpd installed and runned. Actually host_A can have any opened
> TCP listener socket to be attacked. If it closes any established with
> attacker connection it will stuck in the FIN_WAIT1 state. The script
> creates a number of TCP connections with the victim and sends replies
> for the zero window probe packets.
>
> The test requires lua, tcpdump and nemesis on the host_B:
> aptitude install lua5.1 lua5.1-posix nemesis tcpdump
>
> How to run the test:
> 1. Run a httpd daemon on the host_A (I've used lighttpd).
> 2. Copy the test script attack.lua to the host_B.
> 3. Fill in the tested interfaces configuration (source, destination IP
> and MAC addresses) in the beginning of the file attack.lua. You can set
> maximum connections number in the variable *limit*, by default it is 500.
> 4. Set a fake MAC address for victim interface in host_B ARP table. It
> is to prevent host_B system replies (RST) receiving by the host_A:
> sudo arp -s <host_A IP addr> <any MAC address>
> 5. Run the test script on the host_B:
> sudo ./attack.lua
>
> After ~10 minutes you will see 500 connections in the FIN_WAIT1 state on
> the host_A:
> netstat | grep FIN_WAIT1 | wc -l
> 500
>
> Even if you close the http daemon the connections still will be alive.
Also thanks for the report.
Do you see any tcp window repair messages in dmesg? Can you send some
output of ss -oemit state FIN-WAIT-1 from the target host?
I thought they should timeout after RTO_MAX (~2 minutes).
Thanks,
Hannes
^ permalink raw reply
* Re: TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised
From: Yuchung Cheng @ 2014-09-15 23:37 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Andrey Dmitrov, netdev, Alexandra N. Kossovsky,
Konstantin Ushakov
In-Reply-To: <1410822949.5018.4.camel@localhost>
On Mon, Sep 15, 2014 at 4:15 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Mo, 2014-09-15 at 20:11 +0400, Andrey Dmitrov wrote:
>> Greetings,
>>
>> there is possible vulnerability in the TCP stack. Closing a socket after
>> the TCP zero window advertising by peer leads to the socket stuck in
>> FIN_WAIT1 state. FIN-ACK packet is not sent and not retransmitted. So
>> the connection remains alive and without relation to any socket while
>> the peer sends replies to the zero probe packets. It is possible to
>> create a lot of connections in the same manner which will be in
>> FIN_WAIT1 state forever.
>>
>> Linux version 3.13-1-amd64 (debian-kernel@lists.debian.org) (gcc version
>> 4.8.2 (Debian 4.8.2-16) ) #1 SMP Debian 3.13.10-1 (2014-04-15)
>>
>> I've written a script on Lua to reproduce this issue, find it in
>> attachment please. I've used it with two hosts host_A (victim) and
>> host_B (attacker), which are directly connected to each other. host_A
>> has lighttpd installed and runned. Actually host_A can have any opened
>> TCP listener socket to be attacked. If it closes any established with
>> attacker connection it will stuck in the FIN_WAIT1 state. The script
>> creates a number of TCP connections with the victim and sends replies
>> for the zero window probe packets.
>>
>> The test requires lua, tcpdump and nemesis on the host_B:
>> aptitude install lua5.1 lua5.1-posix nemesis tcpdump
>>
>> How to run the test:
>> 1. Run a httpd daemon on the host_A (I've used lighttpd).
>> 2. Copy the test script attack.lua to the host_B.
>> 3. Fill in the tested interfaces configuration (source, destination IP
>> and MAC addresses) in the beginning of the file attack.lua. You can set
>> maximum connections number in the variable *limit*, by default it is 500.
>> 4. Set a fake MAC address for victim interface in host_B ARP table. It
>> is to prevent host_B system replies (RST) receiving by the host_A:
>> sudo arp -s <host_A IP addr> <any MAC address>
>> 5. Run the test script on the host_B:
>> sudo ./attack.lua
>>
>> After ~10 minutes you will see 500 connections in the FIN_WAIT1 state on
>> the host_A:
>> netstat | grep FIN_WAIT1 | wc -l
>> 500
>>
>> Even if you close the http daemon the connections still will be alive.
>
> Also thanks for the report.
>
> Do you see any tcp window repair messages in dmesg? Can you send some
> output of ss -oemit state FIN-WAIT-1 from the target host?
>
> I thought they should timeout after RTO_MAX (~2 minutes).
I think the vulnerability comes from the peer/attacker actually
responds to the probes to evade the orphan counts or memory checks in
tcp_probe_timer(). This is a gray area of being legit but suspiciously
mis-behaving?
maybe have socket option TCP_USER_TIMEOUT for apps to cover conditions
like these.
>
> Thanks,
> Hannes
>
>
> --
> 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: [Patch net-next 5/5] net_sched: clean up tcindex_set_parms()
From: Cong Wang @ 2014-09-15 23:39 UTC (permalink / raw)
To: John Fastabend
Cc: Linux Kernel Network Developers, john fastabend, David S. Miller
In-Reply-To: <5417639F.10008@intel.com>
On Mon, Sep 15, 2014 at 3:09 PM, John Fastabend
<john.r.fastabend@intel.com> wrote:
> On 09/15/2014 02:06 PM, Cong Wang wrote:
>> - if (r == &new_filter_result) {
>> - f = kzalloc(sizeof(*f), GFP_KERNEL);
>> - if (!f)
>> - goto errout_alloc;
>> - }
>> -
>
> It was put here to avoid having logic to unwind the state when/if the
> malloc fails.
>
Right, some operation after that is not undoable so we have to keep it there.
So drop this one.
^ permalink raw reply
* [Patch net-next v2] net_sched: fix memory leak in cls_tcindex
From: Cong Wang @ 2014-09-15 23:43 UTC (permalink / raw)
To: netdev; +Cc: john.fastabend, David S. Miller, Cong Wang
Fixes: commit 331b72922c5f58d48fd ("net: sched: RCU cls_tcindex")
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
v2: fix err = -ENOMEM
net/sched/cls_tcindex.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index dd2d691..ee52542 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -242,8 +242,10 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
* perfect hash and hash pointers from old data.
*/
cp = kzalloc(sizeof(*cp), GFP_KERNEL);
- if (!cp)
- return -ENOMEM;
+ if (!cp) {
+ err = -ENOMEM;
+ goto errout;
+ }
cp->mask = p->mask;
cp->shift = p->shift;
@@ -257,6 +259,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
sizeof(*r) * cp->hash, GFP_KERNEL);
if (!cp->perfect)
goto errout;
+ balloc = 1;
}
cp->h = p->h;
@@ -282,9 +285,9 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
if (cp->perfect) {
if (!valid_perfect_hash(cp) ||
cp->hash > cp->alloc_hash)
- goto errout;
+ goto errout_alloc;
} else if (cp->h && cp->hash != cp->alloc_hash) {
- goto errout;
+ goto errout_alloc;
}
err = -EINVAL;
@@ -311,7 +314,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
*/
if (cp->perfect || valid_perfect_hash(cp))
if (handle >= cp->alloc_hash)
- goto errout;
+ goto errout_alloc;
err = -ENOMEM;
@@ -321,7 +324,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
cp->perfect = kcalloc(cp->hash, sizeof(*r), GFP_KERNEL);
if (!cp->perfect)
- goto errout;
+ goto errout_alloc;
for (i = 0; i < cp->hash; i++)
tcf_exts_init(&cp->perfect[i].exts,
TCA_TCINDEX_ACT,
@@ -335,7 +338,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
GFP_KERNEL);
if (!hash)
- goto errout;
+ goto errout_alloc;
cp->h = hash;
balloc = 2;
--
1.8.3.1
^ permalink raw reply related
* [Patch net-next] net_sched: fix a null pointer dereference in tcindex_set_parms()
From: Cong Wang @ 2014-09-15 23:43 UTC (permalink / raw)
To: netdev; +Cc: john.fastabend, David S. Miller, Cong Wang
In-Reply-To: <1410824623-27516-1-git-send-email-xiyou.wangcong@gmail.com>
This patch fixes the following crash:
[ 42.199159] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[ 42.200027] IP: [<ffffffff817e3fc4>] tcindex_set_parms+0x45c/0x526
[ 42.200027] PGD d2319067 PUD d4ffe067 PMD 0
[ 42.200027] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 42.200027] CPU: 0 PID: 541 Comm: tc Not tainted 3.17.0-rc4+ #603
[ 42.200027] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 42.200027] task: ffff8800d22d2670 ti: ffff8800ce790000 task.ti: ffff8800ce790000
[ 42.200027] RIP: 0010:[<ffffffff817e3fc4>] [<ffffffff817e3fc4>] tcindex_set_parms+0x45c/0x526
[ 42.200027] RSP: 0018:ffff8800ce793898 EFLAGS: 00010202
[ 42.200027] RAX: 0000000000000001 RBX: ffff8800d1786498 RCX: 0000000000000000
[ 42.200027] RDX: ffffffff82114ec8 RSI: ffffffff82114ec8 RDI: ffffffff82114ec8
[ 42.200027] RBP: ffff8800ce793958 R08: 00000000000080d0 R09: 0000000000000001
[ 42.200027] R10: ffff8800ce7939a0 R11: 0000000000000246 R12: ffff8800d017d238
[ 42.200027] R13: 0000000000000018 R14: ffff8800d017c6a0 R15: ffff8800d1786620
[ 42.200027] FS: 00007f4e24539740(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000
[ 42.200027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 42.200027] CR2: 0000000000000018 CR3: 00000000cff38000 CR4: 00000000000006f0
[ 42.200027] Stack:
[ 42.200027] ffff8800ce0949f0 0000000000000000 0000000200000003 ffff880000000000
[ 42.200027] ffff8800ce7938b8 ffff8800ce7938b8 0000000600000007 0000000000000000
[ 42.200027] ffff8800ce7938d8 ffff8800ce7938d8 0000000600000007 ffff8800ce0949f0
[ 42.200027] Call Trace:
[ 42.200027] [<ffffffff817e4169>] tcindex_change+0xdb/0xee
[ 42.200027] [<ffffffff817c16ca>] tc_ctl_tfilter+0x44d/0x63f
[ 42.200027] [<ffffffff8179d161>] rtnetlink_rcv_msg+0x181/0x194
[ 42.200027] [<ffffffff8179cf9d>] ? rtnl_lock+0x17/0x19
[ 42.200027] [<ffffffff8179cfe0>] ? __rtnl_unlock+0x17/0x17
[ 42.200027] [<ffffffff817ee296>] netlink_rcv_skb+0x49/0x8b
[ 43.462494] [<ffffffff8179cfc2>] rtnetlink_rcv+0x23/0x2a
[ 43.462494] [<ffffffff817ec8df>] netlink_unicast+0xc7/0x148
[ 43.462494] [<ffffffff817ed413>] netlink_sendmsg+0x5cb/0x63d
[ 43.462494] [<ffffffff810ad781>] ? mark_lock+0x2e/0x224
[ 43.462494] [<ffffffff817757b8>] __sock_sendmsg_nosec+0x25/0x27
[ 43.462494] [<ffffffff81778165>] sock_sendmsg+0x57/0x71
[ 43.462494] [<ffffffff81152bbd>] ? might_fault+0x57/0xa4
[ 43.462494] [<ffffffff81152c06>] ? might_fault+0xa0/0xa4
[ 43.462494] [<ffffffff81152bbd>] ? might_fault+0x57/0xa4
[ 43.462494] [<ffffffff817838fd>] ? verify_iovec+0x69/0xb7
[ 43.462494] [<ffffffff817784f8>] ___sys_sendmsg+0x21d/0x2bb
[ 43.462494] [<ffffffff81009db3>] ? native_sched_clock+0x35/0x37
[ 43.462494] [<ffffffff8109ab53>] ? sched_clock_local+0x12/0x72
[ 43.462494] [<ffffffff810ad781>] ? mark_lock+0x2e/0x224
[ 43.462494] [<ffffffff8109ada4>] ? sched_clock_cpu+0xa0/0xb9
[ 43.462494] [<ffffffff810aee37>] ? __lock_acquire+0x5fe/0xde4
[ 43.462494] [<ffffffff8119f570>] ? rcu_read_lock_held+0x36/0x38
[ 43.462494] [<ffffffff8119f75a>] ? __fcheck_files.isra.7+0x4b/0x57
[ 43.462494] [<ffffffff8119fbf2>] ? __fget_light+0x30/0x54
[ 43.462494] [<ffffffff81779012>] __sys_sendmsg+0x42/0x60
[ 43.462494] [<ffffffff81779042>] SyS_sendmsg+0x12/0x1c
[ 43.462494] [<ffffffff819d24d2>] system_call_fastpath+0x16/0x1b
'p->h' could be NULL while 'cp->h' is always update to date.
Fixes: commit 331b72922c5f58d48fd ("net: sched: RCU cls_tcindex")
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/sched/cls_tcindex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index ee52542..5054fae 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -381,7 +381,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
f->result = new_filter_result;
f->next = NULL;
- fp = p->h + (handle % p->hash);
+ fp = cp->h + (handle % cp->hash);
for (nfp = rtnl_dereference(*fp);
nfp;
fp = &nfp->next, nfp = rtnl_dereference(*fp))
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net 1/2] r8169: fix the default setting of rx vlan
From: Francois Romieu @ 2014-09-16 0:03 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2523183@RTITMBSV03.realtek.com.tw>
Hayes Wang <hayeswang@realtek.com> :
> Francois Romieu [mailto:romieu@fr.zoreil.com]
> > Sent: Saturday, September 13, 2014 3:40 AM
> [...]
> > The same fix should be relevant for NETIF_F_RXCSUM. You may thus as
> > well remove the "changed" test in __rtl8169_set_features and keep
> > everything there.
>
> In the probe function (rtl_init_one), RxChkSum has been assgined to
> tp->cp_cmd, so only the vlan setting is incorrect. Therefore, I fix
> it only. Do I still have to remove the "changed" test?
You are right, this part does work.
However it's getting messy and the code stomps CPlusCmd in rtl_open right
before it's given a chance to be read in hw_start. Something like the
untested patch below should avoid it and keep related things together.
Thoughts ?
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 7a7860a..ef2cee5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1783,33 +1783,31 @@ static void __rtl8169_set_features(struct net_device *dev,
netdev_features_t features)
{
struct rtl8169_private *tp = netdev_priv(dev);
- netdev_features_t changed = features ^ dev->features;
void __iomem *ioaddr = tp->mmio_addr;
+ u32 rx_config;
- if (!(changed & (NETIF_F_RXALL | NETIF_F_RXCSUM |
- NETIF_F_HW_VLAN_CTAG_RX)))
- return;
+ rx_config = RTL_R32(RxConfig);
+ if (features & NETIF_F_RXALL)
+ rx_config |= (AcceptErr | AcceptRunt);
+ else
+ rx_config &= ~(AcceptErr | AcceptRunt);
- if (changed & (NETIF_F_RXCSUM | NETIF_F_HW_VLAN_CTAG_RX)) {
- if (features & NETIF_F_RXCSUM)
- tp->cp_cmd |= RxChkSum;
- else
- tp->cp_cmd &= ~RxChkSum;
+ RTL_W32(RxConfig, rx_config);
- if (features & NETIF_F_HW_VLAN_CTAG_RX)
- tp->cp_cmd |= RxVlan;
- else
- tp->cp_cmd &= ~RxVlan;
+ if (features & NETIF_F_RXCSUM)
+ tp->cp_cmd |= RxChkSum;
+ else
+ tp->cp_cmd &= ~RxChkSum;
- RTL_W16(CPlusCmd, tp->cp_cmd);
- RTL_R16(CPlusCmd);
- }
- if (changed & NETIF_F_RXALL) {
- int tmp = (RTL_R32(RxConfig) & ~(AcceptErr | AcceptRunt));
- if (features & NETIF_F_RXALL)
- tmp |= (AcceptErr | AcceptRunt);
- RTL_W32(RxConfig, tmp);
- }
+ if (features & NETIF_F_HW_VLAN_CTAG_RX)
+ tp->cp_cmd |= RxVlan;
+ else
+ tp->cp_cmd &= ~RxVlan;
+
+ tp->cp_cmd |= RTL_R16(CPlusCmd) & ~(RxVlan | RxChkSum);
+
+ RTL_W16(CPlusCmd, tp->cp_cmd);
+ RTL_R16(CPlusCmd);
}
static int rtl8169_set_features(struct net_device *dev,
@@ -1817,8 +1815,11 @@ static int rtl8169_set_features(struct net_device *dev,
{
struct rtl8169_private *tp = netdev_priv(dev);
+ features &= NETIF_F_RXALL | NETIF_F_RXCSUM | NETIF_F_HW_VLAN_CTAG_RX;
+
rtl_lock_work(tp);
- __rtl8169_set_features(dev, features);
+ if (features ^ dev->features);
+ __rtl8169_set_features(dev, features);
rtl_unlock_work(tp);
return 0;
@@ -6707,12 +6708,7 @@ static int rtl_open(struct net_device *dev)
rtl8169_init_phy(dev, tp);
- if (dev->features & NETIF_F_HW_VLAN_CTAG_RX)
- tp->cp_cmd |= RxVlan;
- else
- tp->cp_cmd &= ~RxVlan;
-
- RTL_W16(CPlusCmd, tp->cp_cmd);
+ __rtl8169_set_features(dev, dev->features);
rtl_pll_power_up(tp);
@@ -7123,8 +7119,7 @@ static void rtl_hw_initialize(struct rtl8169_private *tp)
}
}
-static int
-rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
+static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
const struct rtl_cfg_info *cfg = rtl_cfg_infos + ent->driver_data;
const unsigned int region = cfg->region;
@@ -7199,7 +7194,7 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_out_mwi_2;
}
- tp->cp_cmd = RxChkSum;
+ tp->cp_cmd = 0;
if ((sizeof(dma_addr_t) > 4) &&
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
@@ -7240,13 +7235,6 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_master(pdev);
- /*
- * Pretend we are using VLANs; This bypasses a nasty bug where
- * Interrupts stop flowing on high load on 8110SCd controllers.
- */
- if (tp->mac_version == RTL_GIGA_MAC_VER_05)
- tp->cp_cmd |= RxVlan;
-
rtl_init_mdio_ops(tp);
rtl_init_pll_power_ops(tp);
rtl_init_jumbo_ops(tp);
@@ -7307,8 +7295,14 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO |
NETIF_F_HIGHDMA;
+ tp->cp_cmd |= RxChkSum | RxVlan;
+
+ /*
+ * Pretend we are using VLANs; This bypasses a nasty bug where
+ * Interrupts stop flowing on high load on 8110SCd controllers.
+ */
if (tp->mac_version == RTL_GIGA_MAC_VER_05)
- /* 8110SCd requires hardware Rx VLAN - disallow toggling */
+ /* Disallow toggling */
dev->hw_features &= ~NETIF_F_HW_VLAN_CTAG_RX;
if (tp->txd_version == RTL_TD_0)
^ permalink raw reply related
* Re: [Patch net-next v2] net_sched: fix memory leak in cls_tcindex
From: John Fastabend @ 2014-09-16 0:11 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David S. Miller
In-Reply-To: <1410824623-27516-1-git-send-email-xiyou.wangcong@gmail.com>
On 09/15/2014 04:43 PM, Cong Wang wrote:
> Fixes: commit 331b72922c5f58d48fd ("net: sched: RCU cls_tcindex")
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
>
> v2: fix err = -ENOMEM
>
> net/sched/cls_tcindex.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
> index dd2d691..ee52542 100644
> --- a/net/sched/cls_tcindex.c
> +++ b/net/sched/cls_tcindex.c
> @@ -242,8 +242,10 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
> * perfect hash and hash pointers from old data.
> */
> cp = kzalloc(sizeof(*cp), GFP_KERNEL);
> - if (!cp)
> - return -ENOMEM;
> + if (!cp) {
> + err = -ENOMEM;
> + goto errout;
> + }
Thanks for fixing up tcindex for me I see now it was missing
from my test scripts. Along with cls_bpf so I'll need to go
back and test that as well.
Acked-By: John Fastabend <john.r.fastabend@gmail.com>
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Jesse Gross @ 2014-09-16 0:15 UTC (permalink / raw)
To: Tom Herbert; +Cc: Or Gerlitz, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx8ATqggG5n-_gUr=QjOp3KeUzD4=+wNgyJBx1C24AsuUw@mail.gmail.com>
On Mon, Sep 15, 2014 at 3:59 PM, Tom Herbert <therbert@google.com> wrote:
> On Mon, Sep 15, 2014 at 3:44 PM, Jesse Gross <jesse@nicira.com> wrote:
>> On Mon, Sep 15, 2014 at 12:15 PM, Tom Herbert <therbert@google.com> wrote:
>>> On Mon, Sep 15, 2014 at 11:08 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>>> On Mon, Sep 15, 2014 at 6:07 AM, Tom Herbert <therbert@google.com> wrote:
>>>> [...]
>>>>> * Notes
>>>>> - This patch set does not implement GSO for FOU. The UDP encapsulation
>>>>> code assumes TEB, so that will need to be reimplemented.
>>>>
>>>> Can you please clarify this point little further? Specifically, today
>>>> few NICs are
>>>> advertizing NETIF_F_GSO_UDP_TUNNEL when they are practically GSO
>>>> capable only w.r.t to VXLAN. What happens when such NIC expose this
>>>> cap and a large guest frame goes through GRE over UDP or alike tunneling?
>>>>
>>> My interpretation is that NETIF_F_GSO_UDP_TUNNEL means L3/L4
>>> encapsulation over UDP, not VXLAN. If the NIC implements things
>>> properly following the generic interface then I believe it should work
>>> with various flavors of UDP encapsulation (FOU, GUE, VXLAN, VXLAN-gpe,
>>> geneve, LISP, L2TP, nvgre, or whatever else people might dream up).
>>> This presumes that any encapsulation headers doesn't require any per
>>> segment update (so no GRE csum for instance). The stack will set up
>>> inner headers as needed, which should enough to provide to devices the
>>> offsets inner IP and TCP header which are needed for the the TSO
>>> operation (outer IP and UDP can be deduced also).
>>
>> From the NICs that I am familiar with this is mostly true. The main
>> part that is missing from the current implementation is a length
>> limit: just because the hardware can skip over headers to an offset
>> doesn't mean that it can do so to an arbitrary depth. For example, in
>> the NICs that are exposing VXLAN as NETIF_F_GSO_UDP_TUNNEL we can
>> probably assume that this is limited to 8 bytes. With the Intel NICs
>> that were just announced with Geneve support, this limit has been
>> increased to 64. If we add a parameter to the driver interface to
>> expose this then it should be generic across tunnels.
>
> Sounds reasonable, although I think you'll need to define precisely
> what length refers to.
I agree, the definition is important.
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix a null pointer dereference in tcindex_set_parms()
From: John Fastabend @ 2014-09-16 0:15 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David S. Miller
In-Reply-To: <1410824623-27516-2-git-send-email-xiyou.wangcong@gmail.com>
On 09/15/2014 04:43 PM, Cong Wang wrote:
> This patch fixes the following crash:
>
> [ 42.199159] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> [ 42.200027] IP: [<ffffffff817e3fc4>] tcindex_set_parms+0x45c/0x526
> [ 42.200027] PGD d2319067 PUD d4ffe067 PMD 0
> [ 42.200027] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
> [ 42.200027] CPU: 0 PID: 541 Comm: tc Not tainted 3.17.0-rc4+ #603
> [ 42.200027] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 42.200027] task: ffff8800d22d2670 ti: ffff8800ce790000 task.ti: ffff8800ce790000
> [ 42.200027] RIP: 0010:[<ffffffff817e3fc4>] [<ffffffff817e3fc4>] tcindex_set_parms+0x45c/0x526
> [ 42.200027] RSP: 0018:ffff8800ce793898 EFLAGS: 00010202
> [ 42.200027] RAX: 0000000000000001 RBX: ffff8800d1786498 RCX: 0000000000000000
> [ 42.200027] RDX: ffffffff82114ec8 RSI: ffffffff82114ec8 RDI: ffffffff82114ec8
> [ 42.200027] RBP: ffff8800ce793958 R08: 00000000000080d0 R09: 0000000000000001
> [ 42.200027] R10: ffff8800ce7939a0 R11: 0000000000000246 R12: ffff8800d017d238
> [ 42.200027] R13: 0000000000000018 R14: ffff8800d017c6a0 R15: ffff8800d1786620
> [ 42.200027] FS: 00007f4e24539740(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000
> [ 42.200027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 42.200027] CR2: 0000000000000018 CR3: 00000000cff38000 CR4: 00000000000006f0
> [ 42.200027] Stack:
> [ 42.200027] ffff8800ce0949f0 0000000000000000 0000000200000003 ffff880000000000
> [ 42.200027] ffff8800ce7938b8 ffff8800ce7938b8 0000000600000007 0000000000000000
> [ 42.200027] ffff8800ce7938d8 ffff8800ce7938d8 0000000600000007 ffff8800ce0949f0
> [ 42.200027] Call Trace:
> [ 42.200027] [<ffffffff817e4169>] tcindex_change+0xdb/0xee
> [ 42.200027] [<ffffffff817c16ca>] tc_ctl_tfilter+0x44d/0x63f
> [ 42.200027] [<ffffffff8179d161>] rtnetlink_rcv_msg+0x181/0x194
> [ 42.200027] [<ffffffff8179cf9d>] ? rtnl_lock+0x17/0x19
> [ 42.200027] [<ffffffff8179cfe0>] ? __rtnl_unlock+0x17/0x17
> [ 42.200027] [<ffffffff817ee296>] netlink_rcv_skb+0x49/0x8b
> [ 43.462494] [<ffffffff8179cfc2>] rtnetlink_rcv+0x23/0x2a
> [ 43.462494] [<ffffffff817ec8df>] netlink_unicast+0xc7/0x148
> [ 43.462494] [<ffffffff817ed413>] netlink_sendmsg+0x5cb/0x63d
> [ 43.462494] [<ffffffff810ad781>] ? mark_lock+0x2e/0x224
> [ 43.462494] [<ffffffff817757b8>] __sock_sendmsg_nosec+0x25/0x27
> [ 43.462494] [<ffffffff81778165>] sock_sendmsg+0x57/0x71
> [ 43.462494] [<ffffffff81152bbd>] ? might_fault+0x57/0xa4
> [ 43.462494] [<ffffffff81152c06>] ? might_fault+0xa0/0xa4
> [ 43.462494] [<ffffffff81152bbd>] ? might_fault+0x57/0xa4
> [ 43.462494] [<ffffffff817838fd>] ? verify_iovec+0x69/0xb7
> [ 43.462494] [<ffffffff817784f8>] ___sys_sendmsg+0x21d/0x2bb
> [ 43.462494] [<ffffffff81009db3>] ? native_sched_clock+0x35/0x37
> [ 43.462494] [<ffffffff8109ab53>] ? sched_clock_local+0x12/0x72
> [ 43.462494] [<ffffffff810ad781>] ? mark_lock+0x2e/0x224
> [ 43.462494] [<ffffffff8109ada4>] ? sched_clock_cpu+0xa0/0xb9
> [ 43.462494] [<ffffffff810aee37>] ? __lock_acquire+0x5fe/0xde4
> [ 43.462494] [<ffffffff8119f570>] ? rcu_read_lock_held+0x36/0x38
> [ 43.462494] [<ffffffff8119f75a>] ? __fcheck_files.isra.7+0x4b/0x57
> [ 43.462494] [<ffffffff8119fbf2>] ? __fget_light+0x30/0x54
> [ 43.462494] [<ffffffff81779012>] __sys_sendmsg+0x42/0x60
> [ 43.462494] [<ffffffff81779042>] SyS_sendmsg+0x12/0x1c
> [ 43.462494] [<ffffffff819d24d2>] system_call_fastpath+0x16/0x1b
>
> 'p->h' could be NULL while 'cp->h' is always update to date.
>
> Fixes: commit 331b72922c5f58d48fd ("net: sched: RCU cls_tcindex")
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/sched/cls_tcindex.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
> index ee52542..5054fae 100644
> --- a/net/sched/cls_tcindex.c
> +++ b/net/sched/cls_tcindex.c
> @@ -381,7 +381,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
> f->result = new_filter_result;
> f->next = NULL;
>
> - fp = p->h + (handle % p->hash);
> + fp = cp->h + (handle % cp->hash);
> for (nfp = rtnl_dereference(*fp);
> nfp;
> fp = &nfp->next, nfp = rtnl_dereference(*fp))
>
Thanks again.
Acked-By: John Fastabend <john.r.fastabend@intel.com>
--
John Fastabend Intel Corporation
^ permalink raw reply
* [PATCH 3] scsi: fix build errors, SCSI_FC_ATTRS needs to depend on SCSI && NET
From: Randy Dunlap @ 2014-09-16 0:20 UTC (permalink / raw)
To: Anish Bhatt, netdev, JBottomley, David Miller
Cc: linux-scsi, mchan, eddie.wai, jim.epost
In-Reply-To: <1410813921-24400-2-git-send-email-anish@chelsio.com>
From: Randy Dunlap <rdunlap@infradead.org>
Fix build errors when CONFIG_SCSI_NETLINK is enabled but
CONFIG_NET is not enabled:
drivers/built-in.o: In function `scsi_nl_rcv_msg':
scsi_netlink.c:(.text+0x1850fa): undefined reference to `netlink_ack'
scsi_netlink.c:(.text+0x185105): undefined reference to `skb_pull'
scsi_netlink.c:(.text+0x18515d): undefined reference to `netlink_capable'
drivers/built-in.o: In function `scsi_netlink_init':
(.text+0x185244): undefined reference to `init_net'
drivers/built-in.o: In function `scsi_netlink_init':
(.text+0x185258): undefined reference to `__netlink_kernel_create'
drivers/built-in.o: In function `scsi_netlink_exit':
(.text+0x185291): undefined reference to `netlink_kernel_release'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
drivers/scsi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Based on Anish's previous SCSI_NETLINK patch.
Sorry about missing this one.
--- lnx-317-rc5.orig/drivers/scsi/Kconfig
+++ lnx-317-rc5/drivers/scsi/Kconfig
@@ -257,7 +257,7 @@ config SCSI_SPI_ATTRS
config SCSI_FC_ATTRS
tristate "FiberChannel Transport Attributes"
- depends on SCSI
+ depends on SCSI && NET
select SCSI_NETLINK
help
If you wish to export transport-specific information about
^ permalink raw reply
* linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2014-09-16 0:24 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Anish Bhatt
[-- Attachment #1: Type: text/plain, Size: 3815 bytes --]
Hi all,
After merging the net tree, today's linux-next build
(powerpc ppc64_defconfig) failed like this:
warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (SCSI_FC_ATTRS) selects SCSI_NETLINK which has unmet direct dependencies (NET)
warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (SCSI_FC_ATTRS) selects SCSI_NETLINK which has unmet direct dependencies (NET)
warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
drivers/built-in.o: In function `.scsi_nl_rcv_msg':
scsi_netlink.c:(.text+0x16455c): undefined reference to `.netlink_ack'
scsi_netlink.c:(.text+0x16456c): undefined reference to `.skb_pull'
scsi_netlink.c:(.text+0x1645e0): undefined reference to `.netlink_capable'
drivers/built-in.o: In function `.scsi_netlink_init':
(.text+0x16471c): undefined reference to `.__netlink_kernel_create'
drivers/built-in.o: In function `.scsi_netlink_exit':
(.text+0x16477c): undefined reference to `.netlink_kernel_release'
drivers/built-in.o: In function `.fc_host_post_event':
(.text+0x16ac1c): undefined reference to `.__alloc_skb'
drivers/built-in.o: In function `.fc_host_post_event':
(.text+0x16ac60): undefined reference to `.__nlmsg_put'
drivers/built-in.o: In function `.fc_host_post_event':
(.text+0x16ace0): undefined reference to `.netlink_broadcast'
drivers/built-in.o: In function `.fc_host_post_event':
(.text+0x16ad24): undefined reference to `.kfree_skb'
drivers/built-in.o: In function `.fc_host_post_vendor_event':
(.text+0x16ae48): undefined reference to `.__alloc_skb'
drivers/built-in.o: In function `.fc_host_post_vendor_event':
(.text+0x16ae90): undefined reference to `.__nlmsg_put'
drivers/built-in.o: In function `.fc_host_post_vendor_event':
(.text+0x16af1c): undefined reference to `.netlink_broadcast'
drivers/built-in.o: In function `.fc_host_post_vendor_event':
(.text+0x16af84): undefined reference to `.kfree_skb'
drivers/built-in.o:(.toc+0x0): undefined reference to `init_net'
Presumably caused by commit 5d6be6a5d486 ("scsi_netlink : Make
SCSI_NETLINK dependent on NET instead of selecting NET").
I used the version of the net tree from next-20140915 (i.e. up to
commit 9e07a422383c ("Merge branch 'bridge_vlan_filtering'")) for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [GIT PULL nf-next 00/21] Second Round of IPVS Updates for v3.18
From: Simon Horman @ 2014-09-16 0:34 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Simon Horman
Hi Pablo,
please consider these IPVS updates for v3.18.
* Add simple weighted failover scheduler
- Thanks to Kenny Mathis
* Support v6 real servers in v4 pools and vice versa
- Thanks to Alex Gartrell and Julian Anastasov
The following changes since commit 0bbe80e571c7b866afd92a98edd32a969467a7a9:
netfilter: masquerading needs to be independent of x_tables in Kconfig (2014-09-12 09:40:18 +0200)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git tags/ipvs2-for-v3.18
for you to fetch changes up to 87f2b83b77d6139a888af87352ff35894e5c5d69:
ipvs: Allow heterogeneous pools now that we support them (2014-09-16 09:03:43 +0900)
----------------------------------------------------------------
Alex Gartrell (10):
ipvs: Add destination address family to netlink interface
ipvs: Supply destination addr family to ip_vs_{lookup_dest,find_dest}
ipvs: Pass destination address family to ip_vs_trash_get_dest
ipvs: Supply destination address family to ip_vs_conn_new
ipvs: prevent mixing heterogeneous pools and synchronization
ipvs: Pull out crosses_local_route_boundary logic
ipvs: Pull out update_pmtu code
ipvs: Add generic ensure_mtu_is_adequate to handle mixed pools
ipvs: support ipv4 in ipv6 and ipv6 in ipv4 tunnel forwarding
ipvs: Allow heterogeneous pools now that we support them
Julian Anastasov (10):
ipvs: address family of LBLC entry depends on svc family
ipvs: address family of LBLCR entry depends on svc family
ipvs: use correct address family in DH logs
ipvs: use correct address family in LC logs
ipvs: use correct address family in NQ logs
ipvs: use correct address family in RR logs
ipvs: use correct address family in SED logs
ipvs: use correct address family in SH logs
ipvs: use correct address family in WLC logs
ipvs: use the new dest addr family field
Kenny Mathis (1):
ipvs: Add simple weighted failover scheduler
include/net/ip_vs.h | 15 +-
include/uapi/linux/ip_vs.h | 3 +
net/netfilter/ipvs/Kconfig | 10 +
net/netfilter/ipvs/Makefile | 1 +
net/netfilter/ipvs/ip_vs_conn.c | 74 +++++--
net/netfilter/ipvs/ip_vs_core.c | 15 +-
net/netfilter/ipvs/ip_vs_ctl.c | 112 +++++++---
net/netfilter/ipvs/ip_vs_dh.c | 2 +-
net/netfilter/ipvs/ip_vs_fo.c | 79 +++++++
net/netfilter/ipvs/ip_vs_ftp.c | 6 +-
net/netfilter/ipvs/ip_vs_lblc.c | 12 +-
net/netfilter/ipvs/ip_vs_lblcr.c | 12 +-
net/netfilter/ipvs/ip_vs_lc.c | 2 +-
net/netfilter/ipvs/ip_vs_nq.c | 3 +-
net/netfilter/ipvs/ip_vs_proto_sctp.c | 2 +-
net/netfilter/ipvs/ip_vs_proto_tcp.c | 2 +-
net/netfilter/ipvs/ip_vs_rr.c | 2 +-
net/netfilter/ipvs/ip_vs_sed.c | 3 +-
net/netfilter/ipvs/ip_vs_sh.c | 8 +-
net/netfilter/ipvs/ip_vs_sync.c | 13 +-
net/netfilter/ipvs/ip_vs_wlc.c | 3 +-
net/netfilter/ipvs/ip_vs_xmit.c | 388 +++++++++++++++++++++-------------
22 files changed, 543 insertions(+), 224 deletions(-)
create mode 100644 net/netfilter/ipvs/ip_vs_fo.c
^ permalink raw reply
* [PATCH nf-next 11/21] ipvs: address family of LBLC entry depends on svc family
From: Simon Horman @ 2014-09-16 0:34 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Alex Gartrell, Simon Horman
In-Reply-To: <1410827675-3637-1-git-send-email-horms@verge.net.au>
From: Julian Anastasov <ja@ssi.bg>
The LBLC entries should use svc->af, not dest->af.
Needed to support svc->af != dest->af.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Alex Gartrell <agartrell@fb.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_lblc.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_lblc.c b/net/netfilter/ipvs/ip_vs_lblc.c
index 547ff33..127f140 100644
--- a/net/netfilter/ipvs/ip_vs_lblc.c
+++ b/net/netfilter/ipvs/ip_vs_lblc.c
@@ -199,11 +199,11 @@ ip_vs_lblc_get(int af, struct ip_vs_lblc_table *tbl,
*/
static inline struct ip_vs_lblc_entry *
ip_vs_lblc_new(struct ip_vs_lblc_table *tbl, const union nf_inet_addr *daddr,
- struct ip_vs_dest *dest)
+ u16 af, struct ip_vs_dest *dest)
{
struct ip_vs_lblc_entry *en;
- en = ip_vs_lblc_get(dest->af, tbl, daddr);
+ en = ip_vs_lblc_get(af, tbl, daddr);
if (en) {
if (en->dest == dest)
return en;
@@ -213,8 +213,8 @@ ip_vs_lblc_new(struct ip_vs_lblc_table *tbl, const union nf_inet_addr *daddr,
if (!en)
return NULL;
- en->af = dest->af;
- ip_vs_addr_copy(dest->af, &en->addr, daddr);
+ en->af = af;
+ ip_vs_addr_copy(af, &en->addr, daddr);
en->lastuse = jiffies;
ip_vs_dest_hold(dest);
@@ -521,13 +521,13 @@ ip_vs_lblc_schedule(struct ip_vs_service *svc, const struct sk_buff *skb,
/* If we fail to create a cache entry, we'll just use the valid dest */
spin_lock_bh(&svc->sched_lock);
if (!tbl->dead)
- ip_vs_lblc_new(tbl, &iph->daddr, dest);
+ ip_vs_lblc_new(tbl, &iph->daddr, svc->af, dest);
spin_unlock_bh(&svc->sched_lock);
out:
IP_VS_DBG_BUF(6, "LBLC: destination IP address %s --> server %s:%d\n",
IP_VS_DBG_ADDR(svc->af, &iph->daddr),
- IP_VS_DBG_ADDR(svc->af, &dest->addr), ntohs(dest->port));
+ IP_VS_DBG_ADDR(dest->af, &dest->addr), ntohs(dest->port));
return dest;
}
--
2.0.1
^ permalink raw reply related
* [PATCH nf-next 13/21] ipvs: use correct address family in DH logs
From: Simon Horman @ 2014-09-16 0:34 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Alex Gartrell, Simon Horman
In-Reply-To: <1410827675-3637-1-git-send-email-horms@verge.net.au>
From: Julian Anastasov <ja@ssi.bg>
Needed to support svc->af != dest->af.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Alex Gartrell <agartrell@fb.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_dh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_dh.c b/net/netfilter/ipvs/ip_vs_dh.c
index c3b8454..6be5c53 100644
--- a/net/netfilter/ipvs/ip_vs_dh.c
+++ b/net/netfilter/ipvs/ip_vs_dh.c
@@ -234,7 +234,7 @@ ip_vs_dh_schedule(struct ip_vs_service *svc, const struct sk_buff *skb,
IP_VS_DBG_BUF(6, "DH: destination IP address %s --> server %s:%d\n",
IP_VS_DBG_ADDR(svc->af, &iph->daddr),
- IP_VS_DBG_ADDR(svc->af, &dest->addr),
+ IP_VS_DBG_ADDR(dest->af, &dest->addr),
ntohs(dest->port));
return dest;
--
2.0.1
^ permalink raw reply related
* [PATCH nf-next 14/21] ipvs: use correct address family in LC logs
From: Simon Horman @ 2014-09-16 0:34 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Alex Gartrell, Simon Horman
In-Reply-To: <1410827675-3637-1-git-send-email-horms@verge.net.au>
From: Julian Anastasov <ja@ssi.bg>
Needed to support svc->af != dest->af.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Alex Gartrell <agartrell@fb.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_lc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_lc.c b/net/netfilter/ipvs/ip_vs_lc.c
index 2bdcb1c..19a0769 100644
--- a/net/netfilter/ipvs/ip_vs_lc.c
+++ b/net/netfilter/ipvs/ip_vs_lc.c
@@ -59,7 +59,7 @@ ip_vs_lc_schedule(struct ip_vs_service *svc, const struct sk_buff *skb,
else
IP_VS_DBG_BUF(6, "LC: server %s:%u activeconns %d "
"inactconns %d\n",
- IP_VS_DBG_ADDR(svc->af, &least->addr),
+ IP_VS_DBG_ADDR(least->af, &least->addr),
ntohs(least->port),
atomic_read(&least->activeconns),
atomic_read(&least->inactconns));
--
2.0.1
^ permalink raw reply related
* [PATCH nf-next 20/21] ipvs: use the new dest addr family field
From: Simon Horman @ 2014-09-16 0:34 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Alex Gartrell, Simon Horman
In-Reply-To: <1410827675-3637-1-git-send-email-horms@verge.net.au>
From: Julian Anastasov <ja@ssi.bg>
Use the new address family field cp->daf when printing
cp->daddr in logs or connection listing.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Alex Gartrell <agartrell@fb.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_conn.c | 49 +++++++++++++++++++++++++++--------
net/netfilter/ipvs/ip_vs_core.c | 6 ++---
net/netfilter/ipvs/ip_vs_proto_sctp.c | 2 +-
net/netfilter/ipvs/ip_vs_proto_tcp.c | 2 +-
4 files changed, 43 insertions(+), 16 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 13e9cee..b0f7b62 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -27,6 +27,7 @@
#include <linux/interrupt.h>
#include <linux/in.h>
+#include <linux/inet.h>
#include <linux/net.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -77,6 +78,13 @@ static unsigned int ip_vs_conn_rnd __read_mostly;
#define CT_LOCKARRAY_SIZE (1<<CT_LOCKARRAY_BITS)
#define CT_LOCKARRAY_MASK (CT_LOCKARRAY_SIZE-1)
+/* We need an addrstrlen that works with or without v6 */
+#ifdef CONFIG_IP_VS_IPV6
+#define IP_VS_ADDRSTRLEN INET6_ADDRSTRLEN
+#else
+#define IP_VS_ADDRSTRLEN (8+1)
+#endif
+
struct ip_vs_aligned_lock
{
spinlock_t l;
@@ -588,7 +596,7 @@ ip_vs_bind_dest(struct ip_vs_conn *cp, struct ip_vs_dest *dest)
ip_vs_proto_name(cp->protocol),
IP_VS_DBG_ADDR(cp->af, &cp->caddr), ntohs(cp->cport),
IP_VS_DBG_ADDR(cp->af, &cp->vaddr), ntohs(cp->vport),
- IP_VS_DBG_ADDR(cp->af, &cp->daddr), ntohs(cp->dport),
+ IP_VS_DBG_ADDR(cp->daf, &cp->daddr), ntohs(cp->dport),
ip_vs_fwd_tag(cp), cp->state,
cp->flags, atomic_read(&cp->refcnt),
atomic_read(&dest->refcnt));
@@ -685,7 +693,7 @@ static inline void ip_vs_unbind_dest(struct ip_vs_conn *cp)
ip_vs_proto_name(cp->protocol),
IP_VS_DBG_ADDR(cp->af, &cp->caddr), ntohs(cp->cport),
IP_VS_DBG_ADDR(cp->af, &cp->vaddr), ntohs(cp->vport),
- IP_VS_DBG_ADDR(cp->af, &cp->daddr), ntohs(cp->dport),
+ IP_VS_DBG_ADDR(cp->daf, &cp->daddr), ntohs(cp->dport),
ip_vs_fwd_tag(cp), cp->state,
cp->flags, atomic_read(&cp->refcnt),
atomic_read(&dest->refcnt));
@@ -754,7 +762,7 @@ int ip_vs_check_template(struct ip_vs_conn *ct)
ntohs(ct->cport),
IP_VS_DBG_ADDR(ct->af, &ct->vaddr),
ntohs(ct->vport),
- IP_VS_DBG_ADDR(ct->af, &ct->daddr),
+ IP_VS_DBG_ADDR(ct->daf, &ct->daddr),
ntohs(ct->dport));
/*
@@ -1051,6 +1059,7 @@ static int ip_vs_conn_seq_show(struct seq_file *seq, void *v)
struct net *net = seq_file_net(seq);
char pe_data[IP_VS_PENAME_MAXLEN + IP_VS_PEDATA_MAXLEN + 3];
size_t len = 0;
+ char dbuf[IP_VS_ADDRSTRLEN];
if (!ip_vs_conn_net_eq(cp, net))
return 0;
@@ -1065,24 +1074,32 @@ static int ip_vs_conn_seq_show(struct seq_file *seq, void *v)
pe_data[len] = '\0';
#ifdef CONFIG_IP_VS_IPV6
+ if (cp->daf == AF_INET6)
+ snprintf(dbuf, sizeof(dbuf), "%pI6", &cp->daddr.in6);
+ else
+#endif
+ snprintf(dbuf, sizeof(dbuf), "%08X",
+ ntohl(cp->daddr.ip));
+
+#ifdef CONFIG_IP_VS_IPV6
if (cp->af == AF_INET6)
seq_printf(seq, "%-3s %pI6 %04X %pI6 %04X "
- "%pI6 %04X %-11s %7lu%s\n",
+ "%s %04X %-11s %7lu%s\n",
ip_vs_proto_name(cp->protocol),
&cp->caddr.in6, ntohs(cp->cport),
&cp->vaddr.in6, ntohs(cp->vport),
- &cp->daddr.in6, ntohs(cp->dport),
+ dbuf, ntohs(cp->dport),
ip_vs_state_name(cp->protocol, cp->state),
(cp->timer.expires-jiffies)/HZ, pe_data);
else
#endif
seq_printf(seq,
"%-3s %08X %04X %08X %04X"
- " %08X %04X %-11s %7lu%s\n",
+ " %s %04X %-11s %7lu%s\n",
ip_vs_proto_name(cp->protocol),
ntohl(cp->caddr.ip), ntohs(cp->cport),
ntohl(cp->vaddr.ip), ntohs(cp->vport),
- ntohl(cp->daddr.ip), ntohs(cp->dport),
+ dbuf, ntohs(cp->dport),
ip_vs_state_name(cp->protocol, cp->state),
(cp->timer.expires-jiffies)/HZ, pe_data);
}
@@ -1120,6 +1137,7 @@ static const char *ip_vs_origin_name(unsigned int flags)
static int ip_vs_conn_sync_seq_show(struct seq_file *seq, void *v)
{
+ char dbuf[IP_VS_ADDRSTRLEN];
if (v == SEQ_START_TOKEN)
seq_puts(seq,
@@ -1132,12 +1150,21 @@ static int ip_vs_conn_sync_seq_show(struct seq_file *seq, void *v)
return 0;
#ifdef CONFIG_IP_VS_IPV6
+ if (cp->daf == AF_INET6)
+ snprintf(dbuf, sizeof(dbuf), "%pI6", &cp->daddr.in6);
+ else
+#endif
+ snprintf(dbuf, sizeof(dbuf), "%08X",
+ ntohl(cp->daddr.ip));
+
+#ifdef CONFIG_IP_VS_IPV6
if (cp->af == AF_INET6)
- seq_printf(seq, "%-3s %pI6 %04X %pI6 %04X %pI6 %04X %-11s %-6s %7lu\n",
+ seq_printf(seq, "%-3s %pI6 %04X %pI6 %04X "
+ "%s %04X %-11s %-6s %7lu\n",
ip_vs_proto_name(cp->protocol),
&cp->caddr.in6, ntohs(cp->cport),
&cp->vaddr.in6, ntohs(cp->vport),
- &cp->daddr.in6, ntohs(cp->dport),
+ dbuf, ntohs(cp->dport),
ip_vs_state_name(cp->protocol, cp->state),
ip_vs_origin_name(cp->flags),
(cp->timer.expires-jiffies)/HZ);
@@ -1145,11 +1172,11 @@ static int ip_vs_conn_sync_seq_show(struct seq_file *seq, void *v)
#endif
seq_printf(seq,
"%-3s %08X %04X %08X %04X "
- "%08X %04X %-11s %-6s %7lu\n",
+ "%s %04X %-11s %-6s %7lu\n",
ip_vs_proto_name(cp->protocol),
ntohl(cp->caddr.ip), ntohs(cp->cport),
ntohl(cp->vaddr.ip), ntohs(cp->vport),
- ntohl(cp->daddr.ip), ntohs(cp->dport),
+ dbuf, ntohs(cp->dport),
ip_vs_state_name(cp->protocol, cp->state),
ip_vs_origin_name(cp->flags),
(cp->timer.expires-jiffies)/HZ);
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 1f6ecb7..990decb 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -492,9 +492,9 @@ ip_vs_schedule(struct ip_vs_service *svc, struct sk_buff *skb,
IP_VS_DBG_BUF(6, "Schedule fwd:%c c:%s:%u v:%s:%u "
"d:%s:%u conn->flags:%X conn->refcnt:%d\n",
ip_vs_fwd_tag(cp),
- IP_VS_DBG_ADDR(svc->af, &cp->caddr), ntohs(cp->cport),
- IP_VS_DBG_ADDR(svc->af, &cp->vaddr), ntohs(cp->vport),
- IP_VS_DBG_ADDR(svc->af, &cp->daddr), ntohs(cp->dport),
+ IP_VS_DBG_ADDR(cp->af, &cp->caddr), ntohs(cp->cport),
+ IP_VS_DBG_ADDR(cp->af, &cp->vaddr), ntohs(cp->vport),
+ IP_VS_DBG_ADDR(cp->daf, &cp->daddr), ntohs(cp->dport),
cp->flags, atomic_read(&cp->refcnt));
ip_vs_conn_stats(cp, svc);
diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
index 2f7ea75..5b84c0b 100644
--- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
@@ -432,7 +432,7 @@ set_sctp_state(struct ip_vs_proto_data *pd, struct ip_vs_conn *cp,
pd->pp->name,
((direction == IP_VS_DIR_OUTPUT) ?
"output " : "input "),
- IP_VS_DBG_ADDR(cp->af, &cp->daddr),
+ IP_VS_DBG_ADDR(cp->daf, &cp->daddr),
ntohs(cp->dport),
IP_VS_DBG_ADDR(cp->af, &cp->caddr),
ntohs(cp->cport),
diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c b/net/netfilter/ipvs/ip_vs_proto_tcp.c
index e3a6972..8e92beb 100644
--- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
@@ -510,7 +510,7 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct ip_vs_conn *cp,
th->fin ? 'F' : '.',
th->ack ? 'A' : '.',
th->rst ? 'R' : '.',
- IP_VS_DBG_ADDR(cp->af, &cp->daddr),
+ IP_VS_DBG_ADDR(cp->daf, &cp->daddr),
ntohs(cp->dport),
IP_VS_DBG_ADDR(cp->af, &cp->caddr),
ntohs(cp->cport),
--
2.0.1
^ permalink raw reply related
* [PATCHv4 net-next 0/3] sunvnet: add jumbo frames support
From: David L Stevens @ 2014-09-16 0:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This patch set updates the sunvnet driver to version 1.6 of the VIO protocol
to support per-port exchange of MTU information and allow non-standard MTU
sizes, including jumbo frames.
Using large MTUs shows a > 4X throughput improvement Linux-Solaris
and > 8X throughput improvement Linux-Linux.
Changes from v3:
- added version functions per Dave Miller <davem@davemloft.net>
- moved rmtu to vnet_port per Dave Miller <davem@davemloft.net>
- explicitly set options bits and capability flags to 0 per
Raghuram Kothakota <Raghuram.Kothakota@oracle.com>
Changes from v2:
- make checkpatch clean
Changes from v1:
- fix brace formatting per Dave Miller <davem@davemloft.net>
David L Stevens (3):
sunvnet: upgrade to VIO protocol version 1.6
sunvnet: allow admin to set sunvnet MTU
sunvnet: generate ICMP PTMUD messages for smaller port MTUs
arch/sparc/include/asm/vio.h | 44 +++++++++++-
arch/sparc/kernel/viohs.c | 14 +++-
drivers/net/ethernet/sun/sunvnet.c | 144 +++++++++++++++++++++++++++++++-----
drivers/net/ethernet/sun/sunvnet.h | 3 +
4 files changed, 182 insertions(+), 23 deletions(-)
^ permalink raw reply
* [PATCH nf-next 01/21] ipvs: Add simple weighted failover scheduler
From: Simon Horman @ 2014-09-16 0:34 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Kenny Mathis, Simon Horman
In-Reply-To: <1410827675-3637-1-git-send-email-horms@verge.net.au>
From: Kenny Mathis <kmathis@chokepoint.net>
Add simple weighted IPVS failover support to the Linux kernel. All
other scheduling modules implement some form of load balancing, while
this offers a simple failover solution. Connections are directed to
the appropriate server based solely on highest weight value and server
availability. Tested functionality with keepalived.
Signed-off-by: Kenny Mathis <kmathis@chokepoint.net>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/Kconfig | 10 ++++++
net/netfilter/ipvs/Makefile | 1 +
net/netfilter/ipvs/ip_vs_fo.c | 79 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 90 insertions(+)
create mode 100644 net/netfilter/ipvs/ip_vs_fo.c
diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
index 0c3b167..3b6929d 100644
--- a/net/netfilter/ipvs/Kconfig
+++ b/net/netfilter/ipvs/Kconfig
@@ -152,6 +152,16 @@ config IP_VS_WLC
If you want to compile it in kernel, say Y. To compile it as a
module, choose M here. If unsure, say N.
+config IP_VS_FO
+ tristate "weighted failover scheduling"
+ ---help---
+ The weighted failover scheduling algorithm directs network
+ connections to the server with the highest weight that is
+ currently available.
+
+ If you want to compile it in kernel, say Y. To compile it as a
+ module, choose M here. If unsure, say N.
+
config IP_VS_LBLC
tristate "locality-based least-connection scheduling"
---help---
diff --git a/net/netfilter/ipvs/Makefile b/net/netfilter/ipvs/Makefile
index 34ee602..38b2723 100644
--- a/net/netfilter/ipvs/Makefile
+++ b/net/netfilter/ipvs/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_IP_VS_RR) += ip_vs_rr.o
obj-$(CONFIG_IP_VS_WRR) += ip_vs_wrr.o
obj-$(CONFIG_IP_VS_LC) += ip_vs_lc.o
obj-$(CONFIG_IP_VS_WLC) += ip_vs_wlc.o
+obj-$(CONFIG_IP_VS_FO) += ip_vs_fo.o
obj-$(CONFIG_IP_VS_LBLC) += ip_vs_lblc.o
obj-$(CONFIG_IP_VS_LBLCR) += ip_vs_lblcr.o
obj-$(CONFIG_IP_VS_DH) += ip_vs_dh.o
diff --git a/net/netfilter/ipvs/ip_vs_fo.c b/net/netfilter/ipvs/ip_vs_fo.c
new file mode 100644
index 0000000..6a2647d
--- /dev/null
+++ b/net/netfilter/ipvs/ip_vs_fo.c
@@ -0,0 +1,79 @@
+/*
+ * IPVS: Weighted Fail Over module
+ *
+ * Authors: Kenny Mathis <kmathis@chokepoint.net>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Changes:
+ * Kenny Mathis : added initial functionality based on weight
+ *
+ */
+
+#define KMSG_COMPONENT "IPVS"
+#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+
+#include <net/ip_vs.h>
+
+/* Weighted Fail Over Module */
+static struct ip_vs_dest *
+ip_vs_fo_schedule(struct ip_vs_service *svc, const struct sk_buff *skb,
+ struct ip_vs_iphdr *iph)
+{
+ struct ip_vs_dest *dest, *hweight = NULL;
+ int hw = 0; /* Track highest weight */
+
+ IP_VS_DBG(6, "ip_vs_fo_schedule(): Scheduling...\n");
+
+ /* Basic failover functionality
+ * Find virtual server with highest weight and send it traffic
+ */
+ list_for_each_entry_rcu(dest, &svc->destinations, n_list) {
+ if (!(dest->flags & IP_VS_DEST_F_OVERLOAD) &&
+ atomic_read(&dest->weight) > hw) {
+ hweight = dest;
+ hw = atomic_read(&dest->weight);
+ }
+ }
+
+ if (hweight) {
+ IP_VS_DBG_BUF(6, "FO: server %s:%u activeconns %d weight %d\n",
+ IP_VS_DBG_ADDR(svc->af, &hweight->addr),
+ ntohs(hweight->port),
+ atomic_read(&hweight->activeconns),
+ atomic_read(&hweight->weight));
+ return hweight;
+ }
+
+ ip_vs_scheduler_err(svc, "no destination available");
+ return NULL;
+}
+
+static struct ip_vs_scheduler ip_vs_fo_scheduler = {
+ .name = "fo",
+ .refcnt = ATOMIC_INIT(0),
+ .module = THIS_MODULE,
+ .n_list = LIST_HEAD_INIT(ip_vs_fo_scheduler.n_list),
+ .schedule = ip_vs_fo_schedule,
+};
+
+static int __init ip_vs_fo_init(void)
+{
+ return register_ip_vs_scheduler(&ip_vs_fo_scheduler);
+}
+
+static void __exit ip_vs_fo_cleanup(void)
+{
+ unregister_ip_vs_scheduler(&ip_vs_fo_scheduler);
+ synchronize_rcu();
+}
+
+module_init(ip_vs_fo_init);
+module_exit(ip_vs_fo_cleanup);
+MODULE_LICENSE("GPL");
--
2.0.1
^ 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