* 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 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] 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: [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: 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: [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
* [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
* 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
* 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
* 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
* [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: [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
* 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 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 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 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 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 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 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 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 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 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] 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 v2] vmxnet3: Enable GRO support.
From: David Miller @ 2011-06-28 5:09 UTC (permalink / raw)
To: jesse; +Cc: netdev, sbhatewara, scottjg, pv-drivers
In-Reply-To: <1308961475-25055-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Fri, 24 Jun 2011 17:24:35 -0700
> When receiving packets from another guest on the same hypervisor, it's
> generally possible to receive large packets because no segmentation is
> necessary and these packets are handled by LRO. However, when doing
> routing or bridging we must disable LRO and lose this benefit. In
> these cases GRO can still be used and it is very effective because the
> packets which are segmented in the hypervisor are received very close
> together and can easily be merged.
>
> CC: Shreyas Bhatewara <sbhatewara@vmware.com>
> CC: Scott Goldman <scottjg@vmware.com>
> CC: VMware PV-Drivers <pv-drivers@vmware.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net-2.6] jme: Fix compile warning introduced by new pm macro
From: Guo-Fu Tseng @ 2011-06-28 5:12 UTC (permalink / raw)
To: David Miller; +Cc: Guo-Fu Tseng, linux-netdev, Aries Lee, Devinchiu, stable
From: Guo-Fu Tseng <cooldavid@cooldavid.org>
SIMPLE_DEV_PM_OPS is using SET_SYSTEM_SLEEP_PM_OPS
and SET_SYSTEM_SLEEP_PM_OPS is empty when CONFIG_PM_SLEEP
is not defined.
Switching #ifdef CONFIG_PM to #ifdef CONFIG_PM_SLEEP
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Cc: stable@kernel.org
---
drivers/net/jme.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/jme.c b/drivers/net/jme.c
index b5b174a..2ce9339 100644
--- a/drivers/net/jme.c
+++ b/drivers/net/jme.c
@@ -3135,7 +3135,7 @@ jme_shutdown(struct pci_dev *pdev)
pci_pme_active(pdev, true);
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int jme_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
--
1.7.3.4
^ permalink raw reply related
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