* Re: Atheros driver
From: Luis R. Rodriguez @ 2008-01-07 17:44 UTC (permalink / raw)
To: John W. Linville
Cc: Ralph Spitzner, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080106212155.GA3149-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Jan 6, 2008 4:21 PM, John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
>
> On Sun, Jan 06, 2008 at 09:04:02PM +0100, Ralph Spitzner wrote:
> > With Kernel 2.6.23.12 && ath5k I get this:
> > ------------------------------------------------------------------
> >
> > Jan 6 20:42:44 meepmeep kernel: CPU: 0
> > Jan 6 20:42:44 meepmeep kernel: EIP: 0060:[<d0d98e61>] Not tainted
> > VLI
> > Jan 6 20:42:44 meepmeep kernel: EFLAGS: 00010246 (2.6.23.12 #1)
> > Jan 6 20:42:44 meepmeep kernel: EIP is at
> > ieee80211_generic_frame_duration+0x21/0x70 [mac80211]
> > Jan 6 20:42:44 meepmeep kernel: eax: c2c68180 ebx: c2c68180 ecx:
> > 0000000a edx: 00000000
> > Jan 6 20:42:44 meepmeep kernel: esi: 00000000 edi: 0000000a ebp:
> > 000003e8 esp: c3a03dd8
> > Jan 6 20:42:44 meepmeep kernel: ds: 007b es: 007b fs: 0000 gs: 0033
> > ss: 0068
> > Jan 6 20:42:44 meepmeep kernel: Process ifconfig (pid: 5119, ti=c3a02000
> > task=c363c570 task.ti=c3a02000)
> > Jan 6 20:42:44 meepmeep kernel: Stack: d0e7539b 00000002 0000876c 00000000
> > c4555000 d0e71c67 0000000a 1fb748ed
> > Jan 6 20:42:44 meepmeep kernel: 0000006b c2c68180 00000000 d0e76e44
> > c2c68eec 00000000 00000000 00000003
> > Jan 6 20:42:44 meepmeep kernel: 00000002 00000002 00000014 00000000
> > d0e76e20 c2c68de0 00000001 00000003
> > Jan 6 20:42:44 meepmeep kernel: Call Trace:
> > Jan 6 20:42:44 meepmeep kernel: [<d0e7539b>] ath5k_hw_rfgain+0x4b/0x80
> > [ath5k]
> > Jan 6 20:42:44 meepmeep kernel: [<d0e71c67>] ath5k_hw_reset+0xaa7/0xeb0
> > [ath5k]
> > Jan 6 20:42:44 meepmeep kernel: [<d0e6a766>] ath5k_init+0x46/0x110 [ath5k]
> > Jan 6 20:42:44 meepmeep kernel: [<d0d86b7c>] ieee80211_open+0x19c/0x4c0
> > [mac80211]
> > Jan 6 20:42:44 meepmeep kernel: [<c0142235>] filemap_fault+0x1c5/0x3e0
> > Jan 6 20:42:44 meepmeep kernel: [<c06a1353>] dev_open+0x33/0x80
> > Jan 6 20:42:44 meepmeep kernel: [<c069f1a9>] dev_change_flags+0x149/0x1c0
> > Jan 6 20:42:44 meepmeep kernel: [<c06e7261>] devinet_ioctl+0x521/0x6c0
> > Jan 6 20:42:44 meepmeep kernel: [<c069efbf>] __dev_get_by_name+0x6f/0x90
> > Jan 6 20:42:44 meepmeep kernel: [<c0693f4f>] sock_ioctl+0xbf/0x230
> > Jan 6 20:42:44 meepmeep kernel: [<c0113b2b>] do_page_fault+0x18b/0x6d0
> > Jan 6 20:42:44 meepmeep kernel: [<c0693e90>] sock_ioctl+0x0/0x230
> > Jan 6 20:42:44 meepmeep kernel: [<c01682cf>] do_ioctl+0x1f/0x70
> > Jan 6 20:42:44 meepmeep kernel: [<c016837c>] vfs_ioctl+0x5c/0x260
> > Jan 6 20:42:44 meepmeep kernel: [<c01685f2>] sys_ioctl+0x72/0x90
> > Jan 6 20:42:44 meepmeep kernel: [<c0104012>] syscall_call+0x7/0xb
> > Jan 6 20:42:44 meepmeep kernel: [<c0710000>] __svc_create+0x1c0/0x1d0
> > Jan 6 20:42:44 meepmeep kernel: =======================
> > Jan 6 20:42:44 meepmeep kernel: Code: 5d c3 90 8d b4 26 00 00 00 00 83 ec
> > 14 89 5c 24 08 89 c3 89 74 24 0c 89 d6 89 7c 24 10
> > 89 cf 8b 4c 24 18 83 78 0c 02 74 31 31 d2 <8b> 86 d0 fd ff ff 89 14 24 89
> > fa 83 e0 08 89 44 24 04 89 d8 e8
> > Jan 6 20:42:44 meepmeep kernel: EIP: [<d0d98e61>]
> > ieee80211_generic_frame_duration+0x21/0x70 [mac80211] SS:ESP 0068:c3a03dd8
> > Jan 6 20:47:27 meepmeep kernel: ACPI: RTC can wake from S4
> >
> > ------------------------------------------------------------------
> >
> >
> > Just in case someone is interested in this......
>
> I'm sure someone is interested
This is fixed by the patch titled: "[PATCH] ath5k: Fix frame duration
oops" posted on January 4rth.
Luis
^ permalink raw reply
* Re: Top 10 kernel oopses for the week ending January 5th, 2008
From: J. Bruce Fields @ 2008-01-07 17:44 UTC (permalink / raw)
To: Al Viro
Cc: Arjan van de Ven, Linux Kernel Mailing List, Linus Torvalds,
Andrew Morton, NetDev
In-Reply-To: <20080105213935.GN27894@ZenIV.linux.org.uk>
On Sat, Jan 05, 2008 at 09:39:35PM +0000, Al Viro wrote:
> On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote:
> > The http://www.kerneloops.org website collects kernel oops and
> > warning reports from various mailing lists and bugzillas as well as
> > with a client users can install to auto-submit oopses.
> > Below is a top 10 list of the oopses collected in the last 7 days.
> > (Reports prior to 2.6.23 have been omitted in collecting the top 10)
> >
> > This week, a total of 49 oopses and warnings have been reported,
> > compared to 53 reports in the previous week.
>
> FWIW, people moaning about the lack of entry-level kernel work would
> do well by decoding those to the level of "this place in this function,
> called from <here>, with so-and-so variable being <this>" and posting
> the results. As skills go, it's far more useful than "how to trim
> the trailing whitespace" and the rest of checkpatch.pl-inspired crap
> that got so popular lately...
Is there any good basic documentation on this to point people at?
--b.
^ permalink raw reply
* [PATCH 1/3] ethtool: fix typo on setting speed 10000
From: Auke Kok @ 2008-01-07 17:36 UTC (permalink / raw)
To: jeff; +Cc: netdev, jesse.brandeburg, davem
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
fix the typo in speed 10000 setting.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
ethtool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 3adf843..a668b49 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -524,7 +524,7 @@ static void parse_cmdline(int argc, char **argp)
speed_wanted = SPEED_1000;
else if (!strcmp(argp[i], "2500"))
speed_wanted = SPEED_2500;
- else if (!strcmp(argp[1], "10000"))
+ else if (!strcmp(argp[i], "10000"))
speed_wanted = SPEED_10000;
else
show_usage(1);
^ permalink raw reply related
* [PATCH 2/3] ethtool: update license field in specfile to be correctly defined
From: Auke Kok @ 2008-01-07 17:36 UTC (permalink / raw)
To: jeff; +Cc: netdev, jesse.brandeburg, davem
In-Reply-To: <20080107173602.8429.56354.stgit@localhost.localdomain>
RPM uses "License" as field and not "Copyright".
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
ethtool.spec.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ethtool.spec.in b/ethtool.spec.in
index 1705d7f..4ff736a 100644
--- a/ethtool.spec.in
+++ b/ethtool.spec.in
@@ -5,7 +5,7 @@ Group : Utilities
Summary : A tool for setting ethernet parameters
-Copyright : GPL
+License : GPL
URL : http://sourceforge.net/projects/gkernel/
Buildroot : %{_tmppath}/%{name}-%{version}
^ permalink raw reply related
* [PATCH 3/3] ethtool: correct man page for advertise mask value of 10gig
From: Auke Kok @ 2008-01-07 17:36 UTC (permalink / raw)
To: jeff; +Cc: netdev, jesse.brandeburg, davem
In-Reply-To: <20080107173602.8429.56354.stgit@localhost.localdomain>
10 gigabit is defined as 0x1000 in the advertise mask. The man
page mistakenly lists 0x800.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
ethtool.8 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ethtool.8 b/ethtool.8
index af51056..cc6a46e 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -362,7 +362,7 @@ a hexidecimal value using one or a combination of the following values:
.TP 3
.BR "0x8000" " 2500 Full" "(not supported by IEEE standards)"
.TP 3
-.BR "0x800" " 10000 Full"
+.BR "0x1000" " 10000 Full"
.TP 3
.BR "0x03F" " Auto"
.PD
^ permalink raw reply related
* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: Brian Haley @ 2008-01-07 17:03 UTC (permalink / raw)
To: David Stevens
Cc: David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <OF27B7DA9C.52E5380F-ON882573B6.00650422-882573B6.0068581B@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
David Stevens wrote:
> Yeah, that's what I get for typing in off-the-cuff code. What
> I was thinking was the fl.oif assignment instead was:
> if (!sk->sk_bound_dev_if &&
> (addr_type & IPV6_ADDR_MULTICAST))
> sk->sk_bound_dev_if = np->mcast_oif;
>
> Which it is not, but maybe it could be, since this is a connect().
How about the simple patch below? I just removed the ENINVAL check from
my original patch, but it accomplishes the same thing.
> That patch looks better, but I'm wondering if we could just remove the
> requirement that sin6_scope_id be set here if it's multicast, since it
> is doing the following later in the code:
>
> if (!fl.oif && (addr_type&IPV6_ADDR_MULTICAST))
> fl.oif = np->mcast_oif;
>
> So, really, all we need to do is get through the LINKLOCAL section
> without error in the multicast case and we can remove the redundant
> multicast check there. I think that'd be simpler.
I don't think we can remove that check since it covers the non-multicast
case.
-Brian
Signed-off-by: Brian Haley <brian.haley@hp.com>
---
[-- Attachment #2: mcast_oif.patch --]
[-- Type: text/x-patch, Size: 574 bytes --]
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 2ed689a..5d4245a 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -123,11 +123,11 @@ ipv4_connected:
goto out;
}
sk->sk_bound_dev_if = usin->sin6_scope_id;
- if (!sk->sk_bound_dev_if &&
- (addr_type & IPV6_ADDR_MULTICAST))
- fl.oif = np->mcast_oif;
}
+ if (!sk->sk_bound_dev_if && (addr_type & IPV6_ADDR_MULTICAST))
+ sk->sk_bound_dev_if = np->mcast_oif;
+
/* Connect to link-local address requires an interface */
if (!sk->sk_bound_dev_if) {
err = -EINVAL;
^ permalink raw reply related
* Re: [patch 5/9][NETNS][IPV6] make bindv6only sysctl per namespace
From: Eric Dumazet @ 2008-01-07 16:49 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: Benjamin Thery, davem, netdev
In-Reply-To: <47825513.50100@fr.ibm.com>
On Mon, 07 Jan 2008 17:36:35 +0100
Daniel Lezcano <dlezcano@fr.ibm.com> wrote:
> Benjamin Thery wrote:
> > Daniel,
> >
> > The kernel fails to build with this patch applied when CONFIG_SYSCTL=n
> > See comment below.
> >
> > Daniel Lezcano wrote:
> >> This patch moves the bindv6only sysctl to the network namespace
> >> structure. Until the ipv6 protocol is not per namespace, the sysctl
> >> variable is always from the initial network namespace.
>
> Argh !
>
> Thanks Benjamin to catch this.
>
> I think I have to apologize to Eric, I thought I tested with this option
> off but it wasn't and Eric was right. I will wait a little for feedbacks
> and send a V3.
No problem Daniel :)
^ permalink raw reply
* [DCCP] [Announce]: Test tree updates
From: Gerrit Renker @ 2008-01-07 16:47 UTC (permalink / raw)
To: Arnaldo; +Cc: dccp, netdev
This is an edited list of recent changes in the test tree
git://eden-feed.erg.abdn.ac.uk/dccp_exp
At the top of each block is the name of the patch, followed by a short
description of the change, and the actual (or abridged if obvious) inter-diff.
Some of these changes refer to improved patches/bug-fixes, which are to be
submitted soon.
Gerrit
================================================================================
[DCCP]: Registration routines for changing feature values
==> Added symbolic constants for the Sequence Window / Ack Ratio limits
==> Added these constants to feat.c / ccid2.c (not shown)
--- a/net/dccp/feat.h
+++ b/net/dccp/feat.h
@@ -14,6 +14,15 @@
#include <linux/types.h>
#include "dccp.h"
+/*
+ * Known limits of feature values.
+ */
+/* Ack Ratio takes 2-byte integer values (11.3) */
+#define DCCPF_ACK_RATIO_MAX 0xFFFF
+/* Wmin=32 and Wmax=2^46-1 from 7.5.2 */
+#define DCCPF_SEQ_WMIN 32
+#define DCCPF_SEQ_WMAX 0x3FFFFFFFFFFFull
+
enum dccp_feat_type {
FEAT_AT_RX = 1, /* located at RX side of half-connection */
FEAT_AT_TX = 2, /* located at TX side of half-connection */
================================================================================
[DCCP]: Implement both feature-local and feature-remote Sequence Window feature
==> Removed the default initialisation of the Sequence Window feature value.
This is redundant, a better solution is implemented in subsequent patch set.
==> Also calls the Sequence Window handlers immediately, so that the sequence
and acknowledgment validity windows are updated.
--- a/net/dccp/feat.c
+++ b/net/dccp/feat.c
@@ -1086,19 +1086,6 @@ int dccp_feat_init(struct sock *sk)
rc = dccp_feat_register_sp(fn, sp[i].feat_num, sp[i].is_local,
sp[i].mandatory, sp[i].val, sp[i].len);
- /*
- * Initial values for the remote and local Sequence Window feature. This
- * is only for the client startup phase, to seed AWL/SWL. Until then,
- * - the default of 100 is enough for 75 Request-retransmissions,
- * - sequence window checks are not performed in state LISTEN/REQUEST,
- * - the only Ack window check is for the Ack completing the handshake.
- * After the handshake, local/remote Sequence Window will be updated
- * with the negotiated values (or the defaults again if not different).
- * The server's AWL/SWL derive directly from the negotiated values.
- */
- for (i = 0; rc == 0 && i <= 1; i++)
- rc = dccp_feat_activate(sk, DCCPF_SEQUENCE_WINDOW, i, NULL);
-
kfree(sp[0].val);
kfree(sp[1].val);
return rc;
--- a/net/dccp/minisocks.c
+++ b/net/dccp/minisocks.c
@@ -319,10 +319,17 @@ int dccp_hdlr_ccid(struct sock *sk, u64
int dccp_hdlr_seq_win(struct sock *sk, u64 seq_win, bool rx)
{
- if (rx)
- dccp_sk(sk)->dccps_r_seq_win = seq_win;
- else
- dccp_sk(sk)->dccps_l_seq_win = seq_win;
+ struct dccp_sock *dp = dccp_sk(sk);
+
+ if (rx) {
+ dp->dccps_r_seq_win = seq_win;
+ /* propagate changes to update SWL/SWH */
+ dccp_update_gsr(sk, dp->dccps_gsr);
+ } else {
+ dp->dccps_l_seq_win = seq_win;
+ /* propagate changes to update AWL */
+ dccp_update_gss(sk, dp->dccps_gss);
+ }
return 0;
}
================================================================================
[DCCP]: Support exchange of NN options in (PART)OPEN state
==> Lifted the restriction to exchanging only Ack Ratio options, since Sequence
Window values also need to be updated in established state.
Patches to actually do this for CCID2 are work in progress.
--- a/net/dccp/feat.c
+++ b/net/dccp/feat.c
@@ -1176,12 +1177,7 @@ static u8 dccp_feat_handle_nn_establishe
} else if (type != FEAT_NN) {
return 0;
}
- /*
- * The restriction to Ack Ratio is here for safety: it may be possible
- * to lift this and also update Sequence Window dynamically.
- */
- if (feat != DCCPF_ACK_RATIO)
- return 0;
+
/*
* We don't accept empty Confirms, since in fast-path feature
* negotiation the values are enabled immediately after sending
================================================================================
[ACKVEC]: Update Ack Vector input routine
==> Added a "cope with large bursts" recovery hook as follows:
When a packet is missing, the Ack Vector code normally reserves one entry. This
causes problems with larger losses, since the space requirements are O(burst_length).
This patch defines a threshold for bursty loss, when exceeding this threshold,
Ack Vector cells are populated up to their limit, without the expensive space
reservation.
The advantage of this strategy is to reduce Ack Vector length under heavier loss
conditions.
--- b/net/dccp/ackvec.h
+++ b/net/dccp/ackvec.h
@@ -27,6 +27,9 @@
#define DCCPAV_NUM_ACKVECS 2
#define DCCPAV_MAX_ACKVEC_LEN (DCCP_SINGLE_OPT_MAXLEN * DCCPAV_NUM_ACKVECS)
+/* Threshold for coping with large bursts of losses */
+#define DCCPAV_BURST_THRESH (DCCPAV_MAX_ACKVEC_LEN / 8)
+
enum dccp_ackvec_states {
DCCPAV_RECEIVED = 0x00,
DCCPAV_ECN_MARKED = 0x40,
--- b/net/dccp/ackvec.c
+++ b/net/dccp/ackvec.c
@@ -206,10 +206,38 @@
* @seqno: sequence number of the first packet in @num_packets
* @state: state in which packet carrying @seqno was received
*/
-static void dccp_ackvec_add_new(struct dccp_ackvec *av, u16 num_packets,
+static void dccp_ackvec_add_new(struct dccp_ackvec *av, u32 num_packets,
u64 seqno, enum dccp_ackvec_states state)
{
- if ((num_packets + dccp_ackvec_buflen(av)) >= DCCPAV_MAX_ACKVEC_LEN) {
+ u32 num_cells = num_packets;
+
+ if (num_packets > DCCPAV_BURST_THRESH) {
+ u32 lost_packets = num_packets - 1;
+
+ DCCP_WARN("Warning: large burst loss (%u)\n", lost_packets);
+ /*
+ * We received 1 packet and have a loss of size "num_packets-1"
+ * which we squeeze into num_cells-1 rather than reserving an
+ * entire byte for each lost packet.
+ * The reason is that the vector grows in O(burst_length); when
+ * it grows too large there will no room left for the payload.
+ * This is a trade-off: if a few packets out of the burst show
+ * up later, their state will not be changed; it is simply too
+ * costly to reshuffle/reallocate/copy the buffer each time.
+ * Should such problems persist, we will need to switch to a
+ * different underlying data structure.
+ */
+ for (num_packets = num_cells = 1; lost_packets; ++num_cells) {
+ u8 len = min(lost_packets, (u32)DCCPAV_MAX_RUNLEN);
+
+ av->av_buf_head = dccp_ackvec_idx_sub(av->av_buf_head, 1);
+ av->av_buf[av->av_buf_head] = DCCPAV_NOT_RECEIVED | len;
+
+ lost_packets -= len;
+ }
+ }
+
+ if (num_cells + dccp_ackvec_buflen(av) >= DCCPAV_MAX_ACKVEC_LEN) {
DCCP_CRIT("Ack Vector buffer overflow: dropping old entries\n");
av->av_overflow = true;
}
--
^ permalink raw reply
* Re: [patch 5/9][NETNS][IPV6] make bindv6only sysctl per namespace
From: Daniel Lezcano @ 2008-01-07 16:36 UTC (permalink / raw)
To: Benjamin Thery, davem; +Cc: netdev, Eric Dumazet
In-Reply-To: <47825402.8030504@bull.net>
Benjamin Thery wrote:
> Daniel,
>
> The kernel fails to build with this patch applied when CONFIG_SYSCTL=n
> See comment below.
>
> Daniel Lezcano wrote:
>> This patch moves the bindv6only sysctl to the network namespace
>> structure. Until the ipv6 protocol is not per namespace, the sysctl
>> variable is always from the initial network namespace.
Argh !
Thanks Benjamin to catch this.
I think I have to apologize to Eric, I thought I tested with this option
off but it wasn't and Eric was right. I will wait a little for feedbacks
and send a V3.
^ permalink raw reply
* Re: [patch 5/9][NETNS][IPV6] make bindv6only sysctl per namespace
From: Benjamin Thery @ 2008-01-07 16:32 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: davem, netdev
In-Reply-To: <20080104111431.444295890@localhost.localdomain>
Daniel,
The kernel fails to build with this patch applied when CONFIG_SYSCTL=n
See comment below.
Daniel Lezcano wrote:
> This patch moves the bindv6only sysctl to the network namespace
> structure. Until the ipv6 protocol is not per namespace, the sysctl
> variable is always from the initial network namespace.
>
> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
> ---
> include/net/ipv6.h | 1 -
> include/net/netns/ipv6.h | 1 +
> net/ipv6/af_inet6.c | 4 +---
> net/ipv6/sysctl_net_ipv6.c | 6 +++++-
> 4 files changed, 7 insertions(+), 5 deletions(-)
>
> Index: net-2.6.25/include/net/ipv6.h
> ===================================================================
> --- net-2.6.25.orig/include/net/ipv6.h
> +++ net-2.6.25/include/net/ipv6.h
> @@ -109,7 +109,6 @@ struct frag_hdr {
> #include <net/sock.h>
>
> /* sysctls */
> -extern int sysctl_ipv6_bindv6only;
> extern int sysctl_mld_max_msf;
>
> #define _DEVINC(statname, modifier, idev, field) \
> Index: net-2.6.25/include/net/netns/ipv6.h
> ===================================================================
> --- net-2.6.25.orig/include/net/netns/ipv6.h
> +++ net-2.6.25/include/net/netns/ipv6.h
> @@ -9,6 +9,7 @@ struct ctl_table_header;
>
> struct netns_sysctl_ipv6 {
> struct ctl_table_header *table;
> + int bindv6only;
> };
>
> struct netns_ipv6 {
> Index: net-2.6.25/net/ipv6/af_inet6.c
> ===================================================================
> --- net-2.6.25.orig/net/ipv6/af_inet6.c
> +++ net-2.6.25/net/ipv6/af_inet6.c
> @@ -66,8 +66,6 @@ MODULE_AUTHOR("Cast of dozens");
> MODULE_DESCRIPTION("IPv6 protocol stack for Linux");
> MODULE_LICENSE("GPL");
>
> -int sysctl_ipv6_bindv6only __read_mostly;
> -
> /* The inetsw6 table contains everything that inet6_create needs to
> * build a new socket.
> */
> @@ -193,7 +191,7 @@ lookup_protocol:
> np->mcast_hops = -1;
> np->mc_loop = 1;
> np->pmtudisc = IPV6_PMTUDISC_WANT;
> - np->ipv6only = sysctl_ipv6_bindv6only;
> + np->ipv6only = init_net.ipv6.sysctl.bindv6only;
The problem is here:
init_net.ipv6.sysctl is not defined if CONFIG_SYSCTL=n.
Benjamin
>
> /* Init the ipv4 part of the socket since we can have sockets
> * using v6 API for ipv4.
> Index: net-2.6.25/net/ipv6/sysctl_net_ipv6.c
> ===================================================================
> --- net-2.6.25.orig/net/ipv6/sysctl_net_ipv6.c
> +++ net-2.6.25/net/ipv6/sysctl_net_ipv6.c
> @@ -35,7 +35,7 @@ static ctl_table ipv6_table_template[] =
> {
> .ctl_name = NET_IPV6_BINDV6ONLY,
> .procname = "bindv6only",
> - .data = &sysctl_ipv6_bindv6only,
> + .data = &init_net.ipv6.sysctl.bindv6only,
> .maxlen = sizeof(int),
> .mode = 0644,
> .proc_handler = &proc_dointvec
> @@ -115,6 +115,10 @@ static int ipv6_sysctl_net_init(struct n
> ipv6_table[0].child = ipv6_route_table;
> ipv6_table[1].child = ipv6_icmp_table;
>
> + ipv6_table[2].data = &net->ipv6.sysctl.bindv6only;
> +
> + net->ipv6.sysctl.bindv6only = 0;
> +
> net->ipv6.sysctl.table = register_net_sysctl_table(net, ipv6_ctl_path, ipv6_table);
> if (!net->ipv6.sysctl.table)
> goto out_ipv6_icmp_table;
>
> -- -- 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
--
B e n j a m i n T h e r y - BULL/DT/Open Software R&D
http://www.bull.com
^ permalink raw reply
* Re: [IPV4] ROUTE: Avoid sparse warnings
From: Eric Dumazet @ 2008-01-07 13:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, netdev, viro
In-Reply-To: <E1JBqpd-0006vB-00@gondolin.me.apana.org.au>
On Mon, 07 Jan 2008 23:11:53 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Eric Dumazet <dada1@cosmosbay.com> wrote:
> > CHECK net/ipv4/route.c
> > net/ipv4/route.c:298:2: warning: context imbalance in 'rt_cache_get_first' - wrong count at exit
> > net/ipv4/route.c:307:3: warning: context imbalance in 'rt_cache_get_next' - unexpected unlock
> > net/ipv4/route.c:346:3: warning: context imbalance in 'rt_cache_seq_stop' - unexpected unlock
> >
> > Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
> >
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index 10915bb..fec0571 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -289,11 +289,11 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
> > struct rt_cache_iter_state *st = seq->private;
> >
> > for (st->bucket = rt_hash_mask; st->bucket >= 0; --st->bucket) {
> > - rcu_read_lock_bh();
> > r = rt_hash_table[st->bucket].chain;
> > if (r)
> > break;
> > rcu_read_unlock_bh();
> > + rcu_read_lock_bh();
>
> If we have to change perfectly working code to silence sparse then
> either sparse or we are doing something wrong.
>
> This is not the only spot where we conditionally hold the lock.
> There's got to be a better fix than changing all of them to hold
> locks unconditionally.
Maybe sparse (or me :) ) is a litle bit dumb :(
You are right other functions conditionally hold some lock(s), but in this
case this is not really necessary / worth the complexity.
AFAIK, this patch reduces complexity and text size.
^ permalink raw reply
* [PATCH][LRO] Fix lro_mgr->features checks
From: Brice Goglin @ 2008-01-07 13:33 UTC (permalink / raw)
To: David S. Miller
Cc: Andrew J. Gallatin, Jan-Bernd Themann, Linus Torvalds, LKML,
netdev
Hi Dave,
The LRO_F_* checks in inet_lro.c are buggy, the following patch
is needed to check lro_mgr->features correctly.
I decided to follow the NETIF_F_* convention and thus removed
test_bit. Some people might like it better if we keep using
test_bit and just set lro_mgr->features to 1<<LRO_F_NAPI instead
of just LRO_F_NAPI. I don't know what's the best.
Without this patch, we noticed several problems with myri10ge,
at least when using non-IP packets. I guess the ehea driver did
not expose any big problem because test_bit(NAPI) returns true
thanks to lro_mgr->features containing LRO_F_EXTRACT_VLAN_ID.
Please apply for 2.6.24.
Brice
[PATCH][LRO] Fix lro_mgr->features checks
lro_mgr->features contains a bitmask of LRO_F_* values which are
defined as power of two, not as bit indexes.
They must be checked with x&LRO_F_FOO, not with test_bit(LRO_F_FOO,&x).
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
Acked-by: Andrew Gallatin <gallatin@myri.com>
---
diff --git a/net/ipv4/inet_lro.c b/net/ipv4/inet_lro.c
index 9a96c27..4a4d49f 100644
--- a/net/ipv4/inet_lro.c
+++ b/net/ipv4/inet_lro.c
@@ -310,7 +310,7 @@ static void lro_flush(struct net_lro_mgr *lro_mgr,
skb_shinfo(lro_desc->parent)->gso_size = lro_desc->mss;
if (lro_desc->vgrp) {
- if (test_bit(LRO_F_NAPI, &lro_mgr->features))
+ if (lro_mgr->features & LRO_F_NAPI)
vlan_hwaccel_receive_skb(lro_desc->parent,
lro_desc->vgrp,
lro_desc->vlan_tag);
@@ -320,7 +320,7 @@ static void lro_flush(struct net_lro_mgr *lro_mgr,
lro_desc->vlan_tag);
} else {
- if (test_bit(LRO_F_NAPI, &lro_mgr->features))
+ if (lro_mgr->features & LRO_F_NAPI)
netif_receive_skb(lro_desc->parent);
else
netif_rx(lro_desc->parent);
@@ -352,7 +352,7 @@ static int __lro_proc_skb(struct net_lro_mgr *lro_mgr, struct sk_buff *skb,
goto out;
if ((skb->protocol == htons(ETH_P_8021Q))
- && !test_bit(LRO_F_EXTRACT_VLAN_ID, &lro_mgr->features))
+ && !(lro_mgr->features & LRO_F_EXTRACT_VLAN_ID))
vlan_hdr_len = VLAN_HLEN;
if (!lro_desc->active) { /* start new lro session */
@@ -474,7 +474,7 @@ static struct sk_buff *__lro_proc_segment(struct net_lro_mgr *lro_mgr,
goto out;
if ((skb->protocol == htons(ETH_P_8021Q))
- && !test_bit(LRO_F_EXTRACT_VLAN_ID, &lro_mgr->features))
+ && !(lro_mgr->features & LRO_F_EXTRACT_VLAN_ID))
vlan_hdr_len = VLAN_HLEN;
iph = (void *)(skb->data + vlan_hdr_len);
@@ -516,7 +516,7 @@ void lro_receive_skb(struct net_lro_mgr *lro_mgr,
void *priv)
{
if (__lro_proc_skb(lro_mgr, skb, NULL, 0, priv)) {
- if (test_bit(LRO_F_NAPI, &lro_mgr->features))
+ if (lro_mgr->features & LRO_F_NAPI)
netif_receive_skb(skb);
else
netif_rx(skb);
@@ -531,7 +531,7 @@ void lro_vlan_hwaccel_receive_skb(struct net_lro_mgr *lro_mgr,
void *priv)
{
if (__lro_proc_skb(lro_mgr, skb, vgrp, vlan_tag, priv)) {
- if (test_bit(LRO_F_NAPI, &lro_mgr->features))
+ if (lro_mgr->features & LRO_F_NAPI)
vlan_hwaccel_receive_skb(skb, vgrp, vlan_tag);
else
vlan_hwaccel_rx(skb, vgrp, vlan_tag);
@@ -550,7 +550,7 @@ void lro_receive_frags(struct net_lro_mgr *lro_mgr,
if (!skb)
return;
- if (test_bit(LRO_F_NAPI, &lro_mgr->features))
+ if (lro_mgr->features & LRO_F_NAPI)
netif_receive_skb(skb);
else
netif_rx(skb);
@@ -570,7 +570,7 @@ void lro_vlan_hwaccel_receive_frags(struct net_lro_mgr *lro_mgr,
if (!skb)
return;
- if (test_bit(LRO_F_NAPI, &lro_mgr->features))
+ if (lro_mgr->features & LRO_F_NAPI)
vlan_hwaccel_receive_skb(skb, vgrp, vlan_tag);
else
vlan_hwaccel_rx(skb, vgrp, vlan_tag);
^ permalink raw reply related
* Re: [git patches] net driver fixes
From: Meelis Roos @ 2008-01-07 12:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Stephen Hemminger
In-Reply-To: <47738F31.20304@garzik.org>
> > JG> A couple [minorly] notable wireless bug fixes, and plenty of viro fixes
> > JG> for obscure issues :)
> >
> > What about the tulip NAPI fix from Stephen Hemminger? Without this, my tulip
> > is hosed easily.
> >
> > The thread where I reported it was "Badness at net/core/dev.c:2199", around
> > Dec 16.
>
> That's going up in the first post-Xmas batch.
Well, it's 2.6.24-rc7 already - any news?
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [IPV4] ROUTE: Avoid sparse warnings
From: Herbert Xu @ 2008-01-07 12:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, viro
In-Reply-To: <20080107120117.aeebd0c8.dada1@cosmosbay.com>
Eric Dumazet <dada1@cosmosbay.com> wrote:
> CHECK net/ipv4/route.c
> net/ipv4/route.c:298:2: warning: context imbalance in 'rt_cache_get_first' - wrong count at exit
> net/ipv4/route.c:307:3: warning: context imbalance in 'rt_cache_get_next' - unexpected unlock
> net/ipv4/route.c:346:3: warning: context imbalance in 'rt_cache_seq_stop' - unexpected unlock
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 10915bb..fec0571 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -289,11 +289,11 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
> struct rt_cache_iter_state *st = seq->private;
>
> for (st->bucket = rt_hash_mask; st->bucket >= 0; --st->bucket) {
> - rcu_read_lock_bh();
> r = rt_hash_table[st->bucket].chain;
> if (r)
> break;
> rcu_read_unlock_bh();
> + rcu_read_lock_bh();
If we have to change perfectly working code to silence sparse then
either sparse or we are doing something wrong.
This is not the only spot where we conditionally hold the lock.
There's got to be a better fix than changing all of them to hold
locks unconditionally.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: forcedeth: MAC-address reversed on resume from suspend
From: Adolfo R. Brandes @ 2008-01-07 12:02 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Adrian Bunk, Andreas Mohr, Richard Jonsson, linux-kernel,
Ayaz Abdulla, jgarzik, netdev
In-Reply-To: <20080107014638.GA4170@atjola.homenet>
Hi,
On Jan 6, 2008 10:46 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Any chance that you applied the patch on your modified sources and didn't get it right?
It is perfectly possible that I messed something up, although I
double checked what I was doing on the MCP51. However, on that board
(an Asus M2NPV-VM) I'm running the 2.6.22-based Ubuntu Gutsy default
kernel with a recompiled forcedeth, as opposed to a vanilla 2.6.24-rc6
on the CK804, where your patch worked. It may be that the different
kernel is throwing the patch off somehow.
Later on today I'm going to try the MCP51 with the same build of
2.6.24-rc6 (built on a .config from the Ubuntu Hardy development
kernel) I'm running on the CK804, and post results.
Adolfo
^ permalink raw reply
* [IPV4] ROUTE: Avoid sparse warnings
From: Eric Dumazet @ 2008-01-07 11:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
CHECK net/ipv4/route.c
net/ipv4/route.c:298:2: warning: context imbalance in 'rt_cache_get_first' - wrong count at exit
net/ipv4/route.c:307:3: warning: context imbalance in 'rt_cache_get_next' - unexpected unlock
net/ipv4/route.c:346:3: warning: context imbalance in 'rt_cache_seq_stop' - unexpected unlock
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 10915bb..fec0571 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -289,11 +289,11 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
struct rt_cache_iter_state *st = seq->private;
for (st->bucket = rt_hash_mask; st->bucket >= 0; --st->bucket) {
- rcu_read_lock_bh();
r = rt_hash_table[st->bucket].chain;
if (r)
break;
rcu_read_unlock_bh();
+ rcu_read_lock_bh();
}
return r;
}
@@ -305,9 +305,9 @@ static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
r = r->u.dst.rt_next;
while (!r) {
rcu_read_unlock_bh();
+ rcu_read_lock_bh();
if (--st->bucket < 0)
break;
- rcu_read_lock_bh();
r = rt_hash_table[st->bucket].chain;
}
return r;
@@ -324,7 +324,9 @@ static struct rtable *rt_cache_get_idx(struct seq_file *seq, loff_t pos)
}
static void *rt_cache_seq_start(struct seq_file *seq, loff_t *pos)
+ __acquires(RCU_BH)
{
+ rcu_read_lock_bh();
return *pos ? rt_cache_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
}
@@ -341,9 +343,9 @@ static void *rt_cache_seq_next(struct seq_file *seq, void *v, loff_t *pos)
}
static void rt_cache_seq_stop(struct seq_file *seq, void *v)
+ __releases(RCU_BH)
{
- if (v && v != SEQ_START_TOKEN)
- rcu_read_unlock_bh();
+ rcu_read_unlock_bh();
}
static int rt_cache_seq_show(struct seq_file *seq, void *v)
^ permalink raw reply related
* [PACKET]: Fix sparse warnings in af_packet.c
From: Eric Dumazet @ 2008-01-07 11:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
CHECK net/packet/af_packet.c
net/packet/af_packet.c:1876:14: warning: context imbalance in 'packet_seq_start' - wrong count at exit
net/packet/af_packet.c:1888:13: warning: context imbalance in 'packet_seq_stop' - unexpected unlock
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 43e49f4..b8b827c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1870,6 +1870,7 @@ static inline struct sock *packet_seq_idx(struct net *net, loff_t off)
}
static void *packet_seq_start(struct seq_file *seq, loff_t *pos)
+ __acquires(seq_file_net(seq)->packet.sklist_lock)
{
struct net *net = seq_file_net(seq);
read_lock(&net->packet.sklist_lock);
@@ -1886,6 +1887,7 @@ static void *packet_seq_next(struct seq_file *seq, void *v, loff_t *pos)
}
static void packet_seq_stop(struct seq_file *seq, void *v)
+ __releases(seq_file_net(seq)->packet.sklist_lock)
{
struct net *net = seq_file_net(seq);
read_unlock(&net->packet.sklist_lock);
^ permalink raw reply related
* Re: [PATCH 3/4] [XFRM]: Kill some bloat
From: Herbert Xu @ 2008-01-07 10:02 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David Miller, Netdev, Arnaldo Carvalho de Melo, paul.moore,
latten
In-Reply-To: <Pine.LNX.4.64.0801071000390.17676@kivilampi-30.cs.helsinki.fi>
On Mon, Jan 07, 2008 at 10:21:47AM +0200, Ilpo Järvinen wrote:
>
> Unexpected enough, even this logic seems to fail in a way with my gcc, I'm
> yet to study it closer but it seems to me that e.g., uninlining only once
> called tcp_fastretrans_alert is worth of at least 100 bytes (note that
> it's not inlined by us, gcc did it all by itself)! Otherwise I'd fail to
> understand why I got -270 bytes from uninlining tcp_moderate_cwnd which is
> only 57 bytes as unlined with three call sites.
Yeah I've studied this effect over the years in my maintainence of
the dash shell where size is paramount :)
On x86-32 due to the scarcity of registers local variables often end
up on the stack. In that case gcc will usually refer to them via %ebp
or %esp. It just so happens that if the offset is within 128 bytes
of the base register then the instruction can encode the offset with
just a single byte. However, if it exceeds 128 bytes the instruction
will take 4 bytes to encode the offset.
Since bigger functions are more likely to go over that threshold,
this explains some instances where uninlining ends up being bigger.
There are other similar issues, such as the branch offset which also
goes from 1 byte to 4 when you go over 128 bytes.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] IRDA: irda_create() nuke user triggable printk
From: David Miller @ 2008-01-07 8:31 UTC (permalink / raw)
To: max; +Cc: netdev, samuel
In-Reply-To: <1199666072-1824-1-git-send-email-max@stro.at>
From: maximilian attems <max@stro.at>
Date: Mon, 7 Jan 2008 01:34:32 +0100
> easy to trigger as user with sfuzz.
>
> irda_create() is quiet on unknown sock->type,
> match this behaviour for SOCK_DGRAM unknown protocol
>
> Signed-off-by: maximilian attems <max@stro.at>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/3] [SCTP]: Add back the code that accounted for FORWARD_TSN parameter in INIT.
From: David Miller @ 2008-01-07 8:28 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp-developers
In-Reply-To: <1199475946-11103-4-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 4 Jan 2008 14:45:46 -0500
> Some recent changes completely removed accounting for the FORWARD_TSN
> parameter length in the INIT and INIT-ACK chunk. This is wrong and
> should be restored.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Also applied, thanks Vlad.
^ permalink raw reply
* Re: [PATCH 2/3] [SCTP]: Correctly handle AUTH parameters in unexpected INIT
From: David Miller @ 2008-01-07 8:27 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp-developers
In-Reply-To: <1199475946-11103-3-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 4 Jan 2008 14:45:45 -0500
> When processing an unexpected INIT chunk, we do not need to
> do any preservation of the old AUTH parameters. In fact,
> doing such preservations will nullify AUTH and allow connection
> stealing.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] [SCTP]: Fix the name of the authentication event.
From: David Miller @ 2008-01-07 8:27 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, lksctp-developers
In-Reply-To: <1199475946-11103-2-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 4 Jan 2008 14:45:44 -0500
> The even should be called SCTP_AUTHENTICATION_INDICATION.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.24][ATM]: [nicstar] delay irq setup until card is configured
From: David Miller @ 2008-01-07 8:26 UTC (permalink / raw)
To: chas; +Cc: netdev
In-Reply-To: <200801042129.m04LTFxZ030640@cmf.nrl.navy.mil>
From: "chas williams - CONTRACTOR" <chas@cmf.nrl.navy.mil>
Date: Fri, 04 Jan 2008 16:29:15 -0500
> [ATM]: [nicstar] delay irq setup until card is configured
>
> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Applied, thanks Chas.
^ permalink raw reply
* Re: 2.6.24-rc6 oops in net_tx_action
From: David Miller @ 2008-01-07 8:23 UTC (permalink / raw)
To: linux; +Cc: romieu, jgarzik, linux-kernel, netdev, shemminger
In-Reply-To: <20080107064350.5042.qmail@science.horizon.com>
From: linux@horizon.com
Date: 7 Jan 2008 01:43:50 -0500
> Thanks! I got the patch from
> http://marc.info/?l=linux-netdev&m=119756785219214
> (Which didn't make it into -rc7; please fix!)
> and am recompiling now.
Jeff is busy so he's asked me to pick up the more important
driver bug fixes that get posted.
I'll push this around, thanks.
^ permalink raw reply
* Re: [PATCH 3/4] [XFRM]: Kill some bloat
From: Ilpo Järvinen @ 2008-01-07 8:21 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, Netdev, Arnaldo Carvalho de Melo, paul.moore,
latten
In-Reply-To: <E1JBJOR-0000jO-00@gondolin.me.apana.org.au>
On Sun, 6 Jan 2008, Herbert Xu wrote:
> is definitely not a fast path. If a function ends up being called
> just once the compiler will most likely inline it anyway, making the
> use of the keyword inline redundant.
Unexpected enough, even this logic seems to fail in a way with my gcc, I'm
yet to study it closer but it seems to me that e.g., uninlining only once
called tcp_fastretrans_alert is worth of at least 100 bytes (note that
it's not inlined by us, gcc did it all by itself)! Otherwise I'd fail to
understand why I got -270 bytes from uninlining tcp_moderate_cwnd which is
only 57 bytes as unlined with three call sites.
net/ipv4/tcp_input.c:
tcp_undo_cwr | -48
tcp_try_undo_recovery | -55
tcp_ack | -2941
3 functions changed, 3044 bytes removed, diff: -3044
net/ipv4/tcp_input.c:
tcp_moderate_cwnd | +57
tcp_fastretrans_alert | +2717
2 functions changed, 2774 bytes added, diff: +2774
net/ipv4/tcp_input.o:
5 functions changed, 2774 bytes added, 3044 bytes removed, diff: -270
I'll probably force uninlining of it without tcp_moderate_cwnd noise and
try a number of gcc versions.
--
i.
^ 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