On Wed, Jul 6, 2016 at 10:15 AM, Casey Schaufler <ca...@schaufler-ca.com> wrote: > On 7/6/2016 5:50 AM, Paul Moore wrote: >> On Tue, Jul 5, 2016 at 8:38 PM, Casey Schaufler <ca...@schaufler-ca.com> >> wrote: >>> 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. >> For the past several months I've been running the SELinux testsuite on >> a weekly basis against Linus' kernel plus the SELinux and audit >> development trees and I haven't noticed any problems that haven't >> already been reported. While not exhaustive, the testsuite does >> exercise the NetLabel/CIPSO code. I'll see if I can take a closer >> look at the Smack code, but do you rely on the inet_skb_param values >> in Smack? We did have a similar problem in the NetLabel core code >> that we fixed with 04f81f0154e4bf002be6f4d85668ce1257efa4d9; it's >> possible there is a similar problem in code that we just aren't >> exercising with SELinux at the moment. > > I reported that problem, and that problem was fixed.
Yep, I know, that is why I included the commit ID. > I'm looking at the Linus tree and see no structure inet_skb_param. I mistakenly added an extra "a", look for "struct inet_skb_parm" near the top of include/net/ip.h; it was modified as part of the pull-request/merge you mentioned. -- paul moore www.paul-moore.com