* Macvlan WARNiNGS about duplicate sysfs filenames (Was [GIT] Networking)
From: Andres Freund, Alexander Y. Fomichev @ 2014-09-08 21:25 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20140907.164109.1944849896872238507.davem@davemloft.net>
Hi,
(don't have netdev archived, thus answering here, sorry)
On 2014-09-07 16:41:09 -0700, David Miller wrote:
> Alexander Y. Fomichev (1):
> net: prevent of emerging cross-namespace symlinks
I'm seeing WARNINGs like:
[ 1005.269134] ------------[ cut here ]------------
[ 1005.269148] WARNING: CPU: 6 PID: 4213 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x80()
[ 1005.269150] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/net/eth0/upper_mv-eth0'
[ 1005.269152] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT iptable_filter ip_tables snd_hda_code
c_ca0110 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm acpi
_cpufreq w83793 jc42 e1000e ptp pps_core
[ 1005.269175] CPU: 6 PID: 4213 Comm: systemd-nspawn Tainted: G W I 3.17.0-rc4-andres-00135-g35af256 #216
[ 1005.269178] Hardware name: empty empty/S7020, BIOS 'V1.03 ' 03/09/2010
[ 1005.269180] 0000000000000009 ffff8803300b3738 ffffffff81cc0ca2 ffff8803300b3780
[ 1005.269183] ffff8803300b3770 ffffffff8111434d ffff88062ce1a000 ffff8803300b3851
[ 1005.269186] ffff88032e5d4c30 ffff88032e5d4c30 ffffffffffffffef ffff8803300b37d0
[ 1005.269190] Call Trace:
[ 1005.269198] [<ffffffff81cc0ca2>] dump_stack+0x45/0x56
[ 1005.269203] [<ffffffff8111434d>] warn_slowpath_common+0x7d/0xa0
[ 1005.269206] [<ffffffff811143bc>] warn_slowpath_fmt+0x4c/0x50
[ 1005.269209] [<ffffffff812c5dc8>] ? kernfs_path+0x48/0x60
[ 1005.269213] [<ffffffff812c9464>] sysfs_warn_dup+0x64/0x80
[ 1005.269216] [<ffffffff812c97be>] sysfs_do_create_link_sd.isra.2+0x9e/0xb0
[ 1005.269219] [<ffffffff812c97f5>] sysfs_create_link+0x25/0x50
[ 1005.269227] [<ffffffff81b73238>] netdev_adjacent_sysfs_add+0x58/0x70
[ 1005.269232] [<ffffffff81b75ebd>] __netdev_adjacent_dev_insert+0x15d/0x1b0
[ 1005.269236] [<ffffffff81b75f41>] __netdev_adjacent_dev_link_lists+0x31/0x80
[ 1005.269240] [<ffffffff81b760e6>] __netdev_upper_dev_link+0x156/0x480
[ 1005.269245] [<ffffffff81b70cb5>] ? call_netdevice_notifiers_info+0x35/0x60
[ 1005.269250] [<ffffffff81b76422>] netdev_upper_dev_link+0x12/0x20
[ 1005.269257] [<ffffffff819b7822>] macvlan_common_newlink+0x182/0x3f0
[ 1005.269261] [<ffffffff819b7a9e>] macvlan_newlink+0xe/0x10
[ 1005.269267] [<ffffffff81b87cf4>] rtnl_newlink+0x6d4/0x790
[ 1005.269270] [<ffffffff81b8779f>] ? rtnl_newlink+0x17f/0x790
[ 1005.269278] [<ffffffff81b86722>] rtnetlink_rcv_msg+0x92/0x260
[ 1005.269284] [<ffffffff81247e71>] ? __kmalloc_node_track_caller+0x181/0x210
[ 1005.269294] [<ffffffff8160e556>] ? rhashtable_lookup_compare+0x36/0x70
[ 1005.269299] [<ffffffff81b86690>] ? rtnetlink_rcv+0x30/0x30
[ 1005.269307] [<ffffffff81ba5679>] netlink_rcv_skb+0xa9/0xd0
[ 1005.269312] [<ffffffff81b86688>] rtnetlink_rcv+0x28/0x30
[ 1005.269316] [<ffffffff81ba4bda>] netlink_unicast+0x10a/0x1a0
[ 1005.269321] [<ffffffff81ba508c>] netlink_sendmsg+0x34c/0x780
[ 1005.269328] [<ffffffff811fc2c6>] ? free_hot_cold_page_list+0x46/0xa0
[ 1005.269334] [<ffffffff81b5bb03>] sock_sendmsg+0x73/0x90
[ 1005.269343] [<ffffffff812228c3>] ? unmap_region+0xd3/0x110
[ 1005.269350] [<ffffffff81271703>] ? __fdget+0x13/0x20
[ 1005.269355] [<ffffffff81b5d381>] ? move_addr_to_kernel+0x31/0x90
[ 1005.269360] [<ffffffff81b5dd23>] SyS_sendto+0x113/0x150
[ 1005.269366] [<ffffffff81607eab>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[ 1005.269374] [<ffffffff81cceb56>] system_call_fastpath+0x1a/0x1f
[ 1005.269377] ---[ end trace 00724f5b901e5d10 ]---
which are quite justified:
# readlink -f /sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/net/eth0/upper_mv-eth0
/sys/devices/virtual/net/mv-eth0
# ls -l /sys/devices/virtual/net/mv-eth0
ls: cannot access /sys/devices/virtual/net/mv-eth0: No such file or directory
That happened after bringing up mv-eth0 up once, then down, and then up
again. There apparently is a dangling symlink somewhere. I'd done this
via:
systemd-nspawn -b -j -D /home/andres/chroot/sid-amd64 --private-network --network-macvlan=eth0
I haven't used macvlan before, so it's not impossible that the bug has
existed for longer. It's also possible that this bug isn't the fault of
this patch. I think both aren't terribly likely though.
Greetings,
Andres Freund
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: remove dst refcount false sharing for prequeue mode
From: Eric Dumazet @ 2014-09-08 21:30 UTC (permalink / raw)
To: David Miller; +Cc: therbert, alexander.h.duyck, netdev
In-Reply-To: <20140908.142143.807176983873922125.davem@davemloft.net>
On Mon, 2014-09-08 at 14:21 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 08 Sep 2014 08:06:07 -0700
>
> > @@ -1559,7 +1559,17 @@ bool tcp_prequeue(struct sock *sk, struct sk_buff *skb)
> > skb_queue_len(&tp->ucopy.prequeue) == 0)
> > return false;
> >
> > - skb_dst_force(skb);
> > + /* Before escaping RCU protected region, we need to take care of skb
> > + * dst. Prequeue is only enabled for established sockets.
> > + * For such sockets, we might need the skb dst only to set sk->sk_rx_dst
> > + * Instead of doing full sk_rx_dst validity here, let's perform
> > + * an optimistic check.
> > + */
> > + if (likely(sk->sk_rx_dst))
> > + skb_dst_drop(skb);
> > + else
> > + skb_dst_force(skb);
> > +
>
> This might not be a strong enough test.
>
> We have to also make all of the checks that would cause the input
> path to invalidate sk->sk_rx_dst too.
>
> Otherwise, if it does, we'll crash when we try to do a dst_hold()
> on skb_dst(skb) in sk->sk_rx_dst_set().
I thought I gave enough details in this comment and changelog. Maybe I
had been too verbose :(
In the worst case, here is what is happening :
sk_rx_dst is checked and invalidated in tcp_v4_do_rcv()
Next packets coming from prequeue might then have a NULL dst, and
we'll do nothing special (sk_rx_dst will stay NULL), because we do
handle NULL dst properly in inet_sk_rx_dst_set() and
inet6_sk_rx_dst_set()
But next packet to be processed (either in non prequeue mode or
prequeue) will carry skb->dst and we will set sk->sk_rx_dst
I decided to not copy/paste the tests we do in the family dependent
parts, because it was not worth the pain.
^ permalink raw reply
* [PATCH next] net_sched: sfq: remove unused macro
From: Florian Westphal @ 2014-09-08 21:33 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
not used anymore since ddecf0f
(net_sched: sfq: add optional RED on top of SFQ).
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/sched/sch_sfq.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 1af2f73..211db90 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -310,11 +310,6 @@ static inline void slot_queue_add(struct sfq_slot *slot, struct sk_buff *skb)
slot->skblist_prev = skb;
}
-#define slot_queue_walk(slot, skb) \
- for (skb = slot->skblist_next; \
- skb != (struct sk_buff *)slot; \
- skb = skb->next)
-
static unsigned int sfq_drop(struct Qdisc *sch)
{
struct sfq_sched_data *q = qdisc_priv(sch);
--
1.8.1.5
^ permalink raw reply related
* [PATCH 1/1] net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr struct from userland.
From: Ani Sinha @ 2014-09-08 21:49 UTC (permalink / raw)
To: ani, fruggeri, davem, netdev, fenner, travisb, hannes,
matthew.leach, eric.dumazet
Linux manpage for recvmsg and sendmsg calls does not explicitly mention setting msg_namelen to 0 when
msg_name passed set as NULL. When developers don't set msg_namelen member in msghdr, it might contain garbage
value which will fail the validation check and sendmsg and recvmsg calls from kernel will return EINVAL. This will
break old binaries and any code for which there is no access to source code.
To fix this, we set msg_namelen to 0 when msg_name is passed as NULL from userland.
Signed-off-by: Ani Sinha <ani@arista.com>
---
net/socket.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 95ee7d8..457be6a 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1997,6 +1997,9 @@ static int copy_msghdr_from_user(struct msghdr *kmsg,
if (copy_from_user(kmsg, umsg, sizeof(struct msghdr)))
return -EFAULT;
+ if (kmsg->msg_name == NULL)
+ kmsg->msg_namelen = 0;
+
if (kmsg->msg_namelen < 0)
return -EINVAL;
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] net: socket: do not validate msg_namelen unless msg_name is non-NULL
From: Ani Sinha @ 2014-09-08 21:53 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: David Miller, matthew.leach, netdev, fenner, fruggeri, travisb
In-Reply-To: <CAOxq_8Nvox3ABUoZFzmvMyb4XwAHx1YdTPfx9rpKAofM7crq=w@mail.gmail.com>
I just resent this patch again with git send-email so that it can be
directly applied without any whitespace damage.
Subject: [PATCH 1/1] net:socket: set msg_namelen to 0 if msg_name is
passed as NULL in msghdr struct from userland.
thanks,
ani
On Fri, Sep 5, 2014 at 2:44 PM, Ani Sinha <ani@arista.com> wrote:
> On Fri, Sep 5, 2014 at 2:26 PM, Hannes Frederic Sowa
>> If you set msg_namelen = 0 if msg_name == NULL prior to the < 0 check it
>> should not trigger the return -EINVAL and also we don't run into the
>> unsafe implicit conversion case when comparing msg_namelen with the
>> result of the sizeof(). Do you see any problems with that?
>
> yes, sorry I misunderstood you. Here's the updated patch :
>
> From ea39174d4475d7def61410210613ab24a4ce0e81 Mon Sep 17 00:00:00 2001
> From: Ani Sinha <ani@aristanetworks.com>
> Date: Fri, 5 Sep 2014 14:33:20 -0700
> Subject: [PATCH] net:socket: set msg_namelen to 0 if msg_name is
> passed as NULL in msghdr struct from userland.
>
> Linux manpage for recvmsg and sendmsg calls does not explicitly
> mention setting msg_namelen to 0 when
> msg_name passed set as NULL. When developers don't set msg_namelen
> member in msghdr, it might contain garbage
> value which will fail the validation check and sendmsg and recvmsg
> calls from kernel will return EINVAL. This will
> break old binaries and any code for which there is no access to source code.
> To fix this, we set msg_namelen to 0 when msg_name is passed as NULL
> from userland.
>
> Signed-off-by: Ani Sinha <ani@aristanetworks.com>
> ---
> net/socket.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/socket.c b/net/socket.c
> index 95ee7d8..457be6a 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -1997,6 +1997,9 @@ static int copy_msghdr_from_user(struct msghdr *kmsg,
> if (copy_from_user(kmsg, umsg, sizeof(struct msghdr)))
> return -EFAULT;
>
> + if (kmsg->msg_name == NULL)
> + kmsg->msg_namelen = 0;
> +
> if (kmsg->msg_namelen < 0)
> return -EINVAL;
>
> --
> 1.7.4.4
^ permalink raw reply
* Re: [PATCH next] net_sched: sfq: remove unused macro
From: Eric Dumazet @ 2014-09-08 21:59 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <1410211981-31081-1-git-send-email-fw@strlen.de>
On Mon, 2014-09-08 at 23:33 +0200, Florian Westphal wrote:
> not used anymore since ddecf0f
> (net_sched: sfq: add optional RED on top of SFQ).
SGTM ;)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH][net-next] openvswitch: change the data type of error status to atomic_long_t
From: Cong Wang @ 2014-09-08 22:21 UTC (permalink / raw)
To: Li RongQing; +Cc: Pravin Shelar, netdev
In-Reply-To: <CAJFZqHwK=5iXxBP+SgcLtub=HSkTt9Pd6LU2_Tjn9qTxbQd3SA@mail.gmail.com>
On Sun, Sep 7, 2014 at 2:24 AM, Li RongQing <roy.qing.li@gmail.com> wrote:
> On Sun, Sep 7, 2014 at 11:44 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>>> The operation of atomic maybe faster than spin lock.
>>
>> What is reason for this change?
>
> 1. The operation of atomic maybe faster than spin lock
> 2. I did not find that tx_dropped/tx_error/.. is protected by spin
> lock under net dir,
> sometime tx_dropped is atomic_long_t; sometime it is percpu variable;
> sometime it is
> u64,but does not need to protect.
I didn't dig the history of the code, why not use u64_stats_sync though?
^ permalink raw reply
* Re: [PATCH] net: Fix GRE RX to use skb_transport_header for GRE header offset
From: David Miller @ 2014-09-08 22:23 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <1410190152-7396-1-git-send-email-therbert@google.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 8 Sep 2014 08:29:12 -0700
> GRE assumes that the GRE header is at skb_network_header +
> ip_hrdlen(skb). It is more general to use skb_transport_header
> and this allows the possbility of inserting additional header
> between IP and GRE (which is what we will done in Generic UDP
> Encapsulation for GRE).
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH][net-next] openvswitch: change the data type of error status to atomic_long_t
From: Pravin Shelar @ 2014-09-08 22:26 UTC (permalink / raw)
To: Li RongQing; +Cc: netdev
In-Reply-To: <CAJFZqHwK=5iXxBP+SgcLtub=HSkTt9Pd6LU2_Tjn9qTxbQd3SA@mail.gmail.com>
On Sun, Sep 7, 2014 at 2:24 AM, Li RongQing <roy.qing.li@gmail.com> wrote:
> On Sun, Sep 7, 2014 at 11:44 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>>> The operation of atomic maybe faster than spin lock.
>>
>> What is reason for this change?
>
> 1. The operation of atomic maybe faster than spin lock
> 2. I did not find that tx_dropped/tx_error/.. is protected by spin
> lock under net dir,
> sometime tx_dropped is atomic_long_t; sometime it is percpu variable;
> sometime it is
> u64,but does not need to protect.
>
These are error counter and the access is not performance sensitive
code. So I do not see obvious need to optimize it. Do you have any
performance number for this patch?
^ permalink raw reply
* Re: [PATCH net-next] hp100: Convert the normal skb free path to dev_consume_skb_any()
From: David Miller @ 2014-09-08 22:40 UTC (permalink / raw)
To: raj; +Cc: netdev, perex
In-Reply-To: <20140908153133.103882900309@tardy>
From: raj@tardy.usa.hp.com (Rick Jones)
Date: Mon, 8 Sep 2014 08:31:32 -0700 (PDT)
> From: Rick Jones <rick.jones2@hp.com>
>
> A bit of floor sweeping in a dusty old corner. Convert the "normal"
> skb free calls to dev_consume_skb_any() so packet drop tracing will
> be more sane.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
Applied, thanks Rick.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: remove dst refcount false sharing for prequeue mode
From: David Miller @ 2014-09-08 22:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, alexander.h.duyck, netdev
In-Reply-To: <1410211842.11872.133.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 08 Sep 2014 14:30:42 -0700
> In the worst case, here is what is happening :
>
> sk_rx_dst is checked and invalidated in tcp_v4_do_rcv()
>
> Next packets coming from prequeue might then have a NULL dst, and
> we'll do nothing special (sk_rx_dst will stay NULL), because we do
> handle NULL dst properly in inet_sk_rx_dst_set() and
> inet6_sk_rx_dst_set()
>
> But next packet to be processed (either in non prequeue mode or
> prequeue) will carry skb->dst and we will set sk->sk_rx_dst
>
> I decided to not copy/paste the tests we do in the family dependent
> parts, because it was not worth the pain.
I must have mis-read some of these code paths, let me look over it
again, thanks!
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: do not ignore autoneg in mlx4_en_set_pauseparam()
From: David Miller @ 2014-09-08 22:57 UTC (permalink / raw)
To: ivecera; +Cc: netdev, amirv
In-Reply-To: <1410194813-994-1-git-send-email-ivecera@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Mon, 8 Sep 2014 18:46:53 +0200
> The driver does not support pause autonegotiation so it should return
> -EINVAL when the function is called with non-zero autoneg.
>
> Cc: Amir Vadai <amirv@mellanox.com>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Applied, thanks Ivan.
^ permalink raw reply
* Re: [net-next PATCH v2 1/1] drivers: net: cpsw: Add support for pause frames
From: David Miller @ 2014-09-08 23:01 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev
In-Reply-To: <1410197042-8168-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Mon, 8 Sep 2014 22:54:02 +0530
> CPSW supports both rx and tx pause frames for flow control.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] net: systemport and bcmgenet OOM fixes
From: David Miller @ 2014-09-08 23:03 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <1410201472-3764-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 8 Sep 2014 11:37:50 -0700
> These two patches fix similar Out of Memory code paths in the SYSTEMPORT and
> GENET drivers. Under high memory pressure, we could produce an OOPS by
> passing a NULL pointer to dma_unmap_single().
Series applied, thanks Florian.
^ permalink raw reply
* [PATCH net-next] inet: remove dead inetpeer sequence code
From: Willem de Bruijn @ 2014-09-08 23:08 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, Willem de Bruijn
inetpeer sequence numbers are no longer incremented, so no need to
check and flush the tree. The function that increments the sequence
number was already dead code and removed in in "ipv4: remove unused
function" (068a6e18). Remove the code that checks for a change, too.
Verifying that v4_seq and v6_seq are never incremented and thus that
flush_check compares bp->flush_seq to 0 is trivial.
The second part of the change removes flush_check completely even
though bp->flush_seq is exactly !0 once, at initialization. This
change is correct because the time this branch is true is when
bp->root == peer_avl_empty_rcu, in which the branch and
inetpeer_invalidate_tree are a NOOP.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
include/net/inetpeer.h | 1 -
net/ipv4/inetpeer.c | 21 ---------------------
2 files changed, 22 deletions(-)
diff --git a/include/net/inetpeer.h b/include/net/inetpeer.h
index 01d590e..80479ab 100644
--- a/include/net/inetpeer.h
+++ b/include/net/inetpeer.h
@@ -61,7 +61,6 @@ struct inet_peer {
struct inet_peer_base {
struct inet_peer __rcu *root;
seqlock_t lock;
- u32 flush_seq;
int total;
};
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index bd5f592..241afd7 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -72,29 +72,10 @@ void inet_peer_base_init(struct inet_peer_base *bp)
{
bp->root = peer_avl_empty_rcu;
seqlock_init(&bp->lock);
- bp->flush_seq = ~0U;
bp->total = 0;
}
EXPORT_SYMBOL_GPL(inet_peer_base_init);
-static atomic_t v4_seq = ATOMIC_INIT(0);
-static atomic_t v6_seq = ATOMIC_INIT(0);
-
-static atomic_t *inetpeer_seq_ptr(int family)
-{
- return (family == AF_INET ? &v4_seq : &v6_seq);
-}
-
-static inline void flush_check(struct inet_peer_base *base, int family)
-{
- atomic_t *fp = inetpeer_seq_ptr(family);
-
- if (unlikely(base->flush_seq != atomic_read(fp))) {
- inetpeer_invalidate_tree(base);
- base->flush_seq = atomic_read(fp);
- }
-}
-
#define PEER_MAXDEPTH 40 /* sufficient for about 2^27 nodes */
/* Exported for sysctl_net_ipv4. */
@@ -444,8 +425,6 @@ struct inet_peer *inet_getpeer(struct inet_peer_base *base,
unsigned int sequence;
int invalidated, gccnt = 0;
- flush_check(base, daddr->family);
-
/* Attempt a lockless lookup first.
* Because of a concurrent writer, we might not find an existing entry.
*/
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: [PATCH net-next] inet: remove dead inetpeer sequence code
From: Eric Dumazet @ 2014-09-08 23:17 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, davem
In-Reply-To: <1410217714-26421-1-git-send-email-willemb@google.com>
On Mon, 2014-09-08 at 19:08 -0400, Willem de Bruijn wrote:
> inetpeer sequence numbers are no longer incremented, so no need to
> check and flush the tree. The function that increments the sequence
> number was already dead code and removed in in "ipv4: remove unused
> function" (068a6e18). Remove the code that checks for a change, too.
>
> Verifying that v4_seq and v6_seq are never incremented and thus that
> flush_check compares bp->flush_seq to 0 is trivial.
>
> The second part of the change removes flush_check completely even
> though bp->flush_seq is exactly !0 once, at initialization. This
> change is correct because the time this branch is true is when
> bp->root == peer_avl_empty_rcu, in which the branch and
> inetpeer_invalidate_tree are a NOOP.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* [PATCH net-next] net-timestamp: optimize sock_tx_timestamp default path
From: Willem de Bruijn @ 2014-09-08 23:27 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, richardcochran, Willem de Bruijn
Few packets have timestamping enabled. Exit sock_tx_timestamp quickly
in this common case.
Packets are only possibly timestamped if one of
SOF_TIMESTAMPING_(SOFTWARE|RAW_HARDWARE) is enabled.
Signed-off-by: Willem de Bruijn <willemb@google.com>
----
I have one more short timestamping patch after this, to remove
SOCK_TIMESTAMPING_RX_SOFTWARE and simplify the receive timestamp
path a bit. I have not forgotten about the timestamp cookies: once
these smaller changes are in, I'll take another look at that. It
is a more complex change, and I didn't want to block these in the
meantime.
---
include/net/sock.h | 8 +++++++-
net/socket.c | 4 ++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 049ab1b..245136e 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2199,6 +2199,8 @@ static inline void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
sk->sk_stamp = skb->tstamp;
}
+void __sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags);
+
/**
* sock_tx_timestamp - checks whether the outgoing packet is to be time stamped
* @sk: socket sending this packet
@@ -2206,7 +2208,11 @@ static inline void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
*
* Note : callers should take care of initial *tx_flags value (usually 0)
*/
-void sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags);
+static inline void sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags)
+{
+ if (unlikely(sk->sk_tsflags & SOF_TIMESTAMPING_MASK))
+ __sock_tx_timestamp(sk, tx_flags);
+}
/**
* sk_eat_skb - Release a skb if it is no longer needed
diff --git a/net/socket.c b/net/socket.c
index 2e2586e..2d1c2c8 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -610,7 +610,7 @@ void sock_release(struct socket *sock)
}
EXPORT_SYMBOL(sock_release);
-void sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags)
+void __sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags)
{
u8 flags = *tx_flags;
@@ -631,7 +631,7 @@ void sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags)
*tx_flags = flags;
}
-EXPORT_SYMBOL(sock_tx_timestamp);
+EXPORT_SYMBOL(__sock_tx_timestamp);
static inline int __sock_sendmsg_nosec(struct kiocb *iocb, struct socket *sock,
struct msghdr *msg, size_t size)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: [PATCH net-next] net-timestamp: optimize sock_tx_timestamp default path
From: Willem de Bruijn @ 2014-09-08 23:29 UTC (permalink / raw)
To: Network Development
Cc: David Miller, Eric Dumazet, Richard Cochran, Willem de Bruijn
In-Reply-To: <1410218824-18296-1-git-send-email-willemb@google.com>
> Few packets have timestamping enabled. Exit sock_tx_timestamp quickly
> in this common case.
>
> Packets are only possibly timestamped if one of
> SOF_TIMESTAMPING_(SOFTWARE|RAW_HARDWARE) is enabled.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
I submitted this too soon. I hadn't noticed that SOCK_WIFI_STATUS is
also possibly set in sock_tx_timestamp. Let me take another look.
Apologies for the churn.
^ permalink raw reply
* Re: [PATCH net-next] inet: remove dead inetpeer sequence code
From: David Miller @ 2014-09-08 23:43 UTC (permalink / raw)
To: willemb; +Cc: netdev, eric.dumazet
In-Reply-To: <1410217714-26421-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Date: Mon, 8 Sep 2014 19:08:34 -0400
> inetpeer sequence numbers are no longer incremented, so no need to
> check and flush the tree. The function that increments the sequence
> number was already dead code and removed in in "ipv4: remove unused
> function" (068a6e18). Remove the code that checks for a change, too.
>
> Verifying that v4_seq and v6_seq are never incremented and thus that
> flush_check compares bp->flush_seq to 0 is trivial.
>
> The second part of the change removes flush_check completely even
> though bp->flush_seq is exactly !0 once, at initialization. This
> change is correct because the time this branch is true is when
> bp->root == peer_avl_empty_rcu, in which the branch and
> inetpeer_invalidate_tree are a NOOP.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: pull request: wireless-next 2014-09-08
From: David Miller @ 2014-09-08 23:44 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20140908191630.GB29412@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 8 Sep 2014 15:16:31 -0400
> Please pull this batch of updates intended for the 3.18 stream...
Pulled into net-next, thanks a lot John.
^ permalink raw reply
* [PATCH net-next v2] net-timestamp: optimize sock_tx_timestamp default path
From: Willem de Bruijn @ 2014-09-08 23:58 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, richardcochran, Willem de Bruijn
Few packets have timestamping enabled. Exit sock_tx_timestamp quickly
in this common case.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
include/net/sock.h | 10 +++++++++-
net/socket.c | 7 ++-----
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 049ab1b..515a4d0 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2199,6 +2199,8 @@ static inline void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
sk->sk_stamp = skb->tstamp;
}
+void __sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags);
+
/**
* sock_tx_timestamp - checks whether the outgoing packet is to be time stamped
* @sk: socket sending this packet
@@ -2206,7 +2208,13 @@ static inline void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
*
* Note : callers should take care of initial *tx_flags value (usually 0)
*/
-void sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags);
+static inline void sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags)
+{
+ if (unlikely(sk->sk_tsflags))
+ __sock_tx_timestamp(sk, tx_flags);
+ if (unlikely(sock_flag(sk, SOCK_WIFI_STATUS)))
+ *tx_flags |= SKBTX_WIFI_STATUS;
+}
/**
* sk_eat_skb - Release a skb if it is no longer needed
diff --git a/net/socket.c b/net/socket.c
index 2e2586e..d40f522 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -610,7 +610,7 @@ void sock_release(struct socket *sock)
}
EXPORT_SYMBOL(sock_release);
-void sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags)
+void __sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags)
{
u8 flags = *tx_flags;
@@ -626,12 +626,9 @@ void sock_tx_timestamp(const struct sock *sk, __u8 *tx_flags)
if (sk->sk_tsflags & SOF_TIMESTAMPING_TX_ACK)
flags |= SKBTX_ACK_TSTAMP;
- if (sock_flag(sk, SOCK_WIFI_STATUS))
- flags |= SKBTX_WIFI_STATUS;
-
*tx_flags = flags;
}
-EXPORT_SYMBOL(sock_tx_timestamp);
+EXPORT_SYMBOL(__sock_tx_timestamp);
static inline int __sock_sendmsg_nosec(struct kiocb *iocb, struct socket *sock,
struct msghdr *msg, size_t size)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Fw: [Bug 84051] New: Panic while transferring bigger amount of data with device driver "forcedeth"
From: Stephen Hemminger @ 2014-09-09 0:28 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sun, 7 Sep 2014 23:43:26 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 84051] New: Panic while transferring bigger amount of data with device driver "forcedeth"
https://bugzilla.kernel.org/show_bug.cgi?id=84051
Bug ID: 84051
Summary: Panic while transferring bigger amount of data with
device driver "forcedeth"
Product: Networking
Version: 2.5
Kernel Version: 3.14.4
Hardware: Intel
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: mapo2364@gmail.com
Regression: No
Created attachment 149391
--> https://bugzilla.kernel.org/attachment.cgi?id=149391&action=edit
/var/log/messages with kernel panic
Overview:
While transferring about 20GB (~40MB/s) over SSH the kernel is going to panic.
After about a minute.
Steps to Reproduce:
1) git clone of a big repo
2) wait
Actual Results:
Kernel Panic: see attached log
Build Date & Hardware:
Linux client-01 3.14.4-aufs-x86_64-mynet-latest-unstable #1 SMP Sat Jul 5
13:06:29 CEST 2014 x86_64 AMD Phenom(tm) II X4 955 Processor AuthenticAMD
GNU/Linux
aufs-sources from gentoo portage
PS: This is my first bug report. Please feel free to ask for further
information, if needed.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH][net-next] openvswitch: change the data type of error status to atomic_long_t
From: Li RongQing @ 2014-09-09 0:29 UTC (permalink / raw)
To: Pravin Shelar; +Cc: netdev
In-Reply-To: <CALnjE+pTVVr3dQTnUZqB4vQ=MjhyJ1C859Rkjmf7JOGzVVsb5w@mail.gmail.com>
On Tue, Sep 9, 2014 at 6:26 AM, Pravin Shelar <pshelar@nicira.com> wrote:
> On Sun, Sep 7, 2014 at 2:24 AM, Li RongQing <roy.qing.li@gmail.com> wrote:
>> On Sun, Sep 7, 2014 at 11:44 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>>>> The operation of atomic maybe faster than spin lock.
>>>
>>> What is reason for this change?
>>
>> 1. The operation of atomic maybe faster than spin lock
>> 2. I did not find that tx_dropped/tx_error/.. is protected by spin
>> lock under net dir,
>> sometime tx_dropped is atomic_long_t; sometime it is percpu variable;
>> sometime it is
>> u64,but does not need to protect.
>>
>
> These are error counter and the access is not performance sensitive
> code. So I do not see obvious need to optimize it. Do you have any
> performance number for this patch?
I have no performance number, and did not know how to get the performance
number, since I did not know how to trigger the error packet continually.
But I think atomic is suitable for this condition, it maybe
over-skill to use a spin
lock to protect a single variable, and using atomic can save a spin lock space.
-Roy
^ permalink raw reply
* Fw: [Bug 84061] New: net/batman-adv/gateway_client.c:813: missing sanity check and dodgy coding ?
From: Stephen Hemminger @ 2014-09-09 0:30 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Mon, 8 Sep 2014 00:04:40 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 84061] New: net/batman-adv/gateway_client.c:813: missing sanity check and dodgy coding ?
https://bugzilla.kernel.org/show_bug.cgi?id=84061
Bug ID: 84061
Summary: net/batman-adv/gateway_client.c:813: missing sanity
check and dodgy coding ?
Product: Networking
Version: 2.5
Kernel Version: 3.17-rc4
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: dcb314@hotmail.com
Regression: No
net/batman-adv/gateway_client.c:813:31: warning: logical not is only applied to
the left hand side of comparison [-Wlogical-not-parentheses]
gw_node = batadv_gw_node_get(bat_priv, orig_dst_node);
if (!gw_node->bandwidth_down == 0)
goto out;
Function batadv_gw_node_get can return NULL, so there's
a missing sanity check there and maybe the if condition
can be reworked for clarity.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM
From: Luis R. Rodriguez @ 2014-09-09 1:04 UTC (permalink / raw)
To: Tejun Heo, Lennart Poettering, Kay Sievers
Cc: Dmitry Torokhov, Greg Kroah-Hartman, Wu Zhangjin, Takashi Iwai,
Arjan van de Ven, linux-kernel@vger.kernel.org, Oleg Nesterov,
hare, Andrew Morton, Tetsuo Handa, Joseph Salisbury,
Benjamin Poirier, Santosh Rastapur, One Thousand Gnomes,
Tim Gardner, Pierre Fersing, Nagalakshmi Nandigama,
Praveen Krishnamoorthy, Sreekanth Reddy, Abhijit Mahajan
In-Reply-To: <20140905224047.GC15723@mtj.dyndns.org>
On Fri, Sep 5, 2014 at 3:40 PM, Tejun Heo <tj@kernel.org> wrote:
> Hello, Luis.
>
> On Fri, Sep 05, 2014 at 11:12:17AM -0700, Luis R. Rodriguez wrote:
>> Meanwhile we are allowing a major design consideration such as a 30
>> second timeout for both init + probe all of a sudden become a hard
>> requirement for device drivers. I see your point but can't also be
>> introducing major design changes willy nilly either. We *need* a
>> solution for the affected drivers.
>
> Yes, make the behavior specifically specified from userland. When did
> I ever say that there should be no solution for the problem? I've
> been saying that the behavior should be selected from userland from
> the get-go, haven't I?
>
> I have no idea how the selection should be. It could be per-insmod or
> maybe just a system-wide flag with explicit exceptions marked on
> drivers is good enough. I don't know.
Its perfectly understandable if we don't know what path to take yet
and its also understandable for it to take time to figure out --
meanwhile though systemd already has merged a policy of a 30 second
timeout for *all drivers* though so we therefore need:
0) a solutions for affected combination of systemd / drivers
1) an agreed path forward
If we want a tight integration between both kernel / init system we
need to be able to communicate effectively folks and I'm afraid this
isn't happening. I last noted on systemd-devel how the 30 second
timeout issue was merged under incorrect assumptions -- that it was
not just init that at times caused delays, and that since we currently
batch both init and probe on the driver core we need a non fatal
userspace solution [0], while we work on design on the kernel side of
things for async'ing for drivers that make sense. A proper kernel
solution may take longer than expected, we can't just assume a
probe_async flag will suffice on drivers, in fact as Tejun notes, its
wrong since historically we have had some random userland depend on
the synhronous behaviour of module loading of some drivers, and that
*could* have taken a while.
Kay, Lennart, any recommendations ?
[0] http://lists.freedesktop.org/archives/systemd-devel/2014-August/022696.html
>> Also what stops drivers from going ahead and just implementing their
>> own async probe? Would that now be frowned upon as it strives away
>
> The drivers can't. How many times should I explain the same thing
> over and over again. libata can't simply make probing asynchronous
> w.r.t. module loading no matter how it does it. Yeah, sure, there can
> be other drivers which can do that without most people noticing it but
> a storage driver isn't one of them and the storage drivers are the
> problematic ones already, right?
Its one of the subsystems that has suffered from this, but not the only one.
>> from the original design? The bool would let those drivers do this
>> easily, and we would still need to identify these drivers, although
>> this particular change can be NAK'd Oleg's suggestion on
>> WARN_ON(fatal_signal_pending() at the end of load_module() seems to me
>> at least needed. And if its not async probe... what do those with
>> failed drivers do?
>
> I'm getting tired of explaining the same thing over and over again.
> The said change was nacked because the whole approach of "let's see
> which drivers get reported on the issue which exists basically for all
> drivers and just change the behavior of them" is braindead. It makes
> no sense whatsoever. It doesn't address the root cause of the problem
> while making the same class of drivers behave significantly
> differently for no good reason. Please stop chasing your own tail and
> try to understand the larger picture.
Understood.
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox