REDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20200930..
88 Petr Vorel
52 Cyril Hrubis
25 Martin Doucha
19 Yang Xu
18 Viresh Kumar
10 Xiao Yang
8 Alexey Kodanev
8 Amir Goldstein
8 Feiyu Zhu
8
E #1 is anyway an issue, so I think documenting this
> proper is the right thing to do.
>
> Thoughts?
I guess that ideally BUGS section for time(2) and clock_gettime(2)
should be updated with this explanation.
--
Cyril Hrubis
chru...@suse.cz
h it took me a week to
write a first prototype from a scratch.
[1] https://github.com/metan-ucw/runltp-ng
--
Cyril Hrubis
chru...@suse.cz
what's exactly wrong with moving the system time forward for a
duration of the test?
--
Cyril Hrubis
chru...@suse.cz
Hi!
> > I would like to avoid triggering the "your system may be vunerable"
> > messages on fixed kernel, hence the separate test.
>
> Good point, go ahead with a separate test then.
Thanks for the review, pushed.
--
Cyril Hrubis
chru...@suse.cz
tests, bugs, comments or questions should go to to our mailing
list at l...@lists.linux.it.
CREDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20200515..
70 Petr Vorel
66 Viresh Kumar
37 Cyril Hrubis
35 Yang Xu
33 Martin
e the separate test.
--
Cyril Hrubis
chru...@suse.cz
ng addr;
>
> AFAICT, we're not compiling with --std=c99 so older compilers may
> complain about the variable declaration here.
The default std for gcc has been at least gnu90 for ages, which includes
subset of c99 features as well including this one. So unless you
explicitly pass --std=c90 or older it will work just fine.
I've moved the declaration to the top of the function nevertheless.
--
Cyril Hrubis
chru...@suse.cz
New regression test for a kernel commit:
commit bd14406b78e6daa1ea3c1673bda1ffc9efdeead0
Author: Jiri Olsa
Date: Mon Aug 27 11:12:25 2018 +0200
perf/hw_breakpoint: Modify breakpoint even if the new attr has disabled set
Signed-off-by: Cyril Hrubis
CC: Andy Lutomirski
CC: Peter Zijlstra
perf/hw_breakpoint: Modify breakpoint even if the new attr has disabled set
--
Cyril Hrubis
chru...@suse.cz
that enables the
breakpoint fails properly after the dr0 has been set to an address in
the kernel range.
Signed-off-by: Cyril Hrubis
CC: Andy Lutomirski
CC: Peter Zijlstra
CC: Thomas Gleixner
CC: Alexandre Chartre
---
testcases/kernel/syscalls/ptrace/ptrace08.c | 136 +++-
1 file
as it should have been.
--
Cyril Hrubis
chru...@suse.cz
, which made the test fail for no good reason.
So this patch changes the test to read the breakpoint address back
instead, which also means that we can drop the /proc/kallsyms parsing as
well.
Signed-off-by: Cyril Hrubis
CC: Andy Lutomirski
CC: Peter Zijlstra
CC: Thomas Gleixner
CC: Alexandre
the previous emails? I guess that this would end
up as a per-architecture mess of ifdefs if we wanted to hardcode it.
--
Cyril Hrubis
chru...@suse.cz
et break on a kernel address");
--
Cyril Hrubis
chru...@suse.cz
Hi!
As much as it's worth the changes looks good to me.
@Jan: I guess that we can as well fix this in LTP first then we can try
to get the kernel version fixed...
--
Cyril Hrubis
chru...@suse.cz
el and could not be killed. So
this looks like deadlock somewhere in filesystem code.
--
Cyril Hrubis
chru...@suse.cz
for documentation or read library source code when
debugging. Think of all the poor kernel QA folks that will cry in
despair when you decided not to submit manual pages.
There is plenty of stuff documented there that most C programmers
shouldn't touch, I do not consider this to be a valid excuse.
--
Cyril Hrubis
chru...@suse.cz
the write to register 7 enables the breakpoints and
what we attempt here is to change an invalid address to a valid one after we
enabled the breakpoint but that's as far I can go.
So does anyone has an idea how to trigger the bug without the do_debug function
address? Would any valid kernel function address suffice?
--
Cyril Hrubis
chru...@suse.cz
has changed from EINVAL to EBADF in a
case we pass file descriptor to a regular file to setns().
--
Cyril Hrubis
chru...@suse.cz
ing
list at l...@lists.linux.it.
CREDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20200120..
105 Petr Vorel
49 Yang Xu
38 Viresh Kumar
35 Martin Doucha
33 Cyril Hrubis
11 Richard Palethorpe
10 Jan Stancek
But then again,
> this would be a bit ugly -- having CHECK_FIELDS would make this simpler.
Any pointers how can be the size figured out without relying on the
E2BIG we are testing for? Does the kernel export it somewhere?
--
Cyril Hrubis
chru...@suse.cz
?
--
Cyril Hrubis
chru...@suse.cz
s
https://github.com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our mailing
list at l...@lists.linux.it.
CREDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20190517..
68 Petr Vorel
he rest of
the threads.
> A note about my testing methodology:
> After I realized, that the execution often failed due to the offense thread
> running after referee set the_ball to 0, I replaced the loop with just
> usleep(1), for faster iteration.
> I tested on ubuntu 19.04 with linux 5.0.0-27 running in vmware and
> a custom yocto distribution running linux 4.19.59 (with and without rt
> patches)
--
Cyril Hrubis
chru...@suse.cz
, failure to write to /etc/passwd
probably means that filesystem is full or some problem happend and how
is remounted RO.
I do not see the kernel messages from this job anywhere at the job
pages, is it stored somewhere?
--
Cyril Hrubis
chru...@suse.cz
EBUSY after the loop device was
succesfully umounted.
We do run the test in a loop for several filesystems and the loop
generally does:
next:
mkfs
mount
test
umount
goto next;
--
Cyril Hrubis
chru...@suse.cz
Hi!
> commit: 8c7829b04c523cdc732cb77f59f03320e09f3386 ("mm: fix false-positive
> OVERCOMMIT_GUESS failures")
This has been reported on the LTP ML already, LTP tests needs to be
adjusted, see:
http://lists.linux.it/pipermail/ltp/2019-May/011962.html
--
Cyril Hrubis
chru...@suse.cz
ments or questions should go to to our mailing
list at l...@lists.linux.it.
CREDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20190115..
40 Petr Vorel
39 Enji Cooper
28 Cyril Hrubis
17 Alexey Kodanev
15 Petr Vorel
15 Xiao
a similar fix for mmap() with MAP_FIXED that caused a LTP
test to fail and was fixed in:
commit e8420a8ece80b3fe810415ecf061d54ca7fab266
Author: Cyril Hrubis
Date: Mon Apr 29 15:08:33 2013 -0700
mm/mmap: check for RLIMIT_AS before unmapping
And I haven't heard of any breakages so far s
Hi!
> > Of course, there aren't any tests for RWF_NOWAIT in xfstests. Are there
> > any in LTP?
Just FYI I've send a patch with basic RWF_NOWAIT test for review to LTP
ML and also CCed mailing lists from this thread.
https://lkml.org/lkml/2019/1/28/416
--
Cyril Hrubis
chru...@suse.cz
From: Cyril Hrubis
We are attempting to trigger the EAGAIN path for the RWF_NOWAIT flag.
In order to do so the test runs three threads:
* nowait_reader: reads from a random offset from a random file with
RWF_NOWAIT flag and expects to get EAGAIN and short
read
nd maintain them for free. LTP is also used in many QA departements
around the word so such tests will end up executed in different
environments also for free. Sadly this does not happen much and there
are only few exceptions so far. But maybe I wasn't shouting loudly
enough.
--
Cyril Hrubis
chru...@suse.cz
omments or questions should go to to our mailing
list at l...@lists.linux.it.
CREDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20180926..
41 Petr Vorel
28 Amir Goldstein
25 Alexey Kodanev
25 Xiao Yang
16 Jan Stancek
13
go to to our mailing
list at l...@lists.linux.it.
CREDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20180515..
61 Petr Vorel
31 Xiao Yang
28 Cyril Hrubis
25 Alexey Kodanev
18 Jan Stancek
13 Li Wang
9 Alist
go to to our mailing
list at l...@lists.linux.it.
CREDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20180515..
61 Petr Vorel
31 Xiao Yang
28 Cyril Hrubis
25 Alexey Kodanev
18 Jan Stancek
13 Li Wang
9 Alist
project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our mailing
list at l...@lists.linux.it.
CREDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20180118..
76 Petr Vorel <pvo...@suse.cz>
38
project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our mailing
list at l...@lists.linux.it.
CREDITS
===
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20180118..
76 Petr Vorel
38 Cyril Hrubis
37 Michael
t the sched one was simply
picked first here.
> Thanks for pointing this out.
Glad to help :-).
--
Cyril Hrubis
chru...@suse.cz
t the sched one was simply
picked first here.
> Thanks for pointing this out.
Glad to help :-).
--
Cyril Hrubis
chru...@suse.cz
Hi!
> Hummm, wondering how LTP sched tests could trigger this, since a quick
> grep into ltp didn't show DEADLINE usage.
See kernel/syscalls/sched_setattr/sched_setattr01.c
--
Cyril Hrubis
chru...@suse.cz
Hi!
> Hummm, wondering how LTP sched tests could trigger this, since a quick
> grep into ltp didn't show DEADLINE usage.
See kernel/syscalls/sched_setattr/sched_setattr01.c
--
Cyril Hrubis
chru...@suse.cz
com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our mailing
list at l...@lists.linux.it.
--
Cyril Hrubis
chru...@suse.cz
com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our mailing
list at l...@lists.linux.it.
--
Cyril Hrubis
chru...@suse.cz
?
Or do we ask BFDL[1] to choose the name?
[1] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
--
Cyril Hrubis
chru...@suse.cz
?
Or do we ask BFDL[1] to choose the name?
[1] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
--
Cyril Hrubis
chru...@suse.cz
Hi!
> Pretty map everyone agreed MAP_FIXED_SAFE was a bad
> name. MAP_FIXED_NOREPLACE (IIRC) was best replacement.
For what it's worth I do agree here.
--
Cyril Hrubis
chru...@suse.cz
Hi!
> Pretty map everyone agreed MAP_FIXED_SAFE was a bad
> name. MAP_FIXED_NOREPLACE (IIRC) was best replacement.
For what it's worth I do agree here.
--
Cyril Hrubis
chru...@suse.cz
HPUXMAP_FIXED and HPUXMAP_REPLACE.
[1] https://github.com/dspinellis/unix-history-repo
--
Cyril Hrubis
chru...@suse.cz
HPUXMAP_FIXED and HPUXMAP_REPLACE.
[1] https://github.com/dspinellis/unix-history-repo
--
Cyril Hrubis
chru...@suse.cz
nnot be
done properly, this is just about exporting one simple constant to
userspace after all.
> Or maybe you're thinking that since the SHMLBA cannot be put in the man
> pages, we could instead provide MapAlignment as sort of a different
> way to document the requirement?
This is my intention as well.
--
Cyril Hrubis
chru...@suse.cz
nnot be
done properly, this is just about exporting one simple constant to
userspace after all.
> Or maybe you're thinking that since the SHMLBA cannot be put in the man
> pages, we could instead provide MapAlignment as sort of a different
> way to document the requirement?
This is my intention as well.
--
Cyril Hrubis
chru...@suse.cz
ce if we had this information exported somehere so that we
do not have to rely on per-architecture ifdefs.
What about adding MapAligment or something similar to the /proc/meminfo?
--
Cyril Hrubis
chru...@suse.cz
ce if we had this information exported somehere so that we
do not have to rely on per-architecture ifdefs.
What about adding MapAligment or something similar to the /proc/meminfo?
--
Cyril Hrubis
chru...@suse.cz
pping addresses."
Which should at least hint the reader that this is architecture specific.
--
Cyril Hrubis
chru...@suse.cz
pping addresses."
Which should at least hint the reader that this is architecture specific.
--
Cyril Hrubis
chru...@suse.cz
ould probably be a best fit.
--
Cyril Hrubis
chru...@suse.cz
ould probably be a best fit.
--
Cyril Hrubis
chru...@suse.cz
hes for SLES kernels.
--
Cyril Hrubis
chru...@suse.cz
hes for SLES kernels.
--
Cyril Hrubis
chru...@suse.cz
er bells and
whistles are a nice to have, but at the end of the day you usually need
someone to reproduce/look at the problem, possibly check the source
code, report a bug, etc. Hence it does not make much sense to have an
automated system without dedicated engineers assigned to review the test
resul
er bells and
whistles are a nice to have, but at the end of the day you usually need
someone to reproduce/look at the problem, possibly check the source
code, report a bug, etc. Hence it does not make much sense to have an
automated system without dedicated engineers assigned to review the test
resul
test it may need a kernel source unpacked /usr/src/linux
as well.
Short HOWTO for building LTP from git is here:
https://github.com/linux-test-project/ltp/blob/master/doc/mini-howto-building-ltp-from-git.txt
And we do have (unofficional) packages for some SUSE distributions:
https://build.o
test it may need a kernel source unpacked /usr/src/linux
as well.
Short HOWTO for building LTP from git is here:
https://github.com/linux-test-project/ltp/blob/master/doc/mini-howto-building-ltp-from-git.txt
And we do have (unofficional) packages for some SUSE distributions:
https://build.o
https://github.com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our mailing
list at l...@lists.linux.it.
--
Cyril Hrubis
chru...@suse.cz
https://github.com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our mailing
list at l...@lists.linux.it.
--
Cyril Hrubis
chru...@suse.cz
7 is ok, but
> next-20170502 fail.
> Is it bug?
Looks like a kernel bug to me.
The test is a very simple one that just does:
add_key("keyring", "wjkey", NULL, 0, KEY_SPEC_THREAD_KEYRING));
And expects success.
Also CCing LTP ML and relevant maintainers.
--
Cyril Hrubis
chru...@suse.cz
7 is ok, but
> next-20170502 fail.
> Is it bug?
Looks like a kernel bug to me.
The test is a very simple one that just does:
add_key("keyring", "wjkey", NULL, 0, KEY_SPEC_THREAD_KEYRING));
And expects success.
Also CCing LTP ML and relevant maintainers.
--
Cyril Hrubis
chru...@suse.cz
queue, but that's a
> flawed assumption.
>
> Would you mind trying another shot in the darkness please? Thanks!
This patch seems to fix the issue, I've tried several times and poll()
just timeouts, haven't seen a single POLLERR in the ping strace.
You can add my Tested-by: for this patch as
queue, but that's a
> flawed assumption.
>
> Would you mind trying another shot in the darkness please? Thanks!
This patch seems to fix the issue, I've tried several times and poll()
just timeouts, haven't seen a single POLLERR in the ping strace.
You can add my Tested-by: for this patch as
= 3 ee_code = 1 ee_info = 0 ee_data = 0
So we get EHOSTUNREACH on SO_EE_ORIGIN_ICMP.
--
Cyril Hrubis
chru...@suse.cz
= 3 ee_code = 1 ee_info = 0 ee_data = 0
So we get EHOSTUNREACH on SO_EE_ORIGIN_ICMP.
--
Cyril Hrubis
chru...@suse.cz
Hi!
> Thank you for the confirmation. Could you please try the following
> patch to see if it fixes your issue?
Does not seem to help, I still got the same bussy loop.
--
Cyril Hrubis
chru...@suse.cz
Hi!
> Thank you for the confirmation. Could you please try the following
> patch to see if it fixes your issue?
Does not seem to help, I still got the same bussy loop.
--
Cyril Hrubis
chru...@suse.cz
is easily
reproducible.
> 2. I've also have sent a fix to iputils on
> https://github.com/iputils/iputils/pull/75. Would you be kind to try
> that pull request as well?
That fixed the problem, you can add:
Tested-by: Cyril Hrubis <chru...@suse.cz>
--
Cyril Hrubis
chru...@suse.cz
sent a fix to iputils on
> https://github.com/iputils/iputils/pull/75. Would you be kind to try
> that pull request as well?
That fixed the problem, you can add:
Tested-by: Cyril Hrubis
--
Cyril Hrubis
chru...@suse.cz
-0400
sock: do not set sk_err in sock_dequeue_err_skb
--
Cyril Hrubis
chru...@suse.cz
sk_err in sock_dequeue_err_skb
--
Cyril Hrubis
chru...@suse.cz
://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines
https://github.com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our
mailing list at l...@lists.linux.it.
--
Cyril Hrubis
chru...@suse.cz
://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines
https://github.com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our
mailing list at l...@lists.linux.it.
--
Cyril Hrubis
chru...@suse.cz
fail for
> more than one reason, it's not guaranteed which error code you'll get.)
That is quite common problem with LTP testcases. Do you care to send a
patch or should I fix that?
> In any case, once we have a fix merged, it would be nice for there to be an
> ltp
> test added for the "NULL payload with nonzero length" case with one of the key
> types that crashed the kernel.
Here as well, feel free to send a patch or at least point us to a
reproducer that could be turned into a testcase.
--
Cyril Hrubis
chru...@suse.cz
fail for
> more than one reason, it's not guaranteed which error code you'll get.)
That is quite common problem with LTP testcases. Do you care to send a
patch or should I fix that?
> In any case, once we have a fix merged, it would be nice for there to be an
> ltp
> test added for the "NULL payload with nonzero length" case with one of the key
> types that crashed the kernel.
Here as well, feel free to send a patch or at least point us to a
reproducer that could be turned into a testcase.
--
Cyril Hrubis
chru...@suse.cz
testing exactly the
corner case the patch is fixing.
So the tests needs to be fixed once this patch hits mainline. And the
best fix is to expect the SGID flag to be cleared on newer kernels.
--
Cyril Hrubis
chru...@suse.cz
testing exactly the
corner case the patch is fixing.
So the tests needs to be fixed once this patch hits mainline. And the
best fix is to expect the SGID flag to be cleared on newer kernels.
--
Cyril Hrubis
chru...@suse.cz
/linux-test-project/ltp/wiki/Test-Writing-Guidelines
https://github.com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our
mailing list at l...@lists.linux.it.
--
Cyril Hrubis
chru...@suse.cz
/linux-test-project/ltp/wiki/Test-Writing-Guidelines
https://github.com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our
mailing list at l...@lists.linux.it.
--
Cyril Hrubis
chru...@suse.cz
l file descriptors or files are equal,
so we may end up with some classes of files and file descriptors
some of them suitable for different subsets of operations.
I think that defining classes of objects and defining how syscalls
transform their state may yield something usable. But that would r
l file descriptors or files are equal,
so we may end up with some classes of files and file descriptors
some of them suitable for different subsets of operations.
I think that defining classes of objects and defining how syscalls
transform their state may yield something usable. But that would r
ith
something quite complex with a large set of exceptions from the rules.
> Cyril, Tavis, can you come up with some set of predicates that can be
> checked automatically yet still useful?
> We can start small, e.g. "must not alter virtual address space".
I will try to thing about this a bit.
--
Cyril Hrubis
chru...@suse.cz
ith
something quite complex with a large set of exceptions from the rules.
> Cyril, Tavis, can you come up with some set of predicates that can be
> checked automatically yet still useful?
> We can start small, e.g. "must not alter virtual address space".
I will try to thing about this a bit.
--
Cyril Hrubis
chru...@suse.cz
en we could write a classes of verify functions,
something as check_file_exits() and use them to check the results
accordingly.
I'm not sure if something like this is really doable or in the scope of
this project, but it may be worth a try.
--
Cyril Hrubis
chru...@suse.cz
en we could write a classes of verify functions,
something as check_file_exits() and use them to check the results
accordingly.
I'm not sure if something like this is really doable or in the scope of
this project, but it may be worth a try.
--
Cyril Hrubis
chru...@suse.cz
/Test-Writing-Guidelines
https://github.com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our
mailing list at ltp-l...@lists.linux.it
--
Cyril Hrubis
chru...@suse.cz
/Test-Writing-Guidelines
https://github.com/linux-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to to our
mailing list at ltp-l...@lists.linux.it
--
Cyril Hrubis
chru...@suse.cz
qual than 20ms and if this fact is documented. If we wanted to
be pedantic about this the man page shoud be patched...
Also this gives us reasonably safe upper bound on timer expiration to be
something as:
sleep_time * 1.125 + 20ms
Does this sounds reasonable now?
--
Cyril Hrubis
chru...@suse.cz
qual than 20ms and if this fact is documented. If we wanted to
be pedantic about this the man page shoud be patched...
Also this gives us reasonably safe upper bound on timer expiration to be
something as:
sleep_time * 1.125 + 20ms
Does this sounds reasonable now?
--
Cyril Hrubis
chru...@suse.cz
test uses gettimeofday() to measure the elapsed time, it
should use CLOCK_MONOTONIC instead.
--
Cyril Hrubis
chru...@suse.cz
test uses gettimeofday() to measure the elapsed time, it
should use CLOCK_MONOTONIC instead.
--
Cyril Hrubis
chru...@suse.cz
in futex() and if it
wakes too late it will fail to fill buffers. In practice this worked
fine for me for years.
--
Cyril Hrubis
chru...@suse.cz
in futex() and if it
wakes too late it will fail to fill buffers. In practice this worked
fine for me for years.
--
Cyril Hrubis
chru...@suse.cz
1 - 100 of 140 matches
Mail list logo
