* Re: [PATCH] net+crypto: Use vmalloc for zlib inflate buffers.
From: Herbert Xu @ 2011-06-28 4:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eilong, mjackson220.list
In-Reply-To: <20110627.212618.657750275676567934.davem@davemloft.net>
On Mon, Jun 27, 2011 at 09:26:18PM -0700, David Miller wrote:
>
> They are 64K and result in order-4 allocations, even with SLUB.
>
> Therefore, just like we always have for the deflate buffers, use
> vmalloc.
>
> Reported-by: Martin Jackson <mjackson220.list@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 14/19] sky2: remove unnecessary reads of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:42 UTC (permalink / raw)
To: jdmason; +Cc: shemminger, netdev
In-Reply-To: <1309196816-16198-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:46:56 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it. Also, pci_is_pcie is a
> better way of determining if the device is PCIE or not (as it uses the
> same saved PCIE capability offset).
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
^ permalink raw reply
* Re: [PATCH 16/19] vxge: remove unnecessary reads of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:41 UTC (permalink / raw)
To: jdmason; +Cc: netdev
In-Reply-To: <1309196891-16274-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:48:11 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
^ permalink raw reply
* Re: [PATCH 13/19] r8169: remove unnecessary read of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:41 UTC (permalink / raw)
To: jdmason; +Cc: nic_swsd, romieu, netdev
In-Reply-To: <1309196791-16157-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:46:31 -0500
> The PCIE capability offset is saved during PCI bus walking. Use the
> value from pci_dev instead of checking in the driver and saving it off
> the the driver specific structure. Also, it will remove an unnecessary
> search in the PCI configuration space if this value is referenced
> instead of reacquiring it.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
^ permalink raw reply
* Re: [PATCH 12/19] niu: remove unnecessary read of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:41 UTC (permalink / raw)
To: jdmason; +Cc: netdev
In-Reply-To: <1309196744-16123-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:45:44 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
^ permalink raw reply
* Re: [PATCH 11/19] bnx2x: remove unnecessary read of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:41 UTC (permalink / raw)
To: jdmason; +Cc: eilong, netdev
In-Reply-To: <1309196712-16081-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:45:12 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it. Also, pci_is_pcie is a
> better way of determining if the device is PCIE or not (as it uses the
> same saved PCIE capability offset).
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
^ permalink raw reply
* Re: [PATCH 10/19] bnx2: remove unnecessary read of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:41 UTC (permalink / raw)
To: jdmason; +Cc: mchan, netdev
In-Reply-To: <1309196683-16046-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:44:43 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it. Also, pci_is_pcie is a
> better way of determining if the device is PCIE or not (as it uses the
> same saved PCIE capability offset).
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
^ permalink raw reply
* Re: [PATCH 09/19] igb: remove unnecessary reads of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:41 UTC (permalink / raw)
To: jdmason; +Cc: e1000-devel, netdev
In-Reply-To: <1309196641-16003-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:44:01 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 07/19] cxgb3: remove unnecessary read of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:41 UTC (permalink / raw)
To: jdmason; +Cc: divy, netdev
In-Reply-To: <1309196569-15926-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:42:49 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
^ permalink raw reply
* Re: [PATCH 08/19] e1000e: remove unnecessary reads of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:41 UTC (permalink / raw)
To: jdmason; +Cc: e1000-devel, netdev
In-Reply-To: <1309196627-15969-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:43:47 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 06/19] mlx4: remove unnecessary read of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:40 UTC (permalink / raw)
To: jdmason; +Cc: yevgenyp, netdev
In-Reply-To: <1309196537-15879-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 12:42:17 -0500
> The PCIE capability offset is saved during PCI bus walking. It will
> remove an unnecessary search in the PCI configuration space if this
> value is referenced instead of reacquiring it.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied.
^ permalink raw reply
* Re: [PATCH 15/19 v2] tg3: remove unnecessary read of PCI_CAP_ID_EXP
From: David Miller @ 2011-06-28 4:39 UTC (permalink / raw)
To: mcarlson, jdmason; +Cc: mchan, netdev
In-Reply-To: <20110627233352.GA6223@mcarlson.broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>, "Jon Mason" <jdmason@kudzu.us>
Date: Mon, 27 Jun 2011 16:33:52 -0700
> On Mon, Jun 27, 2011 at 03:56:50PM -0700, Jon Mason wrote:
>> The PCIE capability offset is saved during PCI bus walking. Use the
>> value from pci_dev instead of checking in the driver and saving it off
>> the the driver specific structure. It will remove an unnecessary search
>> in the PCI configuration space if this value is referenced instead of
>> reacquiring it.
>>
>> v2 of the patch re-adds the PCI_EXPRESS flag and adds comments
>> describing why it is necessary.
>>
>> Signed-off-by: Jon Mason <jdmason@kudzu.us>
...
> Sorry to be a stickler, but can we convert all occurances of
> 'tp->pdev->pcie_cap' to pci_pcie_cap(tp->pdev)? If the PCI layer is
> taking control of that variable, the driver shouldn't be accessing it
> directly if it can help it.
I did this while adding this patch, thanks.
^ permalink raw reply
* [PATCH] net+crypto: Use vmalloc for zlib inflate buffers.
From: David Miller @ 2011-06-28 4:26 UTC (permalink / raw)
To: netdev; +Cc: eilong, herbert, mjackson220.list
They are 64K and result in order-4 allocations, even with SLUB.
Therefore, just like we always have for the deflate buffers, use
vmalloc.
Reported-by: Martin Jackson <mjackson220.list@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
diff --git a/crypto/deflate.c b/crypto/deflate.c
index b5ccae2..b0165ec 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -32,7 +32,6 @@
#include <linux/interrupt.h>
#include <linux/mm.h>
#include <linux/net.h>
-#include <linux/slab.h>
#define DEFLATE_DEF_LEVEL Z_DEFAULT_COMPRESSION
#define DEFLATE_DEF_WINBITS 11
@@ -73,7 +72,7 @@ static int deflate_decomp_init(struct deflate_ctx *ctx)
int ret = 0;
struct z_stream_s *stream = &ctx->decomp_stream;
- stream->workspace = kzalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
+ stream->workspace = vzalloc(zlib_inflate_workspacesize());
if (!stream->workspace) {
ret = -ENOMEM;
goto out;
@@ -86,7 +85,7 @@ static int deflate_decomp_init(struct deflate_ctx *ctx)
out:
return ret;
out_free:
- kfree(stream->workspace);
+ vfree(stream->workspace);
goto out;
}
@@ -99,7 +98,7 @@ static void deflate_comp_exit(struct deflate_ctx *ctx)
static void deflate_decomp_exit(struct deflate_ctx *ctx)
{
zlib_inflateEnd(&ctx->decomp_stream);
- kfree(ctx->decomp_stream.workspace);
+ vfree(ctx->decomp_stream.workspace);
}
static int deflate_init(struct crypto_tfm *tfm)
diff --git a/crypto/zlib.c b/crypto/zlib.c
index d11d761..06b62e5 100644
--- a/crypto/zlib.c
+++ b/crypto/zlib.c
@@ -29,7 +29,6 @@
#include <linux/interrupt.h>
#include <linux/mm.h>
#include <linux/net.h>
-#include <linux/slab.h>
#include <crypto/internal/compress.h>
@@ -60,7 +59,7 @@ static void zlib_decomp_exit(struct zlib_ctx *ctx)
if (stream->workspace) {
zlib_inflateEnd(stream);
- kfree(stream->workspace);
+ vfree(stream->workspace);
stream->workspace = NULL;
}
}
@@ -228,13 +227,13 @@ static int zlib_decompress_setup(struct crypto_pcomp *tfm, void *params,
? nla_get_u32(tb[ZLIB_DECOMP_WINDOWBITS])
: DEF_WBITS;
- stream->workspace = kzalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
+ stream->workspace = vzalloc(zlib_inflate_workspacesize());
if (!stream->workspace)
return -ENOMEM;
ret = zlib_inflateInit2(stream, ctx->decomp_windowBits);
if (ret != Z_OK) {
- kfree(stream->workspace);
+ vfree(stream->workspace);
stream->workspace = NULL;
return -EINVAL;
}
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 4b70311..74be989 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -49,6 +49,7 @@
#include <linux/zlib.h>
#include <linux/io.h>
#include <linux/stringify.h>
+#include <linux/vmalloc.h>
#define BNX2X_MAIN
#include "bnx2x.h"
@@ -4537,8 +4538,7 @@ static int bnx2x_gunzip_init(struct bnx2x *bp)
if (bp->strm == NULL)
goto gunzip_nomem2;
- bp->strm->workspace = kmalloc(zlib_inflate_workspacesize(),
- GFP_KERNEL);
+ bp->strm->workspace = vmalloc(zlib_inflate_workspacesize());
if (bp->strm->workspace == NULL)
goto gunzip_nomem3;
@@ -4562,7 +4562,7 @@ gunzip_nomem1:
static void bnx2x_gunzip_end(struct bnx2x *bp)
{
if (bp->strm) {
- kfree(bp->strm->workspace);
+ vfree(bp->strm->workspace);
kfree(bp->strm);
bp->strm = NULL;
}
diff --git a/drivers/net/ppp_deflate.c b/drivers/net/ppp_deflate.c
index 31e9407..1dbdf82 100644
--- a/drivers/net/ppp_deflate.c
+++ b/drivers/net/ppp_deflate.c
@@ -305,7 +305,7 @@ static void z_decomp_free(void *arg)
if (state) {
zlib_inflateEnd(&state->strm);
- kfree(state->strm.workspace);
+ vfree(state->strm.workspace);
kfree(state);
}
}
@@ -345,8 +345,7 @@ static void *z_decomp_alloc(unsigned char *options, int opt_len)
state->w_size = w_size;
state->strm.next_out = NULL;
- state->strm.workspace = kmalloc(zlib_inflate_workspacesize(),
- GFP_KERNEL|__GFP_REPEAT);
+ state->strm.workspace = vmalloc(zlib_inflate_workspacesize());
if (state->strm.workspace == NULL)
goto out_free;
^ permalink raw reply related
* Re: ppp_deflate + kmalloc
From: David Miller @ 2011-06-28 4:15 UTC (permalink / raw)
To: mjackson220.list; +Cc: carlsonj, paulus, linux-ppp, netdev
In-Reply-To: <BANLkTinMNb65nyo+Y8xhpTP2RC6x06ZJqQ@mail.gmail.com>
From: Martin Jackson <mjackson220.list@gmail.com>
Date: Sun, 26 Jun 2011 23:17:54 +0200
> Thanks for the advice. Hopefully we can indeed remove these obscure
> PPP options from our configuration - I'll look into that.
>
> However, the point still stands that a 4th order kmalloc is likely to
> fail (even our "embedded" device has 256MB RAM and slub allocator,
> after all), and the page allocation code regards anything above order
> 3 as unrealistic and doesn't invoke the OOM to try to satisfy it, so
> my view remains that this should be changed to vmalloc.
PPP is not the only place in the tree where we potentially have
this problem.
crypto/deflate.c: stream->workspace = kzalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
crypto/zlib.c: stream->workspace = kzalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
drivers/net/bnx2x/bnx2x_main.c: bp->strm->workspace = kmalloc(zlib_inflate_workspacesize(),
drivers/net/ppp_deflate.c: state->strm.workspace = kmalloc(zlib_inflate_workspacesize(),
fs/binfmt_flat.c: strm.workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
lib/zlib_inflate/infutil.c: strm->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
A particularly problematic case is binfmt_flat.c since this is used on
systems which lack an MMU, and therefore for which vmalloc() is not
applicable.
What I'll do for now is transform all of the networking cases, but
someone should think seriously about the remaining cases.
^ permalink raw reply
* Re: [PATCH] net: sh_eth: tidyup compile warning
From: David Miller @ 2011-06-28 4:03 UTC (permalink / raw)
To: kuninori.morimoto.gx; +Cc: netdev, yoshihiro.shimoda.uh
In-Reply-To: <87pqm40yx3.wl%kuninori.morimoto.gx@gmail.com>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: Thu, 23 Jun 2011 19:02:38 -0700 (PDT)
> This patch tidyup below warning
>
> ${LINUX}/drivers/net/sh_eth.c:1773: warning:
> 'mdp' may be used uninitialized in this function
>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
Applied, thanks.
^ permalink raw reply
* linux-next: manual merge of the net tree with the wireless-current tree
From: Stephen Rothwell @ 2011-06-28 4:02 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Johannes Berg, Wey-Yi Guy,
John W. Linville, Emmanuel Grumbach
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/wireless/iwlwifi/iwl-tx.c between commits 1107a08a1a3e
("iwlagn: fix cmd queue unmap"), e815407d395e ("iwlagn: map command
buffers BIDI") and 2627c002cbed ("iwlagn: use PCI_DMA_* for pci_*
operations") from the wireless-current tree and commit 795414db8607
("iwlagn: don't use the PCI wrappers for DMA operation") from the net
tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/iwlwifi/iwl-tx.c
index 9eee978,fd8aee9..0000000
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@@ -126,9 -126,8 +126,8 @@@ static inline u8 iwl_tfd_get_num_tbs(st
}
static void iwlagn_unmap_tfd(struct iwl_priv *priv, struct iwl_cmd_meta *meta,
- struct iwl_tfd *tfd)
+ struct iwl_tfd *tfd, enum dma_data_direction dma_dir)
{
- struct pci_dev *dev = priv->pci_dev;
int i;
int num_tbs;
@@@ -150,8 -149,8 +149,8 @@@
/* Unmap chunks, if any. */
for (i = 1; i < num_tbs; i++)
- pci_unmap_single(dev, iwl_tfd_tb_get_addr(tfd, i),
+ dma_unmap_single(priv->bus.dev, iwl_tfd_tb_get_addr(tfd, i),
- iwl_tfd_tb_get_len(tfd, i), DMA_TO_DEVICE);
+ iwl_tfd_tb_get_len(tfd, i), dma_dir);
}
/**
@@@ -167,8 -166,7 +166,8 @@@ void iwlagn_txq_free_tfd(struct iwl_pri
struct iwl_tfd *tfd_tmp = txq->tfds;
int index = txq->q.read_ptr;
- iwlagn_unmap_tfd(priv, &txq->meta[index], &tfd_tmp[index]);
+ iwlagn_unmap_tfd(priv, &txq->meta[index], &tfd_tmp[index],
- PCI_DMA_TODEVICE);
++ DMA_TO_DEVICE);
/* free SKB */
if (txq->txb) {
@@@ -311,8 -309,10 +310,8 @@@ void iwl_cmd_queue_unmap(struct iwl_pri
i = get_cmd_index(q, q->read_ptr);
if (txq->meta[i].flags & CMD_MAPPED) {
- dma_unmap_single(priv->bus.dev,
- dma_unmap_addr(&txq->meta[i], mapping),
- dma_unmap_len(&txq->meta[i], len),
+ iwlagn_unmap_tfd(priv, &txq->meta[i], &txq->tfds[i],
- PCI_DMA_BIDIRECTIONAL);
+ DMA_BIDIRECTIONAL);
txq->meta[i].flags = 0;
}
@@@ -693,12 -698,11 +692,12 @@@ int iwl_enqueue_hcmd(struct iwl_priv *p
continue;
if (!(cmd->dataflags[i] & IWL_HCMD_DFL_NOCOPY))
continue;
- phys_addr = pci_map_single(priv->pci_dev, (void *)cmd->data[i],
- cmd->len[i], PCI_DMA_BIDIRECTIONAL);
- if (pci_dma_mapping_error(priv->pci_dev, phys_addr)) {
+ phys_addr = dma_map_single(priv->bus.dev, (void *)cmd->data[i],
- cmd->len[i], DMA_TO_DEVICE);
++ cmd->len[i], DMA_BIDIRECTIONAL);
+ if (dma_mapping_error(priv->bus.dev, phys_addr)) {
iwlagn_unmap_tfd(priv, out_meta,
- &txq->tfds[q->write_ptr]);
+ &txq->tfds[q->write_ptr],
- PCI_DMA_BIDIRECTIONAL);
++ DMA_BIDIRECTIONAL);
idx = -ENOMEM;
goto out;
}
@@@ -802,7 -806,7 +801,7 @@@ void iwl_tx_cmd_complete(struct iwl_pri
cmd = txq->cmd[cmd_index];
meta = &txq->meta[cmd_index];
- iwlagn_unmap_tfd(priv, meta, &txq->tfds[index], PCI_DMA_BIDIRECTIONAL);
- iwlagn_unmap_tfd(priv, meta, &txq->tfds[index]);
++ iwlagn_unmap_tfd(priv, meta, &txq->tfds[index], DMA_BIDIRECTIONAL);
/* Input error checking is done when commands are added to queue. */
if (meta->flags & CMD_WANT_SKB) {
^ permalink raw reply
* [PATCH 3/9 v3] myri10ge: rework parity error check and cleanup
From: Jon Mason @ 2011-06-28 3:57 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-3-git-send-email-mason@myri.com>
Clean up watchdog reset code:
- move code that checks for stuck slice to a common routine
- unless there is a confirmed h/w fault, verify that a stuck
slice is still stuck in the watchdog worker; if the slice is no
longer stuck, abort the reset.
- this removes an egregious 2000ms pause in the watchdog worker that
was a diagnostic aid (to look for spurious resets) the snuck into
production code.
v3 includes corrections from Joe Perches
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 100 +++++++++++++++++++++++---------------
1 files changed, 60 insertions(+), 40 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 0f0f83d..ca03457 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -193,6 +193,7 @@ struct myri10ge_slice_state {
int watchdog_tx_done;
int watchdog_tx_req;
int watchdog_rx_done;
+ int stuck;
#ifdef CONFIG_MYRI10GE_DCA
int cached_dca_tag;
int cpu;
@@ -3442,6 +3443,42 @@ static u32 myri10ge_read_reboot(struct myri10ge_priv *mgp)
return reboot;
}
+static void
+myri10ge_check_slice(struct myri10ge_slice_state *ss, int *reset_needed,
+ int *busy_slice_cnt, u32 rx_pause_cnt)
+{
+ struct myri10ge_priv *mgp = ss->mgp;
+ int slice = ss - mgp->ss;
+
+ if (ss->tx.req != ss->tx.done &&
+ ss->tx.done == ss->watchdog_tx_done &&
+ ss->watchdog_tx_req != ss->watchdog_tx_done) {
+ /* nic seems like it might be stuck.. */
+ if (rx_pause_cnt != mgp->watchdog_pause) {
+ if (net_ratelimit())
+ netdev_warn(mgp->dev, "slice %d: TX paused, "
+ "check link partner\n", slice);
+ } else {
+ netdev_warn(mgp->dev,
+ "slice %d: TX stuck %d %d %d %d %d %d\n",
+ slice, ss->tx.queue_active, ss->tx.req,
+ ss->tx.done, ss->tx.pkt_start,
+ ss->tx.pkt_done,
+ (int)ntohl(mgp->ss[slice].fw_stats->
+ send_done_count));
+ *reset_needed = 1;
+ ss->stuck = 1;
+ }
+ }
+ if (ss->watchdog_tx_done != ss->tx.done ||
+ ss->watchdog_rx_done != ss->rx_done.cnt) {
+ *busy_slice_cnt += 1;
+ }
+ ss->watchdog_tx_done = ss->tx.done;
+ ss->watchdog_tx_req = ss->tx.req;
+ ss->watchdog_rx_done = ss->rx_done.cnt;
+}
+
/*
* This watchdog is used to check whether the board has suffered
* from a parity error and needs to be recovered.
@@ -3450,10 +3487,12 @@ static void myri10ge_watchdog(struct work_struct *work)
{
struct myri10ge_priv *mgp =
container_of(work, struct myri10ge_priv, watchdog_work);
- struct myri10ge_tx_buf *tx;
- u32 reboot;
+ struct myri10ge_slice_state *ss;
+ u32 reboot, rx_pause_cnt;
int status, rebooted;
int i;
+ int reset_needed = 0;
+ int busy_slice_cnt = 0;
u16 cmd, vendor;
mgp->watchdog_resets++;
@@ -3465,8 +3504,7 @@ static void myri10ge_watchdog(struct work_struct *work)
* For now, just report it */
reboot = myri10ge_read_reboot(mgp);
netdev_err(mgp->dev, "NIC rebooted (0x%x),%s resetting\n",
- reboot,
- myri10ge_reset_recover ? "" : " not");
+ reboot, myri10ge_reset_recover ? "" : " not");
if (myri10ge_reset_recover == 0)
return;
rtnl_lock();
@@ -3498,23 +3536,24 @@ static void myri10ge_watchdog(struct work_struct *work)
return;
}
}
- /* Perhaps it is a software error. Try to reset */
-
- netdev_err(mgp->dev, "device timeout, resetting\n");
+ /* Perhaps it is a software error. See if stuck slice
+ * has recovered, reset if not */
+ rx_pause_cnt = ntohl(mgp->ss[0].fw_stats->dropped_pause);
for (i = 0; i < mgp->num_slices; i++) {
- tx = &mgp->ss[i].tx;
- netdev_err(mgp->dev, "(%d): %d %d %d %d %d %d\n",
- i, tx->queue_active, tx->req,
- tx->done, tx->pkt_start, tx->pkt_done,
- (int)ntohl(mgp->ss[i].fw_stats->
- send_done_count));
- msleep(2000);
- netdev_info(mgp->dev, "(%d): %d %d %d %d %d %d\n",
- i, tx->queue_active, tx->req,
- tx->done, tx->pkt_start, tx->pkt_done,
- (int)ntohl(mgp->ss[i].fw_stats->
- send_done_count));
+ ss = mgp->ss;
+ if (ss->stuck) {
+ myri10ge_check_slice(ss, &reset_needed,
+ &busy_slice_cnt,
+ rx_pause_cnt);
+ ss->stuck = 0;
+ }
}
+ if (!reset_needed) {
+ netdev_dbg(mgp->dev, "not resetting\n");
+ return;
+ }
+
+ netdev_err(mgp->dev, "device timeout, resetting\n");
}
if (!rebooted) {
@@ -3567,27 +3606,8 @@ static void myri10ge_watchdog_timer(unsigned long arg)
myri10ge_fill_thresh)
ss->rx_big.watchdog_needed = 0;
}
-
- if (ss->tx.req != ss->tx.done &&
- ss->tx.done == ss->watchdog_tx_done &&
- ss->watchdog_tx_req != ss->watchdog_tx_done) {
- /* nic seems like it might be stuck.. */
- if (rx_pause_cnt != mgp->watchdog_pause) {
- if (net_ratelimit())
- netdev_err(mgp->dev, "slice %d: TX paused, check link partner\n",
- i);
- } else {
- netdev_warn(mgp->dev, "slice %d stuck:", i);
- reset_needed = 1;
- }
- }
- if (ss->watchdog_tx_done != ss->tx.done ||
- ss->watchdog_rx_done != ss->rx_done.cnt) {
- busy_slice_cnt++;
- }
- ss->watchdog_tx_done = ss->tx.done;
- ss->watchdog_tx_req = ss->tx.req;
- ss->watchdog_rx_done = ss->rx_done.cnt;
+ myri10ge_check_slice(ss, &reset_needed, &busy_slice_cnt,
+ rx_pause_cnt);
}
/* if we've sent or received no traffic, poll the NIC to
* ensure it is still there. Otherwise, we risk not noticing
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] vmxnet3: Convert to new vlan model.
From: David Miller @ 2011-06-28 3:57 UTC (permalink / raw)
To: jesse; +Cc: netdev, sbhatewara, pv-drivers
In-Reply-To: <1308870279-30773-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Thu, 23 Jun 2011 16:04:39 -0700
> This converts the vmxnet3 driver to use the new vlan model. In doing so
> it fixes missing tags in tcpdump and failure to do checksum offload when
> tx vlan offload is disabled.
>
> CC: Shreyas Bhatewara <sbhatewara@vmware.com>
> CC: VMware PV-Drivers <pv-drivers@vmware.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Applied, thanks.
^ permalink raw reply
* Re: what's causing "ip_rt_bug"?
From: David Miller @ 2011-06-28 3:55 UTC (permalink / raw)
To: ja; +Cc: mangoo, eric.dumazet, netdev, bazsi, hidden
In-Reply-To: <alpine.LFD.2.00.1106182036001.1425@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sat, 18 Jun 2011 20:53:59 +0300 (EEST)
> Hm, if it happens "sometimes", can it be some
> problem with tproxy and TIME_WAIT sockets? I see that
> tproxy_sk_is_transparent has special treatment for TW
> sockets while ip_route_me_harder is different. As result,
> may be input route is assigned for TW packets.
>
> May be inet_sk_flowi_flags() needs fixing, not
> sure. But following patch is first step to fix this
> problem. I don't have setup to test this patch.
TPROXY has special code to make sure that time-wait sockets
are not assigned to skb->sk, as explained in commit
d503b30bd648b3cb4e5f50b65d27e389960cc6d9, that would cause
all kinds of crashes in nfnetlink_log etc.
Therefore we would see skb->sk==NULL at ip_route_me_harder()
in that case.
> ===========================================================
>
> Avoid creating input routes with ip_route_me_harder.
> It does not work for locally generated packets. Instead,
> restrict sockets to provide valid saddr for output route (or
> unicast saddr for transparent proxy). For other traffic
> allow saddr to be unicast or local but if callers forget
> to check saddr type use 0 for the output route.
>
> The resulting handling should be:
>
> - REJECT TCP:
> - in INPUT we can provide addr_type = RTN_LOCAL but
> better allow rejecting traffic delivered with
> local route (no IP address => use RTN_UNSPEC to
> allow also RTN_UNICAST).
> - FORWARD: RTN_UNSPEC => allow RTN_LOCAL/RTN_UNICAST
> saddr, add fix to ignore RTN_BROADCAST and RTN_MULTICAST
> - OUTPUT: RTN_UNSPEC
>
> - NAT, mangle, ip_queue, nf_ip_reroute: RTN_UNSPEC in LOCAL_OUT
>
> - IPVS:
> - use RTN_LOCAL in LOCAL_OUT and FORWARD after SNAT
> to restrict saddr to be local
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Unless someone gives some negative feedback soon I'm going to
apply this.
^ permalink raw reply
* Re: [RFC][NET-NEXT PATCH 2/2] net: Add GSO to vlan_features initialization
From: Shan Wei @ 2011-06-28 3:47 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, netdev, Eric Dumazet, Michał Mirosław,
therbert@google.com
In-Reply-To: <1308934302.3034.4.camel@bwh-desktop>
Hi Ben:
Ben Hutchings wrote, at 06/25/2011 12:51 AM:
> Have you verified that GSO works correctly for VLAN devices if the
> underlying device does not support VLAN tag insertion?
OK. I will do some test in future days.
Then report test results.
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH 2/2] can: bfin_can: auto-calculate accessor sizes
From: David Miller @ 2011-06-28 3:42 UTC (permalink / raw)
To: vapier-aBrp7R+bbdUdnm+yROfE0A
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <1308925982-14645-2-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
From: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Date: Fri, 24 Jun 2011 10:33:02 -0400
> Since we have a struct that defines the sizes of the registers, we don't
> need to explicitly use the 16bit read/write helpers. Let the code figure
> out which size access to make based on the size of the C type.
>
> There should be no functional changes here.
>
> Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] can: bfin_can: simplify xmit id1 setup
From: David Miller @ 2011-06-28 3:42 UTC (permalink / raw)
To: kurt.van.dijck-/BeEPy95v10
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, vapier-aBrp7R+bbdUdnm+yROfE0A,
wg-5Yr1BZd7O62+XT7JhA+gdA,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <20110627074355.GA318-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
From: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
Date: Mon, 27 Jun 2011 09:43:55 +0200
> On Fri, Jun 24, 2011 at 10:33:01AM -0400, Mike Frysinger wrote:
>> If we look closely, the 4 writes to TRANSMIT_CHL.id1 can be collapsed
>> down into much simpler code. So do just that.
>>
>> This also fixes a build failure due to the I/O macros no longer
>> getting pulled in. Their minor (and accidental) usage here gets
>> dropped as part of the unification.
>>
>> Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
>
> Nice cleanup.
> Acked-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] ipv4: Fix IPsec slowpath fragmentation problem
From: David Miller @ 2011-06-28 3:39 UTC (permalink / raw)
To: steffen.klassert; +Cc: eric.dumazet, herbert, netdev
In-Reply-To: <20110622110537.GH6489@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 22 Jun 2011 13:05:37 +0200
> ip_append_data() builds packets based on the mtu from dst_mtu(rt->dst.path).
> On IPsec the effective mtu is lower because we need to add the protocol
> headers and trailers later when we do the IPsec transformations. So after
> the IPsec transformations the packet might be too big, which leads to a
> slowpath fragmentation then. This patch fixes this by building the packets
> based on the lower IPsec mtu from dst_mtu(&rt->dst) and adapts the exthdr
> handling to this.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] ipv4: Fix packet size calculation for IPsec packets in __ip_append_data
From: David Miller @ 2011-06-28 3:39 UTC (permalink / raw)
To: steffen.klassert; +Cc: eric.dumazet, herbert, netdev
In-Reply-To: <20110622110219.GF6489@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 22 Jun 2011 13:02:19 +0200
> In between I found the problem. In ip_setup_cork() we take the mtu on the
> base of dst_mtu(rt->dst.path) and assign it to cork->fragsize which is
> used as the mtu in __ip_append_data(). The path dst_entry is a routing
> dst_entry that does not take the IPsec header and trailer overhead into
> account. So if we build an IPsec packet based on this mtu it might be to
> big after the IPsec transformations are applied. If we take the actual
> IPsec mtu from dst_mtu(&rt->dst) and adapt the exthdr handling to this,
> it works as expected. So I'll send two patches, one that reverts Eric's
> patch and one that fixes the slowpath issue.
Thanks for doing this work Steffen.
> While reading through the code of __ip_append_data() I noticed that we
> might use ip_ufo_append_data() for packets that will be IPsec transformed
> later, is this ok? I don't know how ufo handling works, but I would guess
> that it expects an udp header and not an IPsec header as the packets
> transport header.
Indeed, it could be a real problem.
> The IPsec mtu is 1438 here, so the first packet is too big.
> xfrm4_tunnel_check_size() notices this and sends a ICMP_FRAG_NEEDED
> packet that announces a mtu of 1438 to the original sender of the ping
> packet. Unfortunately the sender is a local address, it's the IPsec
> tunnel entry point. So we update the mtu for this connection to 1438.
> Now, with the next packet xfrm_bundle_ok() notices that the path mtu has
> changed, so it subtracts the IPsec overhead from the mtu a second time
> and we end up with a mtu of 1374. This game goes until we reach a minimal
> mtu of 494.
>
> Unfortunately I don't know how to fix this. Any ideas?
If the generic PMTU handling in net/ipv4/route.c is adjusting the MTU
for the IPSEC path's route, that would be the problem.
In the case of IPSEC encapsulation, tunnels, and similar, only the
tunnel or the XFRM layer should be processing the PMTU notification.
^ permalink raw reply
* Re: [PATCH v2 1/2] ipv4: Fix packet size calculation in __ip_append_data
From: David Miller @ 2011-06-28 3:39 UTC (permalink / raw)
To: steffen.klassert; +Cc: eric.dumazet, herbert, netdev
In-Reply-To: <20110622110437.GG6489@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 22 Jun 2011 13:04:37 +0200
> Git commit 59104f06 (ip: take care of last fragment in ip_append_data)
> added a check to see if we exceed the mtu when we add trailer_len.
> However, the mtu is already subtracted by the trailer length when the
> xfrm transfomation bundles are set up. So IPsec packets with mtu
> size get fragmented, or if the DF bit is set the packets will not
> be send even though they match the mtu perfectly fine. This patch
> actually reverts commit 59104f06.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied.
^ 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