SELinux Archive on lore.kernel.org
 help / color / Atom feed
From: Richard Haines <richard_c_haines@btinternet.com>
To: Paul Moore <paul@paul-moore.com>
Cc: selinux@vger.kernel.org
Subject: Re: [PATCH V2 1/2] selinux-testsuite: Add BPF tests
Date: Tue, 13 Aug 2019 13:05:29 +0100
Message-ID: <874a00ab0ab23c21fdecda2f54656662cffbad49.camel@btinternet.com> (raw)
In-Reply-To: <CAHC9VhQixcQ2x+YLXCWZnS8Cf+wAaeTBJb9JZb8sdQR-TH97Tg@mail.gmail.com>

On Mon, 2019-08-12 at 18:48 -0400, Paul Moore wrote:
> On Sun, Aug 11, 2019 at 11:33 AM Richard Haines
> <richard_c_haines@btinternet.com> wrote:
> > On Fri, 2019-08-09 at 17:55 +0100, Richard Haines wrote:
> > > On Fri, 2019-08-09 at 11:22 -0400, Paul Moore wrote:
> > > > On Thu, Aug 1, 2019 at 7:12 AM Richard Haines
> > > > <richard_c_haines@btinternet.com> wrote:
> > > > > This adds basic BPF tests for map and prog functions.
> > > > > 
> > > > > The check-syntax script has been modified to exclude files
> > > > > listed
> > > > > in tools/chk_c_exclude. This is because of macros in
> > > > > bpf_common.c
> > > > > that get horribly reformatted by check-syntax.
> > > > > 
> > > > > Signed-off-by: Richard Haines <
> > > > > richard_c_haines@btinternet.com>
> > > > > ---
> > > > > V2 Change - Split BPF code into bpf_common.c for others to
> > > > > use.
> > > > > 
> > > > >  README.md              |  4 +-
> > > > >  defconfig              |  5 +++
> > > > >  policy/Makefile        |  4 ++
> > > > >  policy/test_bpf.te     | 77 ++++++++++++++++++++++++++++++++
> > > > >  tests/Makefile         |  4 ++
> > > > >  tests/bpf/.gitignore   |  2 +
> > > > >  tests/bpf/Makefile     | 12 +++++
> > > > >  tests/bpf/bpf_common.c | 99
> > > > > ++++++++++++++++++++++++++++++++++++++++++
> > > > >  tests/bpf/bpf_test.c   | 83
> > > > > +++++++++++++++++++++++++++++++++++
> > > > >  tests/bpf/test         | 57 ++++++++++++++++++++++++
> > > > >  tools/check-syntax     |  2 +-
> > > > >  tools/chk_c_exclude    |  1 +
> > > > >  12 files changed, 348 insertions(+), 2 deletions(-)
> > > > >  create mode 100644 policy/test_bpf.te
> > > > >  create mode 100644 tests/bpf/.gitignore
> > > > >  create mode 100644 tests/bpf/Makefile
> > > > >  create mode 100644 tests/bpf/bpf_common.c
> > > > >  create mode 100644 tests/bpf/bpf_test.c
> > > > >  create mode 100755 tests/bpf/test
> > > > >  create mode 100644 tools/chk_c_exclude
> > > > 
> > > > ...
> > > > 
> > > > > diff --git a/tools/check-syntax b/tools/check-syntax
> > > > > index 7f9768d..5b7c211 100755
> > > > > --- a/tools/check-syntax
> > > > > +++ b/tools/check-syntax
> > > > > @@ -11,7 +11,7 @@
> > > > >  #
> > > > > 
> > > > >  CHK_C_LIST="$(find tests/ -name "*.c") $(find tests/ -name
> > > > > "*.h")"
> > > > > -CHK_C_EXCLUDE=""
> > > > > +CHK_C_EXCLUDE="$(cat tools/chk_c_exclude)"
> > > > > 
> > > > >  CHK_PERL_LIST="$(find tests/ -name "*.pl") $(find tests/
> > > > > -name
> > > > > "test")"
> > > > >  CHK_PERL_EXCLUDE=""
> > > > > diff --git a/tools/chk_c_exclude b/tools/chk_c_exclude
> > > > > new file mode 100644
> > > > > index 0000000..20facbf
> > > > > --- /dev/null
> > > > > +++ b/tools/chk_c_exclude
> > > > > @@ -0,0 +1 @@
> > > > > +tests/bpf/bpf_common.c
> > > > 
> > > > Why are we excluding bpf_common.c from the style checks?
> > > 
> > > Because check-syntax reformats a macro and it is not neat and
> > > tidy
> > > said Mr Neat to Mr Tidy
> 
> I was in the middle of writing a response that pushed the Mr Neat and
> Mr Tidy joke to the straining point and I decided I couldn't take it
> anymore ... and if I can endure my own response, how could I expect
> anyone else to do it? ;)
> 
> Regardless, the problem is that style is horribly subjective, and I
> really hate getting bogged down in those sorts of arguments (witness
> the recent on-list discussion of comment styles) so I added the
> "check-syntax" tool to settle those arguments.  You run the code
> through the tool, and that's your answer.  Period.  (I suppose it
> might be "full stop" for Mr Neat and/or Mr Tidy.)  Does that mean I
> always like the output of the tool?  No, sometimes it makes a mess of
> things[1], but I'd rather have that then on-list arguments about
> style.
> 
> [1] In the past I've fixed the really bad check-syntax output by
> tweaking the input code ever so slightly.
> 
> > Just a thought - The patches run the fdreceive with bpf support
> > before
> > the core bpf test. I could resubmit the patches to test core bpf
> > first
> > ?? (and allow Mr Messy to format the macros in bpf_common.c)
> 
> That gets to another thing that bothers me slightly ... I didn't
> mention it earlier because of the test failure, the style issue, and
> lack of time, but I'm not sure what I feel about splitting the BPF
> tests up like that.  Duplicating code isn't a great solution either.
> Thoughts?
> 

I can only think of two options:
1) If BPF, build tests/fdreceive and tests/binder services with
bpf_common services, then in tests/bpf run the appropriate tests (by
setting $fdr_basedir = "$basedir/../fdreceive/"; etc.).

2) For fdreceive I would only need to replicate and modify the client,
therefore putting this code and test under the main bpf is not a
problem. For binder I would probably need to copy 90% of the code,
unless I can find an easier test (although with binder, you have to do
a bit just to get going).

Option 1 seems best.



      reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 11:12 Richard Haines
2019-08-09 15:22 ` Paul Moore
2019-08-09 16:55   ` Richard Haines
2019-08-11 15:33     ` Richard Haines
2019-08-12 22:48       ` Paul Moore
2019-08-13 12:05         ` Richard Haines [this message]

Reply instructions:

You may reply publically 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=874a00ab0ab23c21fdecda2f54656662cffbad49.camel@btinternet.com \
    --to=richard_c_haines@btinternet.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    /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

SELinux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \
		selinux@vger.kernel.org selinux@archiver.kernel.org
	public-inbox-index selinux


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux


AGPL code for this site: git clone https://public-inbox.org/ public-inbox