* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Darren Hart @ 2015-05-12 20:15 UTC (permalink / raw)
To: Cyril Hrubis
Cc: Shuah Khan, linux-api-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, John Stultz, Ingo Molnar,
Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <20150512200528.GA1336@rei>
On 5/12/15, 1:05 PM, "Cyril Hrubis" <chrubis-AlSwsSmVLrQ@public.gmane.org> wrote:
>Hi!
>> >> I'm happy to do that, but I would like to make sure I'm doing the
>>right
>> >> thing.
>> >
>> >The right thing here is to add -pthread to CFLAGS which sets both flags
>> >for preprocessor and linker (see man gcc).
>>
>> Hi Cyril,
>>
>> Thanks. I read that, and mentioned it, but my concern with -pthread in
>>the
>> CFLAGS and LDFLAGS is that it is a non-standard compiler flag. I
>> understand we have a number of gcc-isms in our build - but do we want to
>> add more?
>>
>> I'm also struggling to find any kind of prescribed documentation on this
>> beyond the short blurb in the gcc man page which describes what this
>> option does, but not when to use it. I'll need something concrete to
>> justify changes to testcase Makefiles to Shuah.
>
>Sorry to mislead you with the pointing at gcc man page.
>
>It is a Linux standard. Have a look at pthreads manual page:
>http://man7.org/linux/man-pages/man7/pthreads.7.html
>
>"On Linux, programs that use the Pthreads API should be compiled using
> cc -pthread."
>
>Or any pthread_foo() manual page that starts with:
>
>"Compile and link with -pthread."
>
>The portable way i.e. POSIX would be getting compiler flags with getconf
>but as this is a Linux kernel testsuite I would not bother with that.
>Hmm, and it looks like this is not implemented on Linux anyway.
Thanks Cyril, that's perfect.
I'll roll my latest example patch adding -pthread to LDFLAGS and CFLAGS
into the initial patch and resubmit the patch series as v4.
Thanks all.
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Shuah Khan @ 2015-05-12 20:40 UTC (permalink / raw)
To: Darren Hart, Cyril Hrubis
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
John Stultz, Ingo Molnar, Peter Zijlstra, Thomas Gleixner,
Davidlohr Bueso, KOSAKI Motohiro, Shuah Khan
In-Reply-To: <D177AD46.CC848%dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 05/12/2015 02:15 PM, Darren Hart wrote:
> On 5/12/15, 1:05 PM, "Cyril Hrubis" <chrubis-AlSwsSmVLrQ@public.gmane.org> wrote:
>
>> Hi!
>>>>> I'm happy to do that, but I would like to make sure I'm doing the
>>> right
>>>>> thing.
>>>>
>>>> The right thing here is to add -pthread to CFLAGS which sets both flags
>>>> for preprocessor and linker (see man gcc).
>>>
>>> Hi Cyril,
>>>
>>> Thanks. I read that, and mentioned it, but my concern with -pthread in
>>> the
>>> CFLAGS and LDFLAGS is that it is a non-standard compiler flag. I
>>> understand we have a number of gcc-isms in our build - but do we want to
>>> add more?
>>>
>>> I'm also struggling to find any kind of prescribed documentation on this
>>> beyond the short blurb in the gcc man page which describes what this
>>> option does, but not when to use it. I'll need something concrete to
>>> justify changes to testcase Makefiles to Shuah.
>>
>> Sorry to mislead you with the pointing at gcc man page.
>>
>> It is a Linux standard. Have a look at pthreads manual page:
>> http://man7.org/linux/man-pages/man7/pthreads.7.html
>>
>> "On Linux, programs that use the Pthreads API should be compiled using
>> cc -pthread."
>>
>> Or any pthread_foo() manual page that starts with:
>>
>> "Compile and link with -pthread."
>>
>> The portable way i.e. POSIX would be getting compiler flags with getconf
>> but as this is a Linux kernel testsuite I would not bother with that.
>> Hmm, and it looks like this is not implemented on Linux anyway.
>
> Thanks Cyril, that's perfect.
>
> I'll roll my latest example patch adding -pthread to LDFLAGS and CFLAGS
> into the initial patch and resubmit the patch series as v4.
>
Daren,
While you are generating new version, could you also please add
.gitignore for the futex binaries, so they get ignored by git.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Darren Hart @ 2015-05-12 20:54 UTC (permalink / raw)
To: Shuah Khan, Cyril Hrubis
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
John Stultz, Ingo Molnar, Peter Zijlstra, Thomas Gleixner,
Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <55526544.90909-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On 5/12/15, 1:40 PM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>On 05/12/2015 02:15 PM, Darren Hart wrote:
>> On 5/12/15, 1:05 PM, "Cyril Hrubis" <chrubis-AlSwsSmVLrQ@public.gmane.org> wrote:
>>
>>> Hi!
>>>>>> I'm happy to do that, but I would like to make sure I'm doing the
>>>> right
>>>>>> thing.
>>>>>
>>>>> The right thing here is to add -pthread to CFLAGS which sets both
>>>>>flags
>>>>> for preprocessor and linker (see man gcc).
>>>>
>>>> Hi Cyril,
>>>>
>>>> Thanks. I read that, and mentioned it, but my concern with -pthread in
>>>> the
>>>> CFLAGS and LDFLAGS is that it is a non-standard compiler flag. I
>>>> understand we have a number of gcc-isms in our build - but do we want
>>>>to
>>>> add more?
>>>>
>>>> I'm also struggling to find any kind of prescribed documentation on
>>>>this
>>>> beyond the short blurb in the gcc man page which describes what this
>>>> option does, but not when to use it. I'll need something concrete to
>>>> justify changes to testcase Makefiles to Shuah.
>>>
>>> Sorry to mislead you with the pointing at gcc man page.
>>>
>>> It is a Linux standard. Have a look at pthreads manual page:
>>> http://man7.org/linux/man-pages/man7/pthreads.7.html
>>>
>>> "On Linux, programs that use the Pthreads API should be compiled using
>>> cc -pthread."
>>>
>>> Or any pthread_foo() manual page that starts with:
>>>
>>> "Compile and link with -pthread."
>>>
>>> The portable way i.e. POSIX would be getting compiler flags with
>>>getconf
>>> but as this is a Linux kernel testsuite I would not bother with that.
>>> Hmm, and it looks like this is not implemented on Linux anyway.
>>
>> Thanks Cyril, that's perfect.
>>
>> I'll roll my latest example patch adding -pthread to LDFLAGS and CFLAGS
>> into the initial patch and resubmit the patch series as v4.
>>
>
>Daren,
>
>While you are generating new version, could you also please add
>.gitignore for the futex binaries, so they get ignored by git.
Will do.
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply
* Re: CONFIG_ISOLATION=y
From: Chris Metcalf @ 2015-05-12 21:05 UTC (permalink / raw)
To: Ingo Molnar
Cc: Steven Rostedt, Frederic Weisbecker, Andrew Morton, paulmck,
Gilad Ben Yossef, Peter Zijlstra, Rik van Riel, Tejun Heo,
Thomas Gleixner, Christoph Lameter, Srivatsa S. Bhat, linux-doc,
linux-api, linux-kernel
In-Reply-To: <20150512091032.GA10138@gmail.com>
On 05/12/2015 05:10 AM, Ingo Molnar wrote:
> * Chris Metcalf <cmetcalf@ezchip.com> wrote:
>
>> - ISOLATION (Frederic). I like this but it conflicts with other uses
>> of "isolation" in the kernel: cgroup isolation, lru page isolation,
>> iommu isolation, scheduler isolation (at least it's a superset of
>> that one), etc. Also, we're not exactly isolating a task - often
>> a "dataplane" app consists of a bunch of interacting threads in
>> userspace, so not exactly isolated. So perhaps it's too confusing.
> So I'd vote for Frederic's CONFIG_ISOLATION=y, mostly because this is
> a high level kernel feature, so it won't conflict with isolation
> concepts in lower level subsystems such as IOMMU isolation - and other
> higher level features like scheduler isolation are basically another
> partial implementation we want to merge with all this...
>
> nohz, RCU tricks, watchdog defaults, isolcpus and various other
> measures to keep these CPUs and workloads as isolated as possible
> are (or should become) components of this high level concept.
>
> Ideally CONFIG_ISOLATION=y would be a kernel feature that has almost
> zero overhead on normal workloads and on non-isolated CPUs, so that
> Linux distributions can enable it.
Using CONFIG_CPU_ISOLATION to capture all this stuff instead of
making CONFIG_NO_HZ_FULL do it seems plausible for naming.
However, this feels like just bombing the current naming to this
new name, right? I'd like to argue that this is orthogonal to adding
new isolation functionality into no_hz_full, as my patch series has
been doing. Perhaps we can defer this to a follow-up patch series?
I'm happy to do the work but I'm not sure we want to bundle all
that churn into the current patch series under consideration.
I can use cpu_isolation_xxx for naming in the current patch series
so we don't have to come back and bomb that later.
> Enabling CONFIG_ISOLATION=y should be the only 'kernel config' step
> needed: just like cpusets, the configuration of isolated CPUs should
> be a completely boot option free excercise that can be dynamically
> done and undone by the administrator via an intuitive interface.
Eventually isolation can be runtime-enabled, but for now I think
it makes sense to be boot-enabled. As Frederic suggested, we
can arrange full nohz to be runtime toggled in the future.
I agree that it should be reasonable to compile it in by default.
On 05/12/2015 07:48 AM, Peter Zijlstra wrote:
> But why do we need a CONFIG flag for something that has no content?
>
> That is, I do not see anything much; except the 'I want to stay in
> userspace and kill me otherwise' flag, and I'm not sure that warrants a
> CONFIG flag like this.
>
> Other than that, its all a combination of NOHZ_FULL and cpusets/isolcpus
> and whatnot.
There are three major pieces here - one is the STRICT piece
that you allude to, but there is also the piece where we quiesce
tasks in the kernel until no timer interrupts are pending, and the
piece that allows easy debugging of stray IRQs etc to isolated cpus.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
^ permalink raw reply
* Re: [PATCH 5/6] nohz: support PR_DATAPLANE_STRICT mode
From: Chris Metcalf @ 2015-05-12 21:06 UTC (permalink / raw)
To: Andy Lutomirski, Peter Zijlstra
Cc: Paul E. McKenney, Frederic Weisbecker, Ingo Molnar, Rik van Riel,
linux-doc@vger.kernel.org, Andrew Morton,
linux-kernel@vger.kernel.org, Thomas Gleixner, Tejun Heo,
Steven Rostedt, Christoph Lameter, Gilad Ben Yossef, Linux API
In-Reply-To: <CALCETrW8aNOZmNKx8P=mCD2iZmjxjDFzZH4Yzmh5im9Werzw9g@mail.gmail.com>
On 05/11/2015 06:28 PM, Andy Lutomirski wrote:
> [add peterz due to perf stuff]
>
> On Mon, May 11, 2015 at 12:13 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>> Patch 6/6 proposes a mechanism to track down times when the
>> kernel screws up and delivers an IRQ to a userspace-only task.
>> Here, we're just trying to identify the times when an application
>> screws itself up out of cluelessness, and provide a mechanism
>> that allows the developer to easily figure out why and fix it.
>>
>> In particular, /proc/interrupts won't show syscalls or page faults,
>> which are two easy ways applications can screw themselves
>> when they think they're in userspace-only mode. Also, they don't
>> provide sufficient precision to make it clear what part of the
>> application caused the undesired kernel entry.
> Perf does, though, complete with context.
The perf_event suggestions are interesting, but I think it's plausible
for this to be an alternate way to debug the issues that STRICT
addresses.
>> In this case, killing the task is appropriate, since that's exactly
>> the semantics that have been asked for - it's like on architectures
>> that don't natively support unaligned accesses, but fake it relatively
>> slowly in the kernel, and in development you just say "give me a
>> SIGBUS when that happens" and in production you might say
>> "fix it up and let's try to keep going".
> I think more control is needed. I also think that, if we go this
> route, we should distinguish syscalls, synchronous non-syscall
> entries, and asynchronous non-syscall entries. They're quite
> different.
I don't think it's necessary to distinguish the types. As long as we
have a PC pointing to the instruction that triggered the problem,
we can see if it's a system call instruction, a memory write that
caused a page fault, a trap instruction, etc. We certainly could
add infrastructure to capture syscall numbers, fault/signal numbers,
etc etc, but I think it's overkill if it adds kernel overhead on
entry/exit.
>> A better implementation, I think, is to put the tests for "you
>> screwed up and synchronously entered the kernel" in
>> the syscall_trace_enter() code, which TIF_NOHZ already
>> gets us into;
> No, not unless you're planning on using that to distinguish syscalls
> from other stuff *and* people think that's justified.
So, the question is how we separate synchronous entries
from IRQs? At a high level, IRQs are kernel bugs (for cpu-isolated
tasks), and synchronous entries are application bugs. We'd
like to deliver a signal for the latter, and do some kind of
kernel diagnostics for the former. So we can't just add the
test in the context tracking code, which doesn't actually know
why we're entering or exiting.
That's why I was thinking that the syscall_trace_entry and
exception_enter paths were the best choices. I'm fairly sure
that exception_enter is only done for synchronous traps,
page faults, etc.
Certainly on the tile architecture we include the trap number
in the pt_regs, so it's possible to just examine the pt_regs and
know why you entered or are exiting the kernel, but I don't
think we can rely on that for all architectures.
> It's far to easy to just make a tiny change to the entry code. Add a
> tiny trivial change here, a few lines of asm (that's you, audit!)
> there, some weird written-in-asm scheduling code over here, and you
> end up with the truly awful mess that we currently have.
>
> If it really makes sense for this stuff to go with context tracking,
> then fine, but we should *fix* the context tracking first rather than
> kludging around it. I already have a prototype patch for the relevant
> part of that.
>
>> there, we can test if the dataplane "strict" bit is
>> set and the syscall is not prctl(), then we generate the error.
>> (We'd exclude exit and exit_group here too, since we don't
>> need to shoot down a task that's just trying to kill itself.)
>> This needs a bit of platform-specific code for each platform,
>> but that doesn't seem like too big a problem.
> I'd rather avoid that, too. This feature isn't really arch-specific,
> so let's avoid the arch stuff if at all possible.
I'll put out a v2 of my patch that does both the things you
advise against :-) just so we can have a strawman to think
about how to do it better - unless you have a suggestion
offhand as to how we can better differentiate sync and async
entries into the kernel in a platform-independent way.
I could imagine modifying user_exit() and exception_enter()
to pass an identifier into the context system saying why they
were changing contexts, so we could have syscalls, trap
numbers, fault numbers, etc., and some way to query as
to whether they were synchronous or asynchronous, and
build this scheme on top of that, but I'm not sure the extra
infrastructure is worthwhile.
>> Likewise we can test in exception_enter() since that's only
>> called for all the synchronous user entries like page faults.
> Let's try to generalize a bit. There's also irq_entry and ist_enter,
> and some of the exception_enter cases are for synchronous entries
> while (IIRC -- could be wrong) others aren't always like that.
I don't think we need to generalize this piece. irq_entry()
shouldn't be reported by the STRICT mechanism but by
kernel bug reporting. For ist_enter(), it looks like if you're
coming from userspace it's just handled with exception_enter().
I'm more familiar with the tile architecture mechanisms than
with x86, though, to be honest.
>>> Also, I think that most users will be quite surprised if "strict
>>> dataplane" code causes any machine check on the system to kill your
>>> dataplane task.
>>
>> Fair point, and avoided by testing as described above instead.
>> (Though presumably in development it's not such a big deal,
>> and as I said you'd likely turn it off in production.)
> Until you forget to turn it off in production because it worked so
> nicely in development.
I guess that's an argument for using a non-fatal signal with a
handler from the get-go, since then even in production you'll
just end up with a slightly heavier-weight kernel overhead
(whatever stupid thing your application did, plus the time
spent in the signal handler), but then after that you can get
back to processing packets or whatever the app is doing.
You had mentioned some alternatives to a catchable signal
(a signal to some other process, or queuing to an fd); I think
it still seems reasonable to just deliver a signal to the process,
configurably by the prctl, and not do anything more complex.
Does this seem reasonable to you at this point?
> What if we added a mode to perf where delivery of a sample
> synchronously (or semi-synchronously by catching it on the next exit
> to userspace) freezes the delivering task? It would be like debugger
> support via perf.
>
> peterz, do you think this would be a sensible thing to add to perf?
> It would only make sense for some types of events (tracepoints and
> hw_breakpoints mostly, I think).
I suspect it's reasonable to consider this orthogonal, particularly
if there is some skid between the actual violation by the
application, and the freeze happening.
You pushed back somewhat on prctl() in favor of a quiesce()
syscall in your email, but it seemed like at the end of your
email you were adopting the prctl() perspective. Is that true?
I admit the prctl() still seems cleaner from my perspective.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Shuah Khan @ 2015-05-12 21:17 UTC (permalink / raw)
To: Darren Hart, Cyril Hrubis
Cc: linux-api, Linux Kernel Mailing List, John Stultz, Ingo Molnar,
Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro,
Shuah Khan
In-Reply-To: <D177B3F7.CC8C3%dvhart@linux.intel.com>
On 05/12/2015 02:54 PM, Darren Hart wrote:
> On 5/12/15, 1:40 PM, "Shuah Khan" <shuahkh@osg.samsung.com> wrote:
>
>> On 05/12/2015 02:15 PM, Darren Hart wrote:
>>> On 5/12/15, 1:05 PM, "Cyril Hrubis" <chrubis@suse.cz> wrote:
>>>
>>>> Hi!
>>>>>>> I'm happy to do that, but I would like to make sure I'm doing the
>>>>> right
>>>>>>> thing.
>>>>>>
>>>>>> The right thing here is to add -pthread to CFLAGS which sets both
>>>>>> flags
>>>>>> for preprocessor and linker (see man gcc).
>>>>>
>>>>> Hi Cyril,
>>>>>
>>>>> Thanks. I read that, and mentioned it, but my concern with -pthread in
>>>>> the
>>>>> CFLAGS and LDFLAGS is that it is a non-standard compiler flag. I
>>>>> understand we have a number of gcc-isms in our build - but do we want
>>>>> to
>>>>> add more?
>>>>>
>>>>> I'm also struggling to find any kind of prescribed documentation on
>>>>> this
>>>>> beyond the short blurb in the gcc man page which describes what this
>>>>> option does, but not when to use it. I'll need something concrete to
>>>>> justify changes to testcase Makefiles to Shuah.
>>>>
>>>> Sorry to mislead you with the pointing at gcc man page.
>>>>
>>>> It is a Linux standard. Have a look at pthreads manual page:
>>>> http://man7.org/linux/man-pages/man7/pthreads.7.html
>>>>
>>>> "On Linux, programs that use the Pthreads API should be compiled using
>>>> cc -pthread."
>>>>
>>>> Or any pthread_foo() manual page that starts with:
>>>>
>>>> "Compile and link with -pthread."
>>>>
>>>> The portable way i.e. POSIX would be getting compiler flags with
>>>> getconf
>>>> but as this is a Linux kernel testsuite I would not bother with that.
>>>> Hmm, and it looks like this is not implemented on Linux anyway.
>>>
>>> Thanks Cyril, that's perfect.
>>>
>>> I'll roll my latest example patch adding -pthread to LDFLAGS and CFLAGS
>>> into the initial patch and resubmit the patch series as v4.
>>>
>>
>> Daren,
>>
>> While you are generating new version, could you also please add
>> .gitignore for the futex binaries, so they get ignored by git.
>
> Will do.
>
Daren,
Do you plan to add futex test install support in a later patch
series? When you sent this patch series, install support was
work in progress. 4.1 has the kselftest install feature.
Feel free to defer it for a later patch series if you like. Would
be good to get the futex install support into 4.2 if it is possible.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply
* Re: [PATCH v8 14/16] ARM: dts: Introduce STM32F429 MCU
From: Arnd Bergmann @ 2015-05-12 21:21 UTC (permalink / raw)
To: Maxime Coquelin
Cc: u.kleine-koenig, afaerber, geert, Rob Herring, Philipp Zabel,
Linus Walleij, stefan, pmeerw, pebolle, peter, andy.shevchenko,
cw00.choi, Russell King, Daniel Lezcano, joe, Vladimir Zapolskiy,
lee.jones, Daniel Thompson, Jonathan Corbet, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Thomas Gleixner,
Greg Kroah-Hartman, Jiri Slaby, Andrew Morton
In-Reply-To: <1431158038-3813-15-git-send-email-mcoquelin.stm32@gmail.com>
On Saturday 09 May 2015 09:53:56 Maxime Coquelin wrote:
> +#include <dt-bindings/mfd/stm32f4-rcc.h>
> +
>
Can you find a way to avoid this dependency?
Maybe you can change the bindings so that the numbers you pass as
arguments to the reset and clock specifiers reflect the numbers that
the hardware use?
Arnd
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Shuah Khan @ 2015-05-12 21:21 UTC (permalink / raw)
To: Darren Hart, Cyril Hrubis
Cc: linux-api, Linux Kernel Mailing List, John Stultz, Ingo Molnar,
Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <55526DF1.1020103@osg.samsung.com>
On 05/12/2015 03:17 PM, Shuah Khan wrote:
> On 05/12/2015 02:54 PM, Darren Hart wrote:
>> On 5/12/15, 1:40 PM, "Shuah Khan" <shuahkh@osg.samsung.com> wrote:
>>
>>> On 05/12/2015 02:15 PM, Darren Hart wrote:
>>>> On 5/12/15, 1:05 PM, "Cyril Hrubis" <chrubis@suse.cz> wrote:
>>>>
>>>>> Hi!
>>>>>>>> I'm happy to do that, but I would like to make sure I'm doing the
>>>>>> right
>>>>>>>> thing.
>>>>>>>
>>>>>>> The right thing here is to add -pthread to CFLAGS which sets both
>>>>>>> flags
>>>>>>> for preprocessor and linker (see man gcc).
>>>>>>
>>>>>> Hi Cyril,
>>>>>>
>>>>>> Thanks. I read that, and mentioned it, but my concern with -pthread in
>>>>>> the
>>>>>> CFLAGS and LDFLAGS is that it is a non-standard compiler flag. I
>>>>>> understand we have a number of gcc-isms in our build - but do we want
>>>>>> to
>>>>>> add more?
>>>>>>
>>>>>> I'm also struggling to find any kind of prescribed documentation on
>>>>>> this
>>>>>> beyond the short blurb in the gcc man page which describes what this
>>>>>> option does, but not when to use it. I'll need something concrete to
>>>>>> justify changes to testcase Makefiles to Shuah.
>>>>>
>>>>> Sorry to mislead you with the pointing at gcc man page.
>>>>>
>>>>> It is a Linux standard. Have a look at pthreads manual page:
>>>>> http://man7.org/linux/man-pages/man7/pthreads.7.html
>>>>>
>>>>> "On Linux, programs that use the Pthreads API should be compiled using
>>>>> cc -pthread."
>>>>>
>>>>> Or any pthread_foo() manual page that starts with:
>>>>>
>>>>> "Compile and link with -pthread."
>>>>>
>>>>> The portable way i.e. POSIX would be getting compiler flags with
>>>>> getconf
>>>>> but as this is a Linux kernel testsuite I would not bother with that.
>>>>> Hmm, and it looks like this is not implemented on Linux anyway.
>>>>
>>>> Thanks Cyril, that's perfect.
>>>>
>>>> I'll roll my latest example patch adding -pthread to LDFLAGS and CFLAGS
>>>> into the initial patch and resubmit the patch series as v4.
>>>>
>>>
>>> Daren,
>>>
>>> While you are generating new version, could you also please add
>>> .gitignore for the futex binaries, so they get ignored by git.
>>
>> Will do.
>>
>
> Daren,
>
> Do you plan to add futex test install support in a later patch
> series? When you sent this patch series, install support was
> work in progress. 4.1 has the kselftest install feature.
>
> Feel free to defer it for a later patch series if you like. Would
> be good to get the futex install support into 4.2 if it is possible.
>
I am blind. Never mind. futex tests are installed.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply
* Re: [PATCHv2 1/2] clone: Support passing tls argument via C rather than pt_regs magic
From: Andrew Morton @ 2015-05-12 21:22 UTC (permalink / raw)
To: Josh Triplett
Cc: Andy Lutomirski, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Thomas Gleixner, Linus Torvalds, linux-api, linux-kernel, x86
In-Reply-To: <20150511192918.GA11361@jtriplet-mobl1>
On Mon, 11 May 2015 12:29:19 -0700 Josh Triplett <josh@joshtriplett.org> wrote:
> Introduce a new CONFIG_HAVE_COPY_THREAD_TLS for architectures to opt
> into, and a new copy_thread_tls that accepts the tls parameter as an
> additional unsigned long (syscall-argument-sized) argument.
> Change sys_clone's tls argument to an unsigned long (which does
> not change the ABI), and pass that down to copy_thread_tls.
>
> Architectures that don't opt into copy_thread_tls will continue to
> ignore the C argument to sys_clone in favor of the pt_regs captured at
> kernel entry, and thus will be unable to introduce new versions of the
> clone syscall.
What happens quite frequently is that we do something for x86 with the
expectation that other architectures will follow along, but this
doesn't happen. The arch maintainers simply didn't know about it or
nobody nags them. Nothing happens and inconsistencies hang around for
years. eg, http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04993.html
I'm thinking we should find a way to do this better. One way might be
to maintain a Documentation/arch-todo which identifies each item, has a
little list of what-to-do instructions and perhaps a list of the
not-yet-done architectures. Basically a way for everyone to
communicate at the arch maintainers.
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Sage Weil @ 2015-05-12 21:35 UTC (permalink / raw)
To: Kevin Easton
Cc: Theodore Ts'o, Trond Myklebust, Dave Chinner, Zach Brown,
Alexander Viro, Linux FS-devel Mailing List,
Linux Kernel Mailing List, Linux API Mailing List
In-Reply-To: <20150512050821.GA9404-Qr0l8DEfScZEV+tojptmR0B+6BGkLq7r@public.gmane.org>
On Tue, 12 May 2015, Kevin Easton wrote:
> On Mon, May 11, 2015 at 07:10:21PM -0400, Theodore Ts'o wrote:
> > On Mon, May 11, 2015 at 09:24:09AM -0700, Sage Weil wrote:
> > > > Let me re-ask the question that I asked last week (and was apparently
> > > > ignored). Why not trying to use the lazytime feature instead of
> > > > pointing a head straight at the application's --- and system
> > > > administrators' --- heads?
> > >
> > > Sorry Ted, I thought I responded already.
> > >
> > > The goal is to avoid inode writeout entirely when we can, and
> > > as I understand it lazytime will still force writeout before the inode
> > > is dropped from the cache. In systems like Ceph in particular, the
> > > IOs can be spread across lots of files, so simply deferring writeout
> > > doesn't always help.
> >
> > Sure, but it would reduce the writeout by orders of magnitude. I can
> > understand if you want to reduce it further, but it might be good
> > enough for your purposes.
> >
> > I considered doing the equivalent of O_NOMTIME for our purposes at
> > $WORK, and our use case is actually not that different from Ceph's
> > (i.e., using a local disk file system to support a cluster file
> > system), and lazytime was (a) something I figured was something I
> > could upstream in good conscience, and (b) was more than good enough
> > for us.
>
> A safer alternative might be a chattr file attribute that if set, the
> mtime is not updated on writes, and stat() on the file always shows the
> mtime as "right now". At least that way, the file won't accidentally
> get left out of backups that rely on the mtime.
>
> (If the file attribute is unset, you immediately update the mtime then
> too, and from then on the file is back to normal).
Interesting! I didn't realize there was already a chattr +A that disabled
atime (although I suspect it doesn't do the "right now" for stat thing).
This makes the nomtime-ness a bit more obscure (I don't think most users
would think to check these file attributes), but it's a safer failure
condition for backups at least.
The fact that chattr +A (and hopefully +M) will work for non-root is a
bonus, as we're also trying to get ceph daemons to drop most privileges.
sage
^ permalink raw reply
* Re: [PATCHv2 1/2] clone: Support passing tls argument via C rather than pt_regs magic
From: Peter Zijlstra @ 2015-05-12 21:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Josh Triplett, Andy Lutomirski, Ingo Molnar, H. Peter Anvin,
Thomas Gleixner, Linus Torvalds, linux-api, linux-kernel, x86,
linux-arch
In-Reply-To: <20150512142250.dcb053da81855ae1b5861173@linux-foundation.org>
On Tue, May 12, 2015 at 02:22:50PM -0700, Andrew Morton wrote:
> On Mon, 11 May 2015 12:29:19 -0700 Josh Triplett <josh@joshtriplett.org> wrote:
>
> > Introduce a new CONFIG_HAVE_COPY_THREAD_TLS for architectures to opt
> > into, and a new copy_thread_tls that accepts the tls parameter as an
> > additional unsigned long (syscall-argument-sized) argument.
> > Change sys_clone's tls argument to an unsigned long (which does
> > not change the ABI), and pass that down to copy_thread_tls.
> >
> > Architectures that don't opt into copy_thread_tls will continue to
> > ignore the C argument to sys_clone in favor of the pt_regs captured at
> > kernel entry, and thus will be unable to introduce new versions of the
> > clone syscall.
>
> What happens quite frequently is that we do something for x86 with the
> expectation that other architectures will follow along, but this
> doesn't happen. The arch maintainers simply didn't know about it or
> nobody nags them. Nothing happens and inconsistencies hang around for
> years. eg, http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04993.html
>
> I'm thinking we should find a way to do this better. One way might be
> to maintain a Documentation/arch-todo which identifies each item, has a
> little list of what-to-do instructions and perhaps a list of the
> not-yet-done architectures. Basically a way for everyone to
> communicate at the arch maintainers.
If only there was a linux-arch list to which arch maintainers should
subscribe... oh wait :-)
^ permalink raw reply
* Re: [PATCHv2 1/2] clone: Support passing tls argument via C rather than pt_regs magic
From: Andrew Morton @ 2015-05-12 21:49 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Josh Triplett, Andy Lutomirski, Ingo Molnar, H. Peter Anvin,
Thomas Gleixner, Linus Torvalds, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-arch-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150512213843.GV21418-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
On Tue, 12 May 2015 23:38:43 +0200 Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> > What happens quite frequently is that we do something for x86 with the
> > expectation that other architectures will follow along, but this
> > doesn't happen. The arch maintainers simply didn't know about it or
> > nobody nags them. Nothing happens and inconsistencies hang around for
> > years. eg, http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04993.html
> >
> > I'm thinking we should find a way to do this better. One way might be
> > to maintain a Documentation/arch-todo which identifies each item, has a
> > little list of what-to-do instructions and perhaps a list of the
> > not-yet-done architectures. Basically a way for everyone to
> > communicate at the arch maintainers.
>
> If only there was a linux-arch list to which arch maintainers should
> subscribe... oh wait :-)
It was I who got linux-arch established, so I'm fairly familiar with
it. (12 years ago, gad).
I don't think it's been very successful, particularly for this purpose.
A whole pile of randomly cc'ed lkml overflow which we're relying on each
individual maintainer to sift through and pluck out particular action
items then later remember to implement them. It's disorganized and has
too many cracks for things to fall through.
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Dave Chinner @ 2015-05-12 21:51 UTC (permalink / raw)
To: Austin S Hemmelgarn
Cc: J. Bruce Fields, John Stoffel, Kevin Easton, Theodore Ts'o,
Sage Weil, Trond Myklebust, Zach Brown, Alexander Viro,
Linux FS-devel Mailing List, Linux Kernel Mailing List,
Linux API Mailing List
In-Reply-To: <555213E9.90701@gmail.com>
On Tue, May 12, 2015 at 10:53:29AM -0400, Austin S Hemmelgarn wrote:
> On 2015-05-12 10:36, J. Bruce Fields wrote:
> >On Tue, May 12, 2015 at 09:54:27AM -0400, John Stoffel wrote:
> >>>>>>>"Austin" == Austin S Hemmelgarn <ahferroin7@gmail.com> writes:
> >>
> >>Austin> On 2015-05-12 01:08, Kevin Easton wrote:
> >>>>On Mon, May 11, 2015 at 07:10:21PM -0400, Theodore Ts'o wrote:
> >>>>>On Mon, May 11, 2015 at 09:24:09AM -0700, Sage Weil wrote:
> >>>>>>>Let me re-ask the question that I asked last week (and was apparently
> >>>>>>>ignored). Why not trying to use the lazytime feature instead of
> >>>>>>>pointing a head straight at the application's --- and system
> >>>>>>>administrators' --- heads?
> >>>>>>
> >>>>>>Sorry Ted, I thought I responded already.
> >>>>>>
> >>>>>>The goal is to avoid inode writeout entirely when we can, and
> >>>>>>as I understand it lazytime will still force writeout before the inode
> >>>>>>is dropped from the cache. In systems like Ceph in particular, the
> >>>>>>IOs can be spread across lots of files, so simply deferring writeout
> >>>>>>doesn't always help.
> >>>>>
> >>>>>Sure, but it would reduce the writeout by orders of magnitude. I can
> >>>>>understand if you want to reduce it further, but it might be good
> >>>>>enough for your purposes.
> >>>>>
> >>>>>I considered doing the equivalent of O_NOMTIME for our purposes at
> >>>>>$WORK, and our use case is actually not that different from Ceph's
> >>>>>(i.e., using a local disk file system to support a cluster file
> >>>>>system), and lazytime was (a) something I figured was something I
> >>>>>could upstream in good conscience, and (b) was more than good enough
> >>>>>for us.
> >>>>
> >>>>A safer alternative might be a chattr file attribute that if set, the
> >>>>mtime is not updated on writes, and stat() on the file always shows the
> >>>>mtime as "right now". At least that way, the file won't accidentally
> >>>>get left out of backups that rely on the mtime.
> >>>>
> >>>>(If the file attribute is unset, you immediately update the mtime then
> >>>>too, and from then on the file is back to normal).
> >>>>
> >>
> >>Austin> I like this even better than the flag suggestion, it provides
> >>Austin> better control, means that you don't need to update
> >>Austin> applications to get the benefits, and prevents backup software
> >>Austin> from breaking (although backups would be bigger).
> >>
> >>Me too, it fails in a safer mode, where you do more work on backups
> >>than strictly needed. I'm still against this as a mount option
> >>though, way way way too many bullets in the foot gun. And as someone
> >>else said, once you mount with O_NOMTIME, then unmount, then mount
> >>again without O_NOMTIME, you've lost information. Not good.
> >
> >That was me. Zach also pointed out to me that'd mean figuring out where
> >to store that information on-disk for every filesystem you care about.
> >I like the idea of something persistent, but maybe it's more trouble
> >than it's worth--I honestly don't know.
> >
> But if we do it as a flag controlled by the API used by chattr, it
> becomes the responsibility of the filesystems to deal with where to
> store the information, assuming they choose to support it;
> personally, I would be really surprised if XFS and BTRFS didn't add
> support for this relatively soon after the API getting merged
> upstream, and ext4 would likely follow soon afterwards.
It's an on-disk format change, which means that there are all sorts
of compatibility issues to take into account, as well as all the
work needed to teach the filesystem userspace tools about the new
flag. e.g. xfs_repair, xfs_db, xfsdump/restore, xfs_io, test code in
xfstests, etc.
Keep in mind that the moment we make something persistent, the
amount of work to implement and verify the new functionality
filesystem to implement it goes up by an order of magnitude *for
each filesystem*. IOWs, support of new features that require
persistence don't just magically appear overnight...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH 5/6] nohz: support PR_DATAPLANE_STRICT mode
From: Andy Lutomirski @ 2015-05-12 22:23 UTC (permalink / raw)
To: Chris Metcalf
Cc: Paul E. McKenney, Frederic Weisbecker,
linux-kernel@vger.kernel.org, Rik van Riel, Andrew Morton,
Linux API, Thomas Gleixner, Tejun Heo, Peter Zijlstra,
Steven Rostedt, linux-doc@vger.kernel.org, Christoph Lameter,
Gilad Ben Yossef, Ingo Molnar
In-Reply-To: <55526B39.10208@ezchip.com>
On May 13, 2015 6:06 AM, "Chris Metcalf" <cmetcalf@ezchip.com> wrote:
>
> On 05/11/2015 06:28 PM, Andy Lutomirski wrote:
>>
>> [add peterz due to perf stuff]
>>
>> On Mon, May 11, 2015 at 12:13 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>>>
>>> Patch 6/6 proposes a mechanism to track down times when the
>>> kernel screws up and delivers an IRQ to a userspace-only task.
>>> Here, we're just trying to identify the times when an application
>>> screws itself up out of cluelessness, and provide a mechanism
>>> that allows the developer to easily figure out why and fix it.
>>>
>>> In particular, /proc/interrupts won't show syscalls or page faults,
>>> which are two easy ways applications can screw themselves
>>> when they think they're in userspace-only mode. Also, they don't
>>> provide sufficient precision to make it clear what part of the
>>> application caused the undesired kernel entry.
>>
>> Perf does, though, complete with context.
>
>
> The perf_event suggestions are interesting, but I think it's plausible
> for this to be an alternate way to debug the issues that STRICT
> addresses.
>
>
>>> In this case, killing the task is appropriate, since that's exactly
>>> the semantics that have been asked for - it's like on architectures
>>> that don't natively support unaligned accesses, but fake it relatively
>>> slowly in the kernel, and in development you just say "give me a
>>> SIGBUS when that happens" and in production you might say
>>> "fix it up and let's try to keep going".
>>
>> I think more control is needed. I also think that, if we go this
>> route, we should distinguish syscalls, synchronous non-syscall
>> entries, and asynchronous non-syscall entries. They're quite
>> different.
>
>
> I don't think it's necessary to distinguish the types. As long as we
> have a PC pointing to the instruction that triggered the problem,
> we can see if it's a system call instruction, a memory write that
> caused a page fault, a trap instruction, etc.
Not true. PC right after a syscall insn could be any type of kernel
entry, and you can't even reliably tell whether the syscall insn was
executed or, on x86, whether it was a syscall at all. (x86 insns
can't be reliably decided backwards.)
PC pointing at a load could be a page fault or an IPI.
> We certainly could
> add infrastructure to capture syscall numbers, fault/signal numbers,
> etc etc, but I think it's overkill if it adds kernel overhead on
> entry/exit.
>
None of these should add overhead.
>
>>> A better implementation, I think, is to put the tests for "you
>>> screwed up and synchronously entered the kernel" in
>>> the syscall_trace_enter() code, which TIF_NOHZ already
>>> gets us into;
>>
>> No, not unless you're planning on using that to distinguish syscalls
>> from other stuff *and* people think that's justified.
>
>
> So, the question is how we separate synchronous entries
> from IRQs? At a high level, IRQs are kernel bugs (for cpu-isolated
> tasks), and synchronous entries are application bugs. We'd
> like to deliver a signal for the latter, and do some kind of
> kernel diagnostics for the former. So we can't just add the
> test in the context tracking code, which doesn't actually know
> why we're entering or exiting.
Synchronous entries could be VM bugs, too.
>
> That's why I was thinking that the syscall_trace_entry and
> exception_enter paths were the best choices. I'm fairly sure
> that exception_enter is only done for synchronous traps,
> page faults, etc.
Maybe. Doing it through the actual entry/exit slow paths would be
overhead-free, although I'm not sure that IRQs have real slow paths
for entry.
>
> Certainly on the tile architecture we include the trap number
> in the pt_regs, so it's possible to just examine the pt_regs and
> know why you entered or are exiting the kernel, but I don't
> think we can rely on that for all architectures.
x86 can't do this.
> I'll put out a v2 of my patch that does both the things you
> advise against :-) just so we can have a strawman to think
> about how to do it better - unless you have a suggestion
> offhand as to how we can better differentiate sync and async
> entries into the kernel in a platform-independent way.
>
> I could imagine modifying user_exit() and exception_enter()
> to pass an identifier into the context system saying why they
> were changing contexts, so we could have syscalls, trap
> numbers, fault numbers, etc., and some way to query as
> to whether they were synchronous or asynchronous, and
> build this scheme on top of that, but I'm not sure the extra
> infrastructure is worthwhile.
>
I'll take a look.
Again, though, I think we really do need to distinguish at least MCE
and NMI (on x86) from the others.
>
>> What if we added a mode to perf where delivery of a sample
>> synchronously (or semi-synchronously by catching it on the next exit
>> to userspace) freezes the delivering task? It would be like debugger
>> support via perf.
>>
>> peterz, do you think this would be a sensible thing to add to perf?
>> It would only make sense for some types of events (tracepoints and
>> hw_breakpoints mostly, I think).
>
>
> I suspect it's reasonable to consider this orthogonal, particularly
> if there is some skid between the actual violation by the
> application, and the freeze happening.
>
I think it could be done without skid, except for async entries, but
for asynx entries we don't care about exact user state anyway.
> You pushed back somewhat on prctl() in favor of a quiesce()
> syscall in your email, but it seemed like at the end of your
> email you were adopting the prctl() perspective. Is that true?
> I admit the prctl() still seems cleaner from my perspective.
>
Prctl for the strict thing seems much more reasonable to me than prctl
for quiescing. Also, the scheduler people seem to thing that
quiescing should be automatic.
Anyway, I'll happily look at code and maybe even write more coherent
emails when I'm back in town in a week. Since you're thinking that
async entries should give kernel diagnostics instead of signals, maybe
the right thing to do is to separate them out completely and try to
address the individual entry types separately and as needed.
--Andy
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: NeilBrown @ 2015-05-12 22:39 UTC (permalink / raw)
To: J. Bruce Fields
Cc: John Stoffel, Austin S Hemmelgarn, Kevin Easton,
Theodore Ts'o, Sage Weil, Trond Myklebust, Dave Chinner,
Zach Brown, Alexander Viro, Linux FS-devel Mailing List,
Linux Kernel Mailing List, Linux API Mailing List
In-Reply-To: <20150512143637.GA6370-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3901 bytes --]
On Tue, 12 May 2015 10:36:37 -0400 bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org (J. Bruce Fields)
wrote:
> On Tue, May 12, 2015 at 09:54:27AM -0400, John Stoffel wrote:
> > >>>>> "Austin" == Austin S Hemmelgarn <ahferroin7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >
> > Austin> On 2015-05-12 01:08, Kevin Easton wrote:
> > >> On Mon, May 11, 2015 at 07:10:21PM -0400, Theodore Ts'o wrote:
> > >>> On Mon, May 11, 2015 at 09:24:09AM -0700, Sage Weil wrote:
> > >>>>> Let me re-ask the question that I asked last week (and was apparently
> > >>>>> ignored). Why not trying to use the lazytime feature instead of
> > >>>>> pointing a head straight at the application's --- and system
> > >>>>> administrators' --- heads?
> > >>>>
> > >>>> Sorry Ted, I thought I responded already.
> > >>>>
> > >>>> The goal is to avoid inode writeout entirely when we can, and
> > >>>> as I understand it lazytime will still force writeout before the inode
> > >>>> is dropped from the cache. In systems like Ceph in particular, the
> > >>>> IOs can be spread across lots of files, so simply deferring writeout
> > >>>> doesn't always help.
> > >>>
> > >>> Sure, but it would reduce the writeout by orders of magnitude. I can
> > >>> understand if you want to reduce it further, but it might be good
> > >>> enough for your purposes.
> > >>>
> > >>> I considered doing the equivalent of O_NOMTIME for our purposes at
> > >>> $WORK, and our use case is actually not that different from Ceph's
> > >>> (i.e., using a local disk file system to support a cluster file
> > >>> system), and lazytime was (a) something I figured was something I
> > >>> could upstream in good conscience, and (b) was more than good enough
> > >>> for us.
> > >>
> > >> A safer alternative might be a chattr file attribute that if set, the
> > >> mtime is not updated on writes, and stat() on the file always shows the
> > >> mtime as "right now". At least that way, the file won't accidentally
> > >> get left out of backups that rely on the mtime.
> > >>
> > >> (If the file attribute is unset, you immediately update the mtime then
> > >> too, and from then on the file is back to normal).
> > >>
> >
> > Austin> I like this even better than the flag suggestion, it provides
> > Austin> better control, means that you don't need to update
> > Austin> applications to get the benefits, and prevents backup software
> > Austin> from breaking (although backups would be bigger).
> >
> > Me too, it fails in a safer mode, where you do more work on backups
> > than strictly needed. I'm still against this as a mount option
> > though, way way way too many bullets in the foot gun. And as someone
> > else said, once you mount with O_NOMTIME, then unmount, then mount
> > again without O_NOMTIME, you've lost information. Not good.
>
> That was me. Zach also pointed out to me that'd mean figuring out where
> to store that information on-disk for every filesystem you care about.
> I like the idea of something persistent, but maybe it's more trouble
> than it's worth--I honestly don't know.
>
When this persistent flag is in effect, the values stored in mtime and atime,
and probably ctime, become irrelevant. Surely we can choose some magic value
to store there that would never happen in practice.
e.g. ctime is signed and so goes back to 1902 (is that right?). As ctime
cannot be set (via POSIX) to anything but "now", and as there were no Unix
systems in 1902, such values are impossible.
So a specific large negative value in ctime could safely be take to mean
"don't update time stamps, and always report them as 'now'".
Or do we need to keep ctime 'real'?
BTW When you "swap" to a file the mtime doesn't get updated. No one seems to
complain about that. I guess it is a rather narrow use-case though.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Sage Weil @ 2015-05-12 23:12 UTC (permalink / raw)
To: Dave Chinner
Cc: Trond Myklebust, Zach Brown, Alexander Viro,
Linux FS-devel Mailing List, Linux Kernel Mailing List,
Linux API Mailing List
In-Reply-To: <20150512012133.GR4327@dastard>
On Tue, 12 May 2015, Dave Chinner wrote:
> > > Neither of these examples cases are under the control of the
> > > application that calls open(O_NOMTIME).
> >
> > Wouldn't a mount option (e.g., allow_nomtime) address this concern? Only
> > nodes provisioned explicitly to run these systems would be enable this
> > option.
>
> Back to my Joe Speedracer comments.....
>
> I'm not sure what the right answer is - mount options are simply too
> easy to add without understanding the full implications of them.
> e.g. we didn't merge FALLOC_FL_NO_HIDE_STALE simply because it was
> too dangerous for unsuspecting users. This isn't at that same level
> or concern, but it's still a landmine we want to avoid users from
> arming without realising it...
>
> > > >> I'm happy for it to be an ioctl interface - even an XFS specific
> > > >> interface if you want to go that route, Sage - and it probably
> > > >> should emit a warning to syslog first time it is used so there is
> > > >> trace for bug triage purposes. i.e. we know the app is not using
> > > >> mtime updates, so bug reports that are the result of mtime
> > > >> mishandling don't result in large amounts of wasted developer time
> > > >> trying to understand them...
> > > >
> > > > A warning on using the interface (or when mounting with user_nomtime)
> > > > sounds reasonable.
> > > >
> > > > I'd rather not make this XFS specific as other local filesystmes (ext4,
> > > > f2fs, possibly btrfs) would similarly benefit. (And if we want to target
> > > > XFS specifically the existing XFS open-by-handle ioctl is sufficient as it
> > > > already does O_NOMTIME unconditionally.)
> > >
> > > Lack of a namespace, doesn't imply that you don't want to manage the
> > > data. The whole point of using object storage instead of plain old
> > > block storage is to be able to provide whatever metadata you still
> > > need in order to manage the object.
> >
> > Yeah, agreed--this is presumably why open_by_handle(2) (which is what we'd
> > like to use) doesn't assume O_NOMTIME.
>
> Right - the XFS ioctls were designed specifically for applications
> that interacted directly with the structure of XFS filesystems and
> so needed invisible IO (e.g. online defragmenter). IOWs, they are
> not interfaces intended for general usage. They are also only
> available to root, so a typical user application won't be making use
> of them, either.
I understand that's what they're intended for, but I'm having a hard time
parsing out the difference between what they *do* and what O_NOMTIME + -o
allow_nomtime does. The open-by-handle ioctls have nothing to do with the
online XFS format--they simply allow you to open a file via an opaque
handle (albeit a differently formatted one than the generic
open_by_handle_at(2)). They also force you into an O_NOMTIME-equivalent
mode.
AFAICS the only difference that I see is that
1) the ioctl is XFS specific. (As open_by_handle_at(2) demonstrates, this
needn't be the case.)
2) the NOMTIME mode is only available via the open-by-handle interface,
not open(2).
3) it is an ioctl interface, and thus more obscure. (Well, there is a
libhandle library, but it doesn't seem to be widely used.)
Would you object less if
1) the O_NOMTIME flag were only available via open_by_handle_at(2)?
2) an equivalent ioctl were implemented for each file system of interest
that (say) called into open_by_handle_at(2) code, adding in the O_NOMTIME
flag?
3) O_NOMTIME required root (vs a mount option that requires root and
unpriviledged O_NOMTIME)?
Just trying to tease apart which part is problematic...
Thanks!
sage
^ permalink raw reply
* Re: [PATCHv2 1/2] clone: Support passing tls argument via C rather than pt_regs magic
From: josh-iaAMLnmF4UmaiuxdJuQwMA @ 2015-05-13 0:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Andy Lutomirski, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Thomas Gleixner, Linus Torvalds, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20150512142250.dcb053da81855ae1b5861173-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Tue, May 12, 2015 at 02:22:50PM -0700, Andrew Morton wrote:
> On Mon, 11 May 2015 12:29:19 -0700 Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org> wrote:
>
> > Introduce a new CONFIG_HAVE_COPY_THREAD_TLS for architectures to opt
> > into, and a new copy_thread_tls that accepts the tls parameter as an
> > additional unsigned long (syscall-argument-sized) argument.
> > Change sys_clone's tls argument to an unsigned long (which does
> > not change the ABI), and pass that down to copy_thread_tls.
> >
> > Architectures that don't opt into copy_thread_tls will continue to
> > ignore the C argument to sys_clone in favor of the pt_regs captured at
> > kernel entry, and thus will be unable to introduce new versions of the
> > clone syscall.
>
> What happens quite frequently is that we do something for x86 with the
> expectation that other architectures will follow along, but this
> doesn't happen. The arch maintainers simply didn't know about it or
> nobody nags them. Nothing happens and inconsistencies hang around for
> years. eg, http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04993.html
In this case, there will be a very clear incentive to switch to
CONFIG_HAVE_COPY_THREAD_TLS: if you don't, you can't enable new
syscalls.
- Josh Triplett
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Dave Chinner @ 2015-05-13 0:57 UTC (permalink / raw)
To: Sage Weil
Cc: Trond Myklebust, Zach Brown, Alexander Viro,
Linux FS-devel Mailing List, Linux Kernel Mailing List,
Linux API Mailing List
In-Reply-To: <alpine.DEB.2.00.1505121454000.20395@cobra.newdream.net>
On Tue, May 12, 2015 at 04:12:46PM -0700, Sage Weil wrote:
> On Tue, 12 May 2015, Dave Chinner wrote:
> > > > > I'd rather not make this XFS specific as other local filesystmes (ext4,
> > > > > f2fs, possibly btrfs) would similarly benefit. (And if we want to target
> > > > > XFS specifically the existing XFS open-by-handle ioctl is sufficient as it
> > > > > already does O_NOMTIME unconditionally.)
> > > >
> > > > Lack of a namespace, doesn't imply that you don't want to manage the
> > > > data. The whole point of using object storage instead of plain old
> > > > block storage is to be able to provide whatever metadata you still
> > > > need in order to manage the object.
> > >
> > > Yeah, agreed--this is presumably why open_by_handle(2) (which is what we'd
> > > like to use) doesn't assume O_NOMTIME.
> >
> > Right - the XFS ioctls were designed specifically for applications
> > that interacted directly with the structure of XFS filesystems and
> > so needed invisible IO (e.g. online defragmenter). IOWs, they are
> > not interfaces intended for general usage. They are also only
> > available to root, so a typical user application won't be making use
> > of them, either.
>
> I understand that's what they're intended for, but I'm having a hard time
> parsing out the difference between what they *do* and what O_NOMTIME + -o
> allow_nomtime does. The open-by-handle ioctls have nothing to do with the
> online XFS format--they simply allow you to open a file via an opaque
> handle (albeit a differently formatted one than the generic
> open_by_handle_at(2)). They also force you into an O_NOMTIME-equivalent
> mode.
Actually, the handle is dervied from the information on disk. We
don't do directory lookups to build handles in many cases, we do a
bulkstat to get *on-disk* inode information (inode number, generation,
timestamps, etc) and then use that to build a handle in userspace
*and* validate the file has not changed since the infomration was
retrieved and the handle was built.
> AFAICS the only difference that I see is that
>
> 1) the ioctl is XFS specific. (As open_by_handle_at(2) demonstrates, this
> needn't be the case.)
Of course - it's been in use for 15 years longer than the generic
interface. :)
> 2) the NOMTIME mode is only available via the open-by-handle interface,
> not open(2).
Right, because of the XFS handle interfaces are intended for
invisible IO which is required by applications interacting directly
with the XFS on-disk data layout.
> 3) it is an ioctl interface, and thus more obscure. (Well, there is a
> libhandle library, but it doesn't seem to be widely used.)
The library only exists for xfsdump and the HSMs that interact
directly with the XFS on disk data. These are very constrained
applications.
> Would you object less if
>
> 1) the O_NOMTIME flag were only available via open_by_handle_at(2)?
Which limits it to files that have already by created and written to
disk, otherwise there is no handle....
> 2) an equivalent ioctl were implemented for each file system of interest
> that (say) called into open_by_handle_at(2) code, adding in the O_NOMTIME
> flag?
Seems like a silly hoop to jump through. I was thinking of a
root-only fcntl() style flag that could be set, but....
> 3) O_NOMTIME required root (vs a mount option that requires root and
> unpriviledged O_NOMTIME)?
>
> Just trying to tease apart which part is problematic...
... it's very existence ias either a open or fcntl flag is still
problematic. :/
The concept of it being an on-disk attribute flag is less prone to
silent abuse - it's easily discoverable and is persistent. And it's
managable if we make it an "inherit from parent" style flag, because
then ceph can simply set it on the root dir, and every file it then
creates will not do mtime updates.
The other thing that is worth noting here is that we also have a
NODUMP flag on disk (chattr +d). Hence we could define that the
nomtime attribute also implies/sets the nodump attribute, and hence
makes it clear and upfront that turning on the nomtime inode
attribute will mean the files with this set will not get backed up
by mtime sensitive backup programs....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* [RFC] net: support SOCK_DONTWAIT for non-blocking accept4
From: Eric Wong @ 2015-05-13 2:37 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Michael Kerrisk, linux-api-u79uwXL29TY76Z2rM5mHXA
It may occasionally be useful to share a listen socket between two
or more tasks with different processing models (blocking and
non-blocking).
This may happen during a software upgrade when an older process
(using blocking I/O) shares the listen socket with a new process
which wants to use non-blocking I/O, but still provides a path for
the old process to fall back to blocking I/O and avoiding poll()
for exclusive wakeup if the upgrade does not work out.
Proposed manpage addtion:
SOCK_DONTWAIT
Enable non-blocking operation on the listen socket for this call only.
Unlike SOCK_NONBLOCK, this does not affect the accepted socket, nor does
it change the file status flag of the listen socket for other calls.
Signed-off-by: Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>
---
RFC since this seems a bit esoteric, and I'm not sure if it'd be
useful to others. I've certainly wished I've had it a few times
along with an opposite SOCK_MUSTWAIT flag to ignore O_NONBLOCK on
a listen socket.
include/linux/net.h | 3 +++
net/socket.c | 10 ++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/include/linux/net.h b/include/linux/net.h
index 17d8339..9a71654 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -76,6 +76,9 @@ enum sock_type {
#ifndef SOCK_NONBLOCK
#define SOCK_NONBLOCK O_NONBLOCK
#endif
+#ifndef SOCK_DONTWAIT
+#define SOCK_DONTWAIT MSG_DONTWAIT
+#endif
#endif /* ARCH_HAS_SOCKET_TYPES */
diff --git a/net/socket.c b/net/socket.c
index 245330c..52395df 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1294,6 +1294,7 @@ SYSCALL_DEFINE3(socket, int, family, int, type, int, protocol)
BUILD_BUG_ON((SOCK_MAX | SOCK_TYPE_MASK) != SOCK_TYPE_MASK);
BUILD_BUG_ON(SOCK_CLOEXEC & SOCK_TYPE_MASK);
BUILD_BUG_ON(SOCK_NONBLOCK & SOCK_TYPE_MASK);
+ BUILD_BUG_ON(SOCK_DONTWAIT & SOCK_TYPE_MASK);
flags = type & ~SOCK_TYPE_MASK;
if (flags & ~(SOCK_CLOEXEC | SOCK_NONBLOCK))
@@ -1502,8 +1503,9 @@ SYSCALL_DEFINE4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr,
struct file *newfile;
int err, len, newfd, fput_needed;
struct sockaddr_storage address;
+ int f_flags;
- if (flags & ~(SOCK_CLOEXEC | SOCK_NONBLOCK))
+ if (flags & ~(SOCK_CLOEXEC | SOCK_NONBLOCK | SOCK_DONTWAIT))
return -EINVAL;
if (SOCK_NONBLOCK != O_NONBLOCK && (flags & SOCK_NONBLOCK))
@@ -1513,6 +1515,10 @@ SYSCALL_DEFINE4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr,
if (!sock)
goto out;
+ f_flags = sock->file->f_flags;
+ if (flags & SOCK_DONTWAIT)
+ f_flags |= O_NONBLOCK;
+
err = -ENFILE;
newsock = sock_alloc();
if (!newsock)
@@ -1545,7 +1551,7 @@ SYSCALL_DEFINE4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr,
if (err)
goto out_fd;
- err = sock->ops->accept(sock, newsock, sock->file->f_flags);
+ err = sock->ops->accept(sock, newsock, f_flags);
if (err < 0)
goto out_fd;
--
EW
^ permalink raw reply related
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Darren Hart @ 2015-05-13 3:34 UTC (permalink / raw)
To: Shuah Khan
Cc: Darren Hart, Cyril Hrubis, linux-api-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, John Stultz, Ingo Molnar,
Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <55526EC8.30707-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, May 12, 2015 at 03:21:12PM -0600, Shuah Khan wrote:
> On 05/12/2015 03:17 PM, Shuah Khan wrote:
> > On 05/12/2015 02:54 PM, Darren Hart wrote:
> >> On 5/12/15, 1:40 PM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
> >>
> >>> On 05/12/2015 02:15 PM, Darren Hart wrote:
> >>>> On 5/12/15, 1:05 PM, "Cyril Hrubis" <chrubis-AlSwsSmVLrQ@public.gmane.org> wrote:
> >>>>
> >>>>> Hi!
> >>>>>>>> I'm happy to do that, but I would like to make sure I'm doing the
> >>>>>> right
> >>>>>>>> thing.
> >>>>>>>
> >>>>>>> The right thing here is to add -pthread to CFLAGS which sets both
> >>>>>>> flags
> >>>>>>> for preprocessor and linker (see man gcc).
> >>>>>>
> >>>>>> Hi Cyril,
> >>>>>>
> >>>>>> Thanks. I read that, and mentioned it, but my concern with -pthread in
> >>>>>> the
> >>>>>> CFLAGS and LDFLAGS is that it is a non-standard compiler flag. I
> >>>>>> understand we have a number of gcc-isms in our build - but do we want
> >>>>>> to
> >>>>>> add more?
> >>>>>>
> >>>>>> I'm also struggling to find any kind of prescribed documentation on
> >>>>>> this
> >>>>>> beyond the short blurb in the gcc man page which describes what this
> >>>>>> option does, but not when to use it. I'll need something concrete to
> >>>>>> justify changes to testcase Makefiles to Shuah.
> >>>>>
> >>>>> Sorry to mislead you with the pointing at gcc man page.
> >>>>>
> >>>>> It is a Linux standard. Have a look at pthreads manual page:
> >>>>> http://man7.org/linux/man-pages/man7/pthreads.7.html
> >>>>>
> >>>>> "On Linux, programs that use the Pthreads API should be compiled using
> >>>>> cc -pthread."
> >>>>>
> >>>>> Or any pthread_foo() manual page that starts with:
> >>>>>
> >>>>> "Compile and link with -pthread."
> >>>>>
> >>>>> The portable way i.e. POSIX would be getting compiler flags with
> >>>>> getconf
> >>>>> but as this is a Linux kernel testsuite I would not bother with that.
> >>>>> Hmm, and it looks like this is not implemented on Linux anyway.
> >>>>
> >>>> Thanks Cyril, that's perfect.
> >>>>
> >>>> I'll roll my latest example patch adding -pthread to LDFLAGS and CFLAGS
> >>>> into the initial patch and resubmit the patch series as v4.
> >>>>
> >>>
> >>> Daren,
> >>>
> >>> While you are generating new version, could you also please add
> >>> .gitignore for the futex binaries, so they get ignored by git.
> >>
> >> Will do.
> >>
> >
> > Daren,
> >
> > Do you plan to add futex test install support in a later patch
> > series? When you sent this patch series, install support was
> > work in progress. 4.1 has the kselftest install feature.
> >
> > Feel free to defer it for a later patch series if you like. Would
> > be good to get the futex install support into 4.2 if it is possible.
> >
>
> I am blind. Never mind. futex tests are installed.
Oh good - I just reviewed my patches and could swear it was all there!
I'll add the .gitignore now and roll out v4 with all the cleanups and pthread
linker fixes.
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply
* [PATCH v4 0/6] selftests: Add futex functional tests
From: Darren Hart @ 2015-05-13 4:07 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Shuah Khan, linux-api-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar,
Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro,
Darren Hart, chrubis-AlSwsSmVLrQ
Hi Shuah,
This series begins the process of migrating my futextest tests into kselftest.
I've started with only the functional tests, as the performance and stress may
not be appropriate for kselftest as they stand.
I cleaned up various complaints from checkpatch, but I ignored others that would
require significant rework of the testcases, such as not using volatile and not
creating new typedefs.
Since v1:
Avoid checkpatch errors on 1/5 by:
- combining a later patch which did substantial cleanup.
- removing file-local typedefs and replacing with structs
- correcting all >80 char lines, except for quoted strings and header boiler
plate due to long email addresses
I did *not* make changes for the following:
- Use of new typdefs for types futex_t and atomic_t as they are used throughout
the test suite and I consider them to be worth while.
- Use of volatile as the warning is about use of volatile in kernel code. The
usage in futextest is correct, as an indicator that other threads may modify
the value.
- Adding parentheses around complex defines as it would break one use case and
change the behavior of another.
Since v2:
- Remove trailing newline from selftests/futex/functional/run.sh
Since v3:
- Replace -lpthread in LDFLAGS with -pthread in LDFLAGS and CFLAGS
- Add .gitignore for the target files (compiled tests)
- Resolved bad content encoding header in my patch submission process
The patches will follow, but I'm providing a pull request for your convenience
as well.
The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
are available in the git repository at:
git://git.infradead.org/users/dvhart/linux.git futextest-v4
Darren Hart (6):
selftests: Add futex functional tests
selftests/futex: Update Makefile to use lib.mk
selftests/futex: Increment ksft pass and fail counters
selftests: Add futex tests to the top-level Makefile
kselftest: Add exit code defines
selftests/futex: Add .gitignore
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/futex/Makefile | 29 ++
tools/testing/selftests/futex/README | 62 ++++
.../testing/selftests/futex/functional/.gitignore | 7 +
tools/testing/selftests/futex/functional/Makefile | 25 ++
.../selftests/futex/functional/futex_requeue_pi.c | 409 +++++++++++++++++++++
.../functional/futex_requeue_pi_mismatched_ops.c | 135 +++++++
.../functional/futex_requeue_pi_signal_restart.c | 223 +++++++++++
.../functional/futex_wait_private_mapped_file.c | 125 +++++++
.../futex/functional/futex_wait_timeout.c | 86 +++++
.../functional/futex_wait_uninitialized_heap.c | 124 +++++++
.../futex/functional/futex_wait_wouldblock.c | 79 ++++
tools/testing/selftests/futex/functional/run.sh | 79 ++++
tools/testing/selftests/futex/include/atomic.h | 83 +++++
tools/testing/selftests/futex/include/futextest.h | 266 ++++++++++++++
tools/testing/selftests/futex/include/logging.h | 153 ++++++++
tools/testing/selftests/futex/run.sh | 33 ++
tools/testing/selftests/kselftest.h | 17 +-
18 files changed, 1931 insertions(+), 5 deletions(-)
create mode 100644 tools/testing/selftests/futex/Makefile
create mode 100644 tools/testing/selftests/futex/README
create mode 100644 tools/testing/selftests/futex/functional/.gitignore
create mode 100644 tools/testing/selftests/futex/functional/Makefile
create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi.c
create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
create mode 100644 tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
create mode 100644 tools/testing/selftests/futex/functional/futex_wait_timeout.c
create mode 100644 tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c
create mode 100644 tools/testing/selftests/futex/functional/futex_wait_wouldblock.c
create mode 100755 tools/testing/selftests/futex/functional/run.sh
create mode 100644 tools/testing/selftests/futex/include/atomic.h
create mode 100644 tools/testing/selftests/futex/include/futextest.h
create mode 100644 tools/testing/selftests/futex/include/logging.h
create mode 100755 tools/testing/selftests/futex/run.sh
--
2.1.4
^ permalink raw reply
* [PATCH 1/6] selftests: Add futex functional tests
From: Darren Hart @ 2015-05-13 4:07 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: chrubis-AlSwsSmVLrQ, Darren Hart, Shuah Khan,
linux-api-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Peter Zijlstra,
Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <cover.1431489408.git.dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
The futextest testsuite [1] provides functional, stress, and
performance tests for the various futex op codes. Those tests will be of
more use to futex developers if they are included with the kernel
source.
Copy the core infrastructure and the functional tests into selftests,
but adapt them for inclusion in the kernel:
- Update the Makefile to include the run_tests target, remove reference
to the performance and stress tests from the contributed sources.
- Replace my dead IBM email address with my current Intel email address.
- Remove the warrantee and write-to paragraphs from the license blurbs.
- Remove the NAME section as the filename is easily determined. ;-)
- Make the whitespace usage consistent in a couple of places.
- Cleanup various CodingStyle violations.
A future effort will explore moving the performance and stress tests
into the kernel.
1. http://git.kernel.org/cgit/linux/kernel/git/dvhart/futextest.git
Cc: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Davidlohr Bueso <dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
Cc: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Signed-off-by: Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
tools/testing/selftests/futex/Makefile | 11 +
tools/testing/selftests/futex/README | 62 ++++
tools/testing/selftests/futex/functional/Makefile | 24 ++
.../selftests/futex/functional/futex_requeue_pi.c | 409 +++++++++++++++++++++
.../functional/futex_requeue_pi_mismatched_ops.c | 135 +++++++
.../functional/futex_requeue_pi_signal_restart.c | 223 +++++++++++
.../functional/futex_wait_private_mapped_file.c | 125 +++++++
.../futex/functional/futex_wait_timeout.c | 86 +++++
.../functional/futex_wait_uninitialized_heap.c | 124 +++++++
.../futex/functional/futex_wait_wouldblock.c | 79 ++++
tools/testing/selftests/futex/functional/run.sh | 79 ++++
tools/testing/selftests/futex/include/atomic.h | 83 +++++
tools/testing/selftests/futex/include/futextest.h | 266 ++++++++++++++
tools/testing/selftests/futex/include/logging.h | 150 ++++++++
tools/testing/selftests/futex/run.sh | 33 ++
15 files changed, 1889 insertions(+)
create mode 100644 tools/testing/selftests/futex/Makefile
create mode 100644 tools/testing/selftests/futex/README
create mode 100644 tools/testing/selftests/futex/functional/Makefile
create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi.c
create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
create mode 100644 tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
create mode 100644 tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
create mode 100644 tools/testing/selftests/futex/functional/futex_wait_timeout.c
create mode 100644 tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c
create mode 100644 tools/testing/selftests/futex/functional/futex_wait_wouldblock.c
create mode 100755 tools/testing/selftests/futex/functional/run.sh
create mode 100644 tools/testing/selftests/futex/include/atomic.h
create mode 100644 tools/testing/selftests/futex/include/futextest.h
create mode 100644 tools/testing/selftests/futex/include/logging.h
create mode 100755 tools/testing/selftests/futex/run.sh
diff --git a/tools/testing/selftests/futex/Makefile b/tools/testing/selftests/futex/Makefile
new file mode 100644
index 0000000..2c26d59
--- /dev/null
+++ b/tools/testing/selftests/futex/Makefile
@@ -0,0 +1,11 @@
+SUBDIRS := functional
+
+.PHONY: all clean
+all:
+ for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done
+
+run_tests: all
+ ./run.sh
+
+clean:
+ for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done
diff --git a/tools/testing/selftests/futex/README b/tools/testing/selftests/futex/README
new file mode 100644
index 0000000..3224a04
--- /dev/null
+++ b/tools/testing/selftests/futex/README
@@ -0,0 +1,62 @@
+Futex Test
+==========
+Futex Test is intended to thoroughly test the Linux kernel futex system call
+API.
+
+Functional tests shall test the documented behavior of the futex operation
+code under test. This includes checking for proper behavior under normal use,
+odd corner cases, regression tests, and abject abuse and misuse.
+
+Futextest will also provide example implementation of mutual exclusion
+primitives. These can be used as is in user applications or can serve as
+examples for system libraries. These will likely be added to either a new lib/
+directory or purely as header files under include/, I'm leaning toward the
+latter.
+
+Quick Start
+-----------
+# make
+# ./run.sh
+
+Design and Implementation Goals
+-------------------------------
+o Tests should be as self contained as is practical so as to facilitate sharing
+ the individual tests on mailing list discussions and bug reports.
+o The build system shall remain as simple as possible, avoiding any archive or
+ shared object building and linking.
+o Where possible, any helper functions or other package-wide code shall be
+ implemented in header files, avoiding the need to compile intermediate object
+ files.
+o External dependendencies shall remain as minimal as possible. Currently gcc
+ and glibc are the only dependencies.
+o Tests return 0 for success and < 0 for failure.
+
+Output Formatting
+-----------------
+Test output shall be easily parsable by both human and machine. Title and
+results are printed to stdout, while intermediate ERROR or FAIL messages are
+sent to stderr. Tests shall support the -c option to print PASS, FAIL, and
+ERROR strings in color for easy visual parsing. Output shall conform to the
+following format:
+
+test_name: Description of the test
+ Arguments: arg1=val1 #units specified for clarity where appropriate
+ ERROR: Description of unexpected error
+ FAIL: Reason for test failure
+ # FIXME: Perhaps an " INFO: informational message" option would be
+ # useful here. Using -v to toggle it them on and off, as with -c.
+ # there may be multiple ERROR or FAIL messages
+Result: (PASS|FAIL|ERROR)
+
+Naming
+------
+o FIXME: decide on a sane test naming scheme. Currently the tests are named
+ based on the primary futex operation they test. Eventually this will become a
+ problem as we intend to write multiple tests which collide in this namespace.
+ Perhaps something like "wait-wake-1" "wait-wake-2" is adequate, leaving the
+ detailed description in the test source and the output.
+
+Coding Style
+------------
+o The Futex Test project adheres to the coding standards set forth by Linux
+ kernel as defined in the Linux source Documentation/CodingStyle.
diff --git a/tools/testing/selftests/futex/functional/Makefile b/tools/testing/selftests/futex/functional/Makefile
new file mode 100644
index 0000000..720023e
--- /dev/null
+++ b/tools/testing/selftests/futex/functional/Makefile
@@ -0,0 +1,24 @@
+INCLUDES := -I../include
+CFLAGS := $(CFLAGS) -g -O2 -Wall -D_GNU_SOURCE -pthread $(INCLUDES)
+LDFLAGS := $(LDFLAGS) -pthread -lrt
+
+HEADERS := ../include/futextest.h
+TARGETS := \
+ futex_wait_timeout \
+ futex_wait_wouldblock \
+ futex_requeue_pi \
+ futex_requeue_pi_signal_restart \
+ futex_requeue_pi_mismatched_ops \
+ futex_wait_uninitialized_heap \
+ futex_wait_private_mapped_file
+
+.PHONY: all clean
+all: $(TARGETS)
+
+$(TARGETS): $(HEADERS)
+
+run_tests: all
+ ./run.sh
+
+clean:
+ rm -f $(TARGETS)
diff --git a/tools/testing/selftests/futex/functional/futex_requeue_pi.c b/tools/testing/selftests/futex/functional/futex_requeue_pi.c
new file mode 100644
index 0000000..3da06ad
--- /dev/null
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi.c
@@ -0,0 +1,409 @@
+/******************************************************************************
+ *
+ * Copyright © International Business Machines Corp., 2006-2008
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * This test excercises the futex syscall op codes needed for requeuing
+ * priority inheritance aware POSIX condition variables and mutexes.
+ *
+ * AUTHORS
+ * Sripathi Kodi <sripathik-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>
+ * Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+ *
+ * HISTORY
+ * 2008-Jan-13: Initial version by Sripathi Kodi <sripathik-rWuWpvqGGmM@public.gmane.orgm.com>
+ * 2009-Nov-6: futex test adaptation by Darren Hart <dvhart@linux.intel.com>
+ *
+ *****************************************************************************/
+
+#include <errno.h>
+#include <limits.h>
+#include <pthread.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <signal.h>
+#include <string.h>
+#include "atomic.h"
+#include "futextest.h"
+#include "logging.h"
+
+#define MAX_WAKE_ITERS 1000
+#define THREAD_MAX 10
+#define SIGNAL_PERIOD_US 100
+
+atomic_t waiters_blocked = ATOMIC_INITIALIZER;
+atomic_t waiters_woken = ATOMIC_INITIALIZER;
+
+futex_t f1 = FUTEX_INITIALIZER;
+futex_t f2 = FUTEX_INITIALIZER;
+futex_t wake_complete = FUTEX_INITIALIZER;
+
+/* Test option defaults */
+static long timeout_ns;
+static int broadcast;
+static int owner;
+static int locked;
+
+struct thread_arg {
+ long id;
+ struct timespec *timeout;
+ int lock;
+ int ret;
+};
+#define THREAD_ARG_INITIALIZER { 0, NULL, 0, 0 }
+
+void usage(char *prog)
+{
+ printf("Usage: %s\n", prog);
+ printf(" -b Broadcast wakeup (all waiters)\n");
+ printf(" -c Use color\n");
+ printf(" -h Display this help message\n");
+ printf(" -l Lock the pi futex across requeue\n");
+ printf(" -o Use a third party pi futex owner during requeue (cancels -l)\n");
+ printf(" -t N Timeout in nanoseconds (default: 0)\n");
+ printf(" -v L Verbosity level: %d=QUIET %d=CRITICAL %d=INFO\n",
+ VQUIET, VCRITICAL, VINFO);
+}
+
+int create_rt_thread(pthread_t *pth, void*(*func)(void *), void *arg,
+ int policy, int prio)
+{
+ int ret;
+ struct sched_param schedp;
+ pthread_attr_t attr;
+
+ pthread_attr_init(&attr);
+ memset(&schedp, 0, sizeof(schedp));
+
+ ret = pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
+ if (ret) {
+ error("pthread_attr_setinheritsched\n", ret);
+ return -1;
+ }
+
+ ret = pthread_attr_setschedpolicy(&attr, policy);
+ if (ret) {
+ error("pthread_attr_setschedpolicy\n", ret);
+ return -1;
+ }
+
+ schedp.sched_priority = prio;
+ ret = pthread_attr_setschedparam(&attr, &schedp);
+ if (ret) {
+ error("pthread_attr_setschedparam\n", ret);
+ return -1;
+ }
+
+ ret = pthread_create(pth, &attr, func, arg);
+ if (ret) {
+ error("pthread_create\n", ret);
+ return -1;
+ }
+ return 0;
+}
+
+
+void *waiterfn(void *arg)
+{
+ struct thread_arg *args = (struct thread_arg *)arg;
+ futex_t old_val;
+
+ info("Waiter %ld: running\n", args->id);
+ /* Each thread sleeps for a different amount of time
+ * This is to avoid races, because we don't lock the
+ * external mutex here */
+ usleep(1000 * (long)args->id);
+
+ old_val = f1;
+ atomic_inc(&waiters_blocked);
+ info("Calling futex_wait_requeue_pi: %p (%u) -> %p\n",
+ &f1, f1, &f2);
+ args->ret = futex_wait_requeue_pi(&f1, old_val, &f2, args->timeout,
+ FUTEX_PRIVATE_FLAG);
+
+ info("waiter %ld woke with %d %s\n", args->id, args->ret,
+ args->ret < 0 ? strerror(errno) : "");
+ atomic_inc(&waiters_woken);
+ if (args->ret < 0) {
+ if (args->timeout && errno == ETIMEDOUT)
+ args->ret = 0;
+ else {
+ args->ret = RET_ERROR;
+ error("futex_wait_requeue_pi\n", errno);
+ }
+ futex_lock_pi(&f2, NULL, 0, FUTEX_PRIVATE_FLAG);
+ }
+ futex_unlock_pi(&f2, FUTEX_PRIVATE_FLAG);
+
+ info("Waiter %ld: exiting with %d\n", args->id, args->ret);
+ pthread_exit((void *)&args->ret);
+}
+
+void *broadcast_wakerfn(void *arg)
+{
+ struct thread_arg *args = (struct thread_arg *)arg;
+ int nr_requeue = INT_MAX;
+ int task_count = 0;
+ futex_t old_val;
+ int nr_wake = 1;
+ int i = 0;
+
+ info("Waker: waiting for waiters to block\n");
+ while (waiters_blocked.val < THREAD_MAX)
+ usleep(1000);
+ usleep(1000);
+
+ info("Waker: Calling broadcast\n");
+ if (args->lock) {
+ info("Calling FUTEX_LOCK_PI on mutex=%x @ %p\n", f2, &f2);
+ futex_lock_pi(&f2, NULL, 0, FUTEX_PRIVATE_FLAG);
+ }
+ continue_requeue:
+ old_val = f1;
+ args->ret = futex_cmp_requeue_pi(&f1, old_val, &f2, nr_wake, nr_requeue,
+ FUTEX_PRIVATE_FLAG);
+ if (args->ret < 0) {
+ args->ret = RET_ERROR;
+ error("FUTEX_CMP_REQUEUE_PI failed\n", errno);
+ } else if (++i < MAX_WAKE_ITERS) {
+ task_count += args->ret;
+ if (task_count < THREAD_MAX - waiters_woken.val)
+ goto continue_requeue;
+ } else {
+ error("max broadcast iterations (%d) reached with %d/%d tasks woken or requeued\n",
+ 0, MAX_WAKE_ITERS, task_count, THREAD_MAX);
+ args->ret = RET_ERROR;
+ }
+
+ futex_wake(&wake_complete, 1, FUTEX_PRIVATE_FLAG);
+
+ if (args->lock)
+ futex_unlock_pi(&f2, FUTEX_PRIVATE_FLAG);
+
+ if (args->ret > 0)
+ args->ret = task_count;
+
+ info("Waker: exiting with %d\n", args->ret);
+ pthread_exit((void *)&args->ret);
+}
+
+void *signal_wakerfn(void *arg)
+{
+ struct thread_arg *args = (struct thread_arg *)arg;
+ unsigned int old_val;
+ int nr_requeue = 0;
+ int task_count = 0;
+ int nr_wake = 1;
+ int i = 0;
+
+ info("Waker: waiting for waiters to block\n");
+ while (waiters_blocked.val < THREAD_MAX)
+ usleep(1000);
+ usleep(1000);
+
+ while (task_count < THREAD_MAX && waiters_woken.val < THREAD_MAX) {
+ info("task_count: %d, waiters_woken: %d\n",
+ task_count, waiters_woken.val);
+ if (args->lock) {
+ info("Calling FUTEX_LOCK_PI on mutex=%x @ %p\n",
+ f2, &f2);
+ futex_lock_pi(&f2, NULL, 0, FUTEX_PRIVATE_FLAG);
+ }
+ info("Waker: Calling signal\n");
+ /* cond_signal */
+ old_val = f1;
+ args->ret = futex_cmp_requeue_pi(&f1, old_val, &f2,
+ nr_wake, nr_requeue,
+ FUTEX_PRIVATE_FLAG);
+ if (args->ret < 0)
+ args->ret = -errno;
+ info("futex: %x\n", f2);
+ if (args->lock) {
+ info("Calling FUTEX_UNLOCK_PI on mutex=%x @ %p\n",
+ f2, &f2);
+ futex_unlock_pi(&f2, FUTEX_PRIVATE_FLAG);
+ }
+ info("futex: %x\n", f2);
+ if (args->ret < 0) {
+ error("FUTEX_CMP_REQUEUE_PI failed\n", errno);
+ args->ret = RET_ERROR;
+ break;
+ }
+
+ task_count += args->ret;
+ usleep(SIGNAL_PERIOD_US);
+ i++;
+ /* we have to loop at least THREAD_MAX times */
+ if (i > MAX_WAKE_ITERS + THREAD_MAX) {
+ error("max signaling iterations (%d) reached, giving up on pending waiters.\n",
+ 0, MAX_WAKE_ITERS + THREAD_MAX);
+ args->ret = RET_ERROR;
+ break;
+ }
+ }
+
+ futex_wake(&wake_complete, 1, FUTEX_PRIVATE_FLAG);
+
+ if (args->ret >= 0)
+ args->ret = task_count;
+
+ info("Waker: exiting with %d\n", args->ret);
+ info("Waker: waiters_woken: %d\n", waiters_woken.val);
+ pthread_exit((void *)&args->ret);
+}
+
+void *third_party_blocker(void *arg)
+{
+ struct thread_arg *args = (struct thread_arg *)arg;
+ int ret2 = 0;
+
+ args->ret = futex_lock_pi(&f2, NULL, 0, FUTEX_PRIVATE_FLAG);
+ if (args->ret)
+ goto out;
+ args->ret = futex_wait(&wake_complete, wake_complete, NULL,
+ FUTEX_PRIVATE_FLAG);
+ ret2 = futex_unlock_pi(&f2, FUTEX_PRIVATE_FLAG);
+
+ out:
+ if (args->ret || ret2) {
+ error("third_party_blocker() futex error", 0);
+ args->ret = RET_ERROR;
+ }
+
+ pthread_exit((void *)&args->ret);
+}
+
+int unit_test(int broadcast, long lock, int third_party_owner, long timeout_ns)
+{
+ void *(*wakerfn)(void *) = signal_wakerfn;
+ struct thread_arg blocker_arg = THREAD_ARG_INITIALIZER;
+ struct thread_arg waker_arg = THREAD_ARG_INITIALIZER;
+ pthread_t waiter[THREAD_MAX], waker, blocker;
+ struct timespec ts, *tsp = NULL;
+ struct thread_arg args[THREAD_MAX];
+ int *waiter_ret;
+ int i, ret = RET_PASS;
+
+ if (timeout_ns) {
+ time_t secs;
+
+ info("timeout_ns = %ld\n", timeout_ns);
+ ret = clock_gettime(CLOCK_MONOTONIC, &ts);
+ secs = (ts.tv_nsec + timeout_ns) / 1000000000;
+ ts.tv_nsec = ((int64_t)ts.tv_nsec + timeout_ns) % 1000000000;
+ ts.tv_sec += secs;
+ info("ts.tv_sec = %ld\n", ts.tv_sec);
+ info("ts.tv_nsec = %ld\n", ts.tv_nsec);
+ tsp = &ts;
+ }
+
+ if (broadcast)
+ wakerfn = broadcast_wakerfn;
+
+ if (third_party_owner) {
+ if (create_rt_thread(&blocker, third_party_blocker,
+ (void *)&blocker_arg, SCHED_FIFO, 1)) {
+ error("Creating third party blocker thread failed\n",
+ errno);
+ ret = RET_ERROR;
+ goto out;
+ }
+ }
+
+ atomic_set(&waiters_woken, 0);
+ for (i = 0; i < THREAD_MAX; i++) {
+ args[i].id = i;
+ args[i].timeout = tsp;
+ info("Starting thread %d\n", i);
+ if (create_rt_thread(&waiter[i], waiterfn, (void *)&args[i],
+ SCHED_FIFO, 1)) {
+ error("Creating waiting thread failed\n", errno);
+ ret = RET_ERROR;
+ goto out;
+ }
+ }
+ waker_arg.lock = lock;
+ if (create_rt_thread(&waker, wakerfn, (void *)&waker_arg,
+ SCHED_FIFO, 1)) {
+ error("Creating waker thread failed\n", errno);
+ ret = RET_ERROR;
+ goto out;
+ }
+
+ /* Wait for threads to finish */
+ /* Store the first error or failure encountered in waiter_ret */
+ waiter_ret = &args[0].ret;
+ for (i = 0; i < THREAD_MAX; i++)
+ pthread_join(waiter[i],
+ *waiter_ret ? NULL : (void **)&waiter_ret);
+
+ if (third_party_owner)
+ pthread_join(blocker, NULL);
+ pthread_join(waker, NULL);
+
+out:
+ if (!ret) {
+ if (*waiter_ret)
+ ret = *waiter_ret;
+ else if (waker_arg.ret < 0)
+ ret = waker_arg.ret;
+ else if (blocker_arg.ret)
+ ret = blocker_arg.ret;
+ }
+
+ return ret;
+}
+
+int main(int argc, char *argv[])
+{
+ int c, ret;
+
+ while ((c = getopt(argc, argv, "bchlot:v:")) != -1) {
+ switch (c) {
+ case 'b':
+ broadcast = 1;
+ break;
+ case 'c':
+ log_color(1);
+ break;
+ case 'h':
+ usage(basename(argv[0]));
+ exit(0);
+ case 'l':
+ locked = 1;
+ break;
+ case 'o':
+ owner = 1;
+ locked = 0;
+ break;
+ case 't':
+ timeout_ns = atoi(optarg);
+ break;
+ case 'v':
+ log_verbosity(atoi(optarg));
+ break;
+ default:
+ usage(basename(argv[0]));
+ exit(1);
+ }
+ }
+
+ printf("%s: Test requeue functionality\n", basename(argv[0]));
+ printf("\tArguments: broadcast=%d locked=%d owner=%d timeout=%ldns\n",
+ broadcast, locked, owner, timeout_ns);
+
+ /*
+ * FIXME: unit_test is obsolete now that we parse options and the
+ * various style of runs are done by run.sh - simplify the code and move
+ * unit_test into main()
+ */
+ ret = unit_test(broadcast, locked, owner, timeout_ns);
+
+ print_result(ret);
+ return ret;
+}
diff --git a/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c b/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
new file mode 100644
index 0000000..d5e4f2c
--- /dev/null
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
@@ -0,0 +1,135 @@
+/******************************************************************************
+ *
+ * Copyright © International Business Machines Corp., 2009
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * 1. Block a thread using FUTEX_WAIT
+ * 2. Attempt to use FUTEX_CMP_REQUEUE_PI on the futex from 1.
+ * 3. The kernel must detect the mismatch and return -EINVAL.
+ *
+ * AUTHOR
+ * Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+ *
+ * HISTORY
+ * 2009-Nov-9: Initial version by Darren Hart <dvhart-VuQAYsv1560/9W2qTSuDoA@public.gmane.org.com>
+ *
+ *****************************************************************************/
+
+#include <errno.h>
+#include <getopt.h>
+#include <pthread.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <time.h>
+#include "futextest.h"
+#include "logging.h"
+
+futex_t f1 = FUTEX_INITIALIZER;
+futex_t f2 = FUTEX_INITIALIZER;
+int child_ret = 0;
+
+void usage(char *prog)
+{
+ printf("Usage: %s\n", prog);
+ printf(" -c Use color\n");
+ printf(" -h Display this help message\n");
+ printf(" -v L Verbosity level: %d=QUIET %d=CRITICAL %d=INFO\n",
+ VQUIET, VCRITICAL, VINFO);
+}
+
+void *blocking_child(void *arg)
+{
+ child_ret = futex_wait(&f1, f1, NULL, FUTEX_PRIVATE_FLAG);
+ if (child_ret < 0) {
+ child_ret = -errno;
+ error("futex_wait\n", errno);
+ }
+ return (void *)&child_ret;
+}
+
+int main(int argc, char *argv[])
+{
+ int ret = RET_PASS;
+ pthread_t child;
+ int c;
+
+ while ((c = getopt(argc, argv, "chv:")) != -1) {
+ switch (c) {
+ case 'c':
+ log_color(1);
+ break;
+ case 'h':
+ usage(basename(argv[0]));
+ exit(0);
+ case 'v':
+ log_verbosity(atoi(optarg));
+ break;
+ default:
+ usage(basename(argv[0]));
+ exit(1);
+ }
+ }
+
+ printf("%s: Detect mismatched requeue_pi operations\n",
+ basename(argv[0]));
+
+ if (pthread_create(&child, NULL, blocking_child, NULL)) {
+ error("pthread_create\n", errno);
+ ret = RET_ERROR;
+ goto out;
+ }
+ /* Allow the child to block in the kernel. */
+ sleep(1);
+
+ /*
+ * The kernel should detect the waiter did not setup the
+ * q->requeue_pi_key and return -EINVAL. If it does not,
+ * it likely gave the lock to the child, which is now hung
+ * in the kernel.
+ */
+ ret = futex_cmp_requeue_pi(&f1, f1, &f2, 1, 0, FUTEX_PRIVATE_FLAG);
+ if (ret < 0) {
+ if (errno == EINVAL) {
+ /*
+ * The kernel correctly detected the mismatched
+ * requeue_pi target and aborted. Wake the child with
+ * FUTEX_WAKE.
+ */
+ ret = futex_wake(&f1, 1, FUTEX_PRIVATE_FLAG);
+ if (ret == 1) {
+ ret = RET_PASS;
+ } else if (ret < 0) {
+ error("futex_wake\n", errno);
+ ret = RET_ERROR;
+ } else {
+ error("futex_wake did not wake the child\n", 0);
+ ret = RET_ERROR;
+ }
+ } else {
+ error("futex_cmp_requeue_pi\n", errno);
+ ret = RET_ERROR;
+ }
+ } else if (ret > 0) {
+ fail("futex_cmp_requeue_pi failed to detect the mismatch\n");
+ ret = RET_FAIL;
+ } else {
+ error("futex_cmp_requeue_pi found no waiters\n", 0);
+ ret = RET_ERROR;
+ }
+
+ pthread_join(child, NULL);
+
+ if (!ret)
+ ret = child_ret;
+
+ out:
+ /* If the kernel crashes, we shouldn't return at all. */
+ print_result(ret);
+ return ret;
+}
diff --git a/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c b/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
new file mode 100644
index 0000000..7f0c756
--- /dev/null
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
@@ -0,0 +1,223 @@
+/******************************************************************************
+ *
+ * Copyright © International Business Machines Corp., 2006-2008
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * This test exercises the futex_wait_requeue_pi() signal handling both
+ * before and after the requeue. The first should be restarted by the
+ * kernel. The latter should return EWOULDBLOCK to the waiter.
+ *
+ * AUTHORS
+ * Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+ *
+ * HISTORY
+ * 2008-May-5: Initial version by Darren Hart <dvhart-VuQAYsv1560/9W2qTSuDoA@public.gmane.org.com>
+ *
+ *****************************************************************************/
+
+#include <errno.h>
+#include <getopt.h>
+#include <limits.h>
+#include <pthread.h>
+#include <signal.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include "atomic.h"
+#include "futextest.h"
+#include "logging.h"
+
+#define DELAY_US 100
+
+futex_t f1 = FUTEX_INITIALIZER;
+futex_t f2 = FUTEX_INITIALIZER;
+atomic_t requeued = ATOMIC_INITIALIZER;
+
+int waiter_ret = 0;
+
+void usage(char *prog)
+{
+ printf("Usage: %s\n", prog);
+ printf(" -c Use color\n");
+ printf(" -h Display this help message\n");
+ printf(" -v L Verbosity level: %d=QUIET %d=CRITICAL %d=INFO\n",
+ VQUIET, VCRITICAL, VINFO);
+}
+
+int create_rt_thread(pthread_t *pth, void*(*func)(void *), void *arg,
+ int policy, int prio)
+{
+ struct sched_param schedp;
+ pthread_attr_t attr;
+ int ret;
+
+ pthread_attr_init(&attr);
+ memset(&schedp, 0, sizeof(schedp));
+
+ ret = pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
+ if (ret) {
+ error("pthread_attr_setinheritsched\n", ret);
+ return -1;
+ }
+
+ ret = pthread_attr_setschedpolicy(&attr, policy);
+ if (ret) {
+ error("pthread_attr_setschedpolicy\n", ret);
+ return -1;
+ }
+
+ schedp.sched_priority = prio;
+ ret = pthread_attr_setschedparam(&attr, &schedp);
+ if (ret) {
+ error("pthread_attr_setschedparam\n", ret);
+ return -1;
+ }
+
+ ret = pthread_create(pth, &attr, func, arg);
+ if (ret) {
+ error("pthread_create\n", ret);
+ return -1;
+ }
+ return 0;
+}
+
+void handle_signal(int signo)
+{
+ info("signal received %s requeue\n",
+ requeued.val ? "after" : "prior to");
+}
+
+void *waiterfn(void *arg)
+{
+ unsigned int old_val;
+ int res;
+
+ waiter_ret = RET_PASS;
+
+ info("Waiter running\n");
+ info("Calling FUTEX_LOCK_PI on f2=%x @ %p\n", f2, &f2);
+ old_val = f1;
+ res = futex_wait_requeue_pi(&f1, old_val, &(f2), NULL,
+ FUTEX_PRIVATE_FLAG);
+ if (!requeued.val || errno != EWOULDBLOCK) {
+ fail("unexpected return from futex_wait_requeue_pi: %d (%s)\n",
+ res, strerror(errno));
+ info("w2:futex: %x\n", f2);
+ if (!res)
+ futex_unlock_pi(&f2, FUTEX_PRIVATE_FLAG);
+ waiter_ret = RET_FAIL;
+ }
+
+ info("Waiter exiting with %d\n", waiter_ret);
+ pthread_exit(NULL);
+}
+
+
+int main(int argc, char *argv[])
+{
+ unsigned int old_val;
+ struct sigaction sa;
+ pthread_t waiter;
+ int c, res, ret = RET_PASS;
+
+ while ((c = getopt(argc, argv, "chv:")) != -1) {
+ switch (c) {
+ case 'c':
+ log_color(1);
+ break;
+ case 'h':
+ usage(basename(argv[0]));
+ exit(0);
+ case 'v':
+ log_verbosity(atoi(optarg));
+ break;
+ default:
+ usage(basename(argv[0]));
+ exit(1);
+ }
+ }
+
+ printf("%s: Test signal handling during requeue_pi\n",
+ basename(argv[0]));
+ printf("\tArguments: <none>\n");
+
+ sa.sa_handler = handle_signal;
+ sigemptyset(&sa.sa_mask);
+ sa.sa_flags = 0;
+ if (sigaction(SIGUSR1, &sa, NULL)) {
+ error("sigaction\n", errno);
+ exit(1);
+ }
+
+ info("m1:f2: %x\n", f2);
+ info("Creating waiter\n");
+ res = create_rt_thread(&waiter, waiterfn, NULL, SCHED_FIFO, 1);
+ if (res) {
+ error("Creating waiting thread failed", res);
+ ret = RET_ERROR;
+ goto out;
+ }
+
+ info("Calling FUTEX_LOCK_PI on f2=%x @ %p\n", f2, &f2);
+ info("m2:f2: %x\n", f2);
+ futex_lock_pi(&f2, 0, 0, FUTEX_PRIVATE_FLAG);
+ info("m3:f2: %x\n", f2);
+
+ while (1) {
+ /*
+ * signal the waiter before requeue, waiter should automatically
+ * restart futex_wait_requeue_pi() in the kernel. Wait for the
+ * waiter to block on f1 again.
+ */
+ info("Issuing SIGUSR1 to waiter\n");
+ pthread_kill(waiter, SIGUSR1);
+ usleep(DELAY_US);
+
+ info("Requeueing waiter via FUTEX_CMP_REQUEUE_PI\n");
+ old_val = f1;
+ res = futex_cmp_requeue_pi(&f1, old_val, &(f2), 1, 0,
+ FUTEX_PRIVATE_FLAG);
+ /*
+ * If res is non-zero, we either requeued the waiter or hit an
+ * error, break out and handle it. If it is zero, then the
+ * signal may have hit before the the waiter was blocked on f1.
+ * Try again.
+ */
+ if (res > 0) {
+ atomic_set(&requeued, 1);
+ break;
+ } else if (res > 0) {
+ error("FUTEX_CMP_REQUEUE_PI failed\n", errno);
+ ret = RET_ERROR;
+ break;
+ }
+ }
+ info("m4:f2: %x\n", f2);
+
+ /*
+ * Signal the waiter after requeue, waiter should return from
+ * futex_wait_requeue_pi() with EWOULDBLOCK. Join the thread here so the
+ * futex_unlock_pi() can't happen before the signal wakeup is detected
+ * in the kernel.
+ */
+ info("Issuing SIGUSR1 to waiter\n");
+ pthread_kill(waiter, SIGUSR1);
+ info("Waiting for waiter to return\n");
+ pthread_join(waiter, NULL);
+
+ info("Calling FUTEX_UNLOCK_PI on mutex=%x @ %p\n", f2, &f2);
+ futex_unlock_pi(&f2, FUTEX_PRIVATE_FLAG);
+ info("m5:f2: %x\n", f2);
+
+ out:
+ if (ret == RET_PASS && waiter_ret)
+ ret = waiter_ret;
+
+ print_result(ret);
+ return ret;
+}
diff --git a/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c b/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
new file mode 100644
index 0000000..5f687f2
--- /dev/null
+++ b/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
@@ -0,0 +1,125 @@
+/******************************************************************************
+ *
+ * Copyright FUJITSU LIMITED 2010
+ * Copyright KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * Internally, Futex has two handling mode, anon and file. The private file
+ * mapping is special. At first it behave as file, but after write anything
+ * it behave as anon. This test is intent to test such case.
+ *
+ * AUTHOR
+ * KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
+ *
+ * HISTORY
+ * 2010-Jan-6: Initial version by KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+ *
+ *****************************************************************************/
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <syscall.h>
+#include <unistd.h>
+#include <errno.h>
+#include <linux/futex.h>
+#include <pthread.h>
+#include <libgen.h>
+#include <signal.h>
+
+#include "logging.h"
+#include "futextest.h"
+
+#define PAGE_SZ 4096
+
+char pad[PAGE_SZ] = {1};
+futex_t val = 1;
+char pad2[PAGE_SZ] = {1};
+
+#define WAKE_WAIT_US 3000000
+struct timespec wait_timeout = { .tv_sec = 5, .tv_nsec = 0};
+
+void usage(char *prog)
+{
+ printf("Usage: %s\n", prog);
+ printf(" -c Use color\n");
+ printf(" -h Display this help message\n");
+ printf(" -v L Verbosity level: %d=QUIET %d=CRITICAL %d=INFO\n",
+ VQUIET, VCRITICAL, VINFO);
+}
+
+void *thr_futex_wait(void *arg)
+{
+ int ret;
+
+ info("futex wait\n");
+ ret = futex_wait(&val, 1, &wait_timeout, 0);
+ if (ret && errno != EWOULDBLOCK && errno != ETIMEDOUT) {
+ error("futex error.\n", errno);
+ print_result(RET_ERROR);
+ exit(RET_ERROR);
+ }
+
+ if (ret && errno == ETIMEDOUT)
+ fail("waiter timedout\n");
+
+ info("futex_wait: ret = %d, errno = %d\n", ret, errno);
+
+ return NULL;
+}
+
+int main(int argc, char **argv)
+{
+ pthread_t thr;
+ int ret = RET_PASS;
+ int res;
+ int c;
+
+ while ((c = getopt(argc, argv, "chv:")) != -1) {
+ switch (c) {
+ case 'c':
+ log_color(1);
+ break;
+ case 'h':
+ usage(basename(argv[0]));
+ exit(0);
+ case 'v':
+ log_verbosity(atoi(optarg));
+ break;
+ default:
+ usage(basename(argv[0]));
+ exit(1);
+ }
+ }
+
+ printf("%s: Test the futex value of private file mappings in FUTEX_WAIT\n",
+ basename(argv[0]));
+
+ ret = pthread_create(&thr, NULL, thr_futex_wait, NULL);
+ if (ret < 0) {
+ fprintf(stderr, "pthread_create error\n");
+ ret = RET_ERROR;
+ goto out;
+ }
+
+ info("wait a while\n");
+ usleep(WAKE_WAIT_US);
+ val = 2;
+ res = futex_wake(&val, 1, 0);
+ info("futex_wake %d\n", res);
+ if (res != 1) {
+ fail("FUTEX_WAKE didn't find the waiting thread.\n");
+ ret = RET_FAIL;
+ }
+
+ info("join\n");
+ pthread_join(thr, NULL);
+
+ out:
+ print_result(ret);
+ return ret;
+}
diff --git a/tools/testing/selftests/futex/functional/futex_wait_timeout.c b/tools/testing/selftests/futex/functional/futex_wait_timeout.c
new file mode 100644
index 0000000..ab428ca
--- /dev/null
+++ b/tools/testing/selftests/futex/functional/futex_wait_timeout.c
@@ -0,0 +1,86 @@
+/******************************************************************************
+ *
+ * Copyright © International Business Machines Corp., 2009
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * Block on a futex and wait for timeout.
+ *
+ * AUTHOR
+ * Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+ *
+ * HISTORY
+ * 2009-Nov-6: Initial version by Darren Hart <dvhart-VuQAYsv1560/9W2qTSuDoA@public.gmane.org.com>
+ *
+ *****************************************************************************/
+
+#include <errno.h>
+#include <getopt.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <time.h>
+#include "futextest.h"
+#include "logging.h"
+
+static long timeout_ns = 100000; /* 100us default timeout */
+
+void usage(char *prog)
+{
+ printf("Usage: %s\n", prog);
+ printf(" -c Use color\n");
+ printf(" -h Display this help message\n");
+ printf(" -t N Timeout in nanoseconds (default: 100,000)\n");
+ printf(" -v L Verbosity level: %d=QUIET %d=CRITICAL %d=INFO\n",
+ VQUIET, VCRITICAL, VINFO);
+}
+
+int main(int argc, char *argv[])
+{
+ futex_t f1 = FUTEX_INITIALIZER;
+ struct timespec to;
+ int res, ret = RET_PASS;
+ int c;
+
+ while ((c = getopt(argc, argv, "cht:v:")) != -1) {
+ switch (c) {
+ case 'c':
+ log_color(1);
+ break;
+ case 'h':
+ usage(basename(argv[0]));
+ exit(0);
+ case 't':
+ timeout_ns = atoi(optarg);
+ break;
+ case 'v':
+ log_verbosity(atoi(optarg));
+ break;
+ default:
+ usage(basename(argv[0]));
+ exit(1);
+ }
+ }
+
+ printf("%s: Block on a futex and wait for timeout\n",
+ basename(argv[0]));
+ printf("\tArguments: timeout=%ldns\n", timeout_ns);
+
+ /* initialize timeout */
+ to.tv_sec = 0;
+ to.tv_nsec = timeout_ns;
+
+ info("Calling futex_wait on f1: %u @ %p\n", f1, &f1);
+ res = futex_wait(&f1, f1, &to, FUTEX_PRIVATE_FLAG);
+ if (!res || errno != ETIMEDOUT) {
+ fail("futex_wait returned %d\n", ret < 0 ? errno : ret);
+ ret = RET_FAIL;
+ }
+
+ print_result(ret);
+ return ret;
+}
diff --git a/tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c b/tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c
new file mode 100644
index 0000000..fe7aee9
--- /dev/null
+++ b/tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c
@@ -0,0 +1,124 @@
+/******************************************************************************
+ *
+ * Copyright FUJITSU LIMITED 2010
+ * Copyright KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * Wait on uninitialized heap. It shold be zero and FUTEX_WAIT should
+ * return immediately. This test is intent to test zero page handling in
+ * futex.
+ *
+ * AUTHOR
+ * KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
+ *
+ * HISTORY
+ * 2010-Jan-6: Initial version by KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+ *
+ *****************************************************************************/
+
+#include <pthread.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/mman.h>
+#include <syscall.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+#include <errno.h>
+#include <linux/futex.h>
+#include <libgen.h>
+
+#include "logging.h"
+#include "futextest.h"
+
+#define WAIT_US 5000000
+
+static int child_blocked = 1;
+static int child_ret;
+void *buf;
+
+void usage(char *prog)
+{
+ printf("Usage: %s\n", prog);
+ printf(" -c Use color\n");
+ printf(" -h Display this help message\n");
+ printf(" -v L Verbosity level: %d=QUIET %d=CRITICAL %d=INFO\n",
+ VQUIET, VCRITICAL, VINFO);
+}
+
+void *wait_thread(void *arg)
+{
+ int res;
+
+ child_ret = RET_PASS;
+ res = futex_wait(buf, 1, NULL, 0);
+ child_blocked = 0;
+
+ if (res != 0 && errno != EWOULDBLOCK) {
+ error("futex failure\n", errno);
+ child_ret = RET_ERROR;
+ }
+ pthread_exit(NULL);
+}
+
+int main(int argc, char **argv)
+{
+ int c, ret = RET_PASS;
+ long page_size;
+ pthread_t thr;
+
+ while ((c = getopt(argc, argv, "chv:")) != -1) {
+ switch (c) {
+ case 'c':
+ log_color(1);
+ break;
+ case 'h':
+ usage(basename(argv[0]));
+ exit(0);
+ case 'v':
+ log_verbosity(atoi(optarg));
+ break;
+ default:
+ usage(basename(argv[0]));
+ exit(1);
+ }
+ }
+
+ page_size = sysconf(_SC_PAGESIZE);
+
+ buf = mmap(NULL, page_size, PROT_READ|PROT_WRITE,
+ MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
+ if (buf == (void *)-1) {
+ error("mmap\n", errno);
+ exit(1);
+ }
+
+ printf("%s: Test the uninitialized futex value in FUTEX_WAIT\n",
+ basename(argv[0]));
+
+
+ ret = pthread_create(&thr, NULL, wait_thread, NULL);
+ if (ret) {
+ error("pthread_create\n", errno);
+ ret = RET_ERROR;
+ goto out;
+ }
+
+ info("waiting %dus for child to return\n", WAIT_US);
+ usleep(WAIT_US);
+
+ ret = child_ret;
+ if (child_blocked) {
+ fail("child blocked in kernel\n");
+ ret = RET_FAIL;
+ }
+
+ out:
+ print_result(ret);
+ return ret;
+}
diff --git a/tools/testing/selftests/futex/functional/futex_wait_wouldblock.c b/tools/testing/selftests/futex/functional/futex_wait_wouldblock.c
new file mode 100644
index 0000000..b6b0274
--- /dev/null
+++ b/tools/testing/selftests/futex/functional/futex_wait_wouldblock.c
@@ -0,0 +1,79 @@
+/******************************************************************************
+ *
+ * Copyright © International Business Machines Corp., 2009
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * Test if FUTEX_WAIT op returns -EWOULDBLOCK if the futex value differs
+ * from the expected one.
+ *
+ * AUTHOR
+ * Gowrishankar <gowrishankar.m-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>
+ *
+ * HISTORY
+ * 2009-Nov-14: Initial version by Gowrishankar <gowrishankar.m@in.ibm.com>
+ *
+ *****************************************************************************/
+
+#include <errno.h>
+#include <getopt.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <time.h>
+#include "futextest.h"
+#include "logging.h"
+
+#define timeout_ns 100000
+
+void usage(char *prog)
+{
+ printf("Usage: %s\n", prog);
+ printf(" -c Use color\n");
+ printf(" -h Display this help message\n");
+ printf(" -v L Verbosity level: %d=QUIET %d=CRITICAL %d=INFO\n",
+ VQUIET, VCRITICAL, VINFO);
+}
+
+int main(int argc, char *argv[])
+{
+ struct timespec to = {.tv_sec = 0, .tv_nsec = timeout_ns};
+ futex_t f1 = FUTEX_INITIALIZER;
+ int res, ret = RET_PASS;
+ int c;
+
+ while ((c = getopt(argc, argv, "cht:v:")) != -1) {
+ switch (c) {
+ case 'c':
+ log_color(1);
+ break;
+ case 'h':
+ usage(basename(argv[0]));
+ exit(0);
+ case 'v':
+ log_verbosity(atoi(optarg));
+ break;
+ default:
+ usage(basename(argv[0]));
+ exit(1);
+ }
+ }
+
+ printf("%s: Test the unexpected futex value in FUTEX_WAIT\n",
+ basename(argv[0]));
+
+ info("Calling futex_wait on f1: %u @ %p with val=%u\n", f1, &f1, f1+1);
+ res = futex_wait(&f1, f1+1, &to, FUTEX_PRIVATE_FLAG);
+ if (!res || errno != EWOULDBLOCK) {
+ fail("futex_wait returned: %d %s\n",
+ res ? errno : res, res ? strerror(errno) : "");
+ ret = RET_FAIL;
+ }
+
+ print_result(ret);
+ return ret;
+}
diff --git a/tools/testing/selftests/futex/functional/run.sh b/tools/testing/selftests/futex/functional/run.sh
new file mode 100755
index 0000000..e87dbe2
--- /dev/null
+++ b/tools/testing/selftests/futex/functional/run.sh
@@ -0,0 +1,79 @@
+#!/bin/sh
+
+###############################################################################
+#
+# Copyright © International Business Machines Corp., 2009
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# DESCRIPTION
+# Run tests in the current directory.
+#
+# AUTHOR
+# Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+#
+# HISTORY
+# 2009-Nov-9: Initial version by Darren Hart <dvhart-VuQAYsv1562uYJLRA6qg5Q@public.gmane.orgcom>
+# 2010-Jan-6: Add futex_wait_uninitialized_heap and futex_wait_private_mapped_file
+# by KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
+#
+###############################################################################
+
+# Test for a color capable console
+if [ -z "$USE_COLOR" ]; then
+ tput setf 7
+ if [ $? -eq 0 ]; then
+ USE_COLOR=1
+ tput sgr0
+ fi
+fi
+if [ "$USE_COLOR" -eq 1 ]; then
+ COLOR="-c"
+fi
+
+
+echo
+# requeue pi testing
+# without timeouts
+./futex_requeue_pi $COLOR
+./futex_requeue_pi $COLOR -b
+./futex_requeue_pi $COLOR -b -l
+./futex_requeue_pi $COLOR -b -o
+./futex_requeue_pi $COLOR -l
+./futex_requeue_pi $COLOR -o
+# with timeouts
+./futex_requeue_pi $COLOR -b -l -t 5000
+./futex_requeue_pi $COLOR -l -t 5000
+./futex_requeue_pi $COLOR -b -l -t 500000
+./futex_requeue_pi $COLOR -l -t 500000
+./futex_requeue_pi $COLOR -b -t 5000
+./futex_requeue_pi $COLOR -t 5000
+./futex_requeue_pi $COLOR -b -t 500000
+./futex_requeue_pi $COLOR -t 500000
+./futex_requeue_pi $COLOR -b -o -t 5000
+./futex_requeue_pi $COLOR -l -t 5000
+./futex_requeue_pi $COLOR -b -o -t 500000
+./futex_requeue_pi $COLOR -l -t 500000
+# with long timeout
+./futex_requeue_pi $COLOR -b -l -t 2000000000
+./futex_requeue_pi $COLOR -l -t 2000000000
+
+
+echo
+./futex_requeue_pi_mismatched_ops $COLOR
+
+echo
+./futex_requeue_pi_signal_restart $COLOR
+
+echo
+./futex_wait_timeout $COLOR
+
+echo
+./futex_wait_wouldblock $COLOR
+
+echo
+./futex_wait_uninitialized_heap $COLOR
+./futex_wait_private_mapped_file $COLOR
diff --git a/tools/testing/selftests/futex/include/atomic.h b/tools/testing/selftests/futex/include/atomic.h
new file mode 100644
index 0000000..f861da3
--- /dev/null
+++ b/tools/testing/selftests/futex/include/atomic.h
@@ -0,0 +1,83 @@
+/******************************************************************************
+ *
+ * Copyright © International Business Machines Corp., 2009
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * GCC atomic builtin wrappers
+ * http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
+ *
+ * AUTHOR
+ * Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+ *
+ * HISTORY
+ * 2009-Nov-17: Initial version by Darren Hart <dvhart-VuQAYsv1563N0uC3ymp8PA@public.gmane.orgl.com>
+ *
+ *****************************************************************************/
+
+#ifndef _ATOMIC_H
+#define _ATOMIC_H
+
+typedef struct {
+ volatile int val;
+} atomic_t;
+
+#define ATOMIC_INITIALIZER { 0 }
+
+/**
+ * atomic_cmpxchg() - Atomic compare and exchange
+ * @uaddr: The address of the futex to be modified
+ * @oldval: The expected value of the futex
+ * @newval: The new value to try and assign the futex
+ *
+ * Return the old value of addr->val.
+ */
+static inline int
+atomic_cmpxchg(atomic_t *addr, int oldval, int newval)
+{
+ return __sync_val_compare_and_swap(&addr->val, oldval, newval);
+}
+
+/**
+ * atomic_inc() - Atomic incrememnt
+ * @addr: Address of the variable to increment
+ *
+ * Return the new value of addr->val.
+ */
+static inline int
+atomic_inc(atomic_t *addr)
+{
+ return __sync_add_and_fetch(&addr->val, 1);
+}
+
+/**
+ * atomic_dec() - Atomic decrement
+ * @addr: Address of the variable to decrement
+ *
+ * Return the new value of addr-val.
+ */
+static inline int
+atomic_dec(atomic_t *addr)
+{
+ return __sync_sub_and_fetch(&addr->val, 1);
+}
+
+/**
+ * atomic_set() - Atomic set
+ * @addr: Address of the variable to set
+ * @newval: New value for the atomic_t
+ *
+ * Return the new value of addr->val.
+ */
+static inline int
+atomic_set(atomic_t *addr, int newval)
+{
+ addr->val = newval;
+ return newval;
+}
+
+#endif
diff --git a/tools/testing/selftests/futex/include/futextest.h b/tools/testing/selftests/futex/include/futextest.h
new file mode 100644
index 0000000..b98c3ab
--- /dev/null
+++ b/tools/testing/selftests/futex/include/futextest.h
@@ -0,0 +1,266 @@
+/******************************************************************************
+ *
+ * Copyright © International Business Machines Corp., 2009
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * Glibc independent futex library for testing kernel functionality.
+ *
+ * AUTHOR
+ * Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+ *
+ * HISTORY
+ * 2009-Nov-6: Initial version by Darren Hart <dvhart-VuQAYsv1560/9W2qTSuDoA@public.gmane.org.com>
+ *
+ *****************************************************************************/
+
+#ifndef _FUTEXTEST_H
+#define _FUTEXTEST_H
+
+#include <unistd.h>
+#include <sys/syscall.h>
+#include <sys/types.h>
+#include <linux/futex.h>
+
+typedef volatile u_int32_t futex_t;
+#define FUTEX_INITIALIZER 0
+
+/* Define the newer op codes if the system header file is not up to date. */
+#ifndef FUTEX_WAIT_BITSET
+#define FUTEX_WAIT_BITSET 9
+#endif
+#ifndef FUTEX_WAKE_BITSET
+#define FUTEX_WAKE_BITSET 10
+#endif
+#ifndef FUTEX_WAIT_REQUEUE_PI
+#define FUTEX_WAIT_REQUEUE_PI 11
+#endif
+#ifndef FUTEX_CMP_REQUEUE_PI
+#define FUTEX_CMP_REQUEUE_PI 12
+#endif
+#ifndef FUTEX_WAIT_REQUEUE_PI_PRIVATE
+#define FUTEX_WAIT_REQUEUE_PI_PRIVATE (FUTEX_WAIT_REQUEUE_PI | \
+ FUTEX_PRIVATE_FLAG)
+#endif
+#ifndef FUTEX_REQUEUE_PI_PRIVATE
+#define FUTEX_CMP_REQUEUE_PI_PRIVATE (FUTEX_CMP_REQUEUE_PI | \
+ FUTEX_PRIVATE_FLAG)
+#endif
+
+/**
+ * futex() - SYS_futex syscall wrapper
+ * @uaddr: address of first futex
+ * @op: futex op code
+ * @val: typically expected value of uaddr, but varies by op
+ * @timeout: typically an absolute struct timespec (except where noted
+ * otherwise). Overloaded by some ops
+ * @uaddr2: address of second futex for some ops\
+ * @val3: varies by op
+ * @opflags: flags to be bitwise OR'd with op, such as FUTEX_PRIVATE_FLAG
+ *
+ * futex() is used by all the following futex op wrappers. It can also be
+ * used for misuse and abuse testing. Generally, the specific op wrappers
+ * should be used instead. It is a macro instead of an static inline function as
+ * some of the types over overloaded (timeout is used for nr_requeue for
+ * example).
+ *
+ * These argument descriptions are the defaults for all
+ * like-named arguments in the following wrappers except where noted below.
+ */
+#define futex(uaddr, op, val, timeout, uaddr2, val3, opflags) \
+ syscall(SYS_futex, uaddr, op | opflags, val, timeout, uaddr2, val3)
+
+/**
+ * futex_wait() - block on uaddr with optional timeout
+ * @timeout: relative timeout
+ */
+static inline int
+futex_wait(futex_t *uaddr, futex_t val, struct timespec *timeout, int opflags)
+{
+ return futex(uaddr, FUTEX_WAIT, val, timeout, NULL, 0, opflags);
+}
+
+/**
+ * futex_wake() - wake one or more tasks blocked on uaddr
+ * @nr_wake: wake up to this many tasks
+ */
+static inline int
+futex_wake(futex_t *uaddr, int nr_wake, int opflags)
+{
+ return futex(uaddr, FUTEX_WAKE, nr_wake, NULL, NULL, 0, opflags);
+}
+
+/**
+ * futex_wait_bitset() - block on uaddr with bitset
+ * @bitset: bitset to be used with futex_wake_bitset
+ */
+static inline int
+futex_wait_bitset(futex_t *uaddr, futex_t val, struct timespec *timeout,
+ u_int32_t bitset, int opflags)
+{
+ return futex(uaddr, FUTEX_WAIT_BITSET, val, timeout, NULL, bitset,
+ opflags);
+}
+
+/**
+ * futex_wake_bitset() - wake one or more tasks blocked on uaddr with bitset
+ * @bitset: bitset to compare with that used in futex_wait_bitset
+ */
+static inline int
+futex_wake_bitset(futex_t *uaddr, int nr_wake, u_int32_t bitset, int opflags)
+{
+ return futex(uaddr, FUTEX_WAKE_BITSET, nr_wake, NULL, NULL, bitset,
+ opflags);
+}
+
+/**
+ * futex_lock_pi() - block on uaddr as a PI mutex
+ * @detect: whether (1) or not (0) to perform deadlock detection
+ */
+static inline int
+futex_lock_pi(futex_t *uaddr, struct timespec *timeout, int detect,
+ int opflags)
+{
+ return futex(uaddr, FUTEX_LOCK_PI, detect, timeout, NULL, 0, opflags);
+}
+
+/**
+ * futex_unlock_pi() - release uaddr as a PI mutex, waking the top waiter
+ */
+static inline int
+futex_unlock_pi(futex_t *uaddr, int opflags)
+{
+ return futex(uaddr, FUTEX_UNLOCK_PI, 0, NULL, NULL, 0, opflags);
+}
+
+/**
+ * futex_wake_op() - FIXME: COME UP WITH A GOOD ONE LINE DESCRIPTION
+ */
+static inline int
+futex_wake_op(futex_t *uaddr, futex_t *uaddr2, int nr_wake, int nr_wake2,
+ int wake_op, int opflags)
+{
+ return futex(uaddr, FUTEX_WAKE_OP, nr_wake, nr_wake2, uaddr2, wake_op,
+ opflags);
+}
+
+/**
+ * futex_requeue() - requeue without expected value comparison, deprecated
+ * @nr_wake: wake up to this many tasks
+ * @nr_requeue: requeue up to this many tasks
+ *
+ * Due to its inherently racy implementation, futex_requeue() is deprecated in
+ * favor of futex_cmp_requeue().
+ */
+static inline int
+futex_requeue(futex_t *uaddr, futex_t *uaddr2, int nr_wake, int nr_requeue,
+ int opflags)
+{
+ return futex(uaddr, FUTEX_REQUEUE, nr_wake, nr_requeue, uaddr2, 0,
+ opflags);
+}
+
+/**
+ * futex_cmp_requeue() - requeue tasks from uaddr to uaddr2
+ * @nr_wake: wake up to this many tasks
+ * @nr_requeue: requeue up to this many tasks
+ */
+static inline int
+futex_cmp_requeue(futex_t *uaddr, futex_t val, futex_t *uaddr2, int nr_wake,
+ int nr_requeue, int opflags)
+{
+ return futex(uaddr, FUTEX_CMP_REQUEUE, nr_wake, nr_requeue, uaddr2,
+ val, opflags);
+}
+
+/**
+ * futex_wait_requeue_pi() - block on uaddr and prepare to requeue to uaddr2
+ * @uaddr: non-PI futex source
+ * @uaddr2: PI futex target
+ *
+ * This is the first half of the requeue_pi mechanism. It shall always be
+ * paired with futex_cmp_requeue_pi().
+ */
+static inline int
+futex_wait_requeue_pi(futex_t *uaddr, futex_t val, futex_t *uaddr2,
+ struct timespec *timeout, int opflags)
+{
+ return futex(uaddr, FUTEX_WAIT_REQUEUE_PI, val, timeout, uaddr2, 0,
+ opflags);
+}
+
+/**
+ * futex_cmp_requeue_pi() - requeue tasks from uaddr to uaddr2 (PI aware)
+ * @uaddr: non-PI futex source
+ * @uaddr2: PI futex target
+ * @nr_wake: wake up to this many tasks
+ * @nr_requeue: requeue up to this many tasks
+ */
+static inline int
+futex_cmp_requeue_pi(futex_t *uaddr, futex_t val, futex_t *uaddr2, int nr_wake,
+ int nr_requeue, int opflags)
+{
+ return futex(uaddr, FUTEX_CMP_REQUEUE_PI, nr_wake, nr_requeue, uaddr2,
+ val, opflags);
+}
+
+/**
+ * futex_cmpxchg() - atomic compare and exchange
+ * @uaddr: The address of the futex to be modified
+ * @oldval: The expected value of the futex
+ * @newval: The new value to try and assign the futex
+ *
+ * Implement cmpxchg using gcc atomic builtins.
+ * http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
+ *
+ * Return the old futex value.
+ */
+static inline u_int32_t
+futex_cmpxchg(futex_t *uaddr, u_int32_t oldval, u_int32_t newval)
+{
+ return __sync_val_compare_and_swap(uaddr, oldval, newval);
+}
+
+/**
+ * futex_dec() - atomic decrement of the futex value
+ * @uaddr: The address of the futex to be modified
+ *
+ * Return the new futex value.
+ */
+static inline u_int32_t
+futex_dec(futex_t *uaddr)
+{
+ return __sync_sub_and_fetch(uaddr, 1);
+}
+
+/**
+ * futex_inc() - atomic increment of the futex value
+ * @uaddr: the address of the futex to be modified
+ *
+ * Return the new futex value.
+ */
+static inline u_int32_t
+futex_inc(futex_t *uaddr)
+{
+ return __sync_add_and_fetch(uaddr, 1);
+}
+
+/**
+ * futex_set() - atomic decrement of the futex value
+ * @uaddr: the address of the futex to be modified
+ * @newval: New value for the atomic_t
+ *
+ * Return the new futex value.
+ */
+static inline u_int32_t
+futex_set(futex_t *uaddr, u_int32_t newval)
+{
+ *uaddr = newval;
+ return newval;
+}
+
+#endif
diff --git a/tools/testing/selftests/futex/include/logging.h b/tools/testing/selftests/futex/include/logging.h
new file mode 100644
index 0000000..f6ed5c2
--- /dev/null
+++ b/tools/testing/selftests/futex/include/logging.h
@@ -0,0 +1,150 @@
+/******************************************************************************
+ *
+ * Copyright © International Business Machines Corp., 2009
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * DESCRIPTION
+ * Glibc independent futex library for testing kernel functionality.
+ *
+ * AUTHOR
+ * Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+ *
+ * HISTORY
+ * 2009-Nov-6: Initial version by Darren Hart <dvhart-VuQAYsv1560/9W2qTSuDoA@public.gmane.org.com>
+ *
+ *****************************************************************************/
+
+#ifndef _LOGGING_H
+#define _LOGGING_H
+
+#include <string.h>
+#include <unistd.h>
+#include <linux/futex.h>
+
+/*
+ * Define PASS, ERROR, and FAIL strings with and without color escape
+ * sequences, default to no color.
+ */
+#define ESC 0x1B, '['
+#define BRIGHT '1'
+#define GREEN '3', '2'
+#define YELLOW '3', '3'
+#define RED '3', '1'
+#define ESCEND 'm'
+#define BRIGHT_GREEN ESC, BRIGHT, ';', GREEN, ESCEND
+#define BRIGHT_YELLOW ESC, BRIGHT, ';', YELLOW, ESCEND
+#define BRIGHT_RED ESC, BRIGHT, ';', RED, ESCEND
+#define RESET_COLOR ESC, '0', 'm'
+static const char PASS_COLOR[] = {BRIGHT_GREEN, ' ', 'P', 'A', 'S', 'S',
+ RESET_COLOR, 0};
+static const char ERROR_COLOR[] = {BRIGHT_YELLOW, 'E', 'R', 'R', 'O', 'R',
+ RESET_COLOR, 0};
+static const char FAIL_COLOR[] = {BRIGHT_RED, ' ', 'F', 'A', 'I', 'L',
+ RESET_COLOR, 0};
+static const char INFO_NORMAL[] = " INFO";
+static const char PASS_NORMAL[] = " PASS";
+static const char ERROR_NORMAL[] = "ERROR";
+static const char FAIL_NORMAL[] = " FAIL";
+const char *INFO = INFO_NORMAL;
+const char *PASS = PASS_NORMAL;
+const char *ERROR = ERROR_NORMAL;
+const char *FAIL = FAIL_NORMAL;
+
+/* Verbosity setting for INFO messages */
+#define VQUIET 0
+#define VCRITICAL 1
+#define VINFO 2
+#define VMAX VINFO
+int _verbose = VCRITICAL;
+
+/* Functional test return codes */
+#define RET_PASS 0
+#define RET_ERROR -1
+#define RET_FAIL -2
+
+/**
+ * log_color() - Use colored output for PASS, ERROR, and FAIL strings
+ * @use_color: use color (1) or not (0)
+ */
+void log_color(int use_color)
+{
+ if (use_color) {
+ PASS = PASS_COLOR;
+ ERROR = ERROR_COLOR;
+ FAIL = FAIL_COLOR;
+ } else {
+ PASS = PASS_NORMAL;
+ ERROR = ERROR_NORMAL;
+ FAIL = FAIL_NORMAL;
+ }
+}
+
+/**
+ * log_verbosity() - Set verbosity of test output
+ * @verbose: Enable (1) verbose output or not (0)
+ *
+ * Currently setting verbose=1 will enable INFO messages and 0 will disable
+ * them. FAIL and ERROR messages are always displayed.
+ */
+void log_verbosity(int level)
+{
+ if (level > VMAX)
+ level = VMAX;
+ else if (level < 0)
+ level = 0;
+ _verbose = level;
+}
+
+/**
+ * print_result() - Print standard PASS | ERROR | FAIL results
+ * @ret: the return value to be considered: 0 | RET_ERROR | RET_FAIL
+ *
+ * print_result() is primarily intended for functional tests.
+ */
+void print_result(int ret)
+{
+ const char *result = "Unknown return code";
+
+ switch (ret) {
+ case RET_PASS:
+ result = PASS;
+ break;
+ case RET_ERROR:
+ result = ERROR;
+ break;
+ case RET_FAIL:
+ result = FAIL;
+ break;
+ }
+ printf("Result: %s\n", result);
+}
+
+/* log level macros */
+#define info(message, vargs...) \
+do { \
+ if (_verbose >= VINFO) \
+ fprintf(stderr, "\t%s: "message, INFO, ##vargs); \
+} while (0)
+
+#define error(message, err, args...) \
+do { \
+ if (_verbose >= VCRITICAL) {\
+ if (err) \
+ fprintf(stderr, "\t%s: %s: "message, \
+ ERROR, strerror(err), ##args); \
+ else \
+ fprintf(stderr, "\t%s: "message, ERROR, ##args); \
+ } \
+} while (0)
+
+#define fail(message, args...) \
+do { \
+ if (_verbose >= VCRITICAL) \
+ fprintf(stderr, "\t%s: "message, FAIL, ##args); \
+} while (0)
+
+#endif
diff --git a/tools/testing/selftests/futex/run.sh b/tools/testing/selftests/futex/run.sh
new file mode 100755
index 0000000..4126312
--- /dev/null
+++ b/tools/testing/selftests/futex/run.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+###############################################################################
+#
+# Copyright © International Business Machines Corp., 2009
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# DESCRIPTION
+# Run all tests under the functional, performance, and stress directories.
+# Format and summarize the results.
+#
+# AUTHOR
+# Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+#
+# HISTORY
+# 2009-Nov-9: Initial version by Darren Hart <dvhart-VuQAYsv1562uYJLRA6qg5Q@public.gmane.orgcom>
+#
+###############################################################################
+
+# Test for a color capable shell and pass the result to the subdir scripts
+USE_COLOR=0
+tput setf 7
+if [ $? -eq 0 ]; then
+ USE_COLOR=1
+ tput sgr0
+fi
+export USE_COLOR
+
+(cd functional; ./run.sh)
--
2.1.4
^ permalink raw reply related
* [PATCH 2/6] selftests/futex: Update Makefile to use lib.mk
From: Darren Hart @ 2015-05-13 4:07 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: chrubis-AlSwsSmVLrQ, Darren Hart, Shuah Khan,
linux-api-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Peter Zijlstra,
Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <cover.1431489408.git.dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Adapt the futextest Makefiles to use lib.mk macros for RUN_TESTS and
EMIT_TESTS. For now, we reuse the run.sh mechanism provided by
futextest. This doesn't provide the standard selftests: [PASS|FAIL]
format, but the tests provide very similar output already.
This results in the run_kselftest.sh script for futexes including a
single line: ./run.sh
Cc: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Davidlohr Bueso <dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
Cc: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Signed-off-by: Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
tools/testing/selftests/futex/Makefile | 20 +++++++++++++++++++-
tools/testing/selftests/futex/functional/Makefile | 5 +++--
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/futex/Makefile b/tools/testing/selftests/futex/Makefile
index 2c26d59..6a17529 100644
--- a/tools/testing/selftests/futex/Makefile
+++ b/tools/testing/selftests/futex/Makefile
@@ -1,11 +1,29 @@
SUBDIRS := functional
+TEST_PROGS := run.sh
+
.PHONY: all clean
all:
for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done
-run_tests: all
+include ../lib.mk
+
+override define RUN_TESTS
./run.sh
+endef
+
+override define INSTALL_RULE
+ mkdir -p $(INSTALL_PATH)
+ install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED) $(TEST_FILES)
+
+ @for SUBDIR in $(SUBDIRS); do \
+ $(MAKE) -C $$SUBDIR INSTALL_PATH=$(INSTALL_PATH)/$$SUBDIR install; \
+ done;
+endef
+
+override define EMIT_TESTS
+ echo "./run.sh"
+endef
clean:
for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done
diff --git a/tools/testing/selftests/futex/functional/Makefile b/tools/testing/selftests/futex/functional/Makefile
index 720023e..4b018fe 100644
--- a/tools/testing/selftests/futex/functional/Makefile
+++ b/tools/testing/selftests/futex/functional/Makefile
@@ -12,13 +12,14 @@ TARGETS := \
futex_wait_uninitialized_heap \
futex_wait_private_mapped_file
+TEST_PROGS := $(TARGETS) run.sh
+
.PHONY: all clean
all: $(TARGETS)
$(TARGETS): $(HEADERS)
-run_tests: all
- ./run.sh
+include ../../lib.mk
clean:
rm -f $(TARGETS)
--
2.1.4
^ permalink raw reply related
* [PATCH 3/6] selftests/futex: Increment ksft pass and fail counters
From: Darren Hart @ 2015-05-13 4:07 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: chrubis, Darren Hart, Shuah Khan, linux-api, Ingo Molnar,
Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <cover.1431489408.git.dvhart@linux.intel.com>
Add kselftest.h to logging.h and increment the pass and fail counters as
part of the print_result routine which is called by all futex tests.
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: linux-api@vger.kernel.org
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
tools/testing/selftests/futex/functional/Makefile | 2 +-
tools/testing/selftests/futex/include/logging.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/futex/functional/Makefile b/tools/testing/selftests/futex/functional/Makefile
index 4b018fe..9d6b75e 100644
--- a/tools/testing/selftests/futex/functional/Makefile
+++ b/tools/testing/selftests/futex/functional/Makefile
@@ -1,4 +1,4 @@
-INCLUDES := -I../include
+INCLUDES := -I../include -I../../
CFLAGS := $(CFLAGS) -g -O2 -Wall -D_GNU_SOURCE -pthread $(INCLUDES)
LDFLAGS := $(LDFLAGS) -pthread -lrt
diff --git a/tools/testing/selftests/futex/include/logging.h b/tools/testing/selftests/futex/include/logging.h
index f6ed5c2..014aa01 100644
--- a/tools/testing/selftests/futex/include/logging.h
+++ b/tools/testing/selftests/futex/include/logging.h
@@ -24,6 +24,7 @@
#include <string.h>
#include <unistd.h>
#include <linux/futex.h>
+#include "kselftest.h"
/*
* Define PASS, ERROR, and FAIL strings with and without color escape
@@ -111,12 +112,14 @@ void print_result(int ret)
switch (ret) {
case RET_PASS:
+ ksft_inc_pass_cnt();
result = PASS;
break;
case RET_ERROR:
result = ERROR;
break;
case RET_FAIL:
+ ksft_inc_fail_cnt();
result = FAIL;
break;
}
--
2.1.4
^ permalink raw reply related
* [PATCH 4/6] selftests: Add futex tests to the top-level Makefile
From: Darren Hart @ 2015-05-13 4:07 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: chrubis, Darren Hart, Shuah Khan, linux-api, Ingo Molnar,
Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <cover.1431489408.git.dvhart@linux.intel.com>
Enable futex tests to be built and run with the make kselftest and
associated targets.
Most of the tests require escalated privileges. These return ERROR, and
run.sh continues.
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: linux-api@vger.kernel.org
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
tools/testing/selftests/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 95abddc..ebac6b8 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -4,6 +4,7 @@ TARGETS += efivarfs
TARGETS += exec
TARGETS += firmware
TARGETS += ftrace
+TARGETS += futex
TARGETS += kcmp
TARGETS += memfd
TARGETS += memory-hotplug
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox