be triggered from the brk syscall). The
vm_brk() is called only from binmft handlers so it shouldn't be
triggered unless binmft handler created overlapping mappings.
Signed-off-by: Cyril Hrubis chru...@suse.cz
---
mm/mmap.c | 50 ++
1 file changed, 46
be triggered from the brk syscall). The
vm_brk() is called only from binmft handlers so it shouldn't be
triggered unless binmft handler created overlapping mappings.
Signed-off-by: Cyril Hrubis chru...@suse.cz
---
mm/mmap.c | 50 ++
1 file changed, 46
in a couple weeks most likely. I have some urgent
things that will be taking all my time and then some until then. Feel free
to poke me though if I lose track of it :-)
Do you still plan to work on this?
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe
-trash running? That thing is known to
probe newly mounted filesystems preventing them from being unmounted for
a certain amount of time.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
(here: Ubuntu/precise?
Just kill the process, or run the testcases via ssh session.
And can this issue be documented?
Hmm, maybe we can change the test cases to complain loudly if the
process is found running.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line
circle with i on the right, that, when clicked on shows md5 and
sha1. These were generated by sf.net servers but I've checked that they
match the files I've created.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
-test-project/ltp/wiki/BuildSystem
Patches, new tests, bugs, comments or questions should go to
to our mailing list at ltp-l...@lists.sourceforge.net.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
://github.com/linux-test-project/ltp/commit/6270ba2ebe999ffdb1364e5e814d7e56070a0198
Some of these are losely based on futextest some are written from
scratch. The requeue operation, pi futexes and bitset are not covered
yet.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send
.
And should be fixed in latest git. Now the testcases complain about the
failure, give a hint what may be causing it, and if the umount() is not
the the syscall under test, it's retried a few times with short usleep
between.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send
-Writing-Guidelines
https://github.com/linux-test-project/ltp/wiki/BuildSystem
https://lwn.net/Articles/625969/
https://lwn.net/Articles/630542/
Patches, new tests, bugs, comments or questions should go to
to our mailing list at ltp-list@ltp-l...@lists.sourceforge.net.
--
Cyril Hrubis
chru...@suse.cz
with that.
Hmm, and it looks like this is not implemented on Linux anyway.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
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).
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe
://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines#221-basic-test-structure
[2]
https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines#224-safe-macros
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
, comments or questions should go to to our
mailing list at ltp-l...@lists.sourceforge.net.
PS: We had numerous troubles with mailing list on sourceforge, if you are aware
of good and free mailing list hosting service please let us know.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from
urrent time
+ small amount. I will have a look at the second test as well.
> [1]
> https://github.com/linux-test-project/ltp/blob/20150903/testcases/kernel/syscalls/settimeofday/settimeofday01.c
> [2]
> https://github.com/linux-test-project/ltp/blob/20150903/testcases/kernel/timers/clock_
/blob/20150903/testcases/kernel/syscalls/settimeofday/settimeofday01.c
> > [2]
> > https://github.com/linux-test-project/ltp/blob/20150903/testcases/kernel/timers/clock_settime/clock_settime02.c
Both should be fixed in latest git.
--
Cyril Hrubis
chru...@suse.cz
--
To unsub
bit which should be fixed.
The fix looks good to me.
--
Cyril Hrubis
chru...@suse.cz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
also fix the test to use
the CLOCK_MONOTONIC timer.
And of course the error margin must not be used when we check that the
elapsed time wasn't shorter than we expected.
Does that sound reasonable?
--
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
test uses gettimeofday() to measure the elapsed time, it
should use CLOCK_MONOTONIC instead.
--
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
ugs, comments or questions should go to to our
new mailing list at l...@lists.linux.it
PS: Special thanks to Italian Linux Society (www.ils.org) that provides us with
rock solid mailing list hosting. This release wouldn't be possible without
their kind help.
--
Cyril Hrubis
chru...@suse.cz
or questions should go to to our
mailing list at l...@lists.linux.it.
--
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
/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
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
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
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
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
://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
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
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
= 3 ee_code = 1 ee_info = 0 ee_data = 0
So we get EHOSTUNREACH on SO_EE_ORIGIN_ICMP.
--
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
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
-0400
sock: do not set sk_err in sock_dequeue_err_skb
--
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
?
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
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
hes for SLES kernels.
--
Cyril Hrubis
chru...@suse.cz
ould probably be a best fit.
--
Cyril Hrubis
chru...@suse.cz
pping addresses."
Which should at least hint the reader that this is architecture specific.
--
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
HPUXMAP_FIXED and HPUXMAP_REPLACE.
[1] https://github.com/dspinellis/unix-history-repo
--
Cyril Hrubis
chru...@suse.cz
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
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
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
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
t the sched one was simply
picked first here.
> Thanks for pointing this out.
Glad to help :-).
--
Cyril Hrubis
chru...@suse.cz
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
n't be triggered from the brk syscall). The
vm_brk() is called only from binmft handlers so it shouldn't be
triggered unless binmft handler created overlapping mappings.
Signed-off-by: Cyril Hrubis
---
mm/mmap.c | 50 ++
1 file changed, 46 insertions(+)
n't be triggered from the brk syscall). The
vm_brk() is called only from binmft handlers so it shouldn't be
triggered unless binmft handler created overlapping mappings.
Signed-off-by: Cyril Hrubis
---
mm/mmap.c | 50 ++
1 file changed, 46 insertions(+)
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
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
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
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
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
sk_err in sock_dequeue_err_skb
--
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
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
= 3 ee_code = 1 ee_info = 0 ee_data = 0
So we get EHOSTUNREACH on SO_EE_ORIGIN_ICMP.
--
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
hes for SLES kernels.
--
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
ould probably be a best fit.
--
Cyril Hrubis
chru...@suse.cz
pping addresses."
Which should at least hint the reader that this is architecture specific.
--
Cyril Hrubis
chru...@suse.cz
HPUXMAP_FIXED and HPUXMAP_REPLACE.
[1] https://github.com/dspinellis/unix-history-repo
--
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
?
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
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
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
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
et break on a kernel address");
--
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
e the separate test.
--
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
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
, 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
, 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
as it should have been.
--
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
perf/hw_breakpoint: Modify breakpoint even if the new attr has disabled set
--
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
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
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
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
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
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
t the sched one was simply
picked first here.
> Thanks for pointing this out.
Glad to help :-).
--
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
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
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
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
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
1 - 100 of 140 matches
Mail list logo