From: Casey Schaufler <casey@schaufler-ca.com>
To: David Miller <davem@davemloft.net>,
dsa@cumulusnetworks.com, Paul Moore <paul@paul-moore.com>
Cc: Linux-Netdev <netdev@vger.kernel.org>,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with CIPSO & Smack
Date: Tue, 5 Jul 2016 17:38:59 -0700 [thread overview]
Message-ID: <e5ba1ba9-acf6-c36c-03e4-4cdc81e81648@schaufler-ca.com> (raw)
I have encountered a system hang with my Smack
networking tests that bisects to the change below.
I can't say that I have any idea why the change
would impact the Smack processing, but there appears
to be some serious packet processing going on. The
Smack code is using CIPSO on the loopback interface.
The test is supposed to verify that labels can be
set on the packets using CIPSO. Unlabeled packets
do not appear to be impacted. I do not know if SELinux
is affected, and if not, why not. Smack and SELinux
use CIPSO differently.
c3f1010b30f7fc611139cfb702a8685741aa6827
commit c3f1010b30f7fc611139cfb702a8685741aa6827
Merge: ca4aa97 0b922b7
Author: David S. Miller <davem@davemloft.net>
Date: Wed May 11 19:31:40 2016 -0400
Merge branch 'vrf-pktinfo'
David Ahern says:
====================
net: vrf: Fixup PKTINFO to return enslaved device index
Applications such as OSPF and BFD need the original ingress device not
the VRF device; the latter can be derived from the former. To that end
move the packet intercept from an rx handler that is invoked by
__netif_receive_skb_core to the ipv4 and ipv6 receive processing.
IPv6 already saves the skb_iif to the control buffer in ipv6_rcv. Since
the skb->dev has not been switched the cb has the enslaved device. Make
the same happen for IPv4 by adding the skb_iif to inet_skb_parm and set
it in ipv4 code after clearing the skb control buffer similar to IPv6.
From there the pktinfo can just pull it from cb with the PKTINFO_SKB_CB
cast.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
next reply other threads:[~2016-07-06 0:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 0:38 Casey Schaufler [this message]
2016-07-06 0:49 ` Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with CIPSO & Smack David Ahern
2016-07-06 1:31 ` Casey Schaufler
2016-07-06 16:28 ` David Ahern
2016-07-06 17:24 ` Casey Schaufler
2016-07-06 17:40 ` David Ahern
2016-07-06 18:01 ` Casey Schaufler
2016-07-06 18:43 ` David Ahern
2016-07-06 18:56 ` Casey Schaufler
2016-07-19 23:37 ` Casey Schaufler
2016-07-20 20:13 ` Paul Moore
2016-07-21 22:55 ` Casey Schaufler
2016-07-06 12:50 ` Paul Moore
2016-07-06 14:03 ` Paul Moore
2016-07-06 14:42 ` Casey Schaufler
2016-07-06 14:15 ` Casey Schaufler
2016-07-06 14:37 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e5ba1ba9-acf6-c36c-03e4-4cdc81e81648@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=davem@davemloft.net \
--cc=dsa@cumulusnetworks.com \
--cc=netdev@vger.kernel.org \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox