From: Christian Kellner
The Thunderbolt standard went through several major iterations, here
called generation. USB4, which will be based on Thunderbolt, will be
generation 4. Let userspace know the generation of the controller in
the devices in order to distinguish between Thunderbolt and USB4
From: Christian Kellner
The fdinfo file for a process file descriptor already contains the
pid of the process in the callers namespaces. Additionally, if pid
namespaces are configured, show the process ids of the process in
all nested namespaces in the same format as in the procfs status
file
From: Christian Kellner
The fdinfo file for a process file descriptor already contains the
pid of the process in the callers namespaces. Additionally, if pid
namespaces are configured, show the process ids of the process in
all nested namespaces in the same format as in the procfs status
file
From: Christian Kellner
Add tests that check that if pid namespaces are configured the fdinfo
file of a pidfd contains an NSpid: entry containing the process id
in the current and additionally all nested namespaces.
Signed-off-by: Christian Kellner
---
tools/testing/selftests/pidfd/Makefile
On Fri, 2019-10-04 at 18:16 +0300, Mika Westerberg wrote:
> > Is there any harm of also having the 'generation' exposed
> > as well? I like the simplicity of the mapping from that value to
> > Thunderbolt/USB4 standard version (e.g. I would show that in
> > 'boltctl
> > list'); 'hw_version' will ne
From: Christian Kellner
The fdinfo file for a process file descriptor already contains the
pid of the process in the callers namespaces. Additionally, if pid
namespaces are configured, show the process ids of the process in
all nested namespaces in the same format as in the procfs status
file
From: Christian Kellner
Add tests that check that if pid namespaces are configured the fdinfo
file of a pidfd contains an NSpid: entry containing the process id
in the current and additionally all nested namespaces.
Signed-off-by: Christian Kellner
---
tools/testing/selftests/pidfd/Makefile
From: Christian Kellner
The pidfd_{open,poll}_test.c files both include `linux/wait.h` and
later `sys/wait.h`. The former has `#define P_ALL 0`, but in the
latter P_ALL is part of idtype_t enum, where it gets substituted
due to the aforementioned define to be `0`, which then results in
`typedef
On Sat, 2019-10-12 at 12:21 +0200, Christian Brauner wrote:
> I think this might be more what we want.
Yep, indeed.
> I tried to think of cases where the first entry of Pid is not
> identical
> to the first entry of NSpid but I came up with none. Maybe you do,
> Jann?
Yeah, I don't think that can
On Mon, 2019-10-14 at 17:10 +0200, Jann Horn wrote:
> On Mon, Oct 14, 2019 at 12:32 PM Christian Brauner wrote:
> > On Mon, Oct 14, 2019 at 11:43:01AM +0200, Christian Kellner wrote:
> > You could probably do:
> >
> > #ifdef CONFIG_PID_NS
> > seq_put_decimal_ull
From: Christian Kellner
Add a test that checks that if pid namespaces are configured the fdinfo
file of a pidfd contains an NSpid: entry containing the process id in
the current and additionally all nested namespaces. In the case that
a pidfd is from a pid namespace not in the same namespace
From: Christian Kellner
Currently, the fdinfo file contains the Pid field which shows the
pid a given pidfd refers to in the pid namespace of the procfs
instance. If pid namespaces are configured, also show an NSpid field
for easy retrieval of the pid in all descendant pid namespaces. If
the pid
From: Christian Kellner
Both linux/wait.h and sys/wait.h contain values for the first argument
of 'waitid' (P_ALL, P_PID, ...). While the former uses defines the
latter uses an enum. When linux/wait.h is included before sys/wait.h
this will lead to an error, because P_ALL, P_PID
On Tue, 2019-10-15 at 16:13 +0200, Christian Brauner wrote:
> Test that the fdinfo field of a pidfd referring to a dead process
> correctly shows Pid: -1 and NSpid: -1.
>
> Cc: Christian Kellner
> Signed-off-by: Christian Brauner
Looks good to me.
Reviewed-by: Christian Kellner
Hi!
> This is fourth version of the patch series adding support for Thunderbolt
> security levels and NVM firmware upgrade.
While prototyping the user-space bits for GNOME, I stumbled upon an
oops on the Lenovo T470s (see below) when attaching a Dell TB16
thunderbolt 3 dock. As a result /sys/bus/
Hi,
Did you by chance boot with the dock "plugged in"? Or was this the
result of
plugging in after boot?
Dock was plugged in after boot. I included another dmesg output,
where I marked the time point that I plugged the device in.
There is a known issue that Mika is tracking regarding some p
disabled;
if (port->disabled)
Tested-by: Christian Kellner
sary extra entries in
DROM\n");
+ return 0;
+ }
+
port = &sw->ports[header->index];
port->disabled = header->port_disabled;
if (port->disabled)
Fixes the bug, everything works as expected (tested on boot,
plugging in, key ba
18 matches
Mail list logo
