* Re: [PATCH net] cxgb4: Free completed tx skbs promptly
From: David Miller @ 2014-08-22 4:55 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan, kumaras, anish
In-Reply-To: <1408620886-20065-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Thu, 21 Aug 2014 17:04:46 +0530
> Description of problem:
> The NIC card is not reporting back to the driver the transmitted skbs,
> so they get stuck in the TX ring causing issues with reference
> counters in other kernel components.
>
> Developed a new Automatic Egress Queue Update firmware facility to slowly tick
> through Egress Queues and send back any outstanding CIDX Updates which are
> laying around.
>
> Based on original work by Casey Leedom <leedom@chelsio.com>
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: pull-request: can 2014-08-21
From: David Miller @ 2014-08-22 4:53 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <1408613002-29693-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Thu, 21 Aug 2014 11:23:18 +0200
> The first patch is from Mirza Krak, it fixes the initialization of the hardware
> in the sja1000 driver. The next patch is contributed by Dan Carpenter, it fixes
> the error handling in the c_can's probe function. Then there are two patches
> for the flexcan driver, one by Alexander Stein, which fixes the resetting of
> the bus error interrupt mask, the other one by Sebastian Andrzej Siewior which
> adds an additional error state transition message.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH net v2] cxgb4: Fix race condition in cleanup
From: David Miller @ 2014-08-22 4:45 UTC (permalink / raw)
To: anish; +Cc: netdev, hariprasad, leedom, svemuri, nhorman
In-Reply-To: <1408567446-6598-1-git-send-email-anish@chelsio.com>
From: Anish Bhatt <anish@chelsio.com>
Date: Wed, 20 Aug 2014 13:44:06 -0700
> There is a possible race condition when we unregister the PCI Driver and then
> flush/destroy the global "workq". This could lead to situations where there
> are tasks on the Work Queue with references to now deleted adapter data
> structures. Instead, have per-adapter Work Queues which were instantiated and
> torn down in init_one() and remove_one(), respectively.
>
> v2: Remove unnecessary call to flush_workqueue() before destroy_workqueue()
>
> Signed-off-by: Anish Bhatt <anish@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
Applied thanks.
^ permalink raw reply
* Re: [PATCH v2 3/3] tg3: Fix tx_pending checks for tg3_tso_bug
From: Prashant Sreedharan @ 2014-08-22 4:31 UTC (permalink / raw)
To: Benjamin Poirier; +Cc: Michael Chan, netdev, linux-kernel
In-Reply-To: <1408658240-6811-3-git-send-email-bpoirier@suse.de>
On Thu, 2014-08-21 at 14:57 -0700, Benjamin Poirier wrote:
> In tg3_set_ringparam(), the tx_pending test to cover the cases where
> tg3_tso_bug() is entered has two problems
> 1) the check is only done for certain hardware whereas the workaround
> is now used more broadly. IOW, the check may not be performed when it
> is needed.
> 2) the check is too optimistic.
>
> For example, with a 5761 (SHORT_DMA_BUG), tg3_set_ringparam() skips over the
> "tx_pending <= (MAX_SKB_FRAGS * 3)" check because TSO_BUG is false. Even if it
> did do the check, with a full sized skb, frag_cnt_est = 135 but the check is
> for <= MAX_SKB_FRAGS * 3 (= 17 * 3 = 51). So the check is insufficient. This
> leads to the following situation: by setting, ex. tx_pending = 100, there can
> be an skb that triggers tg3_tso_bug() and that is large enough to cause
> tg3_tso_bug() to stop the queue even when it is empty. We then end up with a
> netdev watchdog transmit timeout.
>
> Given that 1) some of the conditions tested for in tg3_tx_frag_set() apply
> regardless of the chipset flags and that 2) it is difficult to estimate ahead
> of time the max possible number of frames that a large skb may be split into
> by gso, we instead take the approach of adjusting dev->gso_max_segs according
> to the requested tx_pending size.
>
> This puts us in the exceptional situation that a single skb that triggers
> tg3_tso_bug() may require the entire tx ring. Usually the tx queue is woken up
> when at least a quarter of it is available (TG3_TX_WAKEUP_THRESH) but that
> would be insufficient now. To avoid useless wakeups, the tx queue wake up
> threshold is made dynamic. Likewise, usually the tx queue is stopped as soon
> as an skb with max frags may overrun it. Since the skbs submitted from
> tg3_tso_bug() use a controlled number of descriptors, the tx queue stop
> threshold may be lowered.
>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
> ---
> Changes v1->v2
> * in tg3_set_ringparam(), reduce gso_max_segs further to budget 3 descriptors
> per gso seg instead of only 1 as in v1
> * in tg3_tso_bug(), check that this estimation (3 desc/seg) holds, otherwise
> linearize some skbs as needed
> * in tg3_start_xmit(), make the queue stop threshold a parameter, for the
> reason explained in the commit description
>
> I was concerned that this last change, because of the extra call in the
> default xmit path, may impact performance so I performed an rr latency test
> but I did not measure a significant impact. That test was with default mtu and
> ring size.
>
> # perf stat -r10 -ad netperf -H 192.168.9.30 -l60 -T 0,0 -t omni -- -d rr
>
> * without patches
> rr values: 7039.63 6865.03 6939.21 6919.31 6931.88 6932.74 6925.1 6953.33 6868.43 6935.65
> sample size: 10
> mean: 6931.031
> standard deviation: 48.10918
> quantiles: 6865.03 6920.757 6932.31 6938.32 7039.63
> 6930±50
>
> Performance counter stats for 'netperf -H 192.168.9.30 -l60 -T 0,0 -t omni -- -d rr' (10 runs):
>
> 480643.024723 task-clock # 8.001 CPUs utilized ( +- 0.00% ) [100.00%]
> 855,136 context-switches # 0.002 M/sec ( +- 0.23% ) [100.00%]
> 521 CPU-migrations # 0.000 M/sec ( +- 6.49% ) [100.00%]
> 104 page-faults # 0.000 M/sec ( +- 2.73% )
> 298,416,906,437 cycles # 0.621 GHz ( +- 4.08% ) [15.01%]
> 812,072,320,370 stalled-cycles-frontend # 272.13% frontend cycles idle ( +- 1.89% ) [25.01%]
> 685,633,562,247 stalled-cycles-backend # 229.76% backend cycles idle ( +- 2.50% ) [35.00%]
> 117,665,891,888 instructions # 0.39 insns per cycle
> # 6.90 stalled cycles per insn ( +- 2.22% ) [45.00%]
> 26,158,399,505 branches # 54.424 M/sec ( +- 2.10% ) [50.00%]
> 205,688,614 branch-misses # 0.79% of all branches ( +- 0.78% ) [50.00%]
> 27,882,474,171 L1-dcache-loads # 58.011 M/sec ( +- 1.98% ) [50.00%]
> 369,911,372 L1-dcache-load-misses # 1.33% of all L1-dcache hits ( +- 0.62% ) [50.00%]
> 76,240,847 LLC-loads # 0.159 M/sec ( +- 1.04% ) [40.00%]
> 3,220 LLC-load-misses # 0.00% of all LL-cache hits ( +- 19.49% ) [ 5.00%]
>
> 60.074059340 seconds time elapsed ( +- 0.00% )
>
> * with patches
> rr values: 6732.65 6920.1 6909.46 7032.41 6864.43 6897.6 6815.19 6967.83 6849.23 6929.52
> sample size: 10
> mean: 6891.842
> standard deviation: 82.91901
> quantiles: 6732.65 6853.03 6903.53 6927.165 7032.41
> 6890±80
>
> Performance counter stats for 'netperf -H 192.168.9.30 -l60 -T 0,0 -t omni -- -d rr' (10 runs):
>
> 480675.949728 task-clock # 8.001 CPUs utilized ( +- 0.01% ) [100.00%]
> 850,461 context-switches # 0.002 M/sec ( +- 0.37% ) [100.00%]
> 564 CPU-migrations # 0.000 M/sec ( +- 5.67% ) [100.00%]
> 417 page-faults # 0.000 M/sec ( +- 76.04% )
> 287,019,442,295 cycles # 0.597 GHz ( +- 7.16% ) [15.01%]
> 828,198,830,689 stalled-cycles-frontend # 288.55% frontend cycles idle ( +- 3.01% ) [25.01%]
> 718,230,307,166 stalled-cycles-backend # 250.24% backend cycles idle ( +- 3.53% ) [35.00%]
> 117,976,598,188 instructions # 0.41 insns per cycle
> # 7.02 stalled cycles per insn ( +- 4.06% ) [45.00%]
> 26,715,853,108 branches # 55.580 M/sec ( +- 3.77% ) [50.00%]
> 198,787,673 branch-misses # 0.74% of all branches ( +- 0.86% ) [50.00%]
> 28,416,922,166 L1-dcache-loads # 59.119 M/sec ( +- 3.54% ) [50.00%]
> 367,613,007 L1-dcache-load-misses # 1.29% of all L1-dcache hits ( +- 0.47% ) [50.00%]
> 75,260,575 LLC-loads # 0.157 M/sec ( +- 2.24% ) [40.00%]
> 5,777 LLC-load-misses # 0.01% of all LL-cache hits ( +- 36.03% ) [ 5.00%]
>
> 60.077898757 seconds time elapsed ( +- 0.01% )
>
> I reproduced this bug using the same approach explained in patch 1.
> The bug reproduces with tx_pending <= 135
>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 67 +++++++++++++++++++++++++++++--------
> drivers/net/ethernet/broadcom/tg3.h | 1 +
> 2 files changed, 54 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 0cecd6d..c29f2e3 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -204,6 +204,10 @@ static inline void _tg3_flag_clear(enum TG3_FLAGS flag, unsigned long *bits)
> /* minimum number of free TX descriptors required to wake up TX process */
> #define TG3_TX_WAKEUP_THRESH(tnapi) max_t(u32, (tnapi)->tx_pending / 4, \
> MAX_SKB_FRAGS + 1)
> +/* estimate a certain number of descriptors per gso segment */
> +#define TG3_TX_DESC_PER_SEG(seg_nb) ((seg_nb) * 3)
> +#define TG3_TX_SEG_PER_DESC(desc_nb) ((desc_nb) / 3)
> +
> #define TG3_TX_BD_DMA_MAX_2K 2048
> #define TG3_TX_BD_DMA_MAX_4K 4096
>
> @@ -6609,10 +6613,10 @@ static void tg3_tx(struct tg3_napi *tnapi)
> smp_mb();
>
> if (unlikely(netif_tx_queue_stopped(txq) &&
> - (tg3_tx_avail(tnapi) > TG3_TX_WAKEUP_THRESH(tnapi)))) {
> + (tg3_tx_avail(tnapi) > tnapi->wakeup_thresh))) {
> __netif_tx_lock(txq, smp_processor_id());
> if (netif_tx_queue_stopped(txq) &&
> - (tg3_tx_avail(tnapi) > TG3_TX_WAKEUP_THRESH(tnapi)))
> + (tg3_tx_avail(tnapi) > tnapi->wakeup_thresh))
> netif_tx_wake_queue(txq);
> __netif_tx_unlock(txq);
> }
> @@ -7830,6 +7834,8 @@ static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
> }
>
> static netdev_tx_t tg3_start_xmit(struct sk_buff *, struct net_device *);
> +static netdev_tx_t __tg3_start_xmit(struct sk_buff *, struct net_device *,
> + u32);
>
> /* Use GSO to workaround all TSO packets that meet HW bug conditions
> * indicated in tg3_tx_frag_set()
> @@ -7838,11 +7844,13 @@ static int tg3_tso_bug(struct tg3 *tp, struct tg3_napi *tnapi,
> struct netdev_queue *txq, struct sk_buff *skb)
> {
> struct sk_buff *segs, *nskb;
> - u32 frag_cnt_est = skb_shinfo(skb)->gso_segs * 3;
> + unsigned int segs_remaining = skb_shinfo(skb)->gso_segs;
> + u32 desc_cnt_est = TG3_TX_DESC_PER_SEG(segs_remaining);
>
> - /* Estimate the number of fragments in the worst case */
> - if (unlikely(tg3_tx_avail(tnapi) <= frag_cnt_est)) {
> + if (unlikely(tg3_tx_avail(tnapi) <= desc_cnt_est)) {
> netif_tx_stop_queue(txq);
> + tnapi->wakeup_thresh = desc_cnt_est;
> + BUG_ON(tnapi->wakeup_thresh >= tnapi->tx_pending);
>
> /* netif_tx_stop_queue() must be done before checking
> * checking tx index in tg3_tx_avail() below, because in
> @@ -7850,7 +7858,7 @@ static int tg3_tso_bug(struct tg3 *tp, struct tg3_napi *tnapi,
> * netif_tx_queue_stopped().
> */
> smp_mb();
> - if (tg3_tx_avail(tnapi) <= frag_cnt_est)
> + if (tg3_tx_avail(tnapi) <= tnapi->wakeup_thresh)
> return NETDEV_TX_BUSY;
>
> netif_tx_wake_queue(txq);
> @@ -7858,14 +7866,33 @@ static int tg3_tso_bug(struct tg3 *tp, struct tg3_napi *tnapi,
>
> segs = skb_gso_segment(skb, tp->dev->features &
> ~(NETIF_F_TSO | NETIF_F_TSO6));
> - if (IS_ERR(segs) || !segs)
> + if (IS_ERR_OR_NULL(segs))
> goto tg3_tso_bug_end;
>
> do {
> + unsigned int desc_cnt = skb_shinfo(segs)->nr_frags + 1;
> +
> nskb = segs;
> segs = segs->next;
> nskb->next = NULL;
> - tg3_start_xmit(nskb, tp->dev);
> +
> + if (tg3_tx_avail(tnapi) <= segs_remaining - 1 + desc_cnt &&
> + skb_linearize(nskb)) {
> + nskb->next = segs;
> + segs = nskb;
> + do {
> + nskb = segs->next;
> +
> + dev_kfree_skb_any(segs);
> + segs = nskb;
> + } while (segs);
If skb_linearize() fails need to increment the tp->tx_dropped count
> + goto tg3_tso_bug_end;
> + }
> + segs_remaining--;
> + if (segs_remaining)
> + __tg3_start_xmit(nskb, tp->dev, segs_remaining);
To clarify passing segs_remaining will make sure the queue is never
stopped correct ?
> + else
> + tg3_start_xmit(nskb, tp->dev);
> } while (segs);
>
> tg3_tso_bug_end:
> @@ -7877,6 +7904,12 @@ tg3_tso_bug_end:
> /* hard_start_xmit for all devices */
> static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> + return __tg3_start_xmit(skb, dev, MAX_SKB_FRAGS + 1);
> +}
> +
> +static netdev_tx_t __tg3_start_xmit(struct sk_buff *skb,
> + struct net_device *dev, u32 stop_thresh)
> +{
> struct tg3 *tp = netdev_priv(dev);
> u32 len, entry, base_flags, mss, vlan = 0;
> u32 budget;
> @@ -7905,12 +7938,17 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
> if (unlikely(budget <= (skb_shinfo(skb)->nr_frags + 1))) {
> if (!netif_tx_queue_stopped(txq)) {
> netif_tx_stop_queue(txq);
> + tnapi->wakeup_thresh = TG3_TX_WAKEUP_THRESH(tnapi);
>
> /* This is a hard error, log it. */
> netdev_err(dev,
> "BUG! Tx Ring full when queue awake!\n");
> }
> - return NETDEV_TX_BUSY;
> + smp_mb();
> + if (tg3_tx_avail(tnapi) <= tnapi->wakeup_thresh)
> + return NETDEV_TX_BUSY;
> +
> + netif_tx_wake_queue(txq);
> }
>
> entry = tnapi->tx_prod;
> @@ -8087,8 +8125,9 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
> tw32_tx_mbox(tnapi->prodmbox, entry);
>
> tnapi->tx_prod = entry;
> - if (unlikely(tg3_tx_avail(tnapi) <= (MAX_SKB_FRAGS + 1))) {
> + if (unlikely(tg3_tx_avail(tnapi) <= stop_thresh)) {
> netif_tx_stop_queue(txq);
> + tnapi->wakeup_thresh = TG3_TX_WAKEUP_THRESH(tnapi);
>
> /* netif_tx_stop_queue() must be done before checking
> * checking tx index in tg3_tx_avail() below, because in
> @@ -8096,7 +8135,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
> * netif_tx_queue_stopped().
> */
> smp_mb();
> - if (tg3_tx_avail(tnapi) > TG3_TX_WAKEUP_THRESH(tnapi))
> + if (tg3_tx_avail(tnapi) > tnapi->wakeup_thresh)
> netif_tx_wake_queue(txq);
> }
>
> @@ -12319,9 +12358,7 @@ static int tg3_set_ringparam(struct net_device *dev, struct ethtool_ringparam *e
> if ((ering->rx_pending > tp->rx_std_ring_mask) ||
> (ering->rx_jumbo_pending > tp->rx_jmb_ring_mask) ||
> (ering->tx_pending > TG3_TX_RING_SIZE - 1) ||
> - (ering->tx_pending <= MAX_SKB_FRAGS + 1) ||
> - (tg3_flag(tp, TSO_BUG) &&
> - (ering->tx_pending <= (MAX_SKB_FRAGS * 3))))
> + (ering->tx_pending <= MAX_SKB_FRAGS + 1))
> return -EINVAL;
>
> if (netif_running(dev)) {
> @@ -12341,6 +12378,7 @@ static int tg3_set_ringparam(struct net_device *dev, struct ethtool_ringparam *e
> if (tg3_flag(tp, JUMBO_RING_ENABLE))
> tp->rx_jumbo_pending = ering->rx_jumbo_pending;
>
> + dev->gso_max_segs = TG3_TX_SEG_PER_DESC(ering->tx_pending - 1);
> for (i = 0; i < tp->irq_max; i++)
> tp->napi[i].tx_pending = ering->tx_pending;
>
> @@ -17817,6 +17855,7 @@ static int tg3_init_one(struct pci_dev *pdev,
> else
> sndmbx += 0xc;
> }
> + dev->gso_max_segs = TG3_TX_SEG_PER_DESC(TG3_DEF_TX_RING_PENDING - 1);
>
> tg3_init_coal(tp);
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
> index 461acca..6a7e13d 100644
> --- a/drivers/net/ethernet/broadcom/tg3.h
> +++ b/drivers/net/ethernet/broadcom/tg3.h
> @@ -3006,6 +3006,7 @@ struct tg3_napi {
> u32 tx_pending;
> u32 last_tx_cons;
> u32 prodmbox;
> + u32 wakeup_thresh;
> struct tg3_tx_buffer_desc *tx_ring;
> struct tg3_tx_ring_info *tx_buffers;
>
^ permalink raw reply
* Re: [PATCH v5 1/2] net: moxa: clear TX descriptor length bits
From: David Miller @ 2014-08-22 4:39 UTC (permalink / raw)
To: jonas.jensen
Cc: netdev, linux-arm-kernel, linux-kernel, f.fainelli, eric.dumazet
In-Reply-To: <1408544322-32023-1-git-send-email-jonas.jensen@gmail.com>
From: Jonas Jensen <jonas.jensen@gmail.com>
Date: Wed, 20 Aug 2014 16:18:42 +0200
> @@ -348,7 +348,8 @@ static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>
> txdes1 = readl(desc + TX_REG_OFFSET_DESC1);
> txdes1 |= TX_DESC1_LTS | TX_DESC1_FTS;
> - txdes1 &= ~(TX_DESC1_FIFO_COMPLETE | TX_DESC1_INTR_COMPLETE);
> + txdes1 &= ~(TX_DESC1_FIFO_COMPLETE | TX_DESC1_INTR_COMPLETE |
> + TX_DESC1_BUF_SIZE_MASK);
> txdes1 |= (len & TX_DESC1_BUF_SIZE_MASK);
> writel(txdes1, desc + TX_REG_OFFSET_DESC1);
> writel(TX_DESC0_DMA_OWN, desc + TX_REG_OFFSET_DESC0);
Like others I wonder why the existing descriptor value is being read
at all.
It's inefficient and completely unnecessary, you can just compute a new
value from scratch, and that way all of these "uncleared field" issues
just automatically disappear.
^ permalink raw reply
* Re: [PATCH] net: ethernet: broadcom: bnx2x: Remove redundant #ifdef
From: David Miller @ 2014-08-22 4:37 UTC (permalink / raw)
To: linux; +Cc: ariel.elior, netdev, linux-kernel
In-Reply-To: <1408540489-1795-1-git-send-email-linux@rasmusvillemoes.dk>
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date: Wed, 20 Aug 2014 15:14:49 +0200
> Nothing defines _ASM_GENERIC_INT_L64_H, it is a weird way to check for
> 64 bit longs, and u64 should be printed using %llx anyway.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
It's not correct and will warn on some platforms where "u64" is just
a plain "unsigned long".
Ie. all of those which use include/asm-generic/int-l64.h
I'm not applying this.
^ permalink raw reply
* Re: [PATCH 1/1] sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe
From: David Miller @ 2014-08-22 4:35 UTC (permalink / raw)
To: zyjzyj2000
Cc: dborkman, linux-kernel, netdev, vyasevich, tuexen,
khandelwal.deepak.1987, Yue.Tao, alexandre.dietsch, Yanjun.Zhu
In-Reply-To: <1408527103-22772-2-git-send-email-Yanjun.Zhu@windriver.com>
From: Zhu Yanjun <zyjzyj2000@gmail.com>
Date: Wed, 20 Aug 2014 17:31:43 +0800
> Since the transport has always been in state SCTP_UNCONFIRMED, it
> therefore wasn't active before and hasn't been used before, and it
> always has been, so it is unnecessary to bug the user with a
> notification.
>
> Reported-by: Deepak Khandelwal <khandelwal.deepak.1987@gmail.com>
> Suggested-by: Vlad Yasevich <vyasevich@gmail.com>
> Suggested-by: Michael Tuexen <tuexen@fh-muenster.de>
> Suggested-by: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] hyperv: Add handling of IP header with option field in netvsc_set_hash()
From: David Miller @ 2014-08-22 4:30 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1408481635-29639-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Tue, 19 Aug 2014 20:53:55 +0000
> @@ -200,12 +202,18 @@ static bool netvsc_set_hash(u32 *hash, struct sk_buff *skb)
> iphdr = ip_hdr(skb);
>
> if (iphdr->version == 4) {
> - if (iphdr->protocol == IPPROTO_TCP)
> + data = (u8 *)&iphdr->saddr;
> + if (iphdr->protocol == IPPROTO_TCP) {
> data_len = 12;
> - else
> + if (iphdr->ihl > 5) {
> + memcpy(dbuf, &iphdr->saddr, 8);
> + memcpy(&dbuf[8], &tcp_hdr(skb)->source, 4);
This is rediculous.
Make hash_comp() take a void pointer for the buffer.
Then your code is simply:
be32 dbuf[2];
dbuf[1] = iph->saddr;
dbuf[2] = iph->daddr;
dbuf[3] = *(be32 *)tcph->source;
*hash = comp_hash(netvsc_hash_key, HASH_KEYLEN, dbuf, 12);
No special cases for IP options or any garbage like that.
^ permalink raw reply
* Re: [PATCH net] vxlan: fix incorrect initializer in union vxlan_addr
From: David Miller @ 2014-08-22 4:27 UTC (permalink / raw)
To: gstenzel; +Cc: netdev
In-Reply-To: <53F3B55B.6070505@linux.vnet.ibm.com>
From: Gerhard Stenzel <gstenzel@linux.vnet.ibm.com>
Date: Tue, 19 Aug 2014 22:36:43 +0200
> Trying again ...
This is not the correct way to resubmit a patch properly.
Do not ever submit a new copy of a patch as a reply to a discussion
thread, quoting unrelated material, etc.
Instead, make a new, fresh, mailing list posting as if you were
posting the patch for the first time. Except you add
"[PATCH v2 net]" or similar to indicate this is a new submission
of the patch.
^ permalink raw reply
* Re: [PATCH 2/3] tg3: Fix tx_pending checks for tg3_tso_bug
From: David Miller @ 2014-08-22 4:25 UTC (permalink / raw)
To: bpoirier; +Cc: mchan, prashant, netdev, linux-kernel
In-Reply-To: <20140821215911.GA7117@f1.synalogic.ca>
From: Benjamin Poirier <bpoirier@suse.de>
Date: Thu, 21 Aug 2014 14:59:11 -0700
> Ah, now I understand the reason for the * 3 in
> u32 frag_cnt_est = skb_shinfo(skb)->gso_segs * 3;
>
> /* Estimate the number of fragments in the worst case */
> but that is not really the "worst case". It's not forbidden to have more than
> two frags per skb output from skb_gso_segment(). I've kept this estimation
> approach but I've added code to validate the estimation or else linearize the
> skb.
This is a common situation drivers run into, and there have been a few
notable situations in virtualization drivers recently. Although in
those cases the problems arise from the fact that if an SKB fragment
is a compound page, this can evaluate to requiring multiple
descriptors, one for each 4K segment within that fragment.
Anyways, the point I wanted to make is that you shouldn't do anything
too complicated to handle all of this. And I think your conclusion
to linearize if the estimation fails is a good one.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Jason Wang @ 2014-08-22 2:53 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: davem, netdev, linux-kernel
In-Reply-To: <20140821081140.GA29116@redhat.com>
On 08/21/2014 04:11 PM, Michael S. Tsirkin wrote:
> On Thu, Aug 21, 2014 at 04:05:10PM +0800, Jason Wang wrote:
>> > Rx busy loop does not scale well in the case when several parallel
>> > sessions is active. This is because we keep looping even if there's
>> > another process is runnable. For example, if that process is about to
>> > send packet, keep busy polling in current process will brings extra
>> > delay and damage the performance.
>> >
>> > This patch solves this issue by exiting the busy loop when there's
>> > another process is runnable in current cpu. Simple test that pin two
>> > netperf sessions in the same cpu in receiving side shows obvious
>> > improvement:
>> >
>> > Before:
>> > netperf -H 192.168.100.2 -T 0,0 -t TCP_RR -P 0 & \
>> > netperf -H 192.168.100.2 -T 1,0 -t TCP_RR -P 0
>> > 16384 87380 1 1 10.00 15513.74
>> > 16384 87380
>> > 16384 87380 1 1 10.00 15092.78
>> > 16384 87380
>> >
>> > After:
>> > netperf -H 192.168.100.2 -T 0,0 -t TCP_RR -P 0 & \
>> > netperf -H 192.168.100.2 -T 1,0 -t TCP_RR -P 0
>> > 16384 87380 1 1 10.00 23334.53
>> > 16384 87380
>> > 16384 87380 1 1 10.00 23327.58
>> > 16384 87380
>> >
>> > Benchmark was done through two 8 cores Xeon machine back to back connected
>> > with mlx4 through netperf TCP_RR test (busy_read were set to 50):
>> >
>> > sessions/bytes/before/after/+improvement%/busy_read=0/
>> > 1/1/30062.10/30034.72/+0%/20228.96/
>> > 16/1/214719.83/307669.01/+43%/268997.71/
>> > 32/1/231252.81/345845.16/+49%/336157.442/
>> > 64/512/212467.39/373464.93/+75%/397449.375/
>> >
>> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>> > ---
>> > include/net/busy_poll.h | 3 ++-
>> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h
>> > index 1d67fb6..8a33fb2 100644
>> > --- a/include/net/busy_poll.h
>> > +++ b/include/net/busy_poll.h
>> > @@ -109,7 +109,8 @@ static inline bool sk_busy_loop(struct sock *sk, int nonblock)
>> > cpu_relax();
>> >
>> > } while (!nonblock && skb_queue_empty(&sk->sk_receive_queue) &&
>> > - !need_resched() && !busy_loop_timeout(end_time));
>> > + !need_resched() && !busy_loop_timeout(end_time) &&
>> > + nr_running_this_cpu() < 2);
> <= 1 would be a bit clearer? We want at most one process here.
>
Ok, will change it in next version.
^ permalink raw reply
* Re: [PATCH v2 2/3] net: Add Keystone NetCP ethernet driver
From: Stephen Hemminger @ 2014-08-22 2:48 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, sandeep_n-l0cyMroinI0
In-Reply-To: <1408115562-22487-3-git-send-email-santosh.shilimkar-l0cyMroinI0@public.gmane.org>
On Fri, 15 Aug 2014 11:12:41 -0400
Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org> wrote:
> NetCP driver has a plug-in module architecture where each of the NetCP
> sub-modules exist as a loadable kernel module which plug in to the netcp
> core. These sub-modules are represented as "netcp-devices" in the dts
> bindings. It is mandatory to have the ethernet switch sub-module for
> the ethernet interface to be operational. Any other sub-module like the
> PA is optional.
What are you doing to prevent/discourage proprietary binary only
sub-modules?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 1/1] netfilter/jump_label: HAVE_JUMP_LABEL instead of CONFIG_JUMP_LABEL
From: Zhouyi Zhou @ 2014-08-22 2:40 UTC (permalink / raw)
To: fw, pablo, kaber, kadlec, davem, netfilter-devel, coreteam,
netdev, linux-kernel, jbaron
Cc: Zhouyi Zhou
Use HAVE_JUMP_LABEL as elsewhere in the kernel to ensure
that the toolchain has the required support in addition to
CONFIG_JUMP_LABEL being set.
Signed-off-by: Zhouyi Zhou <yizhouzhou@ict.ac.cn>
Reviewed-by: Florian Westphal <fw@strlen.de>
---
include/linux/netfilter.h | 5 +++--
net/netfilter/core.c | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index 2077489..83a1952 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -9,6 +9,7 @@
#include <linux/in6.h>
#include <linux/wait.h>
#include <linux/list.h>
+#include <linux/static_key.h>
#include <uapi/linux/netfilter.h>
#ifdef CONFIG_NETFILTER
static inline int NF_DROP_GETERR(int verdict)
@@ -99,8 +100,8 @@ void nf_unregister_sockopt(struct nf_sockopt_ops *reg);
extern struct list_head nf_hooks[NFPROTO_NUMPROTO][NF_MAX_HOOKS];
-#if defined(CONFIG_JUMP_LABEL)
-#include <linux/static_key.h>
+#ifdef HAVE_JUMP_LABEL
+
extern struct static_key nf_hooks_needed[NFPROTO_NUMPROTO][NF_MAX_HOOKS];
static inline bool nf_hooks_active(u_int8_t pf, unsigned int hook)
{
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index a93c97f..024a2e2 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -54,7 +54,7 @@ EXPORT_SYMBOL_GPL(nf_unregister_afinfo);
struct list_head nf_hooks[NFPROTO_NUMPROTO][NF_MAX_HOOKS] __read_mostly;
EXPORT_SYMBOL(nf_hooks);
-#if defined(CONFIG_JUMP_LABEL)
+#ifdef HAVE_JUMP_LABEL
struct static_key nf_hooks_needed[NFPROTO_NUMPROTO][NF_MAX_HOOKS];
EXPORT_SYMBOL(nf_hooks_needed);
#endif
@@ -72,7 +72,7 @@ int nf_register_hook(struct nf_hook_ops *reg)
}
list_add_rcu(®->list, elem->list.prev);
mutex_unlock(&nf_hook_mutex);
-#if defined(CONFIG_JUMP_LABEL)
+#ifdef HAVE_JUMP_LABEL
static_key_slow_inc(&nf_hooks_needed[reg->pf][reg->hooknum]);
#endif
return 0;
@@ -84,7 +84,7 @@ void nf_unregister_hook(struct nf_hook_ops *reg)
mutex_lock(&nf_hook_mutex);
list_del_rcu(®->list);
mutex_unlock(&nf_hook_mutex);
-#if defined(CONFIG_JUMP_LABEL)
+#ifdef HAVE_JUMP_LABEL
static_key_slow_dec(&nf_hooks_needed[reg->pf][reg->hooknum]);
#endif
synchronize_net();
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH net-next 3/4] r8152: remove clear_bp function
From: Hayes Wang @ 2014-08-22 2:38 UTC (permalink / raw)
To: Sergei Shtylyov, netdev@vger.kernel.org
Cc: nic_swsd, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <53F62C78.8040404@cogentembedded.com>
Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
[...]
> >> Why leave 2 empty lines? One is enough.
>
> > The next patch would use another fucntion at the
> > same location. I skip removing the empty line and
> > re-adding it again. Is that better to do so? I would
> > resend the patches if the answer is yes.
>
> Sorry, I haven't looked at your next patch, too big for me. :-)
It's my mistake. I would avoid it next time. Thanks for your notice.
Best Regards,
Hayes
^ permalink raw reply
* Re: TCP output handling bug ?
From: Dave Jones @ 2014-08-22 2:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Alan Cox, netdev
In-Reply-To: <20140821172445.7c1ba422@uryu.home.lan>
On Thu, Aug 21, 2014 at 05:24:45PM -0700, Stephen Hemminger wrote:
> On Thu, 21 Aug 2014 19:02:08 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> >
> > tcp_send_syn_data:
> >
> > TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
> > TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
> >
> > the reporter has a point 8)
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=82101
>
> I wonder if covertity or smatch could be smart enough to catch this kind of bug?
For coverity: it should be, but isn't :)
I've pointed them at the bugzilla, maybe they can add a check in a
future update.
I bet this isn't the only instance of a bug like this left in the tree.
We've definitely had similar cases before.
Dave
^ permalink raw reply
* [PATCH] ibmveth: Fix endian issues with rx_no_buffer statistic
From: Anton Blanchard @ 2014-08-22 1:36 UTC (permalink / raw)
To: santil, paulus; +Cc: linuxppc-dev, netdev
Hidden away in the last 8 bytes of the buffer_list page is a solitary
statistic. It needs to be byte swapped or else ethtool -S will
produce numbers that terrify the user.
Since we do this in multiple places, create a helper function with a
comment explaining what is going on.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
---
Index: b/drivers/net/ethernet/ibm/ibmveth.c
===================================================================
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -292,6 +292,18 @@ failure:
atomic_add(buffers_added, &(pool->available));
}
+/*
+ * The final 8 bytes of the buffer list is a counter of frames dropped
+ * because there was not a buffer in the buffer list capable of holding
+ * the frame.
+ */
+static void ibmveth_update_rx_no_buffer(struct ibmveth_adapter *adapter)
+{
+ __be64 *p = adapter->buffer_list_addr + 4096 - 8;
+
+ adapter->rx_no_buffer = be64_to_cpup(p);
+}
+
/* replenish routine */
static void ibmveth_replenish_task(struct ibmveth_adapter *adapter)
{
@@ -307,8 +319,7 @@ static void ibmveth_replenish_task(struc
ibmveth_replenish_buffer_pool(adapter, pool);
}
- adapter->rx_no_buffer = *(u64 *)(((char*)adapter->buffer_list_addr) +
- 4096 - 8);
+ ibmveth_update_rx_no_buffer(adapter);
}
/* empty and free ana buffer pool - also used to do cleanup in error paths */
@@ -698,8 +709,7 @@ static int ibmveth_close(struct net_devi
free_irq(netdev->irq, netdev);
- adapter->rx_no_buffer = *(u64 *)(((char *)adapter->buffer_list_addr) +
- 4096 - 8);
+ ibmveth_update_rx_no_buffer(adapter);
ibmveth_cleanup(adapter);
^ permalink raw reply
* Re: pull request (net-next): ipsec-next 2014-07-30
From: David Miller @ 2014-08-22 1:11 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20140819102932.GA6390@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 19 Aug 2014 12:29:32 +0200
> On Wed, Jul 30, 2014 at 08:06:16PM -0700, David Miller wrote:
>> From: Steffen Klassert <steffen.klassert@secunet.com>
>> Date: Wed, 30 Jul 2014 13:12:25 +0200
>>
>> > This is the last pull request for ipsec-next before I'll be
>> > off for two weeks starting on friday. David, can you please
>> > take urgent ipsec patches directly into net/net-next during
>> > this time?
>>
>> Sure, no problem.
>>
>
> I'm back and continue to run the IPsec trees.
>
> Thanks for helping out in the meantime!
Welcome back :-)
^ permalink raw reply
* Re: [PATCH net] bnx2x: Revert UNDI flushing mechanism
From: David Miller @ 2014-08-22 0:55 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, Ariel.Elior
In-Reply-To: <1408390583-22693-1-git-send-email-Yuval.Mintz@qlogic.com>
From: Yuval Mintz <Yuval.Mintz@qlogic.com>
Date: Mon, 18 Aug 2014 22:36:23 +0300
> Commit 91ebb929b6f8 ("bnx2x: Add support for Multi-Function UNDI") [which was
> later supposedly fixed by de682941eef3 ("bnx2x: Fix UNDI driver unload")]
> introduced a bug in which in some [yet-to-be-determined] scenarios the
> alternative flushing mechanism which was to guarantee the Rx buffers are
> empty before resetting them during device probe will fail.
> If this happens, when device will be loaded once more a fatal attention will
> occur; Since this most likely happens in boot from SAN scenarios, the machine
> will fail to load.
>
> Notice this may occur not only in the 'Multi-Function' scenario but in the
> regular scenario as well, i.e., this introduced a regression in the driver's
> ability to perform boot from SAN.
>
> The patch reverts the mechanism and applies the old scheme to multi-function
> devices as well as to single-function devices.
>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
> Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net 0/3] qlcnic: Bug fixes
From: David Miller @ 2014-08-22 0:43 UTC (permalink / raw)
To: shahed.shaikh; +Cc: netdev, Dept-HSGLinuxNICDev
In-Reply-To: <1408368715-8048-1-git-send-email-shahed.shaikh@qlogic.com>
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
Date: Mon, 18 Aug 2014 09:31:52 -0400
> This series fixes some bugs related to endianess.
>
> Please apply this series to net.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: Add section for MRF24J40 IEEE 802.15.4 radio driver
From: David Miller @ 2014-08-22 0:37 UTC (permalink / raw)
To: alan; +Cc: alex.aring, linux-wpan, netdev, linux-kernel
In-Reply-To: <1408223343-6031-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Sat, 16 Aug 2014 17:09:03 -0400
> Alan is the original author of the driver. This change was discussed
> with the 802.15.4 subsystem maintainer, Alexander Aring.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next 1/3] net: propagate sock pointer through netfilter hooks
From: David Miller @ 2014-08-22 0:33 UTC (permalink / raw)
To: jiri
Cc: netdev, kuznet, jmorris, yoshfuji, stephen, cwang, pshelar,
nicolas.dichtel, therbert, dborkman, edumazet
In-Reply-To: <1408127576-11518-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 15 Aug 2014 20:32:54 +0200
> When output function (ip6_finish_output2 for example) needs to be called
> with sock pointer, we need to push sock pointer through the netfilter
> hooks. This patch does that.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Ok, I'm going to admit that I am having second thoughts about this
approach. This is a quite large set of churn to fix this bug.
However, in the same breath, I can't come up with a simpler way to
propagate this information without the really unacceptable overhead of
adding another sk_buff member.
And even if we found some simple way to deal with that sk_mc_loop()
test, ipv6 has other demons in this area.
For example, look at what ip6_fragment() does, it also assumes skb->sk
is an inet6 socket.
struct ipv6_pinfo *np = skb->sk ? inet6_sk(skb->sk) : NULL;
...
if (np && np->frag_size < mtu) {
if (np->frag_size)
mtu = np->frag_size;
}
The rest of the skb->sk usage in these place is fine, as they are
simply propagating socket ownership from one packet to another, rather
than doing protocol specific things with them.
^ permalink raw reply
* Re: TCP output handling bug ?
From: Stephen Hemminger @ 2014-08-22 0:24 UTC (permalink / raw)
To: Alan Cox; +Cc: netdev
In-Reply-To: <20140821190208.208e0de1@www.etchedpixels.co.uk>
On Thu, 21 Aug 2014 19:02:08 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> tcp_send_syn_data:
>
> TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
> TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
>
> the reporter has a point 8)
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=82101
> --
> 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
I wonder if covertity or smatch could be smart enough to catch this kind of bug?
^ permalink raw reply
* Re: [PATCH] macvlan: Allow setting multicast filter on all macvlan types
From: David Miller @ 2014-08-21 23:54 UTC (permalink / raw)
To: vyasevic; +Cc: netdev, john.r.fastabend, mst, jasowang
In-Reply-To: <1408122299-29632-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevic@redhat.com>
Date: Fri, 15 Aug 2014 13:04:59 -0400
> Currently, macvlan code restricts multicast and unicast
> filter setting only to passthru devices. As a result,
> if a guest using macvtap wants to receive multicast
> traffic, it has to set IFF_ALLMULTI or IFF_PROMISC.
>
> This patch makes it possible to use the fdb interface
> to add multicast addresses to the filter thus allowing
> a guest to receive only targeted multicast traffic.
>
> CC: John Fastabend <john.r.fastabend@intel.com>
> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Applied, thanks Vlad.
^ permalink raw reply
* Re: Performance regression on kernels 3.10 and newer
From: David Miller @ 2014-08-21 23:51 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: eric.dumazet, netdev
In-Reply-To: <53EE4023.6080902@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 15 Aug 2014 10:15:15 -0700
> This is one of the reasons why I keep asking if someone can tell me
> what the use case is for this where it performs well.
It allows the TCP connection to be paced by the process scheduler's
ability to put the thread doing the I/O on a cpu.
^ permalink raw reply
* Re: [PATCH v1 net] packet: handle too big packets for PACKET_V3
From: David Miller @ 2014-08-21 23:45 UTC (permalink / raw)
To: eric.dumazet; +Cc: hannes, dborkman, nhorman, brouer, netdev, guy
In-Reply-To: <1408119364.6804.89.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 15 Aug 2014 09:16:04 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> af_packet can currently overwrite kernel memory by out of bound
> accesses, because it assumed a [new] block can always hold one frame.
>
> This is not generally the case, even if most existing tools do it right.
>
> This patch clamps too long frames as API permits, and issue a one time
> error on syslog.
>
> [ 394.357639] tpacket_rcv: packet too big, clamped from 5042 to 3966. macoff=82
>
> In this example, packet header tp_snaplen was set to 3966,
> and tp_len was set to 5042 (skb->len)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
Since both the skb->len and the snaplen are provided to the user in
the ring entry descriptor, it is correct to fix this problem by simply
truncating.
Applied and queued up for -stable, thanks a lot Eric.
^ 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