> ----- Original Message ----- >> From: "Tejun Heo" <tj@xxxxxxxxxx> >> To: "Jan Stancek" <jstancek@xxxxxxxxxx> >> Cc: "Chen Gang" <gang.chen.5i5j@xxxxxxxxx>, "Garrett Cooper" <yanegomi@xxxxxxxxx>, gaowanlong@xxxxxxxxxxxxxx, >> chris@xxxxxxxx, mitani@xxxxxxxxxxx, lizf@xxxxxxxxxxxxxx, "Li Zefan" <lizefan@xxxxxxxxxx>, >> containers@xxxxxxxxxxxxxxxxxxxxxxxxxx, cgroups@xxxxxxxxxxxxxxx >> Sent: Thursday, 21 November, 2013 4:26:45 PM >> Subject: Re: [Suggestion] kernel: cgroup: mount failure in LTP cgroup_regression_test.sh >> >> Hello, Jan. >> >> On Thu, Nov 21, 2013 at 03:04:54AM -0500, Jan Stancek wrote: >>> it looks like those 2 subsystems are already mounted by systemd, >>> each in different hierarchy: >>> >>>> cpuacct 4 35 1 >>>> freezer 5 4 1 >>> >>> from Documentation/cgroups/cgroups.txt: >>> "If an active hierarchy with exactly the same set of subsystems already >>> exists, it will be reused for the new mount. If no existing hierarchy >>> matches, and any of the requested subsystems are in use in an existing >>> hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy >>> is activated, associated with the requested subsystems." >> >> Ah, cgroup now requires that those recycled mounts to have matching >> options. This is an intended behavior change because previously we >> could end up with mounts which have actual options which differ from >> what was specified by mount, which can be misleading at the very >> least. > > I believe the test always respected this requirement. Problem we see > is because of initial state of the system. Test appears to expect > that it is able to mount cgroups freely, but they are already in use. > >> Would it be possible to update LTP accordingly? > > I'm not sure the test can do anything (other than not run at all). > > Other option is to setup system in a way where cgroups are not in use > prior to running this test, though this may not be possible with systemd. > I believe each test will do cleanup after it finishes (like umount cgroupfs). I guess the system already mounted cgroupfs after boot and each cgroup subsystem was mounted separately? And that leads to this issue. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
