* Re: [PATCH net-next] fix rtnl notification in atomic context
From: David Miller @ 2013-10-23 21:09 UTC (permalink / raw)
To: stephen; +Cc: ast, nicolas.dichtel, amwang, netdev
In-Reply-To: <20131023140343.4604d80d@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 23 Oct 2013 14:03:43 -0700
> On Wed, 23 Oct 2013 11:32:41 -0700
> Alexei Starovoitov <ast@plumgrid.com> wrote:
>
>> +
>> +void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change)
>> +{
>> + __rtmsg_ifinfo(type, dev, change, GFP_KERNEL);
>> +}
>> EXPORT_SYMBOL(rtmsg_ifinfo);
>>
>> static int nlmsg_populate_fdb_fill(struct sk_buff *skb,
>> --
>
> Why add another wrapper function? I think it cleaner to just change all the
> callers to use the correct gfp flags.
Indeed, if this were targetted to "net" we'd have the argument of trying
to simplify the patch for -stable inclusion.
But since this is going into net-next, let's just put explicit GFP_* args
at the call site.
^ permalink raw reply
* Re: [PATCH net-next] fix rtnl notification in atomic context
From: Stephen Hemminger @ 2013-10-23 21:03 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David S. Miller, Nicolas Dichtel, Cong Wang, netdev
In-Reply-To: <1382553161-3498-1-git-send-email-ast@plumgrid.com>
On Wed, 23 Oct 2013 11:32:41 -0700
Alexei Starovoitov <ast@plumgrid.com> wrote:
> +
> +void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change)
> +{
> + __rtmsg_ifinfo(type, dev, change, GFP_KERNEL);
> +}
> EXPORT_SYMBOL(rtmsg_ifinfo);
>
> static int nlmsg_populate_fdb_fill(struct sk_buff *skb,
> --
Why add another wrapper function? I think it cleaner to just change all the
callers to use the correct gfp flags.
^ permalink raw reply
* Re: [PATCH net-next 0/3] initialize fragment hash secrets with net_get_random_once
From: David Miller @ 2013-10-23 21:02 UTC (permalink / raw)
To: hannes; +Cc: netdev, netfilter-devel
In-Reply-To: <1382519217-750-1-git-send-email-hannes@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 23 Oct 2013 11:06:54 +0200
> This series switches the inet_frag.rnd hash initialization to
> net_get_random_once.
>
> Included patches:
> ipv4: initialize ip4_frags hash secret as late
> ipv6: split inet6_hash_frag for netfilter and
> inet: remove old fragmentation hash initializing
Looks good, series applied, thanks Hannes.
^ permalink raw reply
* Re: [PATCH net] net: sctp: fix ASCONF to allow non SCTP_ADDR_SRC addresses in ipv6
From: David Miller @ 2013-10-23 20:57 UTC (permalink / raw)
To: dborkman; +Cc: netdev, linux-sctp, micchie
In-Reply-To: <1382459696-1732-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Tue, 22 Oct 2013 18:34:56 +0200
> Commit 8a07eb0a50 ("sctp: Add ASCONF operation on the single-homed host")
> implemented possible use of IPv4 addresses with non SCTP_ADDR_SRC state
> as source address when sending ASCONF (ADD) packets, but IPv6 part for
> that was not implemented in 8a07eb0a50. Therefore, as this is not restricted
> to IPv4-only, fix this up to allow the same for IPv6 addresses in SCTP.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Michio Honda <micchie@sfc.wide.ad.jp>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/3] netfilter fixes for net
From: David Miller @ 2013-10-23 20:56 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1382519724-3953-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 23 Oct 2013 11:15:21 +0200
> The following patchset contains three netfilter fixes for your net
> tree, they are:
>
> * A couple of fixes to resolve info leak to userspace due to uninitialized
> memory area in ulogd, from Mathias Krause.
>
> * Fix instruction ordering issues that may lead to the access of
> uninitialized data in x_tables. The problem involves the table update
> (producer) and the main packet matching (consumer) routines. Detected in
> SMP ARMv7, from Will Deacon.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git master
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH] sh_eth: add/use RMCR.RNC bit
From: David Miller @ 2013-10-23 20:50 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, nobuhiro.iwamatsu.yj, linux-sh, horms
In-Reply-To: <5266F94E.9030406@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Wed, 23 Oct 2013 02:16:46 +0400
> Hello.
>
> On 10/16/2013 02:29 AM, Sergei Shtylyov wrote:
>
>> Declare 'enum EMCR_BIT' containing the single member for the RMCR.RNC
>> bit and
>
> Hm, looks like I typoed here, should have been RMCR_BIT. David, should
> I resubmit or you can fix it while applying? Or simply not worth the
> trouble?
Applied, with the typo fixed, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: always inline net_secret_init
From: David Miller @ 2013-10-23 20:27 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20131023064450.GA26236@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 23 Oct 2013 08:44:50 +0200
> Currently net_secret_init does not get inlined, so we always have a call
> to net_secret_init even in the fast path.
>
> Let's specify net_secret_init as __always_inline so we have the nop in
> the fast-path without the call to net_secret_init and the unlikely path
> at the epilogue of the function.
>
> jump_labels handle the inlining correctly.
>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied, thanks Hannes.
^ permalink raw reply
* Re: [PATCH net] netpoll: fix rx_hook() interface by passing the skb
From: David Miller @ 2013-10-23 20:16 UTC (permalink / raw)
To: antonio; +Cc: David.Laight, netdev
In-Reply-To: <20131023124401.GC1535@neomailbox.net>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Wed, 23 Oct 2013 14:44:01 +0200
> On Wed, Oct 23, 2013 at 12:18:32PM +0100, David Laight wrote:
>> > My idea is to use the following API:
>> >
>> > rx_skb_hook(struct netpoll *np, int source, struct sk_buff *skb, int len);
>> >
>> > Any suggestion or objection?
>>
>> Don't you need to pass the offset of the udp data?
>
> Yes, you are right. I just forgot it. Therefore we have:
>
> rx_skb_hook(struct netpoll *np, int source, struct sk_buff *skb, int offset,
> int len);
>
> where offset is going to be = (udp_hdr + 1) - skb->data
> and len = skb->len - offset
This looks good to me.
^ permalink raw reply
* Re: [PATCH] Fix: Dereference pointer-value of sk_prot->memory_pressure
From: David Miller @ 2013-10-23 20:15 UTC (permalink / raw)
To: ebiederm; +Cc: eric.dumazet, christoph.paasch, fengguang.wu, netdev,
linux-kernel
In-Reply-To: <87r4bbiwyh.fsf_-_@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 23 Oct 2013 12:55:18 -0700
> From: Christoph Paasch <christoph.paasch@uclouvain.be>
> Date: Wed, 23 Oct 2013 12:49:21 -0700
>
> 2e685cad57 (tcp_memcontrol: Kill struct tcp_memcontrol) falsly modified
> the access to memory_pressure of sk->sk_prot->memory_pressure. The patch
> did modify the memory_pressure-field of struct cg_proto, but not the one
> of struct proto.
>
> So, the access to sk_prot->memory_pressure should not be changed.
>
> Acked-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied, but I replaced "Fix: " with "net: " in the commit header line.
^ permalink raw reply
* [PATCH] Fix: Dereference pointer-value of sk_prot->memory_pressure
From: Eric W. Biederman @ 2013-10-23 19:58 UTC (permalink / raw)
To: David Miller
Cc: Christoph Paasch, fengguang.wu, netdev, linux-kernel,
Eric Dumazet
In-Reply-To: <1382533364.7572.15.camel@edumazet-glaptop.roam.corp.google.com>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Wed, 23 Oct 2013 12:49:21 -0700
2e685cad57 (tcp_memcontrol: Kill struct tcp_memcontrol) falsly modified
the access to memory_pressure of sk->sk_prot->memory_pressure. The patch
did modify the memory_pressure-field of struct cg_proto, but not the one
of struct proto.
So, the access to sk_prot->memory_pressure should not be changed.
Acked-by: Eric Dumazet <edumazet@google.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
Resent because I fat fingered and deleted Dave by accident.
include/net/sock.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index c93542f92420..e3a18ff0c38b 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1137,7 +1137,7 @@ static inline bool sk_under_memory_pressure(const struct sock *sk)
if (mem_cgroup_sockets_enabled && sk->sk_cgrp)
return !!sk->sk_cgrp->memory_pressure;
- return !!sk->sk_prot->memory_pressure;
+ return !!*sk->sk_prot->memory_pressure;
}
static inline void sk_leave_memory_pressure(struct sock *sk)
--
1.7.5.4
^ permalink raw reply related
* [PATCH] Fix: Dereference pointer-value of sk_prot->memory_pressure
From: Eric W. Biederman @ 2013-10-23 19:55 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Paasch, fengguang.wu, netdev, linux-kernel,
Eric Dumazet
In-Reply-To: <1382533364.7572.15.camel@edumazet-glaptop.roam.corp.google.com>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Wed, 23 Oct 2013 12:49:21 -0700
2e685cad57 (tcp_memcontrol: Kill struct tcp_memcontrol) falsly modified
the access to memory_pressure of sk->sk_prot->memory_pressure. The patch
did modify the memory_pressure-field of struct cg_proto, but not the one
of struct proto.
So, the access to sk_prot->memory_pressure should not be changed.
Acked-by: Eric Dumazet <edumazet@google.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
include/net/sock.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index c93542f92420..e3a18ff0c38b 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1137,7 +1137,7 @@ static inline bool sk_under_memory_pressure(const struct sock *sk)
if (mem_cgroup_sockets_enabled && sk->sk_cgrp)
return !!sk->sk_cgrp->memory_pressure;
- return !!sk->sk_prot->memory_pressure;
+ return !!*sk->sk_prot->memory_pressure;
}
static inline void sk_leave_memory_pressure(struct sock *sk)
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH net-next 0/2] Removal of struct esp_data
From: David Miller @ 2013-10-23 19:40 UTC (permalink / raw)
To: steffen.klassert; +Cc: mathias.krause, netdev, herbert
In-Reply-To: <20131023080716.GA10148@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 23 Oct 2013 10:07:16 +0200
> Well, I thought to either take this as a reminder to implement the
> missing stuff or to take the removing patches if this is really obsolete.
> I'll do one of both once I'm back from conference week in Edinburgh.
Sounds like a good plan, thanks.
^ permalink raw reply
* Re: [PATCH 1/4] [RFC] net: Explicitly initialize u64_stats_sync structures for lockdep
From: Julian Anastasov @ 2013-10-23 19:37 UTC (permalink / raw)
To: John Stultz
Cc: LKML, Eric Dumazet, Thomas Petazzoni, Mirko Lindner,
Stephen Hemminger, Roger Luethi, Patrick McHardy, Rusty Russell,
Michael S. Tsirkin, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Wensong Zhang, Simon Horman, Jesse Gross,
Mathieu Desnoyers, Steven Rostedt, Peter Zijlstra, Ingo Molnar,
Thomas Gleixner, David S. Miller, netdev, netfilter-devel
In-Reply-To: <52681407.8060804@linaro.org>
Hello,
On Wed, 23 Oct 2013, John Stultz wrote:
> Just wanted to ping folks on this patch, as I haven't gotten any feedback.
>
> As its a prereq for the seqcount lockdep support, I'd like to get it
> queued/merged, but I'm not sure what the right maintainer path or
> approach should be.
>
> 1) Do folks prefer to see this patch split up into 30-some separate
> trivial clenaup patches, or have it go in all as one logical change?
>
> 2) Would folks want this patch (in whichever form) to be merged
> separately via the networking maintainers, or can it be merged via -tip
> as part of the seqcount lockdep series?
The IPVS part in net/netfilter/ipvs/ looks ok to me.
We do not have any pending changes for this area, so you can
skip the ipvs trees for this change. If you need ack for the
IPVS part, here it is:
Acked-by: Julian Anastasov <ja@ssi.bg>
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* URGENT REPLY NEEDED
From: Suleman Abubaker @ 2013-10-23 18:57 UTC (permalink / raw)
Greetings Dear Friend.
I am Mr Suleman Abubaker, Staff of Bank Of Africa in Burkina Faso. I would like you to indicate your interest to
receive the transfer of ($20.5 Million Dollars) I will like you to stand as the next of kin to my late client whose account is presently dormant for claims. if you are interested,indicate and i will intimate you with the method of application and how you can apply to the bank .
But before i send to you the text of application form,I will like you to send me the following informations
1.NAME IN FULL:................................
2.ADDRESS:.......................................
3.NATIONALITY:.................................. .
4.AGE:.............................................
5.SEX..............................................
6.OCCUPATION:......................................
7.MARITAL STATUS:..................................
8.PRIAVTE PHONE NO............................................
9.PRIVATE FAX NO:.............................................
10.ATTACH COPY OF YOUR IDENTIFICATION...........................
Now my questions are:
1) Can you handle this project?
2) Can I give you this trust?
so i will like you to send to me those informations for easy and effective communication.Upon receipt of your reply, I will send to you by fax or
email the text of the application form.I will not fail to bring to your notice that this transaction is hitch-free and that you should not entertain any atom of fear as all required arrangements have been made for the transfer. You should contact me immediately as soon as you receive this letter,if only you are intrested and ready to help. Trusting to hear from you immediately.
Do keep this a top secret for security reasons.
Best Regards
Mr Suleman Abubaker.
^ permalink raw reply
* [PATCH net-next] fix rtnl notification in atomic context
From: Alexei Starovoitov @ 2013-10-23 18:32 UTC (permalink / raw)
To: David S. Miller; +Cc: Nicolas Dichtel, Cong Wang, netdev
commit 991fb3f74c "dev: always advertise rx_flags changes via netlink"
introduced rtnl notification from __dev_set_promiscuity(),
which can be called in atomic context.
Steps to reproduce:
ip tuntap add dev tap1 mode tap
ifconfig tap1 up
tcpdump -nei tap1 &
ip tuntap del dev tap1 mode tap
[ 271.627994] device tap1 left promiscuous mode
[ 271.639897] BUG: sleeping function called from invalid context at mm/slub.c:940
[ 271.664491] in_atomic(): 1, irqs_disabled(): 0, pid: 3394, name: ip
[ 271.677525] INFO: lockdep is turned off.
[ 271.690503] CPU: 0 PID: 3394 Comm: ip Tainted: G W 3.12.0-rc3+ #73
[ 271.703996] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[ 271.731254] ffffffff81a58506 ffff8807f0d57a58 ffffffff817544e5 ffff88082fa0f428
[ 271.760261] ffff8808071f5f40 ffff8807f0d57a88 ffffffff8108bad1 ffffffff81110ff8
[ 271.790683] 0000000000000010 00000000000000d0 00000000000000d0 ffff8807f0d57af8
[ 271.822332] Call Trace:
[ 271.838234] [<ffffffff817544e5>] dump_stack+0x55/0x76
[ 271.854446] [<ffffffff8108bad1>] __might_sleep+0x181/0x240
[ 271.870836] [<ffffffff81110ff8>] ? rcu_irq_exit+0x68/0xb0
[ 271.887076] [<ffffffff811a80be>] kmem_cache_alloc_node+0x4e/0x2a0
[ 271.903368] [<ffffffff810b4ddc>] ? vprintk_emit+0x1dc/0x5a0
[ 271.919716] [<ffffffff81614d67>] ? __alloc_skb+0x57/0x2a0
[ 271.936088] [<ffffffff810b4de0>] ? vprintk_emit+0x1e0/0x5a0
[ 271.952504] [<ffffffff81614d67>] __alloc_skb+0x57/0x2a0
[ 271.968902] [<ffffffff8163a0b2>] rtmsg_ifinfo+0x52/0x100
[ 271.985302] [<ffffffff8162ac6d>] __dev_notify_flags+0xad/0xc0
[ 272.001642] [<ffffffff8162ad0c>] __dev_set_promiscuity+0x8c/0x1c0
[ 272.017917] [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380
[ 272.033961] [<ffffffff8162b109>] dev_set_promiscuity+0x29/0x50
[ 272.049855] [<ffffffff8172e937>] packet_dev_mc+0x87/0xc0
[ 272.065494] [<ffffffff81732052>] packet_notifier+0x1b2/0x380
[ 272.080915] [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380
[ 272.096009] [<ffffffff81761c66>] notifier_call_chain+0x66/0x150
[ 272.110803] [<ffffffff8108503e>] __raw_notifier_call_chain+0xe/0x10
[ 272.125468] [<ffffffff81085056>] raw_notifier_call_chain+0x16/0x20
[ 272.139984] [<ffffffff81620190>] call_netdevice_notifiers_info+0x40/0x70
[ 272.154523] [<ffffffff816201d6>] call_netdevice_notifiers+0x16/0x20
[ 272.168552] [<ffffffff816224c5>] rollback_registered_many+0x145/0x240
[ 272.182263] [<ffffffff81622641>] rollback_registered+0x31/0x40
[ 272.195369] [<ffffffff816229c8>] unregister_netdevice_queue+0x58/0x90
[ 272.208230] [<ffffffff81547ca0>] __tun_detach+0x140/0x340
[ 272.220686] [<ffffffff81547ed6>] tun_chr_close+0x36/0x60
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
include/linux/rtnetlink.h | 4 +++-
net/core/dev.c | 2 +-
net/core/rtnetlink.c | 12 +++++++++---
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index f28544b..26f5edc 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -15,7 +15,9 @@ extern int rtnetlink_put_metrics(struct sk_buff *skb, u32 *metrics);
extern int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst,
u32 id, long expires, u32 error);
-extern void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change);
+void __rtmsg_ifinfo(int type, struct net_device *dev, unsigned change,
+ gfp_t flags);
+void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change);
/* RTNL is used as a global lock for all changes to network configuration */
extern void rtnl_lock(void);
diff --git a/net/core/dev.c b/net/core/dev.c
index 0918aad..59b90fe 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5257,7 +5257,7 @@ void __dev_notify_flags(struct net_device *dev, unsigned int old_flags,
unsigned int changes = dev->flags ^ old_flags;
if (gchanges)
- rtmsg_ifinfo(RTM_NEWLINK, dev, gchanges);
+ __rtmsg_ifinfo(RTM_NEWLINK, dev, gchanges, GFP_ATOMIC);
if (changes & IFF_UP) {
if (dev->flags & IFF_UP)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 4aedf03..5931af9 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1984,14 +1984,15 @@ static int rtnl_dump_all(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
-void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change)
+void __rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change,
+ gfp_t flags)
{
struct net *net = dev_net(dev);
struct sk_buff *skb;
int err = -ENOBUFS;
size_t if_info_size;
- skb = nlmsg_new((if_info_size = if_nlmsg_size(dev, 0)), GFP_KERNEL);
+ skb = nlmsg_new((if_info_size = if_nlmsg_size(dev, 0)), flags);
if (skb == NULL)
goto errout;
@@ -2002,12 +2003,17 @@ void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change)
kfree_skb(skb);
goto errout;
}
- rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL, GFP_KERNEL);
+ rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL, flags);
return;
errout:
if (err < 0)
rtnl_set_sk_err(net, RTNLGRP_LINK, err);
}
+
+void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change)
+{
+ __rtmsg_ifinfo(type, dev, change, GFP_KERNEL);
+}
EXPORT_SYMBOL(rtmsg_ifinfo);
static int nlmsg_populate_fdb_fill(struct sk_buff *skb,
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/4] [RFC] net: Explicitly initialize u64_stats_sync structures for lockdep
From: John Stultz @ 2013-10-23 18:23 UTC (permalink / raw)
To: John Stultz, LKML
Cc: Eric Dumazet, Thomas Petazzoni, Mirko Lindner, Stephen Hemminger,
Roger Luethi, Patrick McHardy, Rusty Russell, Michael S. Tsirkin,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Wensong Zhang,
Simon Horman, Julian Anastasov, Jesse Gross, Mathieu Desnoyers,
Steven Rostedt, Peter Zijlstra, Ingo Molnar, Thomas Gleixner,
David S. Miller, netdev, netfilter-devel
In-Reply-To: <1381186321-4906-2-git-send-email-john.stultz@linaro.org>
On 10/07/2013 03:51 PM, John Stultz wrote:
> In order to enable lockdep on seqcount/seqlock structures, we
> must explicitly initialize any locks.
>
> The u64_stats_sync structure, uses a seqcount, and thus we need
> to introduce a u64_stats_init() function and use it to initialize
> the structure.
>
> This unfortunately adds a lot of fairly trivial initialization code
> to a number of drivers. But the benefit of ensuring correctness makes
> this worth while.
>
> Because these changes are required for lockdep to be enabled, and the
> changes are quite trivial, I've not yet split this patch out into 30-some
> separate patches, as I figured it would be better to get the various
> maintainers thoughts on how to best merge this change along with
> the seqcount lockdep enablement.
Just wanted to ping folks on this patch, as I haven't gotten any feedback.
As its a prereq for the seqcount lockdep support, I'd like to get it
queued/merged, but I'm not sure what the right maintainer path or
approach should be.
1) Do folks prefer to see this patch split up into 30-some separate
trivial clenaup patches, or have it go in all as one logical change?
2) Would folks want this patch (in whichever form) to be merged
separately via the networking maintainers, or can it be merged via -tip
as part of the seqcount lockdep series?
thanks
-john
^ permalink raw reply
* Re: Neterion and UFO handling [was: Re: [PATCH] ipv6: udp packets following an UFO enqueued packet need also be handled by UFO]
From: Hannes Frederic Sowa @ 2013-10-23 18:15 UTC (permalink / raw)
To: Jon Mason
Cc: Jiri Pirko, netdev, yoshfuji, David Miller, Alexey Kuznetsov,
jmorris, Patrick McHardy, Herbert Xu, Eric Dumazet
In-Reply-To: <CAPoiz9xnvmQ18D0iGdFVKL8bD-1nC=8zQVD9o1oxfT4Qc942xw@mail.gmail.com>
On Wed, Oct 23, 2013 at 09:35:43AM -0700, Jon Mason wrote:
> On Wed, Oct 16, 2013 at 9:45 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > Hi Jon and Jiri!
> >
> > Just wanted to remind you if you could have a look at this?
> >
> > If you don't have time to test this may I know your assessment of the
> > situation? I could send a compile-time tested patch to disable UFO or if you
> > say so we could leave this as is.
>
> So, bad news. My Xframe 2 adapter (the only variety that does UFO
> offload) won't fit in a standard PCI(32) slot. Since my PCI-X system
> at home is faulty (I'm trying to fix it , but it won't be in the time
> frame you want), there is no way for me to test it on the hardware.
> Terribly sorry.
>
> I am fine with this patch going out, since UFO is off by default.
> I'll handle any issues once they are discovered. Alternatively, we
> could just kill UFO and make everyone's lives easier.
Oh, I missed that UFO is off by default.
If it turns out that UFO is causing broken frames it should be either
killed or (if you have the time for that) fixed. Because there shouldn't
be regressions in stable kernels I am fine with this resolution. Maybe
you can have a look at this problem once your hardware is fixed.
Thank you,
Hannes
^ permalink raw reply
* [PATCH net-next v2 2/2] net: initialize hashrnd in flow_dissector with net_get_random_once
From: Hannes Frederic Sowa @ 2013-10-23 18:06 UTC (permalink / raw)
To: netdev, davem, edumazet
In-Reply-To: <20131023111219.GA31531@order.stressinduktion.org>
We also can defer the initialization of hashrnd in flow_dissector
to its first use. Since net_get_random_once is irq safe now we don't
have to audit the call paths if one of this functions get called by an
interrupt handler.
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
v2: Reword the commit message only. It looked horribly.
net/core/flow_dissector.c | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index f8e25ac..5cac36e 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -184,6 +184,22 @@ ipv6:
EXPORT_SYMBOL(skb_flow_dissect);
static u32 hashrnd __read_mostly;
+static __always_inline void __flow_hash_secret_init(void)
+{
+ net_get_random_once(&hashrnd, sizeof(hashrnd));
+}
+
+static __always_inline u32 __flow_hash_3words(u32 a, u32 b, u32 c)
+{
+ __flow_hash_secret_init();
+ return jhash_3words(a, b, c, hashrnd);
+}
+
+static __always_inline u32 __flow_hash_1word(u32 a)
+{
+ __flow_hash_secret_init();
+ return jhash_1word(a, hashrnd);
+}
/*
* __skb_get_rxhash: calculate a flow hash based on src/dst addresses
@@ -210,9 +226,9 @@ void __skb_get_rxhash(struct sk_buff *skb)
swap(keys.port16[0], keys.port16[1]);
}
- hash = jhash_3words((__force u32)keys.dst,
- (__force u32)keys.src,
- (__force u32)keys.ports, hashrnd);
+ hash = __flow_hash_3words((__force u32)keys.dst,
+ (__force u32)keys.src,
+ (__force u32)keys.ports);
if (!hash)
hash = 1;
@@ -248,7 +264,7 @@ u16 __skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb,
hash = skb->sk->sk_hash;
else
hash = (__force u16) skb->protocol;
- hash = jhash_1word(hash, hashrnd);
+ hash = __flow_hash_1word(hash);
return (u16) (((u64) hash * qcount) >> 32) + qoffset;
}
@@ -340,7 +356,7 @@ static inline int get_xps_queue(struct net_device *dev, struct sk_buff *skb)
else
hash = (__force u16) skb->protocol ^
skb->rxhash;
- hash = jhash_1word(hash, hashrnd);
+ hash = __flow_hash_1word(hash);
queue_index = map->queues[
((u64)hash * map->len) >> 32];
}
@@ -395,11 +411,3 @@ struct netdev_queue *netdev_pick_tx(struct net_device *dev,
skb_set_queue_mapping(skb, queue_index);
return netdev_get_tx_queue(dev, queue_index);
}
-
-static int __init initialize_hashrnd(void)
-{
- get_random_bytes(&hashrnd, sizeof(hashrnd));
- return 0;
-}
-
-late_initcall_sync(initialize_hashrnd);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: make net_get_random_once irq safe
From: Hannes Frederic Sowa @ 2013-10-23 18:05 UTC (permalink / raw)
To: netdev, davem, edumazet
In-Reply-To: <20131023111200.GB26236@order.stressinduktion.org>
I initial build non irq safe version of net_get_random_once because I
would liked to have the freedom to defer even the extraction process of
get_random_bytes until the nonblocking pool is fully seeded.
I don't think this is a good idea anymore and thus this patch makes
net_get_random_once irq safe. Now someone using net_get_random_once does
not need to care from where it is called.
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
v2: Reword the commit message only. It looked horribly.
include/linux/net.h | 1 -
net/core/utils.c | 7 ++++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/net.h b/include/linux/net.h
index aca446b..b292a04 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -250,7 +250,6 @@ bool __net_get_random_once(void *buf, int nbytes, bool *done,
#define ___NET_RANDOM_STATIC_KEY_INIT STATIC_KEY_INIT_FALSE
#endif /* HAVE_JUMP_LABEL */
-/* BE CAREFUL: this function is not interrupt safe */
#define net_get_random_once(buf, nbytes) \
({ \
bool ___ret = false; \
diff --git a/net/core/utils.c b/net/core/utils.c
index bf09371..2f737bf 100644
--- a/net/core/utils.c
+++ b/net/core/utils.c
@@ -370,16 +370,17 @@ bool __net_get_random_once(void *buf, int nbytes, bool *done,
struct static_key *done_key)
{
static DEFINE_SPINLOCK(lock);
+ unsigned long flags;
- spin_lock_bh(&lock);
+ spin_lock_irqsave(&lock, flags);
if (*done) {
- spin_unlock_bh(&lock);
+ spin_unlock_irqrestore(&lock, flags);
return false;
}
get_random_bytes(buf, nbytes);
*done = true;
- spin_unlock_bh(&lock);
+ spin_unlock_irqrestore(&lock, flags);
__net_random_once_disable_jump(done_key);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 03/16] batman-adv: add bat_orig_print API function
From: Antonio Quartulli @ 2013-10-23 17:37 UTC (permalink / raw)
To: Joe Perches; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1382549233.22433.33.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]
On Wed, Oct 23, 2013 at 10:27:13AM -0700, Joe Perches wrote:
> On Wed, 2013-10-23 at 19:18 +0200, Antonio Quartulli wrote:
> > On Wed, Oct 23, 2013 at 10:00:30AM -0700, Joe Perches wrote:
> > > On Wed, 2013-10-23 at 18:04 +0200, Antonio Quartulli wrote:
> > > > Each routing protocol has its own metric and private
> > > > variables, therefore it is useful to introduce a new API
> > > > for originator information printing.
> > > >
> > > > This API needs to be implemented by each protocol in order
> > > > to provide its specific originator table output.
> > > []
> > > > +static void batadv_iv_ogm_orig_print(struct batadv_priv *bat_priv,
> > > > + struct seq_file *seq)
> > > []
> > > > + seq_printf(seq, " %-15s %s (%s/%i) %17s [%10s]: %20s ...\n",
> > > > + "Originator", "last-seen", "#", BATADV_TQ_MAX_VALUE,
> > > > + "Nexthop", "outgoingIF", "Potential nexthops");
> > >
> > > This header printf really doesn't add much with the formatting sizes.
> > > It's pretty obscure why some of these are sized and others not sized.
> > > For instance: %-15s doesn't refer to a mac address size.
> > > Perhaps it'd be better to just emit the fixed string just using
> > > BATADV_TO_MAX_VALUE. It'd also be easier to find via grep.
> >
> > This string is printed out of a debugfs file and follows a format that we have
> > been using for long time (this patch is just moving this code from one point to
> > another).
>
> I saw.
>
> > I didn't get what you mean with BATADV_TO_MAX_VALUE (maybe you meant
> > BATADV_TQ_MAX_VALUE? but even in this case I don't get it).
>
> Yeah, TQ not TO. Both look similar with squiggles
> underneath them when using spell checking.
>
> It's a #define, all the others are fixed strings.
>
> Anyway, using
> seq_printf(seq, " Originator last-seen (#/%d) Nexthop [outgoingIF]: Potential nexthops ...\n",
> BATADV_TQ_MAX_VALUE);
> is probably trivially smaller overall code size too.
>
> Your code, you decide...
Now I fully understand your point.
Honestly I agree with you, but this string is there since a while and I'd
like to get a feedback from the other guys before changing it.
If for David it is not a problem I'd like keep it like that and I'll discuss and
possibly add this change (this is not the only header in the code printed this
way) later.
Thanks a lot for your feedback!
Cheers,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 03/16] batman-adv: add bat_orig_print API function
From: Joe Perches @ 2013-10-23 17:27 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, Marek Lindner,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Antonio Quartulli
In-Reply-To: <20131023171810.GB2651-rVWd3aGhH2zPj3vggD0kEA@public.gmane.org>
On Wed, 2013-10-23 at 19:18 +0200, Antonio Quartulli wrote:
> On Wed, Oct 23, 2013 at 10:00:30AM -0700, Joe Perches wrote:
> > On Wed, 2013-10-23 at 18:04 +0200, Antonio Quartulli wrote:
> > > Each routing protocol has its own metric and private
> > > variables, therefore it is useful to introduce a new API
> > > for originator information printing.
> > >
> > > This API needs to be implemented by each protocol in order
> > > to provide its specific originator table output.
> > []
> > > +static void batadv_iv_ogm_orig_print(struct batadv_priv *bat_priv,
> > > + struct seq_file *seq)
> > []
> > > + seq_printf(seq, " %-15s %s (%s/%i) %17s [%10s]: %20s ...\n",
> > > + "Originator", "last-seen", "#", BATADV_TQ_MAX_VALUE,
> > > + "Nexthop", "outgoingIF", "Potential nexthops");
> >
> > This header printf really doesn't add much with the formatting sizes.
> > It's pretty obscure why some of these are sized and others not sized.
> > For instance: %-15s doesn't refer to a mac address size.
> > Perhaps it'd be better to just emit the fixed string just using
> > BATADV_TO_MAX_VALUE. It'd also be easier to find via grep.
>
> This string is printed out of a debugfs file and follows a format that we have
> been using for long time (this patch is just moving this code from one point to
> another).
I saw.
> I didn't get what you mean with BATADV_TO_MAX_VALUE (maybe you meant
> BATADV_TQ_MAX_VALUE? but even in this case I don't get it).
Yeah, TQ not TO. Both look similar with squiggles
underneath them when using spell checking.
It's a #define, all the others are fixed strings.
Anyway, using
seq_printf(seq, " Originator last-seen (#/%d) Nexthop [outgoingIF]: Potential nexthops ...\n",
BATADV_TQ_MAX_VALUE);
is probably trivially smaller overall code size too.
Your code, you decide...
cheers, Joe
^ permalink raw reply
* Re: [PATCH 03/16] batman-adv: add bat_orig_print API function
From: Antonio Quartulli @ 2013-10-23 17:18 UTC (permalink / raw)
To: Joe Perches; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1382547630.22433.23.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]
On Wed, Oct 23, 2013 at 10:00:30AM -0700, Joe Perches wrote:
> On Wed, 2013-10-23 at 18:04 +0200, Antonio Quartulli wrote:
> > Each routing protocol has its own metric and private
> > variables, therefore it is useful to introduce a new API
> > for originator information printing.
> >
> > This API needs to be implemented by each protocol in order
> > to provide its specific originator table output.
> []
> > +static void batadv_iv_ogm_orig_print(struct batadv_priv *bat_priv,
> > + struct seq_file *seq)
> []
> > + seq_printf(seq, " %-15s %s (%s/%i) %17s [%10s]: %20s ...\n",
> > + "Originator", "last-seen", "#", BATADV_TQ_MAX_VALUE,
> > + "Nexthop", "outgoingIF", "Potential nexthops");
>
> This header printf really doesn't add much with the formatting sizes.
> It's pretty obscure why some of these are sized and others not sized.
> For instance: %-15s doesn't refer to a mac address size.
> Perhaps it'd be better to just emit the fixed string just using
> BATADV_TO_MAX_VALUE. It'd also be easier to find via grep.
This string is printed out of a debugfs file and follows a format that we have
been using for long time (this patch is just moving this code from one point to
another).
I didn't get what you mean with BATADV_TO_MAX_VALUE (maybe you meant
BATADV_TQ_MAX_VALUE? but even in this case I don't get it).
The sized parameters in the format string are such that this header is correctly
aligned with the entries of the table that follow.
Moreover we tried to keep this table human readable as much as possible.
Here you have an example of what we get (this output is not printed with exactly
that format string because it belongs to an older batman-adv version)
[B.A.T.M.A.N. adv 2013.3.0, MainIF/MAC: mesh0/xx:xx:xx:xx:xx:xx (bat0)]
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...
yyyy 4.720s (247) yyyy [ mesh0]: aaaaa (221) bbbbbb (200)
aaaaa 4.270s (237) ddddd [ mesh0]: aaaa (195) vvvvvv (215)
bbbbbb 4.480s (248) cccccc [ mesh0]: bbbb (213) cccccc (200)
ccccc 0.480s (255) bbbbb [ mesh0]: cccc (217) dddddd (190)
dddddd 1.050s (223) dddddd [ mesh0]: dddddd (191) eeee (203)
If the width of your terminal is adequate you get a nice table which is rather
helpful for debugging purposes.
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] netfilter: x_tables: fix ordering of jumpstack allocation and table update
From: Eric Dumazet @ 2013-10-23 17:04 UTC (permalink / raw)
To: Will Deacon
Cc: David Laight, Pablo Neira Ayuso, netfilter-devel@vger.kernel.org,
davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <20131023163706.GA5117@mudshark.cambridge.arm.com>
On Wed, 2013-10-23 at 17:37 +0100, Will Deacon wrote:
> What I'm *not* 100% sure about is the table freeing path. There is a mutex
> there for removing the table from a list, but I'm not sure how we ensure
> that there are no parallel readers at that point.
Sequence is :
xt_replace_table();
get_counters();
xt_free_table_info();
get_counters() is the way we ensure no cpu is using old copy of the
table before freeing.
^ permalink raw reply
* Fwd: Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4
From: Wolfgang Walter @ 2013-10-23 17:01 UTC (permalink / raw)
To: netdev; +Cc: David Miller, hannes, klassert
Am Mittwoch, 23. Oktober 2013, 09:17:30 schrieben Sie:
> On Wed, 2013-10-23 at 17:57 +0200, Wolfgang Walter wrote:
> > Am Mittwoch, 23. Oktober 2013, 05:00:01 schrieb Eric Dumazet:
> > > On Wed, 2013-10-23 at 13:33 +0200, Wolfgang Walter wrote:
> > > > I don't know what this value actually means. But on 3.4.x it is much
> > > > higher. On a machine with 512MB ram it is 32768, on a machine with 1GB
> > > > ram it is 262144 and with 16GB ram it is 4194304.
> > >
> > > Such huge values should not be needed. We should have at most one dst
> > > per packet in flight.
> > >
> > > On a loaded router, a NIC not using BQL could queue around 16,000
> > > packets.
> > >
> > > Of course, Qdisc layers could also store a lot of packets, but using the
> > > default pfifo_fast is only adding 1000 packets per interface.
> > >
> > > I guess using 65536 as the default value should be safe and reasonable
> > >
> > > Have you tried using 32768 or 65536 ?
> >
> > I use 32768 on routers with 512MB. They usually have around 50
> > ipsec-tunnels and only about 10 interfaces including vlan-interfaces.
> >
> > On larger ones I set the bigger values from 3.4.x. That one with 16GB has
> > about 2000 ipsec-tunnels. It has about 80 interfaces (inlcuding vlan-
> > interfaces). Physically it has 8 interfaces with together about 30
> > hardware- queues.
>
> offlist
>
> OK, but you do not have the idea of actual number of entries ?
>
> If you use SLAB, you probably can try "grep dst /proc/slabinfo"
Ah, ok. I use SLUB, but SLABINFO=y.
Without much traffic it is:
# grep dst /proc/slabinfo
xfrm_dst_cache 4435 4608 448 36 4 : tunables 0 0 0 :
slabdata 128 128 0
on the big one.
I can recompile the kernels with SLAB instead of SLUB if SLAB gives more
usefull infos.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
^ permalink raw reply
* Re: [PATCH 03/16] batman-adv: add bat_orig_print API function
From: Joe Perches @ 2013-10-23 17:00 UTC (permalink / raw)
To: Antonio Quartulli
Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1382544303-2694-4-git-send-email-antonio@meshcoding.com>
On Wed, 2013-10-23 at 18:04 +0200, Antonio Quartulli wrote:
> Each routing protocol has its own metric and private
> variables, therefore it is useful to introduce a new API
> for originator information printing.
>
> This API needs to be implemented by each protocol in order
> to provide its specific originator table output.
[]
> +static void batadv_iv_ogm_orig_print(struct batadv_priv *bat_priv,
> + struct seq_file *seq)
[]
> + seq_printf(seq, " %-15s %s (%s/%i) %17s [%10s]: %20s ...\n",
> + "Originator", "last-seen", "#", BATADV_TQ_MAX_VALUE,
> + "Nexthop", "outgoingIF", "Potential nexthops");
This header printf really doesn't add much with the formatting sizes.
It's pretty obscure why some of these are sized and others not sized.
For instance: %-15s doesn't refer to a mac address size.
Perhaps it'd be better to just emit the fixed string just using
BATADV_TO_MAX_VALUE. It'd also be easier to find via grep.
^ 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