* Re: [PATCH net-next] xfrm: fix RCU bugs
From: Fan Du @ 2012-08-20 6:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, fengguang.wu, Priyanka Jain
In-Reply-To: <1345440800.5158.239.camel@edumazet-glaptop>
On 2012年08月20日 13:33, Eric Dumazet wrote:
> On Mon, 2012-08-20 at 12:40 +0800, Fan Du wrote:
>> Hi Eric
>>
>> Please correct me if I'm wrong about below comments.
>>
>> On 2012年08月19日 18:31, Eric Dumazet wrote:
>>> From: Eric Dumazet<edumazet@google.com>
>>>
>>> This patch reverts commit 56892261ed1a (xfrm: Use rcu_dereference_bh to
>>> deference pointer protected by rcu_read_lock_bh), and fixes bugs
>>> introduced in commit 418a99ac6ad ( Replace rwlock on xfrm_policy_afinfo
>>> with rcu )
>>>
>>> 1) We properly use RCU variant in this file, not a mix of RCU/RCU_BH
>>>
>>> 2) We must defer some writes after the synchronize_rcu() call or a reader
>>> can crash dereferencing NULL pointer.
>>
>> Not exactly.
>>
>> net/ipv4/xfrm4_policy.c
>> static void __exit xfrm4_policy_fini(void)
>> -> xfrm_policy_unregister_afinfo
>>
>> IMHO, ip stack can never be compiled as module, so is xfrm4_policy_fini
>> freed up after system bootup? which means xfrm4_policy_fini can never be
>> called.
>>
>> so an dereferencing NULL pointer by a reader could not happen.
>>
>
> Last famous words.
>
> Anyway xfrm_policy_unregister_afinfo() is also called from
> xfrm6_policy_fini(), and IPv6 is a module. The day we can rmmod it,
> we uncover this bug.
>
> RCU is complex (most people dont get it right, thats the truth),
> and we should make it rock solid, or I can guarantee you
> many patch attempts from future readers of this code.
>
> You wont tell them :
>
> "OK but dont worry we never call this function for real, why do you care
> at all"
>
You are correct!
And one out of topic question:
The usage of xfrm_state_afinfo_lock/xfrm_km_lock is extremely
similar with xfrm_policy_afinfo_lock, except the former is not so
frequently read than that of the later.
Is it justified to convert RW xfrm_state_afinfo_lock/xfrm_km_lock into
RCU?
>>>
>>> 3) Now we use the xfrm_policy_afinfo_lock spinlock only from process
>>> context, we no longer need to block BH in xfrm_policy_register_afinfo()
>>> and xfrm_policy_unregister_afinfo()
>>>
>> I don't think it's related to what kinds of locks we are using.
>> we call xfrm_policy_register_afinfo in process context, but actually
>> what xfrm_policy_afinfo_lock protected can be used in soft irq context.
>> that's why xx_bh is used in:
>
> You did an RCU conversion and obviously have little idea of what
> happened there.
>
> This _bh stuff was needed because _before_ RCU, an rwlock was used.
>
> And since read_lock() was used from BH handler, _all_ write_lock() had
> to use the write_lock_bh() variant to avoid a possible deadlock.
>
> But after RCU, this no longer is needed, as an rcu_read_lock() cannot
> block a writer anymore in the lock/unlock section.
>
> In fact, xfrm_policy_afinfo_lock could be replaced by a mutex. So _bh()
> is absolutely not needed anymore.
>
I indeed misunderstood the code a bit.
Your explanation is crystal clear, thanks :)
>
>
--
Love each day!
--fan
^ permalink raw reply
* RE: [PATCH] caif: Do not dereference NULL in chnl_recv_cb()
From: Sjur BRENDELAND @ 2012-08-20 6:33 UTC (permalink / raw)
To: Jesper Juhl, linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org, David S. Miller, Daniel MARTENSSON
In-Reply-To: <alpine.LNX.2.00.1208172230570.15699@swampdragon.chaosbits.net>
> In net/caif/chnl_net.c::chnl_recv_cb() we call skb_header_pointer()
> which may return NULL, but we do not check for a NULL pointer before
> dereferencing it.
> This patch adds such a NULL check and properly free's allocated memory
> and return an error (-EINVAL) on failure - much better than crashing..
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Thank you for fixing this, the patch looks good to me.
Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
^ permalink raw reply
* Re: [PATCH] tc-tbf.8: Add parameter range to man page.
From: Li Wei @ 2012-08-20 6:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20120813083015.27b66cd7@nehalam.linuxnetplumber.net>
On 08/13/2012 11:30 PM, Stephen Hemminger wrote:
> On Tue, 7 Aug 2012 10:30:32 +0800
> Li Wei <lw@cn.fujitsu.com> wrote:
>
>> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
>> ---
>> man/man8/tc-tbf.8 | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/man/man8/tc-tbf.8 b/man/man8/tc-tbf.8
>> index 3abb238..7b76146 100644
>> --- a/man/man8/tc-tbf.8
>> +++ b/man/man8/tc-tbf.8
>> @@ -76,6 +76,7 @@ latency parameter, which specifies the maximum amount of time a packet can
>> sit in the TBF. The latter calculation takes into account the size of the
>> bucket, the rate and possibly the peakrate (if set). These two parameters
>> are mutually exclusive.
>> +The range of parameter limit is [1, UINT32_MAX] bytes.
>> .TP
>> burst
>> Also known as buffer or maxburst.
>> @@ -85,6 +86,7 @@ if you want to reach your configured rate!
>>
>> If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
>> The minimum buffer size can be calculated by dividing the rate by HZ.
>> +The range of this parameter is [1, UINT32_MAX] bytes.
>>
>> Token usage calculations are performed using a table which by default has a resolution of 8 packets.
>> This resolution can be changed by specifying the
>> @@ -96,11 +98,13 @@ this. Must be an integral power of 2.
>> mpu
>> A zero-sized packet does not use zero bandwidth. For ethernet, no packet uses less than 64 bytes. The Minimum Packet Unit
>> determines the minimal token usage (specified in bytes) for a packet. Defaults to zero.
>> +The range of this parameter is [0, UINT32_MAX] bytes.
>> .TP
>> rate
>> The speed knob. See remarks above about limits! See
>> .BR tc (8)
>> for units.
>> +The range of this parameter is [1, UINT32_MAX] bps.
>> .PP
>> Furthermore, if a peakrate is desired, the following parameters are available:
>>
>> @@ -108,12 +112,14 @@ Furthermore, if a peakrate is desired, the following parameters are available:
>> peakrate
>> Maximum depletion rate of the bucket. Limited to 1mbit/s on Intel, 10mbit/s on Alpha. The peakrate does
>> not need to be set, it is only necessary if perfect millisecond timescale shaping is required.
>> +The range of this parameter is [1, UINT32_MAX] bps.
>>
>> .TP
>> mtu/minburst
>> Specifies the size of the peakrate bucket. For perfect accuracy, should be set to the MTU of the interface.
>> If a peakrate is needed, but some burstiness is acceptable, this size can be raised. A 3000 byte minburst
>> allows around 3mbit/s of peakrate, given 1000 byte packets.
>> +The range of this parameter is [1, UINT32_MAX] bytes.
>>
>> Like the regular burstsize you can also specify a
>> .B cell
>
> Not sure about this, other qdisc don't document ranges on their man pages.
> Probably better to fix the generic documentation about qdisc parameters
> which already exists on 'tc-qdisc' man page.
Hi Stephen,
Not very clear with "the generic documentation about qdisc parameters
which already exists on 'tc-qdisc' man page", is there a separate man page
that describe qdisc parameters?
I'm reading the iproute2 and kernel code which related to TC and record the
value range for each parameter, I think that would be helpful for somebody
else.
Thanks.
>
^ permalink raw reply
* Re: [PATCH 02/11] net: add function to allocate skbuff head without data area
From: Eric Dumazet @ 2012-08-20 6:39 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Florian.Westphal, netdev, netfilter-devel
In-Reply-To: <1345443532-3707-3-git-send-email-kaber@trash.net>
On Mon, 2012-08-20 at 08:18 +0200, Patrick McHardy wrote:
> Add a function to allocate a skbuff head without any data. This will be
> used by memory mapped netlink to attached data from the mmaped area to
> the skb.
>
> Additionally change skb_release_all() to check whether the skb has a
> data area to allow the skb destructor to clear the data pointer in
> case only a head has been allocated.
* ...
>
> +struct sk_buff *__alloc_skb_head(gfp_t gfp_mask, int node)
> +{
> + struct sk_buff *skb;
> +
> + /* Get the HEAD */
> + skb = kmem_cache_alloc_node(skbuff_head_cache,
> + gfp_mask & ~__GFP_DMA, node);
> + if (!skb)
> + goto out;
> + prefetchw(skb);
> +
This prefetch is probably not worth it, since you write on skb on the
following memset(). Cpu wont have enough 'time' to take benefit from
this hint.
> + /*
> + * Only clear those fields we need to clear, not those that we will
> + * actually initialise below. Hence, don't put any more fields after
> + * the tail pointer in struct sk_buff!
> + */
> + memset(skb, 0, offsetof(struct sk_buff, tail));
^ permalink raw reply
* Re: [PATCH 02/11] net: add function to allocate skbuff head without data area
From: Patrick McHardy @ 2012-08-20 6:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian.Westphal, netdev, netfilter-devel
In-Reply-To: <1345444774.5158.241.camel@edumazet-glaptop>
On Mon, 20 Aug 2012, Eric Dumazet wrote:
> On Mon, 2012-08-20 at 08:18 +0200, Patrick McHardy wrote:
>> Add a function to allocate a skbuff head without any data. This will be
>> used by memory mapped netlink to attached data from the mmaped area to
>> the skb.
>>
>> Additionally change skb_release_all() to check whether the skb has a
>> data area to allow the skb destructor to clear the data pointer in
>> case only a head has been allocated.
>
> * ...
>
>>
>> +struct sk_buff *__alloc_skb_head(gfp_t gfp_mask, int node)
>> +{
>> + struct sk_buff *skb;
>> +
>> + /* Get the HEAD */
>> + skb = kmem_cache_alloc_node(skbuff_head_cache,
>> + gfp_mask & ~__GFP_DMA, node);
>> + if (!skb)
>> + goto out;
>> + prefetchw(skb);
>> +
>
> This prefetch is probably not worth it, since you write on skb on the
> following memset(). Cpu wont have enough 'time' to take benefit from
> this hint.
Right, I remember we talked about that before and I already removed it.
Must have forgotten to actually commit that change, thanks!
>
>> + /*
>> + * Only clear those fields we need to clear, not those that we will
>> + * actually initialise below. Hence, don't put any more fields after
>> + * the tail pointer in struct sk_buff!
>> + */
>> + memset(skb, 0, offsetof(struct sk_buff, tail));
^ permalink raw reply
* Re: [PATCH net-next] xfrm: fix RCU bugs
From: Eric Dumazet @ 2012-08-20 7:14 UTC (permalink / raw)
To: Fan Du; +Cc: David Miller, netdev, fengguang.wu, Priyanka Jain
In-Reply-To: <5031DA57.1000904@windriver.com>
On Mon, 2012-08-20 at 14:33 +0800, Fan Du wrote:
> And one out of topic question:
> The usage of xfrm_state_afinfo_lock/xfrm_km_lock is extremely
> similar with xfrm_policy_afinfo_lock, except the former is not so
> frequently read than that of the later.
>
> Is it justified to convert RW xfrm_state_afinfo_lock/xfrm_km_lock into
> RCU?
>
I would say it is justified, and easy enough.
^ permalink raw reply
* Re: [PATCH 4/5] drivers/net/wireless/ath/ath6kl/main.c: introduce missing initialization
From: Kalle Valo @ 2012-08-20 7:24 UTC (permalink / raw)
To: Julia Lawall
Cc: kernel-janitors, John W. Linville, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1345325159-7365-4-git-send-email-Julia.Lawall@lip6.fr>
On 08/19/2012 12:25 AM, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> The result of one call to a function is tested, and then at the second call
> to the same function, the previous result, and not the current result, is
> tested again.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression ret;
> identifier f;
> statement S1,S2;
> @@
>
> *ret = f(...);
> if (\(ret != 0\|ret < 0\|ret == NULL\)) S1
> ... when any
> *f(...);
> if (\(ret != 0\|ret < 0\|ret == NULL\)) S2
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Thanks, but this was already fixed in ath6kl.git by this commit:
commit 3206209f231062170f060fdbae38faacff86ddbf
Author: Pandiyarajan Pitchaimuthu <c_ppitch@qca.qualcomm.com>
Date: Wed Jul 11 12:51:43 2012 +0530
ath6kl: Make use of return value from ath6kl_diag_read()
In ath6kl_read_fwlogs(), return value from ath6kl_diag_read()is not
used to bail out in case of any errors in reading fw log. No real issue
is observed because of this, reported by source code analyzer.
kvalo: fix a long line warning
Signed-off-by: Pandiyarajan Pitchaimuthu <c_ppitch@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Kalle
^ permalink raw reply
* [PATCH] rds: Don't disable BH on BH context
From: Ying Xue @ 2012-08-20 7:44 UTC (permalink / raw)
To: venkat.x.venkatsubra, davem; +Cc: netdev
Since we have already in BH context when *_write_space(),
*_data_ready() as well as *_state_change() are called, it's
unnecessary to disable BH.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
---
net/rds/tcp_connect.c | 4 ++--
net/rds/tcp_listen.c | 4 ++--
net/rds/tcp_recv.c | 4 ++--
net/rds/tcp_send.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/net/rds/tcp_connect.c b/net/rds/tcp_connect.c
index af95c8e..a65ee78 100644
--- a/net/rds/tcp_connect.c
+++ b/net/rds/tcp_connect.c
@@ -43,7 +43,7 @@ void rds_tcp_state_change(struct sock *sk)
struct rds_connection *conn;
struct rds_tcp_connection *tc;
- read_lock_bh(&sk->sk_callback_lock);
+ read_lock(&sk->sk_callback_lock);
conn = sk->sk_user_data;
if (!conn) {
state_change = sk->sk_state_change;
@@ -68,7 +68,7 @@ void rds_tcp_state_change(struct sock *sk)
break;
}
out:
- read_unlock_bh(&sk->sk_callback_lock);
+ read_unlock(&sk->sk_callback_lock);
state_change(sk);
}
diff --git a/net/rds/tcp_listen.c b/net/rds/tcp_listen.c
index 7298137..7787537 100644
--- a/net/rds/tcp_listen.c
+++ b/net/rds/tcp_listen.c
@@ -114,7 +114,7 @@ void rds_tcp_listen_data_ready(struct sock *sk, int bytes)
rdsdebug("listen data ready sk %p\n", sk);
- read_lock_bh(&sk->sk_callback_lock);
+ read_lock(&sk->sk_callback_lock);
ready = sk->sk_user_data;
if (!ready) { /* check for teardown race */
ready = sk->sk_data_ready;
@@ -131,7 +131,7 @@ void rds_tcp_listen_data_ready(struct sock *sk, int bytes)
queue_work(rds_wq, &rds_tcp_listen_work);
out:
- read_unlock_bh(&sk->sk_callback_lock);
+ read_unlock(&sk->sk_callback_lock);
ready(sk, bytes);
}
diff --git a/net/rds/tcp_recv.c b/net/rds/tcp_recv.c
index 6243258..4fac4f2 100644
--- a/net/rds/tcp_recv.c
+++ b/net/rds/tcp_recv.c
@@ -322,7 +322,7 @@ void rds_tcp_data_ready(struct sock *sk, int bytes)
rdsdebug("data ready sk %p bytes %d\n", sk, bytes);
- read_lock_bh(&sk->sk_callback_lock);
+ read_lock(&sk->sk_callback_lock);
conn = sk->sk_user_data;
if (!conn) { /* check for teardown race */
ready = sk->sk_data_ready;
@@ -336,7 +336,7 @@ void rds_tcp_data_ready(struct sock *sk, int bytes)
if (rds_tcp_read_sock(conn, GFP_ATOMIC) == -ENOMEM)
queue_delayed_work(rds_wq, &conn->c_recv_w, 0);
out:
- read_unlock_bh(&sk->sk_callback_lock);
+ read_unlock(&sk->sk_callback_lock);
ready(sk, bytes);
}
diff --git a/net/rds/tcp_send.c b/net/rds/tcp_send.c
index 1b4fd68..81cf5a4 100644
--- a/net/rds/tcp_send.c
+++ b/net/rds/tcp_send.c
@@ -174,7 +174,7 @@ void rds_tcp_write_space(struct sock *sk)
struct rds_connection *conn;
struct rds_tcp_connection *tc;
- read_lock_bh(&sk->sk_callback_lock);
+ read_lock(&sk->sk_callback_lock);
conn = sk->sk_user_data;
if (!conn) {
write_space = sk->sk_write_space;
@@ -194,7 +194,7 @@ void rds_tcp_write_space(struct sock *sk)
queue_delayed_work(rds_wq, &conn->c_send_w, 0);
out:
- read_unlock_bh(&sk->sk_callback_lock);
+ read_unlock(&sk->sk_callback_lock);
/*
* write_space is only called when data leaves tcp's send queue if
--
1.7.11
^ permalink raw reply related
* Re: [PATCH 01/18] ipv4: fix path MTU discovery with connection tracking
From: Eric Dumazet @ 2012-08-20 7:41 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-2-git-send-email-kaber@trash.net>
On Mon, 2012-08-20 at 05:39 +0200, Patrick McHardy wrote:
> IPv4 conntrack defragments incoming packet at the PRE_ROUTING hook and
> (in case of forwarded packets) refragments them at POST_ROUTING
> independant of the IP_DF flag. Refragmentation uses the dst_mtu() of
> the local route without caring about the original fragment sizes,
> thereby breaking PMTUD.
>
> This patch fixes this by keeping track of the largest received fragment
> with IP_DF set and generates an ICMP fragmentation required error during
> refragmentation if that size exceeds the MTU.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH 05/18] netfilter: nf_nat: add protoff argument to packet mangling functions
From: Jan Engelhardt @ 2012-08-20 8:02 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-6-git-send-email-kaber@trash.net>
On Monday 2012-08-20 05:39, Patrick McHardy wrote:
>index 0bb5a69..4b59a15 100644
>--- a/include/linux/netfilter/nf_conntrack_amanda.h
>+++ b/include/linux/netfilter/nf_conntrack_amanda.h
>@@ -4,6 +4,7 @@
>
> extern unsigned int (*nf_nat_amanda_hook)(struct sk_buff *skb,
> enum ip_conntrack_info ctinfo,
>+ unsigned int protoff,
> unsigned int matchoff,
> unsigned int matchlen,
> struct nf_conntrack_expect *exp);
What about using a structure to collect all the accumulating parameters,
like we do for xtables match functions?
^ permalink raw reply
* Re: [PATCH 01/18] ipv4: fix path MTU discovery with connection tracking
From: Jan Engelhardt @ 2012-08-20 8:04 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-2-git-send-email-kaber@trash.net>
On Monday 2012-08-20 05:39, Patrick McHardy wrote:
>IPv4 conntrack defragments incoming packet at the PRE_ROUTING hook and
>(in case of forwarded packets) refragments them at POST_ROUTING
>independant of the IP_DF flag.
"independent". (also in 06/18)
^ permalink raw reply
* Re: [PATCH 1/2] iproute: Add magic cookie to route dump file
From: Pavel Emelyanov @ 2012-08-20 8:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Hemminger, Linux Netdev List
In-Reply-To: <20120817134943.6f26a75e@nehalam.linuxnetplumber.net>
On 08/18/2012 12:49 AM, Stephen Hemminger wrote:
> On Fri, 27 Jul 2012 08:55:41 +0400
> Pavel Emelyanov <xemul@parallels.com> wrote:
>
>> In order to somehow verify that a blob contains route dump a
>> 4-bytes magic is put at the head of the data and is checked
>> on restore.
>>
>> Magic digits are taken from Portland (OR) coordinates :) Is
>> there any more reliable way of generating such?
>>
>> Signed-of-by: Pavel Emelyanov <xemul@parallels.com>
>
> I am planning on putting this in because there were no objections.
> Any followup updates?
Yes, I've recently found that errno propagation from rtnl_talk up to
addrs/routes restore doesn't work on some libc-s. I will post a fixing
patch soon.
Thanks,
Pavel
^ permalink raw reply
* Re: regression with poll(2)
From: Eric Dumazet @ 2012-08-20 8:07 UTC (permalink / raw)
To: Sage Weil
Cc: mgorman, davem, netdev, linux-kernel, ceph-devel, neilb,
a.p.zijlstra, michaelc, emunson, sebastian, cl, akpm, torvalds
In-Reply-To: <alpine.DEB.2.00.1208191051150.15570@cobra.newdream.net>
On Sun, 2012-08-19 at 11:49 -0700, Sage Weil wrote:
> I've bisected and identified this commit:
>
> netvm: propagate page->pfmemalloc to skb
>
> The skb->pfmemalloc flag gets set to true iff during the slab allocation
> of data in __alloc_skb that the the PFMEMALLOC reserves were used. If the
> packet is fragmented, it is possible that pages will be allocated from the
> PFMEMALLOC reserve without propagating this information to the skb. This
> patch propagates page->pfmemalloc from pages allocated for fragments to
> the skb.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Acked-by: David S. Miller <davem@davemloft.net>
> Cc: Neil Brown <neilb@suse.de>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Mike Christie <michaelc@cs.wisc.edu>
> Cc: Eric B Munson <emunson@mgebm.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Christoph Lameter <cl@linux.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> I've retested several times and confirmed that this change leads to the
> breakage, and also confirmed that reverting it on top of -rc1 also fixes
> the problem.
>
> I've also added some additional instrumentation to my code and confirmed
> that the process is blocking on poll(2) while netstat is reporting
> data available on the socket.
>
> What can I do to help track this down?
>
> Thanks!
> sage
>
>
> On Wed, 15 Aug 2012, Sage Weil wrote:
>
> > I'm experiencing a stall with Ceph daemons communicating over TCP that
> > occurs reliably with 3.6-rc1 (and linus/master) but not 3.5. The basic
> > situation is:
> >
> > - the socket is two processes communicating over TCP on the same host, e.g.
> >
> > tcp 0 2164849 10.214.132.38:6801 10.214.132.38:51729 ESTABLISHED
> >
> > - one end writes a bunch of data in
> > - the other end consumes data, but at some point stalls.
> > - reads are nonblocking, e.g.
> >
> > int got = ::recv( sd, buf, len, MSG_DONTWAIT );
> >
> > and between those calls we wait with
> >
> > struct pollfd pfd;
> > short evmask;
> > pfd.fd = sd;
> > pfd.events = POLLIN;
> > #if defined(__linux__)
> > pfd.events |= POLLRDHUP;
> > #endif
> >
> > if (poll(&pfd, 1, msgr->timeout) <= 0)
> > return -1;
> >
> > - in my case the timeout is ~15 minutes. at that point it errors out,
> > and the daemons reconnect and continue for a while until hitting this
> > again.
> >
> > - at the time of the stall, the reading process is blocked on that
> > poll(2) call. There are a bunch of threads stuck on poll(2), some of them
> > stuck and some not, but they all have stacks like
> >
> > [<ffffffff8118f6f9>] poll_schedule_timeout+0x49/0x70
> > [<ffffffff81190baf>] do_sys_poll+0x35f/0x4c0
> > [<ffffffff81190deb>] sys_poll+0x6b/0x100
> > [<ffffffff8163d369>] system_call_fastpath+0x16/0x1b
> >
> > - you'll note that the netstat output shows data queued:
> >
> > tcp 0 1163264 10.214.132.36:6807 10.214.132.36:41738 ESTABLISHED
> > tcp 0 1622016 10.214.132.36:41738 10.214.132.36:6807 ESTABLISHED
> >
In this netstat output, we can see some data in output queues, but no
data on receive queues. poll() is OK.
Some TCP frames are not properly delivered, even after a retransmit.
( to see useful stats/counters : ss -emoi dst 10.214.132.36)
For loopback transmits, skbs are taken from the output queue, cloned and
feeded to local stack.
If they have the pfmemalloc bit, they wont be delivered to normal
sockets, but dropped.
tcp_sendmsg() seems to be able to queue skbs with pfmemalloc set to
true, and this makes no sense to me.
^ permalink raw reply
* [PATCH] iproute: Fix errno propagation from rtnl_talk
From: Pavel Emelyanov @ 2012-08-20 8:08 UTC (permalink / raw)
To: Stephen Hemminger, Linux Netdev List
Callers of rtnl_talk check errno value for their needs. In particular, the addrs
and routes restoring code validly reports success if the EEXISTS is in there.
However, the errno value can be sometimes screwed up by the perror call. Thus
we should only set it _after_ the message was emitted.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 878911e..8e8c8b9 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -360,13 +360,14 @@ int rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n, pid_t peer,
if (l < sizeof(struct nlmsgerr)) {
fprintf(stderr, "ERROR truncated\n");
} else {
- errno = -err->error;
- if (errno == 0) {
+ if (!err->error) {
if (answer)
memcpy(answer, h, h->nlmsg_len);
return 0;
}
- perror("RTNETLINK answers");
+
+ fprintf(stderr, "RTNETLINK answers: %s\n", strerror(-err->error));
+ errno = -err->error;
}
return -1;
}
^ permalink raw reply related
* APPROVED OF PAYMENT
From: BARCLAYS BANK UNITED KINGDOM @ 2012-08-20 8:37 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: BARCLAYS BANK UNITED KINGDOM RE CONFIRMATION OF PAYMENT FUND.doc --]
[-- Type: application/msword, Size: 80896 bytes --]
^ permalink raw reply
* Re: [PATCH 06/18] netfilter: add protocol independant NAT core
From: Jan Engelhardt @ 2012-08-20 8:57 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-7-git-send-email-kaber@trash.net>
On Monday 2012-08-20 05:39, Patrick McHardy wrote:
>
> enum ctattr_nat {
> CTA_NAT_UNSPEC,
>- CTA_NAT_MINIP,
>- CTA_NAT_MAXIP,
>+ CTA_NAT_V4_MINIP,
>+#define CTA_NAT_MINIP CTA_NAT_V4_MINIP
>+ CTA_NAT_V4_MAXIP,
>+#define CTA_NAT_MAXIP CTA_NAT_V4_MAXIP
> CTA_NAT_PROTO,
> __CTA_NAT_MAX
> };
One could also
enum ctattr_nat {
...
__CTA_NAT_MAX,
CTA_NAT_MINIP = CTA_NAT_V4_MINIP,
CTA_NAT_MAXIP = CTA_NAT_V4_MAXIP,
};
to provide the old names.
>diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
>index fcc543c..33372a1 100644
>--- a/net/ipv4/netfilter/Kconfig
>+++ b/net/ipv4/netfilter/Kconfig
[...]
>
>-config NF_NAT_NEEDED
>- bool
>- depends on NF_NAT
>- default y
>-
Could add "if NF_NAT_IPV4".."endif" block as appropriate around here,
to save on all the extra "depend on NF_NAT_IPV4" clauses.
> config IP_NF_TARGET_MASQUERADE
> tristate "MASQUERADE target support"
>- depends on NF_NAT
>+ depends on NF_NAT_IPV4
> default m if NETFILTER_ADVANCED=n
> help
> Masquerading is a special case of NAT: all outgoing connections are
>+static int nf_nat_ipv4_in_range(const struct nf_conntrack_tuple *t,
>+ const struct nf_nat_range *range)
>+{
>+ return ntohl(t->src.u3.ip) >= ntohl(range->min_addr.ip) &&
>+ ntohl(t->src.u3.ip) <= ntohl(range->max_addr.ip);
>+}
static bool ..
>+static bool nf_nat_ipv4_manip_pkt(struct sk_buff *skb,
>+ unsigned int iphdroff,
>+ const struct nf_nat_l4proto *l4proto,
>+ const struct nf_conntrack_tuple *target,
>+ enum nf_nat_manip_type maniptype)
>+{
>+ struct iphdr *iph;
>+ unsigned int hdroff;
>+
>+ if (!skb_make_writable(skb, iphdroff + sizeof(*iph)))
>+ return false;
>+
>+ iph = (void *)skb->data + iphdroff;
Is iph = ip_hdr(skb), hdroff = iphdroff+skb_iphdrlen(iph) not usable here?
>+ hdroff = iphdroff + iph->ihl * 4;
>+
>+ if (!l4proto->manip_pkt(skb, &nf_nat_l3proto_ipv4, iphdroff, hdroff,
>+ target, maniptype))
>+ return false;
>+ iph = (void *)skb->data + iphdroff;
Is trying to avoid some GNU extensions a worthwhile goal? If so,
iph = (struct iphdr *)(skb->data + iphdroff) should be used, like in:
>+static void nf_nat_ipv4_csum_update(struct sk_buff *skb,
>+ unsigned int iphdroff, __sum16 *check,
>+ const struct nf_conntrack_tuple *t,
>+ enum nf_nat_manip_type maniptype)
>+{
>+ struct iphdr *iph = (struct iphdr *)(skb->data + iphdroff);
>[...]
>+}
>+static void nf_nat_ipv4_csum_recalc(struct sk_buff *skb,
>+ u8 proto, void *data, __sum16 *check,
>+ int datalen, int oldlen)
>+{
>+ const struct iphdr *iph = ip_hdr(skb);
>+ struct rtable *rt = skb_rtable(skb);
>+
>+ if (skb->ip_summed != CHECKSUM_PARTIAL) {
>+ if (!(rt->rt_flags & RTCF_LOCAL) &&
>+ (!skb->dev || skb->dev->features & NETIF_F_V4_CSUM)) {
>+ skb->ip_summed = CHECKSUM_PARTIAL;
>+ skb->csum_start = skb_headroom(skb) +
>+ skb_network_offset(skb) +
>+ ip_hdrlen(skb);
>+ skb->csum_offset = (void *)check - data;
>+ *check = ~csum_tcpudp_magic(iph->saddr, iph->daddr,
>+ datalen, proto, 0);
>+ } else {
>+ *check = 0;
>+ *check = csum_tcpudp_magic(iph->saddr, iph->daddr,
>+ datalen, proto,
>+ csum_partial(data, datalen,
>+ 0));
>+ if (proto == IPPROTO_UDP && !*check)
>+ *check = CSUM_MANGLED_0;
>+ }
>+ } else
>+ inet_proto_csum_replace2(check, skb,
>+ htons(oldlen), htons(datalen), 1);
>+}
Here is a style factory trick: invert the condition such that the
simple case is first, and the big one becomes an else if
with a reduced indent:
if (skb->ip_summed == CHECKSUM_PARTIAL) {
inet_proto_csum_replace2(check, skb,
htons(oldlen), htons(datalen), 1);
} else if (!(rt->rt_flags & RTCF_LOCAL) &&
(!skb->dev || skb->dev->features & NETIF_F_V4_CSUM)) {
skb->ip_summed = CHECKSUM_PARTIAL;
skb->csum_start = skb_headroom(skb) +
skb_network_offset(skb) +
ip_hdrlen(skb);
skb->csum_offset = (void *)check - data;
*check = ~csum_tcpudp_magic(iph->saddr, iph->daddr,
datalen, proto, 0);
} else {
*check = 0;
*check = csum_tcpudp_magic(iph->saddr, iph->daddr,
datalen, proto,
csum_partial(data, datalen,
0));
if (proto == IPPROTO_UDP && !*check)
*check = CSUM_MANGLED_0;
}
>+static void __exit nf_nat_l3proto_ipv4_exit(void)
>+{
>+ nf_nat_l3proto_unregister(&nf_nat_l3proto_ipv4);
>+ nf_nat_l4proto_unregister(NFPROTO_IPV4, &nf_nat_l4proto_icmp);
>+}
>+
>+MODULE_LICENSE("GPL");
>+MODULE_ALIAS("nf-nat-" __stringify(AF_INET));
Technically, this would have to be NFPROTO_IPV4, though GNU C has yet
to gain an extension to stringify enum constants..
>+ /* 1) If this srcip/proto/src-proto-part is currently mapped,
>+ * and that same mapping gives a unique tuple within the given
>+ * range, use that.
>+ *
>+ * This is only required for source (ie. NAT/masq) mappings.
>+ * So far, we don't do local source mappings, so multiple
>+ * manips not an issue.
manips are not an issue.
>- /* nf_conntrack_alter_reply might re-allocate extension area */
>+ /* nf_conntrack_alter_reply might re-allocate exntension aera */
extension was correct :)
>+ {
>+ .name = "SNAT",
>+ .revision = 1,
>+ .target = xt_snat_target_v1,
>+ .targetsize = sizeof(struct nf_nat_range),
>+ .table = "nat",
>+ .hooks = (1 << NF_INET_POST_ROUTING) |
>+ (1 << NF_INET_LOCAL_OUT),
>+ .me = THIS_MODULE,
.family = NFPROTO_UNSPEC,
Just for completeness.
^ permalink raw reply
* Re: [PATCH 09/18] netfilter: ipv6: add IPv6 NAT support
From: Jan Engelhardt @ 2012-08-20 9:03 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <1345434006-16549-10-git-send-email-kaber@trash.net>
On Monday 2012-08-20 05:39, Patrick McHardy wrote:
>+static struct nf_hook_ops nf_nat_ipv6_ops[] __read_mostly = {
>+ /* Before packet filtering, change destination */
>+ {
>+ .hook = nf_nat_ipv6_in,
>+ .owner = THIS_MODULE,
>+ .pf = NFPROTO_IPV6,
>+ .hooknum = NF_INET_PRE_ROUTING,
>+ .priority = NF_IP_PRI_NAT_DST,
NF_IP6_PRI_NAT_DST
>+ .hook = nf_nat_ipv6_out,
>+ .owner = THIS_MODULE,
>+ .pf = NFPROTO_IPV6,
>+ .hooknum = NF_INET_POST_ROUTING,
>+ .priority = NF_IP_PRI_NAT_SRC,
IP6 too... (2 more occurrences)
>+static void nf_nat_ipv6_csum_recalc(struct sk_buff *skb,
>+ u8 proto, void *data, __sum16 *check,
>+ int datalen, int oldlen)
>+{
>+ const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
>+ struct rt6_info *rt = (struct rt6_info *)skb_dst(skb);
>+
>+ if (skb->ip_summed != CHECKSUM_PARTIAL) {
Maybe invert to == CHECKSUM_PARTIAL like in p06/18.
^ permalink raw reply
* Re: regression with poll(2)
From: Mel Gorman @ 2012-08-20 9:04 UTC (permalink / raw)
To: Sage Weil
Cc: davem, netdev, linux-kernel, ceph-devel, neilb, a.p.zijlstra,
michaelc, emunson, eric.dumazet, sebastian, cl, akpm, torvalds
In-Reply-To: <alpine.DEB.2.00.1208191051150.15570@cobra.newdream.net>
On Sun, Aug 19, 2012 at 11:49:31AM -0700, Sage Weil wrote:
> I've bisected and identified this commit:
>
> netvm: propagate page->pfmemalloc to skb
>
> The skb->pfmemalloc flag gets set to true iff during the slab allocation
> of data in __alloc_skb that the the PFMEMALLOC reserves were used. If the
> packet is fragmented, it is possible that pages will be allocated from the
> PFMEMALLOC reserve without propagating this information to the skb. This
> patch propagates page->pfmemalloc from pages allocated for fragments to
> the skb.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> Acked-by: David S. Miller <davem@davemloft.net>
> Cc: Neil Brown <neilb@suse.de>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Mike Christie <michaelc@cs.wisc.edu>
> Cc: Eric B Munson <emunson@mgebm.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Christoph Lameter <cl@linux.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
Ok, thanks.
> I've retested several times and confirmed that this change leads to the
> breakage, and also confirmed that reverting it on top of -rc1 also fixes
> the problem.
>
> I've also added some additional instrumentation to my code and confirmed
> that the process is blocking on poll(2) while netstat is reporting
> data available on the socket.
>
> What can I do to help track this down?
>
Can the following patch be tested please? It is reported to fix an fio
regression that may be similar to what you are experiencing but has not
been picked up yet.
---8<---
From: Alex Shi <alex.shi@intel.com>
Subject: [PATCH] mm: correct page->pfmemalloc to fix deactivate_slab regression
commit cfd19c5a9ec (mm: only set page->pfmemalloc when
ALLOC_NO_WATERMARKS was used) try to narrow down page->pfmemalloc
setting, but it missed some places the pfmemalloc should be set.
So, in __slab_alloc, the unalignment pfmemalloc and ALLOC_NO_WATERMARKS
cause incorrect deactivate_slab() on our core2 server:
64.73% fio [kernel.kallsyms] [k] _raw_spin_lock
|
--- _raw_spin_lock
|
|---0.34%-- deactivate_slab
| __slab_alloc
| kmem_cache_alloc
| |
That causes our fio sync write performance has 40% regression.
This patch move the checking in get_page_from_freelist, that resolved
this issue.
Signed-off-by: Alex Shi <alex.shi@intel.com>
---
mm/page_alloc.c | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 009ac28..07f1924 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1928,6 +1928,17 @@ this_zone_full:
zlc_active = 0;
goto zonelist_scan;
}
+
+ if (page)
+ /*
+ * page->pfmemalloc is set when ALLOC_NO_WATERMARKS was
+ * necessary to allocate the page. The expectation is
+ * that the caller is taking steps that will free more
+ * memory. The caller should avoid the page being used
+ * for !PFMEMALLOC purposes.
+ */
+ page->pfmemalloc = !!(alloc_flags & ALLOC_NO_WATERMARKS);
+
return page;
}
@@ -2389,14 +2400,6 @@ rebalance:
zonelist, high_zoneidx, nodemask,
preferred_zone, migratetype);
if (page) {
- /*
- * page->pfmemalloc is set when ALLOC_NO_WATERMARKS was
- * necessary to allocate the page. The expectation is
- * that the caller is taking steps that will free more
- * memory. The caller should avoid the page being used
- * for !PFMEMALLOC purposes.
- */
- page->pfmemalloc = true;
goto got_pg;
}
}
@@ -2569,8 +2572,6 @@ retry_cpuset:
page = __alloc_pages_slowpath(gfp_mask, order,
zonelist, high_zoneidx, nodemask,
preferred_zone, migratetype);
- else
- page->pfmemalloc = false;
trace_mm_page_alloc(page, order, gfp_mask, migratetype);
--
1.7.5.4
^ permalink raw reply related
* Re: [RFC Patch net-next] ipv6: unify conntrack reassembly expire code with standard one
From: Cong Wang @ 2012-08-20 9:06 UTC (permalink / raw)
To: Michal Kubeček
Cc: netdev, Herbert Xu, David S. Miller, Hideaki YOSHIFUJI,
Patrick McHardy, Shan Wei, Pablo Neira Ayuso, netfilter-devel
In-Reply-To: <1826853.rak2U42CMU@alaris>
Hi, Michal!
On Fri, 2012-08-17 at 19:05 +0200, Michal Kubeček wrote:
> On Friday 17 of August 2012 16:02EN, Cong Wang wrote:
> > Two years ago, Shan Wei tried to fix this:
> > http://patchwork.ozlabs.org/patch/43905/
> >
> ...
> >
> > As Herbert suggested, we could actually use the standard IPv6
> > reassembly code which follows RFC2460.
>
> I tested the patch and I ran into a problem in this place in
> ip6_expire_frag_queue():
>
> > net = container_of(fq->q.net, struct net, ipv6.frags);
>
> For frag queues coming from IPv6 conntrack, fq->q.net points to
> nf_init_frags which is not embedded into struct net so that the
> following device lookup leads to reading from an invalid address.
> The same problem has been discussed on the page linked above.
>
> I didn't test with current net-next source but as far as I can tell,
> this hasn't changed. Did I miss something?
>
No, you don't miss anything. I missed that piece of code, you are right
that nf_init_frags is not actually embedded, so that container_of()
doesn't work. I think we probably can save the struct net pointer in
struct netns_frags during inet_frags_init_net(), so that container_of()
can be eliminated.
Thanks for testing! I tried to test it too, but seems I can't trigger a
defragment. Any hints?
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-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
* Re: [PATCH 1/2] dt: introduce for_each_available_child_of_node, of_get_next_available_child
From: David Miller @ 2012-08-20 9:16 UTC (permalink / raw)
To: timur; +Cc: grant.likely, david.daney, netdev, devicetree-discuss
In-Reply-To: <1344986424-14360-1-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Tue, 14 Aug 2012 18:20:23 -0500
> Macro for_each_child_of_node() makes it easy to iterate over all of the
> children for a given device tree node, including those nodes that are
> marked as unavailable (i.e. status = "disabled").
>
> Introduce for_each_available_child_of_node(), which is like
> for_each_child_of_node(), but it automatically skips unavailable nodes.
> This also requires the introduction of helper function
> of_get_next_available_child(), which returns the next available child
> node.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] [v2] netdev/phy: skip disabled mdio-mux nodes
From: David Miller @ 2012-08-20 9:16 UTC (permalink / raw)
To: timur; +Cc: grant.likely, david.daney, netdev, devicetree-discuss
In-Reply-To: <1344986424-14360-2-git-send-email-timur@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Tue, 14 Aug 2012 18:20:24 -0500
> The mdio-mux driver scans all child mdio nodes, without regard to whether
> the node is actually used. Some device trees include all possible
> mdio-mux nodes and rely on the boot loader to disable those that are not
> present, based on some run-time configuration. Those nodes need to be
> skipped.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: sh_eth: Add eth support for R8A7779 device
From: David Miller @ 2012-08-20 9:17 UTC (permalink / raw)
To: phil.edworthy
Cc: netdev, linux-sh, kuninori.morimoto.gx, yoshihiro.shimoda.uh
In-Reply-To: <1345012409-12915-1-git-send-email-phil.edworthy@renesas.com>
From: Phil Edworthy <phil.edworthy@renesas.com>
Date: Wed, 15 Aug 2012 07:33:29 +0100
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: new devices: UML290 and K5006-Z
From: David Miller @ 2012-08-20 9:17 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
dcbw-H+wXaHxf7aLQT0dZR+AlfA, tschaefer-zqRNUXuvxA0b1SvskN2V4Q
In-Reply-To: <1345038177-29189-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Wed, 15 Aug 2012 15:42:57 +0200
> Newer firmware versions for the Pantech UML290 use a different
> subclass ID. The Windows driver match on both IDs, so we do
> that as well.
>
> The ZTE (Vodafone) K5006-Z is a new device.
>
> Cc: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Thomas Schäfer <tschaefer-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCH 001/001] smsc95xx: Fix hard_header_len
From: David Miller @ 2012-08-20 9:19 UTC (permalink / raw)
To: steve; +Cc: bhutchings, jimbob.betts, netdev
In-Reply-To: <CAKh2mn6fr8WjT-2h_A3zmKv3xs26AamXcpJgtK5wFPQ1BXuheg@mail.gmail.com>
From: Steve Glendinning <steve@shawell.net>
Date: Fri, 17 Aug 2012 09:35:04 +0100
>> hard_header_len is set to ETH_HLEN by alloc_etherdev() (in the
>> ether_setup() callback). Any extra headroom you want before the
>> Ethernet header should indeed be specified in needed_headroom.
>
> Thanks Ben, looks like this patch is doing it the right way then.
>
> Acked-By: Steve Glendinning <steve.glendinning@shawell.net>
This patch needs to be submitted with a proper signoff.
^ permalink raw reply
* Re: [PATCH] smsc75xx: add missing entry to MAINTAINERS
From: David Miller @ 2012-08-20 9:20 UTC (permalink / raw)
To: steve.glendinning; +Cc: linux-kernel, netdev, trivial
In-Reply-To: <1345103618-22753-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Thu, 16 Aug 2012 08:53:38 +0100
> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Applied.
^ 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