* Re: [PATCH net-next v2 2/2] openvswitch: remove unnecessary EXPORT_SYMBOLs
From: Pravin Shelar @ 2016-10-19 18:34 UTC (permalink / raw)
To: Jiri Benc; +Cc: ovs dev, Linux Kernel Network Developers
In-Reply-To: <4653b9825aa5e4047c4a91241dcafd1706171e80.1476869133.git.jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Wed, Oct 19, 2016 at 2:26 AM, Jiri Benc <jbenc@redhat.com> wrote:
> Some symbols exported to other modules are really used only by
> openvswitch.ko. Remove the exports.
>
> Tested by loading all 4 openvswitch modules, nothing breaks.
>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] openvswitch: remove unused functions
From: Pravin Shelar @ 2016-10-19 18:34 UTC (permalink / raw)
To: Jiri Benc; +Cc: ovs dev, Linux Kernel Network Developers
In-Reply-To: <75a1e9718357fe5c40948d4c3032c95278277587.1476869133.git.jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Wed, Oct 19, 2016 at 2:26 AM, Jiri Benc <jbenc@redhat.com> wrote:
> ovs_vport_deferred_free is not used anywhere. It's the only caller of
> free_vport_rcu thus this one can be removed, too.
>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* [Patch net] ipv6: fix a potential deadlock in do_ipv6_setsockopt()
From: Cong Wang @ 2016-10-19 18:20 UTC (permalink / raw)
To: netdev; +Cc: sploving1, Cong Wang, Marcelo Ricardo Leitner
Baozeng reported this deadlock case:
CPU0 CPU1
---- ----
lock([ 165.136033] sk_lock-AF_INET6);
lock([ 165.136033] rtnl_mutex);
lock([ 165.136033] sk_lock-AF_INET6);
lock([ 165.136033] rtnl_mutex);
Similar to commit 87e9f0315952
("ipv4: fix a potential deadlock in mcast getsockopt() path")
this is due to we still have a case, ipv6_sock_mc_close(),
where we acquire sk_lock before rtnl_lock. Close this deadlock
with the similar solution, that is always acquire rtnl lock first.
Fixes: baf606d9c9b1 ("ipv4,ipv6: grab rtnl before locking the socket")
Reported-by: Baozeng Ding <sploving1@gmail.com>
Tested-by: Baozeng Ding <sploving1@gmail.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/ipv6/af_inet6.c | 2 ++
net/ipv6/ipv6_sockglue.c | 1 +
net/ipv6/mcast.c | 4 ++--
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 46ad699..b8c8d20 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -414,7 +414,9 @@ int inet6_release(struct socket *sock)
return -EINVAL;
/* Free mc lists */
+ rtnl_lock();
ipv6_sock_mc_close(sk);
+ rtnl_unlock();
/* Free ac lists */
ipv6_sock_ac_close(sk);
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 5330262..1e4bcce 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -120,6 +120,7 @@ struct ipv6_txoptions *ipv6_update_options(struct sock *sk,
static bool setsockopt_needs_rtnl(int optname)
{
switch (optname) {
+ case IPV6_ADDRFORM:
case IPV6_ADD_MEMBERSHIP:
case IPV6_DROP_MEMBERSHIP:
case IPV6_JOIN_ANYCAST:
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 75c1fc5..41badfd 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -282,10 +282,11 @@ void ipv6_sock_mc_close(struct sock *sk)
struct ipv6_mc_socklist *mc_lst;
struct net *net = sock_net(sk);
+ ASSERT_RTNL();
+
if (!rcu_access_pointer(np->ipv6_mc_list))
return;
- rtnl_lock();
while ((mc_lst = rtnl_dereference(np->ipv6_mc_list)) != NULL) {
struct net_device *dev;
@@ -305,7 +306,6 @@ void ipv6_sock_mc_close(struct sock *sk)
kfree_rcu(mc_lst, rcu);
}
- rtnl_unlock();
}
int ip6_mc_source(int add, int omode, struct sock *sk,
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Dave Hansen @ 2016-10-19 17:23 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mips, linux-fbdev, Jan Kara, kvm, linux-sh, dri-devel,
linux-mm, netdev, sparclinux, linux-ia64, linux-s390,
linux-samsung-soc, linux-scsi, linux-rdma, x86, Hugh Dickins,
linux-media, Rik van Riel, intel-gfx, adi-buildroot-devel,
ceph-devel, linux-arm-kernel, Lorenzo Stoakes, linux-cris-kernel,
Linus Torvalds, linuxppc-dev, linux-kernel, linux-security-module,
linux-alpha, linux-fs
In-Reply-To: <20161019170127.GN24393@dhcp22.suse.cz>
On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm
The reason I chose not to do that was that deferred work gets run under
a basically random 'current'. If we just use 'mm != current->mm', then
the deferred work will sometimes have pkeys enforced and sometimes not,
basically randomly.
We want to be consistent with whether they are enforced or not, so we
explicitly indicate that by calling the remote variant vs. plain.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Michal Hocko @ 2016-10-19 17:01 UTC (permalink / raw)
To: Dave Hansen
Cc: Lorenzo Stoakes, linux-mm, Linus Torvalds, Jan Kara, Hugh Dickins,
Rik van Riel, Mel Gorman, Andrew Morton, adi-buildroot-devel,
ceph-devel, dri-devel, intel-gfx, kvm, linux-alpha,
linux-arm-kernel, linux-cris-kernel, linux-fbdev, linux-fsdevel,
linux-ia64, linux-kernel, linux-media, linux-mips, linux-rdma,
linux-s390, linux-samsung-soc, linux-scsi, linux-security-module,
linux-sh
In-Reply-To: <5807A427.7010200@linux.intel.com>
On Wed 19-10-16 09:49:43, Dave Hansen wrote:
> On 10/19/2016 02:07 AM, Michal Hocko wrote:
> > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> >>> I am wondering whether we can go further. E.g. it is not really clear to
> >>> me whether we need an explicit FOLL_REMOTE when we can in fact check
> >>> mm != current->mm and imply that. Maybe there are some contexts which
> >>> wouldn't work, I haven't checked.
> >>
> >> This flag is set even when /proc/self/mem is used. I've not looked deeply into
> >> this flag but perhaps accessing your own memory this way can be considered
> >> 'remote' since you're not accessing it directly. On the other hand, perhaps this
> >> is just mistaken in this case?
> >
> > My understanding of the flag is quite limited as well. All I know it is
> > related to protection keys and it is needed to bypass protection check.
> > See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
> > enforce PKEY permissions on remote mm access").
>
> Yeah, we need the flag to tell us when PKEYs should be applied or not.
> The current task's PKRU (pkey rights register) should really only be
> used to impact access to the task's memory, but has no bearing on how a
> given task should access remote memory.
The question I had earlier was whether this has to be an explicit FOLL
flag used by g-u-p users or we can just use it internally when mm !=
current->mm
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next v12 0/9] openvswitch: support for layer 3 encapsulated packets
From: Jiri Benc @ 2016-10-19 16:59 UTC (permalink / raw)
To: Pravin Shelar
Cc: Linux Kernel Network Developers, ovs dev, Lorand Jakab,
Simon Horman
In-Reply-To: <CAOrHB_AfMFsMbU+NNVX3q+OUntnJaBZX=O2MQTAsnnM2bxJqVA@mail.gmail.com>
On Tue, 18 Oct 2016 22:11:21 -0700, Pravin Shelar wrote:
> I have not finished the review yet, but most of patches looks good to
> me. Can you send userspace patches against latest master so that I can
> try the patches with tunnel setup?
Will do in a few minutes.
Thanks for the review,
Jiri
^ permalink raw reply
* Re: [PATCH net-next v12 9/9] openvswitch: use ipgre tunnel rather than gretap tunnel
From: Jiri Benc @ 2016-10-19 16:58 UTC (permalink / raw)
To: Pravin Shelar
Cc: Linux Kernel Network Developers, ovs dev, Lorand Jakab,
Simon Horman
In-Reply-To: <CAOrHB_AWT1zp_6wJMOP=2GdJGtgZ6yvt5ysf9gBBnGDKHU3BUA@mail.gmail.com>
On Tue, 18 Oct 2016 22:14:06 -0700, Pravin Shelar wrote:
> This is OVS tunnel compatibility code. We are not suppose to add new
> features to compat code. Just provide a way to configure such device
> over rtnl.
Makes sense. Please consider this a test-only patch for now. I won't
include it in v13.
rtnetlink already supports configuration of such devices, I added that
some time ago. We'll just need to make the user space aware of that.
But at the kernel side, just dropping this patch is enough.
Jiri
^ permalink raw reply
* Re: net/sctp: use-after-free in __sctp_connect
From: Marcelo Ricardo Leitner @ 2016-10-19 16:57 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, syzkaller, Kostya Serebryany, Alexander Potapenko,
Sasha Levin, Eric Dumazet, Dmitry Vyukov
In-Reply-To: <CAAeHK+wX8yxVTpmg-Ps7MKTD-x_HS3GgpzX6yfGh51cQE0oPjA@mail.gmail.com>
On Wed, Oct 19, 2016 at 02:25:24PM +0200, Andrey Konovalov wrote:
> Hi,
>
> I've got the following error report while running the syzkaller fuzzer:
>
> ==================================================================
> BUG: KASAN: use-after-free in __sctp_connect+0xabe/0xbf0 at addr
> ffff88006b1dc610
Seems this is the same that Dmitry Vyukov had reported back in Jan 13th.
So far I couldn't identify the reason.
"Good" to know it's still there, thanks for reporting it.
^ permalink raw reply
* Re: [PATCH net-next v12 5/9] openvswitch: add processing of L3 packets
From: Jiri Benc @ 2016-10-19 16:52 UTC (permalink / raw)
To: Pravin Shelar
Cc: Linux Kernel Network Developers, ovs dev, Lorand Jakab,
Simon Horman
In-Reply-To: <CAOrHB_B1-29CM=DWpWuRVbTRriW2ViJRZULMS22+NSPwW_J_=Q@mail.gmail.com>
On Tue, 18 Oct 2016 22:13:45 -0700, Pravin Shelar wrote:
> On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc <jbenc@redhat.com> wrote:
> > - skb_reset_network_header(skb);
> > + skb->protocol = parse_ethertype(skb);
>
> I am not sure about changing skb->protocol here.
> By changing this skb loosing information about packet type. Therefore
> if packet re-enters OVS (through different bridge), this packet would
> look like L3 packet. function key_extract_mac_proto() would not see
> TEB type packet.
This should be okay. If the packet is sent out to an Ethernet interface
(whatever interface it is), skb->protocol needs to contain the payload
type. We're not interested in ETH_P_TEB. If the packet is sent out to
an ARPHRD_NONE interface, ETH_P_TEB is pushed back.
Basically, what we're doing here is unconditionally converting
ETH_P_TEB packets *coming from ARPHRD_NONE interfaces* (this is
important) into regular Ethernet packets. Which is exactly what we want.
Am I missing something?
Jiri
^ permalink raw reply
* Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Dave Hansen @ 2016-10-19 16:49 UTC (permalink / raw)
To: Michal Hocko, Lorenzo Stoakes
Cc: linux-mm, Linus Torvalds, Jan Kara, Hugh Dickins, Rik van Riel,
Mel Gorman, Andrew Morton, adi-buildroot-devel, ceph-devel,
dri-devel, intel-gfx, kvm, linux-alpha, linux-arm-kernel,
linux-cris-kernel, linux-fbdev, linux-fsdevel, linux-ia64,
linux-kernel, linux-media, linux-mips, linux-rdma, linux-s390,
linux-samsung-soc, linux-scsi
In-Reply-To: <20161019090727.GE7517@dhcp22.suse.cz>
On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in fact check
>>> mm != current->mm and imply that. Maybe there are some contexts which
>>> wouldn't work, I haven't checked.
>>
>> This flag is set even when /proc/self/mem is used. I've not looked deeply into
>> this flag but perhaps accessing your own memory this way can be considered
>> 'remote' since you're not accessing it directly. On the other hand, perhaps this
>> is just mistaken in this case?
>
> My understanding of the flag is quite limited as well. All I know it is
> related to protection keys and it is needed to bypass protection check.
> See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
> enforce PKEY permissions on remote mm access").
Yeah, we need the flag to tell us when PKEYs should be applied or not.
The current task's PKRU (pkey rights register) should really only be
used to impact access to the task's memory, but has no bearing on how a
given task should access remote memory.
^ permalink raw reply
* Re: net/ipv6: potential deadlock in do_ipv6_setsockopt
From: Cong Wang @ 2016-10-19 16:36 UTC (permalink / raw)
To: Baozeng Ding; +Cc: Linux Kernel Network Developers
In-Reply-To: <6e9dbe30-ec0f-07cb-0e16-d86eb4bc480f@gmail.com>
On Wed, Oct 19, 2016 at 12:45 AM, Baozeng Ding <sploving1@gmail.com> wrote:
> It fixes the issue for me.
> Tested-by: Baozeng Ding <sploving1@gmail.com>
Thanks for testing, I will send out the patch formally very soon.
BTW, you can check mailing archive to see if your email succeeds or not,
for example, http://marc.info/?l=linux-netdev
^ permalink raw reply
* [PATCH net v2] net: add recursion limit to GRO
From: Sabrina Dubroca @ 2016-10-19 16:29 UTC (permalink / raw)
To: netdev; +Cc: Hannes Frederic Sowa, Jiri Benc, Sabrina Dubroca, Eric Dumazet
Currently, GRO can do unlimited recursion through the gro_receive
handlers. This was fixed for tunneling protocols by limiting tunnel GRO
to one level with encap_mark, but both VLAN and TEB still have this
problem. Thus, the kernel is vulnerable to a stack overflow, if we
receive a packet composed entirely of VLAN headers.
This patch adds a recursion counter to the GRO layer to prevent stack
overflow. When a gro_receive function hits the recursion limit, GRO is
aborted for this skb and it is processed normally. This recursion
counter is put in the GRO CB, but could be turned into a percpu counter
if we run out of space in the CB.
Thanks to Vladimír Beneš <vbenes@redhat.com> for the initial bug report.
Fixes: CVE-2016-7039
Fixes: 9b174d88c257 ("net: Add Transparent Ethernet Bridging GRO support.")
Fixes: 66e5133f19e9 ("vlan: Add GRO support for non hardware accelerated vlan")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
v2: add unlikely() annotations, suggested by Eric Dumazet
benchmark didn't show a difference between CB and pcpu variable for
the recursion counter, so I'm sticking with the CB
drivers/net/geneve.c | 2 +-
drivers/net/vxlan.c | 2 +-
include/linux/netdevice.h | 24 +++++++++++++++++++++++-
net/8021q/vlan.c | 2 +-
net/core/dev.c | 1 +
net/ethernet/eth.c | 2 +-
net/ipv4/af_inet.c | 2 +-
net/ipv4/fou.c | 4 ++--
net/ipv4/gre_offload.c | 2 +-
net/ipv4/udp_offload.c | 8 +++++++-
net/ipv6/ip6_offload.c | 2 +-
11 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 3c20e87bb761..16af1ce99233 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -453,7 +453,7 @@ static struct sk_buff **geneve_gro_receive(struct sock *sk,
skb_gro_pull(skb, gh_len);
skb_gro_postpull_rcsum(skb, gh, gh_len);
- pp = ptype->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ptype->callbacks.gro_receive, head, skb);
flush = 0;
out_unlock:
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index e7d16687538b..c1639a3e95a4 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -583,7 +583,7 @@ static struct sk_buff **vxlan_gro_receive(struct sock *sk,
}
}
- pp = eth_gro_receive(head, skb);
+ pp = call_gro_receive(eth_gro_receive, head, skb);
flush = 0;
out:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 465e128699a1..6db3cb56daab 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2169,7 +2169,10 @@ struct napi_gro_cb {
/* Used to determine if flush_id can be ignored */
u8 is_atomic:1;
- /* 5 bit hole */
+ /* Number of gro_receive callbacks this packet already went through */
+ u8 recursion_counter:4;
+
+ /* 1 bit hole */
/* used to support CHECKSUM_COMPLETE for tunneling protocols */
__wsum csum;
@@ -2180,6 +2183,25 @@ struct napi_gro_cb {
#define NAPI_GRO_CB(skb) ((struct napi_gro_cb *)(skb)->cb)
+#define GRO_RECURSION_LIMIT 15
+static inline int gro_recursion_inc_test(struct sk_buff *skb)
+{
+ return ++NAPI_GRO_CB(skb)->recursion_counter == GRO_RECURSION_LIMIT;
+}
+
+typedef struct sk_buff **(*gro_receive_t)(struct sk_buff **, struct sk_buff *);
+static inline struct sk_buff **call_gro_receive(gro_receive_t cb,
+ struct sk_buff **head,
+ struct sk_buff *skb)
+{
+ if (unlikely(gro_recursion_inc_test(skb))) {
+ NAPI_GRO_CB(skb)->flush |= 1;
+ return NULL;
+ }
+
+ return cb(head, skb);
+}
+
struct packet_type {
__be16 type; /* This is really htons(ether_type). */
struct net_device *dev; /* NULL is wildcarded here */
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 8de138d3306b..f2531ad66b68 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -664,7 +664,7 @@ static struct sk_buff **vlan_gro_receive(struct sk_buff **head,
skb_gro_pull(skb, sizeof(*vhdr));
skb_gro_postpull_rcsum(skb, vhdr, sizeof(*vhdr));
- pp = ptype->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ptype->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
diff --git a/net/core/dev.c b/net/core/dev.c
index b09ac57f4348..dbc871306910 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4511,6 +4511,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
NAPI_GRO_CB(skb)->flush = 0;
NAPI_GRO_CB(skb)->free = 0;
NAPI_GRO_CB(skb)->encap_mark = 0;
+ NAPI_GRO_CB(skb)->recursion_counter = 0;
NAPI_GRO_CB(skb)->is_fou = 0;
NAPI_GRO_CB(skb)->is_atomic = 1;
NAPI_GRO_CB(skb)->gro_remcsum_start = 0;
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 66dff5e3d772..02acfff36028 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -439,7 +439,7 @@ struct sk_buff **eth_gro_receive(struct sk_buff **head,
skb_gro_pull(skb, sizeof(*eh));
skb_gro_postpull_rcsum(skb, eh, sizeof(*eh));
- pp = ptype->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ptype->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 1effc986739e..9648c97e541f 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1391,7 +1391,7 @@ struct sk_buff **inet_gro_receive(struct sk_buff **head, struct sk_buff *skb)
skb_gro_pull(skb, sizeof(*iph));
skb_set_transport_header(skb, skb_gro_offset(skb));
- pp = ops->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ops->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index cf50f7e2b012..030d1531e897 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -249,7 +249,7 @@ static struct sk_buff **fou_gro_receive(struct sock *sk,
if (!ops || !ops->callbacks.gro_receive)
goto out_unlock;
- pp = ops->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ops->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
@@ -441,7 +441,7 @@ static struct sk_buff **gue_gro_receive(struct sock *sk,
if (WARN_ON_ONCE(!ops || !ops->callbacks.gro_receive))
goto out_unlock;
- pp = ops->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ops->callbacks.gro_receive, head, skb);
flush = 0;
out_unlock:
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index 96e0efecefa6..d5cac99170b1 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -229,7 +229,7 @@ static struct sk_buff **gre_gro_receive(struct sk_buff **head,
/* Adjusted NAPI_GRO_CB(skb)->csum after skb_gro_pull()*/
skb_gro_postpull_rcsum(skb, greh, grehlen);
- pp = ptype->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ptype->callbacks.gro_receive, head, skb);
flush = 0;
out_unlock:
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index f9333c963607..cbde0bc37c02 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -295,7 +295,13 @@ struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb,
skb_gro_pull(skb, sizeof(struct udphdr)); /* pull encapsulating udp header */
skb_gro_postpull_rcsum(skb, uh, sizeof(struct udphdr));
- pp = udp_sk(sk)->gro_receive(sk, head, skb);
+
+ if (unlikely(gro_recursion_inc_test(skb))) {
+ flush = 1;
+ pp = NULL;
+ } else {
+ pp = udp_sk(sk)->gro_receive(sk, head, skb);
+ }
out_unlock:
rcu_read_unlock();
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index e7bfd55899a3..1fcf61f1cbc3 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -246,7 +246,7 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
skb_gro_postpull_rcsum(skb, iph, nlen);
- pp = ops->callbacks.gro_receive(head, skb);
+ pp = call_gro_receive(ops->callbacks.gro_receive, head, skb);
out_unlock:
rcu_read_unlock();
--
2.10.0
^ permalink raw reply related
* Re: [PATCH net] net: core: Correctly iterate over lower adjacency list
From: David Miller @ 2016-10-19 16:28 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, eladr, yotamg, nogahf, ogerlitz, dsa, idosch
In-Reply-To: <20161019153627.GA28249@splinter>
From: Ido Schimmel <idosch@idosch.org>
Date: Wed, 19 Oct 2016 18:36:27 +0300
> Below the patch I noted "Please consider queueing this for 4.8.y", but
> you didn't reply and I don't see it here:
> https://patchwork.ozlabs.org/bundle/davem/stable/?state=*
>
> So I'm not sure if this was rejected or you just missed my note.
Sorry, I thought I added it, should be fixes now.
Thanks.
^ permalink raw reply
* Re: [PATCH net] conntrack: restart gc immediately if GC_MAX_EVICTS is reached
From: Pablo Neira Ayuso @ 2016-10-19 16:14 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: fw, davem, netdev, netfilter-devel
In-Reply-To: <1476794252-12398-1-git-send-email-nicolas.dichtel@6wind.com>
On Tue, Oct 18, 2016 at 02:37:32PM +0200, Nicolas Dichtel wrote:
> When the maximum evictions number is reached, do not wait 5 seconds before
> the next run.
Applied, thanks Nicolas.
^ permalink raw reply
* Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers
From: Sabrina Dubroca @ 2016-10-19 16:05 UTC (permalink / raw)
To: Jarod Wilson
Cc: linux-kernel, netdev, Stefan Richter, Faisal Latif, linux-rdma,
Cliff Whickman, Robin Holt, Jes Sorensen, Marek Lindner,
Simon Wunderlich, Antonio Quartulli
In-Reply-To: <20161019023333.15760-7-jarod@redhat.com>
2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
[...]
> diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
> index 309311b..b5f125c 100644
> --- a/drivers/firewire/net.c
> +++ b/drivers/firewire/net.c
> @@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
> return NETDEV_TX_OK;
> }
>
> -static int fwnet_change_mtu(struct net_device *net, int new_mtu)
> -{
> - if (new_mtu < 68)
> - return -EINVAL;
> -
> - net->mtu = new_mtu;
> - return 0;
> -}
> -
This doesn't do any upper bound checking.
> static const struct ethtool_ops fwnet_ethtool_ops = {
> .get_link = ethtool_op_get_link,
> };
> @@ -1366,7 +1357,6 @@ static const struct net_device_ops fwnet_netdev_ops = {
> .ndo_open = fwnet_open,
> .ndo_stop = fwnet_stop,
> .ndo_start_xmit = fwnet_tx,
> - .ndo_change_mtu = fwnet_change_mtu,
> };
>
> static void fwnet_init_dev(struct net_device *net)
> @@ -1481,6 +1471,8 @@ static int fwnet_probe(struct fw_unit *unit,
> max_mtu = (1 << (card->max_receive + 1))
> - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> net->mtu = min(1500U, max_mtu);
> + net->min_mtu = ETH_MIN_MTU;
> + net->max_mtu = net->mtu;
But that will now prevent increasing the MTU above the initial value?
--
Sabrina
^ permalink raw reply
* Re: [PATCH net] conntrack: restart gc immediately if GC_MAX_EVICTS is reached
From: Florian Westphal @ 2016-10-19 16:02 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: pablo, fw, davem, netdev, netfilter-devel
In-Reply-To: <1476794252-12398-1-git-send-email-nicolas.dichtel@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> When the maximum evictions number is reached, do not wait 5 seconds before
> the next run.
>
> CC: Florian Westphal <fw@strlen.de>
Acked-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
From: Johannes Berg @ 2016-10-19 16:00 UTC (permalink / raw)
To: Ben Greear, Ard Biesheuvel
Cc: Herbert Xu, Andy Lutomirski, Sergey Senozhatsky,
<netdev@vger.kernel.org>, David S. Miller,
<linux-wireless@vger.kernel.org>,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <5807984D.4050307@candelatech.com>
On Wed, 2016-10-19 at 08:59 -0700, Ben Greear wrote:
>
> Do you actually expect performance regressions? I'll be complaining
> if so, but will test first :)
I think we can expect this to use a bit more CPU time, but unless
you're very tight on that you probably shouldn't expect any throughput
difference.
johannes
^ permalink raw reply
* Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
From: Ben Greear @ 2016-10-19 15:59 UTC (permalink / raw)
To: Ard Biesheuvel, Johannes Berg
Cc: Herbert Xu, Andy Lutomirski, Sergey Senozhatsky,
<netdev@vger.kernel.org>, David S. Miller,
<linux-wireless@vger.kernel.org>,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <CAKv+Gu9CppR+AN5_RdDJ6ZBRr1EDDLB+nABPddyaj5TKb5=j_Q@mail.gmail.com>
On 10/19/2016 08:08 AM, Ard Biesheuvel wrote:
> On 19 October 2016 at 08:43, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote:
>> We could probably make mac80211 do that too, but can we guarantee in-
>> order processing? Anyway, it's pretty low priority, maybe never
>> happening, since hardly anyone really uses "software" crypto, the wifi
>> devices mostly have it built in anyway.
>>
>
> Indeed. The code is now correct in terms of API requirements, so let's
> just wait for someone to complain about any performance regressions.
Do you actually expect performance regressions? I'll be complaining if
so, but will test first :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Useless debug warning "netlink: 16 bytes leftover after parsing attributes"
From: Nicolas Dichtel @ 2016-10-19 15:50 UTC (permalink / raw)
To: Marcel Holtmann, Network Development; +Cc: Michal Schmidt
In-Reply-To: <0756CFFC-5BF7-4685-A1E2-0D88B2898454@holtmann.org>
Le 18/10/2016 à 07:06, Marcel Holtmann a écrit :
> Hi,
>
> so lately I am seeing a bunch of these warnings:
>
> netlink: 16 bytes leftover after parsing attributes..
>
> While they give you the process name, they are still useless to track down the message that causes them. I find them even more useless since an updated userspace on an older kernel can trigger the nla_policy warning here. And that updated userspace program is doing nothing wrong by including extra attributes. So what purpose is this warning serving?
Usually, it means that a netlink message is malformed, for example that the
header of the family has the wrong size. An unknown attribute should not trigger
this kind of message.
Here is an example:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e5eca6d41f53d
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH net-next 4/6] net: use core MTU range checking in core net infra
From: Jarod Wilson @ 2016-10-19 15:46 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: linux-kernel, netdev, Nicolas Dichtel, Hannes Frederic Sowa,
Tom Herbert, Daniel Borkmann, Alexander Duyck, Paolo Abeni,
Jiri Benc, WANG Cong, Roopa Prabhu, Pravin B Shelar,
Patrick McHardy, Stephen Hemminger, Pravin Shelar
In-Reply-To: <20161019152759.GB11224@bistromath.localdomain>
On Wed, Oct 19, 2016 at 05:28:00PM +0200, Sabrina Dubroca wrote:
> 2016-10-19, 10:40:06 -0400, Jarod Wilson wrote:
> > On Wed, Oct 19, 2016 at 03:55:29PM +0200, Sabrina Dubroca wrote:
> > > 2016-10-18, 22:33:31 -0400, Jarod Wilson wrote:
...
> > I'm thinking more and more that we ought to back out the patch that sets
> > min/max in ether_setup, save it for last, after we're sure everyone that
> > calls it has been prepared.
>
> I'm not sure how that would work now, if some of the patches that
> already went in for ethernet drivers assume that ether_setup will
> configure a basic {min,max}_mtu pair (at least e100 makes that
> assumption, but that might be the only one).
Argh. Yeah. Hrm. Would have to do the revert *and* have e100 and possibly
others set their own min/max pair. So I guess it's a race to fix all the
fallout... Crap.
> > > [...]
> > > > diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
> > > > index 89a687f..81fc79a 100644
> > > > --- a/net/bridge/br_device.c
> > > > +++ b/net/bridge/br_device.c
> > > > @@ -184,17 +184,15 @@ static struct rtnl_link_stats64 *br_get_stats64(struct net_device *dev,
> > > >
> > > > static int br_change_mtu(struct net_device *dev, int new_mtu)
> > > > {
> > > > +#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
> > > > struct net_bridge *br = netdev_priv(dev);
> > > > - if (new_mtu < 68 || new_mtu > br_min_mtu(br))
> > > > - return -EINVAL;
> > > > -
> > > > - dev->mtu = new_mtu;
> > > >
> > > > -#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
> > > > /* remember the MTU in the rtable for PMTU */
> > > > dst_metric_set(&br->fake_rtable.dst, RTAX_MTU, new_mtu);
> > > > #endif
> > > >
> > > > + dev->mtu = new_mtu;
> > > > +
> > > > return 0;
> > > > }
> > > >
> > > > @@ -390,6 +388,7 @@ void br_dev_setup(struct net_device *dev)
> > > > dev->hw_features = COMMON_FEATURES | NETIF_F_HW_VLAN_CTAG_TX |
> > > > NETIF_F_HW_VLAN_STAG_TX;
> > > > dev->vlan_features = COMMON_FEATURES;
> > > > + dev->max_mtu = br_min_mtu(br);
> > >
> > > br_min_mtu uses br->port_list, which is only initialized a few lines
> > > later (right after the spin_lock_init() at the end of the context of
> > > this diff).
> >
> > Ah, okay, I'd just grouped it with the other dev->foo settings.
> >
> > > Besides, I don't think this works: br_min_mtu(br) changes when you add
> > > and remove ports, or when you change the MTU of an enslaved
> > > device. But this makes the max MTU for the bridge fixed (to 1500).
> >
> > Okay, how about this: set no max_mtu (or set it to IP_MAX_MTU/65535), and
> > then retain a check against the possibly ever-changing br_min_mtu(br) in
> > br_change_mtu()?
>
> Sounds good to me.
I think I have something here locally that looks sane. Working on a few
other similar cases now.
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [PATCH net] net: core: Correctly iterate over lower adjacency list
From: Ido Schimmel @ 2016-10-19 15:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jiri, eladr, yotamg, nogahf, ogerlitz, dsa, idosch
In-Reply-To: <20161019.103829.1873231752009765175.davem@davemloft.net>
Hi Dave,
On Wed, Oct 19, 2016 at 10:38:29AM -0400, David Miller wrote:
> From: idosch@idosch.org
> Date: Wed, 19 Oct 2016 16:57:08 +0300
>
> > From: Ido Schimmel <idosch@mellanox.com>
> >
> > Tamir reported the following trace when processing ARP requests received
> > via a vlan device on top of a VLAN-aware bridge:
> ...
> > The problem is that netdev_all_lower_get_next_rcu() never advances the
> > iterator, thereby causing the loop over the lower adjacency list to run
> > forever.
> >
> > Fix this by advancing the iterator and avoid the infinite loop.
> >
> > Fixes: 7ce856aaaf13 ("mlxsw: spectrum: Add couple of lower device helper functions")
> > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> > Reported-by: Tamir Winetroub <tamirw@mellanox.com>
> > Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>
> Applied.
Below the patch I noted "Please consider queueing this for 4.8.y", but
you didn't reply and I don't see it here:
https://patchwork.ozlabs.org/bundle/davem/stable/?state=*
So I'm not sure if this was rejected or you just missed my note.
Thanks
^ permalink raw reply
* Re: [PATCH net v2] flow_dissector: Check skb for VLAN only if skb specified.
From: Amir Vadai @ 2016-10-19 8:44 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Eric Garver, David Miller, Linux Netdev List, Hadar Hen Zion
In-Reply-To: <CAJ3xEMiR3EODEV5aQ9cQG=7YZtVfFkbpHn79_j+s8H7XQ5F0rA@mail.gmail.com>
On Tue, Oct 18, 2016 at 4:59 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Mon, Oct 17, 2016 at 11:30 PM, Eric Garver <e@erig.me> wrote:
>> Fixes a panic when calling eth_get_headlen(). Noticed on i40e driver.
>>
>> Fixes: d5709f7ab776 ("flow_dissector: For stripped vlan, get vlan info from skb->vlan_tci")
>> Signed-off-by: Eric Garver <e@erig.me>
>
> Dave,
>
> Hadar is OOO and I have asked Amir to look on the fix, will appreciate
> if we can have 24 hours to respond
>
> Or.
Reviewed and tested.
Acked-by: Amir Vadai <amir@vadai.me>
^ permalink raw reply
* Re: [PATCH net-next 4/6] net: use core MTU range checking in core net infra
From: Sabrina Dubroca @ 2016-10-19 15:28 UTC (permalink / raw)
To: Jarod Wilson
Cc: linux-kernel, netdev, Nicolas Dichtel, Hannes Frederic Sowa,
Tom Herbert, Daniel Borkmann, Alexander Duyck, Paolo Abeni,
Jiri Benc, WANG Cong, Roopa Prabhu, Pravin B Shelar,
Patrick McHardy, Stephen Hemminger, Pravin Shelar
In-Reply-To: <20161019144006.GF18569@redhat.com>
2016-10-19, 10:40:06 -0400, Jarod Wilson wrote:
> On Wed, Oct 19, 2016 at 03:55:29PM +0200, Sabrina Dubroca wrote:
> > 2016-10-18, 22:33:31 -0400, Jarod Wilson wrote:
> > > geneve:
> > > - Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu
> > > - This one isn't quite as straight-forward as others, could use some
> > > closer inspection and testing
> > >
> > > macvlan:
> > > - set min/max_mtu
> > >
> > > tun:
> > > - set min/max_mtu, remove tun_net_change_mtu
> > >
> > > vxlan:
> > > - Merge __vxlan_change_mtu back into vxlan_change_mtu, set min/max_mtu
> > > - This one is also not as straight-forward and could use closer inspection
> > > and testing from vxlan folks
> > >
> > > bridge:
> > > - set max_mtu via br_min_mtu()
> > >
> > > openvswitch:
> > > - set min/max_mtu, remove internal_dev_change_mtu
> > > - note: max_mtu wasn't checked previously, it's been set to 65535, which
> > > is the largest possible size supported
> > >
> > > sch_teql:
> > > - set min/max_mtu (note: max_mtu previously unchecked, used max of 65535)
> >
> > Nothing for other virtual netdevices? (dummy, veth, bond, etc) Their
> > MTU is limited to 1500 now. Also missing macsec and ip_gre, probably
> > others that are using ether_setup.
>
> Yeah, I've clearly missed more than I thought. Doing another sweep now.
Thanks.
> I'm thinking more and more that we ought to back out the patch that sets
> min/max in ether_setup, save it for last, after we're sure everyone that
> calls it has been prepared.
I'm not sure how that would work now, if some of the patches that
already went in for ethernet drivers assume that ether_setup will
configure a basic {min,max}_mtu pair (at least e100 makes that
assumption, but that might be the only one).
> > [...]
> > > diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
> > > index 89a687f..81fc79a 100644
> > > --- a/net/bridge/br_device.c
> > > +++ b/net/bridge/br_device.c
> > > @@ -184,17 +184,15 @@ static struct rtnl_link_stats64 *br_get_stats64(struct net_device *dev,
> > >
> > > static int br_change_mtu(struct net_device *dev, int new_mtu)
> > > {
> > > +#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
> > > struct net_bridge *br = netdev_priv(dev);
> > > - if (new_mtu < 68 || new_mtu > br_min_mtu(br))
> > > - return -EINVAL;
> > > -
> > > - dev->mtu = new_mtu;
> > >
> > > -#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
> > > /* remember the MTU in the rtable for PMTU */
> > > dst_metric_set(&br->fake_rtable.dst, RTAX_MTU, new_mtu);
> > > #endif
> > >
> > > + dev->mtu = new_mtu;
> > > +
> > > return 0;
> > > }
> > >
> > > @@ -390,6 +388,7 @@ void br_dev_setup(struct net_device *dev)
> > > dev->hw_features = COMMON_FEATURES | NETIF_F_HW_VLAN_CTAG_TX |
> > > NETIF_F_HW_VLAN_STAG_TX;
> > > dev->vlan_features = COMMON_FEATURES;
> > > + dev->max_mtu = br_min_mtu(br);
> >
> > br_min_mtu uses br->port_list, which is only initialized a few lines
> > later (right after the spin_lock_init() at the end of the context of
> > this diff).
>
> Ah, okay, I'd just grouped it with the other dev->foo settings.
>
> > Besides, I don't think this works: br_min_mtu(br) changes when you add
> > and remove ports, or when you change the MTU of an enslaved
> > device. But this makes the max MTU for the bridge fixed (to 1500).
>
> Okay, how about this: set no max_mtu (or set it to IP_MAX_MTU/65535), and
> then retain a check against the possibly ever-changing br_min_mtu(br) in
> br_change_mtu()?
Sounds good to me.
--
Sabrina
^ permalink raw reply
* Re: [Patch net-next 2/2] netns: avoid disabling irq for netns id
From: Elad Raz @ 2016-10-19 15:21 UTC (permalink / raw)
To: nicolas.dichtel, Cong Wang, davem
Cc: Linux Netdev List, Jiri Pirko, Ido Schimmel, Yotam Gigi
In-Reply-To: <7de98923-0cfb-5937-d32b-bdaee7ec10dc@6wind.com>
On Fri, Sep 2, 2016 at 11:12 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> Le 02/09/2016 à 06:53, Cong Wang a écrit :
>> We never read or change netns id in hardirq context,
>> the only place we read netns id in softirq context
>> is in vxlan_xmit(). So, it should be enough to just
>> disable BH.
>
> Are you sure? Did you audit all part of the code?
> peernet2id() is called from netlink core system (do_one_broadcast()). Are you
> sure that no driver call this function from an hard irq context?
>
> I think that NETLINK_LISTEN_ALL_NSID is largely untested, so it will be hard to
> detect a bug introduced in this feature.
I'm seeing strange things on our systems on boot time when trying to
mount autofs.
I bisected and got this patch as the bad one.
I can see that only when I'm using "debug" config file.
CONFIG_LOCKDEP =y I can see on boot:
[ OK ] Started OpenSSH server daemon.
Starting OpenSSH server daemon...
[ 23.498577] ------------[ cut here ]------------
[ 23.503247] WARNING: CPU: 0 PID: 994 at kernel/softirq.c:150
__local_bh_enable_ip+0x9d/0xc0
[ 23.511665] Modules linked in: xt_conntrack ebtable_nat
ebtable_broute bridge stp llc ebtable_filter ebtables iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_mangle iptable_security iptable_raw intel_rapl
x86_pkg_temp_thermal iTCO
_wdt coretemp iTCO_vendor_support kvm_intel kvm irqbypass
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcspkr i2c_i801
i2c_smbus lpc_ich mfd_core mei_me mei video tpm_tis tpm_tis_core tpm
nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c crc32c_intel
e1000e
ptp pps_core
[ 23.561125] CPU: 0 PID: 994 Comm: setsebool Not tainted 4.8.0-rc4eladr+ #51
[ 23.568152] Hardware name: Mellanox Technologies Ltd. Mellanox
switch/Mellanox switch, BIOS 4.6.5 05/21/2015
[ 23.578066] 0000000000000000 ffff8801161d3bb0 ffffffff81411b73
0000000000000000
[ 23.585594] 0000000000000000 ffff8801161d3bf0 ffffffff810aa69b
00000096816dcda7
[ 23.593118] 0000000000000200 ffffffff816dcdc5 ffffffff81f0fb00
ffff8801147a0000
[ 23.600639] Call Trace:
[ 23.603114] [<ffffffff81411b73>] dump_stack+0x85/0xc2
[ 23.608302] [<ffffffff810aa69b>] __warn+0xcb/0xf0
[ 23.613138] [<ffffffff816dcdc5>] ? peernet2id+0x45/0x60
[ 23.618502] [<ffffffff810aa78d>] warn_slowpath_null+0x1d/0x20
[ 23.624394] [<ffffffff810b0a4d>] __local_bh_enable_ip+0x9d/0xc0
[ 23.630453] [<ffffffff8183e845>] _raw_spin_unlock_bh+0x35/0x40
[ 23.636432] [<ffffffff816dcdc5>] peernet2id+0x45/0x60
[ 23.641626] [<ffffffff81727ac5>] netlink_broadcast_filtered+0x265/0x3d0
[ 23.648385] [<ffffffff81727c4d>] netlink_broadcast+0x1d/0x20
[ 23.654188] [<ffffffff81165b21>] audit_log_end+0x2b1/0x2c0
[ 23.659820] [<ffffffff811658a0>] ? audit_log_end+0x30/0x2c0
[ 23.665532] [<ffffffff8116631a>] audit_log+0x5a/0x70
[ 23.670631] [<ffffffff813ab7ce>] security_set_bools+0xee/0x200
[ 23.676602] [<ffffffff8139cbc8>] sel_commit_bools_write+0xb8/0x100
[ 23.682928] [<ffffffff8126c1d8>] __vfs_write+0x28/0x120
[ 23.688291] [<ffffffff810fcc17>] ? update_fast_ctr+0x17/0x30
[ 23.694087] [<ffffffff810fcca9>] ? percpu_down_read+0x49/0x90
[ 23.699980] [<ffffffff81270567>] ? __sb_start_write+0xb7/0xf0
[ 23.705872] [<ffffffff81270567>] ? __sb_start_write+0xb7/0xf0
[ 23.711758] [<ffffffff8126d338>] vfs_write+0xb8/0x1b0
[ 23.716949] [<ffffffff81100e09>] ? trace_hardirqs_on_caller+0x129/0x1b0
[ 23.723717] [<ffffffff8126e689>] SyS_write+0x49/0xa0
[ 23.728828] [<ffffffff8183ef3c>] entry_SYSCALL_64_fastpath+0x1f/0xbd
[ 23.735337] ---[ end trace 576457efb89c3ea5 ]---
and
Starting NIS/YP (Network Informatio... Clients to NIS Domain Binder...
[ 24.182895] FS-Cache: Netfs 'nfs' registered for caching
[ OK ] Started rolekit - role server.
[ 24.210512] Key type dns_resolver registered
[ 24.243061] NFS: Registering the id_resolver key type
[ 24.253951] Key type id_resolver registered
[ 24.258215] Key type id_legacy registered
[ 24.272025]
[ 24.273545] =================================
[ 24.277919] [ INFO: inconsistent lock state ]
[ 24.282348] 4.8.0-rc4eladr+ #51 Tainted: G W
[ 24.287806] ---------------------------------
[ 24.292234] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-R} usage.
[ 24.298301] dbus-daemon/673 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 24.303898] (policy_rwlock){+++?..}, at: [<ffffffff813ac742>]
security_netlbl_sid_to_secattr+0x32/0xc0
[ 24.313456] {SOFTIRQ-ON-W} state was registered at:
[ 24.318388] [<ffffffff81100caf>] mark_held_locks+0x6f/0xa0
[ 24.324134] [<ffffffff81100e09>] trace_hardirqs_on_caller+0x129/0x1b0
[ 24.330900] [<ffffffff81100e9d>] trace_hardirqs_on+0xd/0x10
[ 24.336708] [<ffffffff810b0a20>] __local_bh_enable_ip+0x70/0xc0
[ 24.342912] [<ffffffff8183e845>] _raw_spin_unlock_bh+0x35/0x40
[ 24.349005] [<ffffffff816dcdc5>] peernet2id+0x45/0x60
[ 24.354361] [<ffffffff81727ac5>] netlink_broadcast_filtered+0x265/0x3d0
[ 24.361285] [<ffffffff81727c4d>] netlink_broadcast+0x1d/0x20
[ 24.367222] [<ffffffff81165b21>] audit_log_end+0x2b1/0x2c0
[ 24.372957] [<ffffffff8116631a>] audit_log+0x5a/0x70
[ 24.378174] [<ffffffff813ab7ce>] security_set_bools+0xee/0x200
[ 24.384283] [<ffffffff8139cbc8>] sel_commit_bools_write+0xb8/0x100
[ 24.390733] [<ffffffff8126c1d8>] __vfs_write+0x28/0x120
[ 24.396208] [<ffffffff8126d338>] vfs_write+0xb8/0x1b0
[ 24.401537] [<ffffffff8126e689>] SyS_write+0x49/0xa0
[ 24.406746] [<ffffffff8183ef3c>] entry_SYSCALL_64_fastpath+0x1f/0xbd
[ 24.413375] irq event stamp: 73908
[ 24.416878] hardirqs last enabled at (73908): [<ffffffff812433be>]
__slab_alloc+0x5e/0x90
[ 24.425215] hardirqs last disabled at (73907): [<ffffffff8124339c>]
__slab_alloc+0x3c/0x90
[ 24.433621] softirqs last enabled at (73890): [<ffffffff8173f89d>]
ip_finish_output2+0x1fd/0x610
[ 24.442634] softirqs last disabled at (73891): [<ffffffff8183ffcc>]
do_softirq_own_stack+0x1c/0x30
[ 24.451776]
[ 24.451776] other info that might help us debug this:
[ 24.458345] Possible unsafe locking scenario:
[ 24.458345]
[ 24.464357] CPU0
[ 24.466854] ----
[ 24.469324] lock(policy_rwlock);
[ 24.472817] <Interrupt>
[ 24.475450] lock(policy_rwlock);
[ 24.479108]
[ 24.479108] *** DEADLOCK ***
[ 24.479108]
[ 24.485081] 4 locks held by dbus-daemon/673:
[ 24.489386] #0: (sk_lock-AF_INET){+.+.+.}, at:
[<ffffffff8177dcb7>] inet_stream_connect+0x27/0x50
[ 24.498659] #1: (rcu_read_lock){......}, at: [<ffffffff81740d65>]
ip_queue_xmit+0x5/0x560
[ 24.507169] #2: (rcu_read_lock){......}, at: [<ffffffff816e949d>]
process_backlog+0xcd/0x230
[ 24.515921] #3: (rcu_read_lock){......}, at: [<ffffffff8173a8af>]
ip_local_deliver_finish+0x2f/0x390
[29/1805]
[ 24.525419]
[ 24.525419] stack backtrace:
[ 24.529833] CPU: 0 PID: 673 Comm: dbus-daemon Tainted: G W
4.8.0-rc4eladr+ #51
[ 24.538323] Hardware name: Mellanox Technologies Ltd. Mellanox
switch/Mellanox switch, BIOS 4.6.5 05/21/2015
[ 24.548246] 0000000000000000 ffff88011dc037d0 ffffffff81411b73
ffff880114955700
[ 24.555777] ffffffff828623a0 ffff88011dc03820 ffffffff81100605
0000000000000001
[ 24.563308] 0000000000000001 ffff880100000000 0000000000000006
0000000000000005
[ 24.570811] Call Trace:
[ 24.573284] <IRQ> [<ffffffff81411b73>] dump_stack+0x85/0xc2
[ 24.579093] [<ffffffff81100605>] print_usage_bug+0x215/0x240
[ 24.584889] [<ffffffff81100b7a>] mark_lock+0x54a/0x610
[ 24.590165] [<ffffffff810ffa80>] ?
print_shortest_lock_dependencies+0x1a0/0x1a0
[ 24.597655] [<ffffffff8110174d>] __lock_acquire+0x59d/0x1490
[ 24.603469] [<ffffffff81241b0c>] ? new_slab+0x35c/0x670
[ 24.608860] [<ffffffff81102ab2>] lock_acquire+0xf2/0x1e0
[ 24.614363] [<ffffffff813ac742>] ? security_netlbl_sid_to_secattr+0x32/0xc0
[ 24.621521] [<ffffffff8183e924>] _raw_read_lock+0x34/0x50
[ 24.627058] [<ffffffff813ac742>] ? security_netlbl_sid_to_secattr+0x32/0xc0
[ 24.634154] [<ffffffff813ac742>] security_netlbl_sid_to_secattr+0x32/0xc0
[ 24.641070] [<ffffffff813af520>] selinux_netlbl_inet_conn_request+0x40/0xe0
[ 24.648178] [<ffffffff81393302>] selinux_inet_conn_request+0x62/0x90
[ 24.654686] [<ffffffff8138bf53>] security_inet_conn_request+0x43/0x60
[ 24.661255] [<ffffffff8175298a>] tcp_conn_request+0x32a/0xa50
[ 24.667154] [<ffffffff8139543e>] ? selinux_peerlbl_enabled+0x1e/0x40
[ 24.673707] [<ffffffff81397f89>] ? selinux_socket_sock_rcv_skb+0x89/0x200
[ 24.680675] [<ffffffff81762726>] tcp_v4_conn_request+0x86/0xb0
[ 24.686638] [<ffffffff81757db4>] tcp_rcv_state_process+0x194/0xef0
[ 24.692980] [<ffffffff81763832>] tcp_v4_do_rcv+0xb2/0x200
[ 24.698507] [<ffffffff81764f50>] tcp_v4_rcv+0xba0/0xbf0
[ 24.703884] [<ffffffff8173a95a>] ip_local_deliver_finish+0xda/0x390
[ 24.710303] [<ffffffff8173a8af>] ? ip_local_deliver_finish+0x2f/0x390
[ 24.716933] [<ffffffff8173ae50>] ip_local_deliver+0x60/0xd0
[ 24.722662] [<ffffffff8173a880>] ? ip_rcv_finish+0x620/0x620
[ 24.728476] [<ffffffff8173a3ef>] ip_rcv_finish+0x18f/0x620
[ 24.734118] [<ffffffff8173b12c>] ip_rcv+0x26c/0x390
[ 24.739129] [<ffffffff8173a260>] ? inet_del_offload+0x40/0x40
[ 24.745029] [<ffffffff816e8a8a>] __netif_receive_skb_core+0x22a/0xb10
[ 24.751630] [<ffffffff816e949d>] ? process_backlog+0xcd/0x230
[ 24.757525] [<ffffffff816e9388>] __netif_receive_skb+0x18/0x60
[ 24.763513] [<ffffffff816e9442>] process_backlog+0x72/0x230
[ 24.769213] [<ffffffff816e949d>] ? process_backlog+0xcd/0x230
[ 24.775090] [<ffffffff816eb38f>] net_rx_action+0x21f/0x430
[ 24.780699] [<ffffffff81100caf>] ? mark_held_locks+0x6f/0xa0
[ 24.786504] [<ffffffff81841f29>] __do_softirq+0xc9/0x44d
[ 24.791946] [<ffffffff8173f89d>] ? ip_finish_output2+0x1fd/0x610
[ 24.798091] [<ffffffff8183ffcc>] do_softirq_own_stack+0x1c/0x30
[ 24.804164] <EOI> [<ffffffff810b09a9>] do_softirq.part.17+0x59/0x60
[ 24.810699] [<ffffffff810b0a69>] __local_bh_enable_ip+0xb9/0xc0
[ 24.816817] [<ffffffff8173f8c6>] ip_finish_output2+0x226/0x610
[ 24.822804] [<ffffffff8174083e>] ? ip_finish_output+0x1ae/0x340
[ 24.828897] [<ffffffff8174083e>] ip_finish_output+0x1ae/0x340
[ 24.834800] [<ffffffff8172db12>] ? nf_hook_slow+0xd2/0x170
[ 24.840433] [<ffffffff81741614>] ip_output+0x74/0x120
[ 24.845633] [<ffffffff81740690>] ? ip_fragment.constprop.53+0x80/0x80
[ 24.852236] [<ffffffff81740b1d>] ip_local_out+0x3d/0x80
[ 24.857607] [<ffffffff81740f3d>] ip_queue_xmit+0x1dd/0x560
[ 24.863259] [<ffffffff81740d65>] ? ip_queue_xmit+0x5/0x560
[ 24.868894] [<ffffffff8175aeb4>] tcp_transmit_skb+0x4a4/0x950
[ 24.874776] [<ffffffff8175ceab>] tcp_connect+0x60b/0xa60
[ 24.880287] [<ffffffff816de8d4>] ? secure_tcp_sequence_number+0x74/0xc0
[ 24.887099] [<ffffffff817623e3>] tcp_v4_connect+0x323/0x520
[ 24.892836] [<ffffffff8177da35>] __inet_stream_connect+0x95/0x2f0
[ 24.899104] [<ffffffff81100e9d>] ? trace_hardirqs_on+0xd/0x10
[ 24.904976] [<ffffffff810b0a20>] ? __local_bh_enable_ip+0x70/0xc0
[ 24.911217] [<ffffffff8177dcc8>] inet_stream_connect+0x38/0x50
[ 24.917259] [<ffffffff816c8ec7>] SYSC_connect+0xb7/0xf0
[ 24.922649] [<ffffffff816c6357>] ? sock_alloc_file+0x97/0x110
[ 24.928557] [<ffffffff81100e09>] ? trace_hardirqs_on_caller+0x129/0x1b0
[ 24.935309] [<ffffffff8100301a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 24.941819] [<ffffffff816c9dfe>] SyS_connect+0xe/0x10
[ 24.947050] [<ffffffff8183ef3c>] entry_SYSCALL_64_fastpath+0x1f/0xbd
^ permalink raw reply
* Re: [RFC v3 06/22] landlock: Add LSM hooks
From: Thomas Graf @ 2016-10-19 15:19 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel, Alexei Starovoitov, Andy Lutomirski, Arnd Bergmann,
Casey Schaufler, Daniel Borkmann, Daniel Mack, David Drysdale,
David S . Miller, Elena Reshetova, Eric W . Biederman,
James Morris, Kees Cook, Paul Moore, Sargun Dhillon,
Serge E . Hallyn, Tejun Heo, Will Drewry, kernel-hardening,
linux-api, linux-security-module, netdev, cgroups
In-Reply-To: <20160914072415.26021-7-mic@digikod.net>
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 9aa01d9d3d80..36c3e482239c 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -85,6 +85,8 @@ enum bpf_arg_type {
>
> ARG_PTR_TO_CTX, /* pointer to context */
> ARG_ANYTHING, /* any (initialized) argument is ok */
> +
> + ARG_PTR_TO_STRUCT_FILE, /* pointer to struct file */
This should go into patch 7 I guess?
> +void __init landlock_add_hooks(void)
> +{
> + pr_info("landlock: Becoming ready for sandboxing\n");
> + security_add_hooks(landlock_hooks, ARRAY_SIZE(landlock_hooks));
> +}
Can we add the hooks when we load the first BPF program for a hook? That
would also allow to not make this conditional on a new config option
which all all distros have to enable anyway.
I would really like to see this patch split into the LSM part which
allows running BPF progs at LSM and your specific sandboxing use case
which requires the new BPF helpers, new reg type, etc.
^ 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;
as well as URLs for NNTP newsgroup(s).