From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v59K1Qqh001446 for ; Fri, 9 Jun 2017 16:01:26 -0400 Received: by mail-lf0-f68.google.com with SMTP id u62so5804418lfg.0 for ; Fri, 09 Jun 2017 13:01:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1496162091-129822-1-git-send-email-danielj@mellanox.com> <1496162091-129822-3-git-send-email-danielj@mellanox.com> <1496164182.2164.12.camel@tycho.nsa.gov> <1496166732.2164.18.camel@tycho.nsa.gov> From: Paul Moore Date: Fri, 9 Jun 2017 16:01:21 -0400 Message-ID: Subject: Re: [PATCH v2 2/2] selinux-testsuite: Infiniband endport tests To: Daniel Jurgens Cc: Stephen Smalley , "selinux@tycho.nsa.gov" , Yevgeny Petrilin Content-Type: text/plain; charset="UTF-8" List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: On Fri, Jun 9, 2017 at 10:59 AM, Daniel Jurgens wrote: > On 6/9/2017 9:50 AM, Paul Moore wrote: >> On Fri, Jun 9, 2017 at 10:44 AM, Daniel Jurgens wrote: >>> On 6/5/2017 5:34 PM, Daniel Jurgens wrote: >>>> On 6/5/2017 5:13 PM, Paul Moore wrote: >>>>> On Tue, May 30, 2017 at 1:52 PM, Stephen Smalley wrote: >>>>>> On Tue, 2017-05-30 at 17:40 +0000, Daniel Jurgens wrote: >>>>>>> On 5/30/2017 12:05 PM, Stephen Smalley wrote: >>>>>>>> On Tue, 2017-05-30 at 19:34 +0300, Dan Jurgens wrote: >>>>>>>>> From: Daniel Jurgens >>>>>>>>> >>>>>>>>> New tests for Infiniband endports. Most users do not have >>>>>>>>> infiniband >>>>>>>>> hardware, and if they do the device names can vary. There is a >>>>>>>>> configuration file for enabling the tests and setting environment >>>>>>>>> specific configurations. If the tests are disabled they always >>>>>>>>> show >>>>>>>>> as >>>>>>>>> passed. >>>>>>>>> >>>>>>>>> A special test application was unnecessary, a standard diagnostic >>>>>>>>> application is used instead. This required a change to the make >>>>>>>>> file >>>>>>>>> to avoid trying to build an application in the new subdir. >>>>>>>>> >>>>>>>>> Signed-off-by: Daniel Jurgens >>>>> ... >>>>> >>>>>> I wouldn't bother re-spinning unless Paul has other comments. >>>>> Nothing worthy of a respin. >>>>> >>>>> Daniel, have you run these tests against the kernel, userspace, and >>>>> policy code that has been merged? It would be nice to have a sanity >>>>> check that something didn't break while we were merging everything. >>>>> >>>>> [SIDE NOTE: This afternoon I noticed what I think may be a problem >>>>> with my COPR kernel builds that affects the test suite, so YMMY at the >>>>> moment.] >>>>> >>>> I ran them against the merged kernel and selinux code. But I used the same policy RPMs that I had been using, I didn't try to rebuild the RPMs against the new refpolicy. >>>> >>> Are these tests good to go? I haven't gotten any additional comments since v2. >> Yes, my apologies for not getting back to you sooner; I had hoped to >> talk to some of the IB folks at Red Hat to see if they could verify >> everything (or at least get access to a IB system so I could verify >> it) but I got wrapped in a few audit issues this week and didn't get >> to it. >> >> I'll merge these patches later this afternoon. >> > No problem, just wanted to make sure I wasn't holding it up in anyway. Should be all set now, let me know if you notice any problems. I did add a separate third commit to munge the style/formatting (see previous emails); I didn't bother posting it to the list as it is just style changes, but in case anyone is curious, this is the commit: commit 8e0339cef20d0356d3e115c31a133662e9562e65 Author: Paul Moore Date: Fri Jun 9 15:46:37 2017 -0400 infiniband: apply style corrections to the infiniband tests Patch generated by './tools/check-syntax -f'. Signed-off-by: Paul Moore > I recall you saying you do most of your testing in VMs on a laptop. But if you have a system with a free pci-e slot we can ship you an HCA if you'd like to be able to run these yourself. Thank you for the offer, and yes I generally run the tests in a VM, however we've been working on getting something a bit more automated in place for upstream testing (more info on that once everything is sorted out). Let me think about this a bit (and dust off my somewhat neglected testing hardware), I generally try to avoid getting tied to specific hardware, but it is necessary in this case, and I fear that this may be the easiest way to ensure it gets tested regularly. -- paul moore www.paul-moore.com