* [patch] ipvs: Keep track of backlog connections
From: Simon Horman @ 2010-09-27 14:05 UTC (permalink / raw)
To: lvs-devel, netfilter-devel, netdev
Cc: Sven Wegener, Wensong Zhang, Julian Anastasov,
Venkata Mohan Reddy Koppula, Patrick McHardy
From: Sven Wegener <sven.wegener@stealer.net>
A backlog connection is a connection that is on its way from inactive to
active. Speaking in TCP language, a connection from which we've seen the
initial SYN packet, but the three-way handshake hasn't finished yet.
These connections are expected to move to active soon. When a
destination is overloaded or isn't able to successfully establish
connections for various reasons, this count increases quickly and is an
indication for a problem.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Simon Horman <horms@verge.net.au>
---
Patrick, please consider this for nf-next
diff -urp net-next-2.6-e548833-nfct/linux/include/linux/ip_vs.h linux/include/linux/ip_vs.h
--- net-next-2.6-e548833-nfct/linux/include/linux/ip_vs.h 2010-09-15 11:28:02.000000000 +0300
+++ linux/include/linux/ip_vs.h 2010-09-26 15:21:53.507865229 +0300
@@ -91,6 +91,7 @@
/* Flags that are not sent to backup server start from bit 16 */
#define IP_VS_CONN_F_NFCT (1 << 16) /* use netfilter conntrack */
+#define IP_VS_CONN_F_BACKLOG (1 << 17) /* backlog connection */
/* Connection flags from destination that can be changed by user space */
#define IP_VS_CONN_F_DEST_MASK (IP_VS_CONN_F_FWD_MASK | \
@@ -360,6 +361,7 @@ enum {
IPVS_DEST_ATTR_PERSIST_CONNS, /* persistent connections */
IPVS_DEST_ATTR_STATS, /* nested attribute for dest stats */
+ IPVS_DEST_ATTR_BACKLOG_CONNS, /* backlog connections */
__IPVS_DEST_ATTR_MAX,
};
diff -urp net-next-2.6-e548833-nfct/linux/include/net/ip_vs.h linux/include/net/ip_vs.h
--- net-next-2.6-e548833-nfct/linux/include/net/ip_vs.h 2010-09-16 08:53:04.000000000 +0300
+++ linux/include/net/ip_vs.h 2010-09-26 15:31:27.369865994 +0300
@@ -501,6 +501,7 @@ struct ip_vs_dest {
/* connection counters and thresholds */
atomic_t activeconns; /* active connections */
atomic_t inactconns; /* inactive connections */
+ atomic_t backlogconns; /* backlog connections */
atomic_t persistconns; /* persistent connections */
__u32 u_threshold; /* upper threshold */
__u32 l_threshold; /* lower threshold */
diff -urp net-next-2.6-e548833-nfct/linux/net/netfilter/ipvs/ip_vs_conn.c linux/net/netfilter/ipvs/ip_vs_conn.c
--- net-next-2.6-e548833-nfct/linux/net/netfilter/ipvs/ip_vs_conn.c 2010-09-15 11:14:13.000000000 +0300
+++ linux/net/netfilter/ipvs/ip_vs_conn.c 2010-09-26 15:24:48.292865793 +0300
@@ -611,6 +611,8 @@ static inline void ip_vs_unbind_dest(str
} else {
atomic_dec(&dest->activeconns);
}
+ if (cp->flags & IP_VS_CONN_F_BACKLOG)
+ atomic_dec(&dest->backlogconns);
} else {
/* It is a persistent connection/template, so decrease
the peristent connection counter */
diff -urp net-next-2.6-e548833-nfct/linux/net/netfilter/ipvs/ip_vs_ctl.c linux/net/netfilter/ipvs/ip_vs_ctl.c
--- net-next-2.6-e548833-nfct/linux/net/netfilter/ipvs/ip_vs_ctl.c 2010-09-16 08:56:34.000000000 +0300
+++ linux/net/netfilter/ipvs/ip_vs_ctl.c 2010-09-26 15:26:45.407867200 +0300
@@ -2593,6 +2593,7 @@ static const struct nla_policy ip_vs_des
[IPVS_DEST_ATTR_INACT_CONNS] = { .type = NLA_U32 },
[IPVS_DEST_ATTR_PERSIST_CONNS] = { .type = NLA_U32 },
[IPVS_DEST_ATTR_STATS] = { .type = NLA_NESTED },
+ [IPVS_DEST_ATTR_BACKLOG_CONNS] = { .type = NLA_U32 },
};
static int ip_vs_genl_fill_stats(struct sk_buff *skb, int container_type,
@@ -2840,6 +2841,8 @@ static int ip_vs_genl_fill_dest(struct s
atomic_read(&dest->activeconns));
NLA_PUT_U32(skb, IPVS_DEST_ATTR_INACT_CONNS,
atomic_read(&dest->inactconns));
+ NLA_PUT_U32(skb, IPVS_DEST_ATTR_BACKLOG_CONNS,
+ atomic_read(&dest->backlogconns));
NLA_PUT_U32(skb, IPVS_DEST_ATTR_PERSIST_CONNS,
atomic_read(&dest->persistconns));
diff -urp net-next-2.6-e548833-nfct/linux/net/netfilter/ipvs/ip_vs_proto_tcp.c linux/net/netfilter/ipvs/ip_vs_proto_tcp.c
--- net-next-2.6-e548833-nfct/linux/net/netfilter/ipvs/ip_vs_proto_tcp.c 2010-09-10 08:27:33.000000000 +0300
+++ linux/net/netfilter/ipvs/ip_vs_proto_tcp.c 2010-09-26 15:29:18.425865407 +0300
@@ -510,6 +510,15 @@ set_tcp_state(struct ip_vs_protocol *pp,
atomic_dec(&dest->inactconns);
cp->flags &= ~IP_VS_CONN_F_INACTIVE;
}
+ if (new_state == IP_VS_TCP_S_SYN_RECV &&
+ !(cp->flags & IP_VS_CONN_F_BACKLOG)) {
+ atomic_inc(&dest->backlogconns);
+ cp->flags |= IP_VS_CONN_F_BACKLOG;
+ } else if (new_state == IP_VS_TCP_S_ESTABLISHED &&
+ cp->flags & IP_VS_CONN_F_BACKLOG) {
+ atomic_dec(&dest->backlogconns);
+ cp->flags &= ~IP_VS_CONN_F_BACKLOG;
+ }
}
}
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next-2.6] fib: use atomic_inc_not_zero() in fib_rules_lookup
From: Eric Dumazet @ 2010-09-27 14:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Paul E. McKenney
It seems we dont use appropriate refcount increment in an
rcu_read_lock() protected section.
fib_rule_get() might increment a null refcount and bad things could
happen.
While fib_nl_delrule() respects an rcu grace period before calling
fib_rule_put(), fib_rules_cleanup_ops() calls fib_rule_put() without a
grace period.
Note : after this patch, we might avoid the synchronize_rcu() call done
in fib_nl_delrule()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/fib_rules.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index 42e84e0..910eac3 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -225,9 +225,11 @@ jumped:
err = ops->action(rule, fl, flags, arg);
if (err != -EAGAIN) {
- fib_rule_get(rule);
- arg->rule = rule;
- goto out;
+ if (likely(atomic_inc_not_zero(&rule->refcnt))) {
+ arg->rule = rule;
+ goto out;
+ }
+ break;
}
}
^ permalink raw reply related
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Christoph Lameter @ 2010-09-27 15:37 UTC (permalink / raw)
To: Christian Riesch
Cc: Alan Cox, john stultz, Richard Cochran,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, David Miller,
Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <4C9BC7CE.8020400-U4+xqT1Vg0VeoWH0uzbU5w@public.gmane.org>
On Thu, 23 Sep 2010, Christian Riesch wrote:
> > > It implies clock tuning in userspace for a potential sub microsecond
> > > accurate clock. The clock accuracy will be limited by user space
> > > latencies and noise. You wont be able to discipline the system clock
> > > accurately.
> >
> > Noise matters, latency doesn't.
>
> Well put! That's why we need hardware support for PTP timestamping to reduce
> the noise, but get along well with the clock servo that is steering the PHC in
> user space.
Even if I buy into the catch phrase above: User space is subject to noise
that the in kernel code is not. If you do the tuning over long intervals
then it hopefully averages out but it still causes jitter effects that
affects the degree of accuracy (or sync) that you can reach. And the noise
varies with the load on the system.
^ permalink raw reply
* l2tpv3 support not yet in iproute2?
From: jpo234 @ 2010-09-27 15:22 UTC (permalink / raw)
To: netdev
Hello all,
some time ago James Chapman sent patches that add L2TPv3 support to iproute2:
http://kerneltrap.org/mailarchive/linux-netdev/2010/3/18/6272266/thread
While the kernel support arrived in 2.6.35 the user space configuration support
still seems to be missing:
iproute2-2.6.35$ find . -type f -iname "*.c" | xargs fgrep -i l2tp
doesn't find anything.
Can somebody clarify the current situation?
Thanks in advance
Joerg
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Christoph Lameter @ 2010-09-27 15:52 UTC (permalink / raw)
To: john stultz
Cc: Rodolfo Giometti, Peter Zijlstra,
linux-api-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, Thomas Gleixner,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Richard Cochran,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Krzysztof Halasa
In-Reply-To: <1285278136.2587.154.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Thu, 23 Sep 2010, john stultz wrote:
> > > 3) Further, the PTP hardware counter can be simply set to a new offset
> > > to put it in line with the network time. This could cause trouble with
> > > timekeeping much like unsynced TSCs do.
> >
> > You can do the same for system time.
>
> Settimeofday does allow CLOCK_REALTIME to jump, but the CLOCK_MONOTONIC
> time cannot jump around. Having a clocksource that is non-monotonic
> would break this.
Currently time runs at the same speed. CLOCK_MONOTONIC runs at a offset
to CLOCK_REALTIME. We are creating APIs here that allow time to run at
different speeds.
> The design actually avoids most userland induced latency.
>
> 1) On the PTP hardware syncing point, the reference packet gets
> timestamped with the PTP hardware time on arrival. This allows the
> offset calculation to be done in userland without introducing latency.
The timestamps allows the calculation of the network transmission time I
guess and therefore its more accurate to calculate that effect out. Ok but
then the overhead of getting to code in user space (that does the proper
clock adjustments) is resulting in the addition of a relatively long time
that is subject to OS scheduling latencies and noises.
> 2) On the system syncing side, the proposal for the PPS interrupt allows
> the PTP hardware to trigger an interrupt on the second boundary that
> would take a timestamp of the system time. Then the pps interface allows
> for the timestamp to be read from userland allowing the offset to be
> calculated without introducing additional latency.
Sorry dont really get the whole picture here it seems. Sounds like one is
going through additional unnecessary layers. Why would the PTP hardware
triggger an interrupt? I thought the PTP messages came in via
timestamping and are then processed by software. Then the software is
issuing a hardware interrupt that then triggers the PPS subsystem. And
that is supposed to be better than directly interfacing with the PTP?
> Additionally, even just in userland, it would be easy to bracket two
> reads of the system time around one read of the PTP clock to bound any
> userland latency fairly well. It may not be as good as the PPS interface
> (although that depends on the interrupt latency), but if the accesses
> are all local, it probably could get fairly close.
That sounds hacky.
> > Ok maybe we need some sort of control interface to manage the clock like
> > the others have.
>
> That's what the clock_adjtime call provides.
Ummm... You are managing a hardware device with hardware (driver) specific
settings. That is currently being done via ioctls. Why generalize it?
> > The posix clocks today assumes one notion of real "time" in the kernel.
> > All clocks increase in lockstep (aside from offset updates).
>
> Not true. The cputime clockids do not increment at the same rate (as the
> apps don't always run). Further CLOCK_MONOTONIC_RAW provides a non-freq
> corrected view of CLOCK_MONOTONIC, so it increments at a slightly
> different rate.
cputime clockids are not tracking time but cpu resource use.
> Re-using the fairly nice (Alan of course disagrees :) posix interface
> seems at least a little better for application developers who actually
> have to use the hardware.
Well it may also be confusing for others. The application developers also
will have a hard time using a generic clock interface to control PTP
device specific things like frequencies, rates etc etc. So you always need
to ioctl/device specific control interface regardless.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: Ohad Ben-Cohen @ 2010-09-27 15:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, John W. Linville
In-Reply-To: <20100927154408.55a28127.sfr@canb.auug.org.au>
On Mon, Sep 27, 2010 at 7:44 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Assembler messages:
> Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
>
> Presumably caused by commit 61ee7007a5d61aa066076da578e8e8084e122d7d
> ("wl12xx: add platform data passing support").
>
> I do my builds with a separate object directory (which may be a reason
> you don't see this).
Thank you, Stephen.
I have just tried building with a separate object directory, and I was
then able to reproduce it and fix it with:
From fb0d1dc5ce6c258b3ecb0a8997791a77be3c5307 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen <ohad@wizery.com>
Date: Mon, 27 Sep 2010 17:33:57 +0200
Subject: [PATCH] wl12xx: fix separate-object-folder builds
Make this go away (happens when building with a separate object directory):
Assembler messages:
Fatal error: can't create
drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file
or directory
drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function
'wl12xx_get_platform_data':
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot
open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by
earlier errors, bailing out
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/net/wireless/Makefile | 2 +-
.../wireless/{wl12xx => }/wl12xx_platform_data.c | 0
2 files changed, 1 insertions(+), 1 deletions(-)
rename drivers/net/wireless/{wl12xx => }/wl12xx_platform_data.c (100%)
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 85af697..0a64bd5 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -51,6 +51,6 @@ obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
obj-$(CONFIG_WL12XX) += wl12xx/
# small builtin driver bit
-obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
+obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx_platform_data.o
obj-$(CONFIG_IWM) += iwmc3200wifi/
diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
b/drivers/net/wireless/wl12xx_platform_data.c
similarity index 100%
rename from drivers/net/wireless/wl12xx/wl12xx_platform_data.c
rename to drivers/net/wireless/wl12xx_platform_data.c
--
1.7.0.4
>
> I have reverted that commit for today (and commits
> 09cecc340b3b4d9960b039c0f576548bbf857f5a ("wl1271: take irq info from
> private board data") and 15cea99306ae14ce5f7c3d3989bcc17202e2b0be
> ("wl1271: make ref_clock configurable by board") which follow it).
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
^ permalink raw reply related
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Christoph Lameter @ 2010-09-27 15:56 UTC (permalink / raw)
To: Alan Cox
Cc: Richard Cochran, linux-kernel, devicetree-discuss, linux-api,
linux-arm-kernel, linuxppc-dev, netdev, Arnd Bergmann,
David Miller, John Stultz, Krzysztof Halasa, Peter Zijlstra,
Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <20100924150246.0e6064b6@lxorguk.ukuu.org.uk>
On Fri, 24 Sep 2010, Alan Cox wrote:
> Whether you add new syscalls or do the fd passing using flags and hide
> the ugly bits in glibc is another question.
Use device specific ioctls instead of syscalls?
^ permalink raw reply
* [PATCH net-next-2.6] net: sk_attach_filter() rcu fix
From: Eric Dumazet @ 2010-09-27 15:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Paul E. McKenney
sk_attach_filter() is run with socket locked.
Use the appropriate rcu_dereference_protected() instead of blocking BH,
and rcu_dereference_bh().
There is no point adding BH prevention and memory barrier.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/filter.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 52b051f..93ac5d2 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -638,10 +638,9 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
return err;
}
- rcu_read_lock_bh();
- old_fp = rcu_dereference_bh(sk->sk_filter);
+ old_fp = rcu_dereference_protected(sk->sk_filter,
+ sock_owned_by_user(sk));
rcu_assign_pointer(sk->sk_filter, fp);
- rcu_read_unlock_bh();
if (old_fp)
sk_filter_delayed_uncharge(sk, old_fp);
^ permalink raw reply related
* [PATCH net-next-2.6 v2] net: sk_{detach|attach}_filter() rcu fixes
From: Eric Dumazet @ 2010-09-27 16:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Paul E. McKenney
In-Reply-To: <1285603064.3017.42.camel@edumazet-laptop>
Le lundi 27 septembre 2010 à 17:57 +0200, Eric Dumazet a écrit :
> sk_attach_filter() is run with socket locked.
>
> Use the appropriate rcu_dereference_protected() instead of blocking BH,
> and rcu_dereference_bh().
> There is no point adding BH prevention and memory barrier.
Hmm, same thing can be done in sk_detach_filter, here is a v2.
Thanks
[PATCH net-next-2.6 v2] net: sk_{detach|attach}_filter() rcu fixes
sk_attach_filter() and sk_detach_filter() are run with socket locked.
Use the appropriate rcu_dereference_protected() instead of blocking BH,
and rcu_dereference_bh().
There is no point adding BH prevention and memory barrier.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/filter.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 52b051f..7adf503 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -638,10 +638,9 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
return err;
}
- rcu_read_lock_bh();
- old_fp = rcu_dereference_bh(sk->sk_filter);
+ old_fp = rcu_dereference_protected(sk->sk_filter,
+ sock_owned_by_user(sk));
rcu_assign_pointer(sk->sk_filter, fp);
- rcu_read_unlock_bh();
if (old_fp)
sk_filter_delayed_uncharge(sk, old_fp);
@@ -654,14 +653,13 @@ int sk_detach_filter(struct sock *sk)
int ret = -ENOENT;
struct sk_filter *filter;
- rcu_read_lock_bh();
- filter = rcu_dereference_bh(sk->sk_filter);
+ filter = rcu_dereference_protected(sk->sk_filter,
+ sock_owned_by_user(sk));
if (filter) {
rcu_assign_pointer(sk->sk_filter, NULL);
sk_filter_delayed_uncharge(sk, filter);
ret = 0;
}
- rcu_read_unlock_bh();
return ret;
}
EXPORT_SYMBOL_GPL(sk_detach_filter);
^ permalink raw reply related
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: M. Warner Losh @ 2010-09-27 16:14 UTC (permalink / raw)
To: cl
Cc: johnstul, giometti, peterz, linux-api, devicetree-discuss,
linux-kernel, davem, netdev, tglx, linuxppc-dev, richardcochran,
linux-arm-kernel, khc
In-Reply-To: <alpine.DEB.2.00.1009271038150.9258@router.home>
In message: <alpine.DEB.2.00.1009271038150.9258@router.home>
Christoph Lameter <cl@linux.com> writes:
: On Thu, 23 Sep 2010, john stultz wrote:
: > The design actually avoids most userland induced latency.
: >
: > 1) On the PTP hardware syncing point, the reference packet gets
: > timestamped with the PTP hardware time on arrival. This allows the
: > offset calculation to be done in userland without introducing latency.
:
: The timestamps allows the calculation of the network transmission time I
: guess and therefore its more accurate to calculate that effect out. Ok but
: then the overhead of getting to code in user space (that does the proper
: clock adjustments) is resulting in the addition of a relatively long time
: that is subject to OS scheduling latencies and noises.
The timestamps at the hardware level allow you to factor out variation
caused by OS Scheduling, OS network stack delay and internal buffering
on the NIC. Variation in measurements is what kills accuracy.
When steering a clock by making an error measurement of the phase and
frequency of it, the latency induced by OS scheduling tends to be
unimportant. It is far more important to know when you steered the
clock (called adjtime or friends) than to steer it at any fixed
latency to when the data for the measurements was made. Measuring the
time of steer can tolerate errors in the range of OS scheduling
latencies easily, since that tends to produce a very small effect. It
introduces an error in your expected phase for the next measurement on
the order of the product of the time of steer error times the change
in fractional frequency (abs( 1 - (nu_new / nu_old))). Even if the
estimate is really bad at 100ms, most steers are on the order about
one part per million. This leads to a sub-nanosecond phase error
estimate in the next measurement cycle (a non-accumulating error). A
1ms error leads to maybe tens of picoseconds of estimate error.
This is a common error that I've seen repeated in this thread. The
only reason that it has historically been important is because when
you are doing timestamping in software based on an interrupt, that
stuff does matter.
Warner
^ permalink raw reply
* Re: l2tpv3 support not yet in iproute2?
From: Eric Dumazet @ 2010-09-27 16:23 UTC (permalink / raw)
To: jpo234; +Cc: netdev, James Chapman
In-Reply-To: <loom.20100927T170521-559@post.gmane.org>
Le lundi 27 septembre 2010 à 15:22 +0000, jpo234 a écrit :
> Hello all,
> some time ago James Chapman sent patches that add L2TPv3 support to iproute2:
> http://kerneltrap.org/mailarchive/linux-netdev/2010/3/18/6272266/thread
> While the kernel support arrived in 2.6.35 the user space configuration support
> still seems to be missing:
> iproute2-2.6.35$ find . -type f -iname "*.c" | xargs fgrep -i l2tp
> doesn't find anything.
>
> Can somebody clarify the current situation?
Hmm, this reminds me l2tp locking is buggy and not yet fixed.
http://kerneltrap.org/mailarchive/linux-netdev/2010/4/20/6275106
James, any chance you could fix the locking ?
^ permalink raw reply
* Re: [PATCH RFC] netns: keep vlan slaves on master netns move
From: Eric W. Biederman @ 2010-09-27 16:23 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, netdev, Daniel Lezcano, David Lamparter
In-Reply-To: <4C9363CB.7050302@trash.net>
Patrick McHardy <kaber@trash.net> writes:
> Am 15.09.2010 04:10, schrieb Eric W. Biederman:
>>
>> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> My inclination is that the best way to handle this is to would be to
>> push the device deletion for vlan and macvlan devices into the device
>> core, where we could get the advantage of batched deletions.
>
> We've added batched deletion to both about a year ago, what exactly
> is the problem?
My problem is that while the both have dellink implemented we
don't really batch their deletes as best we can.
For macvlan when the underlying device is unregistered we delete
each macvlan device one by one.
For vlans we do batch the deletes, but not in the same batch as
the underlying device.
>> Right
>> now vlan and macvlan devices are the only devices I know of that cause
>> other devices to be removed during unregister, so removing that
>> specialness seems reasonable.
>
> Actually all devices can cause this when used as a lower device by
> vlan or macvlan. Both vlan and macvlan are useless without a lower
> device, so I don't see why we shouldn't remove them when the lower
> device is unregistered.
I definitely think we should remove the devices when the lower device
is destroyed/removed. However unregistered is a slightly different
concept, and arguably macvlan and vlan devices are much more intimately
connected to their underlying device than that.
What I meant is we should implement the deletion differently. By doing
something like having a list of all derived devices for a device, that
we could walk and call dellink on from rollback_registered_many. In
theory that could destroy a whole pile of macvlan and vlan devices with
various different stackings one on the other all in the same batch.
Eric
^ permalink raw reply
* net-next rcu_dereference_check() warning
From: Dimitris Michailidis @ 2010-09-27 16:30 UTC (permalink / raw)
To: netdev
With today's net-next I am getting the below. It appears to be recent, it
wasn't happening with the net-next I was using last week.
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
/build/net-next-2.6/include/linux/netpoll.h:67 invoked
rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by ypbind/5046:
#0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff81503139>]
udp_sendmsg+0x3fd/0x5dc
stack backtrace:
Pid: 5046, comm: ypbind Not tainted 2.6.36-rc3+ #16
Call Trace:
[<ffffffff810668e4>] lockdep_rcu_dereference+0xaa/0xb3
[<ffffffff814b8d09>] netif_rx+0x53/0x1cf
[<ffffffff810313b7>] ? get_parent_ip+0x11/0x41
[<ffffffff814b9068>] netif_rx_ni+0x23/0x5d
[<ffffffff814e57a9>] ip_dev_loopback_xmit+0xc5/0xcb
[<ffffffff814e593c>] ip_mc_output+0x18d/0x1a5
[<ffffffff814e30ec>] ip_local_out+0x62/0x66
[<ffffffff814e33cb>] ip_push_pending_frames+0x2db/0x337
[<ffffffff81501b55>] udp_push_pending_frames+0x2de/0x34c
[<ffffffff81503139>] ? udp_sendmsg+0x3fd/0x5dc
[<ffffffff8150322a>] udp_sendmsg+0x4ee/0x5dc
[<ffffffff8150aa74>] inet_sendmsg+0x13a/0x145
[<ffffffff8150a93a>] ? inet_sendmsg+0x0/0x145
[<ffffffff814a6d24>] sock_sendmsg+0xc0/0xd9
[<ffffffff8106aad4>] ? lock_release_non_nested+0xe5/0x296
[<ffffffff810c8fb0>] ? might_fault+0x68/0xb8
[<ffffffff810c8fb0>] ? might_fault+0x68/0xb8
[<ffffffff810c8ff9>] ? might_fault+0xb1/0xb8
[<ffffffff810c8fb0>] ? might_fault+0x68/0xb8
[<ffffffff814a6672>] ? move_addr_to_kernel+0x3f/0x56
[<ffffffff814a7458>] sys_sendto+0xe0/0x108
[<ffffffff810f9a76>] ? d_kill+0x6c/0x74
[<ffffffff810e99df>] ? fput+0x1ce/0x1dd
[<ffffffff81002c9b>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: net-next rcu_dereference_check() warning
From: Eric Dumazet @ 2010-09-27 16:45 UTC (permalink / raw)
To: Dimitris Michailidis; +Cc: netdev
In-Reply-To: <4CA0C691.1090001@chelsio.com>
Le lundi 27 septembre 2010 à 09:30 -0700, Dimitris Michailidis a écrit :
> With today's net-next I am getting the below. It appears to be recent, it
> wasn't happening with the net-next I was using last week.
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> /build/net-next-2.6/include/linux/netpoll.h:67 invoked
> rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 0
> 1 lock held by ypbind/5046:
> #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff81503139>]
> udp_sendmsg+0x3fd/0x5dc
>
> stack backtrace:
> Pid: 5046, comm: ypbind Not tainted 2.6.36-rc3+ #16
> Call Trace:
> [<ffffffff810668e4>] lockdep_rcu_dereference+0xaa/0xb3
> [<ffffffff814b8d09>] netif_rx+0x53/0x1cf
> [<ffffffff810313b7>] ? get_parent_ip+0x11/0x41
> [<ffffffff814b9068>] netif_rx_ni+0x23/0x5d
> [<ffffffff814e57a9>] ip_dev_loopback_xmit+0xc5/0xcb
> [<ffffffff814e593c>] ip_mc_output+0x18d/0x1a5
> [<ffffffff814e30ec>] ip_local_out+0x62/0x66
> [<ffffffff814e33cb>] ip_push_pending_frames+0x2db/0x337
> [<ffffffff81501b55>] udp_push_pending_frames+0x2de/0x34c
> [<ffffffff81503139>] ? udp_sendmsg+0x3fd/0x5dc
> [<ffffffff8150322a>] udp_sendmsg+0x4ee/0x5dc
> [<ffffffff8150aa74>] inet_sendmsg+0x13a/0x145
> [<ffffffff8150a93a>] ? inet_sendmsg+0x0/0x145
> [<ffffffff814a6d24>] sock_sendmsg+0xc0/0xd9
> [<ffffffff8106aad4>] ? lock_release_non_nested+0xe5/0x296
> [<ffffffff810c8fb0>] ? might_fault+0x68/0xb8
> [<ffffffff810c8fb0>] ? might_fault+0x68/0xb8
> [<ffffffff810c8ff9>] ? might_fault+0xb1/0xb8
> [<ffffffff810c8fb0>] ? might_fault+0x68/0xb8
> [<ffffffff814a6672>] ? move_addr_to_kernel+0x3f/0x56
> [<ffffffff814a7458>] sys_sendto+0xe0/0x108
> [<ffffffff810f9a76>] ? d_kill+0x6c/0x74
> [<ffffffff810e99df>] ? fput+0x1ce/0x1dd
> [<ffffffff81002c9b>] system_call_fastpath+0x16/0x1b
Hi Dimitris
Fix is known and under its way.
http://kerneltrap.org/mailarchive/linux-kernel/2010/9/23/4623037
Thanks !
^ permalink raw reply
* [PATCH linux-2.6 v2] IPv6: Create temporary address if none exists.
From: Glenn Wurster @ 2010-09-27 17:04 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI <yosh
Cc: netdev, linux-kernel
If privacy extentions are enabled, but no current temporary address exists,
then create one when we get a router advertisement.
Version 2, now with 100% fewer line wraps. Thanks to David Miller for
pointing out the line wrapping issue.
Signed-off-by: Glenn Wurster <gwurster@scs.carleton.ca>
---
net/ipv6/addrconf.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index ab70a3f..cfee6ae 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2022,10 +2022,11 @@ ok:
ipv6_ifa_notify(0, ift);
}
- if (create && in6_dev->cnf.use_tempaddr > 0) {
+ if ((create || list_empty(&in6_dev->tempaddr_list)) && in6_dev->cnf.use_tempaddr > 0) {
/*
* When a new public address is created as described in [ADDRCONF],
- * also create a new temporary address.
+ * also create a new temporary address. Also create a temporary
+ * address if it's enabled but no temporary address currently exists.
*/
read_unlock_bh(&in6_dev->lock);
ipv6_create_tempaddr(ifp, NULL);
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Alan Cox @ 2010-09-27 17:05 UTC (permalink / raw)
To: Christoph Lameter
Cc: John Stultz, Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra,
linux-api, devicetree-discuss, linux-kernel, David Miller, netdev,
Thomas Gleixner, linuxppc-dev, Richard Cochran, linux-arm-kernel,
Krzysztof Halasa
In-Reply-To: <alpine.DEB.2.00.1009271054320.9258@router.home>
On Mon, 27 Sep 2010 10:56:09 -0500 (CDT)
Christoph Lameter <cl@linux.com> wrote:
>
> On Fri, 24 Sep 2010, Alan Cox wrote:
>
> > Whether you add new syscalls or do the fd passing using flags and hide
> > the ugly bits in glibc is another question.
>
> Use device specific ioctls instead of syscalls?
Some of the ioctls are probably not device specific, the job of the OS in
part is to present a unified interface. We already have a mess of HPET
and RTC driver ioctls.
Some of it undoubtedly is device specific.
Alan
^ permalink raw reply
* [PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.
From: Glenn Wurster @ 2010-09-27 17:10 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI <yosh
Cc: netdev, linux-kernel
There is a bug in the interaction between ipv6_create_tempaddr and
addrconf_verify. Because ipv6_create_tempaddr uses the cstamp and tstamp
from the public address in creating a private address, if we have not
received a router advertisement in a while, tstamp + temp_valid_lft might be
< now. If this happens, the new address is created inside
ipv6_create_tempaddr, then the loop within addrconf_verify starts again and
the address is immediately deleted. We are left with no temporary addresses
on the interface, and no more will be created until the public IP address is
updated. To avoid this, set the expiry time to be the minimum of the time
left on the public address or the config option PLUS the current age of the
public interface.
Version 2, now with 100% fewer line wraps. Thanks to David Miller for
pointing out the line wrapping issue.
Signed-off-by: Glenn Wurster <gwurster@scs.carleton.ca>
---
net/ipv6/addrconf.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cfee6ae..9c74454 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -836,7 +836,7 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *i
{
struct inet6_dev *idev = ifp->idev;
struct in6_addr addr, *tmpaddr;
- unsigned long tmp_prefered_lft, tmp_valid_lft, tmp_cstamp, tmp_tstamp;
+ unsigned long tmp_prefered_lft, tmp_valid_lft, tmp_cstamp, tmp_tstamp, age;
unsigned long regen_advance;
int tmp_plen;
int ret = 0;
@@ -886,12 +886,13 @@ retry:
goto out;
}
memcpy(&addr.s6_addr[8], idev->rndid, 8);
+ age = (jiffies - ifp->tstamp) / HZ;
tmp_valid_lft = min_t(__u32,
ifp->valid_lft,
- idev->cnf.temp_valid_lft);
+ idev->cnf.temp_valid_lft + age);
tmp_prefered_lft = min_t(__u32,
ifp->prefered_lft,
- idev->cnf.temp_prefered_lft -
+ idev->cnf.temp_prefered_lft + age -
idev->cnf.max_desync_factor);
tmp_plen = ifp->prefix_len;
max_addresses = idev->cnf.max_addresses;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v3] xmit_compl_seq: information to reclaim vmsplice buffers
From: Michael S. Tsirkin @ 2010-09-27 17:23 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, davem, sridharr
In-Reply-To: <alpine.DEB.1.00.1009231426450.11579@pokey.mtv.corp.google.com>
On Thu, Sep 23, 2010 at 02:35:16PM -0700, Tom Herbert wrote:
> In this patch we propose to adds some socket API to retrieve the
> "transmit completion sequence number", essentially a byte counter
> for the number of bytes that have been transmitted and will not be
> retransmitted. In the case of TCP, this should correspond to snd_una.
>
> The purpose of this API is to provide information to userspace about
> which buffers can be reclaimed when sending with vmsplice() on a
> socket.
>
> There are two methods for retrieving the completed sequence number:
> through a simple getsockopt (implemented here for TCP), as well as
> returning the value in the ancilary data of a recvmsg.
>
> The expected flow would be something like:
> - Connect is created
> - Initial completion seq # is retrieved through the sockopt, and is
> stored in userspace "compl_seq" variable for the connection.
> - Whenever a send is done, compl_seq += # bytes sent.
> - When doing a vmsplice the completion sequence number is saved
> for each user space buffer, buffer_compl_seq = compl_seq.
> - When recvmsg returns with a completion sequence number in
> ancillary data, any buffers cover by that sequence number
> (where buffer_compl_seq < recvmsg_compl_seq) are reclaimed
> and can be written to again.
> - If no data is receieved on a connection (recvmsg does not
> return), a timeout can be used to call the getsockopt and
> reclaim buffers as a fallback.
>
> Using recvmsg data in this manner is sort of a cheap way to get a
> "callback" for when a vmspliced buffer is consumed. It will work
> well for a client where the response causes recvmsg to return.
> On the server side it works well if there are a sufficient
> number of requests coming on the connection (resorting to the
> timeout if necessary as described above).
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> Signed-off-by: Sridhar Raman <sridharr@google.com>
Can not packets referencing this memory
still be outstanding at the NIC device, if retransmit happens
before the ack but after the packet was passed to a device?
It's true that the reftransmit will likely get discarded
by the remote end, but this might be a security issue
if an application puts sensitive data in the buffer
and that gets inadvertently sent on the wire, can it not?
--
MST
^ permalink raw reply
* Re: l2tpv3 support not yet in iproute2?
From: James Chapman @ 2010-09-27 17:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: jpo234, netdev, Stephen Hemminger
In-Reply-To: <1285604596.3017.80.camel@edumazet-laptop>
On 27/09/2010 17:23, Eric Dumazet wrote:
> Le lundi 27 septembre 2010 à 15:22 +0000, jpo234 a écrit :
>> Hello all,
>> some time ago James Chapman sent patches that add L2TPv3 support to iproute2:
>> http://kerneltrap.org/mailarchive/linux-netdev/2010/3/18/6272266/thread
>> While the kernel support arrived in 2.6.35 the user space configuration support
>> still seems to be missing:
>> iproute2-2.6.35$ find . -type f -iname "*.c" | xargs fgrep -i l2tp
>> doesn't find anything.
>>
>> Can somebody clarify the current situation?
Stephen Hemminger (maintainer of iproute2) rejected the patches because
they would add a dependency of libnl to iproute2. iproute2 uses
libnetlink, not libnl. Stephen's objections are reasonable.
The l2tpv3 API uses generic-netlink (genl) which is handled by libnl
APIs very well (and is the main reason why libnl was chosen in the first
place). To recode using libnetlink would require working with low level
libnetlink helpers to build/parse genl messages at low level,
effectively reimplementing some of what is already handled by libnl. I
don't have motivation or time to do this, though I'm happy to support
someone else doing so.
As a quick solution, I posted a new utility, l2tpv3tun, which does the
same as the iproute2 l2tpv3 patches in a standalone utility. l2tpv3tun
is at ftp://ftp.openl2tp.org/releases/l2tpv3tun-0.1.tar.gz
> Hmm, this reminds me l2tp locking is buggy and not yet fixed.
>
> http://kerneltrap.org/mailarchive/linux-netdev/2010/4/20/6275106
>
> James, any chance you could fix the locking ?
This dropped off my radar. I'm too busy right now but I'll look at it as
soon as I can, unless someone else beats me to it.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: igmp: Allow mininum interval specification for igmp timers.
From: David Stevens @ 2010-09-27 17:41 UTC (permalink / raw)
To: David Miller
Cc: cl-vYTEC60ixJUAvxtiuMwx3w, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, rda-x0S3BwdUo6DQT0dZR+AlfA
In-Reply-To: <20100923.213823.137834706.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote on 09/23/2010 09:38:23 PM:
>
> > IGMP timers sometimes fire too rapidly due to randomization of the
> > intervalsfrom 0 to max_delay in igmp_start_timer().
> ...
> > Signed-off-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
>
>
> This change seems reasonable to me, what do you think David?
[sorry for the delay -- I was off-line for the last few days]
Dave,
I don't know if you saw the more extended discussion we
had on this or not, but I think while this would help for IB,
it's not appropriate in general. These can in fact be "0" per
RFC which is worst case for IB if there is a delay for being
able to use the group, and the newer IGMPv3 standard has shortened
the max interval from 10sec in v2 to 1 sec.
Fundamentally, the problem is that the device needs to
be able to send on the group immediately for IGMP; that it
can't for IB is the problem, and I think it should be solved
in IB by either queueing packets there or delaying there as
needed before doing the joins.
I don't think tweaking IGMP for this is appropriate at
all, but if done there, it ought to be per-interface so it
doesn't change anything for other network types which don't
have this problem. It should be randomized and not the fixed
delays to prevent storms on a mass start-up, and we also don't
want to be increasing the number of duplicates for other
network types. The default should be 2 reports in randomized
0-10 sec for each for v2, 2 in randomized 0-1 sec for v3.
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: igmp: Allow mininum interval specification for igmp timers.
From: David Miller @ 2010-09-27 17:54 UTC (permalink / raw)
To: dlstevens-r/Jw6+rmf7HQT0dZR+AlfA
Cc: cl-vYTEC60ixJUAvxtiuMwx3w, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, rda-x0S3BwdUo6DQT0dZR+AlfA
In-Reply-To: <OF4BA8F9C2.467056E9-ON882577AB.005F4832-882577AB.00612DD6-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
From: David Stevens <dlstevens-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Date: Mon, 27 Sep 2010 10:41:20 -0700
> I don't know if you saw the more extended discussion we
> had on this or not, but I think while this would help for IB,
> it's not appropriate in general. These can in fact be "0" per
> RFC which is worst case for IB if there is a delay for being
> able to use the group, and the newer IGMPv3 standard has shortened
> the max interval from 10sec in v2 to 1 sec.
I did see the extended discussion, and it was interesting :-)
But that mainly focused on the second patch, which I appropriately
marked as needing changes in patchwork.
This patch on the other hand is attacking a different problem,
namely avoiding the worst cases caused by the randomization we
do for the timer.
With bad luck this thing times out way too fast because the total of
all of the randomized intervals can end up being very small, and I
think we should fix that independently of the other issues hit by the
IB folks.
Don't you agree?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: linux-next: build failure after merge of the final tree (net tree related)
From: John W. Linville @ 2010-09-27 18:04 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Stephen Rothwell, David Miller, netdev, linux-next, linux-kernel
In-Reply-To: <AANLkTinHk82jM7Ztwb1aB1xb-hSLeg5Hb07mhYCaeszi@mail.gmail.com>
On Mon, Sep 27, 2010 at 05:55:42PM +0200, Ohad Ben-Cohen wrote:
> On Mon, Sep 27, 2010 at 7:44 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Assembler messages:
> > Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
> >
> > Presumably caused by commit 61ee7007a5d61aa066076da578e8e8084e122d7d
> > ("wl12xx: add platform data passing support").
> >
> > I do my builds with a separate object directory (which may be a reason
> > you don't see this).
>
> Thank you, Stephen.
>
> I have just tried building with a separate object directory, and I was
> then able to reproduce it and fix it with:
>
> From fb0d1dc5ce6c258b3ecb0a8997791a77be3c5307 Mon Sep 17 00:00:00 2001
> From: Ohad Ben-Cohen <ohad@wizery.com>
> Date: Mon, 27 Sep 2010 17:33:57 +0200
> Subject: [PATCH] wl12xx: fix separate-object-folder builds
>
> Make this go away (happens when building with a separate object directory):
>
> Assembler messages:
> Fatal error: can't create
> drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file
> or directory
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function
> 'wl12xx_get_platform_data':
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot
> open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by
> earlier errors, bailing out
>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
> drivers/net/wireless/Makefile | 2 +-
> .../wireless/{wl12xx => }/wl12xx_platform_data.c | 0
> 2 files changed, 1 insertions(+), 1 deletions(-)
> rename drivers/net/wireless/{wl12xx => }/wl12xx_platform_data.c (100%)
>
> diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
> index 85af697..0a64bd5 100644
> --- a/drivers/net/wireless/Makefile
> +++ b/drivers/net/wireless/Makefile
> @@ -51,6 +51,6 @@ obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
>
> obj-$(CONFIG_WL12XX) += wl12xx/
> # small builtin driver bit
> -obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
> +obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx_platform_data.o
>
> obj-$(CONFIG_IWM) += iwmc3200wifi/
> diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
> b/drivers/net/wireless/wl12xx_platform_data.c
> similarity index 100%
> rename from drivers/net/wireless/wl12xx/wl12xx_platform_data.c
> rename to drivers/net/wireless/wl12xx_platform_data.c
I like this version better, since it keeps the platform data with
the rest of the code:
>From f8ac84505927d0a1fd79994cefaad7abf9b2e693 Mon Sep 17 00:00:00 2001
From: John W. Linville <linville@tuxdriver.com>
Date: Mon, 27 Sep 2010 14:00:51 -0400
Subject: [PATCH] wl12xx: fix separate-object-folder builds
Make this go away (happens when building with a separate object
directory):
Assembler messages:
Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/net/wireless/Makefile | 2 --
drivers/net/wireless/wl12xx/Makefile | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 85af697..5d4ce4d 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -50,7 +50,5 @@ obj-$(CONFIG_ATH_COMMON) += ath/
obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
obj-$(CONFIG_WL12XX) += wl12xx/
-# small builtin driver bit
-obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
obj-$(CONFIG_IWM) += iwmc3200wifi/
diff --git a/drivers/net/wireless/wl12xx/Makefile b/drivers/net/wireless/wl12xx/Makefile
index 078b439..0d334d6 100644
--- a/drivers/net/wireless/wl12xx/Makefile
+++ b/drivers/net/wireless/wl12xx/Makefile
@@ -16,3 +16,6 @@ wl1271-$(CONFIG_NL80211_TESTMODE) += wl1271_testmode.o
obj-$(CONFIG_WL1271) += wl1271.o
obj-$(CONFIG_WL1271_SPI) += wl1271_spi.o
obj-$(CONFIG_WL1271_SDIO) += wl1271_sdio.o
+
+# small builtin driver bit
+obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx_platform_data.o
--
1.7.2.3
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH] 3c59x: fix regression from patch "Add ethtool WOL support"
From: David Miller @ 2010-09-27 18:08 UTC (permalink / raw)
To: JBeulich; +Cc: andrew, netdev
In-Reply-To: <4CA09E2D0200007800019050@vpn.id2.novell.com>
From: "Jan Beulich" <JBeulich@novell.com>
Date: Mon, 27 Sep 2010 12:37:49 +0100
> This patch (commit 690a1f2002a3091bd18a501f46c9530f10481463) added a
> new call site for acpi_set_WOL() without checking that the function is
> actually suitable to be called via
>
> vortex_set_wol+0xcd/0xe0 [3c59x]
> dev_ethtool+0xa5a/0xb70
> dev_ioctl+0x2e0/0x4b0
> T.961+0x49/0x50
> sock_ioctl+0x47/0x290
> do_vfs_ioctl+0x7f/0x340
> sys_ioctl+0x80/0xa0
> system_call_fastpath+0x16/0x1b
>
> i.e. outside of code paths run when the device is not yet enabled or
> already disabled. In particular, putting the device into D3hot is a
> pretty bad idea when it was already brought up.
>
> Furthermore, all prior callers of the function made sure they're
> actually dealing with a PCI device, while the newly added one didn't.
>
> In the same spirit, the .get_wol handler shouldn't indicate support
> for WOL for non-PCI devices.
>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] fix TSO FACK loss marking in tcp_mark_head_lost
From: David Miller @ 2010-09-27 18:11 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: ycheng, netdev
In-Reply-To: <alpine.DEB.2.00.1009271520560.26447@wel-95.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 27 Sep 2010 15:22:09 +0300 (EEST)
> On Fri, 24 Sep 2010, Yuchung Cheng wrote:
>
>> When TCP uses FACK algorithm to mark lost packets in
>> tcp_mark_head_lost(), if the number of packets in the (TSO) skb is
>> greater than the number of packets that should be marked lost, TCP
>> incorrectly exits the loop and marks no packets lost in the skb. This
>> underestimates tp->lost_out and affects the recovery/retransmission.
>> This patch fargments the skb and marks the correct amount of packets
>> lost.
>>
>> Signed-off-by: Yuchung Cheng <ycheng@google.com>
>> ---
>> net/ipv4/tcp_input.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 1bc87a0..e4f472e 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -2532,7 +2532,8 @@ static void tcp_mark_head_lost(struct sock *sk, int packets)
>> cnt += tcp_skb_pcount(skb);
>>
>> if (cnt > packets) {
>> - if (tcp_is_sack(tp) || (oldcnt >= packets))
>> + if ((tcp_is_sack(tp) && !tcp_is_fack(tp)) ||
>> + (oldcnt >= packets))
>> break;
>>
>> mss = skb_shinfo(skb)->gso_size;
>>
>
> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
BTW, the history is that this code was added to fix a bug because
we didn't handle GSO packets at all at one point.
But, conservatively, we didn't do splits here for SACK, and it was
stated in the commit that we would look into it "at some point in the
future" :-)
--------------------
commit c137f3dda04b0aee1bc6889cdc69185f53df8a82
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Date: Mon Apr 7 22:32:38 2008 -0700
[TCP]: Fix NewReno's fast rexmit/recovery problems with GSOed skb
Fixes a long-standing bug which makes NewReno recovery crippled.
With GSO the whole head skb was marked as LOST which is in
violation of NewReno procedure that only wants to mark one packet
and ended up breaking our TCP code by causing counter overflow
because our code was built on top of assumption about valid
NewReno procedure. This manifested as triggering a WARN_ON for
the overflow in a number of places.
It seems relatively safe alternative to just do nothing if
tcp_fragment fails due to oom because another duplicate ACK is
likely to be received soon and the fragmentation will be retried.
Special thanks goes to Soeren Sonnenburg <kernel@nn7.de> who was
lucky enough to be able to reproduce this so that the warning
for the overflow was hit. It's not as easy task as it seems even
if this bug happens quite often because the amount of outstanding
data is pretty significant for the mismarkings to lead to an
overflow.
Because it's very late in 2.6.25-rc cycle (if this even makes in
time), I didn't want to touch anything with SACK enabled here.
Fragmenting might be useful for it as well but it's more or less
a policy decision rather than mandatory fix. Thus there's no need
to rush and we can postpone considering tcp_fragment with SACK
for 2.6.26.
In 2.6.24 and earlier, this very same bug existed but the effect
is slightly different because of a small changes in the if
conditions that fit to the patch's context. With them nothing
got lost marker and thus no retransmissions happened.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
--------------------
To be honest, we should probably just remove the whole tcp_is_sack()
test, rather than special case FACK.
The cost isn't what it was when this code was added. Back then we
didn't have Ilpo's restransmit queue coalescing code, so it would make
retransmit queue packet freeing more expensive. But since the
coalescing code is there now, splitting all the time to record
accurate loss information should be fine.
Ilpo what do you say?
^ permalink raw reply
* Re: [PATCH] net: Fix IPv6 PMTU disc. w/ asymmetric routes
From: David Miller @ 2010-09-27 18:11 UTC (permalink / raw)
To: maze; +Cc: netdev
In-Reply-To: <AANLkTikPOHy79E1ZG=iJ-rHj0vzS+AY-mGqCEtWoXp2o@mail.gmail.com>
From: Maciej Żenczykowski <maze@google.com>
Date: Mon, 27 Sep 2010 03:10:12 -0700
> FYI, I'm signed up to netdev on my personal account.
You don't need to subscribe in order to post patches to the mailing
list.
^ 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