* Re: [PATCH net-next] igb: Add support for byte queue limits.
From: David Miller @ 2011-12-21 19:42 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jeffrey.t.kirsher, alexander.h.duyck
In-Reply-To: <1324480695.2301.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Dec 2011 16:18:15 +0100
> This adds support for byte queue limits (BQL)
>
> Since this driver collects bytes count in 'bytecount' field, use it also
> in igb_tx_map()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: Alexander Duyck <alexander.h.duyck@intel.com>
Intel folks, you got this?
^ permalink raw reply
* Re: [PATCH 1/1] tcp: Replace constants with #define macros
From: Vijay Subramanian @ 2011-12-21 19:43 UTC (permalink / raw)
To: David Laight; +Cc: David Miller, netdev, eric.dumazet, ilpo.jarvinen, hkchu
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AF1E@saturn3.aculab.com>
>
> Given the values are currently:
>
>> > +#define SACK_SEEN (1 << 0) /*1 = peer is SACK capable, */
>> > +#define FACK_ENABLED (1 << 1) /*1 = FACK is enabled locally*/
>> > +#define DSACK_SEEN (1 << 2) /*1 = DSACK was received from
> peer*/
>
> But the structure field member is 'sack_ok', unless it generates
> very silly long lines - which in this case it probably doesn't -
> it might even be worth prefixing with TCP_SACK_OK_ although
> that might be deemed excessive!
>
Thanks for all the feedback. I will follow these suggestions in future.
Vijay
^ permalink raw reply
* [PATCH ethtool] sfc: Omit zero values in register tables
From: Ben Hutchings @ 2011-12-21 19:48 UTC (permalink / raw)
To: netdev; +Cc: linux-net-drivers
I just pushed this change out.
Ben.
---
Some register tables on Solarflare controllers are very large and may
have only a few rows in use. Make register dumps more readable by
omitting rows where all bits read as zero.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
sfc.c | 29 ++++++++++++++++++++---------
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/sfc.c b/sfc.c
index 46a617b..3ba3da8 100644
--- a/sfc.c
+++ b/sfc.c
@@ -3777,6 +3777,15 @@ print_simple_table(unsigned revision, const struct efx_nic_reg_table *table,
return buf;
}
+static int buf_is_zero(const u8 *buf, size_t size)
+{
+ size_t i;
+ for (i = 0; i < size; i++)
+ if (buf[i])
+ return 0;
+ return 1;
+}
+
static const void *
print_complex_table(unsigned revision, const struct efx_nic_reg_table *table,
const void *buf)
@@ -3808,16 +3817,18 @@ print_complex_table(unsigned revision, const struct efx_nic_reg_table *table,
fputc('\n', stdout);
for (j = 0; j < table->rows; j++) {
- printf("%4zu", j);
- for (i = 0; i < table->field_count; i++) {
- field = &table->fields[i];
- if (!(revision >= field->min_revision &&
- revision <= field->max_revision))
- continue;
- printf(" %*s", (int)column_padding(field), "");
- print_field_value(field, buf);
+ if (!buf_is_zero(buf, size)) {
+ printf("%4zu", j);
+ for (i = 0; i < table->field_count; i++) {
+ field = &table->fields[i];
+ if (!(revision >= field->min_revision &&
+ revision <= field->max_revision))
+ continue;
+ printf(" %*s", (int)column_padding(field), "");
+ print_field_value(field, buf);
+ }
+ fputc('\n', stdout);
}
- fputc('\n', stdout);
buf = (const u8 *)buf + size;
}
--
1.7.4.4
--
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 related
* Re: [PATCH] drivers/iwlwifi: use dma_zalloc_coherent() for DMA allocation
From: Djalal Harouni @ 2011-12-21 19:48 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: Intel Linux Wireless, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrew Morton
In-Reply-To: <1324486330.13074.322.camel@wwguy-huron>
On Wed, Dec 21, 2011 at 08:52:10AM -0800, Guy, Wey-Yi wrote:
> Hi Djalal,
>
>
> On Tue, 2011-12-20 at 16:21 -0800, Djalal Harouni wrote:
> > Replace dma_alloc_coherent()+memset() with the new dma_zalloc_coherent()
> >
> > Signed-off-by: Djalal Harouni <tixxdz-Umm1ozX2/EEdnm+yROfE0A@public.gmane.org>
> > ---
>
> iwl-trans-pcie.c is one of the source files in iwlwifi driver hold
> dual-license (GPL + BSD), are you ok to release your code for the BSD
> license and relinquish the copyright?
Yes, It's ok.
> btw, we are in the process of rewrite and re-architect major portion of
> iwlwifi driver, and we also plan to make most of the code dual-license
> (GPL + BSD).
>
> Thanks you in advance
>
> Wey
Thanks Wey.
--
tixxdz
http://opendz.org
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_select_ident
From: Chris Boot @ 2011-12-21 20:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: lkml, netdev
In-Reply-To: <1324490401.2301.46.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 21/12/2011 18:00, Eric Dumazet wrote:
> Le mercredi 21 décembre 2011 à 18:36 +0100, Eric Dumazet a écrit :
>
>> Good point, thats a different problem then, since 3.1 is not supposed to
>> have this bug.
>>
>> It seems rt->rt6i_peer points to invalid memory in your crash.
>>
>> (RBX=00000000000001f4)
>>
>> 8b 83 a4 00 00 00 mov 0xa4(%rbx),%eax p->refcnt
>> 1f4+a4 -> CR2=0000000000000298
>>
> It would help if you can confirm latest linux tree can reproduce the
> bug.
Hi Eric,
I just built a v3.2-rc6-140-gb9e26df with the same config as the Debian
3.1.0 kernel. I can reproduce the bug just as easily with this kernel as
with the Debian kernel. Unfortunately I wasn't able to get an entire
trace, for some reason it didn't appear to be printed to the serial port
and hung after the (long) list of loaded kernel modules. The crash
happens at the same offset:
[ 356.683420] BUG: unable to handle kernel NULL pointer dereference at
0000000000000298
[ 356.691438] IP: [<ffffffff812ea0da>] ipv6_select_ident+0x31/0xa7
[ 356.697633] PGD 425060067 PUD 41de8d067 PMD 0
[ 356.702123] Oops: 0000 [#1] SMP
[ 356.705451] CPU 4
[ 356.707366] Modules linked in: tun sha1_ssse3 sha1_generic hmac
sha256_generic dlm configfs ebtable_nat ebtables acpi_cpufreq mperf
cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_userspace
microcode xt_NOTRACK ip_set_hash_net act_police cls_basic cls_flow
cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq
xt_realm xt_addrtype xt_connlimit iptable_raw ip_set_hash_ip xt_comment
ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN
ipt_ecn ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic
nf_conntrack_snmp xt_recent nf_nat_sip nf_nat_pptp nf_nat_proto_gre
nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ip6_queue xt_set ip_set
nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane
nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp
nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323
nf_conntrack_ftp ts_kmp xt_NFLOG nfnetlink_log nf_conntrack_amanda
xt_TPROXY nf_tproxy_core xt_time xt_TCPMSS xt_tcpmss xt_sctp xt_policy
xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_multiport xt_mark xt_mac
xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp
xt_dccp xt_connmark ip6t_LOG xt_CLASSIFY ip6t_REJECT xt_AUDIT
nf_conntrack_ipv6
I loaded the kernel in gdb to see where it thought that was:
(gdb) list *ipv6_select_ident+0x31/0xa7
0xffffffff812ea0a9 is in ipv6_select_ident (net/ipv6/ip6_output.c:602).
597
598 return offset;
599 }
600
601 void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt)
602 {
603 static atomic_t ipv6_fragmentation_id;
604 int old, new;
605
606 if (rt) {
HTH,
Chris
--
Chris Boot
bootc@bootc.net
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_select_ident
From: Eric Dumazet @ 2011-12-21 20:28 UTC (permalink / raw)
To: Chris Boot; +Cc: lkml, netdev
In-Reply-To: <4EF23BF2.4000601@bootc.net>
Le mercredi 21 décembre 2011 à 20:05 +0000, Chris Boot a écrit :
> On 21/12/2011 18:00, Eric Dumazet wrote:
> > Le mercredi 21 décembre 2011 à 18:36 +0100, Eric Dumazet a écrit :
> >
> >> Good point, thats a different problem then, since 3.1 is not supposed to
> >> have this bug.
> >>
> >> It seems rt->rt6i_peer points to invalid memory in your crash.
> >>
> >> (RBX=00000000000001f4)
> >>
> >> 8b 83 a4 00 00 00 mov 0xa4(%rbx),%eax p->refcnt
> >> 1f4+a4 -> CR2=0000000000000298
> >>
> > It would help if you can confirm latest linux tree can reproduce the
> > bug.
>
> Hi Eric,
>
> I just built a v3.2-rc6-140-gb9e26df with the same config as the Debian
> 3.1.0 kernel. I can reproduce the bug just as easily with this kernel as
> with the Debian kernel. Unfortunately I wasn't able to get an entire
> trace, for some reason it didn't appear to be printed to the serial port
> and hung after the (long) list of loaded kernel modules. The crash
> happens at the same offset:
>
Thanks !
Oh well, br_netfilter fake_rtable strikes again.
I'll cook a patch in a couple of minutes...
^ permalink raw reply
* Re: [PATCH 2/4] net: ethernet: xilinx: Don't use NO_IRQ in xilinx
From: David Miller @ 2011-12-21 20:43 UTC (permalink / raw)
To: monstr; +Cc: linux-kernel, netdev, devicetree-discuss, sfr, grant.likely,
rmallon
In-Reply-To: <1324477932-19262-2-git-send-email-monstr@monstr.eu>
From: Michal Simek <monstr@monstr.eu>
Date: Wed, 21 Dec 2011 15:32:10 +0100
> Fix ll_temac and emaclite drivers. Only Microblaze and Xilinx PPC
> use then and both use NO_IRQ as 0. It will be removed in near future.
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] sch_sfq: rehash queues in perturb timer
From: David Miller @ 2011-12-21 20:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1324474211.2728.56.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Dec 2011 14:30:11 +0100
> A known Out Of Order (OOO) problem hurts SFQ when timer changes
> perturbation value, since all new packets delivered to SFQ enqueue might
> end on different slots than previous in-flight packets.
>
> With round robin delivery, we can thus deliver packets in a different
> order.
>
> Since SFQ is limited to small amount of in-flight packets, we can rehash
> packets so that this OOO problem is fixed.
>
> This rehashing is performed only if internal flow classifier is in use.
>
> We now store in skb->cb[] the "struct flow_keys" so that we dont call
> skb_flow_dissect() again while rehashing.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next 1/2] stmmac: add the experimental PCI support
From: David Miller @ 2011-12-21 20:45 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, rayagond
In-Reply-To: <1324475900-1470-3-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 21 Dec 2011 14:58:19 +0100
> This patch adds the PCI support (as EXPERIMENTAL)
> this has been also tested on XLINX XC2V3000 FF1152AMT0221
> D1215994A VIRTEX FPGA board.
> To support the PCI bus the main part has been reworked
> and both the platform and the PCI specific parts have
> been moved into different files.
>
> Signed-off-by: Rayagond Kokatanur <rayagond@vayavyalabs.com>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [net-next 2/2] stmmac: update the driver's documentation (Dec-2011)
From: David Miller @ 2011-12-21 20:45 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, rayagond
In-Reply-To: <1324475900-1470-4-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 21 Dec 2011 14:58:20 +0100
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: Kernel-DOS error in arp mechanism =?iso-2022-jp-3?B?GyQoUSN8GyhC?= no delete off incomplete arp adresses
From: David Miller @ 2011-12-21 20:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: richard.weinberger, gladewitz, linux-kernel, netdev
In-Reply-To: <1324461072.2728.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Dec 2011 10:51:12 +0100
> [PATCH] ipv4: reintroduce route cache garbage collector
>
> Commit 2c8cec5c10b (ipv4: Cache learned PMTU information in inetpeer)
> removed IP route cache garbage collector a bit too soon, as this gc was
> responsible for expired routes cleanup, releasing their neighbour
> reference.
>
> As pointed out by Robert Gladewitz, recent kernels can fill and exhaust
> their neighbour cache.
>
> Reintroduce the garbage collection, since we'll have to wait our
> neighbour lookups become refcount-less to not depend on this stuff.
>
> Reported-by: Robert Gladewitz <gladewitz@gmx.de>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] irda: use msecs_to_jiffies() rather than manual calculation
From: David Miller @ 2011-12-21 20:46 UTC (permalink / raw)
To: xi.wang; +Cc: samuel, netdev
In-Reply-To: <1324472236-9681-1-git-send-email-xi.wang@gmail.com>
From: Xi Wang <xi.wang@gmail.com>
Date: Wed, 21 Dec 2011 07:57:16 -0500
> Also use mod_timer() instead of direct assignment to "expires".
>
> Signed-off-by: Xi Wang <xi.wang@gmail.com>
Applied, thanks.
^ permalink raw reply
* usb/mcs7830: Cannot read MAC address
From: eddie @ 2011-12-21 20:40 UTC (permalink / raw)
To: netdev
Hello,
I have a USB adapter by Pluscom with a Moschip chip. Plugging it into a
Centos 5.7 box with a vanilla 3.1.5 kernel I get:
usb 5-8: new high speed USB device number 4 using ehci_hcd
usb 5-8: New USB device found, idVendor=9710, idProduct=7830
usb 5-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-8: Product: USB-MAC Controller
usb 5-8: Manufacturer: Moschip Semiconductor
usb 5-8: SerialNumber: 081600e2
usb 5-8: Cannot read MAC address
MOSCHIP usb-ethernet driver: probe of 5-8:1.0 failed with error -110
I don't see this error plugging the device into my Fedora 15 Laptop with
a very recent kernel, which makes me think this could be something to do
with Centos' old userspace, maybe the kernel headers or udev.
Can anyone suggest roughly whereabouts the problem might lie so I can
hunt around for a solution in the right place?
thanks in advance,
Eddie
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_select_ident
From: Eric Dumazet @ 2011-12-21 20:52 UTC (permalink / raw)
To: Chris Boot; +Cc: lkml, netdev
In-Reply-To: <1324499332.2621.7.camel@edumazet-laptop>
Le mercredi 21 décembre 2011 à 21:28 +0100, Eric Dumazet a écrit :
> Le mercredi 21 décembre 2011 à 20:05 +0000, Chris Boot a écrit :
> > On 21/12/2011 18:00, Eric Dumazet wrote:
> > > Le mercredi 21 décembre 2011 à 18:36 +0100, Eric Dumazet a écrit :
> > >
> > >> Good point, thats a different problem then, since 3.1 is not supposed to
> > >> have this bug.
> > >>
> > >> It seems rt->rt6i_peer points to invalid memory in your crash.
> > >>
> > >> (RBX=00000000000001f4)
> > >>
> > >> 8b 83 a4 00 00 00 mov 0xa4(%rbx),%eax p->refcnt
> > >> 1f4+a4 -> CR2=0000000000000298
> > >>
> > > It would help if you can confirm latest linux tree can reproduce the
> > > bug.
> >
> > Hi Eric,
> >
> > I just built a v3.2-rc6-140-gb9e26df with the same config as the Debian
> > 3.1.0 kernel. I can reproduce the bug just as easily with this kernel as
> > with the Debian kernel. Unfortunately I wasn't able to get an entire
> > trace, for some reason it didn't appear to be printed to the serial port
> > and hung after the (long) list of loaded kernel modules. The crash
> > happens at the same offset:
> >
>
> Thanks !
>
> Oh well, br_netfilter fake_rtable strikes again.
>
> I'll cook a patch in a couple of minutes...
>
Could you try following patch ?
Thanks !
include/net/dst.h | 1 +
net/bridge/br_netfilter.c | 2 +-
net/ipv4/route.c | 4 ++--
net/ipv6/ip6_output.c | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 6faec1a..75766b4 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -53,6 +53,7 @@ struct dst_entry {
#define DST_NOHASH 0x0008
#define DST_NOCACHE 0x0010
#define DST_NOCOUNT 0x0020
+#define DST_NOPEER 0x0040
short error;
short obsolete;
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index d6ec372..5693e5f 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -141,7 +141,7 @@ void br_netfilter_rtable_init(struct net_bridge *br)
rt->dst.dev = br->dev;
rt->dst.path = &rt->dst;
dst_init_metrics(&rt->dst, br_dst_default_metrics, true);
- rt->dst.flags = DST_NOXFRM;
+ rt->dst.flags = DST_NOXFRM | DST_NOPEER;
rt->dst.ops = &fake_dst_ops;
}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 46af623..7720403 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1271,7 +1271,7 @@ void __ip_select_ident(struct iphdr *iph, struct dst_entry *dst, int more)
{
struct rtable *rt = (struct rtable *) dst;
- if (rt) {
+ if (rt && !(rt->dst.flags & DST_NOPEER)) {
if (rt->peer == NULL)
rt_bind_peer(rt, rt->rt_dst, 1);
@@ -1282,7 +1282,7 @@ void __ip_select_ident(struct iphdr *iph, struct dst_entry *dst, int more)
iph->id = htons(inet_getid(rt->peer, more));
return;
}
- } else
+ } else if (!rt)
printk(KERN_DEBUG "rt_bind_peer(0) @%p\n",
__builtin_return_address(0));
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 84d0bd5..ec56271 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -603,7 +603,7 @@ void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt)
static atomic_t ipv6_fragmentation_id;
int old, new;
- if (rt) {
+ if (rt && !(rt->dst.flags & DST_NOPEER)) {
struct inet_peer *peer;
if (!rt->rt6i_peer)
^ permalink raw reply related
* Re: ICMP packets - ll_temac with Microblaze
From: David Miller @ 2011-12-21 20:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: monstr, john.williams, netdev
In-Reply-To: <1324487504.2301.36.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Dec 2011 18:11:44 +0100
> [PATCH net-next] net: relax rcvbuf limits
>
> skb->truesize might be big even for a small packet.
>
> Its even bigger after commit 87fb4b7b533 (net: more accurate skb
> truesize) and big MTU.
>
> We should allow queueing at least one packet per receiver, even with a
> low RCVBUF setting.
>
> Reported-by: Michal Simek <monstr@monstr.eu>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next, although I was tempted to put it into net.
We may end up backporting this into -stable at some point, we'll
see.
^ permalink raw reply
* Re: linux-3.0.x regression with ipv4 routes having mtu
From: David Miller @ 2011-12-21 20:56 UTC (permalink / raw)
To: steffen.klassert; +Cc: timo.teras, netdev
In-Reply-To: <20111221085616.GO6348@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 21 Dec 2011 09:56:16 +0100
> On Tue, Dec 20, 2011 at 01:35:42PM -0500, David Miller wrote:
>> From: Steffen Klassert <steffen.klassert@secunet.com>
>> Date: Tue, 20 Dec 2011 08:18:43 +0100
>>
>> > On Tue, Dec 20, 2011 at 02:03:55AM -0500, David Miller wrote:
>> >> From: Timo Teräs <timo.teras@iki.fi>
>> >> Date: Tue, 20 Dec 2011 08:53:09 +0200
>> >>
>> >> > Or maybe I missed the place where that updated would happen?
>> >>
>> >> It should happen on every routing cache lookup hit just like we
>> >> validate the peer for redirect information.
>> >
>> > The problem is that we need to do a route cache lookup to
>> > validate the peer informations. This does not happen if
>> > somebody adds a new route. I tried already to add a pmtu specific
>> > generation id and it appears to not solve the problem. We would
>> > still need to overwrite the cached value if we add a route with mtu.
>>
>> Why?
>>
>> Every use of a routing cache entry does a dst_check() or a routing
>> cache lookup.
>>
>> You can check the generation ID in both locations, and if the
>> comparison fails then you force the routing cache entry to be killed
>> and the caller performs a lookup. At that time the refreshing of the
>> new FIB entry will be realized.
>
> My decscription was a bit missleading, sorry. This seems to be not
> even related to pmtu handling. It's just that we don't use the
> user configured metrics on the fib entry if we find an inetpeer
> with metrics that are not in INETPEER_METRICS_NEW state when we
> initialize the routing metrics in rt_init_metrics(). I tried to add
> a route with a hoplimit, this has also no effect if the metrics on
> the inetpeer are not new.
Ok, so what you're saying is that we need a way to invalidate inetpeer
entries, or at least invalidate their cached metrics and set
INETPEER_METRICS_NEW once more.
^ permalink raw reply
* RE: [PATCH net-next] igb: Add support for byte queue limits.
From: Wyborny, Carolyn @ 2011-12-21 21:17 UTC (permalink / raw)
To: David Miller, eric.dumazet@gmail.com
Cc: netdev@vger.kernel.org, Kirsher, Jeffrey T, Duyck, Alexander H
In-Reply-To: <20111221.144207.1402252938319338463.davem@davemloft.net>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of David Miller
>Sent: Wednesday, December 21, 2011 11:42 AM
>To: eric.dumazet@gmail.com
>Cc: netdev@vger.kernel.org; Kirsher, Jeffrey T; Duyck, Alexander H
>Subject: Re: [PATCH net-next] igb: Add support for byte queue limits.
>
>From: Eric Dumazet <eric.dumazet@gmail.com>
>Date: Wed, 21 Dec 2011 16:18:15 +0100
>
>> This adds support for byte queue limits (BQL)
>>
>> Since this driver collects bytes count in 'bytecount' field, use it
>also
>> in igb_tx_map()
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> CC: Alexander Duyck <alexander.h.duyck@intel.com>
>
>Intel folks, you got this?
>--
>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
Yes, although many are out for the holidays.
ACK. We'll get it into our queue for testing.
Thanks,
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply
* Re: [PATCH] net: macb: fix build break with !CONFIG_OF
From: Nicolas Ferre @ 2011-12-21 21:34 UTC (permalink / raw)
To: Olof Johansson
Cc: netdev, Jean-Christophe PLAGNIOL-VILLARD, Jamie Iles,
linux-arm-kernel
In-Reply-To: <1324416029-28198-1-git-send-email-olof@lixom.net>
On 12/20/2011 10:20 PM, Olof Johansson :
> This fixes the build of the macb driver that was broken by the DT changes:
>
> drivers/net/ethernet/cadence/macb.c:1503: error: implicit declaration of function 'of_match_ptr'
> drivers/net/ethernet/cadence/macb.c:1503: error: 'macb_dt_ids' undeclared here (not in a function)
> drivers/net/ethernet/cadence/macb.c:1503: error: initializer element is not constant
> drivers/net/ethernet/cadence/macb.c:1503: error: (near initialization for 'macb_driver.driver.of_match_table')
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Olof, thanks for this patch.
Best regards,
> ---
>
> Nicolas, care to ack this so I can apply it on top of the macb DT branch in arm-soc?
>
> drivers/net/ethernet/cadence/macb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index baf1a0d..f3d5c65 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -23,6 +23,7 @@
> #include <linux/platform_data/macb.h>
> #include <linux/platform_device.h>
> #include <linux/phy.h>
> +#include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/of_net.h>
>
--
Nicolas Ferre
^ permalink raw reply
* New LARTC mailing list
From: Andrew Beverley @ 2011-12-21 21:38 UTC (permalink / raw)
To: Linux Networking Developer Mailing List
Dear all,
A new LARTC mailing list has now been set up at vger.kernel.org (thanks
to David for this).
Could I encourage those who often reply to user questions on this list
to join the new list?
Back in its heyday, the LARTC list was an excellent user list for lots
of aspects of Linux networking; it would be nice to recreate this. And
it also saves the small number of user posts getting lost amongst all
the other netdev emails ;-)
Thanks,
Andy
^ permalink raw reply
* Re: [PATCH] net/flow: remove sleeping and deferral mechanism from flow_cache_flush
From: David Miller @ 2011-12-21 21:48 UTC (permalink / raw)
To: timo.teras; +Cc: steffen.klassert, madalin.bucur, eric.dumazet, netdev
In-Reply-To: <4EF04A44.6060400@iki.fi>
From: Timo Teräs <timo.teras@iki.fi>
Date: Tue, 20 Dec 2011 10:41:40 +0200
> On 12/20/2011 10:23 AM, Steffen Klassert wrote:
>> On Tue, Sep 27, 2011 at 03:31:32PM -0400, David Miller wrote:
>>> From: David Miller <davem@davemloft.net>
>>> Date: Tue, 27 Sep 2011 15:28:36 -0400 (EDT)
>>>
>>>> afinfo->garbage_collect is the only other place __xfrm_garbage_collect
>>>> is referenced, and that is completely unused and should thus be deleted
>>>> (I'll take care of that in net-next).
>>>
>>> Nevermind I see how these are referenced directly via xfrm4_policy.c
>>> and xfrm6_policy.c, sigh...
>>
>> Is there any progress in fixing this issue? I've seen this occasionally
>> on some of our production systems, so I fixed it for us in the meantime
>> with the patch below. I could submit this for inclusion if noone else
>> wants to fix it in a different manner.
>>
>> ------
>> net: Add a flow_cache_flush_deferred function
>>
>> flow_cach_flush() might sleep but can be called from
>> atomic context via the xfrm garbage collector. So add
>> a flow_cache_flush_deferred() function and use this if
>> the xfrm garbage colector is invoked from within the
>> packet path.
>>
>> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> Acked-by: Timo Teräs <timo.teras@iki.fi>
>
> I was first thinking if it made sense to run the local CPUs task
> immediately on gc. But since all it does is queue the removed nodes to
> the second gc that actually frees the dst's, it doesn't really make a
> difference.
>
> So this is probably as good as it gets.
Applied, thanks everyone.
^ permalink raw reply
* [PATCH 1/3] netlink: af_netlink cleanup
From: Stephen Hemminger @ 2011-12-21 21:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Don't inline functions that cover several lines, and do inline
the trivial ones. Also make some arguments const.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/netlink/af_netlink.c 2011-12-19 13:35:37.927992632 -0800
+++ b/net/netlink/af_netlink.c 2011-12-20 10:20:33.356914405 -0800
@@ -98,7 +98,7 @@ static inline struct netlink_sock *nlk_s
return container_of(sk, struct netlink_sock, sk);
}
-static inline int netlink_is_kernel(struct sock *sk)
+static inline int netlink_is_kernel(const struct sock *sk)
{
return nlk_sk(sk)->flags & NETLINK_KERNEL_SOCKET;
}
@@ -139,12 +139,12 @@ static atomic_t nl_table_users = ATOMIC_
static ATOMIC_NOTIFIER_HEAD(netlink_chain);
-static u32 netlink_group_mask(u32 group)
+static inline u32 netlink_group_mask(u32 group)
{
return group ? 1 << (group - 1) : 0;
}
-static struct hlist_head *nl_pid_hashfn(struct nl_pid_hash *hash, u32 pid)
+static inline struct hlist_head *nl_pid_hashfn(struct nl_pid_hash *hash, u32 pid)
{
return &hash->table[jhash_1word(pid, hash->rnd) & hash->mask];
}
@@ -226,7 +226,7 @@ netlink_unlock_table(void)
wake_up(&nl_table_wait);
}
-static inline struct sock *netlink_lookup(struct net *net, int protocol,
+static struct sock *netlink_lookup(struct net *net, int protocol,
u32 pid)
{
struct nl_pid_hash *hash = &nl_table[protocol].hash;
@@ -248,7 +248,7 @@ found:
return sk;
}
-static inline struct hlist_head *nl_pid_hash_zalloc(size_t size)
+static struct hlist_head *nl_pid_hash_zalloc(size_t size)
{
if (size <= PAGE_SIZE)
return kzalloc(size, GFP_ATOMIC);
@@ -258,7 +258,7 @@ static inline struct hlist_head *nl_pid_
get_order(size));
}
-static inline void nl_pid_hash_free(struct hlist_head *table, size_t size)
+static void nl_pid_hash_free(struct hlist_head *table, size_t size)
{
if (size <= PAGE_SIZE)
kfree(table);
@@ -578,7 +578,7 @@ retry:
return err;
}
-static inline int netlink_capable(struct socket *sock, unsigned int flag)
+static inline int netlink_capable(const struct socket *sock, unsigned int flag)
{
return (nl_table[sock->sk->sk_protocol].nl_nonroot & flag) ||
capable(CAP_NET_ADMIN);
@@ -846,7 +846,7 @@ void netlink_detachskb(struct sock *sk,
sock_put(sk);
}
-static inline struct sk_buff *netlink_trim(struct sk_buff *skb,
+static struct sk_buff *netlink_trim(struct sk_buff *skb,
gfp_t allocation)
{
int delta;
@@ -871,7 +871,7 @@ static inline struct sk_buff *netlink_tr
return skb;
}
-static inline void netlink_rcv_wake(struct sock *sk)
+static void netlink_rcv_wake(struct sock *sk)
{
struct netlink_sock *nlk = nlk_sk(sk);
@@ -881,7 +881,7 @@ static inline void netlink_rcv_wake(stru
wake_up_interruptible(&nlk->wait);
}
-static inline int netlink_unicast_kernel(struct sock *sk, struct sk_buff *skb)
+static int netlink_unicast_kernel(struct sock *sk, struct sk_buff *skb)
{
int ret;
struct netlink_sock *nlk = nlk_sk(sk);
@@ -952,7 +952,7 @@ int netlink_has_listeners(struct sock *s
}
EXPORT_SYMBOL_GPL(netlink_has_listeners);
-static inline int netlink_broadcast_deliver(struct sock *sk,
+static int netlink_broadcast_deliver(struct sock *sk,
struct sk_buff *skb)
{
struct netlink_sock *nlk = nlk_sk(sk);
@@ -982,7 +982,7 @@ struct netlink_broadcast_data {
void *tx_data;
};
-static inline int do_one_broadcast(struct sock *sk,
+static int do_one_broadcast(struct sock *sk,
struct netlink_broadcast_data *p)
{
struct netlink_sock *nlk = nlk_sk(sk);
@@ -1110,7 +1110,7 @@ struct netlink_set_err_data {
int code;
};
-static inline int do_one_set_err(struct sock *sk,
+static int do_one_set_err(struct sock *sk,
struct netlink_set_err_data *p)
{
struct netlink_sock *nlk = nlk_sk(sk);
--- a/net/netlink/genetlink.c 2011-12-07 10:54:21.808303161 -0800
+++ b/net/netlink/genetlink.c 2011-12-20 10:19:23.104114471 -0800
@@ -106,7 +106,7 @@ static struct genl_ops *genl_get_cmd(u8
/* Of course we are going to have problems once we hit
* 2^16 alive types, but that can only happen by year 2K
*/
-static inline u16 genl_generate_id(void)
+static u16 genl_generate_id(void)
{
static u16 id_gen_idx = GENL_MIN_ID;
int i;
^ permalink raw reply
* [PATCH 2/3] netlink: use vzalloc()
From: Stephen Hemminger @ 2011-12-21 21:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The netlink pid hash can be allocated using vzalloc() rather than direct
access to get_free_pages. It is also safe for nl_pid_hash_zalloc to use
GFP_KERNEL since it is only called from netlink_proto_init and
nl_pid_hash_rehash. The former is already allocating table with GFP_KERNEL,
and the latter is called from netlink_insert() which already could
sleep in netlink_table_grab()
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/netlink/af_netlink.c 2011-12-20 10:20:33.356914405 -0800
+++ b/net/netlink/af_netlink.c 2011-12-20 10:25:19.364247598 -0800
@@ -251,11 +251,9 @@ found:
static struct hlist_head *nl_pid_hash_zalloc(size_t size)
{
if (size <= PAGE_SIZE)
- return kzalloc(size, GFP_ATOMIC);
+ return kzalloc(size, GFP_KERNEL);
else
- return (struct hlist_head *)
- __get_free_pages(GFP_ATOMIC | __GFP_ZERO,
- get_order(size));
+ return vzalloc(size);
}
static void nl_pid_hash_free(struct hlist_head *table, size_t size)
@@ -263,7 +261,7 @@ static void nl_pid_hash_free(struct hlis
if (size <= PAGE_SIZE)
kfree(table);
else
- free_pages((unsigned long)table, get_order(size));
+ vfree(table);
}
static int nl_pid_hash_rehash(struct nl_pid_hash *hash, int grow)
^ permalink raw reply
* [PATCH 3/3] netlink: wake up netlink listeners sooner
From: Stephen Hemminger @ 2011-12-21 21:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
A netlink listening task (such as Quagga/zebra) can easily get overrun
when lots of events happen such as a link state transition with full BGP route
table. This happens because the sender does not yield to the receiver
(unless socket queue is full). The problem is exacerbated because it is
typical for listeners to set large receive buffer to attempt to keep up.
This patch changes it to yield sooner at halfway instead. Still not a cure-all
for listener overrun if listener is slow, but works much reliably.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/netlink/af_netlink.c 2011-12-20 10:25:19.364247598 -0800
+++ b/net/netlink/af_netlink.c 2011-12-20 10:25:46.756570010 -0800
@@ -960,7 +960,7 @@ static int netlink_broadcast_deliver(str
skb_set_owner_r(skb, sk);
skb_queue_tail(&sk->sk_receive_queue, skb);
sk->sk_data_ready(sk, skb->len);
- return atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf;
+ return atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf / 2;
}
return -1;
}
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_select_ident
From: Chris Boot @ 2011-12-21 21:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: lkml, netdev
In-Reply-To: <1324500775.2621.9.camel@edumazet-laptop>
On 21/12/2011 20:52, Eric Dumazet wrote:
> Le mercredi 21 décembre 2011 à 21:28 +0100, Eric Dumazet a écrit :
>> Le mercredi 21 décembre 2011 à 20:05 +0000, Chris Boot a écrit :
>>> On 21/12/2011 18:00, Eric Dumazet wrote:
>>>> Le mercredi 21 décembre 2011 à 18:36 +0100, Eric Dumazet a écrit :
>>>>
>>>>> Good point, thats a different problem then, since 3.1 is not supposed to
>>>>> have this bug.
>>>>>
>>>>> It seems rt->rt6i_peer points to invalid memory in your crash.
>>>>>
>>>>> (RBX=00000000000001f4)
>>>>>
>>>>> 8b 83 a4 00 00 00 mov 0xa4(%rbx),%eax p->refcnt
>>>>> 1f4+a4 -> CR2=0000000000000298
>>>>>
>>>> It would help if you can confirm latest linux tree can reproduce the
>>>> bug.
>>> Hi Eric,
>>>
>>> I just built a v3.2-rc6-140-gb9e26df with the same config as the Debian
>>> 3.1.0 kernel. I can reproduce the bug just as easily with this kernel as
>>> with the Debian kernel. Unfortunately I wasn't able to get an entire
>>> trace, for some reason it didn't appear to be printed to the serial port
>>> and hung after the (long) list of loaded kernel modules. The crash
>>> happens at the same offset:
>>>
>> Thanks !
>>
>> Oh well, br_netfilter fake_rtable strikes again.
>>
>> I'll cook a patch in a couple of minutes...
>>
> Could you try following patch ?
>
> [snip]
Eric,
It looks good! The rsync that caused the crash real quick hasn't done it
at all with the patch applied. I'll keep testing it of course, but I
think that's done it.
Many thanks indeed!
Chris
--
Chris Boot
bootc@bootc.net
^ permalink raw reply
* Re: [PATCH 4/4] microblaze: Remove NO_IRQ from architecture
From: Ryan Mallon @ 2011-12-21 22:09 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, netdev, devicetree-discuss, Grant Likely,
Benjamin Herrenschmidt
In-Reply-To: <1324477932-19262-4-git-send-email-monstr@monstr.eu>
On 22/12/11 01:32, Michal Simek wrote:
> NO_IRQ shouldn't be used by any driver. All Microblaze
> drivers are fixed that's why NO_IRQ can be removed.
This only describes half of what the patch does. You should also state
that arch/microblaze/pci/pci-common.c has references to NO_IRQ removed.
Maybe it' worth splitting this patch in half so the final patch just
does the removal of the NO_IRQ definition, but maybe that is overkill?
Other than that, for the whole series:
Reviewed-by: Ryan Mallon <rmallon@gmail.com>
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> CC: Grant Likely <grant.likely@secretlab.ca>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Ryan Mallon <rmallon@gmail.com>
> ---
> arch/microblaze/include/asm/irq.h | 2 --
> arch/microblaze/pci/pci-common.c | 4 ++--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/microblaze/include/asm/irq.h b/arch/microblaze/include/asm/irq.h
> index b116a82..a175132 100644
> --- a/arch/microblaze/include/asm/irq.h
> +++ b/arch/microblaze/include/asm/irq.h
> @@ -27,8 +27,6 @@ typedef unsigned long irq_hw_number_t;
>
> extern unsigned int nr_irq;
>
> -#define NO_IRQ 0
> -
> struct pt_regs;
> extern void do_IRQ(struct pt_regs *regs);
>
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
> index db841c7..0d71b2e 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -242,7 +242,7 @@ int pci_read_irq_line(struct pci_dev *pci_dev)
> line, pin);
>
> virq = irq_create_mapping(NULL, line);
> - if (virq != NO_IRQ)
> + if (virq)
> irq_set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
> } else {
> pr_debug(" Got one, spec %d cells (0x%08x 0x%08x...) on %s\n",
> @@ -253,7 +253,7 @@ int pci_read_irq_line(struct pci_dev *pci_dev)
> virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
> oirq.size);
> }
> - if (virq == NO_IRQ) {
> + if (!virq) {
> pr_debug(" Failed to map !\n");
> return -1;
> }
^ 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