libcontainer/intelrdt: add support for EnableMonitoring field #4832

marquiz · 2025-08-01T13:54:52Z

The linux.intelRdt.enableMonitoring field enables the creation of a per-container monitoring group. The monitoring group is removed when the container is destroyed.

Refs: opencontainers/runtime-spec#1287

libcontainer/intelrdt/intelrdt.go

rata · 2025-08-05T19:22:03Z

libcontainer/intelrdt/intelrdt.go

@@ -474,6 +474,16 @@ func (m *Manager) Apply(pid int) (err error) {
 		return newLastCmdError(err)
 	}

+	// Create MON group
+	if monPath := m.GetMonPath(); monPath != "" {
+		if err := os.MkdirAll(monPath, 0o755); err != nil {


Where is this path? Inside the container? On the host?

This is on the host (now changed to Mkdir)

marquiz · 2025-08-06T06:57:00Z

Review comments from @rata addressed. Rebased. Submitted the first commit as a separate PR (#4840), too

marquiz · 2025-08-07T19:07:39Z

Rebased

marquiz · 2025-08-18T11:33:01Z

Updated:

rebased
go.mod: bumped runtime-spec to latest tip of the main branch
features.go: set linux.intelRdt.monitoring to true

marquiz · 2025-08-26T17:27:48Z

@rata @kolyshkin @AkihiroSuda @cyphar

rata

Please remove the fmt.Println() lines

libcontainer/intelrdt/intelrdt.go

rata · 2025-08-28T10:28:23Z

libcontainer/intelrdt/intelrdt.go

@@ -478,6 +478,16 @@ func (m *Manager) Apply(pid int) (err error) {
 		return newLastCmdError(err)
 	}

+	// Create MON group
+	if monPath := m.GetMonPath(); monPath != "" {
+		if err := os.Mkdir(monPath, 0o755); err != nil && !os.IsExist(err) {


Who has control of this path? In runc this is trusted, okay, but is it exposed in k8s or containerd or some other to the user?

Not sure with the https://github.com/intel/k8s-rdt-controller what is exposed to an end user

It's runc, it's in this very same file (and patch):

func (m *Manager) GetMonPath() string { if closPath := m.GetPath(); closPath != "" && m.config.IntelRdt.EnableMonitoring { path, err := securejoin.SecureJoin(filepath.Join(closPath, "mon_groups"), m.id)

So it's basically <clos-dir>/mon_groups/<container-id>

Thanks, and that comes from intelRdtRoot. But where does that come from? Is there any way an unprivileged user (or just anyone that is not the sysadmin or so) can control any path component (or the intelRDT root)?

That, in turn, comes from parsing the output of statfs syscall (unix.Statfs()). Note that in the case of runc update the closPath is taken from the config.json of the container.

In any case I cannot see any way that an unprivileged user can control the path

So statfs will have some string value and we will mkdir it on the host, outside of the container rootfs?

This conversation was broken out of this thread, it continued in the main PR discussion. The final answer I found for this is posted here: #4832 (comment)

Basically, the fs will be mounted somewhere on the host by the admin and we might create/delete some dirs inside that. None of that is accessible to the container process.

@marquiz correct me if I'm getting something wrong.

@kolyshkin PTAL, I'd like someone else to look at this part too, just in case I'm missing something :)

marquiz · 2025-08-29T10:32:02Z

Rebased (see if the unrelated linter errors go away...)

libcontainer/intelrdt/intelrdt.go

rata · 2025-08-29T15:14:47Z

libcontainer/intelrdt/intelrdt.go

@@ -478,6 +478,16 @@ func (m *Manager) Apply(pid int) (err error) {
 		return newLastCmdError(err)
 	}

+	// Create MON group
+	if monPath := m.GetMonPath(); monPath != "" {
+		if err := os.Mkdir(monPath, 0o755); err != nil && !os.IsExist(err) {


So statfs will have some string value and we will mkdir it on the host, outside of the container rootfs?

marquiz · 2025-08-29T18:49:09Z

So statfs will have some string value and we will mkdir it on the host, outside of the container rootfs?

Yes the data comes from the Linux kernel. See statfs syscall, e.g. https://man7.org/linux/man-pages/man2/statfs.2.html

rata · 2025-09-02T09:32:36Z

@marquiz that manpage doesn't tell anything about intelrdt :-). But ok, I guess you need to mount the restctrl fs like shown here and therefore the host admin decides where it is mounted, no container will have write access to any file/dir there, I guess.

rata

This mostly LGTM. But let's use the well-known table tests (or are you avoiding them for a reason?)

libcontainer/intelrdt/intelrdt_test.go

libcontainer/intelrdt/intelrdt.go

marquiz · 2025-09-03T14:36:26Z

Updated, review comments addressed

@rata @kolyshkin

libcontainer/configs/validate/intelrdt_test.go

libcontainer/intelrdt/intelrdt_test.go

marquiz · 2025-09-03T18:33:28Z

Updated @rata

Signed-off-by: Markus Lehtonen <[email protected]>

marquiz · 2025-09-03T20:56:39Z

Rebased to resolve conflicts

rata

Sorry I didn't check the tests before. Let's improve and reduce the c&p. Let's make it more standard golang table-tests.

rata · 2025-09-04T10:08:34Z

libcontainer/intelrdt/intelrdt.go

-		defer m.mu.Unlock()
-		if err := os.Remove(m.GetPath()); err != nil && !os.IsNotExist(err) {
-			return err
+	if m.config.IntelRdt != nil {


nit: Let's do a quick return if intelRdt is nil and remove the indentation for the rest of the function

Changed as suggested

rata · 2025-09-04T10:43:06Z

libcontainer/intelrdt/intelrdt_test.go

+				closPath := filepath.Join(intelRdtRoot, closID)
+				intelrdt := newManager(helper.config, "", closPath)
+				if err := intelrdt.Apply(1234); err == nil {
+					t.Fatal("unexpected success when applying pid")
+				}


It seems this can be part of the for ... range tests loop,a s it's c&p in every testFunc(). Yes, one needs a slightly different param, but that can be part of the test struct, I think.

Tests refactored

rata · 2025-09-04T10:43:34Z

libcontainer/intelrdt/intelrdt_test.go

+				helper.config.IntelRdt = &configs.IntelRdt{
+					ClosID: closID,
+				}
+
+				closPath := filepath.Join(intelRdtRoot, closID)
+				if err := os.MkdirAll(closPath, 0o755); err != nil {
+					t.Fatal(err)
+				}
+
+				intelrdt := newManager(helper.config, "container-1", closPath)
+				if err := intelrdt.Apply(1234); err != nil {
+					t.Fatalf("Apply() failed: %v", err)
+				}


The linux.intelRdt.enableMonitoring field enables the creation of a per-container monitoring group. The monitoring group is removed when the container is destroyed. Signed-off-by: Markus Lehtonen <[email protected]>

marquiz · 2025-09-04T15:00:47Z

Updated: test refactored

@rata @kolyshkin

marquiz force-pushed the devel/rdt-enablemonitoring branch 4 times, most recently from 520aadd to d141fb0 Compare August 4, 2025 14:18

rata reviewed Aug 5, 2025

View reviewed changes

marquiz force-pushed the devel/rdt-enablemonitoring branch 3 times, most recently from 169609d to 4024488 Compare August 6, 2025 06:55

marquiz force-pushed the devel/rdt-enablemonitoring branch 2 times, most recently from 86329fe to 2380794 Compare August 7, 2025 19:06

marquiz force-pushed the devel/rdt-enablemonitoring branch 2 times, most recently from e31d98c to 4af20b5 Compare August 18, 2025 11:32

marquiz mentioned this pull request Aug 26, 2025

Support direct editing of the intelRdt config containerd/nri#215

Open

marquiz force-pushed the devel/rdt-enablemonitoring branch 2 times, most recently from fd132e2 to 4e43d65 Compare August 26, 2025 17:23

rata requested changes Aug 27, 2025

View reviewed changes

libcontainer/intelrdt/intelrdt.go Outdated Show resolved Hide resolved

rata added the impact/changelog label Aug 27, 2025

marquiz force-pushed the devel/rdt-enablemonitoring branch from 4e43d65 to 2fbcde5 Compare August 27, 2025 12:44

rata reviewed Aug 28, 2025

View reviewed changes

marquiz force-pushed the devel/rdt-enablemonitoring branch from 2fbcde5 to abafdf8 Compare August 29, 2025 10:31

rata reviewed Aug 29, 2025

View reviewed changes

rata requested changes Sep 2, 2025

View reviewed changes

libcontainer/intelrdt/intelrdt_test.go Outdated Show resolved Hide resolved

kolyshkin reviewed Sep 3, 2025

View reviewed changes

libcontainer/intelrdt/intelrdt.go Outdated Show resolved Hide resolved

kolyshkin reviewed Sep 3, 2025

View reviewed changes

libcontainer/intelrdt/intelrdt.go Outdated Show resolved Hide resolved

marquiz force-pushed the devel/rdt-enablemonitoring branch from abafdf8 to dac3655 Compare September 3, 2025 14:33

rata self-requested a review September 3, 2025 15:05

rata requested changes Sep 3, 2025

View reviewed changes

libcontainer/configs/validate/intelrdt_test.go Outdated Show resolved Hide resolved

libcontainer/intelrdt/intelrdt_test.go Outdated Show resolved Hide resolved

marquiz force-pushed the devel/rdt-enablemonitoring branch 2 times, most recently from ce987d5 to 88604c3 Compare September 3, 2025 18:32

Update runtime-spec

5b8711b

Signed-off-by: Markus Lehtonen <[email protected]>

marquiz force-pushed the devel/rdt-enablemonitoring branch from 88604c3 to c0415e2 Compare September 3, 2025 20:56

rata requested changes Sep 4, 2025

View reviewed changes

marquiz force-pushed the devel/rdt-enablemonitoring branch from c0415e2 to d7032f0 Compare September 4, 2025 14:00

libcontainer/intelrdt: add support for EnableMonitoring field

19e2d0a

The linux.intelRdt.enableMonitoring field enables the creation of a per-container monitoring group. The monitoring group is removed when the container is destroyed. Signed-off-by: Markus Lehtonen <[email protected]>

marquiz force-pushed the devel/rdt-enablemonitoring branch from d7032f0 to 19e2d0a Compare September 4, 2025 14:58

libcontainer/intelrdt: add support for EnableMonitoring field #4832

Are you sure you want to change the base?

libcontainer/intelrdt: add support for EnableMonitoring field #4832

Uh oh!

Conversation

marquiz commented Aug 1, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marquiz commented Aug 6, 2025

Uh oh!

marquiz commented Aug 7, 2025

Uh oh!

marquiz commented Aug 18, 2025

Uh oh!

marquiz commented Aug 26, 2025

Uh oh!

rata left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rata Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marquiz commented Aug 29, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marquiz commented Aug 29, 2025

Uh oh!

rata commented Sep 2, 2025

Uh oh!

rata left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marquiz commented Sep 3, 2025

Uh oh!

Uh oh!

Uh oh!

marquiz commented Sep 3, 2025

Uh oh!

marquiz commented Sep 3, 2025

Uh oh!

rata left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

rata Aug 28, 2025 •

edited

Loading

rata left a comment •

edited

Loading