* RE: [PATCH v2] ARM: net: JIT compiler for packet filters
From: Nicolas Pitre @ 2011-12-23 2:26 UTC (permalink / raw)
To: David Laight; +Cc: Dave Martin, Mircea Gherzan, netdev, linux, linux-arm-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AF25@saturn3.aculab.com>
On Thu, 22 Dec 2011, David Laight wrote:
> > In principle, the condition could be __LINUX_ARM_ARCH__ < 5, since the
> > bx instruction is guaranteed to be available on all ARMv5 CPUs and
> > later (ARMv5T is not required).
>
> Can't this code look at the actual cpu being used, and
> generate the relevant 'return' instruction?
> (Instead of trying to use some compile-time value.)
There is really no point doing so. We intend to ultimately have a
kernel that may support ARMv5 and lower, and another kernel to support
ARMv6 and ARMv7. So in a given context, either bx is always available
(ARMv6+) or never required (ARMv5-).
Nicolas
^ permalink raw reply
* Re: [PATCH v2] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: David Miller @ 2011-12-23 3:37 UTC (permalink / raw)
To: xi.wang; +Cc: eric.dumazet, therbert, netdev
In-Reply-To: <4EF3BEBA.4040402@gmail.com>
From: Xi Wang <xi.wang@gmail.com>
Date: Thu, 22 Dec 2011 18:35:22 -0500
> Setting a large rps_flow_cnt like (1 << 30) on 32-bit platform will
> cause a kernel oops due to insufficient bounds checking.
>
> if (count > 1<<30) {
> /* Enforce a limit to prevent overflow */
> return -EINVAL;
> }
> count = roundup_pow_of_two(count);
> table = vmalloc(RPS_DEV_FLOW_TABLE_SIZE(count));
>
> Note that the macro RPS_DEV_FLOW_TABLE_SIZE(count) is defined as:
>
> ... + (count * sizeof(struct rps_dev_flow))
>
> where sizeof(struct rps_dev_flow) is 8. (1 << 30) * 8 will overflow
> 32 bits.
>
> This patch replaces the magic number (1 << 30) with a symbolic bound.
>
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Xi Wang <xi.wang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] netlink: af_netlink cleanup (v2)
From: David Miller @ 2011-12-23 3:37 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20111222185217.411768888@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Dec 2011 10:52:02 -0800
> Don't inline functions that cover several lines, and do inline
> the trivial ones. Also make some arguments const.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] netlink: wake up netlink listeners sooner (v2)
From: David Miller @ 2011-12-23 3:38 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20111222185217.507023273@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Dec 2011 10:52:03 -0800
> This patch changes it to yield sooner at halfway instead. Still not a cure-all
> for listener overrun if listner is slow, but works much reliably.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference in ipv6_select_ident
From: David Miller @ 2011-12-23 3:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: bootc, linux-kernel, netdev, steffen.klassert
In-Reply-To: <1324563353.2153.27.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 22 Dec 2011 15:15:53 +0100
> [PATCH] net: introduce DST_NOPEER dst flag
>
> Chris Boot reported crashes occurring in ipv6_select_ident().
...
> This is caused by bridge netfilter special dst_entry (fake_rtable), a
> special shared entry, where attaching an inetpeer makes no sense.
>
> Problem is present since commit 87c48fa3b46 (ipv6: make fragment
> identifications less predictable)
>
> Introduce DST_NOPEER dst flag and make sure ipv6_select_ident() and
> __ip_select_ident() fallback to the 'no peer attached' handling.
>
> Reported-by: Chris Boot <bootc@bootc.net>
> Tested-by: Chris Boot <bootc@bootc.net>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] mqprio: Avoid panic if no options are provided
From: David Miller @ 2011-12-23 3:39 UTC (permalink / raw)
To: tgraf; +Cc: netdev, john.r.fastabend
In-Reply-To: <1324555507-10148-1-git-send-email-tgraf@redhat.com>
From: Thomas Graf <tgraf@redhat.com>
Date: Thu, 22 Dec 2011 13:05:07 +0100
> Userspace may not provide TCA_OPTIONS, in fact tc currently does
> so not do so if no arguments are specified on the command line.
> Return EINVAL instead of panicing.
>
> Signed-off-by: Thomas Graf <tgraf@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] Partial revert "Basic kernel memory functionality for the Memory Controller"
From: David Miller @ 2011-12-23 3:39 UTC (permalink / raw)
To: glommer-bzQdu9zFT3WakBO8gow8eQ
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
netdev-u79uwXL29TY76Z2rM5mHXA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
cgroups-u79uwXL29TY76Z2rM5mHXA, kirill-oKw7cIdHH8eLwutG50LtGA,
paul-inf54ven1CmVyaH7bEyXVA, gthelen-hpIqsD4AKlfQT0dZR+AlfA,
jweiner-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1324551747-5925-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Date: Thu, 22 Dec 2011 15:02:27 +0400
> This reverts commit e5671dfae59b165e2adfd4dfbdeab11ac8db5bda.
>
> After a follow up discussion with Michal, it was agreed it would
> be better to leave the kmem controller with just the tcp files,
> deferring the behavior of the other general memory.kmem.* files
> for a later time, when more caches are controlled. This is because
> generic kmem files are not used by tcp accounting and it is
> not clear how other slab caches would fit into the scheme.
>
> We are reverting the original commit so we can track the reference.
> Part of the patch is kept, because it was used by the later tcp
> code. Conflicts are shown in the bottom. init/Kconfig is removed from
> the revert entirely.
>
> Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> Acked-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Applied.
^ permalink raw reply
* [PATCH net-next] packet: fix typo in packet_mmap.txt
From: Wei Yongjun @ 2011-12-23 3:47 UTC (permalink / raw)
To: davem; +Cc: netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Just fixed typo of sample code in packet_mmap.txt
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 4acea66..1c08a4b 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -155,7 +155,7 @@ As capture, each frame contains two parts:
/* fill sockaddr_ll struct to prepare binding */
my_addr.sll_family = AF_PACKET;
- my_addr.sll_protocol = ETH_P_ALL;
+ my_addr.sll_protocol = htons(ETH_P_ALL);
my_addr.sll_ifindex = s_ifr.ifr_ifindex;
/* bind socket to eth0 */
--
1.7.7.4
^ permalink raw reply related
* Re: [PATCH v2] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: Eric Dumazet @ 2011-12-23 4:10 UTC (permalink / raw)
To: Xi Wang; +Cc: Tom Herbert, David S. Miller, netdev
In-Reply-To: <4EF3BEBA.4040402@gmail.com>
Le jeudi 22 décembre 2011 à 18:35 -0500, Xi Wang a écrit :
> Setting a large rps_flow_cnt like (1 << 30) on 32-bit platform will
> cause a kernel oops due to insufficient bounds checking.
>
> if (count > 1<<30) {
> /* Enforce a limit to prevent overflow */
> return -EINVAL;
> }
> count = roundup_pow_of_two(count);
> table = vmalloc(RPS_DEV_FLOW_TABLE_SIZE(count));
>
> Note that the macro RPS_DEV_FLOW_TABLE_SIZE(count) is defined as:
>
> ... + (count * sizeof(struct rps_dev_flow))
>
> where sizeof(struct rps_dev_flow) is 8. (1 << 30) * 8 will overflow
> 32 bits.
>
> This patch replaces the magic number (1 << 30) with a symbolic bound.
>
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Xi Wang <xi.wang@gmail.com>
> ---
> net/core/net-sysfs.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index c71c434..385aefe 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -665,11 +665,14 @@ static ssize_t store_rps_dev_flow_table_cnt(struct netdev_rx_queue *queue,
> if (count) {
> int i;
>
> - if (count > 1<<30) {
> + if (count > INT_MAX)
> + return -EINVAL;
> + count = roundup_pow_of_two(count);
> + if (count > (ULONG_MAX - sizeof(struct rps_dev_flow_table))
Oh well, you added a bug here, since count is "unsigned int"
Why mixing INT_MAX in the previous test and ULONG_MAX here ?
> + / sizeof(struct rps_dev_flow)) {
> /* Enforce a limit to prevent overflow */
> return -EINVAL;
> }
> - count = roundup_pow_of_two(count);
> table = vmalloc(RPS_DEV_FLOW_TABLE_SIZE(count));
> if (!table)
> return -ENOMEM;
^ permalink raw reply
* [PATCH 1/2] alx: Coalesce long formats
From: Joe Perches @ 2011-12-23 4:16 UTC (permalink / raw)
To: Cloud Ren, linux-kernel
Cc: Luis R. Rodriguez, ath9k-devel, Xiong Huang, Jay Cliburn,
Chris Snook, netdev
format strings broken into multiple bits are harder to grep.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ethernet/atheros/alx/alc_cb.c | 3 +-
drivers/net/ethernet/atheros/alx/alf_cb.c | 3 +-
drivers/net/ethernet/atheros/alx/alx_main.c | 54 ++++++++++----------------
3 files changed, 23 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ethernet/atheros/alx/alc_cb.c b/drivers/net/ethernet/atheros/alx/alc_cb.c
index 28c82ca..c6b32ad 100755
--- a/drivers/net/ethernet/atheros/alx/alc_cb.c
+++ b/drivers/net/ethernet/atheros/alx/alc_cb.c
@@ -733,8 +733,7 @@ static int alc_get_fc_mode(struct alx_hw *hw, enum alx_fc_mode *mode)
return retval;
if (!(giga & L1C_GIGA_PSSR_SPD_DPLX_RESOLVED)) {
- alx_hw_err(hw, "error for speed duplex "
- "resolved.\n");
+ alx_hw_err(hw, "error for speed duplex resolved.\n");
return -EINVAL;
}
diff --git a/drivers/net/ethernet/atheros/alx/alf_cb.c b/drivers/net/ethernet/atheros/alx/alf_cb.c
index 4b12df1..fa79bff 100755
--- a/drivers/net/ethernet/atheros/alx/alf_cb.c
+++ b/drivers/net/ethernet/atheros/alx/alf_cb.c
@@ -957,8 +957,7 @@ static int alf_get_fc_mode(struct alx_hw *hw, enum alx_fc_mode *mode)
return retval;
if (!(giga & L1F_GIGA_PSSR_SPD_DPLX_RESOLVED)) {
- alx_hw_err(hw, "error for speed duplex "
- "resolved.\n");
+ alx_hw_err(hw, "error for speed duplex resolved.\n");
return -EINVAL;
}
diff --git a/drivers/net/ethernet/atheros/alx/alx_main.c b/drivers/net/ethernet/atheros/alx/alx_main.c
index 0b71753..64360b4 100755
--- a/drivers/net/ethernet/atheros/alx/alx_main.c
+++ b/drivers/net/ethernet/atheros/alx/alx_main.c
@@ -593,8 +593,7 @@ static int alx_refresh_rx_buffer(struct alx_rx_queue *rxque)
wmb();
MEM_W16(hw, rxque->produce_reg, rxque->rfq.produce_idx);
netif_info(adpt, rx_err, adpt->netdev,
- "RX[%d]: prod_reg[0x%x] = 0x%x, "
- "rfq.produce_idx = 0x%x\n",
+ "RX[%d]: prod_reg[0x%x] = 0x%x, rfq.produce_idx = 0x%x\n",
rxque->que_idx, rxque->produce_reg,
rxque->rfq.produce_idx, rxque->rfq.produce_idx);
}
@@ -1401,8 +1400,8 @@ static int alx_request_msix_irq(struct alx_adapter *adpt)
retval = request_irq(adpt->msix_entries[msix_idx].vector,
handler, 0, msix->name, msix);
if (retval) {
- alx_err(adpt, "request_irq failed for MSIX "
- "Error: %d\n", retval);
+ alx_err(adpt, "request_irq failed for MSIX, Error: %d\n",
+ retval);
goto free_msix_irq;
}
/* assign the mask for this irq */
@@ -1436,8 +1435,8 @@ static int alx_request_irq(struct alx_adapter *adpt)
if (CHK_ADPT_FLAG(0, MSIX_EN)) {
retval = alx_request_msix_irq(adpt);
if (retval)
- alx_err(adpt, "request msix irq failed, "
- "error = %d.\n", retval);
+ alx_err(adpt, "request msix irq failed, error = %d.\n",
+ retval);
goto out;
}
@@ -1446,8 +1445,8 @@ static int alx_request_irq(struct alx_adapter *adpt)
retval = request_irq(adpt->pdev->irq, &alx_interrupt, 0,
netdev->name, netdev);
if (retval)
- alx_err(adpt, "request msix irq failed, "
- "error = %d.\n", retval);
+ alx_err(adpt, "request msix irq failed, error = %d.\n",
+ retval);
goto out;
}
@@ -1455,8 +1454,8 @@ static int alx_request_irq(struct alx_adapter *adpt)
retval = request_irq(adpt->pdev->irq, &alx_interrupt, IRQF_SHARED,
netdev->name, netdev);
if (retval)
- alx_err(adpt, "request shared irq failed, "
- "error = %d\n", retval);
+ alx_err(adpt, "request shared irq failed, error = %d\n",
+ retval);
out:
return retval;
}
@@ -1929,8 +1928,7 @@ static int alx_set_msi_interrupt_mode(struct alx_adapter *adpt)
retval = pci_enable_msi(adpt->pdev);
if (retval) {
netif_info(adpt, probe, adpt->netdev,
- "can't enable MSI interrupt. "
- "retval: %d\n", retval);
+ "can't enable MSI interrupt. retval: %d\n", retval);
return retval;
}
SET_ADPT_FLAG(0, MSI_EN);
@@ -1959,8 +1957,7 @@ static int alx_set_interrupt_mode(struct alx_adapter *adpt)
}
netif_info(adpt, probe, adpt->netdev,
- "can't enable MSIX and MSI interrupt. "
- "then enable Legacy interrupt.\n");
+ "can't enable MSIX and MSI interrupt then enable Legacy interrupt.\n");
retval = 0;
return retval;
}
@@ -2237,8 +2234,7 @@ static int alx_alloc_tx_descriptor(struct alx_adapter *adpt,
return 0;
err_alloc_tpq_buffer:
- alx_err(adpt, "Unable to allocate memory "
- "for the Tx descriptor.\n");
+ alx_err(adpt, "Unable to allocate memory for the Tx descriptor.\n");
return -ENOMEM;
}
@@ -2323,8 +2319,7 @@ err_alloc_swq_buffer:
kfree(rxque->rfq.rfbuff);
rxque->rfq.rfbuff = NULL;
err_alloc_rfq_buffer:
- alx_err(adpt, "Unable to allocate memory "
- "for the Rx descriptor\n");
+ alx_err(adpt, "Unable to allocate memory for the Rx descriptor\n");
return -ENOMEM;
}
@@ -2694,8 +2689,7 @@ static int alx_stop(struct net_device *netdev)
if (CHK_ADPT_FLAG(1, STATE_RESETTING))
netif_warn(adpt, ifdown, adpt->netdev,
- "ALX_ADPT_FLAG_1_STATE_RESETTING "
- "has already set\n");
+ "ALX_ADPT_FLAG_1_STATE_RESETTING has already set\n");
alx_stop_internal(adpt, ALX_OPEN_CTRL_IRQ_EN |
ALX_OPEN_CTRL_RESET_MAC);
@@ -3059,8 +3053,7 @@ static void alx_task_routine(struct work_struct *work)
/* test state of adapter */
if (!CHK_ADPT_FLAG(1, STATE_WATCH_DOG))
netif_warn(adpt, timer, adpt->netdev,
- "ALX_ADPT_FLAG_1_STATE_WATCH_DOG "
- "is not set\n");
+ "ALX_ADPT_FLAG_1_STATE_WATCH_DOG is not set\n");
/* reinit task */
alx_reinit_task_routine(adpt);
@@ -3180,8 +3173,7 @@ check_sum:
cso = skb_transport_offset(skb);
if (unlikely(cso & 0x1)) {
- dev_err(&pdev->dev, "pay load offset should not "
- "be an event number\n");
+ dev_err(&pdev->dev, "pay load offset should not be an event number\n");
return -1;
} else {
css = cso + skb->csum_offset;
@@ -3292,8 +3284,7 @@ netdev_tx_t alx_start_xmit_frame(struct alx_adapter *adpt,
}
netif_info(adpt, tx_err, adpt->netdev,
- "before XMIT: TX[%d]: tpq.consume_idx = 0x%x, "
- "tpq.produce_idx = 0x%x\n",
+ "before XMIT: TX[%d]: tpq.consume_idx = 0x%x, tpq.produce_idx = 0x%x\n",
txque->que_idx, txque->tpq.consume_idx,
txque->tpq.produce_idx);
memset(&stpd, 0, sizeof(struct alx_tpdesc));
@@ -3503,8 +3494,7 @@ int __devinit alx_init(struct pci_dev *pdev,
retval = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (retval) {
- dev_err(&pdev->dev, "No usable DMA "
- "configuration, aborting\n");
+ dev_err(&pdev->dev, "No usable DMA configuration, aborting\n");
goto err_alloc_pci_res_mem;
}
}
@@ -3650,9 +3640,8 @@ int __devinit alx_init(struct pci_dev *pdev,
alx_set_register_info_special(adpt);
- netif_dbg(adpt, probe, adpt->netdev, "num_msix_noque_intrs = %d, "
- "num_msix_rxque_intrs = %d, "
- "num_msix_txque_intrs = %d.\n",
+ netif_dbg(adpt, probe, adpt->netdev,
+ "num_msix_noque_intrs = %d, num_msix_rxque_intrs = %d, num_msix_txque_intrs = %d.\n",
adpt->num_msix_noques,
adpt->num_msix_rxques,
adpt->num_msix_txques);
@@ -3660,8 +3649,7 @@ int __devinit alx_init(struct pci_dev *pdev,
adpt->num_msix_intrs);
netif_dbg(adpt, probe, adpt->netdev,
- "RX Queue Count = %u, HRX Queue Count = %u, "
- "SRX Queue Count = %u, TX Queue Count = %u\n",
+ "RX Queue Count = %u, HRX Queue Count = %u, SRX Queue Count = %u, TX Queue Count = %u\n",
adpt->num_rxques, adpt->num_hw_rxques, adpt->num_sw_rxques,
adpt->num_txques);
--
1.7.8.111.gad25c.dirty
^ permalink raw reply related
* Re: [PATCH 1/2] alx: Coalesce long formats
From: Chris Snook @ 2011-12-23 4:26 UTC (permalink / raw)
To: Joe Perches
Cc: Cloud Ren, linux-kernel, Luis R. Rodriguez, ath9k-devel,
Xiong Huang, Jay Cliburn, netdev
In-Reply-To: <b177a0ce5b62188ba37f1c243d9fe792375c5fa3.1324613334.git.joe@perches.com>
On Thu, Dec 22, 2011 at 8:16 PM, Joe Perches <joe@perches.com> wrote:
> format strings broken into multiple bits are harder to grep.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/ethernet/atheros/alx/alc_cb.c | 3 +-
> drivers/net/ethernet/atheros/alx/alf_cb.c | 3 +-
> drivers/net/ethernet/atheros/alx/alx_main.c | 54 ++++++++++----------------
> 3 files changed, 23 insertions(+), 37 deletions(-)
Acked-by: Chris Snook <chris.snook@gmail.com>
^ permalink raw reply
* Re: [PATCH v5] ARM: net: JIT compiler for packet filters
From: Eric Dumazet @ 2011-12-23 4:44 UTC (permalink / raw)
To: Mircea Gherzan; +Cc: linux-arm-kernel, netdev, linux
In-Reply-To: <1324601625-20351-1-git-send-email-mgherzan@gmail.com>
Le vendredi 23 décembre 2011 à 01:53 +0100, Mircea Gherzan a écrit :
> Based of Matt Evans's PPC64 implementation.
>
> The compiler generates ARM instructions but interworking is
> supported for Thumb2 kernels.
>
> Supports both little and big endian. Unaligned loads are emitted
> for ARMv6+. Not all the BPF opcodes that deal with ancillary data
> are supported. The scratch memory of the filter lives on the stack.
> Hardware integer division is used if it is available.
>
> Enabled in the same way as for x86-64 and PPC64:
>
> echo 1 > /proc/sys/net/core/bpf_jit_enable
>
> A value greater than 1 enables opcode output.
>
> Signed-off-by: Mircea Gherzan <mgherzan@gmail.com>
> ---
>
> Changes in v5:
> * replace SEEN_LEN with SEEN_SKB
> * set ctx->seen when handling some ancillary data opcodes
> + case BPF_S_ANC_CPU:
> + /* A = current_thread_info()->cpu */
> + emit_mov_i(r_scratch, (~(THREAD_SIZE - 1)), ctx);
> + emit(ARM_ADD_R(r_scratch, ARM_SP, r_scratch), ctx);
This cant be right ;)
> +
> + BUILD_BUG_ON(FIELD_SIZEOF(struct thread_info, cpu) != 4);
> + off = offsetof(struct thread_info, cpu);
> + emit(ARM_LDR_I(r_A, r_scratch, off), ctx);
> + break;
code for r_A = raw_smp_processor_id(); should be something like :
mov r0, sp
bic r0, r0, #8128 ; 0x1fc0
bic r0, r0, #63 ; 0x3f
ldr r4, [r0, #20]
^ permalink raw reply
* Re: [PATCH v2] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: Xi Wang @ 2011-12-23 4:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, David S. Miller, netdev
In-Reply-To: <1324613414.2674.2.camel@edumazet-laptop>
On Dec 22, 2011, at 11:10 PM, Eric Dumazet wrote:
>> - if (count > 1<<30) {
>> + if (count > INT_MAX)
>> + return -EINVAL;
>> + count = roundup_pow_of_two(count);
>> + if (count > (ULONG_MAX - sizeof(struct rps_dev_flow_table))
>
> Oh well, you added a bug here, since count is "unsigned int"
>
> Why mixing INT_MAX in the previous test and ULONG_MAX here ?
The first check (count > INT_MAX) is used to avoid overflowing
roundup_pow_of_two(count), e.g., when count is 0xffffffff.
The second check is to avoid overflowing the size for vmalloc().
It gives a less restrictive upper bound than using INT_MAX/UINT_MAX
on 64-bit platform.
Why do you think it's a bug there? I agree using two checks looks
ugly though.
- xi
^ permalink raw reply
* Re: [PATCH v2] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: Eric Dumazet @ 2011-12-23 4:53 UTC (permalink / raw)
To: Xi Wang; +Cc: Tom Herbert, David S. Miller, netdev
In-Reply-To: <C0DC969A-A32B-4CC8-B565-FF741E9D75DA@gmail.com>
Le jeudi 22 décembre 2011 à 23:44 -0500, Xi Wang a écrit :
> On Dec 22, 2011, at 11:10 PM, Eric Dumazet wrote:
> >> - if (count > 1<<30) {
> >> + if (count > INT_MAX)
> >> + return -EINVAL;
> >> + count = roundup_pow_of_two(count);
> >> + if (count > (ULONG_MAX - sizeof(struct rps_dev_flow_table))
> >
> > Oh well, you added a bug here, since count is "unsigned int"
> >
> > Why mixing INT_MAX in the previous test and ULONG_MAX here ?
>
> The first check (count > INT_MAX) is used to avoid overflowing
> roundup_pow_of_two(count), e.g., when count is 0xffffffff.
>
> The second check is to avoid overflowing the size for vmalloc().
> It gives a less restrictive upper bound than using INT_MAX/UINT_MAX
> on 64-bit platform.
>
> Why do you think it's a bug there? I agree using two checks looks
> ugly though.
>
> - xi
All I wanted to say is that while mixing INT_MAX/ULONG_MAX, you could
have spotted the other bug in the code :
unsigned int count;
count = simple_strtoul(buf, &endp, 0);
^ permalink raw reply
* Re: [PATCH v2] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: Xi Wang @ 2011-12-23 5:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, David S. Miller, netdev
In-Reply-To: <1324616007.2674.8.camel@edumazet-laptop>
On Dec 22, 2011, at 11:53 PM, Eric Dumazet wrote:
> All I wanted to say is that while mixing INT_MAX/ULONG_MAX, you could
> have spotted the other bug in the code :
>
> unsigned int count;
>
> count = simple_strtoul(buf, &endp, 0);
Are you suggesting to change the type of "count" to unsigned long?
That seems like a separate issue from the bounds checking part.
I don't see the possible 32-bit truncation here is a serious issue though.
The user could even echo "128abc" into rps_flow_cnt and simple_strtoul()
would be happy to pick 128.
- xi
^ permalink raw reply
* Re: [PATCH v2] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: Eric Dumazet @ 2011-12-23 5:16 UTC (permalink / raw)
To: Xi Wang; +Cc: Tom Herbert, David S. Miller, netdev
In-Reply-To: <ACB00AE8-CFEF-4535-9242-1B5C44F05C13@gmail.com>
Le vendredi 23 décembre 2011 à 00:10 -0500, Xi Wang a écrit :
> On Dec 22, 2011, at 11:53 PM, Eric Dumazet wrote:
> > All I wanted to say is that while mixing INT_MAX/ULONG_MAX, you could
> > have spotted the other bug in the code :
> >
> > unsigned int count;
> >
> > count = simple_strtoul(buf, &endp, 0);
>
> Are you suggesting to change the type of "count" to unsigned long?
> That seems like a separate issue from the bounds checking part.
>
> I don't see the possible 32-bit truncation here is a serious issue though.
> The user could even echo "128abc" into rps_flow_cnt and simple_strtoul()
> would be happy to pick 128.
>
32 bit truncation _is_ a bound checking problem too.
Really, mixing INT_MAX / ULONG_MAX is ugly, this should had ring a bell
when writing such hard to read code.
You cannot claim to give more range to 64bit platform, yet not spotting
the 32bit truncation issue.
When fixing a bug, its always a good thing to look things around, and
try to check the whole function.
^ permalink raw reply
* Re: [PATCH v2] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: Eric Dumazet @ 2011-12-23 5:35 UTC (permalink / raw)
To: Xi Wang; +Cc: Tom Herbert, David S. Miller, netdev
In-Reply-To: <1324617390.2674.13.camel@edumazet-laptop>
Le vendredi 23 décembre 2011 à 06:16 +0100, Eric Dumazet a écrit :
> 32 bit truncation _is_ a bound checking problem too.
>
> Really, mixing INT_MAX / ULONG_MAX is ugly, this should had ring a bell
> when writing such hard to read code.
>
> You cannot claim to give more range to 64bit platform, yet not spotting
> the 32bit truncation issue.
>
> When fixing a bug, its always a good thing to look things around, and
> try to check the whole function.
>
>
By the way, the theorical limit on number of flows on 64bit platform is
2^32 (rxhash being an u32)
Not sure spending 32GB per table would be wise for typical machines :)
^ permalink raw reply
* Re: [PATCH v2] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: Xi Wang @ 2011-12-23 5:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, David S. Miller, netdev
In-Reply-To: <1324617390.2674.13.camel@edumazet-laptop>
On Dec 23, 2011, at 12:16 AM, Eric Dumazet wrote:
> 32 bit truncation _is_ a bound checking problem too.
>
> Really, mixing INT_MAX / ULONG_MAX is ugly, this should had ring a bell
> when writing such hard to read code.
>
> You cannot claim to give more range to 64bit platform, yet not spotting
> the 32bit truncation issue.
>
> When fixing a bug, its always a good thing to look things around, and
> try to check the whole function.
Okay, seems like we are talking about two different issues here.
1) the truncation of "count" on 64-bit platform.
I don't mind if the user shoots himself in the foot by setting a
large or invalid rps_flow_cnt, as long as the kernel is not affected.
I do agree with you that the kernel could be more friendly and
reject the value rather than picking up part of it. To be nicer
the kernel may even want to reject something like "123abc" that
simple_strtoul() would accept. I am happy to see another patch
fixing that.
2) the bounds checking of the vmalloc() size on 32-bit platform.
I agree that the two checks are ugly. ;-) Do you want to use INT_MAX
in both checks, or do you have something more elegant in mind?
- xi
^ permalink raw reply
* Re: [PATCH v2] rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
From: Xi Wang @ 2011-12-23 5:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, David S. Miller, netdev
In-Reply-To: <1324618555.10854.4.camel@edumazet-laptop>
On Dec 23, 2011, at 12:35 AM, Eric Dumazet wrote:
> By the way, the theorical limit on number of flows on 64bit platform is
> 2^32 (rxhash being an u32)
>
> Not sure spending 32GB per table would be wise for typical machines :)
True, a large rps_flow_cnt is not that useful. ;-)
Anyway, my point is that if the patch looks confusing to you, then
it is probably not good. I am happy to see a more elegant fix.
- xi
^ permalink raw reply
* SFQ on HFSC leaf does not seem to work
From: John A. Sullivan III @ 2011-12-23 6:00 UTC (permalink / raw)
To: netdev
Hello, all. I have an experimental HFSC setup with three leaf classes
each with SFQ as the final qdisc. One queue is for ssh on port 822, one
is for tcp traffic on port 443, the third is the default.
If I flood the 443 queue with netcat, my ssh sessions are responsive and
my continuous ping shows a round trip time of around 50ms in keeping
with my netem settings.
However, if I flood the default queue with netcat on port 80, ssh is
still responsive but my ping round trip times shoot up over 3000ms.
I thought it might be the bufferbloat phenomenon so I reduced the
txqueuelen on both sides of the ping to 0. Both sides use old 10BaseT
NICs and have no ring buffer. I also set the SFQ limit on the default
queue to 2 just in case. Still no difference.
The default queue is dequeuing at roughly 400 kbits which matches my
HFSC configuration. A full sized packet should take 30 ms to pass at
that rate ((1514 * 8)/400,000) so, if I am round robining the queues, I
would expect latency on a default sized ping to be only 30 ms plus the
netem delay.
Where might this 3000 ms delay be coming from?
Here is the rule set:
tc qdisc add dev eth1 root handle 1: hfsc default 20
tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 60
tc class add dev eth1 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
tc qdisc add dev eth1 parent 1:30 handle 1301 sfq perturb 60
iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
iptables -t mangle -A PREROUTING -p 6 --syn --dport 822 -j CONNMARK --set-mark 0x11
iptables -t mangle -A POSTROUTING -o eth1 -p 6 -j CONNMARK --restore-mark
modprobe ifb
ifconfig ifb0 up
ifconfig ifb1 up
tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 0x11 fw flowid 1:30 action mirred egress redirect dev ifb1
tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 0x10 fw flowid 1:10 action mirred egress redirect dev ifb1
tc filter add dev eth1 parent 1:0 protocol ip prio 2 u32 match u32 0 0 flowid 1:20 action mirred egress redirect dev ifb1
tc qdisc add dev eth1 ingress
tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match u32 0 0 action mirred egress redirect dev ifb0
tc qdisc add dev ifb0 root handle 1: hfsc default 20
tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
tc qdisc add dev ifb0 parent 1:20 handle 1201 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
tc qdisc add dev ifb0 parent 1:10 handle 1101 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc class add dev ifb0 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
tc qdisc add dev ifb0 parent 1:30 handle 1301 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 handle 6: u32 divisor 1
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff link 6: offset at 0 mask 0x0f00 shift 6 plus 0 eat
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp src 443 0x00ff flowid 1:10
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp dst 822 0xff00 flowid 1:30
tc qdisc add dev ifb1 root handle 2 netem delay 25ms 5ms distribution normal loss 0.1% 30%
Thanks - John
^ permalink raw reply
* Re: SFQ on HFSC leaf does not seem to work
From: Dave Taht @ 2011-12-23 6:32 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: netdev
In-Reply-To: <1324620022.10184.100.camel@denise.theartistscloset.com>
On Fri, Dec 23, 2011 at 7:00 AM, John A. Sullivan III
<jsullivan@opensourcedevel.com> wrote:
> Hello, all. I have an experimental HFSC setup with three leaf classes
> each with SFQ as the final qdisc. One queue is for ssh on port 822, one
> is for tcp traffic on port 443, the third is the default.
>
> If I flood the 443 queue with netcat, my ssh sessions are responsive and
> my continuous ping shows a round trip time of around 50ms in keeping
> with my netem settings.
>
> However, if I flood the default queue with netcat on port 80, ssh is
> still responsive but my ping round trip times shoot up over 3000ms.
>
> I thought it might be the bufferbloat phenomenon so I reduced the
> txqueuelen on both sides of the ping to 0. Both sides use old 10BaseT
> NICs and have no ring buffer. I also set the SFQ limit on the default
> queue to 2 just in case. Still no difference.
Your txqueuelen on the ifb devices is probably 1000.
>
> The default queue is dequeuing at roughly 400 kbits which matches my
> HFSC configuration. A full sized packet should take 30 ms to pass at
> that rate ((1514 * 8)/400,000) so, if I am round robining the queues, I
> would expect latency on a default sized ping to be only 30 ms plus the
> netem delay.
>
> Where might this 3000 ms delay be coming from?
>
> Here is the rule set:
>
> tc qdisc add dev eth1 root handle 1: hfsc default 20
> tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
> tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
> tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
> tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
> tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 60
> tc class add dev eth1 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
> tc qdisc add dev eth1 parent 1:30 handle 1301 sfq perturb 60
> iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
> iptables -t mangle -A PREROUTING -p 6 --syn --dport 822 -j CONNMARK --set-mark 0x11
> iptables -t mangle -A POSTROUTING -o eth1 -p 6 -j CONNMARK --restore-mark
> modprobe ifb
> ifconfig ifb0 up
> ifconfig ifb1 up
> tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 0x11 fw flowid 1:30 action mirred egress redirect dev ifb1
> tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 0x10 fw flowid 1:10 action mirred egress redirect dev ifb1
> tc filter add dev eth1 parent 1:0 protocol ip prio 2 u32 match u32 0 0 flowid 1:20 action mirred egress redirect dev ifb1
> tc qdisc add dev eth1 ingress
> tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match u32 0 0 action mirred egress redirect dev ifb0
> tc qdisc add dev ifb0 root handle 1: hfsc default 20
> tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
> tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
> tc qdisc add dev ifb0 parent 1:20 handle 1201 netem delay 25ms 5ms distribution normal loss 0.1% 30%
> tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
> tc qdisc add dev ifb0 parent 1:10 handle 1101 netem delay 25ms 5ms distribution normal loss 0.1% 30%
> tc class add dev ifb0 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
> tc qdisc add dev ifb0 parent 1:30 handle 1301 netem delay 25ms 5ms distribution normal loss 0.1% 30%
> tc filter add dev ifb0 parent 1:0 protocol ip prio 1 handle 6: u32 divisor 1
> tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff link 6: offset at 0 mask 0x0f00 shift 6 plus 0 eat
> tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp src 443 0x00ff flowid 1:10
> tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp dst 822 0xff00 flowid 1:30
> tc qdisc add dev ifb1 root handle 2 netem delay 25ms 5ms distribution normal loss 0.1% 30%
>
> Thanks - John
>
> --
> 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
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* [PATCH v2] drivers/net/usb/asix: fixed asix_get_wol reported wrong wol status issue
From: allan @ 2011-12-23 6:38 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, 'Freddy Xin',
'Grant Grundler', 'Eugene',
'ASIX Louis [蘇威陸]'
Fixed the asix_get_wol() routine reported wrong wol status issue.
Signed-off-by: Allan Chou <allan@asix.com.tw>
Tested-by: Eugene <elubarsky@gmail.com>; Allan Chou <allan@asix.com.tw>
---
This fix had been verified on x86 Linux kernel 3.0.0-12-generic system with AX88772A/AX88772/Belkin AX88178 USB dongles, and the wol function works fine (can be waked up by receiving the magic packets).
diff --git a/drivers/net/usb/asix.c b/drivers/net/usb/asix.c
--- a/drivers/net/usb/asix.c 2011-12-15 14:01:49.000000000 +0800
+++ b/drivers/net/usb/asix.c 2011-12-22 18:20:39.000000000 +0800
@@ -36,7 +36,7 @@
#include <linux/usb/usbnet.h>
#include <linux/slab.h>
-#define DRIVER_VERSION "08-Nov-2011"
+#define DRIVER_VERSION "22-Dec-2011"
#define DRIVER_NAME "asix"
/* ASIX AX8817X based USB 2.0 Ethernet Devices */
@@ -689,6 +689,10 @@ asix_get_wol(struct net_device *net, str
}
wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
wolinfo->wolopts = 0;
+ if (opt & AX_MONITOR_LINK)
+ wolinfo->wolopts |= WAKE_PHY;
+ if (opt & AX_MONITOR_MAGIC)
+ wolinfo->wolopts |= WAKE_MAGIC;
}
static int
^ permalink raw reply
* Re: SFQ on HFSC leaf does not seem to work
From: John A. Sullivan III @ 2011-12-23 6:40 UTC (permalink / raw)
To: Dave Taht; +Cc: netdev
In-Reply-To: <CAA93jw5FZ=Sz0afmnwwZ-COmSi=HfcXDJfokQgn3_nHEquTb5Q@mail.gmail.com>
On Fri, 2011-12-23 at 07:32 +0100, Dave Taht wrote:
> On Fri, Dec 23, 2011 at 7:00 AM, John A. Sullivan III
> <jsullivan@opensourcedevel.com> wrote:
> > Hello, all. I have an experimental HFSC setup with three leaf classes
> > each with SFQ as the final qdisc. One queue is for ssh on port 822, one
> > is for tcp traffic on port 443, the third is the default.
> >
> > If I flood the 443 queue with netcat, my ssh sessions are responsive and
> > my continuous ping shows a round trip time of around 50ms in keeping
> > with my netem settings.
> >
> > However, if I flood the default queue with netcat on port 80, ssh is
> > still responsive but my ping round trip times shoot up over 3000ms.
> >
> > I thought it might be the bufferbloat phenomenon so I reduced the
> > txqueuelen on both sides of the ping to 0. Both sides use old 10BaseT
> > NICs and have no ring buffer. I also set the SFQ limit on the default
> > queue to 2 just in case. Still no difference.
>
> Your txqueuelen on the ifb devices is probably 1000.
Alas, not. They defaulted to 32 and I reset them to 0 :(
I'll also paste in a slightly optimized rule set but it still made no
difference.
>
>
>
> >
> > The default queue is dequeuing at roughly 400 kbits which matches my
> > HFSC configuration. A full sized packet should take 30 ms to pass at
> > that rate ((1514 * 8)/400,000) so, if I am round robining the queues, I
> > would expect latency on a default sized ping to be only 30 ms plus the
> > netem delay.
> >
> > Where might this 3000 ms delay be coming from?
> >
> > Here is the rule set:
> >
> #!/bin/sh
tc qdisc add dev eth1 root handle 1: hfsc default 20
tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 60
tc class add dev eth1 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
tc qdisc add dev eth1 parent 1:30 handle 1301 sfq perturb 60
iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
iptables -t mangle -A PREROUTING -p 6 --syn --dport 822 -j CONNMARK --set-mark 0x11
iptables -t mangle -A POSTROUTING -o eth1 -p 6 -j CONNMARK --restore-mark
modprobe ifb
ifconfig ifb0 up
ifconfig ifb1 up
tc qdisc add dev ifb0 root handle 1: hfsc default 20
tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
tc qdisc add dev ifb0 parent 1:20 handle 1201 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
tc qdisc add dev ifb0 parent 1:10 handle 1101 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc class add dev ifb0 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
tc qdisc add dev ifb0 parent 1:30 handle 1301 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 handle 6: u32 divisor 1
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff link 6: offset at 0 mask 0x0f00 shift 6 plus 0 eat
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp src 443 0x00ff flowid 1:10
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp dst 822 0xff00 flowid 1:30
tc qdisc add dev ifb1 root handle 2 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc qdisc add dev eth1 ingress
tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match u32 0 0 action mirred egress redirect dev ifb0
tc filter add dev eth1 parent 1:1 protocol ip prio 1 handle 0x11 fw flowid 1:30
tc filter add dev eth1 parent 1:1 protocol ip prio 1 handle 0x10 fw flowid 1:10
tc filter add dev eth1 parent 1:1 protocol ip prio 2 u32 match u32 0 0 flowid 1:20
tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb1
> >
> > Thanks - John
> >
> > --
> > 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
>
>
>
^ permalink raw reply
* RE: [PATCH] drivers/net/usb/asix: fixed asix_get_wol reported wrong wol status issue
From: allan @ 2011-12-23 6:41 UTC (permalink / raw)
To: 'Grant Grundler'
Cc: davem, netdev, linux-kernel, 'Freddy Xin',
'Eugene', 'ASIX Louis [蘇威陸]'
In-Reply-To: <CANEJEGuKdj4dEh2-kyWovPC1TBiBbEot7f6pDVnzLGCf==Oc5g@mail.gmail.com>
Dear Grant,
Thanks a lot for your great suggestions. I had re-submitted the driver patch again. Please correct me if there are anything I should improve on the revised driver patch submission. Thanks a lot in advance.
---
Best regards,
Allan Chou
Technical Support Division
ASIX Electronics Corporation
TEL: 886-3-5799500 ext.228
FAX: 886-3-5799558
E-mail: allan@asix.com.tw
http://www.asix.com.tw/
-----Original Message-----
From: grundler@google.com [mailto:grundler@google.com] On Behalf Of Grant Grundler
Sent: Friday, December 23, 2011 3:02 AM
To: ASIX Allan Email [office]
Cc: davem@davemloft.net; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Freddy Xin; Eugene; ASIX Louis [蘇威陸]
Subject: Re: [PATCH] drivers/net/usb/asix: fixed asix_get_wol reported wrong wol status issue
On Thu, Dec 22, 2011 at 2:56 AM, ASIX Allan Email [office]
<allan@asix.com.tw> wrote:
> Dear David,
>
> This is my first time to submit the driver patch onto Linux kernel mainline source. Please correct me if anything is wrong on my submission way or email format. Thanks a lot for your great helps.
Hi Allan,
Thanks for submitting the patch. I can advise as well since this
probably won't get applied due to how the email is "structured".
Your email which includes the patch needs to follow the "patch format"
described in Documentation/SubmittingPatches (see linux source tree).
Your email should have three main sections:
1) commit log entry + signed-off-by lines followed by one line with
"---" (and nothing else). This text summarizes *why* the patch is
needed: what bug it fixes or feature it enables.
2) optional comments/information about the testing of the patch (e.g.
"tested on Samsung Chromebook" or other comments that do NOT belong in
the commit log entry above. This section can be empty - not required.
3) "diff -u" format patch (this is what "git diff" will produce).
Do not append any other emails or additional text.
thanks!
grant
>
> ========
> Fixed the asix_get_wol() routine reported wrong wol status issue.
> This fix had been verified on x86 Linux kernel 3.0.0-12-generic system with AX88772A/AX88772/Belkin AX88178 USB dongles, and the wol function works fine (can be waked up by receiving the magic packets).
>
> Signed-off-by: Allan Chou <allan@asix.com.tw>
> Tested-by: Allan Chou <allan@asix.com.tw>
> ---
> diff --uprN a/drivers/net/usb/asix.c b/drivers/net/usb/asix.c
> --- a/drivers/net/usb/asix.c 2011-12-15 14:01:49.000000000 +0800
> +++ b/drivers/net/usb/asix.c 2011-12-22 18:20:39.000000000 +0800
> @@ -36,7 +36,7 @@
> #include <linux/usb/usbnet.h>
> #include <linux/slab.h>
>
> -#define DRIVER_VERSION "08-Nov-2011"
> +#define DRIVER_VERSION "22-Dec-2011"
> #define DRIVER_NAME "asix"
>
> /* ASIX AX8817X based USB 2.0 Ethernet Devices */
> @@ -689,6 +689,10 @@ asix_get_wol(struct net_device *net, str
> }
> wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
> wolinfo->wolopts = 0;
> + if (opt & AX_MONITOR_LINK)
> + wolinfo->wolopts |= WAKE_PHY;
> + if (opt & AX_MONITOR_MAGIC)
> + wolinfo->wolopts |= WAKE_MAGIC;
> }
>
> static int
>
>
> ---
> Best regards,
> Allan Chou
> Technical Support Division
> ASIX Electronics Corporation
> TEL: 886-3-5799500 ext.228
> FAX: 886-3-5799558
> E-mail: allan@asix.com.tw
> http://www.asix.com.tw/
>
>
> -----Original Message-----
> From: allan [mailto:allan@asix.com.tw]
> Sent: Saturday, December 17, 2011 10:36 AM
> To: 'Grant Grundler'
> Cc: 'Eugene'; 'netdev@vger.kernel.org'; 'Freddy Xin'; 'ASIX Louis [蘇威陸]'
> Subject: RE: drivers/net/usb/asix: bug in asix_get_wol
>
> Dear Grant,
>
> I will double check this issue and submit the revised patch to Linux kernel mainline source next week. Thanks a lot for your great helps.
>
>
> ---
> Best regards,
> Allan Chou
> Technical Support Division
> ASIX Electronics Corporation
> TEL: 886-3-5799500 ext.228
> FAX: 886-3-5799558
> E-mail: allan@asix.com.tw
> http://www.asix.com.tw/
>
> -----Original Message-----
> From: grundler@google.com [mailto:grundler@google.com] On Behalf Of Grant Grundler
> Sent: Saturday, December 17, 2011 6:16 AM
> To: ASIX Allan Email [office]
> Cc: Eugene; netdev@vger.kernel.org; Freddy Xin; ASIX Louis [蘇威陸]
> Subject: Re: drivers/net/usb/asix: bug in asix_get_wol
>
> On Thu, Dec 15, 2011 at 9:15 PM, ASIX Allan Email [office]
> <allan@asix.com.tw> wrote:
>> Resend without attachment due to below email server error.
> ...
>> -----Original Message-----
>> From: ASIX Allan Email [office] [mailto:allan@asix.com.tw]
>> Sent: Friday, December 16, 2011 11:38 AM
>> To: 'Grant Grundler'; 'Eugene'
>> Cc: 'netdev@vger.kernel.org'; 'Freddy Xin'; ASIX Louis [蘇威陸]
>> Subject: RE: drivers/net/usb/asix: bug in asix_get_wol
>> Importance: High
>>
>> Dear Grant and Eugene,
>>
>> Please refer to the attached file and below statements to modify the
>> asix_get_wol() routine and let us know if this suggestion can solve
>> your issues or not? Thanks a lot.
>
> Allan,
> Thanks for the response but it doesn't answer my previous question.
> Let me ask the same question differently.
>
> Does WOL support in asix driver need more than the four lines of code?
> Ie does MONITOR_MODE need to be enabled or anything like that?
>
>> ================
>> static void
>> asix_get_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
>> {
>> struct usbnet *dev = netdev_priv(net);
>> u8 opt;
>>
>> if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, &opt) < 0) {
>> wolinfo->supported = 0;
>> wolinfo->wolopts = 0;
>> return;
>> }
>> wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
>> wolinfo->wolopts = 0;
>> if (opt & AX_MONITOR_LINK)
>> wolinfo->wolopts |= WAKE_PHY;
>> if (opt & AX_MONITOR_MAGIC)
>> wolinfo->wolopts |= WAKE_MAGIC;
>> }
>
> This looks remarkably similar to the code Eugene said enables WOL for
> him (and it works). I not able to find any difference.
>
> If you believe it was a mistake to remove these four lines of code,
> please submit a patch (See Documentation/SubmittingPatches) to add
> them back. You can add a "Tested-by: Eugene <elubarsky@gmail.com>"
> line after your own "Signed-off-by:" in the patch.
>
> thanks!
> grant
>
>
^ permalink raw reply
* Re: SFQ on HFSC leaf does not seem to work
From: John A. Sullivan III @ 2011-12-23 7:08 UTC (permalink / raw)
To: Dave Taht; +Cc: netdev
In-Reply-To: <1324622450.10184.142.camel@denise.theartistscloset.com>
On Fri, 2011-12-23 at 01:40 -0500, John A. Sullivan III wrote:
> On Fri, 2011-12-23 at 07:32 +0100, Dave Taht wrote:
> > On Fri, Dec 23, 2011 at 7:00 AM, John A. Sullivan III
> > <jsullivan@opensourcedevel.com> wrote:
> > > Hello, all. I have an experimental HFSC setup with three leaf classes
> > > each with SFQ as the final qdisc. One queue is for ssh on port 822, one
> > > is for tcp traffic on port 443, the third is the default.
> > >
> > > If I flood the 443 queue with netcat, my ssh sessions are responsive and
> > > my continuous ping shows a round trip time of around 50ms in keeping
> > > with my netem settings.
> > >
> > > However, if I flood the default queue with netcat on port 80, ssh is
> > > still responsive but my ping round trip times shoot up over 3000ms.
> > >
> > > I thought it might be the bufferbloat phenomenon so I reduced the
> > > txqueuelen on both sides of the ping to 0. Both sides use old 10BaseT
> > > NICs and have no ring buffer. I also set the SFQ limit on the default
> > > queue to 2 just in case. Still no difference.
> >
> > Your txqueuelen on the ifb devices is probably 1000.
> Alas, not. They defaulted to 32 and I reset them to 0 :(
>
> I'll also paste in a slightly optimized rule set but it still made no
> difference.
> >
> >
> >
> > >
> > > The default queue is dequeuing at roughly 400 kbits which matches my
> > > HFSC configuration. A full sized packet should take 30 ms to pass at
> > > that rate ((1514 * 8)/400,000) so, if I am round robining the queues, I
> > > would expect latency on a default sized ping to be only 30 ms plus the
> > > netem delay.
> > >
> > > Where might this 3000 ms delay be coming from?
> > >
> > > Here is the rule set:
> > >
> > #!/bin/sh
>
> tc qdisc add dev eth1 root handle 1: hfsc default 20
> tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
> tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
> tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
> tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
> tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 60
> tc class add dev eth1 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
> tc qdisc add dev eth1 parent 1:30 handle 1301 sfq perturb 60
> iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
> iptables -t mangle -A PREROUTING -p 6 --syn --dport 822 -j CONNMARK --set-mark 0x11
> iptables -t mangle -A POSTROUTING -o eth1 -p 6 -j CONNMARK --restore-mark
> modprobe ifb
> ifconfig ifb0 up
> ifconfig ifb1 up
> tc qdisc add dev ifb0 root handle 1: hfsc default 20
> tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
> tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
> tc qdisc add dev ifb0 parent 1:20 handle 1201 netem delay 25ms 5ms distribution normal loss 0.1% 30%
> tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
> tc qdisc add dev ifb0 parent 1:10 handle 1101 netem delay 25ms 5ms distribution normal loss 0.1% 30%
> tc class add dev ifb0 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
> tc qdisc add dev ifb0 parent 1:30 handle 1301 netem delay 25ms 5ms distribution normal loss 0.1% 30%
> tc filter add dev ifb0 parent 1:0 protocol ip prio 1 handle 6: u32 divisor 1
> tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff link 6: offset at 0 mask 0x0f00 shift 6 plus 0 eat
> tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp src 443 0x00ff flowid 1:10
> tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp dst 822 0xff00 flowid 1:30
> tc qdisc add dev ifb1 root handle 2 netem delay 25ms 5ms distribution normal loss 0.1% 30%
> tc qdisc add dev eth1 ingress
> tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match u32 0 0 action mirred egress redirect dev ifb0
> tc filter add dev eth1 parent 1:1 protocol ip prio 1 handle 0x11 fw flowid 1:30
> tc filter add dev eth1 parent 1:1 protocol ip prio 1 handle 0x10 fw flowid 1:10
> tc filter add dev eth1 parent 1:1 protocol ip prio 2 u32 match u32 0 0 flowid 1:20
> tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb1
<snip>
I just tried setting the txqueuelen to 5 instead of 0 as per Dave's
offlist recommendation but it made no difference. When I start the bulk
traffic, the ICMP response time builds over about 10s from 60ms to
3100ms. Any ideas where it is coming from? Thanks - John
^ 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