linux-kernel - Re: [PATCH 2/3] selftests: add membarrier syscall test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 08 Sep 2015 14:19:54 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	linux-api <linux-api@...r.kernel.org>,
	Pranith Kumar <bobby.prani@...il.com>
Subject: Re: [PATCH 2/3] selftests: add membarrier syscall test

On Mon, 2015-09-07 at 16:01 +0000, Mathieu Desnoyers wrote:
> ----- On Sep 3, 2015, at 11:36 PM, Michael Ellerman mpe@...erman.id.au wrote:
> > On Thu, 2015-09-03 at 15:47 +0000, Mathieu Desnoyers wrote:
> >> 
> >> My personal experience is that make headers_install does not necessarily play
> >> well with the distribution header file hierarchy, which requires some tweaks
> >> to be done by the users (e.g. asm vs x86_64-linux-gnu).
> > 
> > OK, I've never had issues. What exactly are you doing and how is it going wrong?
> 
> After some investigation, I noticed the following:
> 
> 1) I first ran make headers_install as root, which installed the
> headers within my build tree. I later tried it again as user, and
> it failed due to permission issues (my bad). This is where I tried
> to install it into my system rather than under my build directory,
> which caused a mess.

Yeah OK that's a good point about root.

I tend to build as a regular user and then copy the installed tests to another
machine where I run them as root.

> 2) Since make kselftest should be run as root (according to make
> help), 

Well some of the tests only work when run as root. IMHO we should support
running as many tests as possible as non-root, but some of them obviously
require root.

So you can run them as non-root, but to get maximum coverage you need to run
them as root.

> this means that all the output files generated by the build
> are owned by root. It leads to permissions issues when trying to
> rebuild the tests as user afterward. Perhaps we could introduce a
> distinction between make kselftest_build and make kselftest_run ?
> The former could be executed as user, and the latter as root.

Right. Personally I don't use the kselftest target at all, I just cd down to
tools/testing/selftests and run make there.

If it was up to me the kselftest target would go away, because it's only caused
us trouble so far.

But given it's there we should try to make it work as well as possible. So yeah
splitting it into build and run would make sense, that way you could do:

$ make headers_install
$ make kselftest_build
$ sudo make kselftest_run

And that would hopefully do the right thing.

Would that improve the workflow for you?

> > So that seems to be working for me. Are you doing some different work flow, or
> > am I just missing something?
> 
> When doing make headers_install, it indeed installs
> membarrier.h where we expect it under the build output
> dir:
> 
> $ ls usr/include/linux/membarrier.h 
> usr/include/linux/membarrier.h
> 
> However, if I issue 
> 
> $ make -C tools/testing/selftests TARGETS=membarrier
> make: Entering directory `/home/efficios/git/linux-next/tools/testing/selftests'
> for TARGET in membarrier; do \
> 		make -C $TARGET; \
> 	done;
> make[1]: Entering directory `/home/efficios/git/linux-next/tools/testing/selftests/membarrier'
> gcc     membarrier_test.c   -o membarrier_test
> membarrier_test.c:2:30: fatal error: linux/membarrier.h: No such file or directory
>  #include <linux/membarrier.h>
> 
> This is after applying the modifications you requested
> (see patch attached). Perhaps I did something wrong ?

Yeah sorry, you still need the -I line:

CFLAGS += -I../../../../usr/include/


We /should/ add that to lib.mk so it's inherited by everyone, but we haven't
yet.

So I think if you put that back the instructions I gave you will work?

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/