This series is just a set of minor tweaks and improvements for the MTE
tests that I did while working on the asymmetric mode support for
userspace which seemed like they might be worth keeping even though the
prctl() for asymmetric mode got removed.
v2:
- Rebase onto v5.18-rc3
Mark Brown (4):
kselftest/arm64: Handle more kselftest result codes in MTE helpers
kselftest/arm64: Log unexpected asynchronous MTE faults
kselftest/arm64: Refactor parameter checking in mte_switch_mode()
kselftest/arm64: Add simple test for MTE prctl
tools/testing/selftests/arm64/mte/.gitignore | 1 +
.../testing/selftests/arm64/mte/check_prctl.c | 119 ++++++++++++++++++
.../selftests/arm64/mte/mte_common_util.c | 19 ++-
.../selftests/arm64/mte/mte_common_util.h | 15 ++-
4 files changed, 149 insertions(+), 5 deletions(-)
create mode 100644 tools/testing/selftests/arm64/mte/check_prctl.c
base-commit: b2d229d4ddb17db541098b83524d901257e93845
--
2.30.2
Add support for a new kind of kunit_suite registration macro called
kunit_test_init_section_suite(); this new registration macro allows the
registration of kunit_suites that reference functions marked __init and
data marked __initdata.
Signed-off-by: Brendan Higgins <brendanhiggins(a)google.com>
Tested-by: Martin Fernandez <martin.fernandez(a)eclypsium.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Reviewed-by: David Gow <davidgow(a)google.com>
---
Changes since last version:
Renamed the new kunit_suite registration macro for init functions to a
more readable name.
---
include/kunit/test.h | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 00b9ff7783ab..5a870f2d81f4 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -380,6 +380,34 @@ static inline int kunit_run_all_tests(void)
#define kunit_test_suite(suite) kunit_test_suites(&suite)
+/**
+ * kunit_test_init_section_suites() - used to register one or more &struct
+ * kunit_suite containing init functions or
+ * init data.
+ *
+ * @__suites: a statically allocated list of &struct kunit_suite.
+ *
+ * This functions identically as &kunit_test_suites() except that it suppresses
+ * modpost warnings for referencing functions marked __init or data marked
+ * __initdata; this is OK because currently KUnit only runs tests upon boot
+ * during the init phase or upon loading a module during the init phase.
+ *
+ * NOTE TO KUNIT DEVS: If we ever allow KUnit tests to be run after boot, these
+ * tests must be excluded.
+ *
+ * The only thing this macro does that's different from kunit_test_suites is
+ * that it suffixes the array and suite declarations it makes with _probe;
+ * modpost suppresses warnings about referencing init data for symbols named in
+ * this manner.
+ */
+#define kunit_test_init_section_suites(__suites...) \
+ __kunit_test_suites(CONCATENATE(__UNIQUE_ID(array), _probe), \
+ CONCATENATE(__UNIQUE_ID(suites), _probe), \
+ ##__suites)
+
+#define kunit_test_init_section_suite(suite) \
+ kunit_test_init_section_suites(&suite)
+
#define kunit_suite_for_each_test_case(suite, test_case) \
for (test_case = suite->test_cases; test_case->run_case; test_case++)
base-commit: b2d229d4ddb17db541098b83524d901257e93845
--
2.36.0.rc0.470.gd361397f0d-goog
Historically, it has been shown that intercepting kernel faults with
userfaultfd (thereby forcing the kernel to wait for an arbitrary amount
of time) can be exploited, or at least can make some kinds of exploits
easier. So, in 37cd0575b8 "userfaultfd: add UFFD_USER_MODE_ONLY" we
changed things so, in order for kernel faults to be handled by
userfaultfd, either the process needs CAP_SYS_PTRACE, or this sysctl
must be configured so that any unprivileged user can do it.
In a typical implementation of a hypervisor with live migration (take
QEMU/KVM as one such example), we do indeed need to be able to handle
kernel faults. But, both options above are less than ideal:
- Toggling the sysctl increases attack surface by allowing any
unprivileged user to do it.
- Granting the live migration process CAP_SYS_PTRACE gives it this
ability, but *also* the ability to "observe and control the
execution of another process [...], and examine and change [its]
memory and registers" (from ptrace(2)). This isn't something we need
or want to be able to do, so granting this permission violates the
"principle of least privilege".
This is all a long winded way to say: we want a more fine-grained way to
grant access to userfaultfd, without granting other additional
permissions at the same time.
To achieve this, add a /dev/userfaultfd misc device. This device
provides an alternative to the userfaultfd(2) syscall for the creation
of new userfaultfds. The idea is, any userfaultfds created this way will
be able to handle kernel faults, without the caller having any special
capabilities. Access to this mechanism is instead restricted using e.g.
standard filesystem permissions.
Signed-off-by: Axel Rasmussen <axelrasmussen(a)google.com>
---
fs/userfaultfd.c | 79 ++++++++++++++++++++++++++------
include/uapi/linux/userfaultfd.h | 4 ++
2 files changed, 69 insertions(+), 14 deletions(-)
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index aa0c47cb0d16..16d7573ab41a 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -29,6 +29,7 @@
#include <linux/ioctl.h>
#include <linux/security.h>
#include <linux/hugetlb.h>
+#include <linux/miscdevice.h>
int sysctl_unprivileged_userfaultfd __read_mostly;
@@ -65,6 +66,8 @@ struct userfaultfd_ctx {
unsigned int flags;
/* features requested from the userspace */
unsigned int features;
+ /* whether or not to handle kernel faults */
+ bool handle_kernel_faults;
/* released */
bool released;
/* memory mappings are changing because of non-cooperative event */
@@ -410,13 +413,8 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason)
if (ctx->features & UFFD_FEATURE_SIGBUS)
goto out;
- if ((vmf->flags & FAULT_FLAG_USER) == 0 &&
- ctx->flags & UFFD_USER_MODE_ONLY) {
- printk_once(KERN_WARNING "uffd: Set unprivileged_userfaultfd "
- "sysctl knob to 1 if kernel faults must be handled "
- "without obtaining CAP_SYS_PTRACE capability\n");
+ if (!(vmf->flags & FAULT_FLAG_USER) && !ctx->handle_kernel_faults)
goto out;
- }
/*
* If it's already released don't get it. This avoids to loop
@@ -2064,19 +2062,33 @@ static void init_once_userfaultfd_ctx(void *mem)
seqcount_spinlock_init(&ctx->refile_seq, &ctx->fault_pending_wqh.lock);
}
-SYSCALL_DEFINE1(userfaultfd, int, flags)
+static inline bool userfaultfd_allowed(bool is_syscall, int flags)
+{
+ bool kernel_faults = !(flags & UFFD_USER_MODE_ONLY);
+ bool allow_unprivileged = sysctl_unprivileged_userfaultfd;
+
+ /* userfaultfd(2) access is controlled by sysctl + capability. */
+ if (is_syscall && kernel_faults) {
+ if (!allow_unprivileged && !capable(CAP_SYS_PTRACE))
+ return false;
+ }
+
+ /*
+ * For /dev/userfaultfd, access is to be controlled using e.g.
+ * permissions on the device node. We assume this is correctly
+ * configured by userspace, so we simply allow access here.
+ */
+
+ return true;
+}
+
+static int new_userfaultfd(bool is_syscall, int flags)
{
struct userfaultfd_ctx *ctx;
int fd;
- if (!sysctl_unprivileged_userfaultfd &&
- (flags & UFFD_USER_MODE_ONLY) == 0 &&
- !capable(CAP_SYS_PTRACE)) {
- printk_once(KERN_WARNING "uffd: Set unprivileged_userfaultfd "
- "sysctl knob to 1 if kernel faults must be handled "
- "without obtaining CAP_SYS_PTRACE capability\n");
+ if (!userfaultfd_allowed(is_syscall, flags))
return -EPERM;
- }
BUG_ON(!current->mm);
@@ -2095,6 +2107,11 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)
refcount_set(&ctx->refcount, 1);
ctx->flags = flags;
ctx->features = 0;
+ /*
+ * If UFFD_USER_MODE_ONLY is not set, then userfaultfd_allowed() above
+ * decided that kernel faults were allowed and should be handled.
+ */
+ ctx->handle_kernel_faults = !(flags & UFFD_USER_MODE_ONLY);
ctx->released = false;
atomic_set(&ctx->mmap_changing, 0);
ctx->mm = current->mm;
@@ -2110,8 +2127,42 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)
return fd;
}
+SYSCALL_DEFINE1(userfaultfd, int, flags)
+{
+ return new_userfaultfd(true, flags);
+}
+
+static int userfaultfd_dev_open(struct inode *inode, struct file *file)
+{
+ return 0;
+}
+
+static long userfaultfd_dev_ioctl(struct file *file, unsigned int cmd, unsigned long flags)
+{
+ if (cmd != USERFAULTFD_IOC_NEW)
+ return -EINVAL;
+
+ return new_userfaultfd(false, flags);
+}
+
+static const struct file_operations userfaultfd_dev_fops = {
+ .open = userfaultfd_dev_open,
+ .unlocked_ioctl = userfaultfd_dev_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
+ .owner = THIS_MODULE,
+ .llseek = noop_llseek,
+};
+
+static struct miscdevice userfaultfd_misc = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = "userfaultfd",
+ .fops = &userfaultfd_dev_fops
+};
+
static int __init userfaultfd_init(void)
{
+ WARN_ON(misc_register(&userfaultfd_misc));
+
userfaultfd_ctx_cachep = kmem_cache_create("userfaultfd_ctx_cache",
sizeof(struct userfaultfd_ctx),
0,
diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h
index ef739054cb1c..032a35b3bbd2 100644
--- a/include/uapi/linux/userfaultfd.h
+++ b/include/uapi/linux/userfaultfd.h
@@ -12,6 +12,10 @@
#include <linux/types.h>
+/* ioctls for /dev/userfaultfd */
+#define USERFAULTFD_IOC 0xAA
+#define USERFAULTFD_IOC_NEW _IOWR(USERFAULTFD_IOC, 0x00, int)
+
/*
* If the UFFDIO_API is upgraded someday, the UFFDIO_UNREGISTER and
* UFFDIO_WAKE ioctls should be defined as _IOW and not as _IOR. In
--
2.35.1.1178.g4f1659d476-goog
> I don't recall why we decided to add the check in runner.sh - let's keep them
> consistent with the rest of the scripts. If we get rid of the check, we can
> make the change then.
>
> thanks,
> -- Shuah
It seems reasonable to add the x bit for these tests to be consistent with
the rest.
I also received an email from a patchwork-bot+linux-kselftest(a)kernel.org
telling me my patch series was included in shuah/linux-kselftest.git, but
that does not seem to be the case.
Is this a bug?
Sorry about the previous non-plain-text email. I never replied to anyone
before and didn't know what I was doing.
> Hello:
>
>
> This series was applied to shuah/linux-kselftest.git (next)
>
> by Jakub Kicinski <kuba(a)kernel.org>:
>
>
> On Fri, 18 Feb 2022 00:10:15 +0000 you wrote:
> > These patches fixes trivial errors with building
> > and running DAMON selftests.
> >
> > Yuanchu Xie (2):
> > selftests/damon: add damon to selftests root Makefile
> > selftests/damon: make selftests executable
> >
> > [...]
>
>
> Here is the summary with links:
> - [1/2] selftests/damon: add damon to selftests root Makefile
> (no matching commit)
> - [2/2] selftests/damon: make selftests executable
> https://git.kernel.org/shuah/linux-kselftest/c/1335648f0b6f
>
> You are awesome, thank you!
> --
> Deet-doot-dot, I am a bot.
> https://korg.docs.kernel.org/patchwork/pwbot.html
This patchset proposes roadtest, a device-driver testing framework. Drivers
are tested under User Mode Linux (UML) and interact with mocked/modelled
hardware. The tests and hardware models are written in Python, the former
using Python's built-in unittest framework.
Drivers are tested via their userspace interfaces. The hardware models allow
tests to inject values into registers and assert that drivers control the
hardware in the right way and react as expected to stimuli.
Roadtest is meant to be used for relatively simple drivers, such as the ones
part of the IIO, regulator and RTC subsystems.
Questions and answers:
= Why do we need this?
There are a large amount of these kind of drivers in the kernel. Most of the
hardware is not available in current CI systems so most drivers can only, at
best, be build-tested there. Even basic soundness such as a driver
successfully probing and binding to the devices it tries to be support cannot
be tested. Drivers cannot be easily regression-tested to ensure that bugs
fixed once do not get reintroduced.
Many drivers support multiple related hardware variants, and far from all patch
submitters have access to all the variants which the driver that they are
patching supports, so there is no way for them to easily verify that they
haven't broken something basic on a variant which they do not own.
Furthermore, hardware can be used in many different configurations with drivers
supporting many different devicetree properties, so even just having access to
all the variants would be insufficient.
On top of that, some of the chips measure environmental conditions such as
temperature, so testing extreme cases may not be simple even if one has access
to the hardware.
All this makes development, modification, maintenance, and reviewing of these
drivers harder than it necessarily needs to be. Roadtest hopes to make some of
these things slightly easier by providing a framework to create hardware
models/mocks and to write testcases which exercise drivers using these models.
= Do you have some specific examples of the kind of code this could be used to
test?
Here is an example of a patch which can easily be regression-tested using
roadtest (in fact, this series includes such a regression test) but is much
harder to do so automatically with real hardware since it requires specific
environmental conditions:
iio: light: opt3001: Fixed timeout error when 0 lux
https://lore.kernel.org/lkml/20210920125351.6569-1-valek@2n.cz/
Here is another example. This driver has code which correctly parses a
documented devicetree property (amstaos,proximity-diodes) but which then fails
to actually communicate this setting to the hardware in any way. Such code can
be easily tested with roadtest since the framework integrates devicetree
support and provides functions to assert that drivers writes expected registers
with expected values:
drivers/iio/light/tsl2772.c tsl2772_read_prox_diodes()
(Both the above examples happen to be from the same subsystem but that should
in no way be taken to imply that such issues are unique to that subsystem or
that that subsystem has more of them.)
= How does this relate to kselftests?
Tests in kselftests also test kernel code using the userspace interfaces, but
that's about what's common between the frameworks. kselftests has other goals
and does not provide any kind of mechanism for hardware mocking.
= How does this relate to kunit?
Kunit is for unit testing of functions in kernel code, and is not meant for
testing kernel code via userspace interfaces. It could in theory be used to
test some of the simple drivers too, but that would require (1) a large amount
of mocking code in various kernel frameworks, and, more importantly, (2)
refactoring of the drivers to be tested.
This can be contrasted with roadtest which works with mostly unmodified drivers
and which mocks the hardware at the lowest level without having to change
kernel frameworks.
= How do I use it?
See Documentation/dev-tools/roadtest.rst added by the documentation patch for
more information about running and writing tests using this framework.
= What's included in the patchset?
The current framework allows developing tests for hardware which uses the I2C
bus. Hardware models can also control GPIOs and use them to trigger
interrupts.
This series includes tests for some IIO, regulator and RTC drivers. The
regulator and RTC tests depend on a few driver patches which are either in
review or in linux-next. These are noted in the commit messages.
The entire patch set, including the required dependencies, is also available in
a git tree:
https://github.com/vwax/linux/commits/roadtest/rfc-v1
Cc: linux-kernel(a)vger.kernel.org
Cc: devicetree(a)vger.kernel.org
Cc: linux-um(a)lists.infradead.org
Cc: shuah(a)kernel.org
Cc: brendanhiggins(a)google.com
Cc: linux-kselftest(a)vger.kernel.org
Cc: jic23(a)kernel.org
Cc: linux-iio(a)vger.kernel.org
Cc: lgirdwood(a)gmail.com
Cc: broonie(a)kernel.org
Cc: a.zummo(a)towertech.it
Cc: alexandre.belloni(a)bootlin.com
Cc: linux-rtc(a)vger.kernel.org
Cc: corbet(a)lwn.net
Cc: linux-doc(a)vger.kernel.org
Vincent Whitchurch (10):
roadtest: import libvhost-user from QEMU
roadtest: add C backend
roadtest: add framework
roadtest: add base config
roadtest: add build files
roadtest: add documentation
iio: light: opt3001: add roadtest
iio: light: vcnl4000: add roadtest
regulator: tps62864: add roadtest
rtc: pcf8563: add roadtest
Documentation/dev-tools/index.rst | 1 +
Documentation/dev-tools/roadtest.rst | 669 ++++
tools/testing/roadtest/.gitignore | 2 +
tools/testing/roadtest/Dockerfile | 25 +
tools/testing/roadtest/Makefile | 84 +
tools/testing/roadtest/init.sh | 19 +
tools/testing/roadtest/pyproject.toml | 10 +
tools/testing/roadtest/requirements.txt | 4 +
tools/testing/roadtest/roadtest/__init__.py | 2 +
.../roadtest/roadtest/backend/__init__.py | 0
.../roadtest/roadtest/backend/backend.py | 32 +
.../testing/roadtest/roadtest/backend/gpio.py | 111 +
.../testing/roadtest/roadtest/backend/i2c.py | 123 +
.../testing/roadtest/roadtest/backend/main.py | 13 +
.../testing/roadtest/roadtest/backend/mock.py | 20 +
.../roadtest/roadtest/backend/test_gpio.py | 98 +
.../roadtest/roadtest/backend/test_i2c.py | 84 +
.../testing/roadtest/roadtest/cmd/__init__.py | 0
tools/testing/roadtest/roadtest/cmd/main.py | 146 +
tools/testing/roadtest/roadtest/cmd/remote.py | 48 +
.../roadtest/roadtest/core/__init__.py | 0
.../testing/roadtest/roadtest/core/control.py | 52 +
.../roadtest/roadtest/core/devicetree.py | 155 +
.../roadtest/roadtest/core/hardware.py | 94 +
tools/testing/roadtest/roadtest/core/log.py | 42 +
.../testing/roadtest/roadtest/core/modules.py | 38 +
.../testing/roadtest/roadtest/core/opslog.py | 35 +
tools/testing/roadtest/roadtest/core/proxy.py | 48 +
tools/testing/roadtest/roadtest/core/suite.py | 286 ++
tools/testing/roadtest/roadtest/core/sysfs.py | 77 +
.../roadtest/roadtest/core/test_control.py | 35 +
.../roadtest/roadtest/core/test_devicetree.py | 31 +
.../roadtest/roadtest/core/test_hardware.py | 41 +
.../roadtest/roadtest/core/test_log.py | 54 +
.../roadtest/roadtest/core/test_opslog.py | 27 +
.../roadtest/roadtest/tests/__init__.py | 0
.../roadtest/roadtest/tests/base/config | 84 +
.../roadtest/roadtest/tests/iio/__init__.py | 0
.../roadtest/roadtest/tests/iio/config | 1 +
.../roadtest/roadtest/tests/iio/iio.py | 112 +
.../roadtest/tests/iio/light/__init__.py | 0
.../roadtest/roadtest/tests/iio/light/config | 2 +
.../roadtest/tests/iio/light/test_opt3001.py | 95 +
.../roadtest/tests/iio/light/test_vcnl4000.py | 132 +
.../roadtest/tests/iio/light/test_vcnl4010.py | 282 ++
.../roadtest/tests/iio/light/test_vcnl4040.py | 104 +
.../roadtest/tests/iio/light/test_vcnl4200.py | 96 +
.../roadtest/tests/regulator/__init__.py | 0
.../roadtest/roadtest/tests/regulator/config | 4 +
.../roadtest/tests/regulator/test_tps62864.py | 187 ++
.../roadtest/roadtest/tests/rtc/__init__.py | 0
.../roadtest/roadtest/tests/rtc/config | 1 +
.../roadtest/roadtest/tests/rtc/rtc.py | 73 +
.../roadtest/tests/rtc/test_pcf8563.py | 348 ++
tools/testing/roadtest/src/.gitignore | 1 +
tools/testing/roadtest/src/backend.c | 884 +++++
.../src/libvhost-user/include/atomic.h | 310 ++
.../src/libvhost-user/libvhost-user.c | 2885 +++++++++++++++++
.../src/libvhost-user/libvhost-user.h | 691 ++++
59 files changed, 8798 insertions(+)
create mode 100644 Documentation/dev-tools/roadtest.rst
create mode 100644 tools/testing/roadtest/.gitignore
create mode 100644 tools/testing/roadtest/Dockerfile
create mode 100644 tools/testing/roadtest/Makefile
create mode 100755 tools/testing/roadtest/init.sh
create mode 100644 tools/testing/roadtest/pyproject.toml
create mode 100644 tools/testing/roadtest/requirements.txt
create mode 100644 tools/testing/roadtest/roadtest/__init__.py
create mode 100644 tools/testing/roadtest/roadtest/backend/__init__.py
create mode 100644 tools/testing/roadtest/roadtest/backend/backend.py
create mode 100644 tools/testing/roadtest/roadtest/backend/gpio.py
create mode 100644 tools/testing/roadtest/roadtest/backend/i2c.py
create mode 100644 tools/testing/roadtest/roadtest/backend/main.py
create mode 100644 tools/testing/roadtest/roadtest/backend/mock.py
create mode 100644 tools/testing/roadtest/roadtest/backend/test_gpio.py
create mode 100644 tools/testing/roadtest/roadtest/backend/test_i2c.py
create mode 100644 tools/testing/roadtest/roadtest/cmd/__init__.py
create mode 100644 tools/testing/roadtest/roadtest/cmd/main.py
create mode 100644 tools/testing/roadtest/roadtest/cmd/remote.py
create mode 100644 tools/testing/roadtest/roadtest/core/__init__.py
create mode 100644 tools/testing/roadtest/roadtest/core/control.py
create mode 100644 tools/testing/roadtest/roadtest/core/devicetree.py
create mode 100644 tools/testing/roadtest/roadtest/core/hardware.py
create mode 100644 tools/testing/roadtest/roadtest/core/log.py
create mode 100644 tools/testing/roadtest/roadtest/core/modules.py
create mode 100644 tools/testing/roadtest/roadtest/core/opslog.py
create mode 100644 tools/testing/roadtest/roadtest/core/proxy.py
create mode 100644 tools/testing/roadtest/roadtest/core/suite.py
create mode 100644 tools/testing/roadtest/roadtest/core/sysfs.py
create mode 100644 tools/testing/roadtest/roadtest/core/test_control.py
create mode 100644 tools/testing/roadtest/roadtest/core/test_devicetree.py
create mode 100644 tools/testing/roadtest/roadtest/core/test_hardware.py
create mode 100644 tools/testing/roadtest/roadtest/core/test_log.py
create mode 100644 tools/testing/roadtest/roadtest/core/test_opslog.py
create mode 100644 tools/testing/roadtest/roadtest/tests/__init__.py
create mode 100644 tools/testing/roadtest/roadtest/tests/base/config
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/__init__.py
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/config
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/iio.py
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/__init__.py
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/config
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_opt3001.py
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_vcnl4000.py
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_vcnl4010.py
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_vcnl4040.py
create mode 100644 tools/testing/roadtest/roadtest/tests/iio/light/test_vcnl4200.py
create mode 100644 tools/testing/roadtest/roadtest/tests/regulator/__init__.py
create mode 100644 tools/testing/roadtest/roadtest/tests/regulator/config
create mode 100644 tools/testing/roadtest/roadtest/tests/regulator/test_tps62864.py
create mode 100644 tools/testing/roadtest/roadtest/tests/rtc/__init__.py
create mode 100644 tools/testing/roadtest/roadtest/tests/rtc/config
create mode 100644 tools/testing/roadtest/roadtest/tests/rtc/rtc.py
create mode 100644 tools/testing/roadtest/roadtest/tests/rtc/test_pcf8563.py
create mode 100644 tools/testing/roadtest/src/.gitignore
create mode 100644 tools/testing/roadtest/src/backend.c
create mode 100644 tools/testing/roadtest/src/libvhost-user/include/atomic.h
create mode 100644 tools/testing/roadtest/src/libvhost-user/libvhost-user.c
create mode 100644 tools/testing/roadtest/src/libvhost-user/libvhost-user.h
--
2.34.1
Hello,
I lead family investment vehicles who want to invest a proportion of their funds with a trust party .
Please if you are interested in discussing investment in your sector?
Please email, or simply write to me here. I value promptness and will make every attempt to respond within a short time.
Thank you.
Allen S.
Hello,
I am so sorry contacting you in this means especially when we have never
met before. I urgently seek your service to represent me in investing in
your region / country and you will be rewarded for your service without
affecting your present job with very little time invested in it.
My interest is in buying real estate, private schools or companies with
potentials for rapid growth in long terms.
So please confirm interest by responding back.
My dearest regards
Seyba Daniel
Hi Linus,
Please pull the following Kselftest update for Linux 5.18-rc3.
This Kselftest fixes update consists of a mqueue perf test memory leak
bug fix. mq_perf_tests fail to call CPU_FREE to free memory allocated
by CPU_SET.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 79ee8aa31d518c1fd5f3b1b1ac39dd1fb4dc7039:
selftests/harness: Pass variant to teardown (2022-04-04 13:37:48 -0600)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-fixes-5.18-rc3
for you to fetch changes up to ce64763c63854b4079f2e036638aa881a1fb3fbc:
testing/selftests/mqueue: Fix mq_perf_tests to free the allocated cpu set (2022-04-12 13:54:49 -0600)
----------------------------------------------------------------
linux-kselftest-fixes-5.18-rc3
This Kselftest fixes update consists of a mqueue perf test memory leak
bug fix. mq_perf_tests fail to call CPU_FREE to free memory allocated
by CPU_SET.
----------------------------------------------------------------
Athira Rajeev (1):
testing/selftests/mqueue: Fix mq_perf_tests to free the allocated cpu set
tools/testing/selftests/mqueue/mq_perf_tests.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
----------------------------------------------------------------