* RE: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement code
From: Himanshu Madhani @ 2013-10-08 22:46 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org, linux390@de.ibm.com,
linux-s390@vger.kernel.org, x86@kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <c92efbde96541d08f37510422c096d543bb01279.1380703263.git.agordeev@redhat.com>
> -----Original Message-----
> From: Alexander Gordeev [mailto:agordeev@redhat.com]
> Sent: Wednesday, October 02, 2013 3:49 AM
> To: linux-kernel
> Cc: Alexander Gordeev; Bjorn Helgaas; Ralf Baechle; Michael Ellerman;
> Benjamin Herrenschmidt; Martin Schwidefsky; Ingo Molnar; Tejun Heo; Dan
> Williams; Andy King; Jon Mason; Matt Porter; linux-pci; linux-mips@linux-
> mips.org; linuxppc-dev@lists.ozlabs.org; linux390@de.ibm.com; linux-
> s390@vger.kernel.org; x86@kernel.org; linux-ide@vger.kernel.org;
> iss_storagedev@hp.com; linux-nvme@lists.infradead.org; linux-
> rdma@vger.kernel.org; netdev; e1000-devel@lists.sourceforge.net; Dept-
> Eng Linux Driver; Solarflare linux maintainers; VMware, Inc.; linux-scsi
> Subject: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement
> code
>
> As result of recent re-design of the MSI/MSI-X interrupts enabling pattern
> this driver has to be updated to use the new technique to obtain a optimal
> number of MSI/MSI-X interrupts required.
>
"We will test this change for the driver and provide feedback."
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Thanks,
Himanshu
^ permalink raw reply
* [PATCH v2 net] pkt_sched: fq: fix non TCP flows pacing
From: Eric Dumazet @ 2013-10-08 22:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Steinar H. Gunderson
In-Reply-To: <1381182269.12191.27.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
Steinar reported FQ pacing was not working for UDP flows.
It looks like the initial sk->sk_pacing_rate value of 0 was
a wrong choice. We should init it to ~0U (unlimited)
Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
no real sense. The default rate is really unlimited, and we
need to avoid a zero divide.
Reported-by: Steinar H. Gunderson <sesse@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
I removed the ACCESS_ONCE() stuff, as it adds conflicts for
next (net / net-next) merge. I'll send a separate patch later.
net/core/sock.c | 1 +
net/sched/sch_fq.c | 20 +++++++++-----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 5b6beba..0b39e7a 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2319,6 +2319,7 @@ void sock_init_data(struct socket *sock, struct sock *sk)
sk->sk_ll_usec = sysctl_net_busy_read;
#endif
+ sk->sk_pacing_rate = ~0U;
/*
* Before updating sk_refcnt, we must commit prior changes to memory
* (Documentation/RCU/rculist_nulls.txt for details)
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 48501a2..a9dfdda 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -472,20 +472,16 @@ begin:
if (f->credit > 0 || !q->rate_enable)
goto out;
- if (skb->sk && skb->sk->sk_state != TCP_TIME_WAIT) {
- rate = skb->sk->sk_pacing_rate ?: q->flow_default_rate;
+ rate = q->flow_max_rate;
+ if (skb->sk && skb->sk->sk_state != TCP_TIME_WAIT)
+ rate = min(skb->sk->sk_pacing_rate, rate);
- rate = min(rate, q->flow_max_rate);
- } else {
- rate = q->flow_max_rate;
- if (rate == ~0U)
- goto out;
- }
- if (rate) {
+ if (rate != ~0U) {
u32 plen = max(qdisc_pkt_len(skb), q->quantum);
u64 len = (u64)plen * NSEC_PER_SEC;
- do_div(len, rate);
+ if (likely(rate))
+ do_div(len, rate);
/* Since socket rate can change later,
* clamp the delay to 125 ms.
* TODO: maybe segment the too big skb, as in commit
@@ -735,12 +731,14 @@ static int fq_dump(struct Qdisc *sch, struct sk_buff *skb)
if (opts == NULL)
goto nla_put_failure;
+ /* TCA_FQ_FLOW_DEFAULT_RATE is not used anymore,
+ * do not bother giving its value
+ */
if (nla_put_u32(skb, TCA_FQ_PLIMIT, sch->limit) ||
nla_put_u32(skb, TCA_FQ_FLOW_PLIMIT, q->flow_plimit) ||
nla_put_u32(skb, TCA_FQ_QUANTUM, q->quantum) ||
nla_put_u32(skb, TCA_FQ_INITIAL_QUANTUM, q->initial_quantum) ||
nla_put_u32(skb, TCA_FQ_RATE_ENABLE, q->rate_enable) ||
- nla_put_u32(skb, TCA_FQ_FLOW_DEFAULT_RATE, q->flow_default_rate) ||
nla_put_u32(skb, TCA_FQ_FLOW_MAX_RATE, q->flow_max_rate) ||
nla_put_u32(skb, TCA_FQ_BUCKETS_LOG, q->fq_trees_log))
goto nla_put_failure;
^ permalink raw reply related
* Re: [PATCH] pkt_sched: fq: fix non TCP flows pacing
From: Eric Dumazet @ 2013-10-08 21:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sesse
In-Reply-To: <20131008.165318.1392122841162708841.davem@davemloft.net>
On Tue, 2013-10-08 at 16:53 -0400, David Miller wrote:
> Is this meant for net or net-next? It doesn't apply cleanly to the
> former.
Oh right, I need to respin for net tree, sorry for the confusion.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: Stephen Hemminger @ 2013-10-08 21:13 UTC (permalink / raw)
To: David Miller; +Cc: yamato, netdev
In-Reply-To: <20131008.152349.729447337097758010.davem@davemloft.net>
On Tue, 08 Oct 2013 15:23:49 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Masatake YAMATO <yamato@redhat.com>
> Date: Fri, 4 Oct 2013 11:34:21 +0900
>
> > ip link has ability to show extra information of net work device if
> > kernel provides sunh information. With this patch veth driver can
> > provide its peer ifindex information to ip command via netlink
> > interface.
> >
> > Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>
> Applied to net-next, thank you.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Please revert this. It is incorrect.
The info returned by any netlink message should be equal to the message
for setting.
I think the correct patch would be something like this (compile tested only).
--- a/drivers/net/veth.c 2013-10-06 14:48:23.806461177 -0700
+++ b/drivers/net/veth.c 2013-10-08 14:11:42.434074690 -0700
@@ -434,6 +434,35 @@ static const struct nla_policy veth_poli
[VETH_INFO_PEER] = { .len = sizeof(struct ifinfomsg) },
};
+static size_t veth_get_size(const struct net_device *dev)
+{
+ return nla_total_size(sizeof(struct ifinfomsg)) + /* VETH_INFO_PEER */
+ 0;
+}
+
+static int veth_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct veth_priv *priv = netdev_priv(dev);
+ struct net_device *peer = rtnl_dereference(priv->peer);
+
+ if (peer) {
+ struct ifinfomsg ifi = {
+ .ifi_family = AF_UNSPEC,
+ .ifi_type = peer->type,
+ .ifi_index = peer->ifindex,
+ .ifi_flags = dev_get_flags(peer),
+ };
+
+ if (nla_put(skb, VETH_INFO_PEER, sizeof(ifi), &ifi))
+ goto nla_put_failure;
+ }
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
static struct rtnl_link_ops veth_link_ops = {
.kind = DRV_NAME,
.priv_size = sizeof(struct veth_priv),
@@ -443,6 +472,8 @@ static struct rtnl_link_ops veth_link_op
.dellink = veth_dellink,
.policy = veth_policy,
.maxtype = VETH_INFO_MAX,
+ .get_size = veth_get_size,
+ .fill_info = veth_fill_info,
};
/*
^ permalink raw reply
* Re: IPv6 kernel warning
From: Yuchung Cheng @ 2013-10-08 20:53 UTC (permalink / raw)
To: dormando
Cc: Michele Baldessari, Russell King - ARM Linux, netdev,
Neal Cardwell, Nandita Dukkipati
In-Reply-To: <alpine.DEB.2.02.1310081123230.21359@dtop>
On Tue, Oct 8, 2013 at 11:24 AM, dormando <dormando@rydia.net> wrote:
> On Mon, 7 Oct 2013, Yuchung Cheng wrote:
>
>> On Mon, Oct 7, 2013 at 12:56 PM, dormando <dormando@rydia.net> wrote:
>> > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
>> >
>> >> On Mon, Oct 7, 2013 at 11:13 AM, dormando <dormando@rydia.net> wrote:
>> >> >
>> >> > > >
>> >> > > > there's been multiple reports about this one:
>> >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=989251
>> >> > > > http://bugzilla.kernel.org/show_bug.cgi?id=60779
>> >> > > >
>> >> > > > Could you try Yuchung's debug patch?
>> >> > > > http://www.spinics.net/lists/netdev/msg250193.html
>> >> > > Yes it looks like the same bug. Please try that patch to help identify
>> >> > > this elusive bug.
>> >> > >
>> >> >
>> >> > Hi!
>> >> >
>> >> > We get this one a few times a day in production. Here's a warning with
>> >> > your debug trace in the line immediately following:
>> >> > (I censored a few things)
>> >> >
>> >> > [125311.721950] ------------[ cut here ]------------
>> >> > [125311.721961] WARNING: at net/ipv4/tcp_input.c:2776 tcp_fastretrans_alert+0xb58/0xc80()
>> >> > [125311.721962] Modules linked in: bridge ip_vs macvlan coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog microcode ipmi_devintf sb_edac lpc_ich edac_core mfd_core ipmi_si ipmi_msghandler iptable_nat nf_nat_ipv4 nf_nat ixgbe igb mdio i2c_algo_bit ptp pps_core
>> >> > [125311.721981] CPU: 11 PID: 0 Comm: swapper/11 Not tainted 3.10.13 #1
>> >> > [125311.721982] Hardware name: Supermicro XXXXXXXXXXX, BIOS 1.1 10/03/2012
>> >> > [125311.721984] ffffffff81a82007 ffff88407fc63958 ffffffff816bb9cc ffff88407fc63998
>> >> > [125311.721986] ffffffff8104b940 00ff8840ad904f82 ffff883b8a165b00 0000000000004120
>> >> > [125311.721989] 0000000000000001 0000000000000019 0000000000000000 ffff88407fc639a8
>> >> > [125311.721991] Call Trace:
>> >> > [125311.721992] <IRQ> [<ffffffff816bb9cc>] dump_stack+0x19/0x1d
>> >> > [125311.722002] [<ffffffff8104b940>] warn_slowpath_common+0x70/0xa0
>> >> > [125311.722005] [<ffffffff8104b98a>] warn_slowpath_null+0x1a/0x20
>> >> > [125311.722007] [<ffffffff81616db8>] tcp_fastretrans_alert+0xb58/0xc80
>> >> > [125311.722011] [<ffffffff8161891f>] tcp_ack+0x6df/0xe90
>> >> > [125311.722016] [<ffffffff8164e0ca>] ? ipt_do_table+0x22a/0x680
>> >> > [125311.722018] [<ffffffff816194b3>] ? tcp_validate_incoming+0x63/0x320
>> >> > [125311.722021] [<ffffffff8161a55c>] tcp_rcv_established+0x2cc/0x810
>> >> > [125311.722023] [<ffffffff81622c84>] tcp_v4_do_rcv+0x254/0x4f0
>> >> > [125311.722025] [<ffffffff816245ac>] tcp_v4_rcv+0x5fc/0x750
>> >> > [125311.722027] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
>> >> > [125311.722032] [<ffffffff815df3ad>] ? nf_hook_slow+0x7d/0x160
>> >> > [125311.722034] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
>> >> > [125311.722036] [<ffffffff815fface>] ip_local_deliver_finish+0xce/0x250
>> >> > [125311.722037] [<ffffffff815ffc9c>] ip_local_deliver+0x4c/0x80
>> >> > [125311.722039] [<ffffffff815ff329>] ip_rcv_finish+0x119/0x360
>> >> > [125311.722040] [<ffffffff815ff8e0>] ip_rcv+0x230/0x350
>> >> > [125311.722046] [<ffffffff815b4067>] __netif_receive_skb_core+0x477/0x600
>> >> > [125311.722049] [<ffffffff815b4217>] __netif_receive_skb+0x27/0x70
>> >> > [125311.722051] [<ffffffff815b4354>] process_backlog+0xf4/0x1e0
>> >> > [125311.722053] [<ffffffff815b4b45>] net_rx_action+0xf5/0x250
>> >> > [125311.722056] [<ffffffff81053a5f>] __do_softirq+0xef/0x270
>> >> > [125311.722058] [<ffffffff81053cb5>] irq_exit+0x95/0xa0
>> >> > [125311.722062] [<ffffffff816c8f26>] do_IRQ+0x66/0xe0
>> >> > [125311.722065] [<ffffffff816bf62a>] common_interrupt+0x6a/0x6a
>> >> > [125311.722065] <EOI> [<ffffffff8100abf1>] ? default_idle+0x21/0xc0
>> >> > [125311.722082] [<ffffffff8100a54f>] arch_cpu_idle+0xf/0x20
>> >> > [125311.722086] [<ffffffff8108f353>] cpu_startup_entry+0xb3/0x230
>> >> > [125311.722091] [<ffffffff816b439e>] start_secondary+0x1dc/0x1e3
>> >> > [125311.722093] ---[ end trace e77cd5ba583fcbe9 ]---
>> >> > [125311.722096] 355.355.1.355:22496 F0x4120 S1 s7 IF25+17-1-24f0 ur57 rr3 rt0 um0 hs23120 nxt23120
>> >> >
>> >> > It's been happening with all 3.10 kernels, and the one above is .13 as
>> >> > stated in the trace.
>> >>
>> >> Thanks! could you post the output of `sysctl -a |grep tcp`?
>> >>
>> >> I suspect tcp_process_tlp_ack() should not revert state to Open
>> >> directly, but calling tcp_try_keep_open() instead, similar to all the
>> >> undo processing in the tcp_fastretrans_alert(): after
>> >> tcp_end_cwnd_reduction(), the process (E) falls back to check other
>> >> stats before moving to CA_Open.
>> >>
>> >>
>> >> index 9c62257..9012b42 100644
>> >> --- a/net/ipv4/tcp_input.c
>> >> +++ b/net/ipv4/tcp_input.c
>> >> @@ -3314,7 +3314,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack,
>> >> tcp_init_cwnd_reduction(sk, true);
>> >> tcp_set_ca_state(sk, TCP_CA_CWR);
>> >> tcp_end_cwnd_reduction(sk);
>> >> - tcp_set_ca_state(sk, TCP_CA_Open);
>> >> + tcp_try_keep_open(sk);
>> >> NET_INC_STATS_BH(sock_net(sk),
>> >> LINUX_MIB_TCPLOSSPROBERECOVERY);
>> >> }
>> >>
>> >
>> > Should I apply this and see if the warning stops?
>> I'd like to hear what the authors of TLP think. In the mean time could
>> you help us collect more evidence by disabling TLP with
>> sysctl net.ipv4.tcp_early_retrans=2
>> and see if the problem still occurs? (it should not).
>>
>> thanks
>
> Box hasn't had a warning in the last 24ish hours. A neighboring machine
> with the default tcp_early_retrans setting has had 5-6 in the same
> timeframe.
>
> Is this a harmful situation to the socket in any way, or is it just
> informational weirdness?
It should be fairly harmless. The ack that triggers the warning should
set the TCP back to the good (non-Open) state, but it's still good to
get rid of.
^ permalink raw reply
* Re: [PATCH] qlcnic: add missing destroy_workqueue() on error path in qlcnic_probe()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: weiyj.lk
Cc: himanshu.madhani, rajesh.borundia, shahed.shaikh,
jitendra.kalsaria, sony.chacko, sucheta.chakraborty, yongjun_wei,
linux-driver, netdev
In-Reply-To: <CAPgLHd9oA08=1o_DWE0SGeg_7nokr3-WPEAOrG71bYg2C1676A@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 8 Oct 2013 11:32:17 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add the missing destroy_workqueue() before return from
> qlcnic_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] sh_eth: NAPI requires netif_receive_skb()
From: Sergei Shtylyov @ 2013-10-08 21:52 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: David Miller, netdev, nobuhiro.iwamatsu.yj, linux-sh
In-Reply-To: <Pine.LNX.4.64.1309261751200.11968@axis700.grange>
Hello.
On 26-09-2013 18:12, Guennadi Liakhovetski wrote:
>> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Date: Tue, 3 Sep 2013 03:03:10 +0400
>>> Driver supporting NAPI should use NAPI-specific function for receiving packets,
>>> so netif_rx() should be changed to netif_receive_skb().
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> This patch breaks NFS boot on Armadillo800eva for me. Network
> communication slows down to a crawl with
> net eth0: Receive FIFO Overflow
> nfs: server 192.168.x.y not responding, still trying
> With this patch reverted (e.g. in today's Linus tree snapshot) boot is
> restored.
Guennadi, are you expecting some actions (like looking into what Eric have
suggested) from me? If so, I'm still on vacation, should be back next Tuesday.
I don't think reverting the patch is a Right Thing to do.
> Thanks
> Guennadi
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] moxa: fix the error handling in moxart_mac_probe()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: weiyj.lk
Cc: grant.likely, rob.herring, jg1.han, b.zolnierkie, kyungmin.park,
yongjun_wei, netdev
In-Reply-To: <CAPgLHd95agB+cseQmD4wg50wX_ddyZ0=0VxJ8vAR80ZbcFsMTw@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 8 Oct 2013 11:19:19 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> This patch fix the error handling in moxart_mac_probe():
> - return -ENOMEM in some memory alloc fail cases
> - add missing free_netdev() in the error handling case
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix non TCP flows pacing
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, sesse
In-Reply-To: <1381182269.12191.27.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 14:44:29 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Steinar reported FQ pacing was not working for UDP flows.
>
> It looks like the initial sk->sk_pacing_rate value of 0 was
> a wrong choice. We should init it to ~0U like sk_max_pacing_rate
>
> Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
> no real sense. (The default rate is really : ~0U)
>
> While debugging this issue, I realized sk_pacing_rate is shared between
> transport and packet scheduler without locking / barriers :
>
> We should use ACCESS_ONCE() to make sure compiler wont perform
> multiple loads or stores.
>
> Reported-by: Steinar H. Gunderson <sesse@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Is this meant for net or net-next? It doesn't apply cleanly to the
former.
^ permalink raw reply
* Re: [PATCH] net: vlan: fix nlmsg size calculation in vlan_get_size()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, kaber
In-Reply-To: <1381180798-26654-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 7 Oct 2013 23:19:58 +0200
> This patch fixes the calculation of the nlmsg size, by adding the missing
> nla_total_size().
>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix typo for initial_quantum
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381175418.12191.19.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 12:50:18 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCA_FQ_INITIAL_QUANTUM should set q->initial_quantum
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: Fix the upper MTU limit in GRE tunnel
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: ou.ghorbel; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1381168205-7465-1-git-send-email-ou.ghorbel@gmail.com>
From: Oussama Ghorbel <ou.ghorbel@gmail.com>
Date: Mon, 7 Oct 2013 18:50:05 +0100
> Unlike ipv4, the struct member hlen holds the length of the GRE and ipv6
> headers. This length is also counted in dev->hard_header_len.
> Perhaps, it's more clean to modify the hlen to count only the GRE header
> without ipv6 header as the variable name suggest, but the simple way to fix
> this without regression risk is simply modify the calculation of the limit
> in ip6gre_tunnel_change_mtu function.
> Verified in kernel version v3.11.
>
> Signed-off-by: Oussama Ghorbel <ou.ghorbel@gmail.com>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] cgroup: cls: remove unnecessary task_cls_classid
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: gaofeng-BthXqXjhjHXQFUHtdCDX3A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
jhs-jkUAjuhPggJWk0Htik3J/w, tj-DgEjT+Ai2ygdnm+yROfE0A,
nhorman-2XuSBdqkA4R54TAoqtyWWQ, lizefan-hv44wF8Li93QT0dZR+AlfA,
daniel.wagner-98C5kh4wR6ohFhg+JK9F0w
In-Reply-To: <1381201520-25938-2-git-send-email-gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
From: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Date: Tue, 8 Oct 2013 11:05:20 +0800
> We can get classid through cgroup_subsys_state,
> this is directviewing and effective.
>
> Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] cgroup: netprio: remove unnecessary task_netprioidx
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: gaofeng-BthXqXjhjHXQFUHtdCDX3A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
jhs-jkUAjuhPggJWk0Htik3J/w, tj-DgEjT+Ai2ygdnm+yROfE0A,
nhorman-2XuSBdqkA4R54TAoqtyWWQ, lizefan-hv44wF8Li93QT0dZR+AlfA,
daniel.wagner-98C5kh4wR6ohFhg+JK9F0w
In-Reply-To: <1381201520-25938-1-git-send-email-gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
From: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Date: Tue, 8 Oct 2013 11:05:19 +0800
> Since the tasks have been migrated to the cgroup,
> there is no need to call task_netprioidx to get
> task's cgroup id.
>
> Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] Improve UDP multicast receive latency
From: David Miller @ 2013-10-08 20:51 UTC (permalink / raw)
To: shawn.bohrer; +Cc: netdev, tomk, eric.dumazet, sbohrer
In-Reply-To: <1381161700-14453-1-git-send-email-shawn.bohrer@gmail.com>
From: Shawn Bohrer <shawn.bohrer@gmail.com>
Date: Mon, 7 Oct 2013 11:01:37 -0500
> From: Shawn Bohrer <sbohrer@rgmadvisors.com>
>
> The removal of the routing cache in 3.6 had impacted the latency of our
> UDP multicast workload. This patch series brings down the latency to
> what we were seeing with 3.4.
>
> Patch 1 "udp: Only allow busy read/poll on connected sockets" is mostly
> done for correctness and because it allows unifying the unicast and
> multicast paths when a socket is found in early demux. It can also
> improve latency for a connected multicast socket if busy read/poll is
> used.
>
> Patches 2&3 remove the fib lookups and restore latency for our workload
> to the pre 3.6 levels.
>
> Benchmark results from a netperf UDP_RR test:
> v3.12-rc3-447-g40dc9ab kernel 87961.22 transactions/s
> v3.12-rc3-447-g40dc9ab + series 90587.62 transactions/s
>
> Benchmark results from a fio 1 byte UDP multicast pingpong test
> (Multicast one way unicast response):
> v3.12-rc3-447-g40dc9ab kernel 12.97us RTT
> v3.12-rc3-447-g40dc9ab + series 12.48us RTT
Great work, all applied to net-next, thanks!
^ permalink raw reply
* Re: [PATCH net-next] net_sched: increment drop counters in qdisc_tree_decrease_qlen()
From: David Miller @ 2013-10-08 20:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381159952.12191.14.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 08:32:32 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> qdisc_tree_decrease_qlen() is called when some packets are dropped
> on a qdisc, and we want to notify parents of qlen changes.
>
> We also can increment parents qdisc qstats drop counters.
>
> This permits more accurate drop counters up to root qdisc.
>
> For example a graft operation typically resets a qdisc
> (drops all packets) and call qdisc_tree_decrease_qlen()
>
> Note that callers are responsible for their drop counters.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net V1 0/2] net/mlx4_en: Fix pages never dma unmapped on rx
From: David Miller @ 2013-10-08 20:10 UTC (permalink / raw)
To: amirv; +Cc: netdev, ogerlitz, eugenia, edumazet
In-Reply-To: <1381145893-20930-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Mon, 7 Oct 2013 13:38:11 +0200
> This patchset fixes a bug introduced by commit 51151a16 (mlx4: allow order-0
> memory allocations in RX path). Where dma_unmap_page wasn't called.
>
> Changes from V0:
> - Added "Rename name of mlx4_en_rx_alloc members". Old names were confusing.
> - Last frag in page calculation was wrong. Since all frags in page are of the
> same size, need to add this frag_stride to end of frag offset, and not the
> size of next frag in skb.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bonding: ensure that TLB mode's active slave has correct mac filter
From: David Miller @ 2013-10-08 20:07 UTC (permalink / raw)
To: vfalico; +Cc: netdev, fubar, andy, yuvalmin
In-Reply-To: <1381130240-3561-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Mon, 7 Oct 2013 09:17:20 +0200
> Currently, in TLB mode we change mac addresses only by memcpy-ing the to
> net_device->dev_addr, without actually setting them via
> dev_set_mac_address(). This permits us to receive all the traffic always on
> one mac address.
>
> However, in case the interface flips, some drivers might enforce the
> mac filtering for its FW/HW based on current ->dev_addr, and thus we won't
> be able to receive traffic on that interface, in case it will be selected
> as active in TLB mode.
>
> Fix it by setting the mac address forcefully on every new active slave that
> we select in TLB mode.
>
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: Yuval Mintz <yuvalmin@broadcom.com>
> Reported-by: Yuval Mintz <yuvalmin@broadcom.com>
> Tested-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Since we hole the RTNL during this tricky operation I guess this is fine.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: sh_eth: Fix RX packets errors on R8A7740
From: David Miller @ 2013-10-08 20:04 UTC (permalink / raw)
To: nh-ky; +Cc: netdev, ryusuke.sakato.bx, sergei.shtylyov, horms
In-Reply-To: <1381127365-6521-1-git-send-email-nh-ky@jinso.co.jp>
From: Nguyen Hong Ky <nh-ky@jinso.co.jp>
Date: Mon, 7 Oct 2013 15:29:24 +0900
> This patch will fix RX packets errors when receiving big size of data.
> Moreover, I set suitable parameters for get more stable when receiving
> packets.
>
> It was created on the top of mainline kernel v3.11.
>
> I tested this patch on Armadillo800eva, it appears to be working well.
>
> Would you please review and apply it for me.
Applied, but at some point someone has to add definitions for the
RMCR register fields so that this driver is not full of magic constants.
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 20:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Patch Tracking, linville
In-Reply-To: <1381259316.13359.17.camel@jlt4.sipsolutions.net>
On 8 October 2013 21:08, Johannes Berg <johannes@sipsolutions.net> wrote:
> I'm not too familiar with the aead API, so here's another question:
>
>> + sg_init_one(&pt, data, data_len);
>> + sg_init_one(&assoc, &aad[2], be16_to_cpup((__be16 *)aad));
>> + sg_init_table(ct, 2);
>> + sg_set_buf(&ct[0], cdata, data_len);
>> + sg_set_buf(&ct[1], mic, IEEE80211_CCMP_MIC_LEN);
>
> Is it guaranteed to be allowed that the input and output are the same
> buffer? It seems we rely on that for encrypt_one(), but is it true here
> as well?
>
Yes, the crypto layer handles all of that without issue.
> (Btw - why pass in data/cdata as separate pointers into the function?)
>
That is just a leftover of the old implementation. I will remove that
in v2, that will cut down the number of function args as well.
>> @@ -343,7 +337,7 @@ static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *scratch,
>> data_len -= IEEE80211_CCMP_MIC_LEN;
>>
>> /* First block, b_0 */
>> - b_0[0] = 0x59; /* flags: Adata: 1, M: 011, L: 001 */
>> + b_0[0] = 0x1; /* set L := 1, M and Adata flags are implied */
>
> Hmm. I don't think I understand, can you explain this to me?
>
Well M is implied by the setauthsize() in init() [M := (MIC_LEN-2)/2
== 3], and the set_assoc() call in en/decrypt() indicates the presence
of assoc (A) data. Instead of setting the flags here, and clearing
them by anding with ~0x7 (as in the old implementation), this lets the
CCM layer handle that.
--
Ard.
^ permalink raw reply
* Re: [PATCH] net: af802154: Fix wrong structure declaration
From: David Miller @ 2013-10-08 19:49 UTC (permalink / raw)
To: linux; +Cc: alex.bluesman.smirnov, dbaryshkov, netdev, linux-zigbee-devel
In-Reply-To: <1381095841-15031-1-git-send-email-linux@roeck-us.net>
From: Guenter Roeck <linux@roeck-us.net>
Date: Sun, 6 Oct 2013 14:44:01 -0700
> net_devce doesn't exist.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This is simply rediculous.
The reason I say this is that every user of this header includes
net/sock.h which in turn includes linux/skbuff.h and linux/netdevice.h
which therefore bring in all the necessary structure definitions.
Really, the most correct change is to make af802154.h explicitly
include those header files.
^ permalink raw reply
* Re: [PATCH] tun: don't look at current when non-blocking
From: David Miller @ 2013-10-08 19:46 UTC (permalink / raw)
To: mst; +Cc: netdev, linux-kernel, jasowang, edumazet, xemul
In-Reply-To: <20131006182512.GA16504@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 6 Oct 2013 21:25:12 +0300
> We play with a wait queue even if socket is
> non blocking. This is an obvious waste.
> Besides, it will prevent calling the non blocking
> variant when current is not valid.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH] l2tp: Fix build warning with ipv6 disabled.
From: David Miller @ 2013-10-08 19:45 UTC (permalink / raw)
To: netdev
net/l2tp/l2tp_core.c: In function ‘l2tp_verify_udp_checksum’:
net/l2tp/l2tp_core.c:499:22: warning: unused variable ‘tunnel’ [-Wunused-variable]
Create a helper "l2tp_tunnel()" to facilitate this, and as a side
effect get rid of a bunch of unnecessary void pointer casts.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/l2tp/l2tp_core.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index aedaa2c..b076e83 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -115,6 +115,11 @@ struct l2tp_net {
static void l2tp_session_set_header_len(struct l2tp_session *session, int version);
static void l2tp_tunnel_free(struct l2tp_tunnel *tunnel);
+static inline struct l2tp_tunnel *l2tp_tunnel(struct sock *sk)
+{
+ return sk->sk_user_data;
+}
+
static inline struct l2tp_net *l2tp_pernet(struct net *net)
{
BUG_ON(!net);
@@ -496,7 +501,6 @@ out:
static inline int l2tp_verify_udp_checksum(struct sock *sk,
struct sk_buff *skb)
{
- struct l2tp_tunnel *tunnel = (struct l2tp_tunnel *)sk->sk_user_data;
struct udphdr *uh = udp_hdr(skb);
u16 ulen = ntohs(uh->len);
__wsum psum;
@@ -505,7 +509,7 @@ static inline int l2tp_verify_udp_checksum(struct sock *sk,
return 0;
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6 && !tunnel->v4mapped) {
+ if (sk->sk_family == PF_INET6 && !l2tp_tunnel(sk)->v4mapped) {
if (!uh->check) {
LIMIT_NETDEBUG(KERN_INFO "L2TP: IPv6: checksum is 0\n");
return 1;
@@ -1305,10 +1309,9 @@ EXPORT_SYMBOL_GPL(l2tp_xmit_skb);
*/
static void l2tp_tunnel_destruct(struct sock *sk)
{
- struct l2tp_tunnel *tunnel;
+ struct l2tp_tunnel *tunnel = l2tp_tunnel(sk);
struct l2tp_net *pn;
- tunnel = sk->sk_user_data;
if (tunnel == NULL)
goto end;
@@ -1676,7 +1679,7 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32
}
/* Check if this socket has already been prepped */
- tunnel = (struct l2tp_tunnel *)sk->sk_user_data;
+ tunnel = l2tp_tunnel(sk);
if (tunnel != NULL) {
/* This socket has already been prepped */
err = -EBUSY;
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH v1 0/3] Fix race conditions in mrf24j40 interrupts
From: David Miller @ 2013-10-08 19:32 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, david, linux-zigbee-devel,
netdev, linux-kernel
In-Reply-To: <1381031544-2960-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Sat, 5 Oct 2013 23:52:21 -0400
> After testing with the betas of this patchset, it's been rebased and is
> ready for inclusion.
>
> David Hauweele noticed that the mrf24j40 would hang arbitrarily after some
> period of heavy traffic. Two race conditions were discovered, and the
> driver was changed to use threaded interrupts, since the enable/disable of
> interrupts in the driver has recently been a lighning rod whenever issues
> arise related to interrupts (costing engineering time), and since threaded
> interrupts are the right way to do it.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] 6lowpan default hardware address
From: David Miller @ 2013-10-08 19:29 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, alex.aring, linux-zigbee-devel,
netdev, linux-kernel
In-Reply-To: <1381029319-6835-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Sat, 5 Oct 2013 23:15:17 -0400
> Alexander Aring suggested that devices desired to be linked to 6lowpan
> be checked for actually being of type IEEE802154, since IEEE802154 devices
> are all that are supported by 6lowpan at present.
>
> Alan Ott (2):
> 6lowpan: Only make 6lowpan links to IEEE802154 devices
> 6lowpan: Sync default hardware address of lowpan links to their wpan
Series applied, thanks Alan.
^ 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