lsns: continue the executing even if opening a /proc/$pid fails #2952
Conversation
In the original code, lsns printed nothing if it failed in opening the
last dntry in /proc/[0-9]* though lsns should work partially.
The original behavior caused the combination of the following two
test cases failed:
$ tests/ts/lsns/filter & tests/ts/lsns/ioctl_ns &
[1] 19178
[2] 19179
$ lsns: ownership and hierarchy ... \
lsns: -Q, --filter option ... FAILED
FAILED
[1]- Done tests/ts/lsns/filter
[2]+ Done tests/ts/lsns/ioctl_ns
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
cd382a3 to
c5eccab
Compare
|
Reporting ENOSYS is a bit strange for me. The environments must have ioctl. |
d98cb9b to
84de673
Compare
…OSYS
With the original code, "lsns/filedesc" test case failed on
"build (qemu-user, s390x)" and "build (qemu-user, riscv64)".
On the platforms, lsns_ioctl(fd, NS_GET_{PARENT,USERNS}) failed
with ENOSYS. The error stoped the iteration for gathering
information from /proc/[0-9]+. As a result, lsns printed
nothing. We don't expect this behavior.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Qemu userspace emulation reports ENOSYS if it doesn't support a given ioctl command. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
f775762 to
60363f4
Compare
60363f4 to
fe97fd9
Compare
Currently, Qemu userspace emulation doesn't support the ioctl cmd. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
fe97fd9 to
dbfd5ef
Compare
|
The top half of these commits are applicable to the stable branch. |
It will be better if you select the patches (to a stable PR) rather than rely on my guess ;-) |
|
@karelzak I misunderstood what I did. I assumed the top half of these commits were applicable to the stable branch. However, they were not. They are for new code added to the master branch after you forked the stable branch. f2a8b20 is one of the candidates for backporting. It may improve lsns running on Qemu userspace emulation. Do you think we should backport this to the stable branch? We cannot cherry-pick this commit easily because the code bases were changed between the master and stable branches. 0a7a8fb is another candidates. |
In the original code, lsns printed nothing if it failed in opening the
last dntry in /proc/[0-9]* though lsns should work partially.
The original behavior caused the combination of the following two
test cases failed: