* Re: [PATCH 11/13] udp_diag: Implement the get_exact dumping functionality
From: Pavel Emelyanov @ 2011-12-10 9:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1323467297.4016.10.camel@edumazet-laptop>
On 12/10/2011 01:48 AM, Eric Dumazet wrote:
> Le vendredi 09 décembre 2011 à 20:24 +0400, Pavel Emelyanov a écrit :
>> Do the same as TCP does -- lookup a socket in the given udp_table,
>> check cookie, fill the reply message with existing inet socket dumping
>> helper and send one back.
>>
>> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
>
>> +
>> + if (req->sdiag_family == AF_INET)
>> + sk = __udp4_lib_lookup(&init_net,
>> + req->id.idiag_src[0], req->id.idiag_sport,
>> + req->id.idiag_dst[0], req->id.idiag_dport,
>> + req->id.idiag_if, tbl);
>> + else if (req->sdiag_family == AF_INET6)
>> + sk = __udp6_lib_lookup(&init_net,
>> + (struct in6_addr *)req->id.idiag_src,
>> + req->id.idiag_sport,
>> + (struct in6_addr *)req->id.idiag_dst,
>> + req->id.idiag_dport,
>> + req->id.idiag_if, tbl);
>> + else
>
> OK, but what happens if IPv6 is a module ?
And the udp_diag is built-in, right?
> LD .tmp_vmlinux1
> net/built-in.o: In function `udp_dump_one':
> udp_diag.c:(.text+0xa2b40): undefined reference to `__udp6_lib_lookup'
> make: *** [.tmp_vmlinux1] Erreur 1
Crap :( I suppose the Kconfig rule should be fixed, I will try to provide a fix...
Thanks,
Pavel
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 000000000000002c
From: Stefan Priebe @ 2011-12-10 9:03 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, jwboyer, hch, netdev, david, stable, gregkh
In-Reply-To: <20111209.142117.357254752872525966.davem@davemloft.net>
Am 09.12.2011 20:21, schrieb David Miller:
> From: Stefan Priebe<s.priebe@profihost.ag>
> Date: Fri, 09 Dec 2011 20:01:26 +0100
>
>> any news on that? Systems still crashing every now and then. 3.0.13
>> was released today but i haven't seen any of them.
>
> I only had time to submit these fixes for 3.1.x-stable, you'll just
> have to be incredibly patient.
is it this whole set of 13 patches?
http://www.spinics.net/lists/netdev/msg182508.html
i will then try to backport them.
Stefan
^ permalink raw reply
* [PATCH 03/16] mac_sonic: add irq resources and cleanup
From: Finn Thain @ 2011-12-10 5:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-m68k, Geert Uytterhoeven
In-Reply-To: <20111023141124.538715283@telegraphics.com.au>
Make better use of the SONIC platform device by adding irq resources.
This moves the via_type logic out of the NIC device driver which
improves modularity.
Since interrupt handlers now run with CPU interrupts disabled, we don't
need the macsonic_interrupt() wrapper. Remove it.
For consistency, rename retval as err.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
Re-sending unchanged. Still needs the right ack.
Index: linux-m68k/arch/m68k/mac/config.c
===================================================================
--- linux-m68k.orig/arch/m68k/mac/config.c 2011-10-22 23:02:22.000000000 +1100
+++ linux-m68k/arch/m68k/mac/config.c 2011-10-23 00:51:11.000000000 +1100
@@ -936,9 +936,16 @@ static struct platform_device esp_1_pdev
.id = 1,
};
+static struct resource sonic_rsrcs[] = {
+ { .flags = IORESOURCE_IRQ },
+ { .flags = IORESOURCE_IRQ },
+};
+
static struct platform_device sonic_pdev = {
.name = "macsonic",
.id = -1,
+ .num_resources = ARRAY_SIZE(sonic_rsrcs),
+ .resource = sonic_rsrcs,
};
static struct platform_device mace_pdev = {
@@ -1002,6 +1009,10 @@ int __init mac_platform_init(void)
switch (macintosh_config->ether_type) {
case MAC_ETHER_SONIC:
+ sonic_rsrcs[0].start = sonic_rsrcs[0].end = IRQ_NUBUS_9;
+ if (via_alt_mapping)
+ sonic_rsrcs[1].start = sonic_rsrcs[1].end = IRQ_AUTO_3;
+
platform_device_register(&sonic_pdev);
break;
case MAC_ETHER_MACE:
Index: linux-m68k/drivers/net/macsonic.c
===================================================================
--- linux-m68k.orig/drivers/net/macsonic.c 2011-10-22 23:02:38.000000000 +1100
+++ linux-m68k/drivers/net/macsonic.c 2011-10-22 23:02:38.000000000 +1100
@@ -60,7 +60,6 @@
#include <asm/dma.h>
#include <asm/macintosh.h>
#include <asm/macints.h>
-#include <asm/mac_via.h>
static char mac_sonic_string[] = "macsonic";
@@ -127,61 +126,49 @@ static inline void bit_reverse_addr(unsi
addr[i] = bitrev8(addr[i]);
}
-static irqreturn_t macsonic_interrupt(int irq, void *dev_id)
-{
- irqreturn_t result;
- unsigned long flags;
-
- local_irq_save(flags);
- result = sonic_interrupt(irq, dev_id);
- local_irq_restore(flags);
- return result;
-}
-
static int macsonic_open(struct net_device* dev)
{
- int retval;
+ struct sonic_local *lp = netdev_priv(dev);
+ int err;
- retval = request_irq(dev->irq, sonic_interrupt, 0, "sonic", dev);
- if (retval) {
- printk(KERN_ERR "%s: unable to get IRQ %d.\n",
- dev->name, dev->irq);
- goto err;
- }
- /* Under the A/UX interrupt scheme, the onboard SONIC interrupt comes
- * in at priority level 3. However, we sometimes get the level 2 inter-
- * rupt as well, which must prevent re-entrance of the sonic handler.
- */
- if (dev->irq == IRQ_AUTO_3) {
- retval = request_irq(IRQ_NUBUS_9, macsonic_interrupt, 0,
- "sonic", dev);
- if (retval) {
- printk(KERN_ERR "%s: unable to get IRQ %d.\n",
- dev->name, IRQ_NUBUS_9);
- goto err_irq;
+ err = request_irq(dev->irq, sonic_interrupt, 0, "SONIC", dev);
+ if (err) {
+ pr_err("%s: unable to get IRQ %d\n", dev->name, dev->irq);
+ goto out;
+ }
+ if (lp->irq1) {
+ err = request_irq(lp->irq1, sonic_interrupt, 0, "SONIC", dev);
+ if (err) {
+ pr_err("%s: unable to get IRQ %d\n",
+ dev->name, lp->irq1);
+ goto out_irq;
}
}
- retval = sonic_open(dev);
- if (retval)
- goto err_irq_nubus;
+ err = sonic_open(dev);
+ if (err)
+ goto out_irq1;
+
return 0;
-err_irq_nubus:
- if (dev->irq == IRQ_AUTO_3)
- free_irq(IRQ_NUBUS_9, dev);
-err_irq:
+out_irq1:
+ if (lp->irq1)
+ free_irq(lp->irq1, dev);
+out_irq:
free_irq(dev->irq, dev);
-err:
- return retval;
+out:
+ return err;
}
static int macsonic_close(struct net_device* dev)
{
+ struct sonic_local *lp = netdev_priv(dev);
int err;
+
err = sonic_close(dev);
+
+ if (lp->irq1)
+ free_irq(lp->irq1, dev);
free_irq(dev->irq, dev);
- if (dev->irq == IRQ_AUTO_3)
- free_irq(IRQ_NUBUS_9, dev);
return err;
}
@@ -310,8 +297,9 @@ static void __devinit mac_onboard_sonic_
random_ether_addr(dev->dev_addr);
}
-static int __devinit mac_onboard_sonic_probe(struct net_device *dev)
+static int __devinit mac_onboard_sonic_probe(struct platform_device *pdev)
{
+ struct net_device *dev = platform_get_drvdata(pdev);
struct sonic_local* lp = netdev_priv(dev);
int sr;
int commslot = 0;
@@ -348,10 +336,12 @@ static int __devinit mac_onboard_sonic_p
/* Danger! My arms are flailing wildly! You *must* set lp->reg_offset
* and dev->base_addr before using SONIC_READ() or SONIC_WRITE() */
dev->base_addr = ONBOARD_SONIC_REGISTERS;
- if (via_alt_mapping)
- dev->irq = IRQ_AUTO_3;
- else
- dev->irq = IRQ_NUBUS_9;
+
+ dev->irq = platform_get_irq(pdev, 0);
+ lp->irq1 = platform_get_irq(pdev, 1);
+
+ if (!dev->irq)
+ return -ENODEV;
if (!sonic_version_printed) {
printk(KERN_INFO "%s", version);
@@ -590,7 +580,7 @@ static int __devinit mac_sonic_probe(str
platform_set_drvdata(pdev, dev);
/* This will catch fatal stuff like -ENOMEM as well as success */
- err = mac_onboard_sonic_probe(dev);
+ err = mac_onboard_sonic_probe(pdev);
if (err == 0)
goto found;
if (err != -ENODEV)
Index: linux-m68k/drivers/net/sonic.h
===================================================================
--- linux-m68k.orig/drivers/net/sonic.h 2011-10-22 23:02:22.000000000 +1100
+++ linux-m68k/drivers/net/sonic.h 2011-10-22 23:02:38.000000000 +1100
@@ -318,6 +318,9 @@ struct sonic_local {
unsigned int eol_rx;
unsigned int eol_tx; /* last unacked transmit packet */
unsigned int next_tx; /* next free TD */
+#ifdef CONFIG_MAC
+ int irq1; /* Second IRQ for Mac Quadras */
+#endif
struct device *device; /* generic device */
struct net_device_stats stats;
};
Index: linux-m68k/arch/m68k/mac/via.c
===================================================================
--- linux-m68k.orig/arch/m68k/mac/via.c 2011-10-22 23:02:38.000000000 +1100
+++ linux-m68k/arch/m68k/mac/via.c 2011-10-23 00:51:10.000000000 +1100
@@ -40,7 +40,6 @@
volatile __u8 *via1, *via2;
int rbv_present;
int via_alt_mapping;
-EXPORT_SYMBOL(via_alt_mapping);
static __u8 rbv_clear;
/*
^ permalink raw reply
* Re: [PATCH v3 REPOST] xen-netfront: delay gARP until backend switches to Connected
From: David Miller @ 2011-12-10 0:24 UTC (permalink / raw)
To: Ian.Campbell
Cc: jeremy, xen-devel, konrad.wilk, netdev, linux-kernel,
virtualization, lersek
In-Reply-To: <1323465781.20936.49.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 9 Dec 2011 21:23:00 +0000
> On Fri, 2011-12-09 at 18:45 +0000, David Miller wrote:
>> From: Laszlo Ersek <lersek@redhat.com>
>> Date: Fri, 9 Dec 2011 12:38:58 +0100
>>
>> > These two together provide complete ordering. Sub-condition (1) is
>> > satisfied by pvops commit 43223efd9bfd.
>>
>> I don't see this commit in Linus's tree,
>
> The referenced commit is in
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#xen/next-2.6.32 some people call the "pvops tree" but there's no reason to expect someone outside the Xen world to know that...
>
> A better reference would have been 6b0b80ca7165 in
> git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history which is the precise branch that was flattened to make f942dc2552b8, which is the upstream commit that added netback, so this change is already in upstream.
I want the commit message fixed so someone seeing the commit ID can
figure out what it actually refers to.
^ permalink raw reply
* [PATCH net-next 1/2] be2net: update some counters to display via ethtool
From: Ajit Khaparde @ 2011-12-09 23:53 UTC (permalink / raw)
To: netdev, davem
update pmem_fifo_overflow_drop, rx_priority_pause_frames counters.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index b8a526f..73fe389 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -316,6 +316,8 @@ static void populate_be3_stats(struct be_adapter *adapter)
struct be_drv_stats *drvs = &adapter->drv_stats;
be_dws_le_to_cpu(hw_stats, sizeof(*hw_stats));
+ drvs->pmem_fifo_overflow_drop = port_stats->pmem_fifo_overflow_drop;
+ drvs->rx_priority_pause_frames = port_stats->rx_priority_pause_frames;
drvs->rx_pause_frames = port_stats->rx_pause_frames;
drvs->rx_crc_errors = port_stats->rx_crc_errors;
drvs->rx_control_frames = port_stats->rx_control_frames;
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next 2/2] be2net: workaround to fix a bug in BE
From: Ajit Khaparde @ 2011-12-09 23:53 UTC (permalink / raw)
To: netdev, davem
disable Tx vlan offloading in certain cases.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 46 ++++++++++++++++++++++-----
1 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 73fe389..62f5514 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -552,11 +552,26 @@ static inline void wrb_fill(struct be_eth_wrb *wrb, u64 addr, int len)
wrb->frag_len = len & ETH_WRB_FRAG_LEN_MASK;
}
+static inline u16 be_get_tx_vlan_tag(struct be_adapter *adapter,
+ struct sk_buff *skb)
+{
+ u8 vlan_prio;
+ u16 vlan_tag;
+
+ vlan_tag = vlan_tx_tag_get(skb);
+ vlan_prio = (vlan_tag & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
+ /* If vlan priority provided by OS is NOT in available bmap */
+ if (!(adapter->vlan_prio_bmap & (1 << vlan_prio)))
+ vlan_tag = (vlan_tag & ~VLAN_PRIO_MASK) |
+ adapter->recommended_prio;
+
+ return vlan_tag;
+}
+
static void wrb_fill_hdr(struct be_adapter *adapter, struct be_eth_hdr_wrb *hdr,
struct sk_buff *skb, u32 wrb_cnt, u32 len)
{
- u8 vlan_prio = 0;
- u16 vlan_tag = 0;
+ u16 vlan_tag;
memset(hdr, 0, sizeof(*hdr));
@@ -587,12 +602,7 @@ static void wrb_fill_hdr(struct be_adapter *adapter, struct be_eth_hdr_wrb *hdr,
if (vlan_tx_tag_present(skb)) {
AMAP_SET_BITS(struct amap_eth_hdr_wrb, vlan, hdr, 1);
- vlan_tag = vlan_tx_tag_get(skb);
- vlan_prio = (vlan_tag & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
- /* If vlan priority provided by OS is NOT in available bmap */
- if (!(adapter->vlan_prio_bmap & (1 << vlan_prio)))
- vlan_tag = (vlan_tag & ~VLAN_PRIO_MASK) |
- adapter->recommended_prio;
+ vlan_tag = be_get_tx_vlan_tag(adapter, skb);
AMAP_SET_BITS(struct amap_eth_hdr_wrb, vlan_tag, hdr, vlan_tag);
}
@@ -695,6 +705,25 @@ static netdev_tx_t be_xmit(struct sk_buff *skb,
u32 start = txq->head;
bool dummy_wrb, stopped = false;
+ /* For vlan tagged pkts, BE
+ * 1) calculates checksum even when CSO is not requested
+ * 2) calculates checksum wrongly for padded pkt less than
+ * 60 bytes long.
+ * As a workaround disable TX vlan offloading in such cases.
+ */
+ if (unlikely(vlan_tx_tag_present(skb) &&
+ (skb->ip_summed != CHECKSUM_PARTIAL || skb->len <= 60))) {
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (unlikely(!skb))
+ goto tx_drop;
+
+ skb = __vlan_put_tag(skb, be_get_tx_vlan_tag(adapter, skb));
+ if (unlikely(!skb))
+ goto tx_drop;
+
+ skb->vlan_tci = 0;
+ }
+
wrb_cnt = wrb_cnt_for_skb(adapter, skb, &dummy_wrb);
copied = make_tx_wrbs(adapter, txq, skb, wrb_cnt, dummy_wrb);
@@ -722,6 +751,7 @@ static netdev_tx_t be_xmit(struct sk_buff *skb,
txq->head = start;
dev_kfree_skb_any(skb);
}
+tx_drop:
return NETDEV_TX_OK;
}
--
1.7.5.4
^ permalink raw reply related
* Latency guarantees in HFSC rt service curves
From: John A. Sullivan III @ 2011-12-09 21:51 UTC (permalink / raw)
To: netdev
Hello, all. Sorry to be SPAMming the list but I think I must have a
fundamental conceptual misunderstanding of HFSC's decoupling of latency
and bandwidth guarantees. I understand how it is done. I understand in
theory why it is critically important. Where I'm failing is seeing how
the current implementation makes any real world difference. I'm sure it
does, I just don't see it.
Here's how I've explained it at the end of the 14 pages of documentation
I've created to try to explain IFB and HFSC from a system
administrator's perspective. As you can see, I'm relying upon the
excellent illustration of this part of HFSC in the SIGCOM97 paper on
page 4:
"To illustrate the advantage of decoupling delay and bandwidth
allocation with non-linear service curves, consider the example in
Figure 2, where a video and a FTP session share a 10 Mbps link . . . .
Let the video source sends 30 8KB frames per second, which corresponds
to a required bandwidth of 2 Mbps. The remaining 8 Mbps is reserved by a
continuously backlogged FTP session. For simplicity, let all packets be
of size 8 KB. Thus, it takes roughly 6.5 ms to transmit a packet."
"As can be seen, the deadlines of the video packets occur every 33 ms,
while the deadlines of the FTP packets occur every 8.2 ms. This results
in a delay of approximately 26 ms for a video packet."
Let's work through the math to make that more understandable. HFSC is
committed to deliver 2 Mbps to video and each packet is 8KB long. Thus,
HFSC's commitment to deliver that packet is within (8000 * 8)bits /
2,000,000(b/s) = 32ms. I'm not quite sure why I come up with 32 and
they say 33 but we'll use 33. In other words, to meet the deadline
based solely upon the rate, the bandwidth part of the rt service curve,
the packet needs to be finished dequeueing at 33ms. Since it only takes
6.5ms to send the packet, HFSC can sit on the packet it received for 33
- 6.5 = 26.5ms. This adds unnecessary latency to the video stream.
In the second scenario, we introduce an initial, elevated bandwidth
guarantee for the first 10ms. The bandwidth for the first 10ms is now
6.6 Mbps instead of 2 Mbps. We do the math again and HFSC's commitment
to video to maintain 6.6 Mbps is to finish dequeueing the packet within
(8000 * 8)bits / 6,600,000(b/s) = 10ms. Since it takes 6.5 ms to send
the packet, HFSC can sit on the packet for no more than 10 - 6.5 = 3.5
ms. Quite a difference!
That's our documentation so I think I get it but here's my problem.
Practically speaking, as long as it's not extreme, latency at the
beginning of a video stream (I'm using video because that is the example
given) is not an issue. The problem is if I introduce latency in the
video stream once it has started. So what is the advantage of starting
the stream in 3.5ms versus 26.5ms? The subsequent packets where latency
really matters are all governed by the m2 curve at 2 Mbps in this
example.
Moreover, let's say I have three video streams which start
simultaneously. Only the first packet of the first stream receives the
6.6Mbps bandwidth guarantee of the first 10ms so the other videos
receive no practical benefit whatsoever from this m1 curve.
I'm sure that's not the case but what am I missing? Thanks - John
^ permalink raw reply
* Re: [PATCH 11/13] udp_diag: Implement the get_exact dumping functionality
From: Eric Dumazet @ 2011-12-09 21:48 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Linux Netdev List
In-Reply-To: <4EE23626.6000104@parallels.com>
Le vendredi 09 décembre 2011 à 20:24 +0400, Pavel Emelyanov a écrit :
> Do the same as TCP does -- lookup a socket in the given udp_table,
> check cookie, fill the reply message with existing inet socket dumping
> helper and send one back.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
> +
> + if (req->sdiag_family == AF_INET)
> + sk = __udp4_lib_lookup(&init_net,
> + req->id.idiag_src[0], req->id.idiag_sport,
> + req->id.idiag_dst[0], req->id.idiag_dport,
> + req->id.idiag_if, tbl);
> + else if (req->sdiag_family == AF_INET6)
> + sk = __udp6_lib_lookup(&init_net,
> + (struct in6_addr *)req->id.idiag_src,
> + req->id.idiag_sport,
> + (struct in6_addr *)req->id.idiag_dst,
> + req->id.idiag_dport,
> + req->id.idiag_if, tbl);
> + else
OK, but what happens if IPv6 is a module ?
LD .tmp_vmlinux1
net/built-in.o: In function `udp_dump_one':
udp_diag.c:(.text+0xa2b40): undefined reference to `__udp6_lib_lookup'
make: *** [.tmp_vmlinux1] Erreur 1
^ permalink raw reply
* Re: [PATCH v3 REPOST] xen-netfront: delay gARP until backend switches to Connected
From: Ian Campbell @ 2011-12-09 21:23 UTC (permalink / raw)
To: David Miller
Cc: lersek@redhat.com, konrad.wilk@oracle.com, jeremy@goop.org,
xen-devel@lists.xensource.com,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20111209.134514.2071890208094978847.davem@davemloft.net>
On Fri, 2011-12-09 at 18:45 +0000, David Miller wrote:
> From: Laszlo Ersek <lersek@redhat.com>
> Date: Fri, 9 Dec 2011 12:38:58 +0100
>
> > These two together provide complete ordering. Sub-condition (1) is
> > satisfied by pvops commit 43223efd9bfd.
>
> I don't see this commit in Linus's tree,
The referenced commit is in
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#xen/next-2.6.32 some people call the "pvops tree" but there's no reason to expect someone outside the Xen world to know that...
A better reference would have been 6b0b80ca7165 in
git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history which is the precise branch that was flattened to make f942dc2552b8, which is the upstream commit that added netback, so this change is already in upstream.
Ian.
^ permalink raw reply
* Re: [GIT PULL nf-next] IPVS
From: Pablo Neira Ayuso @ 2011-12-09 21:13 UTC (permalink / raw)
To: Simon Horman
Cc: Patrick McHardy, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov, Michael Maxim
In-Reply-To: <1323414797-26002-1-git-send-email-horms@verge.net.au>
On Fri, Dec 09, 2011 at 04:13:16PM +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider pulling
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git master
> to obtain and enhancement to the SH scheduelr from Michael Maixim.
>
> This patch includes the changes that you requested; A note about the
> Kconfig change in the changelog and removal of whitespace-only changes.
Pulled, thanks!
^ permalink raw reply
* [PATCH] xfrm: Apply fix for key lengths for rfc3686(ctr(aes)) to 2.6.32.y
From: Calvin Owens @ 2011-12-09 20:29 UTC (permalink / raw)
To: stable
Cc: David S. Miller, netdev, linux-kernel, Greg Kroah-Hartman,
Calvin Owens
This fix was applied to 3.0.3, but was not applied to the earlier series. Several
widely-used distros base (or based) their kernels on this series, so the problem
hasn't been fixed for them. The patch below is against 2.6.32.49.
Original commit was 4203223a1aed862b4445fdcd260d6139603a51d9
Signed-off-by: Calvin Owens <jcalvinowens@gmail.com>
---
net/xfrm/xfrm_algo.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index faf54c6..9bd850a 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -411,8 +411,8 @@ static struct xfrm_algo_desc ealg_list[] = {
.desc = {
.sadb_alg_id = SADB_X_EALG_AESCTR,
.sadb_alg_ivlen = 8,
- .sadb_alg_minbits = 128,
- .sadb_alg_maxbits = 256
+ .sadb_alg_minbits = 160,
+ .sadb_alg_maxbits = 288
}
},
};
--
1.7.4.1
^ permalink raw reply related
* Re: An error in my HFSC sysadmin documentation
From: John A. Sullivan III @ 2011-12-09 19:35 UTC (permalink / raw)
To: netdev
In-Reply-To: <1323455084.3159.63.camel@denise.theartistscloset.com>
On Fri, 2011-12-09 at 13:24 -0500, John A. Sullivan III wrote:
> Hello, all. As I mentioned, I'm trying to compile documentation on IFB
> and HFSC from a sysadmin's perspective but I think I have an error in
> the way I'm explaining how HFSC determines when to send which packet to
> meet bandwidth and latency guarantees of the rt service curve. I'll
> show where my math is breaking down in the hope someone can see and
> correct my error.
Argh!! After walking through it again, correcting my original error and
using much closer rounding, I still hit a problem. I'll paste in the
documentation I've written on deadline time and the walk through of how
it works but, at the very end, Queue B's rt service curve is violated
when it should not be:
<snip>
Deadline time is closely related to eligible time and is likewise
measured against clock time. However, deadline time is measured against
the end or tail of the packet, i.e., by when must we have finished
sending this packet at the specified bandwidth in order to meet our
packet delivery guarantees for bandwidth and latency. Once again,
http://www.sonycsl.co.jp/~kjc/software/TIPS.txt has an excellent ASCII
graphic for illustrating the relationship between eligible time measured
at the beginning of the packet and deadline time measured from the end:
bytes
| /
| /service curve
| /
next -->+ +----------------+
packet | | /|
length | | / |
| | / |
cumulative --> + +------------+ |
bytes | /| |
already | / | |
sent | / | |
/ | |
| |
| |
--------+---+--------------> time
eligible deadline
time
This time, the slope is the rt service curve. The way in which HFSC
chooses from among several different queues all with packets whose
eligible time is greater than current clock time is almost identical to
the way it chooses among backlogged queues with virtual time, viz., it
chooses the packet with the lowest deadline time. Remember that the
steeper the curve, the greater the bandwidth and the shorter the
distance between eligible time and deadline time for the same sized
packet.
Let's walk through a real example. We have Queue A with VoIP traffic -
small, 222 byte packets and an rt service curve bandwidth such that it
takes 0.2ms to send its packets; that equates to roughly 8.88 Mbps ((222
* 8)bits/0.0002s). Let's also assume that we have so much VoIP traffic
that the queue is filled so we always have a VoIP packet asking to be
dequeued. Queue B is sending FTP with large packets and an rt service
curve rate such that each packet takes 2ms to send; this equates to
6.056 Mbps ((1514 * 8)bits/0.002s). Queue B is also completely full.
Let's assume that the maximum bandwidth available is the sum of the
guaranteed bandwidths, viz., 14.936 Mbps. This will allow us to
calculated the progress of clock time, i.e., how long it actually takes
to send each packet. Also remember that each packet has a 4 byte CRC,
and 8 byte preamble, and a 12 byte interframe gap time at least in
traditional Ethernet. Thus to transmit a packet in Queue A, we really
need to transmit 246 bytes and, to transmit one in Queue B, we need to
transmit 1538 bytes. Thus, the elapsed time to send a Queue A packet is
(246 * 8)bits / 14,936,000(b/s) = 0.132ms and the time to transmit a
Queue B packet is (1538 * 8)bits / 14,936,000(b/s) = 0.824ms. Sorry for
all the math but this is what is inside the black box (and a very
simplified version!).
Let's assume that clock time (CT - the actual time) is 1000ms (not
realistic but it makes the explanation easier!). The next packet queued
in Queue A has an ET (eligible time) of 1000ms and the next packet in
Queue B has an ET of 999ms, i.e., both are eligible to be sent. A less
sophisticated traffic shaping algorithm would send the FTP packet first.
However, HFSC calculates the deadline time (DT) for the packet in Queue
A at 1000.2 (1000 + 0.2) and the deadline time for the packet in Queue B
at 1001ms (999 + 2) so it sends A instead since it has the smaller DT.
0.132ms has elapsed in real time so CT is now 1000.132. The
eligible/deadline times (ET/DT) for A and B respectively are
1000.2/1000.4 and 999/1001. Notice that A is no longer eligible to send
because its ET > CT so B is serviced. 0.824ms has elapsed to send B's
packet so CT is now 1000.956. ET/DT for A is still 1000.2/1000.4 but B
has changed to 1001/1003. B just misses being eligible to send but A is
eligible so A is sent. Elapsed time is 0.132, CT is now 1001.088, ET/DT
for A is 1000.4/1000.6. Both A and B are eligible at the same time
again as both their ETs <= CT. A's DT is less than B's DT so A is
serviced.
In fact, A will send 11 packets. Let's see the result after A sends 11
packets. Elapsed time is 11* 0.132 = 1.452ms so clock time is 1002.54.
A's ET/DT have incremented by 11 * 0.2 so they are 1002.6/1002.8. B's
ET/DT have remained at 1001/1003. A is no longer eligible so the fact
that its DT is less than B's DT is irrelevant. B is serviced.
Here's the problem. B is serviced when clock time is 1002.54. It takes
0.824 to send B's packet so it has finished dequeueing at 1002.54 +
0.824 = 1003.364 which violates B's deadline time of 1003. That seems
too big for a rounding error. Where am I wrong? Thanks - John
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 000000000000002c
From: David Miller @ 2011-12-09 19:21 UTC (permalink / raw)
To: s.priebe; +Cc: eric.dumazet, jwboyer, hch, netdev, david, stable, gregkh
In-Reply-To: <4EE25B06.7010907@profihost.ag>
From: Stefan Priebe <s.priebe@profihost.ag>
Date: Fri, 09 Dec 2011 20:01:26 +0100
> any news on that? Systems still crashing every now and then. 3.0.13
> was released today but i haven't seen any of them.
I only had time to submit these fixes for 3.1.x-stable, you'll just
have to be incredibly patient.
^ permalink raw reply
* pull request: wirelss 2011-12-09
From: John W. Linville @ 2011-12-09 19:22 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 16546 bytes --]
commit e7ab5f1c323e137120561daeec75e91a1bd9ec8b
Dave,
This is a collection of fixes intended for 3.2.
Gustavo describes the Blueooth bits thusly: "Some fixes for 3.2:
support for a new Marvell device, two module reference fixes, a memory
leak fix and finally a check in a HCI version check."
Additionally, we have an ath9k fix for a regression on single-stream
chips, a mac80211 fix for a race in aggregation start (looks big due
to moving some functions to avoid forward declarations), a fix for
some improper power state management in the rtlwifi suite, and a fix
for an ssb init regression on some SoCs.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 1af32f0fcf33ddca52c8fd2b5bc84c129dcb1bdd:
Merge branch 'batman-adv/maint' of git://git.open-mesh.org/linux-merge (2011-12-07 15:06:33 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
Andrei Emeltchenko (1):
Bluetooth: Correct version check in hci_setup
Bing Zhao (1):
Bluetooth: btmrvl: support Marvell Bluetooth device SD8797
Cong Wang (1):
btusb: fix a memory leak in btusb_send_frame()
David Herrmann (2):
Bluetooth: cmtp: Fix module reference
Bluetooth: bnep: Fix module reference
Felix Fietkau (1):
ath9k: fix check for antenna diversity support
Hauke Mehrtens (1):
ssb: fix init regression with SoCs
Johannes Berg (1):
mac80211: fix another race in aggregation start
John W. Linville (2):
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Philipp Dreimann (1):
rtl8192{ce,cu,de,se}: avoid problems because of possible ERFOFF -> ERFSLEEP transition
drivers/bluetooth/Kconfig | 6 +-
drivers/bluetooth/btmrvl_sdio.c | 15 ++++-
drivers/bluetooth/btusb.c | 3 +-
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192ce/phy.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192cu/phy.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 2 +-
drivers/ssb/driver_pcicore.c | 8 ++-
net/bluetooth/bnep/core.c | 8 +--
net/bluetooth/cmtp/core.c | 5 +-
net/bluetooth/hci_event.c | 2 +-
net/mac80211/agg-tx.c | 86 ++++++++++++-------------
13 files changed, 76 insertions(+), 67 deletions(-)
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 11b41fd..5ccf142 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -188,7 +188,7 @@ config BT_MRVL
The core driver to support Marvell Bluetooth devices.
This driver is required if you want to support
- Marvell Bluetooth devices, such as 8688/8787.
+ Marvell Bluetooth devices, such as 8688/8787/8797.
Say Y here to compile Marvell Bluetooth driver
into the kernel or say M to compile it as module.
@@ -201,8 +201,8 @@ config BT_MRVL_SDIO
The driver for Marvell Bluetooth chipsets with SDIO interface.
This driver is required if you want to use Marvell Bluetooth
- devices with SDIO interface. Currently SD8688/SD8787 chipsets are
- supported.
+ devices with SDIO interface. Currently SD8688/SD8787/SD8797
+ chipsets are supported.
Say Y here to compile support for Marvell BT-over-SDIO driver
into the kernel or say M to compile it as module.
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 9ef4816..27b74b0 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -65,7 +65,7 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_8688 = {
.io_port_1 = 0x01,
.io_port_2 = 0x02,
};
-static const struct btmrvl_sdio_card_reg btmrvl_reg_8787 = {
+static const struct btmrvl_sdio_card_reg btmrvl_reg_87xx = {
.cfg = 0x00,
.host_int_mask = 0x02,
.host_intstatus = 0x03,
@@ -92,7 +92,14 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
.helper = NULL,
.firmware = "mrvl/sd8787_uapsta.bin",
- .reg = &btmrvl_reg_8787,
+ .reg = &btmrvl_reg_87xx,
+ .sd_blksz_fw_dl = 256,
+};
+
+static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
+ .helper = NULL,
+ .firmware = "mrvl/sd8797_uapsta.bin",
+ .reg = &btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -103,6 +110,9 @@ static const struct sdio_device_id btmrvl_sdio_ids[] = {
/* Marvell SD8787 Bluetooth device */
{ SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, 0x911A),
.driver_data = (unsigned long) &btmrvl_sdio_sd8787 },
+ /* Marvell SD8797 Bluetooth device */
+ { SDIO_DEVICE(SDIO_VENDOR_ID_MARVELL, 0x912A),
+ .driver_data = (unsigned long) &btmrvl_sdio_sd8797 },
{ } /* Terminating entry */
};
@@ -1076,3 +1086,4 @@ MODULE_LICENSE("GPL v2");
MODULE_FIRMWARE("sd8688_helper.bin");
MODULE_FIRMWARE("sd8688.bin");
MODULE_FIRMWARE("mrvl/sd8787_uapsta.bin");
+MODULE_FIRMWARE("mrvl/sd8797_uapsta.bin");
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index fe4ebc3..eabc437 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -777,9 +777,8 @@ skip_waking:
usb_mark_last_busy(data->udev);
}
- usb_free_urb(urb);
-
done:
+ usb_free_urb(urb);
return err;
}
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 93fbe6f..d2348a5 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -286,7 +286,7 @@ static bool ath_complete_reset(struct ath_softc *sc, bool start)
ath_start_ani(common);
}
- if (ath9k_hw_ops(ah)->antdiv_comb_conf_get && sc->ant_rx != 3) {
+ if ((ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) && sc->ant_rx != 3) {
struct ath_hw_antcomb_conf div_ant_conf;
u8 lna_conf;
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
index 592a10a..3b585aa 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
@@ -569,7 +569,7 @@ static bool _rtl92ce_phy_set_rf_power_state(struct ieee80211_hw *hw,
}
case ERFSLEEP:{
if (ppsc->rfpwr_state == ERFOFF)
- break;
+ return false;
for (queue_id = 0, i = 0;
queue_id < RTL_PCI_MAX_TX_QUEUE_COUNT;) {
ring = &pcipriv->dev.tx_ring[queue_id];
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c b/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c
index 7285290..e49cf22 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c
@@ -548,7 +548,7 @@ static bool _rtl92cu_phy_set_rf_power_state(struct ieee80211_hw *hw,
break;
case ERFSLEEP:
if (ppsc->rfpwr_state == ERFOFF)
- break;
+ return false;
for (queue_id = 0, i = 0;
queue_id < RTL_PCI_MAX_TX_QUEUE_COUNT;) {
ring = &pcipriv->dev.tx_ring[queue_id];
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
index 3ac7af1..0883349 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
@@ -3374,7 +3374,7 @@ bool rtl92d_phy_set_rf_power_state(struct ieee80211_hw *hw,
break;
case ERFSLEEP:
if (ppsc->rfpwr_state == ERFOFF)
- break;
+ return false;
for (queue_id = 0, i = 0;
queue_id < RTL_PCI_MAX_TX_QUEUE_COUNT;) {
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
index f27171a..f10ac1a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
@@ -602,7 +602,7 @@ bool rtl92s_phy_set_rf_power_state(struct ieee80211_hw *hw,
}
case ERFSLEEP:
if (ppsc->rfpwr_state == ERFOFF)
- break;
+ return false;
for (queue_id = 0, i = 0;
queue_id < RTL_PCI_MAX_TX_QUEUE_COUNT;) {
diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c
index 84c934c..520e828 100644
--- a/drivers/ssb/driver_pcicore.c
+++ b/drivers/ssb/driver_pcicore.c
@@ -517,10 +517,14 @@ static void ssb_pcicore_pcie_setup_workarounds(struct ssb_pcicore *pc)
static void __devinit ssb_pcicore_init_clientmode(struct ssb_pcicore *pc)
{
- ssb_pcicore_fix_sprom_core_index(pc);
+ struct ssb_device *pdev = pc->dev;
+ struct ssb_bus *bus = pdev->bus;
+
+ if (bus->bustype == SSB_BUSTYPE_PCI)
+ ssb_pcicore_fix_sprom_core_index(pc);
/* Disable PCI interrupts. */
- ssb_write32(pc->dev, SSB_INTVEC, 0);
+ ssb_write32(pdev, SSB_INTVEC, 0);
/* Additional PCIe always once-executed workarounds */
if (pc->dev->id.coreid == SSB_DEV_PCIE) {
diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
index 91bcd3a..1eea820 100644
--- a/net/bluetooth/bnep/core.c
+++ b/net/bluetooth/bnep/core.c
@@ -79,17 +79,12 @@ static struct bnep_session *__bnep_get_session(u8 *dst)
static void __bnep_link_session(struct bnep_session *s)
{
- /* It's safe to call __module_get() here because sessions are added
- by the socket layer which has to hold the reference to this module.
- */
- __module_get(THIS_MODULE);
list_add(&s->list, &bnep_session_list);
}
static void __bnep_unlink_session(struct bnep_session *s)
{
list_del(&s->list);
- module_put(THIS_MODULE);
}
static int bnep_send(struct bnep_session *s, void *data, size_t len)
@@ -530,6 +525,7 @@ static int bnep_session(void *arg)
up_write(&bnep_session_sem);
free_netdev(dev);
+ module_put_and_exit(0);
return 0;
}
@@ -616,9 +612,11 @@ int bnep_add_connection(struct bnep_connadd_req *req, struct socket *sock)
__bnep_link_session(s);
+ __module_get(THIS_MODULE);
s->task = kthread_run(bnep_session, s, "kbnepd %s", dev->name);
if (IS_ERR(s->task)) {
/* Session thread start failed, gotta cleanup. */
+ module_put(THIS_MODULE);
unregister_netdev(dev);
__bnep_unlink_session(s);
err = PTR_ERR(s->task);
diff --git a/net/bluetooth/cmtp/core.c b/net/bluetooth/cmtp/core.c
index 7d00ddf..5a6e634 100644
--- a/net/bluetooth/cmtp/core.c
+++ b/net/bluetooth/cmtp/core.c
@@ -67,14 +67,12 @@ static struct cmtp_session *__cmtp_get_session(bdaddr_t *bdaddr)
static void __cmtp_link_session(struct cmtp_session *session)
{
- __module_get(THIS_MODULE);
list_add(&session->list, &cmtp_session_list);
}
static void __cmtp_unlink_session(struct cmtp_session *session)
{
list_del(&session->list);
- module_put(THIS_MODULE);
}
static void __cmtp_copy_session(struct cmtp_session *session, struct cmtp_conninfo *ci)
@@ -327,6 +325,7 @@ static int cmtp_session(void *arg)
up_write(&cmtp_session_sem);
kfree(session);
+ module_put_and_exit(0);
return 0;
}
@@ -376,9 +375,11 @@ int cmtp_add_connection(struct cmtp_connadd_req *req, struct socket *sock)
__cmtp_link_session(session);
+ __module_get(THIS_MODULE);
session->task = kthread_run(cmtp_session, session, "kcmtpd_ctr_%d",
session->num);
if (IS_ERR(session->task)) {
+ module_put(THIS_MODULE);
err = PTR_ERR(session->task);
goto unlink;
}
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index d7d96b6..643a41b 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -545,7 +545,7 @@ static void hci_setup(struct hci_dev *hdev)
{
hci_setup_event_mask(hdev);
- if (hdev->lmp_ver > 1)
+ if (hdev->hci_ver > 1)
hci_send_cmd(hdev, HCI_OP_READ_LOCAL_COMMANDS, 0, NULL);
if (hdev->features[6] & LMP_SIMPLE_PAIR) {
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index b064e4d..2e4b961 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -303,6 +303,38 @@ ieee80211_wake_queue_agg(struct ieee80211_local *local, int tid)
__release(agg_queue);
}
+/*
+ * splice packets from the STA's pending to the local pending,
+ * requires a call to ieee80211_agg_splice_finish later
+ */
+static void __acquires(agg_queue)
+ieee80211_agg_splice_packets(struct ieee80211_local *local,
+ struct tid_ampdu_tx *tid_tx, u16 tid)
+{
+ int queue = ieee80211_ac_from_tid(tid);
+ unsigned long flags;
+
+ ieee80211_stop_queue_agg(local, tid);
+
+ if (WARN(!tid_tx, "TID %d gone but expected when splicing aggregates"
+ " from the pending queue\n", tid))
+ return;
+
+ if (!skb_queue_empty(&tid_tx->pending)) {
+ spin_lock_irqsave(&local->queue_stop_reason_lock, flags);
+ /* copy over remaining packets */
+ skb_queue_splice_tail_init(&tid_tx->pending,
+ &local->pending[queue]);
+ spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags);
+ }
+}
+
+static void __releases(agg_queue)
+ieee80211_agg_splice_finish(struct ieee80211_local *local, u16 tid)
+{
+ ieee80211_wake_queue_agg(local, tid);
+}
+
void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid)
{
struct tid_ampdu_tx *tid_tx;
@@ -314,19 +346,17 @@ void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid)
tid_tx = rcu_dereference_protected_tid_tx(sta, tid);
/*
- * While we're asking the driver about the aggregation,
- * stop the AC queue so that we don't have to worry
- * about frames that came in while we were doing that,
- * which would require us to put them to the AC pending
- * afterwards which just makes the code more complex.
+ * Start queuing up packets for this aggregation session.
+ * We're going to release them once the driver is OK with
+ * that.
*/
- ieee80211_stop_queue_agg(local, tid);
-
clear_bit(HT_AGG_STATE_WANT_START, &tid_tx->state);
/*
- * make sure no packets are being processed to get
- * valid starting sequence number
+ * Make sure no packets are being processed. This ensures that
+ * we have a valid starting sequence number and that in-flight
+ * packets have been flushed out and no packets for this TID
+ * will go into the driver during the ampdu_action call.
*/
synchronize_net();
@@ -340,17 +370,15 @@ void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid)
" tid %d\n", tid);
#endif
spin_lock_bh(&sta->lock);
+ ieee80211_agg_splice_packets(local, tid_tx, tid);
ieee80211_assign_tid_tx(sta, tid, NULL);
+ ieee80211_agg_splice_finish(local, tid);
spin_unlock_bh(&sta->lock);
- ieee80211_wake_queue_agg(local, tid);
kfree_rcu(tid_tx, rcu_head);
return;
}
- /* we can take packets again now */
- ieee80211_wake_queue_agg(local, tid);
-
/* activate the timer for the recipient's addBA response */
mod_timer(&tid_tx->addba_resp_timer, jiffies + ADDBA_RESP_INTERVAL);
#ifdef CONFIG_MAC80211_HT_DEBUG
@@ -466,38 +494,6 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
}
EXPORT_SYMBOL(ieee80211_start_tx_ba_session);
-/*
- * splice packets from the STA's pending to the local pending,
- * requires a call to ieee80211_agg_splice_finish later
- */
-static void __acquires(agg_queue)
-ieee80211_agg_splice_packets(struct ieee80211_local *local,
- struct tid_ampdu_tx *tid_tx, u16 tid)
-{
- int queue = ieee80211_ac_from_tid(tid);
- unsigned long flags;
-
- ieee80211_stop_queue_agg(local, tid);
-
- if (WARN(!tid_tx, "TID %d gone but expected when splicing aggregates"
- " from the pending queue\n", tid))
- return;
-
- if (!skb_queue_empty(&tid_tx->pending)) {
- spin_lock_irqsave(&local->queue_stop_reason_lock, flags);
- /* copy over remaining packets */
- skb_queue_splice_tail_init(&tid_tx->pending,
- &local->pending[queue]);
- spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags);
- }
-}
-
-static void __releases(agg_queue)
-ieee80211_agg_splice_finish(struct ieee80211_local *local, u16 tid)
-{
- ieee80211_wake_queue_agg(local, tid);
-}
-
static void ieee80211_agg_tx_operational(struct ieee80211_local *local,
struct sta_info *sta, u16 tid)
{
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH 0/13] Implement dumping udp sockets via sock_diag netlink
From: David Miller @ 2011-12-09 19:19 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <4EE23561.5020804@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Fri, 09 Dec 2011 20:20:49 +0400
> This is an extension of inet_diag module and the new udp_diag one. Plus
> the patch for iproute's ss to dump udp sockets via netlink (applies on top
> of previous patch for new NETLINK_SOCK_DIAG API [1]).
I like it :-) All applied, thanks!
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 000000000000002c
From: Stefan Priebe @ 2011-12-09 19:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: Josh Boyer, Christoph Hellwig, netdev, Dave Chinner, stable,
Greg KH
In-Reply-To: <4ED86B79.4060506@profihost.ag>
Am 02.12.2011 07:08, schrieb Stefan Priebe - Profihost AG:
> Am 01.12.2011 22:05, schrieb Eric Dumazet:
>> Le jeudi 01 décembre 2011 à 15:37 -0500, Josh Boyer a écrit :
>>
>>> Did you mean f2c31e32bf2c31e32b378a665 ?
>>
>> Oh well, yes ;)
>>
>>>> But this patch needs some followup patches (some of them in David net
>>>> tree, not yet in Linus tree)
>>>
>>> 9de79c127cccecb11ae6a21ab1499e87aa222880 (net: fix potential neighbour
>>> race in dst_ifdown()) is in Linus' tree. Which others are missing?
>>
>> Hmm
>>
>> Linus tree :
>>
>> commit 580da35a31f91a594f3090b7a2c39b85cb051a12
>> IB: Fix RCU lockdep splats
>>
>> David tree :
>>
>> commit 218fa90f072e4aeff9003d57e390857f4f35513e
>> ipv4: fix lockdep splat in rt_cache_seq_show
>>
>> commit f7e57044eeb1841847c24aa06766c8290c202583
>> sch_teql: fix lockdep splat
>>
Hi,
any news on that? Systems still crashing every now and then. 3.0.13 was
released today but i haven't seen any of them.
Thanks!
Stefan
^ permalink raw reply
* Re: [PATCH net-next] sch_red: generalize accurate MAX_P support to RED/GRED/CHOKE
From: David Miller @ 2011-12-09 18:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, dave.taht, netdev, hagen
In-Reply-To: <1323434805.2336.16.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 09 Dec 2011 13:46:45 +0100
> Now RED uses a Q0.32 number to store max_p (max probability), allow
> RED/GRED/CHOKE to use/report full resolution at config/dump time.
>
> Old tc binaries are non aware of new attributes, and still set/get Plog.
>
> New tc binary set/get both Plog and max_p for backward compatibility,
> they display "probability value" if they get max_p from new kernels.
>
> # tc -d qdisc show dev ...
> ...
> qdisc red 10: parent 1:1 limit 360Kb min 30Kb max 90Kb ecn ewma 5
> probability 0.09 Scell_log 15
>
> Make sure we avoid potential divides by 0 in reciprocal_value(), if
> (max_th - min_th) is big.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 REPOST] xen-netfront: delay gARP until backend switches to Connected
From: David Miller @ 2011-12-09 18:45 UTC (permalink / raw)
To: lersek
Cc: ian.campbell, konrad.wilk, jeremy, xen-devel, virtualization,
netdev, linux-kernel
In-Reply-To: <1323430738-3798-1-git-send-email-lersek@redhat.com>
From: Laszlo Ersek <lersek@redhat.com>
Date: Fri, 9 Dec 2011 12:38:58 +0100
> These two together provide complete ordering. Sub-condition (1) is
> satisfied by pvops commit 43223efd9bfd.
I don't see this commit in Linus's tree, so I doubt it's valid for
me to apply this as a bug fix to my 'net' tree since the precondition
pvops commit isn't upstream as far as I can tell.
Where did you intend me to apply this patch, and how did you expect
the dependent commit to make it's way into the tree so that this
fix is complete?
BTW, you should always explicitly specificy the answers to all the
questions in the previous paragraph, otherwise (like right now) we
go back and forth wasting time establishing these facts.
The way to say which tree the patch is intended for is to specify
it in the Subject like, f.e. "[PATCH net-next v3 REPOST] ..."
^ permalink raw reply
* Re: [PATCH] Revert "net: netprio_cgroup: make net_prio_subsys static"
From: David Miller @ 2011-12-09 18:39 UTC (permalink / raw)
To: john.r.fastabend; +Cc: nhorman, eric.dumazet, netdev
In-Reply-To: <20111209170325.26422.11885.stgit@jf-dev1-dcblab>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Fri, 09 Dec 2011 09:03:25 -0800
> This reverts commit 865d9f9f748fdc1943679ea65d9ee1dc55e4a6ae.
>
> This commit breaks the build with CONFIG_NETPRIO_CGROUP=y so
> revert it. It does build as a module though. The SUBSYS macro
> in the cgroup core code automatically defines a subsys structure
> as extern. Long term we should fix the macro. And I need to
> fully build test things.
>
> Tested with CONFIG_NETPRIO_CGROUP={y|m|n} with and without
> CONFIG_CGROUPS defined.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> CC: Neil Horman <nhorman@tuxdriver.com>
> Reported-By: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/4] skb paged fragment destructors
From: David Miller @ 2011-12-09 18:34 UTC (permalink / raw)
To: Ian.Campbell; +Cc: eric.dumazet, jesse.brandeburg, netdev
In-Reply-To: <1323438427.20077.57.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 9 Dec 2011 13:47:07 +0000
> If we had a concept like MAX_SKB_PAGES then it would perhaps make
> sense to have + 2 there, but AFAICT drivers etc are already
> accounting for this appropriately by adding a further + 2 (or
> sometimes + 1) to MAX_SKB_FRAGS.
Any kind of code like this, including the "+ 2" in the skbuff header,
should be coded to use some kind of macro so we can track this
dependency instead of stumbling onto it and accidently breaking lots
of stuff if we want to change this "2" value.
^ permalink raw reply
* [PATCH iproute2] red: Add adaptative algo
From: Eric Dumazet @ 2011-12-09 18:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20111209093309.04b32e27@nehalam.linuxnetplumber.net>
Enable Adaptative RED algo, using :
tc qdisc ... red limit BYTES ... adaptative ...
Support of high precision probability/max_p setting and reporting, with
support of old kernels.
With a new kernel, "Plog ..." is replaced in tc output by "probability
value" :
qdisc red 10: dev eth3 parent 1:1 limit 360Kb min 30Kb max 90Kb ecn ewma
5 probability 0.09 Scell_log 15
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/pkt_sched.h | 17 ++++++++++++-----
tc/q_red.c | 24 +++++++++++++++++++++---
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h
index c533670..e41e0d4 100644
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
@@ -30,7 +30,7 @@
*/
struct tc_stats {
- __u64 bytes; /* NUmber of enqueues bytes */
+ __u64 bytes; /* Number of enqueued bytes */
__u32 packets; /* Number of enqueued packets */
__u32 drops; /* Packets dropped because of lack of resources */
__u32 overlimits; /* Number of throttle events when this
@@ -181,6 +181,7 @@ enum {
TCA_RED_UNSPEC,
TCA_RED_PARMS,
TCA_RED_STAB,
+ TCA_RED_MAX_P,
__TCA_RED_MAX,
};
@@ -194,8 +195,9 @@ struct tc_red_qopt {
unsigned char Plog; /* log(P_max/(qth_max-qth_min)) */
unsigned char Scell_log; /* cell size for idle damping */
unsigned char flags;
-#define TC_RED_ECN 1
-#define TC_RED_HARDDROP 2
+#define TC_RED_ECN 1
+#define TC_RED_HARDDROP 2
+#define TC_RED_ADAPTATIVE 4
};
struct tc_red_xstats {
@@ -297,7 +299,7 @@ struct tc_htb_glob {
__u32 debug; /* debug flags */
/* stats */
- __u32 direct_pkts; /* count of non shapped packets */
+ __u32 direct_pkts; /* count of non shaped packets */
};
enum {
TCA_HTB_UNSPEC,
@@ -465,6 +467,7 @@ enum {
TCA_NETEM_REORDER,
TCA_NETEM_CORRUPT,
TCA_NETEM_LOSS,
+ TCA_NETEM_RATE,
__TCA_NETEM_MAX,
};
@@ -495,6 +498,10 @@ struct tc_netem_corrupt {
__u32 correlation;
};
+struct tc_netem_rate {
+ __u32 rate; /* byte/s */
+};
+
enum {
NETEM_LOSS_UNSPEC,
NETEM_LOSS_GI, /* General Intuitive - 4 state model */
@@ -503,7 +510,7 @@ enum {
};
#define NETEM_LOSS_MAX (__NETEM_LOSS_MAX - 1)
-/* State transition probablities for 4 state model */
+/* State transition probabilities for 4 state model */
struct tc_netem_gimodel {
__u32 p13;
__u32 p31;
diff --git a/tc/q_red.c b/tc/q_red.c
index 18020d7..0e5d228 100644
--- a/tc/q_red.c
+++ b/tc/q_red.c
@@ -28,7 +28,8 @@
static void explain(void)
{
fprintf(stderr, "Usage: ... red limit BYTES [min BYTES] [max BYTES] avpkt BYTES [burst PACKETS]\n");
- fprintf(stderr, " [probability PROBABILITY] bandwidth KBPS [ecn] [harddrop]\n");
+ fprintf(stderr, " [adaptative] [probability PROBABILITY] bandwidth KBPS\n");
+ fprintf(stderr, " [ecn] [harddrop]\n");
}
static int red_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nlmsghdr *n)
@@ -40,6 +41,7 @@ static int red_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
unsigned rate = 0;
int wlog;
__u8 sbuf[256];
+ __u32 max_P;
struct rtattr *tail;
memset(&opt, 0, sizeof(opt));
@@ -91,6 +93,8 @@ static int red_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
opt.flags |= TC_RED_ECN;
} else if (strcmp(*argv, "harddrop") == 0) {
opt.flags |= TC_RED_HARDDROP;
+ } else if (strcmp(*argv, "adaptative") == 0) {
+ opt.flags |= TC_RED_ADAPTATIVE;
} else if (strcmp(*argv, "help") == 0) {
explain();
return -1;
@@ -141,6 +145,8 @@ static int red_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
addattr_l(n, 1024, TCA_OPTIONS, NULL, 0);
addattr_l(n, 1024, TCA_RED_PARMS, &opt, sizeof(opt));
addattr_l(n, 1024, TCA_RED_STAB, sbuf, 256);
+ max_P = probability * pow(2, 32);
+ addattr_l(n, 1024, TCA_RED_MAX_P, &max_P, sizeof(max_P));
tail->rta_len = (void *) NLMSG_TAIL(n) - (void *) tail;
return 0;
}
@@ -149,6 +155,7 @@ static int red_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
{
struct rtattr *tb[TCA_RED_MAX + 1];
struct tc_red_qopt *qopt;
+ __u32 max_P = 0;
SPRINT_BUF(b1);
SPRINT_BUF(b2);
SPRINT_BUF(b3);
@@ -163,6 +170,11 @@ static int red_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
qopt = RTA_DATA(tb[TCA_RED_PARMS]);
if (RTA_PAYLOAD(tb[TCA_RED_PARMS]) < sizeof(*qopt))
return -1;
+
+ if (tb[TCA_RED_MAX_P] &&
+ RTA_PAYLOAD(tb[TCA_RED_MAX_P]) >= sizeof(__u32))
+ max_P = *(__u32 *)RTA_DATA(tb[TCA_RED_MAX_P]);
+
fprintf(f, "limit %s min %s max %s ",
sprint_size(qopt->limit, b1),
sprint_size(qopt->qth_min, b2),
@@ -171,9 +183,15 @@ static int red_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
fprintf(f, "ecn ");
if (qopt->flags & TC_RED_HARDDROP)
fprintf(f, "harddrop ");
+ if (qopt->flags & TC_RED_ADAPTATIVE)
+ fprintf(f, "adaptative ");
if (show_details) {
- fprintf(f, "ewma %u Plog %u Scell_log %u",
- qopt->Wlog, qopt->Plog, qopt->Scell_log);
+ fprintf(f, "ewma %u ", qopt->Wlog);
+ if (max_P)
+ fprintf(f, "probability %lg ", max_P / pow(2, 32));
+ else
+ fprintf(f, "Plog %u ", qopt->Plog);
+ fprintf(f, "Scell_log %u", qopt->Scell_log);
}
return 0;
}
^ permalink raw reply related
* An error in my HFSC sysadmin documentation
From: John A. Sullivan III @ 2011-12-09 18:24 UTC (permalink / raw)
To: netdev
Hello, all. As I mentioned, I'm trying to compile documentation on IFB
and HFSC from a sysadmin's perspective but I think I have an error in
the way I'm explaining how HFSC determines when to send which packet to
meet bandwidth and latency guarantees of the rt service curve. I'll
show where my math is breaking down in the hope someone can see and
correct my error.
As I was writing this, I saw my error but I will post it in case someone
else steps into the same hole.
Let's say we have a 15 Mbps circuit. We have two rt service curves.
One is for VoIP and has a rate of 8.9 Mbps (we'll refer to it as V)
while the other is for FTP with a rate of 6.1 Mbps (we'll refer to it as
F). Let's say that both are being used to the maximum. V is filled
with 222 byte packets for its ulaw streams and F is filled with 1514
byte packets.
Let's now pick it up where the eligible time for the head of the packet
in each queue is 1000ms just to pick a convenient time. At the given
rate and packet sizes, the deadline differential (for lack of a better
term) is 2ms for F ((1514 * 8)bits/6,100,000(b/s)) and 0.2ms for V ((222
* 8)bits/8,900,000(b/s)). The actual transmission time for a packet in
F is 0.8ms ((1514 * 8)bits/15,000,000(b/s)) and 0.1ms for V excluding
CRC, preamble, and IFG.
Thus deadline time measured at the end of the packet is 1000.2 for V and
1002 for F thus V is serviced, correct? Ah, I see my error but I'll
continue in case someone else steps into the same error. The new
deadline time for V is 1000.4 and for F is still 1002 so V is serviced
again and so it goes until eligible time for V is 1001.8. Then,
perhaps, F is selected to transmit but, it has only 0.2ms left to meet
deadline time and it takes 0.8ms to send the packet thus violating our
guarantees.
Here is the mistake. Let's assume that clock time equaled eligible time
at 1000ms when we began. DT (deadline time) for V is 1000.2 and 1002
for F so V is serviced. It took 0.1ms to send the packet so clock time
is now 1000.1. ET (Eligible time) for V is 1000.2 while it is still
1000 for F thus DT doesn't enter into the mix since V is not eligible to
dequeue. F is sent, CT (clock time) becomes 1000.9, V ET is 1000.2 and
DT is 1000.4 while F ET is 1002 and DT is 1004. V's ET <= CT and its DT
< F's DT so V is serviced while F cannot dequeue because its ET > CT.
CT becomes 1001, V's ET becomes 1000.4 and its DT 1000.6. In fact, it
will send 6 more packets advancing CT to 1001.6 and its ET to 1001.6
making its DT 1001.8. This means, it can send yet one more packet
advancing CT to 1001.7, its ET to 1001.8. At this point, neither is
eligible to send which should not be the case since we have guaranteed
to the full rate of the line. I'm assuming this does not reflect
reality but reflects the fact that I have rounded my calculations (e.g.,
the time to transmit the V packet is not 0.1ms but rather 0.1184ms) and
have not included CRC, preamble, and IFG (which would make V
transmission time 0.1312ms).
By the way, how does HFSC decide which packet to send if multiple
packets happen to have the exact same deadline time? Thanks - John
^ permalink raw reply
* Re: [PATCH RESEND] sctp: fix incorrect overflow check on autoclose
From: Xi Wang @ 2011-12-09 18:04 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, linux-sctp, Andrew Morton, Andrei Pelinescu-Onciul,
David S. Miller
In-Reply-To: <4EE2478B.5010409@hp.com>
On Dec 9, 2011, at 12:38 PM, Vladislav Yasevich wrote:
> I think this should be u32 since that's what sp->autoclose is.
Do you mean something like this?
min_t(u32, sp->autoclose, MAX_SCHEDULE_TIMEOUT / HZ)
On 64-bit platform this would limit autoclose for no good
reason to
(u32)(MAX_SCHEDULE_TIMEOUT / HZ),
which is basically 0x978d4fdf (assuming HZ is 250). I guess the
intention was to allow autoclose to be any u32 on 64-bit platform.
- xi
^ permalink raw reply
* Re: kernel 3.1.1 message: <IRQ> warn_alloc_failed
From: starlight @ 2011-12-09 18:03 UTC (permalink / raw)
To: Stephen Hemminger, Sony Chacko, Rajesh Borundia; +Cc: linux-kernel, netdev
In-Reply-To: <20111209095014.14a647cd@nehalam.linuxnetplumber.net >
At 09:50 AM 12/9/2011 -0800, Stephen Hemminger wrote:
>On Thu, 08 Dec 2011 21:10:02 -0500 starlight@binnacle.cx wrote:
>
>You are seeing memory allocation failures because device
>is allocating a 16K (order 2) size socket buffer. You are using
>netxen device, and it looks like the problem.
>
>From reading the netxen driver source. The LRO buffers
>in this device are very large (8060+skb overhead).
>Until the driver is fixed to use fragmented page size memory,
>I recommend turning off LRO.
Thank you for the analysis. As an alternative
would it make sense to double or quadruple
/proc/sys/vm/min_free_kbytes
or perhaps do the same for
/proc/slabinfo(size-16384)
or both?
^ permalink raw reply
* Re: BCM43224 hanging [3.2.0-rc4-00248-gb835c0f]
From: Nico Schottelius @ 2011-12-09 18:00 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Nico Schottelius, LKML, netdev, b43-dev, Greg KH
In-Reply-To: <4EE0F50B.5040407@broadcom.com>
Hey Arend,
Arend van Spriel [Thu, Dec 08, 2011 at 06:34:03PM +0100]:
> On 12/07/2011 08:08 PM, Nico Schottelius wrote:
> Could you try and see what happens when you kill wpa_supplicant.
I can't kill it, it's in D state :-/
I was just browsing through
drivers/net/wireless/brcm80211/brcmsmac/main.c and it seems that
your patch from my last problem has already been applied.
What may be different this time that the network being used
is *not* on 5Ghz, but 2.4 Ghz (I'm not in the same environment anymore).
Nico
--
PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
^ 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