Hi,friend,
This is Daniel Murray and i am purchasing manager from Sinara Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Thanks and Best Regards,
Daniel Murray
Purchasing Manager
Sinara Group Co.,LTD
Hi All,
I am trying to build kselftest on Linux-5.4-rc3+ on ubuntu 18.04. I
installed LLVM-9.0.0 and Clang-9.0.0 from below links after following
steps from [1] because of discussion [2]
https://releases.llvm.org/9.0.0/llvm-9.0.0.src.tar.xzhttps://releases.llvm.org/9.0.0/clang-tools-extra-9.0.0.src.tar.xzhttps://releases.llvm.org/9.0.0/cfe-9.0.0.src.tar.xz
After that I started this error.
make[2]: Leaving directory '/usr/src/tovards/linux/tools/lib/bpf'
(clang -I. -I./include/uapi -I../../../include/uapi
-I/usr/src/tovards/linux/tools/testing/selftests/bpf/../usr/include
-D__TARGET_ARCH_arm64 -idirafter /usr/local/include -idirafter
/usr/local/lib/clang/9.0.0/include -idirafter
/usr/include/aarch64-linux-gnu -idirafter /usr/include
-Wno-compare-distinct-pointer-types -O2 -target bpf -emit-llvm \
-c progs/test_core_reloc_ints.c -o - || echo "clang failed") | \
llc -march=arm64 -mcpu=generic -filetype=obj -o
/usr/src/tovards/linux/tools/testing/selftests/bpf/test_core_reloc_ints.o
progs/test_core_reloc_ints.c:32:6: error: using
builtin_preserve_access_index() without -g
if (BPF_CORE_READ(&out->u8_field, &in->u8_field) ||
^
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^
progs/test_core_reloc_ints.c:33:6: error: using
builtin_preserve_access_index() without -g
BPF_CORE_READ(&out->s8_field, &in->s8_field) ||
^
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^
progs/test_core_reloc_ints.c:34:6: error: using
builtin_preserve_access_index() without -g
BPF_CORE_READ(&out->u16_field, &in->u16_field) ||
^
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^
progs/test_core_reloc_ints.c:35:6: error: using
builtin_preserve_access_index() without -g
BPF_CORE_READ(&out->s16_field, &in->s16_field) ||
^
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^
progs/test_core_reloc_ints.c:36:6: error: using
builtin_preserve_access_index() without -g
BPF_CORE_READ(&out->u32_field, &in->u32_field) ||
^
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^
progs/test_core_reloc_ints.c:37:6: error: using
builtin_preserve_access_index() without -g
BPF_CORE_READ(&out->s32_field, &in->s32_field) ||
^
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^
progs/test_core_reloc_ints.c:38:6: error: using
builtin_preserve_access_index() without -g
BPF_CORE_READ(&out->u64_field, &in->u64_field) ||
^
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^
progs/test_core_reloc_ints.c:39:6: error: using
builtin_preserve_access_index() without -g
BPF_CORE_READ(&out->s64_field, &in->s64_field))
^
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^
8 errors generated.
llc: error: llc: <stdin>:1:1: error: expected top-level entity
clang failed
In order to solve this error, I modifed bpf/Makefile as
CLANG_CFLAGS = $(CLANG_SYS_INCLUDES) \
- -Wno-compare-distinct-pointer-types
+ -Wno-compare-distinct-pointer-types -g
Now I am getting this error
(clang -I. -I./include/uapi -I../../../include/uapi
-I/usr/src/tovards/linux/tools/testing/selftests/bpf/../usr/include
-D__TARGET_ARCH_arm64 -idirafter /usr/local/include -idirafter
/usr/local/lib/clang/9.0.0/include -idirafter
/usr/include/aarch64-linux-gnu -idirafter /usr/include
-Wno-compare-distinct-pointer-types -g -O2 -target bpf -emit-llvm \
-c progs/test_core_reloc_ints.c -o - || echo "clang failed") | \
llc -march=arm64 -mcpu=generic -filetype=obj -o
/usr/src/tovards/linux/tools/testing/selftests/bpf/test_core_reloc_ints.o
LLVM ERROR: Cannot select: intrinsic %llvm.preserve.struct.access.index
Makefile:267: recipe for target
'/usr/src/tovards/linux/tools/testing/selftests/bpf/test_core_reloc_ints.o'
failed
make[1]: ***
[/usr/src/tovards/linux/tools/testing/selftests/bpf/test_core_reloc_ints.o]
Error 1
Please suggest!!
--prabhakar(pk)
[1]
https://stackoverflow.com/questions/47255526/how-to-build-the-latest-clang-…
[2] https://www.mail-archive.com/netdev@vger.kernel.org/msg315096.html
Linux top-commit
----------------
commit bc88f85c6c09306bd21917e1ae28205e9cd775a7 (HEAD -> master,
origin/master, origin/HEAD)
Author: Ben Dooks <ben.dooks(a)codethink.co.uk>
Date: Wed Oct 16 12:24:58 2019 +0100
kthread: make __kthread_queue_delayed_work static
The __kthread_queue_delayed_work is not exported so
make it static, to avoid the following sparse warning:
kernel/kthread.c:869:6: warning: symbol
'__kthread_queue_delayed_work' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks(a)codethink.co.uk>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Hey Knut and Shuah,
Following up on our offline discussion on Wednesday night:
We decided that it would make sense for Knut to try to implement Hybrid
Testing (testing that crosses the kernel userspace boundary) that he
introduced here[1] on top of the existing KUnit infrastructure.
We discussed several possible things in the kernel that Knut could test
with the new Hybrid Testing feature as an initial example. Those were
(in reverse order of expected difficulty):
1. RDS (Reliable Datagram Sockets) - We decided that, although this was
one of the more complicated subsystems to work with, it was probably
the best candidate for Knut to start with because it was in desperate
need of better testing, much of the testing would require crossing
the kernel userspace boundary to be effective, and Knut has access to
RDS (since he works at Oracle).
2. KMOD - Probably much simpler than RDS, and the maintainer, Luis
Chamberlain (CC'ed) would like to see better testing here, but
probably still not as good as RDS because it is in less dire need of
testing, collaboration on this would be more difficult, and Luis is
currently on an extended vacation. Luis and I had already been
discussing testing KMOD here[2].
3. IP over USB - Least desirable option, but still possible. More
complicated than KMOD, and not as easy to collaborate on as RDS.
I don't really think we discussed how this would work. I remember that I
mentioned that it would be easier if I sent out a patch that
centralizes where KUnit tests are dispatched from in the kernel; I will
try to get an RFC for that out, probably sometime next week. That should
provide a pretty straightforward place for Knut to move his work on top
of.
The next question is what the userspace component of this should look
like. To me it seems like we should probably have the kselftest test
runner manage when the test gets run, and collecting and reporting the
result of the test, but I think Knut has thought more about this than I,
and Shuah is the kselftest maintainer, so I am guessing this will
probably mostly be a discussion between the two of you.
So I think we have a couple of TODOs between us:
Brendan:
- Need to send out patch that provides a single place where all tests
are dispatched from.
Knut:
- Start splitting out the hybrid test stuff from the rest of the RFC
you sent previously.
Knut and Shuah:
- Start figuring out what the userspace component of this will look
like.
Cheers!
[1] https://lore.kernel.org/linux-kselftest/524b4e062500c6a240d4d7c0e1d0a299680…
[2] https://groups.google.com/forum/#!topic/kunit-dev/CdIytJtii00
Sorry for the delayed reply. I was on vacation.
On Fri, Oct 11, 2019 at 5:16 AM Theodore Ts'o <theodore.tso(a)gmail.com> wrote:
>
>
>
> On Friday, October 11, 2019 at 7:19:49 AM UTC-4, Brendan Higgins wrote:
>>
>>
>> Should we maybe drop `--build_dir` in favor of `O`?
>
>
> How about if "make kunit" results in "./tools/testing/kunit/kunit.py run --build_dir=/.kunit --allconfig"
>
> ... where --allconfig automatically creates kunitconfig but in includes all of the CONFIG options which depends on CONFIG_KUNIT, so that all unit tests are run? That way, we make it super easy for people to run the unit tests. Since most users are used using make targets, this I bet will significantly increase the number of developers using kunit, because it will be super-duper convenient for them.
>
> Also, it would be nice if kunit.py first looks for kunitconfig in build_dir, and then in the top-level of the kernel sources, and we put .kunit in .gitignore. That will make "git status" look nice and clean.
>
> What do folks think?
Having something like --allconfig is the ultimate goal. I had been
talking to Luis and Shuah about this for some time.
I think the best way to make this work would be for kunit_tool to be
able to detect all the tests with CONFIG_KUNIT as you suggest (or
something like it). Luis actually already suggested it; however, we
identified that this would likely not be as easy as it sounds as it is
possible to have mutually exclusive CONFIGs. Luis pointed out that
some researchers are currently working on a sat solver for Kconfig
that we could use to potentially address this problem. Nevertheless, a
complete solution in this regard is actually somewhat difficult.
Shuah's solution was just to use CONFIG fragments in the meantime
similar to what kselftest already does. I was leaning in that
direction since kselftest already does that and we know that it works.
Shuah, Luis, does this still match what you have been thinking?
+open list:KERNEL SELFTEST FRAMEWORK In case anyone in kselftest has
any thoughts.
On Thu, Oct 10, 2019 at 7:05 PM Theodore Ts'o <theodore.tso(a)gmail.com> wrote:
>
> I've been experimenting with the ext4 kunit test case, and something that would be really helpful is if the default is to store the object files for the ARCM=um kernel and its .config file in the top-level directory .kunit. That is, that the default for --build_dir should be .kunit.
>
> Why does this important? Because the kernel developer will want to be running unit tests as well as building kernels that can be run under whatever architecture they are normally developing for (for example, an x86 kernel that can be run using kvm; or a arm64 kernel that gets run on an Android device by using the "fastboot" command). So that means we don't want to be overwriting the object files and .config files for building the kernel for x86 when building the kunit kernel using the um arch. For example, for ext4, my ideal workflow might go something like this:
That's a good point.
> <hack hack hack>
> % ./tools/testing/kunit/kunit.py run
> <watch to see that unit tests succeed, and since most of the object files have already been built for the kunit kernel in be stored in the .kunit directory, this will be fast, since only the modified files will need to be recompiled>
> % kbuild
> <this is a script that builds an x86 kernel in /build/ext4-64 that is designed to be run under either kvm or in a GCE VM; since the kunit object files are stored in /build/ext4-kunit, the pre-existing files when building for x86_64 haven't been disturbed, so this build is fast as well>
> % kvm-xfstests smoke
> <this will run xfstests using the kernel plucked from /build/ext-64, using kvm>
>
> The point is when I'm developing an ext4 feature, or reviewing and merging ext4 commits, I need to be able to maintain separate build trees and separate config files for ARCH=um as well as ARCH=x86_64, and if the ARCH=um are stored in the kernel sources, then building with O=... doesn't work:
>
> <tytso@lambda> {/usr/projects/linux/kunit} (kunit)
> 1084% make O=/build/test-dir
> make[1]: Entering directory '/build/test-dir'
> ***
> *** The source tree is not clean, please run 'make mrproper'
> *** in /usr/projects/linux/kunit
> ***
Should we maybe drop `--build_dir` in favor of `O`?
> One of the other reasons why it would be good to use --build_dir by default is that way, building with a separate O= build directory is regularly tested. Right now, "kunit.py --build_dir=" seems to be broken.
Good point.
> % ./tools/testing/kunit/kunit.py run --build_dir=/build/ext4-kunit
> Generating .config ...
> [22:04:12] Building KUnit Kernel ...
> /usr/projects/linux/kunit/arch/x86/um/user-offsets.c:20:10: fatal error: asm/syscalls_64.h: No such file or directory
> 20 | #include <asm/syscalls_64.h>
> | ^~~~~~~~~~~~~~~~~~~
> compilation terminated.
>
> (This appears to be an ARCH=um bug, not a kunit bug, though.)
Yeah, I encountered this before. Some file is not getting properly
cleaned up by `make mrproper`. It works if you do `git clean -fdx` (I
know that's not a real solution for most people). Nevertheless, it
sounds like we need to sit down and actually solve this problem since
it is affecting users now.
I think you make a compelling argument. Anyone else have any thoughts on this?
From: Kees Cook <keescook(a)chromium.org>
[ Upstream commit 852c8cbf34d3b3130a05c38064dd98614f97d3a8 ]
Commit a745f7af3cbd ("selftests/harness: Add 30 second timeout per
test") solves the problem of kselftest_harness.h-using binary tests
possibly hanging forever. However, scripts and other binaries can still
hang forever. This adds a global timeout to each test script run.
To make this configurable (e.g. as needed in the "rtc" test case),
include a new per-test-directory "settings" file (similar to "config")
that can contain kselftest-specific settings. The first recognized field
is "timeout".
Additionally, this splits the reporting for timeouts into a specific
"TIMEOUT" not-ok (and adds exit code reporting in the remaining case).
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/kselftest/runner.sh | 36 +++++++++++++++++++--
tools/testing/selftests/rtc/settings | 1 +
2 files changed, 34 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/rtc/settings
diff --git a/tools/testing/selftests/kselftest/runner.sh b/tools/testing/selftests/kselftest/runner.sh
index 00c9020bdda8b..84de7bc74f2cf 100644
--- a/tools/testing/selftests/kselftest/runner.sh
+++ b/tools/testing/selftests/kselftest/runner.sh
@@ -3,9 +3,14 @@
#
# Runs a set of tests in a given subdirectory.
export skip_rc=4
+export timeout_rc=124
export logfile=/dev/stdout
export per_test_logging=
+# Defaults for "settings" file fields:
+# "timeout" how many seconds to let each test run before failing.
+export kselftest_default_timeout=45
+
# There isn't a shell-agnostic way to find the path of a sourced file,
# so we must rely on BASE_DIR being set to find other tools.
if [ -z "$BASE_DIR" ]; then
@@ -24,6 +29,16 @@ tap_prefix()
fi
}
+tap_timeout()
+{
+ # Make sure tests will time out if utility is available.
+ if [ -x /usr/bin/timeout ] ; then
+ /usr/bin/timeout "$kselftest_timeout" "$1"
+ else
+ "$1"
+ fi
+}
+
run_one()
{
DIR="$1"
@@ -32,6 +47,18 @@ run_one()
BASENAME_TEST=$(basename $TEST)
+ # Reset any "settings"-file variables.
+ export kselftest_timeout="$kselftest_default_timeout"
+ # Load per-test-directory kselftest "settings" file.
+ settings="$BASE_DIR/$DIR/settings"
+ if [ -r "$settings" ] ; then
+ while read line ; do
+ field=$(echo "$line" | cut -d= -f1)
+ value=$(echo "$line" | cut -d= -f2-)
+ eval "kselftest_$field"="$value"
+ done < "$settings"
+ fi
+
TEST_HDR_MSG="selftests: $DIR: $BASENAME_TEST"
echo "# $TEST_HDR_MSG"
if [ ! -x "$TEST" ]; then
@@ -44,14 +71,17 @@ run_one()
echo "not ok $test_num $TEST_HDR_MSG"
else
cd `dirname $TEST` > /dev/null
- (((((./$BASENAME_TEST 2>&1; echo $? >&3) |
+ ((((( tap_timeout ./$BASENAME_TEST 2>&1; echo $? >&3) |
tap_prefix >&4) 3>&1) |
(read xs; exit $xs)) 4>>"$logfile" &&
echo "ok $test_num $TEST_HDR_MSG") ||
- (if [ $? -eq $skip_rc ]; then \
+ (rc=$?; \
+ if [ $rc -eq $skip_rc ]; then \
echo "not ok $test_num $TEST_HDR_MSG # SKIP"
+ elif [ $rc -eq $timeout_rc ]; then \
+ echo "not ok $test_num $TEST_HDR_MSG # TIMEOUT"
else
- echo "not ok $test_num $TEST_HDR_MSG"
+ echo "not ok $test_num $TEST_HDR_MSG # exit=$rc"
fi)
cd - >/dev/null
fi
diff --git a/tools/testing/selftests/rtc/settings b/tools/testing/selftests/rtc/settings
new file mode 100644
index 0000000000000..ba4d85f74cd6b
--- /dev/null
+++ b/tools/testing/selftests/rtc/settings
@@ -0,0 +1 @@
+timeout=90
--
2.20.1
From: Cristian Marussi <cristian.marussi(a)arm.com>
[ Upstream commit 131b30c94fbc0adb15f911609884dd39dada8f00 ]
A TARGET which failed to be built/installed should not be included in the
runlist generated inside the run_kselftest.sh script.
Signed-off-by: Cristian Marussi <cristian.marussi(a)arm.com>
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 25b43a8c2b159..1779923d7a7b8 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -198,8 +198,12 @@ ifdef INSTALL_PATH
echo " cat /dev/null > \$$logfile" >> $(ALL_SCRIPT)
echo "fi" >> $(ALL_SCRIPT)
+ @# While building run_kselftest.sh skip also non-existent TARGET dirs:
+ @# they could be the result of a build failure and should NOT be
+ @# included in the generated runlist.
for TARGET in $(TARGETS); do \
BUILD_TARGET=$$BUILD/$$TARGET; \
+ [ ! -d $$INSTALL_PATH/$$TARGET ] && echo "Skipping non-existent dir: $$TARGET" && continue; \
echo "[ -w /dev/kmsg ] && echo \"kselftest: Running tests in $$TARGET\" >> /dev/kmsg" >> $(ALL_SCRIPT); \
echo "cd $$TARGET" >> $(ALL_SCRIPT); \
echo -n "run_many" >> $(ALL_SCRIPT); \
--
2.20.1
Currently, when a task is dead we still print the pid it used to use in
the fdinfo files of its pidfds. This doesn't make much sense since the
pid may have already been reused. So verify that the task is still
alive. If the task is not alive anymore, we will print -1. This allows
us to differentiate between a task not being present in a given pid
namespace - in which case we already print 0 - and a task having been
reaped.
Note that this uses PIDTYPE_PID for the check. Technically, we could've
checked PIDTYPE_TGID since pidfds currently only refer to thread-group
leaders but if they won't anymore in the future then this check becomes
problematic without it being immediately obvious to non-experts imho. If
a thread is created via clone(CLONE_THREAD) than struct pid has a single
non-empty list pid->tasks[PIDTYPE_PID] and this pid can't be used as a
PIDTYPE_TGID meaning pid->tasks[PIDTYPE_TGID] will return NULL even
though the thread-group leader might still be very much alive. We could
be more complicated and do something like:
bool alive = false;
rcu_read_lock();
struct task_struct *tsk = pid_task(pid, PIDTYPE_PID);
if (tsk && task_tgid(tsk))
alive = true;
rcu_read_unlock();
but it's really not worth it. We already have created a pidfd and we
thus know it refers to a thread-group leader. Checking PIDTYPE_PID is
fine and is easier to maintain should we ever allow pidfds to refer to
threads.
Cc: Jann Horn <jannh(a)google.com>
Cc: Christian Kellner <christian(a)kellner.me>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: linux-api(a)vger.kernel.org
Signed-off-by: Christian Brauner <christian.brauner(a)ubuntu.com>
---
kernel/fork.c | 29 +++++++++++++++++++++++------
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 782986962d47..a67944a5e542 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1695,6 +1695,18 @@ static int pidfd_release(struct inode *inode, struct file *file)
}
#ifdef CONFIG_PROC_FS
+static inline bool task_alive(struct pid *pid)
+{
+ bool alive = true;
+
+ rcu_read_lock();
+ if (!pid_task(pid, PIDTYPE_PID))
+ alive = false;
+ rcu_read_unlock();
+
+ return alive;
+}
+
/**
* pidfd_show_fdinfo - print information about a pidfd
* @m: proc fdinfo file
@@ -1732,15 +1744,20 @@ static int pidfd_release(struct inode *inode, struct file *file)
*/
static void pidfd_show_fdinfo(struct seq_file *m, struct file *f)
{
- struct pid_namespace *ns = proc_pid_ns(file_inode(m->file));
struct pid *pid = f->private_data;
- pid_t nr = pid_nr_ns(pid, ns);
+ struct pid_namespace *ns;
+ pid_t nr = -1;
+
+ if (likely(task_alive(pid))) {
+ ns = proc_pid_ns(file_inode(m->file));
+ nr = pid_nr_ns(pid, ns);
+ }
- seq_put_decimal_ull(m, "Pid:\t", nr);
+ seq_put_decimal_ll(m, "Pid:\t", nr);
#ifdef CONFIG_PID_NS
- seq_put_decimal_ull(m, "\nNSpid:\t", nr);
- if (nr) {
+ seq_put_decimal_ll(m, "\nNSpid:\t", nr);
+ if (nr > 0) {
int i;
/* If nr is non-zero it means that 'pid' is valid and that
@@ -1749,7 +1766,7 @@ static void pidfd_show_fdinfo(struct seq_file *m, struct file *f)
* Start at one below the already printed level.
*/
for (i = ns->level + 1; i <= pid->level; i++)
- seq_put_decimal_ull(m, "\t", pid->numbers[i].nr);
+ seq_put_decimal_ll(m, "\t", pid->numbers[i].nr);
}
#endif
seq_putc(m, '\n');
--
2.23.0