* Re: [PATCH] myri10ge: Fix typo of 'VMware' in comment.
From: Andrew Gallatin @ 2011-12-19 20:21 UTC (permalink / raw)
To: Vinson Lee; +Cc: netdev, linux-kernel, trivial
In-Reply-To: <1324325875-30907-1-git-send-email-vlee@vmware.com>
On 12/19/11 15:17, Vinson Lee wrote:
> Signed-off-by: Vinson Lee<vlee@vmware.com>
Acked by: Andrew Gallatin <gallatin@myri.com>
^ permalink raw reply
* [PATCH] libertas: clean up scan thread handling
From: Andres Salomon @ 2011-12-19 20:22 UTC (permalink / raw)
To: dcbw; +Cc: linville, libertas-dev, linux-wireless, netdev, linux-kernel, dsd
The libertas scan thread expects priv->scan_req to be non-NULL. In theory,
it should always be set. In practice, we've seen the following oops:
[ 8363.067444] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 8363.067490] pgd = c0004000
[ 8363.078393] [00000004] *pgd=00000000
[ 8363.086711] Internal error: Oops: 17 [#1] PREEMPT
[ 8363.091375] Modules linked in: fuse libertas_sdio libertas psmouse mousedev ov7670 mmp_camera joydev videobuf2_core videobuf2_dma_sg videobuf2_memops [last unloaded: scsi_wait_scan]
[ 8363.107490] CPU: 0 Not tainted (3.0.0-gf7ccc69 #671)
[ 8363.112799] PC is at lbs_scan_worker+0x108/0x5a4 [libertas]
[ 8363.118326] LR is at 0x0
[ 8363.120836] pc : [<bf03a854>] lr : [<00000000>] psr: 60000113
[ 8363.120845] sp : ee66bf48 ip : 00000000 fp : 00000000
[ 8363.120845] r10: ee2c2088 r9 : c04e2efc r8 : eef97005
[ 8363.132231] r7 : eee0716f r6 : ee2c02c0 r5 : ee2c2088 r4 : eee07160
[ 8363.137419] r3 : 00000000 r2 : a0000113 r1 : 00000001 r0 : eee07160
[ 8363.143896] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 8363.157630] Control: 10c5387d Table: 2e754019 DAC: 00000015
[ 8363.163334] Process kworker/u:1 (pid: 25, stack limit = 0xee66a2f8)
While I've not found a smoking gun, there are two places that raised red flags
for me. The first is in _internal_start_scan, when we queue up a scan; we
first queue the worker, and then set priv->scan_req. There's theoretically
a 50mS delay which should be plenty, but doing things that way just seems
racy (and not in the good way).
The second is in the scan worker thread itself. Depending on the state of
priv->scan_channel, we cancel pending scan runs and then requeue a run in
300mS. We then send the scan command down to the hardware, sleep, and if
we get scan results for all the desired channels, we set priv->scan_req to
NULL. However, it that's happened in less than 300mS, what happens with
the pending scan run?
This patch addresses both of those concerns. With the patch applied, we
have not seen the oops in the past two weeks.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Cc: stable@kernel.org
---
drivers/net/wireless/libertas/cfg.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index a7f1ab2..db64ef1 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -728,9 +728,11 @@ static void lbs_scan_worker(struct work_struct *work)
le16_to_cpu(scan_cmd->hdr.size),
lbs_ret_scan, 0);
- if (priv->scan_channel >= priv->scan_req->n_channels)
+ if (priv->scan_channel >= priv->scan_req->n_channels) {
/* Mark scan done */
+ cancel_delayed_work(&priv->scan_work);
lbs_scan_done(priv);
+ }
/* Restart network */
if (carrier)
@@ -759,12 +761,12 @@ static void _internal_start_scan(struct lbs_private *priv, bool internal,
request->n_ssids, request->n_channels, request->ie_len);
priv->scan_channel = 0;
- queue_delayed_work(priv->work_thread, &priv->scan_work,
- msecs_to_jiffies(50));
-
priv->scan_req = request;
priv->internal_scan = internal;
+ queue_delayed_work(priv->work_thread, &priv->scan_work,
+ msecs_to_jiffies(50));
+
lbs_deb_leave(LBS_DEB_CFG80211);
}
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] myri10ge: Fix typo of 'VMware' in comment.
From: David Miller @ 2011-12-19 20:45 UTC (permalink / raw)
To: gallatin; +Cc: vlee, netdev, linux-kernel, trivial
In-Reply-To: <4EEF9CDC.1040100@myri.com>
From: Andrew Gallatin <gallatin@myri.com>
Date: Mon, 19 Dec 2011 15:21:48 -0500
> On 12/19/11 15:17, Vinson Lee wrote:
>> Signed-off-by: Vinson Lee<vlee@vmware.com>
>
>
> Acked by: Andrew Gallatin <gallatin@myri.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next] bnx2: Update driver to use new mips firmware.
From: David Miller @ 2011-12-19 20:48 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1324268109-27740-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Sun, 18 Dec 2011 20:15:09 -0800
> bnx2-mips-06-6.2.3 and bnx2-mips-09-6.2.1.b
>
> New firmware fixes iSCSI problems with some LeftHand targets that don't
> set TTT=0xffffffff for Data-In according to spec. Firmware generates
> exception warnings for this condition and becomes very slow. This is
> fixed by suppressing these warnings when using default error mask.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: bpf_jit: fix an off-one bug in x86_64 cond jump target
From: David Miller @ 2011-12-19 20:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, nepenthesdev
In-Reply-To: <1324157948.3323.36.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 17 Dec 2011 22:39:08 +0100
> From: Markus Kötter <nepenthesdev@gmail.com>
>
> x86 jump instruction size is 2 or 5 bytes (near/long jump), not 2 or 6
> bytes.
>
> In case a conditional jump is followed by a long jump, conditional jump
> target is one byte past the start of target instruction.
>
> Signed-off-by: Markus Kötter <nepenthesdev@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] tg3: Make the RSS indir tbl admin configurable
From: David Miller @ 2011-12-19 20:51 UTC (permalink / raw)
To: mcarlson; +Cc: netdev, mchan
In-Reply-To: <1324078403-10617-1-git-send-email-mcarlson@broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Fri, 16 Dec 2011 15:33:23 -0800
> This patch adds the ethtool callbacks necessary to change the rss
> indirection table from userspace. Should the number of interrupts
> change (e.g. across a close / open call, or through a reset) and
> any one of the indirection table values fall out-of-range, the driver
> will reset the indirection table to a default layout.
>
> [Integrated many suggestions made by Ben Hutchings.]
>
> Changes since v3
>
> * Removed TG3_FLAG_SUPPORT_MSIX checks at the start of
> tg3_get_rxfh_indir() and tg3_set_rxfh_indir().
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] llc_cmsg_rcv was getting called after sk_eat_skb.
From: David Miller @ 2011-12-19 20:59 UTC (permalink / raw)
To: ajuncu; +Cc: acme, netdev, alex.juncu, knaik, shemminger
In-Reply-To: <1324026085-11812-1-git-send-email-ajuncu@ixiacom.com>
From: Alexandru Juncu <ajuncu@ixiacom.com>
Date: Fri, 16 Dec 2011 11:01:25 +0200
> Received non stream protocol packets were calling llc_cmsg_rcv that used a
> skb after that skb was released by sk_eat_skb. This caused received STP
> packets to generate kernel panics.
>
> Signed-off-by: Alexandru Juncu <ajuncu@ixiacom.com>
> Signed-off-by: Kunjan Naik <knaik@ixiacom.com>
This bug was introduced by commit 30a584d944fbd599d4a8f470f75bf7af1a15b466:
commit 30a584d944fbd599d4a8f470f75bf7af1a15b466
Author: Stephen Hemminger <shemminger@osdl.org>
Date: Thu Aug 3 16:38:49 2006 -0700
[LLX]: SOCK_DGRAM interface fixes
The new logic added by this fix is slightly clumsy, but seems correct
and I can't suggest a better fix at this time.
I'll apply this, thanks.
^ permalink raw reply
* Re: LARTC mailing list
From: Niccolò Belli @ 2011-12-19 20:59 UTC (permalink / raw)
To: David Miller
Cc: andy, postmaster, netfilter, lartc, andyqos, jsullivan, lloyd,
netdev
In-Reply-To: <20111219.145940.2030642788874548046.davem@davemloft.net>
Il 19/12/2011 20:59, David Miller ha scritto:
> From: Andrew Beverley<andy@andybev.com>
> Date: Mon, 19 Dec 2011 17:11:52 +0000
>
>> VGER postmasters: can we try a new LARTC list at VGER please?
>
> I've created lartc@vger.kernel.org, enjoy.
A-W-E-S-O-M-E, thank you so much!
We really need to find a place for the wiki now :)
Niccolò
^ permalink raw reply
* Re: [PATCH] asix: new device id
From: David Miller @ 2011-12-19 21:00 UTC (permalink / raw)
To: aurel; +Cc: netdev, grundler
In-Reply-To: <1324068562-3761-1-git-send-email-aurel@gnuage.org>
From: Aurelien Jacobs <aurel@gnuage.org>
Date: Fri, 16 Dec 2011 21:49:22 +0100
> Adds the device id needed for the USB Ethernet Adapter delivered by
> ASUS with their Zenbook.
>
> Signed-off-by: Aurelien Jacobs <aurel@gnuage.org>
Grant, ACK/NACK?
^ permalink raw reply
* Re: [PATCH net-next] net: two vzalloc() cleanups
From: David Miller @ 2011-12-19 21:01 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1324070255.2621.29.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 16 Dec 2011 22:17:35 +0100
> We can use vzalloc() helper now instead of __vmalloc() trick
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: TTL=0 multicast packets leaving host
From: David Miller @ 2011-12-19 21:06 UTC (permalink / raw)
To: sbohrer; +Cc: netdev
In-Reply-To: <20111207213158.GA2444@BohrerMBP.rgmadvisors.com>
From: Shawn Bohrer <sbohrer@rgmadvisors.com>
Date: Wed, 7 Dec 2011 15:31:58 -0600
> This looks like a bug to me. I'd assume that if the local computer
> has not joined the multicast group and I send a TTL=0 packet that it
> would simply get discarded.
This behavior is intentional, several multicast applications set TTL
to zero and expect it to reach the local network.
See the comment elsewhere in route.c:
/* Special hack: user can direct multicasts
and limited broadcast via necessary interface
without fiddling with IP_MULTICAST_IF or IP_PKTINFO.
This hack is not just for fun, it allows
vic,vat and friends to work.
They bind socket to loopback, set ttl to zero
and expect that it will work.
From the viewpoint of routing cache they are broken,
because we are not allowed to build multicast path
with loopback source addr (look, routing cache
cannot know, that ttl is zero, so that packet
will not leave this host and route is valid).
Luckily, this hack is good workaround.
*/
^ permalink raw reply
* Re: linux-3.0.x regression with ipv4 routes having mtu
From: David Miller @ 2011-12-19 21:10 UTC (permalink / raw)
To: steffen.klassert; +Cc: timo.teras, netdev
In-Reply-To: <20111216122147.GJ6348@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 16 Dec 2011 13:21:47 +0100
> Subject: [PATCH] route: Initialize with the fib_metrics in the non default case
>
> We initialize the routing metrics with the cached values in
> rt_init_metrics(). So if we have the metrics cached on the
> inetpeer, we ignore the user configured fib_metrics. So
> initialize the routing metrics with the fib_metrics if they
> are different from dst_default_metrics.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
The current behavior is intentional.
Learned metrics should be used on all routes for which a inetpeer
peer exists and the destination matches.
There is no sane way to allow overrides.
I'm pretty sure all of Timo's bugs will be fixed when you add the
generation count for PMTU stuff.
^ permalink raw reply
* Re: [net-next PATCH 1/1] qla3xxx: Adding Maintainer.
From: David Miller @ 2011-12-19 21:12 UTC (permalink / raw)
To: jitendra.kalsaria; +Cc: netdev, ron.mercer, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1324071697-23414-1-git-send-email-jitendra.kalsaria@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Date: Fri, 16 Dec 2011 13:41:37 -0800
> Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/6] sunhme/PCI: use list_for_each_entry() for bus->devices traversal
From: David Miller @ 2011-12-19 21:13 UTC (permalink / raw)
To: bhelgaas; +Cc: jbarnes, linux-pci, netdev
In-Reply-To: <20111216223149.5963.61942.stgit@bhelgaas.mtv.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Fri, 16 Dec 2011 15:31:49 -0700
> Replace open-coded list traversal with list_for_each_entry().
>
> CC: David S. Miller <davem@davemloft.net>
> CC: netdev@vger.kernel.org
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 5/6] de4x5/PCI: use list_for_each_entry() for bus->devices traversal
From: David Miller @ 2011-12-19 21:13 UTC (permalink / raw)
To: bhelgaas; +Cc: jbarnes, linux-pci, grundler, netdev
In-Reply-To: <20111216223154.5963.39965.stgit@bhelgaas.mtv.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Fri, 16 Dec 2011 15:31:54 -0700
> Replace open-coded list traversal with list_for_each_entry().
>
> CC: Grant Grundler <grundler@parisc-linux.org>
> CC: netdev@vger.kernel.org
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: make the net.ipv6.conf.all.use_tempaddr sysctl propagate to interface settings
From: David Miller @ 2011-12-19 21:16 UTC (permalink / raw)
To: mathieu.trudel-lapierre; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <1324071933-2961-1-git-send-email-mathieu.trudel-lapierre@canonical.com>
From: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
Date: Fri, 16 Dec 2011 16:45:33 -0500
> The description for IPV6_PRIVACY mentions using .../all/use_tempaddr to enable
> IPv6 Privacy Extensions, and IP sysctl documentation mentions 'all' as setting
> all interface-specific settings. We make sure at least use_tempaddr actually
> works as documented.
>
> Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
"all" settings must be in place before the device is created and comes up.
You can't just "propagate" to the existing devices when the "all"
setting is changed, because an individual device might have had it's
independent sysctl setting modified by the administrator and you'll be
smashing that.
I'm not applying this patch.
^ permalink raw reply
* Re: [PATCH 14/15] module_param: make bool parameters really bool (net & drivers/net)
From: David Miller @ 2011-12-19 21:22 UTC (permalink / raw)
To: rusty; +Cc: joe, linux-kernel, pawel.moll, netdev
In-Reply-To: <87ehw1nm9r.fsf@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Mon, 19 Dec 2011 16:19:52 +1030
> On Thu, 15 Dec 2011 23:15:17 -0500 (EST), David Miller <davem@davemloft.net> wrote:
>> From: Rusty Russell <rusty@rustcorp.com.au>
>> Date: Fri, 16 Dec 2011 09:44:31 +1030
>>
>> > Dave, did you want a true/false cleanup too?
>>
>> Please, this kind of stuff rots forever and not using bool properly
>> drives me crazy.
>
> And here's the updated patch:
Neither of your two patches comes close to applying cleanly to net-next,
even when I try to apply it by hand there are rejects and references to
files that don't even exist in net-next any more.
Please respin them.
Thanks!
^ permalink raw reply
* Re: [PATCH] asix: new device id
From: Grant Grundler @ 2011-12-19 21:22 UTC (permalink / raw)
To: David Miller; +Cc: aurel, netdev, Allan Chou, Freddy Xin
In-Reply-To: <20111219.160059.783127741333326755.davem@davemloft.net>
On Mon, Dec 19, 2011 at 1:00 PM, David Miller <davem@davemloft.net> wrote:
> From: Aurelien Jacobs <aurel@gnuage.org>
> Date: Fri, 16 Dec 2011 21:49:22 +0100
>
>> Adds the device id needed for the USB Ethernet Adapter delivered by
>> ASUS with their Zenbook.
>>
>> Signed-off-by: Aurelien Jacobs <aurel@gnuage.org>
>
> Grant, ACK/NACK?
Dave,
I'm totally ok with it if Aurelien is confident it "works" (well enough).
I'm really the wrong guy to ask though. I don't have the device
and I'm not associated with the mfg.
The right people to ask (CC'd) are Allan Chou and Freddy Xin (both from ASIX).
cheers!
grant
^ permalink raw reply
* [PATCH] net/sched: sch_plug - Queue traffic until an explicit release command
From: rshriram @ 2011-12-19 21:22 UTC (permalink / raw)
To: hadi; +Cc: netdev, Brendan Cully, Shriram Rajagopalan
This qdisc can be used to implement output buffering, an essential
functionality required for consistent recovery in checkpoint based
fault tolerance systems. The qdisc supports two operations - plug and
unplug. When the qdisc receives a plug command via netlink request,
packets arriving henceforth are buffered until a corresponding unplug
command is received.
Its intention is to support speculative execution by allowing generated
network traffic to be rolled back. It is used to provide network
protection for domUs in the Remus high availability project, available as
part of Xen. This module is generic enough to be used by any other
system that wishes to add speculative execution and output buffering to
its applications.
This module was originally available in the linux 2.6.32 PV-OPS tree,
used as dom0 for Xen.
For more information, please refer to http://nss.cs.ubc.ca/remus/
and http://wiki.xensource.com/xenwiki/Remus
Signed-off-by: Brendan Cully <brendan@cs.ubc.ca>
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
[shriram - ported the code from older 2.6.32 to current tree]
---
net/sched/Kconfig | 19 ++++++
net/sched/Makefile | 1 +
net/sched/sch_plug.c | 159 ++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 net/sched/sch_plug.c
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index 2590e91..d0ccefa 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -260,6 +260,25 @@ config NET_SCH_INGRESS
To compile this code as a module, choose M here: the
module will be called sch_ingress.
+config NET_SCH_PLUG
+ tristate "Plug network traffic until release (PLUG)"
+ ---help---
+ Say Y here if you are using this kernel for Xen dom0 and
+ want to protect Xen guests with Remus.
+
+ This queueing discipline is controlled by netlink. When it receives an
+ enqueue command it inserts a plug into the outbound queue that causes
+ following packets to enqueue until a dequeue command arrives over
+ netlink, releasing packets up to the plug for delivery.
+
+ This module provides "output buffering" functionality in the Remus HA
+ project. It enables speculative execution of virtual machines by allowing
+ the generated network output to be rolled back if needed. For more
+ information, please refer to http://wiki.xensource.com/xenwiki/Remus
+
+ To compile this code as a module, choose M here: the
+ module will be called sch_plug.
+
comment "Classification"
config NET_CLS
diff --git a/net/sched/Makefile b/net/sched/Makefile
index dc5889c..8cdf4e2 100644
--- a/net/sched/Makefile
+++ b/net/sched/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_NET_SCH_MULTIQ) += sch_multiq.o
obj-$(CONFIG_NET_SCH_ATM) += sch_atm.o
obj-$(CONFIG_NET_SCH_NETEM) += sch_netem.o
obj-$(CONFIG_NET_SCH_DRR) += sch_drr.o
+obj-$(CONFIG_NET_SCH_PLUG) += sch_plug.o
obj-$(CONFIG_NET_SCH_MQPRIO) += sch_mqprio.o
obj-$(CONFIG_NET_SCH_CHOKE) += sch_choke.o
obj-$(CONFIG_NET_SCH_QFQ) += sch_qfq.o
diff --git a/net/sched/sch_plug.c b/net/sched/sch_plug.c
new file mode 100644
index 0000000..7436498
--- /dev/null
+++ b/net/sched/sch_plug.c
@@ -0,0 +1,159 @@
+/*
+ * sch_plug.c Queue traffic until an explicit release command
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * The operation of the buffer is as follows:
+ * When a checkpoint begins, a plug is inserted into the
+ * network queue by a netlink request (it operates by storing
+ * a pointer to the next packet which arrives and blocking dequeue
+ * when that packet is at the head of the queue).
+ * When a checkpoint completes (the backup acknowledges receipt),
+ * currently-queued packets are released.
+ * So it supports two operations, plug and unplug.
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/netdevice.h>
+#include <linux/skbuff.h>
+#include <net/pkt_sched.h>
+
+#define FIFO_BUF (10*1024*1024)
+
+#define TCQ_PLUG 0
+#define TCQ_UNPLUG 1
+
+struct plug_sched_data {
+ /*
+ * stop points to the first packet which should not be
+ * delivered. If it is NULL, plug_enqueue will set it to the
+ * next packet it sees.
+ *
+ * release is the last packet in the fifo that can be
+ * released.
+ */
+ struct sk_buff *stop, *release;
+};
+
+struct tc_plug_qopt {
+ /* 0: reset stop packet pointer
+ * 1: dequeue to release pointer */
+ int action;
+};
+
+static int skb_remove_foreign_references(struct sk_buff *skb)
+{
+ return !skb_linearize(skb);
+}
+
+static int plug_enqueue(struct sk_buff *skb, struct Qdisc* sch)
+{
+ struct plug_sched_data *q = qdisc_priv(sch);
+
+ if (likely(sch->qstats.backlog + skb->len <= FIFO_BUF)) {
+ if (!q->stop)
+ q->stop = skb;
+
+ if (!skb_remove_foreign_references(skb)) {
+ printk(KERN_DEBUG "error removing foreign ref\n");
+ return qdisc_reshape_fail(skb, sch);
+ }
+
+ return qdisc_enqueue_tail(skb, sch);
+ }
+ printk(KERN_WARNING "queue reported full: %d,%d\n",
+ sch->qstats.backlog, skb->len);
+
+ return qdisc_reshape_fail(skb, sch);
+}
+
+/* dequeue doesn't actually dequeue until the release command is
+ * received. */
+static struct sk_buff *plug_dequeue(struct Qdisc* sch)
+{
+ struct plug_sched_data *q = qdisc_priv(sch);
+ struct sk_buff *peek;
+
+ if (qdisc_is_throttled(sch))
+ return NULL;
+
+ peek = (struct sk_buff *)((sch->q).next);
+
+ /* this pointer comparison may be shady */
+ if (peek == q->release) {
+ /*
+ * This is the tail of the last round. Release it and
+ * block the queue
+ */
+ qdisc_throttled(sch);
+ return NULL;
+ }
+
+ return qdisc_dequeue_head(sch);
+}
+
+static int plug_init(struct Qdisc *sch, struct nlattr *opt)
+{
+ qdisc_throttled(sch);
+ return 0;
+}
+
+/*
+ * receives two messages:
+ * 0: checkpoint queue (set stop to next packet)
+ * 1: dequeue until stop
+ */
+static int plug_change(struct Qdisc *sch, struct nlattr *opt)
+{
+ struct plug_sched_data *q = qdisc_priv(sch);
+ struct tc_plug_qopt *msg;
+
+ if (!opt || nla_len(opt) < sizeof(*msg))
+ return -EINVAL;
+
+ msg = nla_data(opt);
+
+ if (msg->action == TCQ_PLUG) {
+ /* reset stop */
+ q->stop = NULL;
+ } else if (msg->action == TCQ_UNPLUG) {
+ /* dequeue */
+ q->release = q->stop;
+ qdisc_unthrottled(sch);
+ netif_schedule_queue(sch->dev_queue);
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+struct Qdisc_ops plug_qdisc_ops = {
+ .id = "plug",
+ .priv_size = sizeof(struct plug_sched_data),
+ .enqueue = plug_enqueue,
+ .dequeue = plug_dequeue,
+ .peek = qdisc_peek_head,
+ .init = plug_init,
+ .change = plug_change,
+ .owner = THIS_MODULE,
+};
+
+static int __init plug_module_init(void)
+{
+ return register_qdisc(&plug_qdisc_ops);
+}
+
+static void __exit plug_module_exit(void)
+{
+ unregister_qdisc(&plug_qdisc_ops);
+}
+module_init(plug_module_init)
+module_exit(plug_module_exit)
+MODULE_LICENSE("GPL");
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] asix: new device id
From: David Miller @ 2011-12-19 21:25 UTC (permalink / raw)
To: grundler; +Cc: aurel, netdev, allan, freddy
In-Reply-To: <CANEJEGswxaxgD9eet9uDZm6Ezf67ibG0XOTggSBONZ6M1KMErA@mail.gmail.com>
From: Grant Grundler <grundler@google.com>
Date: Mon, 19 Dec 2011 13:22:35 -0800
> I'm really the wrong guy to ask though. I don't have the device
> and I'm not associated with the mfg.
Strongly disagree.
When you make changes to a driver, in fact you've made the most
recent 5 or 6, it's like "tag, you're it" :-)
Just so you understand why I am not going to ask random people who
have never submitted a change to the driver whether a change makes
sense or not.
^ permalink raw reply
* Re: [PATCH] net/sched: sch_plug - Queue traffic until an explicit release command
From: Stephen Hemminger @ 2011-12-19 21:32 UTC (permalink / raw)
To: rshriram; +Cc: hadi, netdev, Brendan Cully
In-Reply-To: <1324329752-28459-1-git-send-email-rshriram@cs.ubc.ca>
On Mon, 19 Dec 2011 13:22:32 -0800
rshriram@cs.ubc.ca wrote:
> +
> +static int skb_remove_foreign_references(struct sk_buff *skb)
> +{
> + return !skb_linearize(skb);
> +}
> +
This is silly. Just make qdisc work with fragmented skb's.
^ permalink raw reply
* Re: [PATCH] asix: new device id
From: Grant Grundler @ 2011-12-19 21:34 UTC (permalink / raw)
To: David Miller; +Cc: aurel, netdev, allan, freddy
In-Reply-To: <20111219.162516.1008359598690049381.davem@davemloft.net>
On Mon, Dec 19, 2011 at 1:25 PM, David Miller <davem@davemloft.net> wrote:
> From: Grant Grundler <grundler@google.com>
> Date: Mon, 19 Dec 2011 13:22:35 -0800
>
>> I'm really the wrong guy to ask though. I don't have the device
>> and I'm not associated with the mfg.
>
> Strongly disagree.
>
> When you make changes to a driver, in fact you've made the most
> recent 5 or 6, it's like "tag, you're it" :-)
Fair enough. :) But I'm trying to change that. :) (Have ASIX to
participate in asix.c devel/support).
Acked-by: Grant Grundler <grundler@chromium.org>
The change is "harmless" in that it won't interfere with anything that
works today.
> Just so you understand why I am not going to ask random people who
> have never submitted a change to the driver whether a change makes
> sense or not.
Understood. But I have no clue what driver functionality *will* work
with the new device.
I guess this is the first step to finding out. :)
cheers,
grant
^ permalink raw reply
* Re: [PATCH net-next] be2net: Fix INTx processing for Lancer
From: David Miller @ 2011-12-19 21:34 UTC (permalink / raw)
To: padmanabh.ratnakar; +Cc: netdev
In-Reply-To: <607e9a88-8d23-4cca-8aff-07578855b0e8@exht1.ad.emulex.com>
From: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Date: Mon, 19 Dec 2011 17:23:35 +0530
> Lancer does not have HW registers to indicate the EQ causing the INTx
> interrupt. As a result EQE entries of one EQ may be consumed when interrupt
> is caused by another EQ. Fix this by arming CQs at the end of NAPI poll
> routine to regenerate the EQEs.
>
> Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/sched: sch_plug - Queue traffic until an explicit release command
From: David Miller @ 2011-12-19 21:35 UTC (permalink / raw)
To: rshriram; +Cc: hadi, netdev, brendan
In-Reply-To: <1324329752-28459-1-git-send-email-rshriram@cs.ubc.ca>
From: rshriram@cs.ubc.ca
Date: Mon, 19 Dec 2011 13:22:32 -0800
> +#define FIFO_BUF (10*1024*1024)
This limit is, at best, extremely arbitrary.
^ permalink raw reply
* Re: [PATCH] stmmac: reduce queue lengths if MTU is very large
From: David Miller @ 2011-12-19 21:33 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, rubini, giancarlo.asnaghi
In-Reply-To: <1324273530-18499-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Mon, 19 Dec 2011 06:45:30 +0100
> From: Alessandro Rubini <rubini@gnudd.com>
>
> In my use case (STA2X11 IO-Hub), the alloc_coherent, map_single and
> friends map to a reserved area set up in swiotlb. With the default
> MTU each packet takes 2kB, but with jumbo frames it increases to 16kB
> and consumes up my area (it takes 8MB instead of 1MB).
>
> Instead of increasing the reserved (== wasted) preallocated area in
> swiotlb, this patch rescales the user-selected queue lengths if the MTU
> is modified at runtime to be larger than the default. User choices
> are still obeyed (compiled default, module parameter, command line)
>
> Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
> Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
This change doesn't make sense.
If the user is only sending/receiving small frames, then this patch
will hurt them.
I'm not applying this, it just points out that the amount of reserved
space in your SWIOMMU setup might be insufficient for this situation
rather than something that should be tweaked in this driver.
^ 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