* Re: [PATCH 0/3] ipvs: IPv6 fragment handling for IPVS
From: Simon Horman @ 2012-08-21 5:24 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, Patrick McHardy, Hans Schillstrom, lvs-devel,
Julian Anastasov, Wensong Zhang, netfilter-devel,
Pablo Neira Ayuso
In-Reply-To: <20120820130732.1509.13080.stgit@dragon>
On Mon, Aug 20, 2012 at 03:08:30PM +0200, Jesper Dangaard Brouer wrote:
> The following patchset implement IPv6 fragment handling for IPVS.
>
> This work is based upon patches from Hans Schillstrom. I have taken
> over the patchset, in close agreement with Hans, because he don't have
> (gotten allocated) time to complete his work.
>
> I have cleaned up the patchset, changed the API a bit, fixed a refcnt
> bug, and rebased on top of Julians recent changes. (All with Hans'es
> knowledge)
>
> Patch01: is just unrelated trivial fixes.
>
> Patch02: Fix faulty IPv6 extension header handling in IPVS
>
> Patch03: Complete IPv6 fragment handling for IPVS
>
> This patchset is based upon:
> Homes ipvs-next tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git
>
> On top of commit 3654e61137db891f5312e6dd813b961484b5fdf3:
> ipvs: add pmtu_disc option to disable IP DF for TUN packets
I have no objection to these changes, but I would be more comfortable
applying them after a review from Hans, Julian or Pablo.
>
> ---
>
> Jesper Dangaard Brouer (3):
> ipvs: Complete IPv6 fragment handling for IPVS
> ipvs: Fix faulty IPv6 extension header handling in IPVS
> ipvs: Trivial changes, use compressed IPv6 address in output
>
>
> include/net/ip_vs.h | 191 +++++++++++----
> net/netfilter/ipvs/Kconfig | 7 -
> net/netfilter/ipvs/ip_vs_conn.c | 15 -
> net/netfilter/ipvs/ip_vs_core.c | 384 +++++++++++++++++--------------
> net/netfilter/ipvs/ip_vs_dh.c | 2
> net/netfilter/ipvs/ip_vs_lblc.c | 2
> net/netfilter/ipvs/ip_vs_lblcr.c | 2
> net/netfilter/ipvs/ip_vs_pe_sip.c | 27 ++
> net/netfilter/ipvs/ip_vs_proto.c | 6
> net/netfilter/ipvs/ip_vs_proto_ah_esp.c | 9 -
> net/netfilter/ipvs/ip_vs_proto_sctp.c | 42 +--
> net/netfilter/ipvs/ip_vs_proto_tcp.c | 40 +--
> net/netfilter/ipvs/ip_vs_proto_udp.c | 41 +--
> net/netfilter/ipvs/ip_vs_sched.c | 2
> net/netfilter/ipvs/ip_vs_sh.c | 2
> net/netfilter/ipvs/ip_vs_xmit.c | 75 +++---
> net/netfilter/xt_ipvs.c | 4
> 17 files changed, 489 insertions(+), 362 deletions(-)
>
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Sr. Network Kernel Developer at Red Hat
> Author of http://www.iptv-analyzer.org
> LinkedIn: http://www.linkedin.com/in/brouer
>
^ permalink raw reply
* [PATCH] iproute2: Add missing tc-ematch.8 for man page installation
From: Oliver Hartkopp @ 2012-08-21 5:16 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Netdev List
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/man/man8/Makefile b/man/man8/Makefile
index c344094..2556564 100644
--- a/man/man8/Makefile
+++ b/man/man8/Makefile
@@ -1,7 +1,7 @@
TARGETS = ip-address.8 ip-link.8 ip-route.8
MAN8PAGES = $(TARGETS) ip.8 arpd.8 lnstat.8 routel.8 rtacct.8 rtmon.8 ss.8 \
- tc-bfifo.8 tc-cbq-details.8 tc-cbq.8 tc-drr.8 tc-htb.8 \
+ tc-bfifo.8 tc-cbq-details.8 tc-cbq.8 tc-drr.8 tc-ematch.8 tc-htb.8 \
tc-pfifo.8 tc-pfifo_fast.8 tc-prio.8 tc-red.8 tc-sfq.8 \
tc-tbf.8 tc.8 tc-codel.8 tc-fq_codel.8 tc-sfb.8 tc-netem.8 tc-choke.8 \
bridge.8 rtstat.8 ctstat.8 nstat.8 routef.8 \
^ permalink raw reply related
* Re: regression with poll(2)
From: Eric Dumazet @ 2012-08-21 5:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Sage Weil, davem, netdev, linux-kernel, ceph-devel,
neilb, a.p.zijlstra, michaelc, emunson, sebastian, cl, torvalds
In-Reply-To: <20120820162046.f827f758.akpm@linux-foundation.org>
On Mon, 2012-08-20 at 16:20 -0700, Andrew Morton wrote:
> On Mon, 20 Aug 2012 11:30:59 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Mon, 2012-08-20 at 10:04 +0100, Mel Gorman wrote:
> >
> > > 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.
> > >
> > > -
> >
> > This seems to help here.
> >
> > Boot your machine with "mem=768M" or a bit less depending on your setup,
> > and try a netperf.
> >
> > -> before patch :
> >
> > # netperf
> > MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> > localhost.localdomain () port 0 AF_INET
> > Recv Send Send
> > Socket Socket Message Elapsed
> > Size Size Size Time Throughput
> > bytes bytes bytes secs. 10^6bits/sec
> >
> > 87380 16384 16384 14.00 6.05
> >
> > -> after patch :
> >
> > Recv Send Send
> > Socket Socket Message Elapsed
> > Size Size Size Time Throughput
> > bytes bytes bytes secs. 10^6bits/sec
> >
> > 87380 16384 16384 10.00 18509.73
>
> "seem to help"? Was previous performance fully restored?
I did some tests this morning on my HP Z600, and got same numbers than
3.5.0
Of course, its a bit difficult to say, because there is no
CONFIG_PFMEMALLOC to test real impact.
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: do not hold route table lock when send ndisc probe
From: Cong Wang @ 2012-08-21 3:44 UTC (permalink / raw)
To: Debabrata Banerjee
Cc: netdev, Banerjee, Debabrata, David S. Miller, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <CAATkVEzKuTeUbU75B6EoSfFvGVsz_eK47XNWmsP5KcCvjTDEDA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Hi, Debabrata,
Could you help to test the attached patch below?
Thanks!
[-- Attachment #2: ipv6-deadlock.diff --]
[-- Type: text/x-patch, Size: 1563 bytes --]
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index eb3f1e4..cd141a5 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -440,9 +440,26 @@ out:
}
#ifdef CONFIG_IPV6_ROUTER_PREF
+struct ndisc_work {
+ struct work_struct work;
+ struct in6_addr mcaddr;
+ struct in6_addr target;
+ struct net_device *dev;
+};
+
+static void queue_ndisc(struct work_struct *work)
+{
+ struct ndisc_work *nw =
+ container_of(work, struct ndisc_work, work);
+ ndisc_send_ns(nw->dev, NULL, &nw->target, &nw->mcaddr, NULL);
+ kfree(nw);
+}
+
static void rt6_probe(struct rt6_info *rt)
{
struct neighbour *neigh;
+ struct ndisc_work *nw;
+
/*
* Okay, this does not seem to be appropriate
* for now, however, we need to check if it
@@ -457,15 +474,18 @@ static void rt6_probe(struct rt6_info *rt)
read_lock_bh(&neigh->lock);
if (!(neigh->nud_state & NUD_VALID) &&
time_after(jiffies, neigh->updated + rt->rt6i_idev->cnf.rtr_probe_interval)) {
- struct in6_addr mcaddr;
- struct in6_addr *target;
neigh->updated = jiffies;
read_unlock_bh(&neigh->lock);
- target = (struct in6_addr *)&neigh->primary_key;
- addrconf_addr_solict_mult(target, &mcaddr);
- ndisc_send_ns(rt->dst.dev, NULL, target, &mcaddr, NULL);
+ nw = kmalloc(sizeof(*nw), GFP_ATOMIC);
+ if (nw) {
+ memcpy(&nw->target, &neigh->primary_key, sizeof(struct in6_addr));
+ addrconf_addr_solict_mult(&nw->target, &nw->mcaddr);
+ nw->dev = rt->dst.dev;
+ INIT_WORK(&nw->work, queue_ndisc);
+ schedule_work(&nw->work);
+ }
} else {
read_unlock_bh(&neigh->lock);
}
^ permalink raw reply related
* Re: [PATCH] serial: add a new helper function
From: Huang Shijie @ 2012-08-21 2:52 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg KH, alan, jirislaby, linux-kernel, linux-serial, netdev
In-Reply-To: <20120819164658.1737bb74@pyramind.ukuu.org.uk>
On Sun, Aug 19, 2012 at 11:46 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sat, 18 Aug 2012 23:44:29 -0700
> Greg KH <gregkh@linuxfoundation.org> wrote:
>
>> On Sun, Aug 19, 2012 at 02:27:12PM -0400, Huang Shijie wrote:
>> > --- a/include/linux/tty.h
>> > +++ b/include/linux/tty.h
>> > @@ -43,6 +43,7 @@
>> > #include <linux/tty_driver.h>
>> > #include <linux/tty_ldisc.h>
>> > #include <linux/mutex.h>
>> > +#include <linux/serial.h>
>> >
>> >
>> >
>> > @@ -513,6 +514,12 @@ static inline struct tty_port *tty_port_get(struct tty_port *port)
>> > return port;
>> > }
>> >
>> > +/* If the cts flow control is enabled, return true. */
>> > +static inline bool tty_port_cts_enabled(struct tty_port *port)
>> > +{
>> > + return port->flags & ASYNC_CTS_FLOW;
>> > +}
>> > +
>>
>> The fact that you have to add serial.h to this file kind of implies that
>> this function shouldn't be here, right?
>>
>> How about serial.h instead? Not all tty drivers are serial drivers :)
>
> tty_port is tty generic so possibly if there is a generic helper the
> flags and helper should likewise be this way.
>
> As it stands at the moment ASYNC_CTS_FLOW is a convention a few drivers
> use. So calling it tty_port_xxx is going to misleading.
this patch makes the header files in a mess.
Please just ignore this patch if it is not good enough.
thanks
Huang Shijie
>
> Alan
^ permalink raw reply
* Re: [PATCH] tcp: fix possible socket refcount problem
From: Fengguang Wu @ 2012-08-21 2:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, networking
In-Reply-To: <1345458166.5158.316.camel@edumazet-glaptop>
I'm sure it fixed the problem: up to now, there are 264 boots (each
taking 1.5 hours) without a single failure. Thanks for the quick fix!
On Mon, Aug 20, 2012 at 12:22:46PM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Commit 6f458dfb40 (tcp: improve latencies of timer triggered events)
> added bug leading to following trace :
>
> [ 2866.131281] IPv4: Attempt to release TCP socket in state 1 ffff880019ec0000
> [ 2866.131726]
> [ 2866.132188] =========================
> [ 2866.132281] [ BUG: held lock freed! ]
> [ 2866.132281] 3.6.0-rc1+ #622 Not tainted
> [ 2866.132281] -------------------------
> [ 2866.132281] kworker/0:1/652 is freeing memory ffff880019ec0000-ffff880019ec0a1f, with a lock still held there!
> [ 2866.132281] (sk_lock-AF_INET-RPC){+.+...}, at: [<ffffffff81903619>] tcp_sendmsg+0x29/0xcc6
> [ 2866.132281] 4 locks held by kworker/0:1/652:
> [ 2866.132281] #0: (rpciod){.+.+.+}, at: [<ffffffff81083567>] process_one_work+0x1de/0x47f
> [ 2866.132281] #1: ((&task->u.tk_work)){+.+.+.}, at: [<ffffffff81083567>] process_one_work+0x1de/0x47f
> [ 2866.132281] #2: (sk_lock-AF_INET-RPC){+.+...}, at: [<ffffffff81903619>] tcp_sendmsg+0x29/0xcc6
> [ 2866.132281] #3: (&icsk->icsk_retransmit_timer){+.-...}, at: [<ffffffff81078017>] run_timer_softirq+0x1ad/0x35f
> [ 2866.132281]
> [ 2866.132281] stack backtrace:
> [ 2866.132281] Pid: 652, comm: kworker/0:1 Not tainted 3.6.0-rc1+ #622
> [ 2866.132281] Call Trace:
> [ 2866.132281] <IRQ> [<ffffffff810bc527>] debug_check_no_locks_freed+0x112/0x159
> [ 2866.132281] [<ffffffff818a0839>] ? __sk_free+0xfd/0x114
> [ 2866.132281] [<ffffffff811549fa>] kmem_cache_free+0x6b/0x13a
> [ 2866.132281] [<ffffffff818a0839>] __sk_free+0xfd/0x114
> [ 2866.132281] [<ffffffff818a08c0>] sk_free+0x1c/0x1e
> [ 2866.132281] [<ffffffff81911e1c>] tcp_write_timer+0x51/0x56
> [ 2866.132281] [<ffffffff81078082>] run_timer_softirq+0x218/0x35f
> [ 2866.132281] [<ffffffff81078017>] ? run_timer_softirq+0x1ad/0x35f
> [ 2866.132281] [<ffffffff810f5831>] ? rb_commit+0x58/0x85
> [ 2866.132281] [<ffffffff81911dcb>] ? tcp_write_timer_handler+0x148/0x148
> [ 2866.132281] [<ffffffff81070bd6>] __do_softirq+0xcb/0x1f9
> [ 2866.132281] [<ffffffff81a0a00c>] ? _raw_spin_unlock+0x29/0x2e
> [ 2866.132281] [<ffffffff81a1227c>] call_softirq+0x1c/0x30
> [ 2866.132281] [<ffffffff81039f38>] do_softirq+0x4a/0xa6
> [ 2866.132281] [<ffffffff81070f2b>] irq_exit+0x51/0xad
> [ 2866.132281] [<ffffffff81a129cd>] do_IRQ+0x9d/0xb4
> [ 2866.132281] [<ffffffff81a0a3ef>] common_interrupt+0x6f/0x6f
> [ 2866.132281] <EOI> [<ffffffff8109d006>] ? sched_clock_cpu+0x58/0xd1
> [ 2866.132281] [<ffffffff81a0a172>] ? _raw_spin_unlock_irqrestore+0x4c/0x56
> [ 2866.132281] [<ffffffff81078692>] mod_timer+0x178/0x1a9
> [ 2866.132281] [<ffffffff818a00aa>] sk_reset_timer+0x19/0x26
> [ 2866.132281] [<ffffffff8190b2cc>] tcp_rearm_rto+0x99/0xa4
> [ 2866.132281] [<ffffffff8190dfba>] tcp_event_new_data_sent+0x6e/0x70
> [ 2866.132281] [<ffffffff8190f7ea>] tcp_write_xmit+0x7de/0x8e4
> [ 2866.132281] [<ffffffff818a565d>] ? __alloc_skb+0xa0/0x1a1
> [ 2866.132281] [<ffffffff8190f952>] __tcp_push_pending_frames+0x2e/0x8a
> [ 2866.132281] [<ffffffff81904122>] tcp_sendmsg+0xb32/0xcc6
> [ 2866.132281] [<ffffffff819229c2>] inet_sendmsg+0xaa/0xd5
> [ 2866.132281] [<ffffffff81922918>] ? inet_autobind+0x5f/0x5f
> [ 2866.132281] [<ffffffff810ee7f1>] ? trace_clock_local+0x9/0xb
> [ 2866.132281] [<ffffffff8189adab>] sock_sendmsg+0xa3/0xc4
> [ 2866.132281] [<ffffffff810f5de6>] ? rb_reserve_next_event+0x26f/0x2d5
> [ 2866.132281] [<ffffffff8103e6a9>] ? native_sched_clock+0x29/0x6f
> [ 2866.132281] [<ffffffff8103e6f8>] ? sched_clock+0x9/0xd
> [ 2866.132281] [<ffffffff810ee7f1>] ? trace_clock_local+0x9/0xb
> [ 2866.132281] [<ffffffff8189ae03>] kernel_sendmsg+0x37/0x43
> [ 2866.132281] [<ffffffff8199ce49>] xs_send_kvec+0x77/0x80
> [ 2866.132281] [<ffffffff8199cec1>] xs_sendpages+0x6f/0x1a0
> [ 2866.132281] [<ffffffff8107826d>] ? try_to_del_timer_sync+0x55/0x61
> [ 2866.132281] [<ffffffff8199d0d2>] xs_tcp_send_request+0x55/0xf1
> [ 2866.132281] [<ffffffff8199bb90>] xprt_transmit+0x89/0x1db
> [ 2866.132281] [<ffffffff81999bcd>] ? call_connect+0x3c/0x3c
> [ 2866.132281] [<ffffffff81999d92>] call_transmit+0x1c5/0x20e
> [ 2866.132281] [<ffffffff819a0d55>] __rpc_execute+0x6f/0x225
> [ 2866.132281] [<ffffffff81999bcd>] ? call_connect+0x3c/0x3c
> [ 2866.132281] [<ffffffff819a0f33>] rpc_async_schedule+0x28/0x34
> [ 2866.132281] [<ffffffff810835d6>] process_one_work+0x24d/0x47f
> [ 2866.132281] [<ffffffff81083567>] ? process_one_work+0x1de/0x47f
> [ 2866.132281] [<ffffffff819a0f0b>] ? __rpc_execute+0x225/0x225
> [ 2866.132281] [<ffffffff81083a6d>] worker_thread+0x236/0x317
> [ 2866.132281] [<ffffffff81083837>] ? process_scheduled_works+0x2f/0x2f
> [ 2866.132281] [<ffffffff8108b7b8>] kthread+0x9a/0xa2
> [ 2866.132281] [<ffffffff81a12184>] kernel_thread_helper+0x4/0x10
> [ 2866.132281] [<ffffffff81a0a4b0>] ? retint_restore_args+0x13/0x13
> [ 2866.132281] [<ffffffff8108b71e>] ? __init_kthread_worker+0x5a/0x5a
> [ 2866.132281] [<ffffffff81a12180>] ? gs_change+0x13/0x13
> [ 2866.308506] IPv4: Attempt to release TCP socket in state 1 ffff880019ec0000
> [ 2866.309689] =============================================================================
> [ 2866.310254] BUG TCP (Not tainted): Object already free
> [ 2866.310254] -----------------------------------------------------------------------------
> [ 2866.310254]
>
> The bug comes from the fact that timer set in sk_reset_timer() can run
> before we actually do the sock_hold(). socket refcount reaches zero and
> we free the socket too soon.
>
> timer handler is not allowed to reduce socket refcnt if socket is owned
> by the user, or we need to change sk_reset_timer() implementation.
>
> We should take a reference on the socket in case TCP_DELACK_TIMER_DEFERRED
> or TCP_DELACK_TIMER_DEFERRED bit are set in tsq_flags
>
> Also fix a typo in tcp_delack_timer(), where TCP_WRITE_TIMER_DEFERRED
> was used instead of TCP_DELACK_TIMER_DEFERRED.
>
> For consistency, use same socket refcount change for TCP_MTU_REDUCED_DEFERRED,
> even if not fired from a timer.
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Tested-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv4/tcp_ipv4.c | 8 +++++---
> net/ipv4/tcp_output.c | 14 +++++++++-----
> net/ipv4/tcp_timer.c | 6 ++++--
> 3 files changed, 18 insertions(+), 10 deletions(-)
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 7678237..6278a11 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -417,10 +417,12 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
>
> if (code == ICMP_FRAG_NEEDED) { /* PMTU discovery (RFC1191) */
> tp->mtu_info = info;
> - if (!sock_owned_by_user(sk))
> + if (!sock_owned_by_user(sk)) {
> tcp_v4_mtu_reduced(sk);
> - else
> - set_bit(TCP_MTU_REDUCED_DEFERRED, &tp->tsq_flags);
> + } else {
> + if (!test_and_set_bit(TCP_MTU_REDUCED_DEFERRED, &tp->tsq_flags))
> + sock_hold(sk);
> + }
> goto out;
> }
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 20dfd89..d046326 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -910,14 +910,18 @@ void tcp_release_cb(struct sock *sk)
> if (flags & (1UL << TCP_TSQ_DEFERRED))
> tcp_tsq_handler(sk);
>
> - if (flags & (1UL << TCP_WRITE_TIMER_DEFERRED))
> + if (flags & (1UL << TCP_WRITE_TIMER_DEFERRED)) {
> tcp_write_timer_handler(sk);
> -
> - if (flags & (1UL << TCP_DELACK_TIMER_DEFERRED))
> + __sock_put(sk);
> + }
> + if (flags & (1UL << TCP_DELACK_TIMER_DEFERRED)) {
> tcp_delack_timer_handler(sk);
> -
> - if (flags & (1UL << TCP_MTU_REDUCED_DEFERRED))
> + __sock_put(sk);
> + }
> + if (flags & (1UL << TCP_MTU_REDUCED_DEFERRED)) {
> sk->sk_prot->mtu_reduced(sk);
> + __sock_put(sk);
> + }
> }
> EXPORT_SYMBOL(tcp_release_cb);
>
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index 6df36ad..b774a03 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -252,7 +252,8 @@ static void tcp_delack_timer(unsigned long data)
> inet_csk(sk)->icsk_ack.blocked = 1;
> NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_DELAYEDACKLOCKED);
> /* deleguate our work to tcp_release_cb() */
> - set_bit(TCP_WRITE_TIMER_DEFERRED, &tcp_sk(sk)->tsq_flags);
> + if (!test_and_set_bit(TCP_DELACK_TIMER_DEFERRED, &tcp_sk(sk)->tsq_flags))
> + sock_hold(sk);
> }
> bh_unlock_sock(sk);
> sock_put(sk);
> @@ -481,7 +482,8 @@ static void tcp_write_timer(unsigned long data)
> tcp_write_timer_handler(sk);
> } else {
> /* deleguate our work to tcp_release_cb() */
> - set_bit(TCP_WRITE_TIMER_DEFERRED, &tcp_sk(sk)->tsq_flags);
> + if (!test_and_set_bit(TCP_WRITE_TIMER_DEFERRED, &tcp_sk(sk)->tsq_flags))
> + sock_hold(sk);
> }
> bh_unlock_sock(sk);
> sock_put(sk);
>
^ permalink raw reply
* Re: [iproute2][PATCH] utils: invarg: msg precedes the faulty arg
From: Li Wei @ 2012-08-21 0:54 UTC (permalink / raw)
To: Dan Kenigsberg; +Cc: netdev, Stephen Hemminger
In-Reply-To: <1345119956-16863-1-git-send-email-danken@redhat.com>
On 08/16/2012 08:25 PM, Dan Kenigsberg wrote:
> fix all call which reversed the arg order.
To send a patch for iproute2, you'd better to or cc the
maintainer(Stephen Hemminger <shemminger@vyatta.com>).
Thanks
>
> Signed-off-by: Dan Kenigsberg <danken@redhat.com>
> ---
> ip/ip.c | 2 +-
> ip/ipaddress.c | 2 +-
> tc/tc_class.c | 10 +++++-----
> tc/tc_filter.c | 12 ++++++------
> tc/tc_qdisc.c | 4 ++--
> 5 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/ip/ip.c b/ip/ip.c
> index 20dc3b5..4e8ac5c 100644
> --- a/ip/ip.c
> +++ b/ip/ip.c
> @@ -188,7 +188,7 @@ int main(int argc, char **argv)
> else if (strcmp(argv[1], "help") == 0)
> usage();
> else
> - invarg(argv[1], "invalid protocol family");
> + invarg("invalid protocol family", argv[1]);
> } else if (strcmp(opt, "-4") == 0) {
> preferred_family = AF_INET;
> } else if (strcmp(opt, "-6") == 0) {
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index 69a63b3..cbff143 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -1147,7 +1147,7 @@ static int ipaddr_modify(int cmd, int flags, int argc, char **argv)
> unsigned scope = 0;
> NEXT_ARG();
> if (rtnl_rtscope_a2n(&scope, *argv))
> - invarg(*argv, "invalid scope value.");
> + invarg("invalid scope value.", *argv);
> req.ifa.ifa_scope = scope;
> scoped = 1;
> } else if (strcmp(*argv, "dev") == 0) {
> diff --git a/tc/tc_class.c b/tc/tc_class.c
> index de18fd1..95bf615 100644
> --- a/tc/tc_class.c
> +++ b/tc/tc_class.c
> @@ -74,7 +74,7 @@ int tc_class_modify(int cmd, unsigned flags, int argc, char **argv)
> if (req.t.tcm_handle)
> duparg("classid", *argv);
> if (get_tc_classid(&handle, *argv))
> - invarg(*argv, "invalid class ID");
> + invarg("invalid class ID", *argv);
> req.t.tcm_handle = handle;
> } else if (strcmp(*argv, "handle") == 0) {
> fprintf(stderr, "Error: try \"classid\" instead of \"handle\"\n");
> @@ -91,7 +91,7 @@ int tc_class_modify(int cmd, unsigned flags, int argc, char **argv)
> if (req.t.tcm_parent)
> duparg("parent", *argv);
> if (get_tc_classid(&handle, *argv))
> - invarg(*argv, "invalid parent ID");
> + invarg("invalid parent ID", *argv);
> req.t.tcm_parent = handle;
> } else if (matches(*argv, "estimator") == 0) {
> if (parse_estimator(&argc, &argv, &est))
> @@ -252,13 +252,13 @@ int tc_class_list(int argc, char **argv)
> if (filter_qdisc)
> duparg("qdisc", *argv);
> if (get_qdisc_handle(&filter_qdisc, *argv))
> - invarg(*argv, "invalid qdisc ID");
> + invarg("invalid qdisc ID", *argv);
> } else if (strcmp(*argv, "classid") == 0) {
> NEXT_ARG();
> if (filter_classid)
> duparg("classid", *argv);
> if (get_tc_classid(&filter_classid, *argv))
> - invarg(*argv, "invalid class ID");
> + invarg("invalid class ID", *argv);
> } else if (strcmp(*argv, "root") == 0) {
> if (t.tcm_parent) {
> fprintf(stderr, "Error: \"root\" is duplicate parent ID\n");
> @@ -271,7 +271,7 @@ int tc_class_list(int argc, char **argv)
> duparg("parent", *argv);
> NEXT_ARG();
> if (get_tc_classid(&handle, *argv))
> - invarg(*argv, "invalid parent ID");
> + invarg("invalid parent ID", *argv);
> t.tcm_parent = handle;
> } else if (matches(*argv, "help") == 0) {
> usage();
> diff --git a/tc/tc_filter.c b/tc/tc_filter.c
> index 04c3b82..c9e09d8 100644
> --- a/tc/tc_filter.c
> +++ b/tc/tc_filter.c
> @@ -93,7 +93,7 @@ int tc_filter_modify(int cmd, unsigned flags, int argc, char **argv)
> if (req.t.tcm_parent)
> duparg("parent", *argv);
> if (get_tc_classid(&handle, *argv))
> - invarg(*argv, "Invalid parent ID");
> + invarg("Invalid parent ID", *argv);
> req.t.tcm_parent = handle;
> } else if (strcmp(*argv, "handle") == 0) {
> NEXT_ARG();
> @@ -106,14 +106,14 @@ int tc_filter_modify(int cmd, unsigned flags, int argc, char **argv)
> if (prio)
> duparg("priority", *argv);
> if (get_u32(&prio, *argv, 0) || prio > 0xFFFF)
> - invarg(*argv, "invalid priority value");
> + invarg("invalid priority value", *argv);
> } else if (matches(*argv, "protocol") == 0) {
> __u16 id;
> NEXT_ARG();
> if (protocol_set)
> duparg("protocol", *argv);
> if (ll_proto_a2n(&id, *argv))
> - invarg(*argv, "invalid protocol");
> + invarg("invalid protocol", *argv);
> protocol = id;
> protocol_set = 1;
> } else if (matches(*argv, "estimator") == 0) {
> @@ -290,7 +290,7 @@ int tc_filter_list(int argc, char **argv)
> if (t.tcm_parent)
> duparg("parent", *argv);
> if (get_tc_classid(&handle, *argv))
> - invarg(*argv, "invalid parent ID");
> + invarg("invalid parent ID", *argv);
> filter_parent = t.tcm_parent = handle;
> } else if (strcmp(*argv, "handle") == 0) {
> NEXT_ARG();
> @@ -303,7 +303,7 @@ int tc_filter_list(int argc, char **argv)
> if (prio)
> duparg("priority", *argv);
> if (get_u32(&prio, *argv, 0))
> - invarg(*argv, "invalid preference");
> + invarg("invalid preference", *argv);
> filter_prio = prio;
> } else if (matches(*argv, "protocol") == 0) {
> __u16 res;
> @@ -311,7 +311,7 @@ int tc_filter_list(int argc, char **argv)
> if (protocol)
> duparg("protocol", *argv);
> if (ll_proto_a2n(&res, *argv))
> - invarg(*argv, "invalid protocol");
> + invarg("invalid protocol", *argv);
> protocol = res;
> filter_protocol = protocol;
> } else if (matches(*argv, "help") == 0) {
> diff --git a/tc/tc_qdisc.c b/tc/tc_qdisc.c
> index 3f932a7..c8d7335 100644
> --- a/tc/tc_qdisc.c
> +++ b/tc/tc_qdisc.c
> @@ -83,7 +83,7 @@ int tc_qdisc_modify(int cmd, unsigned flags, int argc, char **argv)
> duparg("handle", *argv);
> NEXT_ARG();
> if (get_qdisc_handle(&handle, *argv))
> - invarg(*argv, "invalid qdisc ID");
> + invarg("invalid qdisc ID", *argv);
> req.t.tcm_handle = handle;
> } else if (strcmp(*argv, "root") == 0) {
> if (req.t.tcm_parent) {
> @@ -111,7 +111,7 @@ int tc_qdisc_modify(int cmd, unsigned flags, int argc, char **argv)
> if (req.t.tcm_parent)
> duparg("parent", *argv);
> if (get_tc_classid(&handle, *argv))
> - invarg(*argv, "invalid parent ID");
> + invarg("invalid parent ID", *argv);
> req.t.tcm_parent = handle;
> } else if (matches(*argv, "estimator") == 0) {
> if (parse_estimator(&argc, &argv, &est))
^ permalink raw reply
* Re: [PATCH] tc-tbf.8: Add parameter range to man page.
From: Li Wei @ 2012-08-21 0:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20120820105803.2ce45a2a@nehalam.linuxnetplumber.net>
On 08/21/2012 01:58 AM, Stephen Hemminger wrote:
>
>>
>> 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.
>>
>
> Rather than putting range on each parameter on every sub-page of tc man
> page. Why not put something in tc.8 under UNITS.
>
> The following implies everything is floating-point which it isn't:
>
> UNITS
> All parameters accept a floating point number, possibly followed by a
> unit.
>
> I would like this section broken down to cover all the generic types
> PARAMETERS
> RATES
> TIMES
> SIZES
> VALUES
>
> Also needs to explain IEC units here.
>
>
>
Thanks Stephen, I got it and will try to work it out.
^ permalink raw reply
* [PATCH 1/1] ipv4: ipmr_expire_timer causes crash when removing net namespace
From: Francesco Ruggeri @ 2012-08-21 0:15 UTC (permalink / raw)
To: netdev; +Cc: Eric W. Biederman, Francesco Ruggeri
In ipv4 mr_table's are freed without checking if their
ipmr_expire_timer is active.
This patch applies to ipv4 the same logic as in ipv6 and deletes the
timer and performs other cleanups before the structure is freed.
We have seen mr_table's being freed with their ipmr_expire_timer
active when removing net namespaces, as in the following backtrace:
[<ffffffff813e1f7b>] ipmr_rules_exit+0x9d/0xd9
[<ffffffff8137e435>] ? net_drop_ns+0x39/0x39
[<ffffffff8137e435>] ? net_drop_ns+0x39/0x39
[<ffffffff813e1fe6>] ipmr_net_exit+0x2f/0x34
[<ffffffff8137dd2e>] ops_exit_list+0x25/0x4e
[<ffffffff8137e523>] cleanup_net+0xee/0x180
[<ffffffff81045f16>] process_one_work+0x17e/0x29a
[<ffffffff81046b18>] worker_thread+0xfe/0x182
[<ffffffff81046a1a>] ? manage_workers.clone.19+0x16d/0x16d
[<ffffffff8104a235>] kthread+0x84/0x8c
[<ffffffff81450ce4>] kernel_thread_helper+0x4/0x10
[<ffffffff8104a1b1>] ? kthread_freezable_should_stop+0x41/0x41
[<ffffffff81450ce0>] ? gs_change+0x13/0x13
When this happens unpredictable crashes such as the following one have
occured in run_timer_softirq:
<4>------------[ cut here ]------------
<2>kernel BUG at kernel/timer.c:1085!
<4>invalid opcode: 0000 [#1] SMP
<4>CPU 0
<4>Modules linked in: xt_mark xt_comment macvtap iptable_mangle xt_hl xt_state
xt_limit ipt_REJECT vfat fat loop dummy tulip xt_tcpudp iptable_filter veth
nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc macvlan dm_mirror dm_region_hash
dm_log uinput bonding kvm_intel kvm fuse xt_multiport iptable_nat ip_tables
nf_nat x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 tun 8021q ioatdma
i5k_amb dca sg iTCO_wdt iTCO_vendor_support coretemp shpchp i2c_i801 i5400_edac
edac_core pcspkr serio_raw microcode sr_mod cdrom ehci_hcd uhci_hcd igb
netxen_nic radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core dm_mod
[last unloaded: mperf]
<4>
<4>Pid: 15426, comm: cc1 Not tainted
3.4.8-827282.2012fruggeriArora34.fc14.x86_64 #1 Supermicro X7DWU/X7DWU
<4>RIP: 0010:[<ffffffff8103bffb>] [<ffffffff8103bffb>] cascade+0x56/0x7a
<4>RSP: 0000:ffff8802afc03e10 EFLAGS: 00010082
<4>RAX: 3031003336333530 RBX: ffffffff81d88740 RCX: 00000001015b8d00
<4>RDX: ffff8800b3209028 RSI: ffff8800a9c19028 RDI: ffffffff81d88740
<4>RBP: ffff8802afc03e40 R08: ffff8802afc0d640 R09: ffff8802afc03e38
<4>R10: 0000000000000158 R11: ffffffff81605b25 R12: ffff8802afc03e10
<4>R13: 000000000000000d R14: ffff8802afc03e10 R15: ffff880254f93fd8
<4>FS: 00007f9b63c98720(0000) GS:ffff8802afc00000(0000) knlGS:0000000000000000
<4>CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>CR2: 00007f9b6188f000 CR3: 00000002a10c6000 CR4: 00000000000007e0
<4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>Process cc1 (pid: 15426, threadinfo ffff880254f92000, task ffff8800b90ad7c0)
<4>Stack:
<4> ffff8800a7336028 ffff8800a9c19028 ffffffff81d88740 0000000000000000
<4> ffff8802afc03ea0 ffff880254f93fd8 ffff8802afc03ee0 ffffffff8103c0bb
<4> ffff8802afc0d650 ffff8802afc03e68 ffff880254f93fd8 ffffffff81d8a360
<4>Call Trace:
<4> <IRQ>
<4> [<ffffffff8103c0bb>] run_timer_softirq+0x9c/0x288
<4> [<ffffffff81060cf3>] ? ktime_get+0x59/0x95
<4> [<ffffffff8101b81e>] ? apic_write+0x11/0x13
<4> [<ffffffff81036060>] __do_softirq+0xb6/0x195
<4> [<ffffffff810668a8>] ? tick_program_event+0x1f/0x21
<4> [<ffffffff81450d5c>] call_softirq+0x1c/0x30
<4> [<ffffffff81003d6f>] do_softirq+0x41/0x7e
<4> [<ffffffff810362fd>] irq_exit+0x3f/0x9a
<4> [<ffffffff8101bdc7>] smp_apic_timer_interrupt+0x77/0x85
<4> [<ffffffff8145040a>] apic_timer_interrupt+0x6a/0x70
<4> <EOI>
<4>Code: 89 45 d0 48 8b 46 08 48 89 45 d8 4c 89 30 48 89 36 48 89 76 08 48 8b
75 d0 4c 8b 26 eb 1e 48 8b 46 18 48 83 e0 fe 48 39 c3 74 02 <0f> 0b 48 89 df e8
c8 e4 ff ff 4c 89 e6 4d 8b 24 24 4c 39 f6 75
<1>RIP [<ffffffff8103bffb>] cascade+0x56/0x7a
<4> RSP <ffff8802afc03e10>
Tested in Linux 3.4.8.
Signed-off-by: Francesco Ruggeri <fruggeri@aristanetworks.com>
Index: linux-3.4.x86_64/net/ipv4/ipmr.c
===================================================================
--- linux-3.4.x86_64.orig/net/ipv4/ipmr.c
+++ linux-3.4.x86_64/net/ipv4/ipmr.c
@@ -124,6 +124,8 @@ static DEFINE_SPINLOCK(mfc_unres_lock);
static struct kmem_cache *mrt_cachep __read_mostly;
static struct mr_table *ipmr_new_table(struct net *net, u32 id);
+static void ipmr_free_table(struct mr_table *mrt);
+
static int ip_mr_forward(struct net *net, struct mr_table *mrt,
struct sk_buff *skb, struct mfc_cache *cache,
int local);
@@ -131,6 +133,7 @@ static int ipmr_cache_report(struct mr_t
struct sk_buff *pkt, vifi_t vifi, int assert);
static int __ipmr_fill_mroute(struct mr_table *mrt, struct sk_buff *skb,
struct mfc_cache *c, struct rtmsg *rtm);
+static void mroute_clean_tables(struct mr_table *mrt);
static void ipmr_expire_process(unsigned long arg);
#ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
@@ -271,7 +274,7 @@ static void __net_exit ipmr_rules_exit(s
list_for_each_entry_safe(mrt, next, &net->ipv4.mr_tables, list) {
list_del(&mrt->list);
- kfree(mrt);
+ ipmr_free_table(mrt);
}
fib_rules_unregister(net->ipv4.mr_rules_ops);
}
@@ -299,7 +302,7 @@ static int __net_init ipmr_rules_init(st
static void __net_exit ipmr_rules_exit(struct net *net)
{
- kfree(net->ipv4.mrt);
+ ipmr_free_table(net->ipv4.mrt);
}
#endif
@@ -336,6 +339,13 @@ static struct mr_table *ipmr_new_table(s
return mrt;
}
+static void ipmr_free_table(struct mr_table *mrt)
+{
+ del_timer(&mrt->ipmr_expire_timer);
+ mroute_clean_tables(mrt);
+ kfree(mrt);
+}
+
/* Service routines creating virtual interfaces: DVMRP tunnels and PIMREG */
static void ipmr_del_tunnel(struct net_device *dev, struct vifctl *v)
^ permalink raw reply
* Re: [PATCH 3/3] netfilter: replace list_for_each_continue_rcu with new interface
From: Paul E. McKenney @ 2012-08-21 0:02 UTC (permalink / raw)
To: Michael Wang
Cc: LKML, netdev@vger.kernel.org, netfilter, coreteam,
netfilter-devel, David Miller, kaber, pablo
In-Reply-To: <502DC9A3.2070703@linux.vnet.ibm.com>
On Fri, Aug 17, 2012 at 12:33:39PM +0800, Michael Wang wrote:
> From: Michael Wang <wangyun@linux.vnet.ibm.com>
>
> This patch replaces list_for_each_continue_rcu() with
> list_for_each_entry_continue_rcu() to allow removing
> list_for_each_continue_rcu().
>
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> net/netfilter/core.c | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/core.c b/net/netfilter/core.c
> index e19f365..50225bd 100644
> --- a/net/netfilter/core.c
> +++ b/net/netfilter/core.c
> @@ -131,14 +131,14 @@ unsigned int nf_iterate(struct list_head *head,
> int hook_thresh)
> {
> unsigned int verdict;
> + struct nf_hook_ops *elem = list_entry_rcu(*i,
> + struct nf_hook_ops, list);
>
> /*
> * The caller must not block between calls to this
> * function because of risk of continuing from deleted element.
> */
> - list_for_each_continue_rcu(*i, head) {
> - struct nf_hook_ops *elem = (struct nf_hook_ops *)*i;
> -
> + list_for_each_entry_continue_rcu(elem, head, list) {
> if (hook_thresh > elem->priority)
> continue;
>
> @@ -155,11 +155,14 @@ repeat:
> continue;
> }
> #endif
> - if (verdict != NF_REPEAT)
> + if (verdict != NF_REPEAT) {
> + *i = &elem->list;
> return verdict;
> + }
> goto repeat;
> }
> }
> + *i = &elem->list;
> return NF_ACCEPT;
> }
>
> --
> 1.7.4.1
>
>
^ permalink raw reply
* Re: regression with poll(2)
From: Andrew Morton @ 2012-08-20 23:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Mel Gorman, Sage Weil, davem, netdev, linux-kernel, ceph-devel,
neilb, a.p.zijlstra, michaelc, emunson, sebastian, cl, torvalds
In-Reply-To: <1345455059.5158.302.camel@edumazet-glaptop>
On Mon, 20 Aug 2012 11:30:59 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-08-20 at 10:04 +0100, Mel Gorman wrote:
>
> > 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.
> >
> > -
>
> This seems to help here.
>
> Boot your machine with "mem=768M" or a bit less depending on your setup,
> and try a netperf.
>
> -> before patch :
>
> # netperf
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> localhost.localdomain () port 0 AF_INET
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 14.00 6.05
>
> -> after patch :
>
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.00 18509.73
"seem to help"? Was previous performance fully restored?
^ permalink raw reply
* Re: [RFC PATCH 1/1] fair.c: Add/Export find_idlest_perfer_cpu API
From: Shirley Ma @ 2012-08-20 22:17 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, mingo, Michael S. Tsirkin, netdev, sri, vivek
In-Reply-To: <1345464035.23018.38.camel@twins>
On Mon, 2012-08-20 at 14:00 +0200, Peter Zijlstra wrote:
> On Fri, 2012-08-17 at 12:46 -0700, Shirley Ma wrote:
> > Add/Export a new API for per-cpu thread model networking device
> driver
> > to choose a preferred idlest cpu within allowed cpumask.
> >
> > The receiving CPUs of a networking device are not under cgroup
> controls.
> > Normally the receiving work will be scheduled on the cpu on which
> the
> > interrupts are received. When such a networking device uses per-cpu
> > thread model, the cpu which is chose to process the packets might
> not be
> > part of cgroup cpusets without using such an API here.
> >
> > On NUMA system, by using the preferred cpumask from the same NUMA
> node
> > would help to reduce expensive cross memory access to/from the other
> > NUMA node.
> >
> > KVM per-cpu vhost will be the first one to use this API. Any other
> > device driver which uses per-cpu thread model and has cgroup cpuset
> > control will use this API later.
>
> How often will this be called and how do you obtain the cpumasks
> provided to the function?
It depends. It might be called pretty often if the user keeps changing
cgroups control cpuset. It might be less called if the cgroups control
cpuset is stable, and the host scheduler always schedules the work on
the same NUMA node.
The preferred cpumasks are obtained from local numa node. The allowed
cpumasks are obtained from caller's task allowed cpumasks (cgroups
control cpuset).
Thanks
Shirley
^ permalink raw reply
* Re: RFC - document network device carrier management
From: Ben Hutchings @ 2012-08-20 21:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20120815085827.2b252094@nehalam.linuxnetplumber.net>
On Wed, 2012-08-15 at 08:58 -0700, Stephen Hemminger wrote:
> Since carrier handling is often done incorrectly by new device drivers
> be explicit about carrier handling API.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> This is a meant as starting point for discussion, it's probably wrong as is.
> Since this isn't code, it could be applied for 3.6 and doesn't need for net-next.
>
>
> --- a/Documentation/networking/netdevices.txt 2012-06-22 08:27:46.729168196 -0700
> +++ b/Documentation/networking/netdevices.txt 2012-08-15 08:56:31.120429994 -0700
> @@ -45,6 +45,36 @@ drop, truncate, or pass up oversize pack
> packets is preferred.
>
>
> +CARRIER
> +=======
> +Most network devices have an operational state that the device
> +monitors. The Linux kernel uses the name "carrier" for this flag which
> +is a historical reference to old modems. Carrier is reported to
> +userspace via the IFF_RUNNING flag from SIOCGIFFLAGS ioctl.
> +Carrier is controlled in the device driver
> +by the functions netif_carrier_on and netif_carrier_off. These
> +functions trigger the necessary netlink and userspace API changes;
> +device drivers must not change netdevice->flags directly.
> +
> +The carrier defaults to ON when the device is created and registered.
> +Simple devices (such as dummy) do not need to do anything.
> +Ethernet style devices should:
> + * alloc_etherdev in probe routine
> + * call netif_carrier_off
> + * register network device
> + * start auto negotiation with phy in open routine
Auto-negotiation is only one of several stages of link setup, and of
course is not used in all Ethernet physical layers. I think the
important point is that once the ndo_open method returns the hardware
and driver should be ready to set up the link and report this state
whenever a suitable partner is physically connected.
> + * call netif_carrier_on when link is up
> +
> +More complex RFC2863 style operational state is also possible
> +but not required (see operstates.txt).
Drivers are not allowed to set operstate directly.
> +The monitoring of link state is the responsibility of the network
> +device driver. It can be done by polling, interrupt, or any other
> +mechanism. netif_carrier_on/netif_carrier_off are atomic and can
> +safely be called by an interrupt routine. Carrier events are
> +managed by the linkwatch work queue and limited to one per second
> +to avoid overwhelming management applications.
> +
> struct net_device synchronization rules
> =======================================
> ndo_open:
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next] net: Set device operstate at registration time
From: Ben Hutchings @ 2012-08-20 21:16 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Ilya Shchepetkov, bjorn, Michael Marineau
The operstate of a device is initially IF_OPER_UNKNOWN and is updated
asynchronously by linkwatch after each change of carrier state
reported by the driver. The default carrier state of a net device is
on, and this will never be changed on drivers that do not support
carrier detection, thus the operstate remains IF_OPER_UNKNOWN.
For devices that do support carrier detection, the driver must set the
carrier state to off initially, then poll the hardware state when the
device is opened. However, we must not activate linkwatch for a
unregistered device, and commit b473001 ('net: Do not fire linkwatch
events until the device is registered.') ensured that we don't. But
this means that the operstate for many devices that support carrier
detection remains IF_OPER_UNKNOWN when it should be IF_OPER_DOWN.
The same issue exists with the dormant state.
The proper initialisation sequence, avoiding a race with opening of
the device, is:
rtnl_lock();
rc = register_netdevice(dev);
if (rc)
goto out_unlock;
netif_carrier_off(dev); /* or netif_dormant_on(dev) */
rtnl_unlock();
but it seems silly that this should have to be repeated in so many
drivers. Further, the operstate seen immediately after opening the
device may still be IF_OPER_UNKNOWN due to the asynchronous nature of
linkwatch.
Commit 22604c8 ('net: Fix for initial link state in 2.6.28') attempted
to fix this by setting the operstate synchronously, but it was
reverted as it could lead to deadlock.
This initialises the operstate synchronously at registration time
only.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
This seems to deal properly with the registration-time problem, but not
the case where a device is brought down and then up again. Many but not
all drivers that support carrier detection call netif_carrier_off() in
their ndo_stop method. Should the others be changed, or is there some
way we can make that automatic?
Ben.
include/linux/netdevice.h | 1 +
net/core/dev.c | 2 ++
net/core/link_watch.c | 8 ++++++++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 1d6ab69..72ae4cf 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2224,6 +2224,7 @@ static inline void dev_hold(struct net_device *dev)
* kind of lower layer not just hardware media.
*/
+extern void linkwatch_init_dev(struct net_device *dev);
extern void linkwatch_fire_event(struct net_device *dev);
extern void linkwatch_forget_dev(struct net_device *dev);
diff --git a/net/core/dev.c b/net/core/dev.c
index ce1bccb..2baeceb 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5639,6 +5639,8 @@ int register_netdevice(struct net_device *dev)
set_bit(__LINK_STATE_PRESENT, &dev->state);
+ linkwatch_init_dev(dev);
+
dev_init_scheduler(dev);
dev_hold(dev);
list_netdevice(dev);
diff --git a/net/core/link_watch.c b/net/core/link_watch.c
index c3519c6..a019222 100644
--- a/net/core/link_watch.c
+++ b/net/core/link_watch.c
@@ -76,6 +76,14 @@ static void rfc2863_policy(struct net_device *dev)
}
+void linkwatch_init_dev(struct net_device *dev)
+{
+ /* Handle pre-registration link state changes */
+ if (!netif_carrier_ok(dev) || netif_dormant(dev))
+ rfc2863_policy(dev);
+}
+
+
static bool linkwatch_urgent_event(struct net_device *dev)
{
if (!netif_running(dev))
--
1.7.7.6
^ permalink raw reply related
* Re: 3.5.1 fib_rules_lookup oops
From: Andi Kleen @ 2012-08-20 20:35 UTC (permalink / raw)
To: Dave Jones; +Cc: Eric Dumazet, netdev, Fedora Kernel Team
In-Reply-To: <20120820172240.GA378@redhat.com>
Dave Jones <davej@redhat.com> writes:
>
> Same user reported a slew of other problems, so he may have bad hardware.
> I've asked him to run a memtest to rule that out.
Bad DIMM is unlikely to cause random ASCII in memory. That's more like a
bad DMA or a buffer overflow in some driver. I would look for a unique
driver that user is using.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply
* Re: [RFC Patch net-next] ipv6: unify conntrack reassembly expire code with standard one
From: Michal Kubecek @ 2012-08-20 20:21 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, Herbert Xu, David S. Miller, Hideaki YOSHIFUJI,
Patrick McHardy, Shan Wei, Pablo Neira Ayuso, netfilter-devel
In-Reply-To: <1345453599.22373.9.camel@cr0>
On Mon, Aug 20, 2012 at 05:06:39PM +0800, Cong Wang wrote:
> 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.
This would work but one would have to check carefully that the pointer
is always set to an usable value. Or we could just add a flag indicating
whether the structure is embedded (and if it is not, use init_net).
Another approach was suggested in the patchworks discussion: add a
special namespace for IPv6 conntrack fragment handling.
> Thanks for testing! I tried to test it too, but seems I can't trigger a
> defragment. Any hints?
I used netfilter on a computer between source and destination of the
packets (generated with "ping6 -s 3000"):
ip6tables -A FORWARD -o ... -m frag --fragid 0:0xFFFFFFFF --fraglast -j DROP
The --fragid condition is needed to work around a bug in iptables (if
frag module is loaded and there is no --fragid, only packets with zero
fragment id match - patch for this is already in git). On the target,
packet is defragmented automatically, by default by the "normal" code,
with nf_conntrack_ipv6 module by the conntrack code.
Setting
echo 5 >/proc/sys/net/ipv6/ip6frag_time
echo 5 >/proc/sys/net/netfilter/nf_conntrack_frag6_timeout
on target also helps.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH iproute2 2/2] em_canid: Ematch used to classify CAN frames according to their identifiers
From: Stephen Hemminger @ 2012-08-20 20:13 UTC (permalink / raw)
To: Rostislav Lisovy; +Cc: netdev, linux-can, pisa, sojkam1
In-Reply-To: <1343745981-14248-2-git-send-email-lisovy@gmail.com>
On Tue, 31 Jul 2012 16:46:21 +0200
Rostislav Lisovy <lisovy@gmail.com> wrote:
> This ematch enables effective filtering of CAN frames (AF_CAN) based
> on CAN identifiers with masking of compared bits. Implementation
> utilizes bitmap based classification for standard frame format (SFF)
> which is optimized for minimal overhead.
>
> Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
Since this doesn't have any conflicts (unlike other CAN filtering),
I applied it for 3.6 version.
^ permalink raw reply
* Re: [PATCH iproute2 v2 0/3] CAN Filter/Classifier
From: Stephen Hemminger @ 2012-08-20 20:06 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, linux-can, lartc, pisa, sojkam1, lisovy
In-Reply-To: <1343383363-6174-1-git-send-email-mkl@pengutronix.de>
On Fri, 27 Jul 2012 12:02:40 +0200
Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> Hello,
>
> I'm reposting Rostislav's iproute2 patches, as Stephen requested,
> during the v3.6 merge window with the corresponding kernel patches
> already applied.
>
> Changes since v1:
> - use can.h generated by 'make headers_install' (tnx Stephen)
> - remove some trailing whitespace
>
> Now Rostislav original introduction message:
>
> ---
>
> This classifier classifies CAN frames (AF_CAN) according to their
> identifiers. This functionality can not be easily achieved with
> existing classifiers, such as u32. This classifier can be used
> with any available qdisc and it is able to classify both SFF
> or EFF frames.
>
> The filtering rules for EFF frames are stored in an array, which
> is traversed during classification. A bitmap is used to store SFF
> rules -- one bit for each ID.
>
> More info about the project:
> http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
>
> ---
>
> The following changes since commit fa1f7441a94670ecf5cbf8eb2ee19173437b5127:
>
> Remove reference to multipath algorithms in usage (2012-07-26 16:12:20 -0700)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-can/iproute2.git for-stephen
>
If your changes work with 3.6 then please rebase your patches on current iproute2 tree.
Note: do not include changes to include/linux which now includes can.h
and matches 3.6-rc2.
^ permalink raw reply
* Re: [PATCH] iproute: Fix errno propagation from rtnl_talk
From: Stephen Hemminger @ 2012-08-20 19:55 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Stephen Hemminger, Linux Netdev List
In-Reply-To: <5031F088.1030404@parallels.com>
On Mon, 20 Aug 2012 12:08:40 +0400
Pavel Emelyanov <xemul@parallels.com> wrote:
> 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;
> }
Applied
^ permalink raw reply
* [PATCH] [v2] net/fsl: introduce Freescale 10G MDIO driver
From: Timur Tabi @ 2012-08-20 19:26 UTC (permalink / raw)
To: David Miller, netdev, Andy Fleming, romieu
Similar to fsl_pq_mdio.c, this driver is for the 10G MDIO controller on
Freescale Frame Manager Ethernet controllers.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
v2: add register polling helper functions, clean up messages
drivers/net/ethernet/freescale/Kconfig | 7 +
drivers/net/ethernet/freescale/Makefile | 1 +
drivers/net/ethernet/freescale/xgmac_mdio.c | 274 +++++++++++++++++++++++++++
3 files changed, 282 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/ethernet/freescale/xgmac_mdio.c
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 3574e14..feff516 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -62,6 +62,13 @@ config FSL_PQ_MDIO
---help---
This driver supports the MDIO bus used by the gianfar and UCC drivers.
+config FSL_XGMAC_MDIO
+ tristate "Freescale XGMAC MDIO"
+ depends on FSL_SOC
+ select PHYLIB
+ ---help---
+ This driver supports the MDIO bus on the Fman 10G Ethernet MACs.
+
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
diff --git a/drivers/net/ethernet/freescale/Makefile b/drivers/net/ethernet/freescale/Makefile
index 1752488..3d1839a 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -9,6 +9,7 @@ ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
endif
obj-$(CONFIG_FS_ENET) += fs_enet/
obj-$(CONFIG_FSL_PQ_MDIO) += fsl_pq_mdio.o
+obj-$(CONFIG_FSL_XGMAC_MDIO) += xgmac_mdio.o
obj-$(CONFIG_GIANFAR) += gianfar_driver.o
obj-$(CONFIG_PTP_1588_CLOCK_GIANFAR) += gianfar_ptp.o
gianfar_driver-objs := gianfar.o \
diff --git a/drivers/net/ethernet/freescale/xgmac_mdio.c b/drivers/net/ethernet/freescale/xgmac_mdio.c
new file mode 100644
index 0000000..1afb5ea
--- /dev/null
+++ b/drivers/net/ethernet/freescale/xgmac_mdio.c
@@ -0,0 +1,274 @@
+/*
+ * QorIQ 10G MDIO Controller
+ *
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Authors: Andy Fleming <afleming@freescale.com>
+ * Timur Tabi <timur@freescale.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+#include <linux/mdio.h>
+#include <linux/of_platform.h>
+#include <linux/of_mdio.h>
+
+/* Number of microseconds to wait for a register to respond */
+#define TIMEOUT 1000
+
+struct tgec_mdio_controller {
+ __be32 reserved[12];
+ __be32 mdio_stat; /* MDIO configuration and status */
+ __be32 mdio_ctl; /* MDIO control */
+ __be32 mdio_data; /* MDIO data */
+ __be32 mdio_addr; /* MDIO address */
+} __packed;
+
+#define MDIO_STAT_CLKDIV(x) (((x>>1) & 0xff) << 8)
+#define MDIO_STAT_BSY (1 << 0)
+#define MDIO_STAT_RD_ER (1 << 1)
+#define MDIO_CTL_DEV_ADDR(x) (x & 0x1f)
+#define MDIO_CTL_PORT_ADDR(x) ((x & 0x1f) << 5)
+#define MDIO_CTL_PRE_DIS (1 << 10)
+#define MDIO_CTL_SCAN_EN (1 << 11)
+#define MDIO_CTL_POST_INC (1 << 14)
+#define MDIO_CTL_READ (1 << 15)
+
+#define MDIO_DATA(x) (x & 0xffff)
+#define MDIO_DATA_BSY (1 << 31)
+
+/*
+ * Wait untill the MDIO bus is free
+ */
+static int xgmac_wait_until_free(struct device *dev,
+ struct tgec_mdio_controller __iomem *regs)
+{
+ uint32_t status;
+
+ /* Wait till the bus is free */
+ status = spin_event_timeout(
+ !((in_be32(®s->mdio_stat)) & MDIO_STAT_BSY), TIMEOUT, 0);
+ if (!status) {
+ dev_err(dev, "timeout waiting for bus to be free\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+/*
+ * Wait till the MDIO read or write operation is complete
+ */
+static int xgmac_wait_until_done(struct device *dev,
+ struct tgec_mdio_controller __iomem *regs)
+{
+ uint32_t status;
+
+ /* Wait till the MDIO write is complete */
+ status = spin_event_timeout(
+ !((in_be32(®s->mdio_data)) & MDIO_DATA_BSY), TIMEOUT, 0);
+ if (!status) {
+ dev_err(dev, "timeout waiting for operation to complete\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+/*
+ * Write value to the PHY for this device to the register at regnum,waiting
+ * until the write is done before it returns. All PHY configuration has to be
+ * done through the TSEC1 MIIM regs.
+ */
+static int xgmac_mdio_write(struct mii_bus *bus, int phy_id, int regnum, u16 value)
+{
+ struct tgec_mdio_controller __iomem *regs = bus->priv;
+ uint16_t dev_addr = regnum >> 16;
+ int ret;
+
+ /* Setup the MII Mgmt clock speed */
+ out_be32(®s->mdio_stat, MDIO_STAT_CLKDIV(100));
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Set the port and dev addr */
+ out_be32(®s->mdio_ctl,
+ MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr));
+
+ /* Set the register address */
+ out_be32(®s->mdio_addr, regnum & 0xffff);
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Write the value to the register */
+ out_be32(®s->mdio_data, MDIO_DATA(value));
+
+ ret = xgmac_wait_until_done(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+/*
+ * Reads from register regnum in the PHY for device dev, returning the value.
+ * Clears miimcom first. All PHY configuration has to be done through the
+ * TSEC1 MIIM regs.
+ */
+static int xgmac_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
+{
+ struct tgec_mdio_controller __iomem *regs = bus->priv;
+ uint16_t dev_addr = regnum >> 16;
+ uint32_t mdio_ctl;
+ uint16_t value;
+ int ret;
+
+ /* Setup the MII Mgmt clock speed */
+ out_be32(®s->mdio_stat, MDIO_STAT_CLKDIV(100));
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Set the Port and Device Addrs */
+ mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
+ out_be32(®s->mdio_ctl, mdio_ctl);
+
+ /* Set the register address */
+ out_be32(®s->mdio_addr, regnum & 0xffff);
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Initiate the read */
+ out_be32(®s->mdio_ctl, mdio_ctl | MDIO_CTL_READ);
+
+ ret = xgmac_wait_until_done(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Return all Fs if nothing was there */
+ if (in_be32(®s->mdio_stat) & MDIO_STAT_RD_ER) {
+ dev_err(&bus->dev, "MDIO read error\n");
+ return 0xffff;
+ }
+
+ value = in_be32(®s->mdio_data) & 0xffff;
+ dev_dbg(&bus->dev, "read %04x\n", value);
+
+ return value;
+}
+
+/* Reset the MIIM registers, and wait for the bus to free */
+static int xgmac_mdio_reset(struct mii_bus *bus)
+{
+ struct tgec_mdio_controller __iomem *regs = bus->priv;
+ int ret;
+
+ mutex_lock(&bus->mdio_lock);
+
+ /* Setup the MII Mgmt clock speed */
+ out_be32(®s->mdio_stat, MDIO_STAT_CLKDIV(100));
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+
+ mutex_unlock(&bus->mdio_lock);
+
+ return ret;
+}
+
+static int __devinit xgmac_mdio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct mii_bus *bus;
+ struct resource res;
+ int ret;
+
+ ret = of_address_to_resource(np, 0, &res);
+ if (ret) {
+ dev_err(&pdev->dev, "could not obtain address\n");
+ return ret;
+ }
+
+ bus = mdiobus_alloc_size(PHY_MAX_ADDR * sizeof(int));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = "Freescale XGMAC MDIO Bus";
+ bus->read = xgmac_mdio_read;
+ bus->write = xgmac_mdio_write;
+ bus->reset = xgmac_mdio_reset;
+ bus->irq = bus->priv;
+ bus->parent = &pdev->dev;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%llx", (unsigned long long)res.start);
+
+ /* Set the PHY base address */
+ bus->priv = of_iomap(np, 0);
+ if (!bus->priv) {
+ ret = -ENOMEM;
+ goto err_ioremap;
+ }
+
+ ret = of_mdiobus_register(bus, np);
+ if (ret) {
+ dev_err(&pdev->dev, "cannot register MDIO bus\n");
+ goto err_registration;
+ }
+
+ dev_set_drvdata(&pdev->dev, bus);
+
+ return 0;
+
+err_registration:
+ iounmap(bus->priv);
+
+err_ioremap:
+ mdiobus_free(bus);
+
+ return ret;
+}
+
+static int __devexit xgmac_mdio_remove(struct platform_device *pdev)
+{
+ struct mii_bus *bus = dev_get_drvdata(&pdev->dev);
+
+ mdiobus_unregister(bus);
+ iounmap(bus->priv);
+ mdiobus_free(bus);
+
+ return 0;
+}
+
+static struct of_device_id xgmac_mdio_match[] = {
+ {
+ .compatible = "fsl,fman-xmdio",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, xgmac_mdio_match);
+
+static struct platform_driver xgmac_mdio_driver = {
+ .driver = {
+ .name = "fsl-fman_xmdio",
+ .of_match_table = xgmac_mdio_match,
+ },
+ .probe = xgmac_mdio_probe,
+ .remove = xgmac_mdio_remove,
+};
+
+module_platform_driver(xgmac_mdio_driver);
+
+MODULE_DESCRIPTION("Freescale QorIQ 10G MDIO Controller");
+MODULE_LICENSE("GPL v2");
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 2/2] [RFC] netlink: fix possible spoofing from non-root processes
From: Pablo Neira Ayuso @ 2012-08-20 19:09 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20120819212327.GA14853@1984>
On Sun, Aug 19, 2012 at 11:23:27PM +0200, Pablo Neira Ayuso wrote:
> On Fri, Aug 17, 2012 at 07:22:29PM +0200, pablo@netfilter.org wrote:
> [...]
> > [ I don't know any FOSS program making use of Netlink to communicate
> > to processes, please, let me know if I'm missing anyone important ]
>
> Patrick pinged me for little reminder on NETLINK_USERSOCK. We still
> have to allow netlink-to-netlink userspace communication for it.
>
> So, please find a new version of this patch that allows non-root
> processes for that Netlink bus. For others, my patch restricts to root
> processes the ability of sending messages with dst_pid != 0.
Sorry, I just noticed that you cannot apply this to your net tree
since it depends on patch 1/2 which is not a fix.
I'll get back to you with one path that you can apply to your net
tree.
I'll resend 1/2 later to net-next once this has been sorted out.
^ permalink raw reply
* Re: [PATCH net-next] packet: Protect packet sk list with mutex
From: Eric Dumazet @ 2012-08-20 19:05 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Linux Netdev List
In-Reply-To: <50327D8A.5010400@parallels.com>
On Mon, 2012-08-20 at 22:10 +0400, Pavel Emelyanov wrote:
> AFAIU now this is the case for e.g. TCP sockets since they can be created in
> rx code. For packet I've found no places where these stats can be modified other
> than those two in af_packet.c
sock_prot_inuse_add() uses __this_cpu_add(), and on non x86, needs to be
safe against preemption ( or irq if applicable)
Changing spin_lock_bh() to mutex_lock() breaks this.
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-20 18:57 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, davem, roland, netdev, ali, sean.hefty,
Erez Shitrit, Doug Ledford
In-Reply-To: <20120812205457.GA14081@redhat.com>
On Sun, Aug 12, 2012 at 11:54:57PM +0300, Michael S. Tsirkin wrote:
> > and remember that
> > this code (VM through eipoib) can talk to any IPoIB element on the
> > fabric, native,
> > virtualized, HW/SW gateways, etc etc.
> >
> > Or.
>
> If you want this, then you really want a limited form of IPoIB bridging.
And to clarify that statement, here is how I would make such
IPoIB "bridging" work:
Guest side:
- Implement virtio-ipoib. This would be a device like virtio-net,
but instead of ethernet packets, it would pass packets
that consist of:
IPoIB destination address
IP packet
- this is passed to/from host without modifications, possibly with addition
of header such as virtio net header
- flags such as broadcast can also be added to header
- like virtio net get capabilities from host and expose
as netdev capabilities
Host side:
- create macvtap -passthrough like device that can sit on top of an
ipoib interface
- expose this device QPN and GID to guest as hardware address
- as we get packet forward it on UD QPN or CM as appropriate
depending on size,checksum and admin preference
- expose capabilities such as TSO
- can expose capability such as max MTU to guest too
Above means hardware address changes with migration.
So we need to notify guest when this happens.
This can be addressed from host by notifying all
neighbours.
Alternatively guest can notify all neighbours.
Notification can be done by broadcast.
This second option seems preferable.
this ipoib-vtap can support two modes
- bridge like mode:
guest to guest and guest to host packets
can be detected by macvtap and passed
to/from guest directly like macvlan bridge mode
- vepa like mode
guest to guest and guest to host packets
are sent out and looped back by IB switch
like macvlan vepa mode
As compared to the custom protocol I sent, it has -
Advantages: interoperates cleanly with ipoib
Disadvantages: no support for legacy (ethernet-only) guest
--
MST
^ permalink raw reply
* Re: Documenting UNIX domain autobind
From: Colin McCabe @ 2012-08-20 18:42 UTC (permalink / raw)
To: linux-man, netdev
> Hello Tetsuo,
>
> I'm the Linux man-pages mainatiner. I write to you because I see that
> you recently (http://kerneltrap.org/mailarchive/linux-netdev/2010/8/30/6284106/thread#mid-6284106)
> did some work patchiing Linux unix_autobind(), so you may know the
> answer to this question. But, also others on the CC may know.
>
> I recently noticed this feature in the kernel, and so added some
> documentation to the unix(7) man page. That text reads as follows:
>
> Autobind Feature
> If a bind() call specifies addrlen as sizeof(sa_family_t), or
> the SO_PASSCRED socket option was specified for a socket that
> was not explicitly bound to an address, then the socket is
> autobound to an abstract address. The address consists of a
> null byte followed by 5 bytes in the character set [0-9a-f].
> (Thus, there is a limit of 2^20 autobind addresses.)
>
> I think this text correctly documents the technical details (but let
> me know if you see errors). What is lacking is an explanation of why
> this feature exists. Is someone able to explain where this feature is
> used and why?
>
> thanks,
>
> Michael
I wasn't involved in developing this feature, but as someone who has
used UNIX domain sockets in the past, I think I can comment on this.
As you know, you have to bind every UNIX domain socket to a unique
identifier. In Linux, this can be either a path or an entry in the
abstract namespace. Either way, if you try to use an identifier that
someone is already using, it won't work. If autobind did not exist,
you could write a loop to try random identifers until you get one that
works. With autobind, you don't have to write this code and risk
getting it wrong.
Another consideration is that autobind gives you a guarantee that
you're not using an identifier that someone else has chosen. Without
this guarantee, it's possible that the random-ish identifer you chose
will conflict with another process on the system. One man's randomly
chosen string is another man's carefully-chosen identifier. Autobind
eliminates this risk completely.
It would be nice to see some discussion in the man pages about the
potential security issues of using UNIX domain sockets. For example,
if you create a UNIX domain socket under /tmp, a malicious process
could move it out of the way and create its own socket there,
effectively performing a man-in-the-middle attack on you. If you
create a socket under /tmp that is named predictably (like
/tmp/my-program-name), a malicious process could create a
denial-of-service by creating a socket or other entry in that
position. These issues can be avoided by using the abstract
namespace, or using a well-known and secure path for UNIX domain
sockets. However, a novice wouldn't necessarily know that he needed
to do that.
cheers,
Colin McCabe
^ permalink raw reply
* Re: [PATCH net-next] packet: Protect packet sk list with mutex
From: Pavel Emelyanov @ 2012-08-20 18:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1345475500.5158.321.camel@edumazet-glaptop>
On 08/20/2012 07:11 PM, Eric Dumazet wrote:
> On Mon, 2012-08-20 at 18:50 +0400, Pavel Emelyanov wrote:
>> In patch eea68e2f (packet: Report socket mclist info via diag module) I've
>> introduced a "scheduling in atomic" problem in packet diag module -- the
>> socket list is traversed under rcu_read_lock() while performed under it sk
>> mclist access requires rtnl lock (i.e. -- mutex) to be taken. Similar thing
>> was then re-introduced by further packet diag patches (fanount mutex and
>> pgvec mutex for rings) :(
>>
>> Apart from being terribly sorry for the above, I propose to change the
>> packet sk list protection from spinlock to mutex. This lock currently
>> protects only the sklist modifications (that already happen in sleeping
>> context) and nothing more.
>>
>> Am I wrong again and a fine-grained atomic locking is required for
>> everything that is reported by packet diag instead?
>>
>> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
>>
>> ---
>>
>> diff --git a/include/net/netns/packet.h b/include/net/netns/packet.h
>> index cb4e894..4780b08 100644
>> --- a/include/net/netns/packet.h
>> +++ b/include/net/netns/packet.h
>> @@ -8,7 +8,7 @@
>> #include <linux/spinlock.h>
>>
>> struct netns_packet {
>> - spinlock_t sklist_lock;
>> + struct mutex sklist_lock;
>> struct hlist_head sklist;
>> };
>>
>> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>> index 226b2cd..5048672 100644
>> --- a/net/packet/af_packet.c
>> +++ b/net/packet/af_packet.c
>> @@ -2308,10 +2308,10 @@ static int packet_release(struct socket *sock)
>> net = sock_net(sk);
>> po = pkt_sk(sk);
>>
>> - spin_lock_bh(&net->packet.sklist_lock);
>> + mutex_lock(&net->packet.sklist_lock);
>> sk_del_node_init_rcu(sk);
>> sock_prot_inuse_add(net, sk->sk_prot, -1);
>
> Last time I checked, sock_prot_inuse_add() needed BH protection.
AFAIU now this is the case for e.g. TCP sockets since they can be created in
rx code. For packet I've found no places where these stats can be modified other
than those two in af_packet.c
> ( This could be relaxed somehow on x86 thanks to this_cpu_add() ... but
> thats another point)
>
> Could you please report the full stack trace ?
Sure:
[152363.820563] BUG: scheduling while atomic: crtools/12517/0x10000002
[152363.820573] 4 locks held by crtools/12517:
[152363.820581] #0: (sock_diag_mutex){+.+.+.}, at: [<ffffffff81a2dcb5>] sock_diag_rcv+0x1f/0x3e
[152363.820613] #1: (sock_diag_table_mutex){+.+.+.}, at: [<ffffffff81a2de70>] sock_diag_rcv_msg+0xdb/0x11a
[152363.820644] #2: (nlk->cb_mutex){+.+.+.}, at: [<ffffffff81a67d01>] netlink_dump+0x23/0x1ab
[152363.820693] #3: (rcu_read_lock){.+.+..}, at: [<ffffffff81b6a049>] packet_diag_dump+0x0/0x1af
[152363.820724] Modules linked in:
[152363.820737] Pid: 12517, comm: crtools Tainted: G W 3.6.0-rc1-46175-g07cbd24-dirty #236
[152363.820750] Call Trace:
[152363.820761] [<ffffffff810959c2>] __schedule_bug+0x6a/0x78
[152363.820772] [<ffffffff81c26cb9>] __schedule+0xb1/0x5b1
[152363.820784] [<ffffffff81098af0>] __cond_resched+0x2a/0x35
[152363.820795] [<ffffffff81c27234>] _cond_resched+0x2c/0x37
[152363.820806] [<ffffffff81c26210>] mutex_lock_nested+0x2a/0x45
[152363.820818] [<ffffffff81a2b81c>] rtnl_lock+0x17/0x19
[152363.820829] [<ffffffff81b69de0>] pdiag_put_mclist+0x4e/0xeb
[152363.820840] [<ffffffff81b6a001>] sk_diag_fill.clone.0+0x14c/0x194
[152363.820851] [<ffffffff81c28545>] ? _raw_read_unlock_bh+0x43/0x47
[152363.820863] [<ffffffff81b6a147>] packet_diag_dump+0xfe/0x1af
[152363.820874] [<ffffffff81b6a049>] ? sk_diag_fill.clone.0+0x194/0x194
[152363.820885] [<ffffffff81a67d4b>] netlink_dump+0x6d/0x1ab
[152363.820896] [<ffffffff81a6847f>] netlink_dump_start+0xed/0x114
[152363.820907] [<ffffffff81b69d89>] packet_diag_handler_dump+0x61/0x6a
[152363.820918] [<ffffffff81b6a049>] ? sk_diag_fill.clone.0+0x194/0x194
[152363.820930] [<ffffffff81a2de8b>] sock_diag_rcv_msg+0xf6/0x11a
[152363.820941] [<ffffffff81a2dd95>] ? sock_diag_register_inet_compat+0x36/0x36
[152363.820953] [<ffffffff81a690a0>] netlink_rcv_skb+0x43/0x94
[152363.820979] [<ffffffff81a2dcc4>] sock_diag_rcv+0x2e/0x3e
[152363.820990] [<ffffffff81a68e4f>] netlink_unicast+0xe9/0x16f
[152363.821002] [<ffffffff81a69601>] netlink_sendmsg+0x1e6/0x204
[152363.821129] [<ffffffff81a0ba29>] ? rcu_read_unlock+0x56/0x67
[152363.821143] [<ffffffff81a06877>] __sock_sendmsg_nosec+0x58/0x61
[152363.821155] [<ffffffff81a072b6>] sock_sendmsg+0x6e/0x87
[152363.821168] [<ffffffff8113a172>] ? might_fault+0xa5/0xac
[152363.821180] [<ffffffff81a138ae>] ? copy_from_user+0x2a/0x2c
[152363.821192] [<ffffffff81a13c9e>] ? verify_iovec+0x54/0xaa
[152363.821204] [<ffffffff81a08092>] __sys_sendmsg+0x211/0x2a7
[152363.821216] [<ffffffff810b7515>] ? lock_release_holdtime+0x2c/0xf5
[152363.821228] [<ffffffff810bba71>] ? __lock_release+0x113/0x12c
[152363.821243] [<ffffffff81c28937>] ? _raw_spin_unlock_irq+0x30/0x4a
[152363.821257] [<ffffffff810bafa6>] ? trace_hardirqs_on_caller+0x123/0x15a
[152363.821272] [<ffffffff810bafea>] ? trace_hardirqs_on+0xd/0xf
[152363.821286] [<ffffffff8116dc31>] ? fcheck_files+0xac/0xea
[152363.821297] [<ffffffff8116ddaa>] ? fget_light+0x3a/0xb9
[152363.821309] [<ffffffff81c27183>] ? __schedule+0x57b/0x5b1
[152363.821320] [<ffffffff81a082ed>] sys_sendmsg+0x42/0x60
[152363.821332] [<ffffffff81c295e9>] system_call_fastpath+0x16/0x1b
>
>
Thank,
Pavel
^ 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