* Re: [PATCH net] in6: fix conflict with glibc
From: David Miller @ 2014-12-22 21:13 UTC (permalink / raw)
To: stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ
Cc: hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
florent.fourcot-Pj3lBMu8rt9bbU8NOSLlsg,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141220121549.7c1b8aad@urahara>
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Date: Sat, 20 Dec 2014 12:15:49 -0800
> Resolve conflicts between glibc definition of IPV6 socket options
> and those defined in Linux headers. Looks like earlier efforts to
> solve this did not cover all the definitions.
>
> It resolves warnings during iproute2 build.
> Please consider for stable as well.
>
> Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
>
> ---
> Patch against -net tree
Applied and queued up for -stable, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net]tg3: tg3_disable_ints using uninitialized mailbox value to disable interrupts
From: David Miller @ 2014-12-22 21:13 UTC (permalink / raw)
To: prashant
Cc: netdev, linux-pci, nholland, marcelo.leitner, bhelgaas,
rajatxjain, mchan
In-Reply-To: <1419106577-12891-1-git-send-email-prashant@broadcom.com>
From: Prashant Sreedharan <prashant@broadcom.com>
Date: Sat, 20 Dec 2014 12:16:17 -0800
> During driver load in tg3_init_one, if the driver detects DMA activity before
> intializing the chip tg3_halt is called. As part of tg3_halt interrupts are
> disabled using routine tg3_disable_ints. This routine was using mailbox value
> which was not initialized (default value is 0). As a result driver was writing
> 0x00000001 to pci config space register 0, which is the vendor id / device id.
>
> This driver bug was exposed because of the commit a7877b17a667 (PCI: Check only
> the Vendor ID to identify Configuration Request Retry). Also this issue is only
> seen in older generation chipsets like 5722 because config space write to offset
> 0 from driver is possible. The newer generation chips ignore writes to offset 0.
> Also without commit a7877b17a667, for these older chips when a GRC reset is
> issued the Bootcode would reprogram the vendor id/device id, which is the reason
> this bug was masked earlier.
>
> Fixed by initializing the interrupt mailbox registers before calling tg3_halt.
>
> Please queue for -stable.
>
> Reported-by: Nils Holland <nholland@tisys.org>
> Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Prashant Sreedharan <prashant@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: Stable fixes for batman-adv
From: David Miller @ 2014-12-22 21:14 UTC (permalink / raw)
To: antonio; +Cc: sven, netdev
In-Reply-To: <54969541.2060500@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Sun, 21 Dec 2014 10:39:13 +0100
> David, please merge these fixes and queue them for stable even if this
> is not the standard pull request we usually do.
Fair enough, will do.
^ permalink raw reply
* Re: [PATCH net] net/core: Handle csum for CHECKSUM_COMPLETE VXLAN forwarding
From: David Miller @ 2014-12-22 21:21 UTC (permalink / raw)
To: jay.vosburgh; +Cc: netdev
In-Reply-To: <2983.1419031920@famine>
From: Jay Vosburgh <jay.vosburgh@canonical.com>
Date: Fri, 19 Dec 2014 15:32:00 -0800
> The receive code is careful to update the skb->csum, except in
> __dev_forward_skb, as called by dev_forward_skb. __dev_forward_skb
> calls eth_type_trans, which in turn calls skb_pull_inline(skb, ETH_HLEN)
> to skip over the Ethernet header, but does not update skb->csum when
> doing so.
Hmmm, wasn't there some discussion about doing the skb_postpull_rcsum()
in eth_type_trans()?
But I guess that won't work for non-encapsulated ethernet cases?
^ permalink raw reply
* Re: [RESEND PATCH] net: s6gmac: remove driver
From: David Miller @ 2014-12-22 21:29 UTC (permalink / raw)
To: dg; +Cc: netdev, linux-kernel
In-Reply-To: <1419190059-16501-1-git-send-email-dg@emlix.com>
From: Daniel Glöckner <dg@emlix.com>
Date: Sun, 21 Dec 2014 20:27:39 +0100
> The s6000 Xtensa support has been removed from the kernel in
> 4006e565e1500db4. There are no other chips using this driver.
>
> While the Mentor/Alcatel PE-MCXMAC IP core is also used in other
> designs (Freescale Gianfar/UCC, QLogic NetXen, Solarflare, Agere
> ET-1310, Netlogic XLR/XLS), none of these use this driver as it
> heavily depends on the s6000 DMA engine. In fact, there is no
> code sharing across any of the aforementioned devices.
>
> Signed-off-by: Daniel Glöckner <dg@emlix.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 10/28] net: ethernet: stmicro: stmmac: drop owner assignment from platform_drivers
From: David Miller @ 2014-12-22 21:31 UTC (permalink / raw)
To: wsa; +Cc: linux-kernel, peppe.cavallaro, netdev
In-Reply-To: <1419196495-9626-11-git-send-email-wsa@the-dreams.de>
From: Wolfram Sang <wsa@the-dreams.de>
Date: Sun, 21 Dec 2014 22:14:31 +0100
> This platform_driver does not need to set an owner, it will be populated by the
> driver core.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] [PATCH v3 1/2] 8139too: Fix the lack of pci_disable_device
From: David Miller @ 2014-12-22 21:32 UTC (permalink / raw)
To: baijiaju1990; +Cc: sergei.shtylyov, netdev, jgarzik
In-Reply-To: <1419208132-23657-1-git-send-email-baijiaju1990@163.com>
From: Jia-Ju Bai <baijiaju1990@163.com>
Date: Mon, 22 Dec 2014 08:28:52 +0800
> For linux-3.18.0
> When pci_request_regions is failed in rtl8139_init_board, pci_disable_device
> is not called to disable the device which are enabled by pci_enable_device,
> because of disable_dev_on_err is not assigned 1.
> This patch fix this problem.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 2/2] 8139too: Add netif_napi_del in the driver
From: David Miller @ 2014-12-22 21:32 UTC (permalink / raw)
To: baijiaju1990; +Cc: sergei.shtylyov, netdev, jgarzik
In-Reply-To: <1419208994-23908-1-git-send-email-baijiaju1990@163.com>
From: Jia-Ju Bai <baijiaju1990@163.com>
Date: Mon, 22 Dec 2014 08:43:14 +0800
> For linux-3.18.0
> The driver lacks netif_napi_del in the normal path and error path
> to match the call of netif_napi_add in rtl8139_init_one.
> This patch fixes this problem.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Applied.
^ permalink raw reply
* Re: [PATCH net V1] net/mlx4_en: Doorbell is byteswapped in Little Endian archs
From: David Miller @ 2014-12-22 21:34 UTC (permalink / raw)
To: amirv; +Cc: netdev, ogerlitz, yevgenyp, weiyang, david.laight
In-Reply-To: <1419236517-15666-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Mon, 22 Dec 2014 10:21:57 +0200
> iowrite32() will byteswap it's argument on big endian archs.
> iowrite32be() will byteswap on little endian archs.
> Since we don't want to do this unnecessary byteswap on the fast path,
> doorbell is stored in the NIC's native endianness. Using the right
> iowrite() according to the arch endianness.
>
> CC: Wei Yang <weiyang@linux.vnet.ibm.com>
> CC: David Laight <david.laight@aculab.com>
> Fixes: 6a4e812 ("net/mlx4_en: Avoid calling bswap in tx fast path")
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: caif: Fix napi poll list corruption
From: David Miller @ 2014-12-22 21:35 UTC (permalink / raw)
To: herbert
Cc: jasowang, david.vrabel, netdev, xen-devel, konrad.wilk,
boris.ostrovsky, edumazet
In-Reply-To: <20141222093525.GA18616@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 22 Dec 2014 20:35:25 +1100
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks caif.
>
> It is now required that if the entire budget is consumed when poll
> returns, the napi poll_list must remain empty. However, like some
> other drivers caif tries to do a last-ditch check and if there is
> more work it will call napi_schedule and then immediately process
> some of this new work. Should the entire budget be consumed while
> processing such new work then we will violate the new caller
> contract.
>
> This patch fixes this by not touching any work when we reschedule
> in caif.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] cxgb4vf: Fix ethtool get_settings for VF driver
From: David Miller @ 2014-12-22 21:35 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan, kumaras
In-Reply-To: <1419241477-15718-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Mon, 22 Dec 2014 15:14:37 +0530
> Decode and display Port Type and Module Type for ethtool get_settings() call
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] tcp6: don't move IP6CB before xfrm6_policy_check()
From: David Miller @ 2014-12-22 21:48 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: eric.dumazet, netdev
In-Reply-To: <1419268968-4136-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 22 Dec 2014 18:22:48 +0100
> When xfrm6_policy_check() is used, _decode_session6() is called after some
> intermediate functions. This function uses IP6CB(), thus TCP_SKB_CB() must be
> prepared after the call of xfrm6_policy_check().
>
> Before this patch, scenarii with IPv6 + TCP + IPsec Transport are broken.
>
> Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
> Reported-by: Huaibin Wang <huaibin.wang@6wind.com>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied and queued up for -stable, thanks everyone.
^ permalink raw reply
* Re: [RFC PATCH 02/17] fib_trie: Make leaf and tnode more uniform
From: David Miller @ 2014-12-22 21:50 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <54986915.6050906@redhat.com>
From: Alexander Duyck <alexander.h.duyck@redhat.com>
Date: Mon, 22 Dec 2014 10:55:17 -0800
> The thing is I don't think we would actually be saving any space. The
> slub allocator will round us up anyway. On a 32b system the size is
> 28B if I recall correctly. Dropping it to 24B would mean only a 2
> child node could be allocated from the 32B slab. Anything larger than
> that it wouldn't matter.
Indeed, you even mention this in the commit messages of your
series.
> My real concern with all of this is the fact that we have to do 2
> separate memory reads per node, one for the key info and one for the
> child pointer. I really think we need to get this down to 1 in order
> to get there, but the overhead is the tricky part for that. What I
> would look at doing is splitting the tnode into two parts. One would
> be a key vector (key, pos, bits, seq) paired with a pointer to either
> a tnode_info or leaf_info, the other would be something like a
> tnode_info (rcu, parent pointer, full_children, empty_children, key
> vector array[0]) that provides a means of backtracing and stores the
> nodes. The problem is it makes insertion/deletion and backtracking
> more complicated and doubles (64b) or quadruples (32b) the memory
> needed as such I am still just throwing the idea around and haven't
> gotten into implementation yet.
I think calling into this code twice for every non-local FIB lookup
has costs as well.
And yes I agree with you that the memory references matter a lot.
^ permalink raw reply
* [PATCH 3/3] net: ieee802154: don't use devm_pinctrl_get_select_default() in probe
From: Wolfram Sang @ 2014-12-22 22:16 UTC (permalink / raw)
To: linux-kernel
Cc: linux-gpio, Wolfram Sang, Varka Bhadram, Alexander Aring,
linux-wpan, netdev
In-Reply-To: <1419286616-9893-1-git-send-email-wsa@the-dreams.de>
Since commit ab78029ecc34 (drivers/pinctrl: grab default handles from device
core), we can rely on device core for setting the default pins.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/net/ieee802154/cc2520.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
index c2b7da3da183..033473448d9f 100644
--- a/drivers/net/ieee802154/cc2520.c
+++ b/drivers/net/ieee802154/cc2520.c
@@ -19,7 +19,6 @@
#include <linux/workqueue.h>
#include <linux/interrupt.h>
#include <linux/skbuff.h>
-#include <linux/pinctrl/consumer.h>
#include <linux/of_gpio.h>
#include <linux/ieee802154.h>
@@ -841,7 +840,6 @@ done:
static int cc2520_probe(struct spi_device *spi)
{
struct cc2520_private *priv;
- struct pinctrl *pinctrl;
struct cc2520_platform_data *pdata;
int ret;
@@ -854,11 +852,6 @@ static int cc2520_probe(struct spi_device *spi)
spi_set_drvdata(spi, priv);
- pinctrl = devm_pinctrl_get_select_default(&spi->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&spi->dev,
- "pinctrl pins are not configured\n");
-
pdata = cc2520_get_platform_data(spi);
if (!pdata) {
dev_err(&spi->dev, "no platform data\n");
--
2.1.3
^ permalink raw reply related
* [PATCH iproute2 v2] ip lib: Added shorter timestamp option
From: Vadim Kochan @ 2014-12-22 22:13 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
Added another timestamp format to look like more logging info:
[2014-12-22T22:36:50.489 ] 2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
link/ether 3c:97:0e:a3:86:2e brd ff:ff:ff:ff:ff:ff
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
include/utils.h | 1 +
ip/ip.c | 5 ++++-
lib/utils.c | 15 ++++++++++++---
man/man8/ip-monitor.8 | 13 +++++++++++++
4 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/include/utils.h b/include/utils.h
index eef9c42..eecbc39 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -19,6 +19,7 @@ extern int show_raw;
extern int resolve_hosts;
extern int oneline;
extern int timestamp;
+extern int timestamp_short;
extern char * _SL_;
extern int max_flush_loops;
extern int batch_mode;
diff --git a/ip/ip.c b/ip/ip.c
index 5f759d5..9b90707 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -53,7 +53,7 @@ static void usage(void)
" -f[amily] { inet | inet6 | ipx | dnet | bridge | link } |\n"
" -4 | -6 | -I | -D | -B | -0 |\n"
" -l[oops] { maximum-addr-flush-attempts } |\n"
-" -o[neline] | -t[imestamp] | -b[atch] [filename] |\n"
+" -o[neline] | -t[imestamp] | -t[short] | -b[atch] [filename] |\n"
" -rc[vbuf] [size]}\n");
exit(-1);
}
@@ -232,6 +232,9 @@ int main(int argc, char **argv)
++oneline;
} else if (matches(opt, "-timestamp") == 0) {
++timestamp;
+ } else if (matches(opt, "-tshort") == 0) {
+ ++timestamp;
+ ++timestamp_short;
#if 0
} else if (matches(opt, "-numeric") == 0) {
rtnl_names_numeric++;
diff --git a/lib/utils.c b/lib/utils.c
index 987377b..1cf0679 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -32,6 +32,8 @@
#include "utils.h"
+int timestamp_short = 0;
+
int get_integer(int *val, const char *arg, int base)
{
long res;
@@ -773,13 +775,20 @@ int print_timestamp(FILE *fp)
{
struct timeval tv;
char *tstr;
+ char tshort[40] = {};
memset(&tv, 0, sizeof(tv));
gettimeofday(&tv, NULL);
- tstr = asctime(localtime(&tv.tv_sec));
- tstr[strlen(tstr)-1] = 0;
- fprintf(fp, "Timestamp: %s %ld usec\n", tstr, (long)tv.tv_usec);
+ if (timestamp_short) {
+ strftime(tshort, sizeof(tshort), "%Y-%m-%dT%H:%M:%S", localtime(&tv.tv_sec));
+ fprintf(fp, "[%s.%-4ld] ", tshort, (long)tv.tv_usec / 1000);
+ } else {
+ tstr = asctime(localtime(&tv.tv_sec));
+ tstr[strlen(tstr)-1] = 0;
+ fprintf(fp, "Timestamp: %s %ld usec\n", tstr, (long)tv.tv_usec);
+ }
+
return 0;
}
diff --git a/man/man8/ip-monitor.8 b/man/man8/ip-monitor.8
index 68e83f1..544b625 100644
--- a/man/man8/ip-monitor.8
+++ b/man/man8/ip-monitor.8
@@ -16,6 +16,19 @@ ip-monitor, rtmon \- state monitoring
]
.sp
+.SH OPTIONS
+
+.TP
+.BR "\-t" , " \-timestamp"
+Prints timestamp before the event message on the separated line in format:
+ Timestamp: <Day> <Month> <DD> <hh:mm:ss> <YYYY> <usecs> usec
+ <EVENT>
+
+.TP
+.BR "\-ts" , " \-tshort"
+Prints short timestamp before the event message on the same line in format:
+ [<YYYY>-<MM>-<DD>T<hh:mm:ss>.<ms>] <EVENT>
+
.SH DESCRIPTION
The
.B ip
--
2.1.3
^ permalink raw reply related
* Re: [PATCH iproute2 v2] tc: Show classes in tree view
From: Vadim Kochan @ 2014-12-22 22:19 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
In-Reply-To: <1419263518-14434-1-git-send-email-vadim4j@gmail.com>
On Mon, Dec 22, 2014 at 05:51:58PM +0200, Vadim Kochan wrote:
> From: Vadim Kochan <vadim4j@gmail.com>
>
> Added new '-t[ree]' which shows classes dependency
> in the tree view. Meanwhile only generic stats info
> is supported.
>
Seems here is one limitation with this code so that it will not pick child
classes from the leaf classfull qdisc.
^ permalink raw reply
* Re: [RFC PATCH net-next] tun: support retrieving multiple packets in a single read with IFF_MULTI_READ
From: Herbert Xu @ 2014-12-22 22:34 UTC (permalink / raw)
To: Alex Gartrell
Cc: jasonwang, davem, netdev, linux-kernel, mst, herbert, kernel-team
In-Reply-To: <54987C9F.5070103@fb.com>
On Mon, Dec 22, 2014 at 12:18:39PM -0800, Alex Gartrell wrote:
>
> While fully aware that this makes me look like an idiot, I have to
> admit that I've tried and failed to figure out how to get a socket
> fd out of the tun device.
Well right now the socket is only used within the kernel by
vhost so it's not exported to user-space. If we were to use
recvmmsg obviously we'd create a new interface based on sockets
for tun and expose the existing socket through that.
The current file-based tun interface was never designed to be
a high-performance interface. So let's take this opportunity
and create a new interface (but still using the same underlying
code since whatever you create should be easily applicable to
the existing kernel user vhost).
Cheers,
--
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 for 3.19] rtlwifi: Fix error when accessing unmapped memory in skb
From: Larry Finger @ 2014-12-22 22:41 UTC (permalink / raw)
To: Eric Biggers
Cc: kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Stable
In-Reply-To: <20141222194843.GA7575@zzz>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On 12/22/2014 01:48 PM, Eric Biggers wrote:
> Is this really the same behavior as 3.17? In 3.17, allocating the new skb is
> one of the first things the interrupt handler does, and if that fails it drops
> the packet and keeps using the old skb. In this proposal, it's only after the
> packet has been received and the old skb has been freed that a new one is
> allocated. And if that fails --- well, what are you expecting to happen
> exactly?
You are correct. In trying to get a small patch for stable, I missed some
important points.
Please look at the attached patch. I think it handles the skb allocations
correctly. The critical point is that _rtl_pci_init_one_rxdesc() cannot be
allowed to fail to allocate an skb while in the interrupt path. Now, I have
already allocated the skb before the call and bypassed this routine if the
allocation fails. After a couple of crashes, this one now works for the case
when the allocation wouldn't fail anyway. I will likely pull the allocation out
of _rtl_pci_init_one_rxdesc() in all cases for the final patch.
@Kalle: Please drop the patch I submitted this morning with this subject. It
would not help the problem. I will resubmit after I am sure of the proper fix.
Thanks,
Larry
[-- Attachment #2: fix_skb_alloc_v2 --]
[-- Type: text/plain, Size: 3218 bytes --]
Index: wireless-drivers/drivers/net/wireless/rtlwifi/pci.c
===================================================================
--- wireless-drivers.orig/drivers/net/wireless/rtlwifi/pci.c
+++ wireless-drivers/drivers/net/wireless/rtlwifi/pci.c
@@ -666,6 +666,7 @@ tx_status_ok:
}
static int _rtl_pci_init_one_rxdesc(struct ieee80211_hw *hw,
+ struct sk_buff *new_skb,
u8 *entry, int rxring_idx, int desc_idx)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
@@ -674,7 +675,10 @@ static int _rtl_pci_init_one_rxdesc(stru
u8 tmp_one = 1;
struct sk_buff *skb;
- skb = dev_alloc_skb(rtlpci->rxbuffersize);
+ if (new_skb)
+ skb = new_skb;
+ else
+ skb = dev_alloc_skb(rtlpci->rxbuffersize);
if (!skb)
return 0;
rtlpci->rx_ring[rxring_idx].rx_buf[desc_idx] = skb;
@@ -772,6 +776,7 @@ static void _rtl_pci_rx_interrupt(struct
/*RX NORMAL PKT */
while (count--) {
struct ieee80211_hdr *hdr;
+ struct sk_buff *new_skb = NULL;
__le16 fc;
u16 len;
/*rx buffer descriptor */
@@ -800,6 +805,12 @@ static void _rtl_pci_rx_interrupt(struct
return;
}
+ new_skb = dev_alloc_skb(rtlpci->rxbuffersize);
+ if (unlikely(!new_skb)) {
+ RT_TRACE(rtlpriv, (COMP_INTR | COMP_RECV), DBG_DMESG,
+ "can't alloc skb for rx\n");
+ goto end;
+ }
/* Reaching this point means: data is filled already
* AAAAAAttention !!!
* We can NOT access 'skb' before 'pci_unmap_single'
@@ -845,6 +856,7 @@ static void _rtl_pci_rx_interrupt(struct
if (rtlpriv->cfg->ops->rx_command_packet &&
rtlpriv->cfg->ops->rx_command_packet(hw, stats, skb)) {
dev_kfree_skb_any(skb);
+ skb = new_skb;
goto end;
}
@@ -895,6 +907,7 @@ static void _rtl_pci_rx_interrupt(struct
} else {
dev_kfree_skb_any(skb);
}
+ skb = new_skb;
if (rtlpriv->use_new_trx_flow) {
rtlpci->rx_ring[hw_queue].next_rx_rp += 1;
rtlpci->rx_ring[hw_queue].next_rx_rp %=
@@ -912,12 +925,13 @@ static void _rtl_pci_rx_interrupt(struct
}
end:
if (rtlpriv->use_new_trx_flow) {
- if (!_rtl_pci_init_one_rxdesc(hw, (u8 *)buffer_desc,
- rxring_idx,
- rtlpci->rx_ring[rxring_idx].idx))
+ /* TODO: Can the following fail? */
+ if (!_rtl_pci_init_one_rxdesc(hw, skb,
+ (u8 *)buffer_desc, rxring_idx,
+ rtlpci->rx_ring[rxring_idx].idx))
return;
} else {
- if (!_rtl_pci_init_one_rxdesc(hw, (u8 *)pdesc,
+ if (!_rtl_pci_init_one_rxdesc(hw, skb, (u8 *)pdesc,
rxring_idx,
rtlpci->rx_ring[rxring_idx].idx))
return;
@@ -1309,7 +1323,7 @@ static int _rtl_pci_init_rx_ring(struct
rtlpci->rx_ring[rxring_idx].idx = 0;
for (i = 0; i < rtlpci->rxringcount; i++) {
entry = &rtlpci->rx_ring[rxring_idx].buffer_desc[i];
- if (!_rtl_pci_init_one_rxdesc(hw, (u8 *)entry,
+ if (!_rtl_pci_init_one_rxdesc(hw, NULL, (u8 *)entry,
rxring_idx, i))
return -ENOMEM;
}
@@ -1334,7 +1348,7 @@ static int _rtl_pci_init_rx_ring(struct
for (i = 0; i < rtlpci->rxringcount; i++) {
entry = &rtlpci->rx_ring[rxring_idx].desc[i];
- if (!_rtl_pci_init_one_rxdesc(hw, (u8 *)entry,
+ if (!_rtl_pci_init_one_rxdesc(hw, NULL, (u8 *)entry,
rxring_idx, i))
return -ENOMEM;
}
^ permalink raw reply
* Re: REGRESSION in nfnetlink on 3.18.x (bisected)
From: Andre Tomt @ 2014-12-22 23:23 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, netdev
In-Reply-To: <20141222115607.GA4961@salvia>
On 22. des. 2014 12:56, Pablo Neira Ayuso wrote:
> On Sun, Dec 21, 2014 at 12:33:51AM +0100, Andre Tomt wrote:
>> On at least Ubuntu 14.04 LTS and Ubuntu 14.10 "conntrack -E" has
>> started failing with Linux 3.18.x. conntrack -L still works.
>>
>> 14.04 and 14.10 ships conntrack-utils version 1.4.1, but 1.4.2 does
>> not work either.
>>
>> It fails with:
>>> # conntrack -E
>>> conntrack v1.4.2 (conntrack-tools): Can't open handler
>>
>> strace shows:
>>> bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
>>> getsockname(3, {sa_family=AF_NETLINK, pid=14092, groups=00000000}, [12]) = 0
>>> bind(3, {sa_family=AF_NETLINK, pid=14092, groups=00000007}, 12) = -1 EINVAL (Invalid argument)
>>
>> Reverting 97840cb67ff5ac8add836684f011fd838518d698 - netfilter:
>> nfnetlink: fix insufficient validation in nfnetlink_bind
>
> Could you give a test to this patch? Thanks.
>
Initial testing looks good with this patch applied on top of 3.18.1
I will give it a spin on some more systems tomorrow.
Thanks
^ permalink raw reply
* Re: [PATCH for 3.19] rtlwifi: Fix error when accessing unmapped memory in skb
From: Eric Biggers @ 2014-12-22 23:33 UTC (permalink / raw)
To: Larry Finger; +Cc: kvalo, linux-wireless, netdev, Stable
In-Reply-To: <54989E12.6050808@lwfinger.net>
On Mon, Dec 22, 2014 at 04:41:22PM -0600, Larry Finger wrote:
> Please look at the attached patch. I think it handles the skb allocations
> correctly. The critical point is that _rtl_pci_init_one_rxdesc() cannot be
> allowed to fail to allocate an skb while in the interrupt path. Now, I have
> already allocated the skb before the call and bypassed this routine if the
> allocation fails. After a couple of crashes, this one now works for the case
> when the allocation wouldn't fail anyway. I will likely pull the allocation
> out of _rtl_pci_init_one_rxdesc() in all cases for the final patch.
Well, it's looking better. But what seems strange to me is that
_rtl_pci_init_one_rxdesc() will map the skb for DMA, even though in the error
path it was never unmapped from the previous use. The 3.17 version will neither
unmap nor map the skb in the error path.
I also suspect that trying to share _rtl_pci_init_one_rxdesc() between the
driver initialization and the interrupt handler is just confusing matters.
Perhaps only the ->set_desc() calls should be shared?
In any case, I assume it would be a good idea to, for testing, inject some
random skb allocation failures and make sure the driver still works smoothly
except for some dropped packets.
^ permalink raw reply
* Re: [RFC PATCH 02/17] fib_trie: Make leaf and tnode more uniform
From: Alexander Duyck @ 2014-12-22 23:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141222.165015.1694288362513627826.davem@davemloft.net>
On 12/22/2014 01:50 PM, David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@redhat.com>
> Date: Mon, 22 Dec 2014 10:55:17 -0800
>
>> My real concern with all of this is the fact that we have to do 2
>> separate memory reads per node, one for the key info and one for the
>> child pointer. I really think we need to get this down to 1 in order
>> to get there, but the overhead is the tricky part for that. What I
>> would look at doing is splitting the tnode into two parts. One would
>> be a key vector (key, pos, bits, seq) paired with a pointer to either
>> a tnode_info or leaf_info, the other would be something like a
>> tnode_info (rcu, parent pointer, full_children, empty_children, key
>> vector array[0]) that provides a means of backtracing and stores the
>> nodes. The problem is it makes insertion/deletion and backtracking
>> more complicated and doubles (64b) or quadruples (32b) the memory
>> needed as such I am still just throwing the idea around and haven't
>> gotten into implementation yet.
> I think calling into this code twice for every non-local FIB lookup
> has costs as well.
Agreed. I remember when you sent me the patch to test out merging the
two tries a few years back that did make a significant difference.
By my math the difference with these patches is probably around 26ns
extra, 113ns vs 87ns, to do the second table lookup. The changes in
adding/checking the suffix length and the fact that we validate the key
is usable as a prefix before reading the leaf_info made the first table
lookup much cheaper than it was before so merging the tables should
provide less of a gain.
What it will come down to is if the cost to backtrack however many bits
it takes to get to the route is greater than the cost to start the
search over in the main trie. In the case of subnets with a short
prefix you may end up finding that the cost to backtrack will be more
expensive for addresses at the end of the address range with a large
number of bits set in the host identifier.
> And yes I agree with you that the memory references matter a lot.
Especially now. Considering the loop for lookup is fairly small the
only thing that is really holding it back is the memory access latency.
That is why I am playing around with the idea of doubling the memory
footprint for the trie just to make it so that the key and the pointer
could co-exist in the same 16B region. I'm hoping it would allow us to
cut total memory access latency in half and double the speed at which we
could process tnodes.
Thanks for the feedback.
- Alex
^ permalink raw reply
* Re: [RFC PATCH net-next] tun: support retrieving multiple packets in a single read with IFF_MULTI_READ
From: Alex Gartrell @ 2014-12-22 23:39 UTC (permalink / raw)
To: Herbert Xu
Cc: jasonwang, davem, netdev, linux-kernel, mst, herbert, kernel-team
In-Reply-To: <20141222223436.GA25970@gondor.apana.org.au>
Hey Herbert,
On 12/22/2014 02:34 PM, Herbert Xu wrote:
> On Mon, Dec 22, 2014 at 12:18:39PM -0800, Alex Gartrell wrote:
>>
>> While fully aware that this makes me look like an idiot, I have to
>> admit that I've tried and failed to figure out how to get a socket
>> fd out of the tun device.
>
> Well right now the socket is only used within the kernel by
> vhost so it's not exported to user-space. If we were to use
> recvmmsg obviously we'd create a new interface based on sockets
> for tun and expose the existing socket through that.
Ah, that explains it then. I was afraid I was just going insane :)
> The current file-based tun interface was never designed to be
> a high-performance interface. So let's take this opportunity
> and create a new interface (but still using the same underlying
> code since whatever you create should be easily applicable to
> the existing kernel user vhost).
Sounds good to me. I'll get a patch turned around soon.
Thanks,
--
Alex Gartrell <agartrell@fb.com>
^ permalink raw reply
* [PATCH net] net: Reset secmark when scrubbing packet
From: Thomas Graf @ 2014-12-23 0:13 UTC (permalink / raw)
To: davem; +Cc: netdev
skb_scrub_packet() is called when a packet switches between a context
such as between underlay and overlay, between namespaces, or between
L3 subnets.
While we already scrub the packet mark, connection tracking entry,
and cached destination, the security mark/context is left intact.
It seems wrong to inherit the security context of a packet when going
from overlay to underlay or across forwarding paths.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
net/core/skbuff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index ae13ef6..395c15b 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4148,6 +4148,7 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet)
skb->ignore_df = 0;
skb_dst_drop(skb);
skb->mark = 0;
+ skb_init_secmark(skb);
secpath_reset(skb);
nf_reset(skb);
nf_reset_trace(skb);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 3/3] net: ieee802154: don't use devm_pinctrl_get_select_default() in probe
From: Varka Bhadram @ 2014-12-23 0:28 UTC (permalink / raw)
Cc: linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-wpan - ML, netdev@vger.kernel.org
In-Reply-To: <CAEUmHyYbPbeWzHEaPYFAV+wTGYqhz7pps6XEzNrK_jQm_HPKpg@mail.gmail.com>
Thanks for the patch.
Acked-by: Varka Bhadram <varkabhadram@gmail.com>
On Tue, Dec 23, 2014 at 5:40 AM, Varka Bhadram <varkabhadram@gmail.com> wrote:
>
> Thanks for the patch.
>
> Acked-by: Varka Bhadram <varkabhadram@gmail.com>
>
> On Tue, Dec 23, 2014 at 3:46 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
>>
>> Since commit ab78029ecc34 (drivers/pinctrl: grab default handles from device
>> core), we can rely on device core for setting the default pins.
>>
>> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
>> ---
>> drivers/net/ieee802154/cc2520.c | 7 -------
>> 1 file changed, 7 deletions(-)
>>
>> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
>> index c2b7da3da183..033473448d9f 100644
>> --- a/drivers/net/ieee802154/cc2520.c
>> +++ b/drivers/net/ieee802154/cc2520.c
>> @@ -19,7 +19,6 @@
>> #include <linux/workqueue.h>
>> #include <linux/interrupt.h>
>> #include <linux/skbuff.h>
>> -#include <linux/pinctrl/consumer.h>
>> #include <linux/of_gpio.h>
>> #include <linux/ieee802154.h>
>>
>> @@ -841,7 +840,6 @@ done:
>> static int cc2520_probe(struct spi_device *spi)
>> {
>> struct cc2520_private *priv;
>> - struct pinctrl *pinctrl;
>> struct cc2520_platform_data *pdata;
>> int ret;
>>
>> @@ -854,11 +852,6 @@ static int cc2520_probe(struct spi_device *spi)
>>
>> spi_set_drvdata(spi, priv);
>>
>> - pinctrl = devm_pinctrl_get_select_default(&spi->dev);
>> - if (IS_ERR(pinctrl))
>> - dev_warn(&spi->dev,
>> - "pinctrl pins are not configured\n");
>> -
>> pdata = cc2520_get_platform_data(spi);
>> if (!pdata) {
>> dev_err(&spi->dev, "no platform data\n");
>> --
>> 2.1.3
>>
>
>
>
> --
> Thanks and Regards,
> Varka Bhadram.
--
Thanks and Regards,
Varka Bhadram.
^ permalink raw reply
* [PATCH] bonding: change error message to debug message in __bond_release_one()
From: Wengang Wang @ 2014-12-23 1:24 UTC (permalink / raw)
To: netdev, gospo, dingtianhong; +Cc: wen.gang.wang
In __bond_release_one(), when the interface is not a slave or not a slave of
"this" master, it log error message.
The message actually should be a debug message matching what bond_enslave()
does.
Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
---
drivers/net/bonding/bond_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 184c434..0dceba1 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1648,7 +1648,7 @@ static int __bond_release_one(struct net_device *bond_dev,
/* slave is not a slave or master is not master of this slave */
if (!(slave_dev->flags & IFF_SLAVE) ||
!netdev_has_upper_dev(slave_dev, bond_dev)) {
- netdev_err(bond_dev, "cannot release %s\n",
+ netdev_dbg(bond_dev, "cannot release %s\n",
slave_dev->name);
return -EINVAL;
}
--
1.8.3.1
^ 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