after calling fork() in the test_prctl_fork_exec() function,
the global variable ksm_full_scans_fd is initialized to 0
in the child process upon entering the main function
of ./ksm_functional_tests.
In the function call chain test_child_ksm() ->
__mmap_and_merge_range -> ksm_merge-> ksm_get_full_sc
On Thu, Jun 13, 2024 at 02:13:33PM -0400, Aaron Conole wrote:
> The pmtu testing will require that the OVS module is installed,
> so do that.
>
> Signed-off-by: Aaron Conole
Reviewed-by: Simon Horman
Tested-by: Simon Horman
On Thu, Jun 13, 2024 at 02:13:29PM -0400, Aaron Conole wrote:
> These will be used in upcoming commits to set specific attributes for
> interacting with tunnels. Since set() will use the key parsing routine, we
> also make sure to prepend it with an open paren, for the action parsing to
> properly
On Thu, Jun 13, 2024 at 02:13:28PM -0400, Aaron Conole wrote:
> Until recently, the ovs-dpctl utility was used with a limited actions set
> and didn't need to have support for multiple similar actions. However,
> when adding support for tunnels, it will be important to support multiple
> set() act
On Thu, Jun 13, 2024 at 02:13:31PM -0400, Aaron Conole wrote:
> The current iteration of IPv6 support requires explicit fields to be set
> in addition to not properly support the actual IPv6 addresses properly.
> With this change, make it so that the ipv6() bare option is usable to
> create wildcar
On Thu, Jun 13, 2024 at 02:13:30PM -0400, Aaron Conole wrote:
> This will be used when setting details about the tunnel to use as
> transport. There is a difference between the ODP format between tunnel():
> the 'key' flag is not actually a flag field, so we don't support it in the
> same way that
On Thu, Jun 13, 2024 at 02:13:27PM -0400, Aaron Conole wrote:
> The OVS module can operate in conjunction with various types of
> tunnel ports. These are created as either explicit tunnel vport
> types, OR by creating a tunnel interface which acts as an anchor
> for the lightweight tunnel support.
Add a simple sanity check to HD-audio HDMI Channel Map controls.
Although the value might not be accepted for the actual connection, we
can filter out some bogus values beforehand, and that should be enough
for making kselftest happier.
Reviewed-by: Jaroslav Kysela
Signed-off-by: Takashi Iwai
--
Although we have already a mechanism for sanity checks of input values
for control writes, it's not applied unless the kconfig
CONFIG_SND_CTL_INPUT_VALIDATION is set due to the performance reason.
Nevertheless, it still makes sense to apply the same check for user
elements despite of its cost, as t
Hi,
this is a v3 patch set as a follow up of the thread about the errors
reported by kselftest mixer-test. It changes HD-audio and vmaster
control behavior to return -EINVAL for invalid input values.
There is a change in kselftest itself to skip the verification after
write tests for volatile co
The values returned from Playback Channel Map and Capture Channel Map
controls may vary dynamically depending on the corresponding PCM
stream. Mark those as volatile to indicate the values are unstable
and not suitable for testing.
Note that we may change the driver to return -EINVAL, but this wo
From: Mark Brown
When validating writes to controls we check that whatever value we wrote
actually appears in the control. For volatile controls we cannot assume
that this will be the case, the value may be changed at any time
including between our write and read. Handle this by moving the chec
So far the HD-audio driver has been tolerant about the input values
and accepts any values by correcting the amp volume and switch values
internally. But now our own selftest starts complaining about this
behavior, so let's be picky and change the behavior to return -EINVAL
for invalid input value
So far the vmaster code has been tolerant about the input values and
accepts any values by correcting internally. But now our own selftest
starts complaining about this behavior, so let's be picky and change
the behavior to return -EINVAL for invalid input values instead.
Reported-by: Paul Menzel
On Fri, 14 Jun 2024 18:40:37 +0200,
Mark Brown wrote:
>
> When validating writes to controls we check that whatever value we wrote
> actually appears in the control. For volatile controls we cannot assume
> that this will be the case, the value may be changed at any time
> including between our w
15 matches
Mail list logo
