linux-kernel - Re: [PATCH V2] cgroup: Trace event cgroup id fields should be u64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20211201114453.6bbdb87c@gandalf.local.home>
Date:   Wed, 1 Dec 2021 11:44:53 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     William Kucharski <william.kucharski@...cle.com>
Cc:     Ingo Molnar <mingo@...hat.com>, Tejun Heo <tj@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2] cgroup: Trace event cgroup id fields should be u64

On Wed, 1 Dec 2021 16:27:54 +0000
William Kucharski <william.kucharski@...cle.com> wrote:

> I had pondered that as a consequence for two of the three uses but wasn't sure
> if it was worth reordering things; I can easily do so.
> 
> What do you suggest for cgroup_migrate as that will have a hole either way
> as it's:
> 
>         TP_STRUCT__entry(
>                 __field(        int,            dst_root                )
>                 __field(        u64,            dst_id                  )
>                 __field(        int,            dst_level               )
>                 __field(        int,            pid                     )
>                 __string(       dst_path,       path                    )
>                 __string(       comm,           task->comm              )
>         ),
> 
> if I put dst_level above dst_id, the int for pid field will leave a hole
> anyway because the string pointer for dst_path will want to be 64-bit
> aligned.
> 
> Thanks in advance.
> 

It's not actually a string pointer, both string() macros are really 4 byte
words. The above would be best compressed as:

         TP_STRUCT__entry(
                 __field(        int,            dst_root                )
                 __field(        int,            dst_level               )
                 __field(        u64,            dst_id                  )
                 __field(        int,            pid                     )
                 __string(       dst_path,       path                    )
                 __string(       comm,           task->comm              )
         ),

What that would turn into is:

	struct __entry {
		int		dst_root;
		int		dst_level;
		u64		dst_id;
		int		pid;
		int		dst_path_offset_size;
		int		comm_offset_size;
		char		strings[];
	}

Remember, this is used for storing data onto the ring buffer. I'll make up
two strings to show an example.

  dst_path = "/path/to/dst_path";
  comm = "bash";

The string(dst_path) and string(comm) would be where the data to find the
strings are. The strings will be stored in the strings[] field of the
structure, and the dst_path and comm fields will be used to find those
strings.

	dst_root = 1;
	dst_level = 2;
	dst_id = 3;
	pid = 4;

	dst_path = (28 << 16) | 18;
	comm = ((28 + 18) << 16 | 5;

	strings = "/path/to/dst_path\0bash\0";

The dst_path holds how to find the string it represents. It starts at
offset 28[*] (sizeof(int) * 5 + sizeof(u64))
And has size of 18 (strlen("/path/to/dst_path") + 1)

The comm string starts at offset 46 (28 + size of dst_path), and has he
size of 5 (strlen("bash") + 1).

So consider "string()" macros to be only 4 bytes in size. And leave the
"holes" at the end, especially if there's strings, because the will start
the actual strings nicely aligned.

-- Steve

[*] It really starts at a later offset, because there's common fields added
before the first field (common_type, common_flags, common_preempt_count,
common_pid) that is also included in that offset count.