* ❌ FAIL: Test report for kernel 5.7.0-rc5-51f14e2.cki (arm-next)
@ 2020-05-13 3:01 CKI Project
2020-05-13 6:12 ` Will Deacon
0 siblings, 1 reply; 9+ messages in thread
From: CKI Project @ 2020-05-13 3:01 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel; +Cc: Memory Management, Jan Stancek
Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Commit: 51f14e2c02e8 - Merge branch 'for-next/core' into for-kernelci
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Merge: OK
Compile: OK
Tests: FAILED
All kernel binaries, config files, and logs are available for download here:
https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=datawarehouse/2020/05/12/564910
One or more kernel tests failed:
aarch64:
❌ LTP
We hope that these logs can help you find the problem quickly. For the full
detail on our testing procedures, please scroll to the bottom of this message.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Compile testing
---------------
We compiled the kernel for 1 architecture:
aarch64:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
Hardware testing
----------------
We booted each kernel and ran the following tests:
aarch64:
Host 1:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ selinux-policy: serge-testsuite
✅ storage: software RAID testing
🚧 ✅ IPMI driver test
🚧 ✅ IPMItool loop stress test
🚧 ✅ Storage blktests
Host 2:
✅ Boot test
✅ Podman system integration test - as root
✅ Podman system integration test - as user
❌ LTP
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Networking bridge: sanity
✅ Ethernet drivers sanity
✅ Networking socket: fuzz
✅ Networking: igmp conformance test
✅ Networking route: pmtu
✅ Networking route_func - local
✅ Networking route_func - forward
✅ Networking TCP: keepalive test
✅ Networking UDP: socket
✅ Networking tunnel: geneve basic test
✅ Networking tunnel: gre basic
✅ L2TP basic test
✅ Networking tunnel: vxlan basic
✅ Networking ipsec: basic netns - transport
✅ Networking ipsec: basic netns - tunnel
✅ httpd: mod_ssl smoke sanity
✅ tuned: tune-processes-through-perf
✅ ALSA PCM loopback test
✅ ALSA Control (mixer) Userspace Element test
✅ storage: SCSI VPD
🚧 ✅ CIFS Connectathon
🚧 ✅ POSIX pjd-fstest suites
🚧 ✅ jvm - DaCapo Benchmark Suite
🚧 ✅ jvm - jcstress tests
🚧 ✅ Memory function: kaslr
🚧 ✅ audit: audit testsuite test
🚧 ✅ iotop: sanity
🚧 ✅ trace: ftrace/tracer
Test sources: https://github.com/CKI-project/tests-beaker
💚 Pull requests are welcome for new tests or improvements to existing tests!
Aborted tests
-------------
Tests that didn't complete running successfully are marked with ⚡⚡⚡.
If this was caused by an infrastructure issue, we try to mark that
explicitly in the report.
Waived tests
------------
If the test run included waived tests, they are marked with 🚧. Such tests are
executed but their results are not taken into account. Tests are waived when
their results are not reliable enough, e.g. when they're just introduced or are
being fixed.
Testing timeout
---------------
We aim to provide a report within reasonable timeframe. Tests that haven't
finished running yet are marked with ⏱.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ❌ FAIL: Test report for kernel 5.7.0-rc5-51f14e2.cki (arm-next)
2020-05-13 3:01 ❌ FAIL: Test report for kernel 5.7.0-rc5-51f14e2.cki (arm-next) CKI Project
@ 2020-05-13 6:12 ` Will Deacon
2020-05-13 10:19 ` Veronika Kabatova
0 siblings, 1 reply; 9+ messages in thread
From: Will Deacon @ 2020-05-13 6:12 UTC (permalink / raw)
To: CKI Project
Cc: catalin.marinas, Memory Management, Jan Stancek, linux-arm-kernel
Hi CKI folks,
On Wed, May 13, 2020 at 03:01:36AM -0000, CKI Project wrote:
> We ran automated tests on a recent commit from this kernel tree:
>
> Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> Commit: 51f14e2c02e8 - Merge branch 'for-next/core' into for-kernelci
>
> The results of these automated tests are provided below.
>
> Overall result: FAILED (see details below)
> Merge: OK
> Compile: OK
> Tests: FAILED
>
> All kernel binaries, config files, and logs are available for download here:
>
> https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=datawarehouse/2020/05/12/564910
>
> One or more kernel tests failed:
>
> aarch64:
> ❌ LTP
[...]
> Host 2:
> ✅ Boot test
> ✅ Podman system integration test - as root
> ✅ Podman system integration test - as user
> ❌ LTP
I'm struggling a bit with this one, please can you confirm that it's not
an issue on your end? The failures are related to /dev/cpuset:
mem.c:760: BROK: mount /dev/cpuset: EBUSY (16)
...
safe_macros.c:172: BROK: mem.c:750: mkdir(/dev/cpuset,0777) failed: EEXIST (17)
https://cki-artifacts.s3.us-east-2.amazonaws.com/datawarehouse/2020/05/12/564910/LTP/aarch64_2_ltp_mm.fail.log
But we haven't been anywhere near that in the arm64 tree afaik.
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ❌ FAIL: Test report for kernel 5.7.0-rc5-51f14e2.cki (arm-next)
2020-05-13 6:12 ` Will Deacon
@ 2020-05-13 10:19 ` Veronika Kabatova
2020-05-13 15:40 ` [LTP] " Jan Stancek
0 siblings, 1 reply; 9+ messages in thread
From: Veronika Kabatova @ 2020-05-13 10:19 UTC (permalink / raw)
To: Will Deacon, Jan Stancek, Memory Management
Cc: catalin marinas, linux-arm-kernel, CKI Project
----- Original Message -----
> From: "Will Deacon" <will@kernel.org>
> To: "CKI Project" <cki-project@redhat.com>
> Cc: "catalin marinas" <catalin.marinas@arm.com>, "Memory Management" <mm-qe@redhat.com>, "Jan Stancek"
> <jstancek@redhat.com>, linux-arm-kernel@lists.infradead.org
> Sent: Wednesday, May 13, 2020 8:12:27 AM
> Subject: Re: ❌ FAIL: Test report for kernel 5.7.0-rc5-51f14e2.cki (arm-next)
>
> Hi CKI folks,
>
> On Wed, May 13, 2020 at 03:01:36AM -0000, CKI Project wrote:
> > We ran automated tests on a recent commit from this kernel tree:
> >
> > Kernel repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> > Commit: 51f14e2c02e8 - Merge branch 'for-next/core' into
> > for-kernelci
> >
> > The results of these automated tests are provided below.
> >
> > Overall result: FAILED (see details below)
> > Merge: OK
> > Compile: OK
> > Tests: FAILED
> >
> > All kernel binaries, config files, and logs are available for download
> > here:
> >
> > https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=datawarehouse/2020/05/12/564910
> >
> > One or more kernel tests failed:
> >
> > aarch64:
> > ❌ LTP
>
> [...]
>
> > Host 2:
> > ✅ Boot test
> > ✅ Podman system integration test - as root
> > ✅ Podman system integration test - as user
> > ❌ LTP
>
> I'm struggling a bit with this one, please can you confirm that it's not
> an issue on your end? The failures are related to /dev/cpuset:
>
> mem.c:760: BROK: mount /dev/cpuset: EBUSY (16)
> ...
> safe_macros.c:172: BROK: mem.c:750: mkdir(/dev/cpuset,0777) failed: EEXIST
> (17)
>
> https://cki-artifacts.s3.us-east-2.amazonaws.com/datawarehouse/2020/05/12/564910/LTP/aarch64_2_ltp_mm.fail.log
>
> But we haven't been anywhere near that in the arm64 tree afaik.
>
Hi,
I suspect this is an LTP bug:
https://github.com/linux-test-project/ltp/issues/611
The original issue wasn't manifesting with ksm02 test that failed
though.
@Jan or @Li, can you confirm whether this is the case and we should
disable these tests as well? We've found some hidden kernel bugs with
LTP and I can't see any recent similar upstream failures so I'm hesitant
to mark it as a test bug right away.
Thanks,
Veronika
> Cheers,
>
> Will
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ❌ FAIL: Test report for kernel 5.7.0-rc5-51f14e2.cki (arm-next)
2020-05-13 10:19 ` Veronika Kabatova
2020-05-13 15:40 ` [LTP] " Jan Stancek
@ 2020-05-13 15:40 ` Jan Stancek
0 siblings, 0 replies; 9+ messages in thread
From: Jan Stancek @ 2020-05-13 15:40 UTC (permalink / raw)
To: Veronika Kabatova, cgroups
Cc: catalin marinas, Memory Management, linux-arm-kernel,
CKI Project, Will Deacon, LTP List
----- Original Message -----
> > Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> > Commit: 51f14e2c02e8 - Merge branch 'for-next/core' into for-kernelci
> >
> > I'm struggling a bit with this one, please can you confirm that it's not
> > an issue on your end? The failures are related to /dev/cpuset:
> >
> > mem.c:760: BROK: mount /dev/cpuset: EBUSY (16)
> > ...
> > safe_macros.c:172: BROK: mem.c:750: mkdir(/dev/cpuset,0777) failed:
> > EEXIST
> > (17)
> >
> > https://cki-artifacts.s3.us-east-2.amazonaws.com/datawarehouse/2020/05/12/564910/LTP/aarch64_2_ltp_mm.fail.log
> >
> > But we haven't been anywhere near that in the arm64 tree afaik.
> >
>
> Hi,
>
> I suspect this is an LTP bug:
>
> https://github.com/linux-test-project/ltp/issues/611
[CC cgroups & LTP]
In LTP issue above it was clear that memory controller is in use.
Here it looks like some lingering reference to cpuset controller
that can't be seen in sysfs.
It's triggered by podman tests actually:
1. run podman tests
2. mount -t cgroup -ocpuset cpuset /mnt/cpuset/ -> EBUSY
# mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel)
# grep cpuset -r /sys/fs/cgroup/
/sys/fs/cgroup/cgroup.controllers:cpuset cpu io memory pids
And yet, v1 cgroup fails to mount:
# mount -t cgroup -ocpuset cpuset /mnt/cpuset/
mount: /mnt/cpuset: cpuset already mounted or mount point busy.
Fail state persists also after I disable all controllers and move
all processes to root:
# cat /sys/fs/cgroup/cgroup.subtree_control
# ll /sys/fs/cgroup/
total 0
-r--r--r--. 1 root root 0 May 13 10:35 cgroup.controllers
-rw-r--r--. 1 root root 0 May 13 10:44 cgroup.max.depth
-rw-r--r--. 1 root root 0 May 13 10:44 cgroup.max.descendants
-rw-r--r--. 1 root root 0 May 13 10:58 cgroup.procs
-r--r--r--. 1 root root 0 May 13 10:44 cgroup.stat
-rw-r--r--. 1 root root 0 May 13 11:00 cgroup.subtree_control
-rw-r--r--. 1 root root 0 May 13 10:44 cgroup.threads
-rw-r--r--. 1 root root 0 May 13 10:44 cpu.pressure
-r--r--r--. 1 root root 0 May 13 10:44 cpuset.cpus.effective
-r--r--r--. 1 root root 0 May 13 10:44 cpuset.mems.effective
-rw-r--r--. 1 root root 0 May 13 10:44 io.cost.model
-rw-r--r--. 1 root root 0 May 13 10:44 io.cost.qos
-rw-r--r--. 1 root root 0 May 13 10:44 io.pressure
-rw-r--r--. 1 root root 0 May 13 10:44 memory.pressure
# mount -t cgroup -ocpuset cpuset /mnt/cpuset/
mount: /mnt/cpuset: cpuset already mounted or mount point busy
If I reboot and don't run any podman tests, v1 cgroup mounts fine:
# cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory pids
# mount -t cgroup -ocpuset cpuset /mnt/cpuset/
# cat /sys/fs/cgroup/cgroup.controllers
cpu io memory pids
# umount /mnt/cpuset/
# cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory pids
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] ❌ FAIL: Test report for kernel 5.7.0-rc5-51f14e2.cki (arm-next)
@ 2020-05-13 15:40 ` Jan Stancek
0 siblings, 0 replies; 9+ messages in thread
From: Jan Stancek @ 2020-05-13 15:40 UTC (permalink / raw)
To: ltp
----- Original Message -----
> > Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> > Commit: 51f14e2c02e8 - Merge branch 'for-next/core' into for-kernelci
> >
> > I'm struggling a bit with this one, please can you confirm that it's not
> > an issue on your end? The failures are related to /dev/cpuset:
> >
> > mem.c:760: BROK: mount /dev/cpuset: EBUSY (16)
> > ...
> > safe_macros.c:172: BROK: mem.c:750: mkdir(/dev/cpuset,0777) failed:
> > EEXIST
> > (17)
> >
> > https://cki-artifacts.s3.us-east-2.amazonaws.com/datawarehouse/2020/05/12/564910/LTP/aarch64_2_ltp_mm.fail.log
> >
> > But we haven't been anywhere near that in the arm64 tree afaik.
> >
>
> Hi,
>
> I suspect this is an LTP bug:
>
> https://github.com/linux-test-project/ltp/issues/611
[CC cgroups & LTP]
In LTP issue above it was clear that memory controller is in use.
Here it looks like some lingering reference to cpuset controller
that can't be seen in sysfs.
It's triggered by podman tests actually:
1. run podman tests
2. mount -t cgroup -ocpuset cpuset /mnt/cpuset/ -> EBUSY
# mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel)
# grep cpuset -r /sys/fs/cgroup/
/sys/fs/cgroup/cgroup.controllers:cpuset cpu io memory pids
And yet, v1 cgroup fails to mount:
# mount -t cgroup -ocpuset cpuset /mnt/cpuset/
mount: /mnt/cpuset: cpuset already mounted or mount point busy.
Fail state persists also after I disable all controllers and move
all processes to root:
# cat /sys/fs/cgroup/cgroup.subtree_control
# ll /sys/fs/cgroup/
total 0
-r--r--r--. 1 root root 0 May 13 10:35 cgroup.controllers
-rw-r--r--. 1 root root 0 May 13 10:44 cgroup.max.depth
-rw-r--r--. 1 root root 0 May 13 10:44 cgroup.max.descendants
-rw-r--r--. 1 root root 0 May 13 10:58 cgroup.procs
-r--r--r--. 1 root root 0 May 13 10:44 cgroup.stat
-rw-r--r--. 1 root root 0 May 13 11:00 cgroup.subtree_control
-rw-r--r--. 1 root root 0 May 13 10:44 cgroup.threads
-rw-r--r--. 1 root root 0 May 13 10:44 cpu.pressure
-r--r--r--. 1 root root 0 May 13 10:44 cpuset.cpus.effective
-r--r--r--. 1 root root 0 May 13 10:44 cpuset.mems.effective
-rw-r--r--. 1 root root 0 May 13 10:44 io.cost.model
-rw-r--r--. 1 root root 0 May 13 10:44 io.cost.qos
-rw-r--r--. 1 root root 0 May 13 10:44 io.pressure
-rw-r--r--. 1 root root 0 May 13 10:44 memory.pressure
# mount -t cgroup -ocpuset cpuset /mnt/cpuset/
mount: /mnt/cpuset: cpuset already mounted or mount point busy
If I reboot and don't run any podman tests, v1 cgroup mounts fine:
# cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory pids
# mount -t cgroup -ocpuset cpuset /mnt/cpuset/
# cat /sys/fs/cgroup/cgroup.controllers
cpu io memory pids
# umount /mnt/cpuset/
# cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory pids
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ❌ FAIL: Test report for kernel 5.7.0-rc5-51f14e2.cki (arm-next)
@ 2020-05-13 15:40 ` Jan Stancek
0 siblings, 0 replies; 9+ messages in thread
From: Jan Stancek @ 2020-05-13 15:40 UTC (permalink / raw)
To: Veronika Kabatova, cgroups-u79uwXL29TY76Z2rM5mHXA
Cc: catalin marinas, Memory Management,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, CKI Project,
Will Deacon, LTP List
----- Original Message -----
> > Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> > Commit: 51f14e2c02e8 - Merge branch 'for-next/core' into for-kernelci
> >
> > I'm struggling a bit with this one, please can you confirm that it's not
> > an issue on your end? The failures are related to /dev/cpuset:
> >
> > mem.c:760: BROK: mount /dev/cpuset: EBUSY (16)
> > ...
> > safe_macros.c:172: BROK: mem.c:750: mkdir(/dev/cpuset,0777) failed:
> > EEXIST
> > (17)
> >
> > https://cki-artifacts.s3.us-east-2.amazonaws.com/datawarehouse/2020/05/12/564910/LTP/aarch64_2_ltp_mm.fail.log
> >
> > But we haven't been anywhere near that in the arm64 tree afaik.
> >
>
> Hi,
>
> I suspect this is an LTP bug:
>
> https://github.com/linux-test-project/ltp/issues/611
[CC cgroups & LTP]
In LTP issue above it was clear that memory controller is in use.
Here it looks like some lingering reference to cpuset controller
that can't be seen in sysfs.
It's triggered by podman tests actually:
1. run podman tests
2. mount -t cgroup -ocpuset cpuset /mnt/cpuset/ -> EBUSY
# mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel)
# grep cpuset -r /sys/fs/cgroup/
/sys/fs/cgroup/cgroup.controllers:cpuset cpu io memory pids
And yet, v1 cgroup fails to mount:
# mount -t cgroup -ocpuset cpuset /mnt/cpuset/
mount: /mnt/cpuset: cpuset already mounted or mount point busy.
Fail state persists also after I disable all controllers and move
all processes to root:
# cat /sys/fs/cgroup/cgroup.subtree_control
# ll /sys/fs/cgroup/
total 0
-r--r--r--. 1 root root 0 May 13 10:35 cgroup.controllers
-rw-r--r--. 1 root root 0 May 13 10:44 cgroup.max.depth
-rw-r--r--. 1 root root 0 May 13 10:44 cgroup.max.descendants
-rw-r--r--. 1 root root 0 May 13 10:58 cgroup.procs
-r--r--r--. 1 root root 0 May 13 10:44 cgroup.stat
-rw-r--r--. 1 root root 0 May 13 11:00 cgroup.subtree_control
-rw-r--r--. 1 root root 0 May 13 10:44 cgroup.threads
-rw-r--r--. 1 root root 0 May 13 10:44 cpu.pressure
-r--r--r--. 1 root root 0 May 13 10:44 cpuset.cpus.effective
-r--r--r--. 1 root root 0 May 13 10:44 cpuset.mems.effective
-rw-r--r--. 1 root root 0 May 13 10:44 io.cost.model
-rw-r--r--. 1 root root 0 May 13 10:44 io.cost.qos
-rw-r--r--. 1 root root 0 May 13 10:44 io.pressure
-rw-r--r--. 1 root root 0 May 13 10:44 memory.pressure
# mount -t cgroup -ocpuset cpuset /mnt/cpuset/
mount: /mnt/cpuset: cpuset already mounted or mount point busy
If I reboot and don't run any podman tests, v1 cgroup mounts fine:
# cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory pids
# mount -t cgroup -ocpuset cpuset /mnt/cpuset/
# cat /sys/fs/cgroup/cgroup.controllers
cpu io memory pids
# umount /mnt/cpuset/
# cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory pids
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ❌ FAIL: Test report for kernel?5.7.0-rc5-51f14e2.cki (arm-next)
2020-05-13 15:40 ` [LTP] " Jan Stancek
(?)
@ 2020-05-13 15:51 ` Tejun Heo
-1 siblings, 0 replies; 9+ messages in thread
From: Tejun Heo @ 2020-05-13 15:51 UTC (permalink / raw)
To: Jan Stancek
Cc: Veronika Kabatova, catalin marinas, Memory Management, LTP List,
CKI Project, cgroups, Will Deacon, linux-arm-kernel
On Wed, May 13, 2020 at 11:40:15AM -0400, Jan Stancek wrote:
> In LTP issue above it was clear that memory controller is in use.
> Here it looks like some lingering reference to cpuset controller
> that can't be seen in sysfs.
>
> It's triggered by podman tests actually:
> 1. run podman tests
> 2. mount -t cgroup -ocpuset cpuset /mnt/cpuset/ -> EBUSY
>
> # mount | grep cgroup
> cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel)
>
> # grep cpuset -r /sys/fs/cgroup/
> /sys/fs/cgroup/cgroup.controllers:cpuset cpu io memory pids
>
> And yet, v1 cgroup fails to mount:
>
> # mount -t cgroup -ocpuset cpuset /mnt/cpuset/
> mount: /mnt/cpuset: cpuset already mounted or mount point busy.
While if a regression it may point to a newly introduced behavior, in
general, dynamically reassigning cgroup controllers to a different version
hierarchy after active use is not something fully supported. From cgroup2
documentation:
A controller can be moved across hierarchies only after the controller is
no longer referenced in its current hierarchy. Because per-cgroup
controller states are destroyed asynchronously and controllers may have
lingering references, a controller may not show up immediately on the v2
hierarchy after the final umount of the previous hierarchy. Similarly, a
controller should be fully disabled to be moved out of the unified
hierarchy and it may take some time for the disabled controller to become
available for other hierarchies; furthermore, due to inter-controller
dependencies, other controllers may need to be disabled too.
While useful for development and manual configurations, moving controllers
dynamically between the v2 and other hierarchies is strongly discouraged
for production use. It is recommended to decide the hierarchies and
controller associations before starting using the controllers after system
boot.
Thanks.
--
tejun
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] ❌ FAIL: Test report for kernel?5.7.0-rc5-51f14e2.cki (arm-next)
@ 2020-05-13 15:51 ` Tejun Heo
0 siblings, 0 replies; 9+ messages in thread
From: Tejun Heo @ 2020-05-13 15:51 UTC (permalink / raw)
To: ltp
On Wed, May 13, 2020 at 11:40:15AM -0400, Jan Stancek wrote:
> In LTP issue above it was clear that memory controller is in use.
> Here it looks like some lingering reference to cpuset controller
> that can't be seen in sysfs.
>
> It's triggered by podman tests actually:
> 1. run podman tests
> 2. mount -t cgroup -ocpuset cpuset /mnt/cpuset/ -> EBUSY
>
> # mount | grep cgroup
> cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel)
>
> # grep cpuset -r /sys/fs/cgroup/
> /sys/fs/cgroup/cgroup.controllers:cpuset cpu io memory pids
>
> And yet, v1 cgroup fails to mount:
>
> # mount -t cgroup -ocpuset cpuset /mnt/cpuset/
> mount: /mnt/cpuset: cpuset already mounted or mount point busy.
While if a regression it may point to a newly introduced behavior, in
general, dynamically reassigning cgroup controllers to a different version
hierarchy after active use is not something fully supported. From cgroup2
documentation:
A controller can be moved across hierarchies only after the controller is
no longer referenced in its current hierarchy. Because per-cgroup
controller states are destroyed asynchronously and controllers may have
lingering references, a controller may not show up immediately on the v2
hierarchy after the final umount of the previous hierarchy. Similarly, a
controller should be fully disabled to be moved out of the unified
hierarchy and it may take some time for the disabled controller to become
available for other hierarchies; furthermore, due to inter-controller
dependencies, other controllers may need to be disabled too.
While useful for development and manual configurations, moving controllers
dynamically between the v2 and other hierarchies is strongly discouraged
for production use. It is recommended to decide the hierarchies and
controller associations before starting using the controllers after system
boot.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ❌ FAIL: Test report for kernel?5.7.0-rc5-51f14e2.cki (arm-next)
@ 2020-05-13 15:51 ` Tejun Heo
0 siblings, 0 replies; 9+ messages in thread
From: Tejun Heo @ 2020-05-13 15:51 UTC (permalink / raw)
To: Jan Stancek
Cc: Veronika Kabatova, cgroups-u79uwXL29TY76Z2rM5mHXA, Will Deacon,
Memory Management, CKI Project, catalin marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, LTP List
On Wed, May 13, 2020 at 11:40:15AM -0400, Jan Stancek wrote:
> In LTP issue above it was clear that memory controller is in use.
> Here it looks like some lingering reference to cpuset controller
> that can't be seen in sysfs.
>
> It's triggered by podman tests actually:
> 1. run podman tests
> 2. mount -t cgroup -ocpuset cpuset /mnt/cpuset/ -> EBUSY
>
> # mount | grep cgroup
> cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel)
>
> # grep cpuset -r /sys/fs/cgroup/
> /sys/fs/cgroup/cgroup.controllers:cpuset cpu io memory pids
>
> And yet, v1 cgroup fails to mount:
>
> # mount -t cgroup -ocpuset cpuset /mnt/cpuset/
> mount: /mnt/cpuset: cpuset already mounted or mount point busy.
While if a regression it may point to a newly introduced behavior, in
general, dynamically reassigning cgroup controllers to a different version
hierarchy after active use is not something fully supported. From cgroup2
documentation:
A controller can be moved across hierarchies only after the controller is
no longer referenced in its current hierarchy. Because per-cgroup
controller states are destroyed asynchronously and controllers may have
lingering references, a controller may not show up immediately on the v2
hierarchy after the final umount of the previous hierarchy. Similarly, a
controller should be fully disabled to be moved out of the unified
hierarchy and it may take some time for the disabled controller to become
available for other hierarchies; furthermore, due to inter-controller
dependencies, other controllers may need to be disabled too.
While useful for development and manual configurations, moving controllers
dynamically between the v2 and other hierarchies is strongly discouraged
for production use. It is recommended to decide the hierarchies and
controller associations before starting using the controllers after system
boot.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-05-13 15:51 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-13 3:01 ❌ FAIL: Test report for kernel 5.7.0-rc5-51f14e2.cki (arm-next) CKI Project
2020-05-13 6:12 ` Will Deacon
2020-05-13 10:19 ` Veronika Kabatova
2020-05-13 15:40 ` Jan Stancek
2020-05-13 15:40 ` Jan Stancek
2020-05-13 15:40 ` [LTP] " Jan Stancek
2020-05-13 15:51 ` ❌ FAIL: Test report for kernel?5.7.0-rc5-51f14e2.cki (arm-next) Tejun Heo
2020-05-13 15:51 ` Tejun Heo
2020-05-13 15:51 ` [LTP] " Tejun Heo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.