* [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
* [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
* 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
* 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: [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: 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 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: [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] [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 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: [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 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: 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]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: [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-next] hyperv: Fix some variable name typos in send-buffer init/revoke
From: David Miller @ 2014-12-22 21:11 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1419042318-7221-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Fri, 19 Dec 2014 18:25:18 -0800
> The changed names are union fields with the same size, so the existing code
> still works. But, we now update these variables to the correct names.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied.
^ permalink raw reply
* Re: virtio_net: Fix napi poll list corruption
From: David Miller @ 2014-12-22 21:10 UTC (permalink / raw)
To: herbert
Cc: david.vrabel, netdev, xen-devel, konrad.wilk, boris.ostrovsky,
edumazet
In-Reply-To: <20141220002327.GA31975@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 20 Dec 2014 11:23:27 +1100
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) breaks virtio_net in an insidious way.
>
> 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 virtio_net 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 virtio_net.
>
> The worst part of this bug is that the list corruption causes other
> napi users to be moved off-list. In my case I was chasing a stall
> in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
> was virtio_net which caused the stall even though the virtio_net
> poll was still functioning perfectly after IPsec stalled.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* OOPS: unable to handle kernel NULL pointer dereference in unix_detach_fds
From: Wolfgang Walter @ 2014-12-22 20:52 UTC (permalink / raw)
To: netdev
Hello,
today I saw this oops with kernel 3.18.1:
Dec 22 14:30:26 hobel kernel: [ 37.476849] BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
Dec 22 14:30:26 hobel kernel: [ 37.476856] IP: [<ffffffff81a7c70c>] unix_detach_fds.isra.28+0x1c/0x50
Dec 22 14:30:26 hobel kernel: [ 37.476862] PGD a90ab067 PUD a8d2c067 PMD 0
Dec 22 14:30:26 hobel kernel: [ 37.476866] Oops: 0000 [#1] PREEMPT SMP
Dec 22 14:30:26 hobel kernel: [ 37.476868] Modules linked in: bnep bluetooth rfkill vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) nfsd xt_conntrack xt_socket xt_helper nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_broadcast nf_conntrack_sip nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack uvcvideo videobuf2_vmalloc snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi nvidia(PO) i2c_piix4
Dec 22 14:30:26 hobel kernel: [ 37.476887] CPU: 4 PID: 2234 Comm: plasma-desktop Tainted: P O 3.18.1-ei+6.9 #2
Dec 22 14:30:26 hobel kernel: [ 37.476890] Hardware name: System manufacturer System Product Name/M4A89GTD-PRO/USB3, BIOS 1104 03/12/2010
Dec 22 14:30:26 hobel kernel: [ 37.476892] task: ffff88022aa2e320 ti: ffff8800aebec000 task.ti: ffff8800aebec000
Dec 22 14:30:26 hobel kernel: [ 37.476894] RIP: 0010:[<ffffffff81a7c70c>] [<ffffffff81a7c70c>] unix_detach_fds.isra.28+0x1c/0x50
Dec 22 14:30:26 hobel kernel: [ 37.476897] RSP: 0018:ffff8800aebefb68 EFLAGS: 00010202
Dec 22 14:30:26 hobel kernel: [ 37.476898] RAX: 0000000000000001 RBX: 0000000040000040 RCX: 00000000000000f0
Dec 22 14:30:26 hobel kernel: [ 37.476900] RDX: 0000000000000006 RSI: ffff880206110300 RDI: ffff8800aebefc18
Dec 22 14:30:26 hobel kernel: [ 37.476901] RBP: ffff8800aebefb78 R08: 0000000000000000 R09: ffff88022f001700
Dec 22 14:30:26 hobel kernel: [ 37.476902] R10: ffff880206110300 R11: 00000000000000f0 R12: ffff8800aebefc18
Dec 22 14:30:26 hobel kernel: [ 37.476904] R13: 0000000000000000 R14: ffff8802076a2710 R15: ffff880206110300
Dec 22 14:30:26 hobel kernel: [ 37.476906] FS: 00007f3a37991800(0000) GS:ffff880237d00000(0000) knlGS:0000000000000000
Dec 22 14:30:26 hobel kernel: [ 37.476907] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 22 14:30:26 hobel kernel: [ 37.476909] CR2: 0000000000000001 CR3: 00000000a9190000 CR4: 00000000000007e0
Dec 22 14:30:26 hobel kernel: [ 37.476910] Stack:
Dec 22 14:30:26 hobel kernel: [ 37.476911] 0000000040000040 ffff8802076a2680 ffff8800aebefc88 ffffffff81a7caec
Dec 22 14:30:26 hobel kernel: [ 37.476914] ffff8800a8d0ba01 ffff88022aa2e320 ffff8800aebefc48 ffff88022aa2e320
Dec 22 14:30:26 hobel kernel: [ 37.476916] ffff8802076a2938 000000010000000d 0000000000000000 0000000700000000
Dec 22 14:30:26 hobel kernel: [ 37.476918] Call Trace:
Dec 22 14:30:26 hobel kernel: [ 37.476922] [<ffffffff81a7caec>] unix_stream_recvmsg+0x32c/0x870
Dec 22 14:30:26 hobel kernel: [ 37.476925] [<ffffffff81a7dedb>] ? unix_stream_sendmsg+0x3fb/0x430
Dec 22 14:30:26 hobel kernel: [ 37.476928] [<ffffffff819416ae>] sock_recvmsg+0x6e/0x90
Dec 22 14:30:26 hobel kernel: [ 37.476931] [<ffffffff81201280>] ? poll_select_copy_remaining+0x130/0x130
Dec 22 14:30:26 hobel kernel: [ 37.476933] [<ffffffff81201280>] ? poll_select_copy_remaining+0x130/0x130
Dec 22 14:30:26 hobel kernel: [ 37.476936] [<ffffffff819501a2>] ? verify_iovec+0x42/0xd0
Dec 22 14:30:26 hobel kernel: [ 37.476938] [<ffffffff819427b6>] ___sys_recvmsg+0x106/0x2e0
Dec 22 14:30:26 hobel kernel: [ 37.476941] [<ffffffff81201280>] ? poll_select_copy_remaining+0x130/0x130
Dec 22 14:30:26 hobel kernel: [ 37.476943] [<ffffffff8123078b>] ? eventfd_ctx_read+0x1ab/0x220
Dec 22 14:30:26 hobel kernel: [ 37.476946] [<ffffffff81133e70>] ? wake_up_process+0x50/0x50
Dec 22 14:30:26 hobel kernel: [ 37.476949] [<ffffffff8120a704>] ? __fget+0x74/0xb0
Dec 22 14:30:26 hobel kernel: [ 37.476952] [<ffffffff8120a77f>] ? __fget_light+0x1f/0x80
Dec 22 14:30:26 hobel kernel: [ 37.476954] [<ffffffff81943e84>] __sys_recvmsg+0x44/0x80
Dec 22 14:30:26 hobel kernel: [ 37.476957] [<ffffffff81943ecd>] SyS_recvmsg+0xd/0x20
Dec 22 14:30:26 hobel kernel: [ 37.476961] [<ffffffff81b34c69>] system_call_fastpath+0x12/0x17
Dec 22 14:30:26 hobel kernel: [ 37.476962] Code: ff ff 48 8b 5d f0 4c 8b 65 f8 c9 c3 0f 1f 00 55 48 8b 46 38 48 89 e5 41 54 49 89 fc 53 48 89 07 48 c7 46 38 00 00 00 00 48 8b 07 <0f> bf 18 ff cb 79 09 eb 1b 0f 1f 00 49 8b 04 24 48 63 d3 ff cb
Dec 22 14:30:26 hobel kernel: [ 37.476983] RIP [<ffffffff81a7c70c>] unix_detach_fds.isra.28+0x1c/0x50
Dec 22 14:30:26 hobel kernel: [ 37.476985] RSP <ffff8800aebefb68>
Dec 22 14:30:26 hobel kernel: [ 37.476986] CR2: 0000000000000001
Dec 22 14:30:26 hobel kernel: [ 37.476988] ---[ end trace 05163e1048a933ce ]---
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
^ permalink raw reply
* Re: [RFC PATCH net-next] tun: support retrieving multiple packets in a single read with IFF_MULTI_READ
From: Dave Taht @ 2014-12-22 20:51 UTC (permalink / raw)
To: Alex Gartrell
Cc: Herbert Xu, jasonwang, davem@davemloft.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael S. Tsirkin, herbert, kernel-team
In-Reply-To: <54987C9F.5070103@fb.com>
On Mon, Dec 22, 2014 at 12:18 PM, Alex Gartrell <agartrell@fb.com> wrote:
> Hey Herbert,
>
> Thanks for getting back to me
>
> On 12/22/14 4:09 AM, Herbert Xu wrote:
>>
>> As tun already has a socket interface can we do this through
>> recvmmsg?
>
>
> This just presents an easier interface (IMHO) for accomplishing that. And I
> say easier because I was unable how to figure out the recvmmsg way to do it.
the recvmsg and recvmmsg calls and layers above them could use an abstraction
that allows for better passing of per packet header information to applications
in the QUIC and webrtc age.
> While fully aware that this makes me look like an idiot, I have to admit
I have lost several days of hair to *msg calls. So have the authors of
multipath mosh
(which is WAY cool, btw: https://github.com/boutier/mosh
So, no, trying and failing does not make you an idiot. Trying at all does
make you a mite crazy, however. :)
> that I've tried and failed to figure out how to get a socket fd out of the
> tun device.
>
> The regular fd doesn't work (which is obvious when you look at the
> implementation sock_from_file), there's a tun_get_socket function but it's
> only referenced by a single file, and none of the ioctl's jump out at me as
> doing anything to enable this behavior. Additionally, tuntap.txt makes no
> mention of sockets specifically.
>
> FWIW, I don't feel strongly that IFF_MULTI_READ is the right way to do this
> either.
I have been thinking about how to implement multiple ways of eliminating
serialization dependencies in userspace vpns using fair queueing, and
multithreading...
(with splitting out the seqno + address across an entire /64)
... and excess latency with multipacket reads, and then codeling
internal queues (as many vpns
bottleneck on the encap and encode step allowing for packets to
accumulate in the OS recv buffer)
See:
http://www.tinc-vpn.org/pipermail/tinc-devel/2014-December/000680.html
And especially:
https://plus.google.com/u/0/107942175615993706558/posts/QWPWLoGMtrm
and after having just suffered through making that work with recvmsg,
was dreading trying to make it work with recvmmsg.
It appears that one of the core crazy ideas (listening on an entire
/64) doesn´t work with the existing APIs, and this new interface would
help? Or recvmmsg could be generalized? Or?
--
Dave Täht
http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
^ permalink raw reply
* Re: [PATCH RESEND] stmmac: Don't init ptp again when resume from suspend/hibernation
From: David Miller @ 2014-12-22 20:42 UTC (permalink / raw)
To: chenhc; +Cc: peppe.cavallaro, srinivas.kandagatla, netdev
In-Reply-To: <1418999898-10298-1-git-send-email-chenhc@lemote.com>
From: Huacai Chen <chenhc@lemote.com>
Date: Fri, 19 Dec 2014 22:38:18 +0800
> Both stmmac_open() and stmmac_resume() call stmmac_hw_setup(), and
> stmmac_hw_setup() call stmmac_init_ptp() unconditionally. However, only
> stmmac_release() calls stmmac_release_ptp(). Since stmmac_suspend()
> doesn't call stmmac_release_ptp(), stmmac_resume() also needn't call
> stmmac_init_ptp().
>
> This patch also fix a "scheduling while atomic" problem when resume
> from suspend/hibernation. Because stmmac_init_ptp() will trigger
> scheduling while stmmac_resume() hold a spinlock.
>
> Callgraph of "scheduling while atomic":
> stmmac_resume() --> stmmac_hw_setup() --> stmmac_init_ptp() -->
> stmmac_ptp_register() --> ptp_clock_register() --> device_create() -->
> device_create_groups_vargs() --> device_add() --> devtmpfs_create_node()
> --> wait_for_common() --> schedule_timeout() --> __schedule()
>
> Signed-off-by: Huacai Chen <chenhc@lemote.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] Fixed TPACKET V3 to signal poll when block is closed rather than every packet
From: David Miller @ 2014-12-22 20:41 UTC (permalink / raw)
To: dan; +Cc: netdev, linux-kernel
In-Reply-To: <1418960965-29522-1-git-send-email-dan@dcollins.co.nz>
From: Dan Collins <dan@dcollins.co.nz>
Date: Fri, 19 Dec 2014 16:49:25 +1300
> Make TPACKET_V3 signal poll when block is closed rather than for every
> packet. Side effect is that poll will be signaled when block retire
> timer expires which didn't previously happen. Issue was visible when
> sending packets at a very low frequency such that all blocks are retired
> before packets are received by TPACKET_V3. This caused avoidable packet
> loss. The fix ensures that the signal is sent when blocks are closed
> which covers the normal path where the block is filled as well as the
> path where the timer expires. The case where a block is filled without
> moving to the next block (ie. all blocks are full) will still cause poll
> to be signaled.
>
> Signed-off-by: Dan Collins <dan@dcollins.co.nz>
Applied, thanks.
^ 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 20:18 UTC (permalink / raw)
To: Herbert Xu
Cc: jasonwang, davem, netdev, linux-kernel, mst, herbert, kernel-team
In-Reply-To: <20141222120957.GA21319@gondor.apana.org.au>
Hey Herbert,
Thanks for getting back to me
On 12/22/14 4:09 AM, Herbert Xu wrote:
> As tun already has a socket interface can we do this through
> recvmmsg?
This just presents an easier interface (IMHO) for accomplishing that.
And I say easier because I was unable how to figure out the recvmmsg way
to do it.
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.
The regular fd doesn't work (which is obvious when you look at the
implementation sock_from_file), there's a tun_get_socket function but
it's only referenced by a single file, and none of the ioctl's jump out
at me as doing anything to enable this behavior. Additionally,
tuntap.txt makes no mention of sockets specifically.
FWIW, I don't feel strongly that IFF_MULTI_READ is the right way to do
this either.
Thanks,
--
Alex Gartrell <agartrell@fb.com>
^ permalink raw reply
* Re: [PATCH for 3.19] rtlwifi: Fix error when accessing unmapped memory in skb
From: Eric Biggers @ 2014-12-22 19:48 UTC (permalink / raw)
To: Larry Finger; +Cc: kvalo, linux-wireless, netdev, Stable
In-Reply-To: <1419269826-12552-1-git-send-email-Larry.Finger@lwfinger.net>
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?
^ permalink raw reply
* Re: [RFC PATCH 01/17] fib_trie: Update usage stats to be percpu instead of global variables
From: Cong Wang @ 2014-12-22 19:21 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev
In-Reply-To: <20141222174058.1119.55120.stgit@ahduyck-vm-fedora20>
On Mon, Dec 22, 2014 at 9:40 AM, Alexander Duyck
<alexander.h.duyck@redhat.com> wrote:
> @@ -1388,7 +1388,7 @@ static int check_leaf(struct fib_table *tb, struct trie *t, struct leaf *l,
> }
>
> #ifdef CONFIG_IP_FIB_TRIE_STATS
> - t->stats.semantic_match_miss++;
> + this_cpu_ptr(t->stats->semantic_match_miss);
You mean this_cpu_inc() ?
^ permalink raw reply
* [PATCH iproute2] ip: allow ip address show to list addresses with certain flags not being set
From: Heiner Kallweit @ 2014-12-22 19:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Sometimes it's needed to have "ip address show" list only addresses
with certain flags not being set, e.g. in network scripts.
As an example one might want to exclude addresses in "tentative"
or "deprecated" state.
Support listing addresses with flags tentative, deprecated, dadfailed
not being set by prefixing the respective flag with a minus.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
ip/ipaddress.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 221ae1f..a071572 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -80,7 +80,7 @@ static void usage(void)
fprintf(stderr, "SCOPE-ID := [ host | link | global | NUMBER ]\n");
fprintf(stderr, "FLAG-LIST := [ FLAG-LIST ] FLAG\n");
fprintf(stderr, "FLAG := [ permanent | dynamic | secondary | primary |\n");
- fprintf(stderr, " tentative | deprecated | dadfailed | temporary |\n");
+ fprintf(stderr, " [-]tentative | [-]deprecated | [-]dadfailed | temporary |\n");
fprintf(stderr, " CONFFLAG-LIST ]\n");
fprintf(stderr, "CONFFLAG-LIST := [ CONFFLAG-LIST ] CONFFLAG\n");
fprintf(stderr, "CONFFLAG := [ home | nodad | mngtmpaddr | noprefixroute ]\n");
@@ -1261,9 +1261,15 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
} else if (strcmp(*argv, "tentative") == 0) {
filter.flags |= IFA_F_TENTATIVE;
filter.flagmask |= IFA_F_TENTATIVE;
+ } else if (strcmp(*argv, "-tentative") == 0) {
+ filter.flags &= ~IFA_F_TENTATIVE;
+ filter.flagmask |= IFA_F_TENTATIVE;
} else if (strcmp(*argv, "deprecated") == 0) {
filter.flags |= IFA_F_DEPRECATED;
filter.flagmask |= IFA_F_DEPRECATED;
+ } else if (strcmp(*argv, "-deprecated") == 0) {
+ filter.flags &= ~IFA_F_DEPRECATED;
+ filter.flagmask |= IFA_F_DEPRECATED;
} else if (strcmp(*argv, "home") == 0) {
filter.flags |= IFA_F_HOMEADDRESS;
filter.flagmask |= IFA_F_HOMEADDRESS;
@@ -1279,6 +1285,9 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
} else if (strcmp(*argv, "dadfailed") == 0) {
filter.flags |= IFA_F_DADFAILED;
filter.flagmask |= IFA_F_DADFAILED;
+ } else if (strcmp(*argv, "-dadfailed") == 0) {
+ filter.flags &= ~IFA_F_DADFAILED;
+ filter.flagmask |= IFA_F_DADFAILED;
} else if (strcmp(*argv, "label") == 0) {
NEXT_ARG();
filter.label = *argv;
--
2.2.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