* Re: [PATCH net-next] tcp:Remove redundant code entering quickack mode
From: David Miller @ 2012-04-14 19:26 UTC (permalink / raw)
To: fbl; +Cc: subramanian.vijay, netdev
In-Reply-To: <20120414020103.302f2c66@asterix.rh>
From: Flavio Leitner <fbl@redhat.com>
Date: Sat, 14 Apr 2012 02:01:03 -0300
> On Fri, 13 Apr 2012 16:23:59 -0700
> Vijay Subramanian <subramanian.vijay@gmail.com> wrote:
>
>> tcp_enter_quickack_mode() already calls tcp_incr_quickack() and sets
>> icsk->icsk_ack.ato to TCP_ATO_MIN. This patch removes the duplication.
>>
>> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
>
> Reviewed-by: Flavio Leitner <fbl@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: start slaves with link down for ARP monitor
From: Michal Kubecek @ 2012-04-14 19:25 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Flavio Leitner, netdev, Andy Gospodarek
In-Reply-To: <9048.1334380877@death.nxdomain>
On Fri, Apr 13, 2012 at 10:21:17PM -0700, Jay Vosburgh wrote:
>
> The functional part I'm not sure about yet is if the this will
> cause slave devices with fast autoneg to wait for an ARP monitor cycle
> before going link up according to ARP monitor.
>
> I think this may work better if the initial slave state is set
> to whatever netif_carrier_ok() says, instead of unconditionally up or
> down.
This would mean the initial state would be always up for drivers not
supporting netif_carrier_ok(). But as far as I can see, only a few such
drivers are left and they are not very frequent ones. So I agree it will
be less harm to keep starting with up link state for these drivers than
to introduce an unnecessary delay for cards/driver which are fast enough.
I'll send updated version of the patch after I test it.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH 3/3] net/wan: use module_pci_driver
From: David Miller @ 2012-04-14 19:20 UTC (permalink / raw)
To: axel.lin; +Cc: netdev, romieu
In-Reply-To: <1334378481.2862.4.camel@phoenix>
From: Axel Lin <axel.lin@gmail.com>
Date: Sat, 14 Apr 2012 12:41:21 +0800
> This patch converts the drivers in drivers/net/wan/* to use
> module_pci_driver() macro which makes the code smaller and a bit simpler.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] net/tokenring: use module_pci_driver
From: David Miller @ 2012-04-14 19:20 UTC (permalink / raw)
To: axel.lin; +Cc: netdev, dhowells
In-Reply-To: <1334378417.2862.3.camel@phoenix>
From: Axel Lin <axel.lin@gmail.com>
Date: Sat, 14 Apr 2012 12:40:17 +0800
> This patch converts the drivers in drivers/net/tokenring/* to use
> module_pci_driver() macro which makes the code smaller and a bit simpler.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: David Howells <dhowells@redhat.com>
Applied.
^ permalink raw reply
* Re: [net-next 0/6][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-04-14 19:18 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1334394991-5839-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 14 Apr 2012 02:16:25 -0700
> This series of patches contains updates for e100, e1000e, igb and
> ixgbe. The e100 patches from Richard Cochran complete the
> time stamping support for e100.
>
> The following are changes since commit 64d683c5825003ffb3b127057a165e6bfc26691e:
> bonding: Fixup get_tx_queue() op second arg type.
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Also pulled, thanks a lot.
^ permalink raw reply
* Re: [net 0/2][pull request] Intel Wired LAN Driver updates
From: David Miller @ 2012-04-14 19:17 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1334393478-31885-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 14 Apr 2012 01:51:16 -0700
> This series of patches contains fixes for e1000e and ixgbe.
>
> The following are changes since commit 3c5e979bd037888dd7d722da22da4b43659af485:
> net: smsc911x: fix skb handling in receive path
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] bonding: start slaves with link down for ARP monitor
From: Michal Kubecek @ 2012-04-14 19:09 UTC (permalink / raw)
To: Flavio Leitner; +Cc: netdev, Jay Vosburgh, Andy Gospodarek
In-Reply-To: <20120414015319.11e196d4@asterix.rh>
On Sat, Apr 14, 2012 at 01:53:19AM -0300, Flavio Leitner wrote:
> On Thu, 12 Apr 2012 20:38:09 +0200
> Michal Kubecek <mkubecek@suse.cz> wrote:
> > new_slave->last_arp_rx = jiffies;
> > + if (bond->params.arp_interval)
> > + new_slave->last_arp_rx -=
> > + (msecs_to_jiffies(bond->params.arp_interval) + 1);
>
>
> I don't see the point of checking bond->params.arp_interval.
> Why not simply:
>
> - new_slave->last_arp_rx = jiffies;
> + /* put it behind to avoid fake initial link up detection */
> + new_slave->last_arp_rx = jiffies -
> + (msecs_to_jiffies(bond->params.arp_interval) + 1);
The idea was to avoid calculation when ARP monitoring is off. But
thinking it over again, this part of the code is not that performance
critical and the conditional jump may be in fact worse than the two
instructions it would jump over.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH 2/4] ipgre: follow state of lower device
From: David Miller @ 2012-04-14 18:53 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20120412163142.544953001@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 12 Apr 2012 09:31:17 -0700
> GRE tunnels like other layered devices should propogate
> carrier and RFC2863 state from lower device to tunnel.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Like others I don't like the ugly hash traversal.
A small hash on ifindex, iflink, or whatever ought to be easy and make
the code look much nicer.
Longer term project is that a lot of this tunneling code can be
commonized at some point.
^ permalink raw reply
* Re: [PATCH 1/4] tunnel: implement 64 bits statistics
From: David Miller @ 2012-04-14 18:51 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20120412163142.441631834@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 12 Apr 2012 09:31:16 -0700
> Convert the per-cpu statistics kept for GRE, IPIP, and SIT tunnels
> to use 64 bit statistics.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Looks good, applied.
^ permalink raw reply
* Re: [net 2/2] ixgbe: fix WoL issue with fiber
From: Jan Ceuleers @ 2012-04-14 18:47 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Don Skidmore, netdev, gospo, sassmann
In-Reply-To: <1334393478-31885-3-git-send-email-jeffrey.t.kirsher@intel.com>
Jeff Kirsher wrote:
> From: Don Skidmore<donald.c.skidmore@intel.com>
>
> There are times we turn of the laser before shutdown. This is a bad thing
> if we want to wake on lan to work so now we make sure the laser is on
> before shutdown if we support WoL.
I'm ever-so-sorry if this is a silly question, but:
WOL is receive-only, right? Why does the laser need to be on?
Thanks, Jan
^ permalink raw reply
* Re: [PATCH 00/12] atl1c: update hardware settings -v1
From: David Miller @ 2012-04-14 18:43 UTC (permalink / raw)
To: xiong; +Cc: netdev, linux-kernel, qca-linux-team, nic-devel
In-Reply-To: <1334397568-8444-1-git-send-email-xiong@qca.qualcomm.com>
I'm ignoring this entire submission, you'll need to resend it all
again once you deal with our feedback properly.
^ permalink raw reply
* Re: [PATCH 04/12] atl1c: remove VPD register
From: David Miller @ 2012-04-14 18:43 UTC (permalink / raw)
To: xiong; +Cc: netdev, linux-kernel, qca-linux-team, nic-devel
In-Reply-To: <1334397568-8444-5-git-send-email-xiong@qca.qualcomm.com>
From: xiong <xiong@qca.qualcomm.com>
Date: Sat, 14 Apr 2012 17:59:20 +0800
> VPD register is only used for L1(devid=PCI_DEVICE_ID_ATTANSIC_L1) to
> access external NV-memory.
> l1c & later chip doesn't use it any more.
> no special userspace tool interpret the dumpped registers.
> dumpping them via ethtool is just for debug.
>
> Signed-off-by: xiong <xiong@qca.qualcomm.com>
> Tested-by: Liu David <dwliu@qca.qualcomm.com>
I'm really disappointed that you're posting this patch again and
completely ignoring our feedback.
You're making this code buggy, and you're make me extremely irritated.
What's the point of our feedback if you just completely ignore it?
You can't crap up the register dump like this, you have to make
several modifications if you want to change the layout in any
way:
1) You have to adjust AT_REGS_LEN, because you're reporting one
less register.
2) You have to adjust the offsets at the end of atl1c_get_regs(),
the ones that explicitly use regs_buff[73] and regs_buf[74],
otherwise you're leaving a gap between that area that's filled
in using those p++ pointer increments and the entries filled
in with these explicit offsets into reg_buff[].
3) You have to increment the register dump version, via the struct
ethtool_regs 'version' field, so that userland programs can know
that you've changed it.
So, tell me, are you going to completely ignore our feedback on
this issue again?
^ permalink raw reply
* Re: [PATCH 04/37] atl1c: remove VPD register
From: David Miller @ 2012-04-14 18:24 UTC (permalink / raw)
To: bhutchings; +Cc: xiong, netdev, linux-kernel, qca-linux-team, nic-devel
In-Reply-To: <1334413369.7150.422.camel@deadeye>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Sat, 14 Apr 2012 15:22:49 +0100
> On Sat, 2012-04-14 at 09:12 +0000, Huang, Xiong wrote:
>>
>> > -----Original Message-----
>> > From: David Miller [mailto:davem@davemloft.net]
>> > Sent: Saturday, April 14, 2012 8:46
>> > To: Huang, Xiong
>> > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; qca-linux-team; nic-
>> > devel
>> > Subject: Re: [PATCH 04/37] atl1c: remove VPD register
>> >
>> > From: xiong <xiong@qca.qualcomm.com>
>> > Date: Fri, 13 Apr 2012 08:14:29 +0800
>> >
>> > > VPD register is only used for L1(devid=PCI_DEVICE_ID_ATTANSIC_L1) to
>> > > access external NV-memory.
>> > > l1c & later chip doesn't use it any more.
>> > >
>> > > Signed-off-by: xiong <xiong@qca.qualcomm.com>
>> > > Tested-by: Liu David <dwliu@qca.qualcomm.com>
>> >
>> > You just broke ethtool register dumps with this change.
>> >
>> > Now, all the initial registers are reported offset by one entry, yet the last two are
>> > still reported in their original spots.
>> >
>> > This layout is exposed to userspace, and interpreted by tools, and you cannot
>> > change it.
>> >
>> > If this register always reports some value, you should just keep it there in the
>> > dumps.
>> >
>> The VPD register doesn't report anything :(, just a dummy register now.
>> we don't have any special tools in userspace to explain the dumped registers.
>> Actually the purpose of dumping these registers via ethtool is just for debug.
> [...]
>
> Of course, the whole purpose of the operation is for debugging. But you
> should bump the dump version number (currently 0) every time you change
> the offsets of registers in the dump.
And also update the size, and not leave any holes between the actually
used register slots, etc.
^ permalink raw reply
* Re: Question about tlv message support and encoding
From: Spiridon Gasteratos @ 2012-04-14 17:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20120414100302.051c5298@nehalam.linuxnetplumber.net>
thank you
On Sat, Apr 14, 2012 at 8:03 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Sat, 14 Apr 2012 19:18:16 +0300
> Spyros Gasteratos <spyrosgaster@gmail.com> wrote:
>
>> Hello everyone
>>
>> Do you know if the kernel has any support for the construction and encoding
>> of type/length/value (TLV) or other information element messages?
>> if it has(or if you dont know) where can I find a list or more documentation?
>
>
> netlink.h
^ permalink raw reply
* Re: Question about tlv message support and encoding
From: Stephen Hemminger @ 2012-04-14 17:03 UTC (permalink / raw)
To: Spyros Gasteratos; +Cc: netdev
In-Reply-To: <CA+wR77pwetwv7W3r6EB261mMKAZj6npjNE_nnXKeTQSnfCwe7w@mail.gmail.com>
On Sat, 14 Apr 2012 19:18:16 +0300
Spyros Gasteratos <spyrosgaster@gmail.com> wrote:
> Hello everyone
>
> Do you know if the kernel has any support for the construction and encoding
> of type/length/value (TLV) or other information element messages?
> if it has(or if you dont know) where can I find a list or more documentation?
netlink.h
^ permalink raw reply
* [PATCH v3 2/2] netfilter: ipvs: use GFP_KERNEL allocation where possible
From: Sasha Levin @ 2012-04-14 16:37 UTC (permalink / raw)
To: wensong, horms, ja, kaber, davem
Cc: davej, netdev, lvs-devel, netfilter-devel, linux-kernel,
Sasha Levin
In-Reply-To: <1334421467-30313-1-git-send-email-levinsasha928@gmail.com>
Use GFP_KERNEL instead of GFP_ATOMIC when registering an ipvs protocol.
This is safe since it will always run from a process context.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
net/netfilter/ipvs/ip_vs_proto.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
index a62360e..307dbbb 100644
--- a/net/netfilter/ipvs/ip_vs_proto.c
+++ b/net/netfilter/ipvs/ip_vs_proto.c
@@ -68,7 +68,7 @@ register_ip_vs_proto_netns(struct net *net, struct ip_vs_protocol *pp)
struct netns_ipvs *ipvs = net_ipvs(net);
unsigned hash = IP_VS_PROTO_HASH(pp->protocol);
struct ip_vs_proto_data *pd =
- kzalloc(sizeof(struct ip_vs_proto_data), GFP_ATOMIC);
+ kzalloc(sizeof(struct ip_vs_proto_data), GFP_KERNEL);
if (!pd)
return -ENOMEM;
--
1.7.8.5
^ permalink raw reply related
* [PATCH v3 1/2] netfilter: ipvs: Verify that IP_VS protocol has been registered
From: Sasha Levin @ 2012-04-14 16:37 UTC (permalink / raw)
To: wensong, horms, ja, kaber, davem
Cc: davej, netdev, lvs-devel, netfilter-devel, linux-kernel,
Sasha Levin
The registration of a protocol might fail, there were no checks
and all registrations were assumed to be correct. This lead to
NULL ptr dereferences when apps tried registering.
For example:
[ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
[ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
[ 1293.227038] CPU 1
[ 1293.227038] Pid: 19609, comm: trinity Tainted: G W 3.4.0-rc1-next-20120405-sasha-dirty #57
[ 1293.227038] RIP: 0010:[<ffffffff822aacb0>] [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] RSP: 0018:ffff880038c1dd18 EFLAGS: 00010286
[ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
[ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
[ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
[ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
[ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
[ 1293.227038] FS: 00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
[ 1293.227038] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
[ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
[ 1293.227038] Stack:
[ 1293.227038] ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
[ 1293.227038] ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
[ 1293.227038] 0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
[ 1293.227038] Call Trace:
[ 1293.227038] [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
[ 1293.227038] [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
[ 1293.227038] [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
[ 1293.227038] [<ffffffff821c9060>] ops_init+0x80/0x90
[ 1293.227038] [<ffffffff821c90cb>] setup_net+0x5b/0xe0
[ 1293.227038] [<ffffffff821c9416>] copy_net_ns+0x76/0x100
[ 1293.227038] [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
[ 1293.227038] [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
[ 1293.227038] [<ffffffff810afd1f>] sys_unshare+0xff/0x290
[ 1293.227038] [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 1293.227038] [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
[ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
[ 1293.227038] RIP [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] RSP <ffff880038c1dd18>
[ 1293.227038] CR2: 0000000000000018
[ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
[ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
net/netfilter/ipvs/ip_vs_proto.c | 27 ++++++++++++++++++---------
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
index f843a88..a62360e 100644
--- a/net/netfilter/ipvs/ip_vs_proto.c
+++ b/net/netfilter/ipvs/ip_vs_proto.c
@@ -59,9 +59,6 @@ static int __used __init register_ip_vs_protocol(struct ip_vs_protocol *pp)
return 0;
}
-#if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP) || \
- defined(CONFIG_IP_VS_PROTO_SCTP) || defined(CONFIG_IP_VS_PROTO_AH) || \
- defined(CONFIG_IP_VS_PROTO_ESP)
/*
* register an ipvs protocols netns related data
*/
@@ -86,7 +83,6 @@ register_ip_vs_proto_netns(struct net *net, struct ip_vs_protocol *pp)
return 0;
}
-#endif
/*
* unregister an ipvs protocol
@@ -316,22 +312,35 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
*/
int __net_init ip_vs_protocol_net_init(struct net *net)
{
+ int i, ret;
+ static struct ip_vs_protocol *protos[] = {
#ifdef CONFIG_IP_VS_PROTO_TCP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
+ &ip_vs_protocol_tcp,
#endif
#ifdef CONFIG_IP_VS_PROTO_UDP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
+ &ip_vs_protocol_udp,
#endif
#ifdef CONFIG_IP_VS_PROTO_SCTP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_sctp);
+ &ip_vs_protocol_sctp,
#endif
#ifdef CONFIG_IP_VS_PROTO_AH
- register_ip_vs_proto_netns(net, &ip_vs_protocol_ah);
+ &ip_vs_protocol_ah,
#endif
#ifdef CONFIG_IP_VS_PROTO_ESP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_esp);
+ &ip_vs_protocol_esp,
#endif
+ };
+
+ for (i = 0; i < ARRAY_SIZE(protos); i++) {
+ ret = register_ip_vs_proto_netns(net, protos[i]);
+ if (ret < 0)
+ goto cleanup;
+ }
return 0;
+
+cleanup:
+ ip_vs_protocol_net_cleanup(net);
+ return ret;
}
void __net_exit ip_vs_protocol_net_cleanup(struct net *net)
--
1.7.8.5
^ permalink raw reply related
* Question about tlv message support and encoding
From: Spyros Gasteratos @ 2012-04-14 16:18 UTC (permalink / raw)
To: netdev
Hello everyone
Do you know if the kernel has any support for the construction and encoding
of type/length/value (TLV) or other information element messages?
if it has(or if you dont know) where can I find a list or more documentation?
^ permalink raw reply
* Re: via-rhine: Problem with lost link after a while
From: Bjarke Istrup Pedersen @ 2012-04-14 15:10 UTC (permalink / raw)
To: Francois Romieu
Cc: linux-kernel, netdev, Svenning Sørensen, Andreas Mohr
In-Reply-To: <20120414100601.GA11698@electric-eye.fr.zoreil.com>
14. apr. 2012 12.06 skrev Francois Romieu <romieu@fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
> [...]
>> I've been testing v3.4-rc2 with this patch applied for the past few
>> days, with alot of trafic across, both incoming and outgoing, with VPN
>> which is normally what can trigger problems, and it seems rock solid
>> :o)
>
> Thanks.
>
>> Do you need me to do any specific testing of this patch?
>
> See below.
>
> Changes of behavior should be reported for this patch over plain 3.4-rc2 or
> current 3.3-stable as both include Andreas's fix.
>
> Otherwise it can not be labelled it as a fix : it does not go into 3.4-rc
> nor 3.3-stable but proceeds through net-next where it will land into
> 3.5-rc then -stable.
>
> One can not exercize the Tx xmit vs napi Tx completion race part of the
> patch with a single core. Afaiui non-Soekris users are needed here.
>
> Even if you don't experience change of behavior over 3.4-rc or 3.3-stable,
> some longterm use of this driver would be welcome. It may end as an effort
> for 3.5-rc though.
Okay, I'll keep staying up to date with 3.4-rcX and report if anything breaks.
Going for v3.5-rc should be fine AFAICS :-)
/Bjarke
> --
> Ueimor
>
> Will code drivers for food.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH v3 1/2] netfilter: ipvs: Verify that IP_VS protocol has been registered
From: Julian Anastasov @ 2012-04-14 14:23 UTC (permalink / raw)
To: Sasha Levin
Cc: wensong, horms, kaber, davem, davej, netdev, lvs-devel,
netfilter-devel, linux-kernel
In-Reply-To: <1334421467-30313-1-git-send-email-levinsasha928@gmail.com>
Hello,
On Sat, 14 Apr 2012, Sasha Levin wrote:
> The registration of a protocol might fail, there were no checks
> and all registrations were assumed to be correct. This lead to
> NULL ptr dereferences when apps tried registering.
>
> For example:
>
> [ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> [ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
> [ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
> [ 1293.227038] CPU 1
> [ 1293.227038] Pid: 19609, comm: trinity Tainted: G W 3.4.0-rc1-next-20120405-sasha-dirty #57
> [ 1293.227038] RIP: 0010:[<ffffffff822aacb0>] [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] RSP: 0018:ffff880038c1dd18 EFLAGS: 00010286
> [ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
> [ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
> [ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
> [ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
> [ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
> [ 1293.227038] FS: 00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
> [ 1293.227038] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
> [ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
> [ 1293.227038] Stack:
> [ 1293.227038] ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
> [ 1293.227038] ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
> [ 1293.227038] 0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
> [ 1293.227038] Call Trace:
> [ 1293.227038] [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
> [ 1293.227038] [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
> [ 1293.227038] [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
> [ 1293.227038] [<ffffffff821c9060>] ops_init+0x80/0x90
> [ 1293.227038] [<ffffffff821c90cb>] setup_net+0x5b/0xe0
> [ 1293.227038] [<ffffffff821c9416>] copy_net_ns+0x76/0x100
> [ 1293.227038] [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
> [ 1293.227038] [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
> [ 1293.227038] [<ffffffff810afd1f>] sys_unshare+0xff/0x290
> [ 1293.227038] [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 1293.227038] [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
> [ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
> [ 1293.227038] RIP [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
> [ 1293.227038] RSP <ffff880038c1dd18>
> [ 1293.227038] CR2: 0000000000000018
> [ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
> [ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Very good. Thank you! Simon, please apply both
patches from v3.
Acked-by: Julian Anastasov <ja@ssi.bg>
This patch can be applied on 2.6.39+
> ---
> net/netfilter/ipvs/ip_vs_proto.c | 27 ++++++++++++++++++---------
> 1 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
> index f843a88..a62360e 100644
> --- a/net/netfilter/ipvs/ip_vs_proto.c
> +++ b/net/netfilter/ipvs/ip_vs_proto.c
> @@ -59,9 +59,6 @@ static int __used __init register_ip_vs_protocol(struct ip_vs_protocol *pp)
> return 0;
> }
>
> -#if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP) || \
> - defined(CONFIG_IP_VS_PROTO_SCTP) || defined(CONFIG_IP_VS_PROTO_AH) || \
> - defined(CONFIG_IP_VS_PROTO_ESP)
> /*
> * register an ipvs protocols netns related data
> */
> @@ -86,7 +83,6 @@ register_ip_vs_proto_netns(struct net *net, struct ip_vs_protocol *pp)
>
> return 0;
> }
> -#endif
>
> /*
> * unregister an ipvs protocol
> @@ -316,22 +312,35 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
> */
> int __net_init ip_vs_protocol_net_init(struct net *net)
> {
> + int i, ret;
> + static struct ip_vs_protocol *protos[] = {
> #ifdef CONFIG_IP_VS_PROTO_TCP
> - register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
> + &ip_vs_protocol_tcp,
> #endif
> #ifdef CONFIG_IP_VS_PROTO_UDP
> - register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
> + &ip_vs_protocol_udp,
> #endif
> #ifdef CONFIG_IP_VS_PROTO_SCTP
> - register_ip_vs_proto_netns(net, &ip_vs_protocol_sctp);
> + &ip_vs_protocol_sctp,
> #endif
> #ifdef CONFIG_IP_VS_PROTO_AH
> - register_ip_vs_proto_netns(net, &ip_vs_protocol_ah);
> + &ip_vs_protocol_ah,
> #endif
> #ifdef CONFIG_IP_VS_PROTO_ESP
> - register_ip_vs_proto_netns(net, &ip_vs_protocol_esp);
> + &ip_vs_protocol_esp,
> #endif
> + };
> +
> + for (i = 0; i < ARRAY_SIZE(protos); i++) {
> + ret = register_ip_vs_proto_netns(net, protos[i]);
> + if (ret < 0)
> + goto cleanup;
> + }
> return 0;
> +
> +cleanup:
> + ip_vs_protocol_net_cleanup(net);
> + return ret;
> }
>
> void __net_exit ip_vs_protocol_net_cleanup(struct net *net)
> --
> 1.7.8.5
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* RE: [PATCH 04/37] atl1c: remove VPD register
From: Ben Hutchings @ 2012-04-14 14:22 UTC (permalink / raw)
To: Huang, Xiong
Cc: David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, qca-linux-team, nic-devel
In-Reply-To: <157393863283F442885425D2C454285623D486D9@nasanexd02a.na.qualcomm.com>
On Sat, 2012-04-14 at 09:12 +0000, Huang, Xiong wrote:
>
> > -----Original Message-----
> > From: David Miller [mailto:davem@davemloft.net]
> > Sent: Saturday, April 14, 2012 8:46
> > To: Huang, Xiong
> > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; qca-linux-team; nic-
> > devel
> > Subject: Re: [PATCH 04/37] atl1c: remove VPD register
> >
> > From: xiong <xiong@qca.qualcomm.com>
> > Date: Fri, 13 Apr 2012 08:14:29 +0800
> >
> > > VPD register is only used for L1(devid=PCI_DEVICE_ID_ATTANSIC_L1) to
> > > access external NV-memory.
> > > l1c & later chip doesn't use it any more.
> > >
> > > Signed-off-by: xiong <xiong@qca.qualcomm.com>
> > > Tested-by: Liu David <dwliu@qca.qualcomm.com>
> >
> > You just broke ethtool register dumps with this change.
> >
> > Now, all the initial registers are reported offset by one entry, yet the last two are
> > still reported in their original spots.
> >
> > This layout is exposed to userspace, and interpreted by tools, and you cannot
> > change it.
> >
> > If this register always reports some value, you should just keep it there in the
> > dumps.
> >
> The VPD register doesn't report anything :(, just a dummy register now.
> we don't have any special tools in userspace to explain the dumped registers.
> Actually the purpose of dumping these registers via ethtool is just for debug.
[...]
Of course, the whole purpose of the operation is for debugging. But you
should bump the dump version number (currently 0) every time you change
the offsets of registers in the dump.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH v2 2/2] netfilter: ipvs: use GFP_KERNEL allocation where possible
From: Sasha Levin @ 2012-04-14 13:22 UTC (permalink / raw)
To: wensong, horms, ja, kaber, davem
Cc: davej, netdev, lvs-devel, netfilter-devel, linux-kernel,
Sasha Levin
In-Reply-To: <1334409722-26315-1-git-send-email-levinsasha928@gmail.com>
Use GFP_KERNEL instead of GFP_ATOMIC when registering an ipvs protocol.
This is safe since it will always run from a process context.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
net/netfilter/ipvs/ip_vs_proto.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
index 57a242d..73d06c6 100644
--- a/net/netfilter/ipvs/ip_vs_proto.c
+++ b/net/netfilter/ipvs/ip_vs_proto.c
@@ -71,7 +71,7 @@ register_ip_vs_proto_netns(struct net *net, struct ip_vs_protocol *pp)
struct netns_ipvs *ipvs = net_ipvs(net);
unsigned hash = IP_VS_PROTO_HASH(pp->protocol);
struct ip_vs_proto_data *pd =
- kzalloc(sizeof(struct ip_vs_proto_data), GFP_ATOMIC);
+ kzalloc(sizeof(struct ip_vs_proto_data), GFP_KERNEL);
if (!pd)
return -ENOMEM;
--
1.7.8.5
^ permalink raw reply related
* [PATCH v2 1/2] netfilter: ipvs: Verify that IP_VS protocol has been registered
From: Sasha Levin @ 2012-04-14 13:22 UTC (permalink / raw)
To: wensong, horms, ja, kaber, davem
Cc: davej, netdev, lvs-devel, netfilter-devel, linux-kernel,
Sasha Levin
The registration of a protocol might fail, there were no checks
and all registrations were assumed to be correct. This lead to
NULL ptr dereferences when apps tried registering.
For example:
[ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
[ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
[ 1293.227038] CPU 1
[ 1293.227038] Pid: 19609, comm: trinity Tainted: G W 3.4.0-rc1-next-20120405-sasha-dirty #57
[ 1293.227038] RIP: 0010:[<ffffffff822aacb0>] [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] RSP: 0018:ffff880038c1dd18 EFLAGS: 00010286
[ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
[ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
[ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
[ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
[ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
[ 1293.227038] FS: 00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
[ 1293.227038] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
[ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
[ 1293.227038] Stack:
[ 1293.227038] ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
[ 1293.227038] ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
[ 1293.227038] 0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
[ 1293.227038] Call Trace:
[ 1293.227038] [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
[ 1293.227038] [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
[ 1293.227038] [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
[ 1293.227038] [<ffffffff821c9060>] ops_init+0x80/0x90
[ 1293.227038] [<ffffffff821c90cb>] setup_net+0x5b/0xe0
[ 1293.227038] [<ffffffff821c9416>] copy_net_ns+0x76/0x100
[ 1293.227038] [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
[ 1293.227038] [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
[ 1293.227038] [<ffffffff810afd1f>] sys_unshare+0xff/0x290
[ 1293.227038] [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 1293.227038] [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
[ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
[ 1293.227038] RIP [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] RSP <ffff880038c1dd18>
[ 1293.227038] CR2: 0000000000000018
[ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
[ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
net/netfilter/ipvs/ip_vs_proto.c | 23 ++++++++++++++++++-----
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
index f843a88..57a242d 100644
--- a/net/netfilter/ipvs/ip_vs_proto.c
+++ b/net/netfilter/ipvs/ip_vs_proto.c
@@ -316,22 +316,35 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
*/
int __net_init ip_vs_protocol_net_init(struct net *net)
{
+ int i, ret;
+ static struct ip_vs_protocol *protos[] = {
#ifdef CONFIG_IP_VS_PROTO_TCP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
+ &ip_vs_protocol_tcp,
#endif
#ifdef CONFIG_IP_VS_PROTO_UDP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
+ &ip_vs_protocol_udp,
#endif
#ifdef CONFIG_IP_VS_PROTO_SCTP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_sctp);
+ &ip_vs_protocol_sctp,
#endif
#ifdef CONFIG_IP_VS_PROTO_AH
- register_ip_vs_proto_netns(net, &ip_vs_protocol_ah);
+ &ip_vs_protocol_ah,
#endif
#ifdef CONFIG_IP_VS_PROTO_ESP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_esp);
+ &ip_vs_protocol_esp,
#endif
+ };
+
+ for (i = 0; i < ARRAY_SIZE(protos); i++) {
+ ret = register_ip_vs_proto_netns(net, protos[i]);
+ if (ret < 0)
+ goto cleanup;
+ }
return 0;
+
+cleanup:
+ ip_vs_protocol_net_cleanup(net);
+ return ret;
}
void __net_exit ip_vs_protocol_net_cleanup(struct net *net)
--
1.7.8.5
^ permalink raw reply related
* Re: [RFC] endianness bugs in net/batman-adv/
From: Antonio Quartulli @ 2012-04-14 13:07 UTC (permalink / raw)
To: Al Viro
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20120414093404.GA5300-E/2OGukznS5g9hUCZPvPmw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
Hello,
On Sat, Apr 14, 2012 at 11:34:05AM +0200, Antonio Quartulli wrote:
....
>
> Thank you very much. I'll fix it.
I sent two patches to the batman-adv mailing list that will fix the bugs you
have found.
If you would like to have a look at the patches, you can find them on the list
archive:
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-April/006692.html
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-April/006693.html
Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] netfilter: ipvs: Verify that IP_VS protocol has been registered
From: Sasha Levin @ 2012-04-14 12:32 UTC (permalink / raw)
To: Julian Anastasov
Cc: wensong, horms, kaber, davem, davej, netdev, lvs-devel,
netfilter-devel, linux-kernel
In-Reply-To: <alpine.LFD.2.00.1204141518270.9966@ja.ssi.bg>
On Sat, Apr 14, 2012 at 2:23 PM, Julian Anastasov <ja@ssi.bg> wrote:
>
> Hello,
>
> On Sat, 14 Apr 2012, Sasha Levin wrote:
>
>> On Sat, Apr 14, 2012 at 1:53 PM, Julian Anastasov <ja@ssi.bg> wrote:
>> > Ops. It seems now we expose old problem when
>> > no protocol is configured. As this change probably will
>> > go to stable kernels, lets make it correct. Can you
>> > remove the defines around register_ip_vs_proto_netns, so
>> > that it is always compiled. One that wants to save
>> > memory will not disable all protocols. See commit
>> > 091bb34c143674d37a59b2d4857534f7106c5d7d for reference.
>>
>> Oh, so it wasn't getting built right now at all if we didn't select
>> any protocols.
>>
>> How about moving those defines down to our loop as well? this way
>> everything will behave exactly like it did before.
>
> Better to remove the defines. It is a misconfiguration
> to enable IPVS without protocols. The referenced commit
> just tried to remove warnings, not save memory by commenting
> unused function. Adding more define makes the things more ugly.
Understood. I'll resend.
^ 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