fix(cws): collect mount fields from make_visible to support kernels >= 6.18 (#54708)

### What does this PR do?

Collects the fields of a mount syscall event from `make_visible` instead of `attach_recursive_mnt`.

### Motivation

Kernel 6.18 changed how `attach_recursive_mnt` receives its destination, and compilers usually emit it as an ISRA optimized function, so the hook either reads the wrong arguments or is not called at all. It is the only hook covering plain mounts, so CWS stops reporting them entirely: no mount event, no mount resolution, and paths on those mounts can no longer be resolved from events.

`make_visible` is reached on the same code path, takes a single argument and exposes the parent mount and the mountpoint through the new mount itself. It exists since 6.17, which covers every kernel affected by the change, and older kernels keep using the existing hook.

### Describe how you validated your changes

Existing functional tests (TestMount* and TestUmount tests) running on Ubuntu 26.04 that this PR fixes.

### Additional Notes

Co-authored-by: yoann.ghigoff <yoann.ghigoff@datadoghq.com> eb0f7c4

Author: gh-worker-dd-mergequeue-cf854d[bot]

agent-schema/cli/index.html

@@ -4018,7 +4018,7 @@
 
 
 
-<h1 id="cli-commands-dda-inv-schema">CLI Commands (<code>dda inv schema.*</code>)<a class="headerlink" href="#cli-commands-dda-inv-schema" title="Permanent link">&para;</a></h1>
+<h1 id="cli-commands-dda-inv-schema">CLI Commands (<code>dda inv schema.*</code>)</h1>
 <p>The schema tooling is exposed through a set of <code>dda inv schema.*</code> invoke tasks
 (defined in <code>tasks/schema/</code>). This page documents each command, its arguments,
 and when you would run it.</p>
@@ -4027,7 +4027,7 @@ <h1 id="cli-commands-dda-inv-schema">CLI Commands (<code>dda inv schema.*</code>
 pipelines, so you rarely need to invoke them by hand — but they are useful when
 adding or editing settings, debugging schema problems, or regenerating output
 locally.</p>
-<h2 id="how-the-commands-fit-together">How the commands fit together<a class="headerlink" href="#how-the-commands-fit-together" title="Permanent link">&para;</a></h2>
+<h2 id="how-the-commands-fit-together">How the commands fit together</h2>
 <p>The schema files under <code>pkg/config/schema/yaml/</code> are the source of truth and are
 edited by hand (or through <code>schema.add-setting</code>). Everything else is derived from
 them:</p>
@@ -4043,7 +4043,7 @@ <h2 id="how-the-commands-fit-together">How the commands fit together<a class="he
   external consumers.</li>
 <li><code>schema.locate</code> finds where a setting is declared.</li>
 </ul>
-<h2 id="schemaadd-setting"><code>schema.add-setting</code><a class="headerlink" href="#schemaadd-setting" title="Permanent link">&para;</a></h2>
+<h2 id="schemaadd-setting"><code>schema.add-setting</code></h2>
 <p>Interactive wizard to add a new setting to the schema. It prompts for the
 setting name (dotted path), type, default, visibility, and description, then
 inserts the node into the correct schema file under <code>pkg/config/schema/yaml/</code>
@@ -4073,7 +4073,7 @@ <h2 id="schemaadd-setting"><code>schema.add-setting</code><a class="headerlink"
 public with a description. It runs <code>schema.lint</code> at the end so any remaining
 problems are visible.</p>
 <hr />
-<h2 id="schemalint"><code>schema.lint</code><a class="headerlink" href="#schemalint" title="Permanent link">&para;</a></h2>
+<h2 id="schemalint"><code>schema.lint</code></h2>
 <p>Validate the schema against the schema quality rules and exit
 non-zero on any violation.</p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-1-1"><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>schema.lint
@@ -4103,7 +4103,7 @@ <h2 id="schemalint"><code>schema.lint</code><a class="headerlink" href="#schemal
 </tbody>
 </table>
 <hr />
-<h2 id="schematemplate"><code>schema.template</code><a class="headerlink" href="#schematemplate" title="Permanent link">&para;</a></h2>
+<h2 id="schematemplate"><code>schema.template</code></h2>
 <p>Render a single config template (one build type, one OS) from the schema file. Useful for inspecting what a setting will
 look like in the generated example without running the whole build.</p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-2-1"><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>schema.template<span class="w"> </span><span class="se">\</span>
@@ -4147,7 +4147,7 @@ <h2 id="schematemplate"><code>schema.template</code><a class="headerlink" href="
 template sections are included; the OS target controls which platform-specific
 defaults and <code>platform_only</code> settings are emitted.</p>
 <hr />
-<h2 id="schematemplate-all"><code>schema.template-all</code><a class="headerlink" href="#schematemplate-all" title="Permanent link">&para;</a></h2>
+<h2 id="schematemplate-all"><code>schema.template-all</code></h2>
 <p>Render every combination of build type × OS target from the core and
 system-probe schemas at once. This is what the build pipeline uses to keep the
 shipped <code>*.yaml.example</code> files in sync.</p>
@@ -4183,7 +4183,7 @@ <h2 id="schematemplate-all"><code>schema.template-all</code><a class="headerlink
 </tbody>
 </table>
 <hr />
-<h2 id="schemalocate"><code>schema.locate</code><a class="headerlink" href="#schemalocate" title="Permanent link">&para;</a></h2>
+<h2 id="schemalocate"><code>schema.locate</code></h2>
 <p>Find where a setting or section is defined in the schema source and print its
 node plus the exact file and line.</p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-4-1"><a id="__codelineno-4-1" name="__codelineno-4-1" href="#__codelineno-4-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>--<span class="w"> </span>schema.locate<span class="w"> </span>apm_config.enabled
@@ -4211,7 +4211,7 @@ <h2 id="schemalocate"><code>schema.locate</code><a class="headerlink" href="#sch
 </span><span id="__span-5-8"><a id="__codelineno-5-8" name="__codelineno-5-8" href="#__codelineno-5-8"></a>dda<span class="w"> </span>inv<span class="w"> </span>--<span class="w"> </span>schema.locate<span class="w"> </span><span class="s1">&#39;apm_config\..*enabled&#39;</span><span class="w"> </span>--json
 </span></code></pre></div>
 <hr />
-<h2 id="typical-workflows">Typical workflows<a class="headerlink" href="#typical-workflows" title="Permanent link">&para;</a></h2>
+<h2 id="typical-workflows">Typical workflows</h2>
 <p><strong>I edited a setting in the schema and want the Go code to reflect it:</strong></p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-6-1"><a id="__codelineno-6-1" name="__codelineno-6-1" href="#__codelineno-6-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>schema.lint<span class="w">            </span><span class="c1"># validate the schema</span>
 </span><span id="__span-6-2"><a id="__codelineno-6-2" name="__codelineno-6-2" href="#__codelineno-6-2"></a>dda<span class="w"> </span>inv<span class="w"> </span>schema.codegen<span class="w">        </span><span class="c1"># regenerate pkg/config/setup from it</span>
@@ -4225,7 +4225,7 @@ <h2 id="typical-workflows">Typical workflows<a class="headerlink" href="#typical
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-8-1"><a id="__codelineno-8-1" name="__codelineno-8-1" href="#__codelineno-8-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>--<span class="w"> </span>schema.locate<span class="w"> </span>apm_config.enabled<span class="w">   </span><span class="c1"># exact: node + file:line</span>
 </span><span id="__span-8-2"><a id="__codelineno-8-2" name="__codelineno-8-2" href="#__codelineno-8-2"></a>dda<span class="w"> </span>inv<span class="w"> </span>--<span class="w"> </span>schema.locate<span class="w"> </span><span class="s1">&#39;*enabled&#39;</span><span class="w">           </span><span class="c1"># pattern: all paths ending in &quot;enabled&quot;</span>
 </span></code></pre></div>
-<h2 id="see-also">See also<a class="headerlink" href="#see-also" title="Permanent link">&para;</a></h2>
+<h2 id="see-also">See also</h2>
 <ul>
 <li><a href="../">Introduction</a> — what the schema is and why it exists.</li>
 <li><a href="../keywords/">Keyword Reference</a> — the keywords these commands read and write.</li>

agent-schema/examples/index.html

@@ -3908,12 +3908,12 @@
 
 
 
-<h1 id="examples">Examples<a class="headerlink" href="#examples" title="Permanent link">&para;</a></h1>
+<h1 id="examples">Examples</h1>
 <p>This page walks through three annotated examples taken from or inspired by the
 real schema files. Each example builds on the concepts introduced in the
 <a href="../keywords/">Keyword Reference</a>.</p>
 <hr />
-<h2 id="example-1-simple-public-setting-node-api_key">Example 1 — Simple public setting node (<code>api_key</code>)<a class="headerlink" href="#example-1-simple-public-setting-node-api_key" title="Permanent link">&para;</a></h2>
+<h2 id="example-1-simple-public-setting-node-api_key">Example 1 — Simple public setting node (<code>api_key</code>)</h2>
 <div class="language-yaml highlight"><pre><span></span><code><span id="__span-0-1"><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a><span class="nt">api_key</span><span class="p">:</span>
 </span><span id="__span-0-2"><a id="__codelineno-0-2" name="__codelineno-0-2" href="#__codelineno-0-2"></a><span class="w">  </span><span class="nt">node_type</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">setting</span><span class="w">    </span><span class="c1"># (1)</span>
 </span><span id="__span-0-3"><a id="__codelineno-0-3" name="__codelineno-0-3" href="#__codelineno-0-3"></a><span class="w">  </span><span class="nt">type</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">string</span><span class="w">          </span><span class="c1"># (2)</span>
@@ -3945,7 +3945,7 @@ <h2 id="example-1-simple-public-setting-node-api_key">Example 1 — Simple publi
    and public documentation. Without this, the setting is considered internal.</li>
 </ol>
 <hr />
-<h2 id="example-2-section-node-with-mixed-children-apm_config">Example 2 — Section node with mixed children (<code>apm_config</code>)<a class="headerlink" href="#example-2-section-node-with-mixed-children-apm_config" title="Permanent link">&para;</a></h2>
+<h2 id="example-2-section-node-with-mixed-children-apm_config">Example 2 — Section node with mixed children (<code>apm_config</code>)</h2>
 <p>This example shows a section node taken from <code>pkg/config/schema/core_schema.yaml</code>
 with several child setting nodes, including one with a <code>platform_default</code>.</p>
 <div class="language-yaml highlight"><pre><span></span><code><span id="__span-1-1"><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a><span class="nt">apm_config</span><span class="p">:</span>
@@ -4009,7 +4009,7 @@ <h2 id="example-2-section-node-with-mixed-children-apm_config">Example 2 — Sec
    is known, eg. setting a value for <code>other</code> which is Darwin specific when you already have a value for Linux and Windows.</li>
 </ol>
 <hr />
-<h2 id="example-3-complex-nested-type-cel_workload_exclude">Example 3 — Complex nested type (<code>cel_workload_exclude</code>)<a class="headerlink" href="#example-3-complex-nested-type-cel_workload_exclude" title="Permanent link">&para;</a></h2>
+<h2 id="example-3-complex-nested-type-cel_workload_exclude">Example 3 — Complex nested type (<code>cel_workload_exclude</code>)</h2>
 <p>This example shows how JSON Schema's composable
 validation handles a non-trivial type. <code>cel_workload_exclude</code> corresponds to
 the following Go struct:</p>

agent-schema/faq/index.html

@@ -3974,9 +3974,9 @@
 
 
 
-<h1 id="faq">FAQ<a class="headerlink" href="#faq" title="Permanent link">&para;</a></h1>
+<h1 id="faq">FAQ</h1>
 <hr />
-<h2 id="how-do-i-add-a-new-setting">How do I add a new setting?<a class="headerlink" href="#how-do-i-add-a-new-setting" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-add-a-new-setting">How do I add a new setting?</h2>
 <ol>
 <li>
 <p><strong>Determine the node type.</strong> If the setting holds a value (string, number,
@@ -4019,12 +4019,12 @@ <h2 id="how-do-i-add-a-new-setting">How do I add a new setting?<a class="headerl
 </span><span id="__span-0-4"><a id="__codelineno-0-4" name="__codelineno-0-4" href="#__codelineno-0-4"></a><span class="w">  </span><span class="nt">description</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Enables the new feature.</span>
 </span></code></pre></div>
 <hr />
-<h2 id="how-do-i-deprecate-a-setting">How do I deprecate a setting?<a class="headerlink" href="#how-do-i-deprecate-a-setting" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-deprecate-a-setting">How do I deprecate a setting?</h2>
 <blockquote>
 <p><strong>Note:</strong> [WIP] Automated solution coming soon.</p>
 </blockquote>
 <hr />
-<h2 id="how-do-i-make-a-setting-public">How do I make a setting public?<a class="headerlink" href="#how-do-i-make-a-setting-public" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-make-a-setting-public">How do I make a setting public?</h2>
 <ol>
 <li>
 <p><strong>Write a <code>description</code></strong> that explains what the setting does, what the default means, and any caveats. Every public
@@ -4057,7 +4057,7 @@ <h2 id="how-do-i-make-a-setting-public">How do I make a setting public?<a class=
 <p>The setting will appear in the configuration examples (ex: <code>datadog.yaml.example</code>) the next time the file is
 regenerated.</p>
 <hr />
-<h2 id="how-do-i-document-a-public-setting">How do I document a public setting?<a class="headerlink" href="#how-do-i-document-a-public-setting" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-document-a-public-setting">How do I document a public setting?</h2>
 <ol>
 <li><strong>Write a clear <code>description</code></strong> covering:</li>
 <li>What the setting does.</li>
@@ -4082,13 +4082,13 @@ <h2 id="how-do-i-document-a-public-setting">How do I document a public setting?<
 <li><strong>Set <code>visibility: public</code></strong> to include the setting in generated output.</li>
 </ol>
 <hr />
-<h2 id="how-do-i-generate-datadogyamlexample">How do I generate <code>datadog.yaml.example</code>?<a class="headerlink" href="#how-do-i-generate-datadogyamlexample" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-generate-datadogyamlexample">How do I generate <code>datadog.yaml.example</code>?</h2>
 <p>The generation of <code>datadog.yaml.example</code> from the schema is wired into the
 Agent's build pipeline and runs automatically. Developers do not normally need
 to trigger it manually.</p>
 <p>If you want to validate the generated example you can use <code>dda inv schema.template-all</code> command.</p>
 <hr />
-<h2 id="what-is-the-difference-between-datadogyamlexample-and-system-probeyamlexample">What is the difference between <code>datadog.yaml.example</code> and <code>system-probe.yaml.example</code>?<a class="headerlink" href="#what-is-the-difference-between-datadogyamlexample-and-system-probeyamlexample" title="Permanent link">&para;</a></h2>
+<h2 id="what-is-the-difference-between-datadogyamlexample-and-system-probeyamlexample">What is the difference between <code>datadog.yaml.example</code> and <code>system-probe.yaml.example</code>?</h2>
 <p>Each configuration file has its own schema and its own generated example file:</p>
 <ul>
 <li>

agent-schema/index.html

@@ -3870,19 +3870,19 @@
 
 
 
-<h1 id="agent-configuration-schema">Agent Configuration Schema<a class="headerlink" href="#agent-configuration-schema" title="Permanent link">&para;</a></h1>
+<h1 id="agent-configuration-schema">Agent Configuration Schema</h1>
 <p>The Datadog Agent configuration schema is a YAML-based
 <a href="https://json-schema.org/">JSON Schema</a> that centrally describes every
 configuration setting for the Agent. It is written in YAML for readability but
 is fully compatible with JSON Schema tooling.</p>
-<h2 id="why-it-exists">Why it exists<a class="headerlink" href="#why-it-exists" title="Permanent link">&para;</a></h2>
+<h2 id="why-it-exists">Why it exists</h2>
 <p>Previously, Agent configuration was defined through a combination of imperative Go code (<code>BindEnvAndSetDefault</code> calls in
 <code>pkg/config/setup</code>), YAML example files maintained by-hand, and scattered validation logic. This made it hard to
 understand what a setting does, what values it accepts, or what its default is — without reading source code.</p>
 <p>The schema replaces this with a <strong>single source of truth</strong>. All information
 about a setting — its type, default value, documentation, environment variables,
 validation rules, and visibility — lives in one place.</p>
-<h2 id="what-it-enables">What it enables<a class="headerlink" href="#what-it-enables" title="Permanent link">&para;</a></h2>
+<h2 id="what-it-enables">What it enables</h2>
 <ul>
 <li><strong>Config validation without running the Agent</strong> — any JSON Schema library can
   validate a customer's <code>datadog.yaml</code> against the schema.</li>
@@ -3896,15 +3896,15 @@ <h2 id="what-it-enables">What it enables<a class="headerlink" href="#what-it-ena
 <li><strong>Runtime validation</strong>  — The user configuration can be validate at runtime by the Agent allowing automatic fallback
   to default upon an invalid value.</li>
 </ul>
-<h2 id="terminology">Terminology<a class="headerlink" href="#terminology" title="Permanent link">&para;</a></h2>
+<h2 id="terminology">Terminology</h2>
 <ul>
 <li><strong>Path</strong> — a string of terms separated by dots (<code>"."</code>) that represents a series of nodes in the config tree.</li>
 <li><strong>Setting</strong> — a configurable value that can be located using a path (example <code>apm_config.enabled</code>)</li>
 <li><strong>Section</strong> — a groupping of settings under a common name (example <code>apm_config</code>)</li>
 <li><strong>Object</strong> — a data type of key-value pairs. Also called a map (in Go) or dict (in Python), but called an object in JSON Schema since it comes from JavaScript.</li>
 <li><strong>Default</strong> — the value that will be retrieved for a given setting if none is specified by the user's file-based configuration or environment variable (or other source).</li>
 </ul>
-<h2 id="node-types">Node types<a class="headerlink" href="#node-types" title="Permanent link">&para;</a></h2>
+<h2 id="node-types">Node types</h2>
 <p>The schema tree is composed of two types of nodes:</p>
 <ul>
 <li><strong>Setting nodes</strong> represent individual settings. They have a type and a value.
@@ -3917,7 +3917,7 @@ <h2 id="node-types">Node types<a class="headerlink" href="#node-types" title="Pe
 <p>The distinction matters when a setting's value is an object. For example, <code>docker_labels_as_tags</code> is a <code>type: object</code>
 setting node — its value is a dict of strings, but that dict is the setting's <em>value</em>, not a group of child settings. It
 is a setting node, and <strong>not</strong> a section node.</p>
-<h2 id="one-schema-per-configuration-file">One schema per configuration file<a class="headerlink" href="#one-schema-per-configuration-file" title="Permanent link">&para;</a></h2>
+<h2 id="one-schema-per-configuration-file">One schema per configuration file</h2>
 <p>The Agent ships with multiple configuration files, each with its own schema:</p>
 <table>
 <thead>
@@ -3938,12 +3938,12 @@ <h2 id="one-schema-per-configuration-file">One schema per configuration file<a c
 </tbody>
 </table>
 <p>All schemas share the same keyword set described in this documentation.</p>
-<h2 id="json-schema-foundation">JSON Schema foundation<a class="headerlink" href="#json-schema-foundation" title="Permanent link">&para;</a></h2>
+<h2 id="json-schema-foundation">JSON Schema foundation</h2>
 <p>The Agent schema builds on <a href="https://json-schema.org/">JSON Schema draft 2020-12</a>.
 This documentation focuses on how keywords are used in the Agent schema
 specifically. For a general introduction to JSON Schema, see
 <a href="https://json-schema.org/understanding-json-schema">Understanding JSON Schema</a>.</p>
-<h2 id="next-steps">Next steps<a class="headerlink" href="#next-steps" title="Permanent link">&para;</a></h2>
+<h2 id="next-steps">Next steps</h2>
 <ul>
 <li><a href="keywords/">Keyword Reference</a> — complete reference for all supported keywords.</li>
 <li><a href="examples/">Examples</a> — annotated, real-world examples from the schema.</li>