diff --git a/bpfconf2024/bpfconf2024.html b/bpfconf2024/bpfconf2024.html
index 58e2467..f011ffa 100644
--- a/bpfconf2024/bpfconf2024.html
+++ b/bpfconf2024/bpfconf2024.html
@@ -60,7 +60,7 @@ <h2>Discussion Topics</h2>
         </p>
         <p>
           LWN coverage of the BPF track from Daroc Alden can be found
-          <a href="https://lwn.net/Articles/lsfmmbpf2024/" target="_blank" rel="noopener">here</a>.
+          <a href="https://lwn.net/Articles/lsfmmbpf2025/" target="_blank" rel="noopener">here</a>.
           Raw (and incomplete) notes for some of the sessions have been collected by participants
           <a href="bpfconf2024_material/LSFMMBPF_2024_raw_notes.pdf" target="_blank" rel="noopener">here</a>.
         </p>
@@ -119,6 +119,7 @@ <h2>Photos Attendees</h2>
 
         <h2>Past Events</h2>
         <ul>
+          <li><a href="../bpfconf2023/bpfconf2024.html">bpfconf 2024</a></li>
           <li><a href="../bpfconf2023/bpfconf2023.html">bpfconf 2023</a></li>
           <li><a href="../bpfconf2022/bpfconf2022.html">bpfconf 2022</a></li>
           <li>bpfconf 2020/2021 (cancelled due to COVID restrictions)</li>
diff --git a/bpfconf2025/bpfconf2025.html b/bpfconf2025/bpfconf2025.html
new file mode 100644
index 0000000..c0ad43f
--- /dev/null
+++ b/bpfconf2025/bpfconf2025.html
@@ -0,0 +1,256 @@
+<!doctype html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8">
+  <base id="app-base" href="/bpfconf2025/">
+  <script>
+    // If opened via file://, make relative paths resolve from this folder
+    if (location.protocol === 'file:') {
+      document.getElementById('app-base').setAttribute('href', './');
+    }
+  </script>
+  <meta name="viewport" content="width=device-width, initial-scale=1" />
+  <title>Linux Kernel Developers' bpfconf 2025</title>
+  <style>
+    /* Base */
+    :root { --maxw: 900px; --muted:#666; --ring:#0ea5e9; --border:#e5e7eb; }
+    html, body { height: 100%; }
+    body {
+      margin: 0;
+      color: #111;
+      background: #fff;
+      font: 15px/1.55 system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Helvetica Neue", Arial, "Noto Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji", sans-serif;
+      -webkit-font-smoothing: antialiased;
+      text-rendering: optimizeLegibility;
+    }
+    /* Center the main table and make it responsive */
+    body > table {
+      width: min(100%, var(--maxw));
+      margin: 0 auto;
+      border-collapse: collapse;
+    }
+    img { max-width: 100%; height: auto; }
+
+    /* Headings */
+    h1 { margin: 10px 0 0; line-height: 1.2; }
+    h2 {
+      margin-top: 28px;
+      padding-left: 10px;
+      border-left: 3px solid #111;
+      line-height: 1.3;
+    }
+
+    /* Links */
+    a { color: #0b63ce; text-decoration: underline; text-underline-offset: 2px; }
+    a:hover { text-decoration-thickness: 2px; }
+    a:focus-visible {
+      outline: 2px solid var(--ring);
+      outline-offset: 2px;
+      border-radius: 4px;
+    }
+
+    .collapsible {
+      background: #fff;
+      cursor: pointer;
+      padding: 10px;
+      width: 100%;
+      border: 0;
+      text-align: left;
+      color: #000;
+      text-decoration: none;
+      font: inherit;
+    }
+    .content { padding: 0 18px; display: none; overflow: hidden; }
+    .collapsible:after { content: "\02795"; font-size: 13px; color: #000; float: right; margin-left: 5px; }
+    .active:after { content: "\2796"; }
+    .speaker { font-size: 11px; color: grey; display: inline; margin-left: 10px; }
+
+    /* Tables */
+    table[border="1"] {
+      width: 100%;
+      border-collapse: collapse;
+      border: 1px solid var(--border);
+    }
+    table[border="1"] th,
+    table[border="1"] td {
+      border: 1px solid var(--border);
+      padding: 6px 8px;
+      vertical-align: top;
+    }
+    table[border="1"] th {
+      background: #f8fafc;
+      text-align: left;
+    }
+    table[border="0"] td { padding: 3px 0; } 
+
+    /* --- Attendee photos --- */
+    .photos {
+      display: grid;
+      grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
+      gap: 12px;
+      margin: 16px 0 4px;
+    }
+    .photos a {
+      display: block;
+      border-radius: 10px;
+      overflow: hidden;
+      box-shadow: 0 1px 6px rgba(0,0,0,0.08);
+      transition: transform 0.12s ease, box-shadow 0.12s ease;
+      background: #fafafa;
+    }
+    .photos a:hover {
+      transform: translateY(-2px);
+      box-shadow: 0 6px 18px rgba(0,0,0,0.12);
+    }
+    .photos img {
+      width: 100%;
+      height: 220px;          /* uniform tile height */
+      object-fit: cover;      /* tidy composition across ratios */
+      display: block;
+    }
+    .photos-caption {
+      font-size: 12px;
+      color: var(--muted);
+      margin-top: 6px;
+    }
+    @media (max-width: 520px) {
+      .photos img { height: 180px; }
+      h1 { font-size: 22px; }
+    }
+
+    /* Tiny quality-of-life tweaks */
+    hr { border: 0; height: 1px; background: var(--border); }
+    .muted { color: var(--muted); }
+
+    /* Print-friendly */
+    @media print {
+      a { color: #000; text-decoration: none; }
+      .photos a { box-shadow: none; transform: none; }
+    }
+  </style>
+</head>
+
+<body bgcolor="#ffffff">
+  <table border="0" width="850">
+    <tbody>
+      <tr><td>&nbsp;&nbsp;&nbsp;&nbsp;</td></tr>
+      <tr>
+        <td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
+        <td valign="top" align="center" colspan="2">
+          <h1>Linux Kernel Developers' bpfconf 2025</h1><br>
+          <img src="bpfconf2025_material/bpf_logo.png" width="180" alt="BPF logo" loading="lazy">
+        </td>
+      </tr>
+
+      <tr><td><br></td></tr>
+      <tr><td><br></td></tr>
+
+      <tr>
+        <td></td>
+        <td>
+          bpfconf is an invitation-only technical workshop run by the Linux
+          community in order to bring BPF core developers together, to discuss
+          new ideas and to work out improvements to the BPF subsystem
+          that will make their way into future mainline kernels and into
+          the BPF compiler backends.
+          <p>
+            The conference is purposely kept small with focus on discussion rather
+            than just presentation. Along with the LPC's
+            <a href="https://lore.kernel.org/bpf/63792467-9be4-0d84-8fd1-93f63bcee3d9@iogearbox.net/" target="_blank" rel="noopener">BPF Track</a>
+            which is organized and run by the same community, the goal is to allow
+            developers to meet face to face twice per year to exchange and discuss
+            ongoing developments in the BPF ecosystem.
+          </p>
+          <p>
+            The 2025 bpfconf edition is a three-days conference which is part of the
+            <a href="https://events.linuxfoundation.org/lsfmm/" target="_blank" rel="noopener">LSF/MM/BPF summit</a>. It is therefore
+            also open to all LSF/MM/BPF attendees.
+          </p>
+
+          <h2>Discussion Topics</h2>
+
+          <p>The following discussion topics have been brought up at this
+            year's bpfconf. In each slot below, there is a short discussion
+            topic with a link to the corresponding slides in case slides have
+            been used as a discussion starter.
+          </p>
+          <p>
+            LWN coverage of the BPF track from Daroc Alden can be found
+            <a href="https://lwn.net/Articles/lsfmmbpf2025/" target="_blank" rel="noopener">here</a>.
+            <!-- Raw (and incomplete) notes for some of the sessions have been collected by participants
+            <a href="bpfconf2024_material/LSFMMBPF_2024_raw_notes.pdf" target="_blank" rel="noopener">here</a>. -->
+          </p>
+
+          <table border="1" cellpadding="3" cellspacing="1">
+            <tr><th width="250">Name</th><th width="550">Topic</th></tr>
+            <tr><td>Anton Protopopov</td><td><a href="bpfconf2025_material/2025.03_ Indirect Calls (LSF_MM_BPF 2025, Canada).pdf" target="_blank" rel="noopener">BPF Indirect calls</a></td></tr>
+            <tr><td>Anton Protopopov</td><td><a href="bpfconf2024_material/2025.03_ Hashtab & Friends (LSF_MM_BPF 2025, Canada).pdf" target="_blank" rel="noopener">Hashtab Memory Optimizations & a few other topics</a></td></tr>
+            <tr><td>Anton Protopopo</td><td><a href="bpfconf2025_material/2025.03_ Static Keys (LSF_MM_BPF, Canada).pdf" target="_blank" rel="noopener">Update on Static Keys</a></td></tr>
+            <tr><td>Alexei Starovoitov</td><td><a href="bpfconf2025_material/Beyond 1M instructions.pdf" target="_blank" rel="noopener">Beyond 1M BPF instructions</a></td></tr>
+            <tr><td>Ihor Solodrai</td><td><a href="bpfconf2025_material/BPF CI - LSF_MM 2025.pdf" target="_blank" rel="noopener">BPF CI updates</a></td></tr>
+            <tr><td>Martin Lau</td><td><a href="bpfconf2025_material/bpf netdev perf and api improvements - Martin Lau.pdf" target="_blank" rel="noopener">An upgrade on some of the existing BPF/netdev implementations</a></td></tr>
+            <tr><td>Paul E. McKenney</td><td><a href="bpfconf2025_material/hornet-lsm.pdf" target="_blank" rel="noopener">eBPF Code Signing and Gatekeeper Introducing Hornet LSM</a></td></tr>
+            <tr><td>John Fastabend, Mahé Tardy</td><td><a href="bpfconf2025_material/kfunc for TCP rst.pdf" target="_blank" rel="noopener">kfunc for TCP reset</a></td></tr>
+            <tr><td>Kumar Kartikeya Dwivedi</td><td><a href="bpfconf2025_material/Locking in BPF - LSFMMBPF 2025.pdf" target="_blank" rel="noopener">Locking in BPF</a></td></tr>
+            <tr><td>Eduard Zingerman</td><td><a href="bpfconf2025_material/lsfmm25-kfuncs-inlining-eduard-zingerman.pdf" target="_blank" rel="noopener">kfuncs inlining in BPF programs</a></td></tr>
+            <tr><td>Daniel Borkman</td><td><a href="bpfconf2025_material/lsfmmbpf_2025_netkit_borkmann.pdf" target="_blank" rel="noopener">netkit for VM workloads</a></td></tr>
+            <tr><td>Maxwell Bland</td><td><a href="bpfconf2024_material/BPF-NX+CFI.pdf" target="_blank" rel="noopener">BPF-NX+CFI</a></td></tr>
+            <tr><td>Kumar Kartikeya, Dwivedi Rishabh, Iyer Sanidhya Kashyap</td><td><a href="bpfconf2025_material/Nous - LSFMMBPF 2025.pdf" target="_blank" rel="noopener">Efficient IO-Intensive us-scale Applications using eBPF</a></td></tr>
+            <tr><td>Cong Wang</td><td><a href="bpfconf2025_material/Optimizing sk_msg for Socket Map.pdf" target="_blank" rel="noopener">Optimizing sk_msg for Socket Map</a></td></tr>
+            <tr><td>Alexei Starovoitov</td><td><a href="bpfconf2025_material/Reentrant kmalloc.pdf" target="_blank" rel="noopener">Reentrant kmalloc for any context</a></td></tr>
+            <tr><td>Santosh Nagarakatte</td><td><a href="bpfconf2025_material/Santosh Nagarakatte-LSFMMBPF-2025.pdf" target="_blank" rel="noopener">Formal Verification of the eBPF Verifier with Agni</a></td></tr>
+            <tr><td>John Fastabend, Kornilios Kourtis, Mahé Tardy</td><td><a href="bpfconf2025_material/Splicing BPF maps  to the NIC.pdf" target="_blank" rel="noopener">Splicing BPF maps to the NIC</a></td></tr>
+            <tr><td>Cong Wang</td><td><a href="bpfconf2025_material/Two-Phase eBPF Program Signing.pdf" target="_blank" rel="noopener">Two-Phase eBPF Program Signing</a></td></tr>
+            <tr><td>Mahé Tardy</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">Adding a BPF kfunc for TCP Reset/FIN</a></td></tr>
+            <tr><td>Srinivas Narayana</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">Verified path exploration for the eBPF verifier</a></td></tr>
+            <tr><td>Alan Jowett</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">Brief discussion of fuzzing the Prevail verifier</a></td></tr>
+            <tr><td>Emil Tsalapatis</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">sched_ext and BPF arenas</a></td></tr>
+            <tr><td>Amery Hung</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">uptr and kv store</a></td></tr>
+            <tr><td>Song Liu</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">fanotify-bpf: Use BPF programs to filter fanotify events in kernel space</a></td></tr>
+            <tr><td>John Fastabend</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">BPF Windows Support</a></td></tr>
+            <tr><td>Song Liu, Thierry Treyer</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">BTF extension for inlined kernel functions</a></td></tr>
+            <tr><td>Arnaldo Carvalho de Melo</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">pahole + BTF update and "BTF augmenter"</a></td></tr>
+            <tr><td>Yonghong Song</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">Uninitialized Variable In BPF Programs</a></td></tr>
+            <tr><td>Jose E. Marchesi, David Faust</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">Compiled BPF in general and GCC BPF in particular</a></td></tr>
+            <tr><td>Daniel Xu</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">Modular BPF verifier</a></td></tr>
+            <tr><td>Shung-Hsi Yu</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">BPF in Stable Kernels</a></td></tr>
+            <tr><td>Blaise Boscaccy & Cong Wang</td><td><a href="bpfconf2025_material/" target="_blank" rel="noopener">eBPF Code signing and Gatekeeper</a></td></tr>
+          </table>
+
+          <h2>Conference Info</h2>
+          <table border="0" cellpadding="3" cellspacing="1" width="100%">
+            <tr><td><b>Location:</b></td><td>Montreal, Canada, part of LSF/MM/BPF</td></tr>
+            <tr><td><b>Committee:</b></td><td>Daniel Borkmann, Martin Lau</td></tr>
+            <tr><td><b>Date:</b></td><td>March 24 - 26, 2025</td></tr>
+            <tr><td></td><td><a href="https://docs.google.com/spreadsheets/d/1PgjzaPOnIHgRIfqgwDNiftY5Xr6aU3NLWtDs7zFoIvc/edit?gid=1852749899#gid=1852749899" target="_blank" rel="noopener">Schedule</a></td></tr>
+            <tr><td><b>Attendees</b> (by invitation only)<b>:</b></td><td></td></tr>
+          </table>
+
+          <h2>Photos Attendees</h2>
+          <div class="photos">
+            <a href="bpfconf2025_material/bpfconf2025_1.jpg" target="_blank" rel="noopener">
+              <img src="bpfconf2025_material/bpfconf2025_1.jpg" alt="Attendees group photo 1" loading="lazy">
+            </a>
+            <a href="bpfconf2025_material/bpfconf2025_2.jpg" target="_blank" rel="noopener">
+              <img src="bpfconf2025_material/bpfconf2025_2.jpg" alt="Attendees group photo 2" loading="lazy">
+            </a>
+            <a href="bpfconf2025_material/bpfconf2025_3.jpg" target="_blank" rel="noopener">
+              <img src="bpfconf2025_material/bpfconf2025_3.jpg" alt="Attendees group photo 3" loading="lazy">
+            </a>
+          </div>
+          <div class="photos-caption">(Photos by Daniel Borkmann)</div>
+
+          <h2>Past Events</h2>
+          <ul>
+            <li><a href="../bpfconf2024/bpfconf2024.html">bpfconf 2023</a></li>
+            <li><a href="../bpfconf2023/bpfconf2023.html">bpfconf 2023</a></li>
+            <li><a href="../bpfconf2022/bpfconf2022.html">bpfconf 2022</a></li>
+            <li>bpfconf 2020/2021 (cancelled due to COVID restrictions)</li>
+            <li><a href="../bpfconf2019/bpfconf2019.html">bpfconf 2019</a></li>
+          </ul>
+        </td>
+      </tr>
+    </tbody>
+  </table>
+</body>
+</html>
diff --git a/bpfconf2025/bpfconf2025_material/2025.03_ Hashtab & Friends (LSF_MM_BPF 2025, Canada).pdf b/bpfconf2025/bpfconf2025_material/2025.03_ Hashtab & Friends (LSF_MM_BPF 2025, Canada).pdf
new file mode 100644
index 0000000..ae03ff4
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/2025.03_ Hashtab & Friends (LSF_MM_BPF 2025, Canada).pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/2025.03_ Indirect Calls (LSF_MM_BPF 2025, Canada).pdf b/bpfconf2025/bpfconf2025_material/2025.03_ Indirect Calls (LSF_MM_BPF 2025, Canada).pdf
new file mode 100644
index 0000000..f948bd8
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/2025.03_ Indirect Calls (LSF_MM_BPF 2025, Canada).pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/2025.03_ Static Keys (LSF_MM_BPF, Canada).pdf b/bpfconf2025/bpfconf2025_material/2025.03_ Static Keys (LSF_MM_BPF, Canada).pdf
new file mode 100644
index 0000000..0826e14
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/2025.03_ Static Keys (LSF_MM_BPF, Canada).pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/BPF CI - LSF_MM 2025.pdf b/bpfconf2025/bpfconf2025_material/BPF CI - LSF_MM 2025.pdf
new file mode 100644
index 0000000..cd5404e
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/BPF CI - LSF_MM 2025.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/Beyond 1M instructions.pdf b/bpfconf2025/bpfconf2025_material/Beyond 1M instructions.pdf
new file mode 100644
index 0000000..b813b58
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/Beyond 1M instructions.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/Locking in BPF - LSFMMBPF 2025.pdf b/bpfconf2025/bpfconf2025_material/Locking in BPF - LSFMMBPF 2025.pdf
new file mode 100644
index 0000000..ad0a049
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/Locking in BPF - LSFMMBPF 2025.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/Nous - LSFMMBPF 2025.pdf b/bpfconf2025/bpfconf2025_material/Nous - LSFMMBPF 2025.pdf
new file mode 100644
index 0000000..bde87cc
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/Nous - LSFMMBPF 2025.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/Optimizing sk_msg for Socket Map.pdf b/bpfconf2025/bpfconf2025_material/Optimizing sk_msg for Socket Map.pdf
new file mode 100644
index 0000000..2236f05
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/Optimizing sk_msg for Socket Map.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/Reentrant kmalloc.pdf b/bpfconf2025/bpfconf2025_material/Reentrant kmalloc.pdf
new file mode 100644
index 0000000..1254ec9
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/Reentrant kmalloc.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/Santosh Nagarakatte-LSFMMBPF-2025.pdf b/bpfconf2025/bpfconf2025_material/Santosh Nagarakatte-LSFMMBPF-2025.pdf
new file mode 100644
index 0000000..2894138
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/Santosh Nagarakatte-LSFMMBPF-2025.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/Splicing BPF maps  to the NIC.pdf b/bpfconf2025/bpfconf2025_material/Splicing BPF maps  to the NIC.pdf
new file mode 100644
index 0000000..95ef668
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/Splicing BPF maps  to the NIC.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/Two-Phase eBPF Program Signing.pdf b/bpfconf2025/bpfconf2025_material/Two-Phase eBPF Program Signing.pdf
new file mode 100644
index 0000000..8c6b9b3
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/Two-Phase eBPF Program Signing.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/bpf netdev perf and api improvements - Martin Lau.pdf b/bpfconf2025/bpfconf2025_material/bpf netdev perf and api improvements - Martin Lau.pdf
new file mode 100644
index 0000000..e6cfd1b
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/bpf netdev perf and api improvements - Martin Lau.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/bpf_logo.png b/bpfconf2025/bpfconf2025_material/bpf_logo.png
new file mode 100644
index 0000000..bea8c36
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/bpf_logo.png differ
diff --git a/bpfconf2025/bpfconf2025_material/bpfconf2025_1.jpg b/bpfconf2025/bpfconf2025_material/bpfconf2025_1.jpg
new file mode 100644
index 0000000..d90be10
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/bpfconf2025_1.jpg differ
diff --git a/bpfconf2025/bpfconf2025_material/bpfconf2025_2.jpg b/bpfconf2025/bpfconf2025_material/bpfconf2025_2.jpg
new file mode 100644
index 0000000..8723d11
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/bpfconf2025_2.jpg differ
diff --git a/bpfconf2025/bpfconf2025_material/bpfconf2025_3.jpg b/bpfconf2025/bpfconf2025_material/bpfconf2025_3.jpg
new file mode 100644
index 0000000..e6a1fb3
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/bpfconf2025_3.jpg differ
diff --git a/bpfconf2025/bpfconf2025_material/hornet-lsm.pdf b/bpfconf2025/bpfconf2025_material/hornet-lsm.pdf
new file mode 100644
index 0000000..e08dcd6
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/hornet-lsm.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/kfunc for TCP rst.pdf b/bpfconf2025/bpfconf2025_material/kfunc for TCP rst.pdf
new file mode 100644
index 0000000..c47c569
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/kfunc for TCP rst.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/lsfmm25-kfuncs-inlining-eduard-zingerman.pdf b/bpfconf2025/bpfconf2025_material/lsfmm25-kfuncs-inlining-eduard-zingerman.pdf
new file mode 100644
index 0000000..3dfd815
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/lsfmm25-kfuncs-inlining-eduard-zingerman.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/lsfmmbpf2025-v4.org b/bpfconf2025/bpfconf2025_material/lsfmmbpf2025-v4.org
new file mode 100644
index 0000000..920ad52
--- /dev/null
+++ b/bpfconf2025/bpfconf2025_material/lsfmmbpf2025-v4.org
@@ -0,0 +1,426 @@
+Compiled BPF - LSFMMBPF 2025
+
+* Update on the port
+** Distribution
+
+- We added BPF support to cross-binutils and cross-gcc in Fedora.
+  That shoul propagate to centos, RHEL, etc.
+
+- Now that we got users, we get feedback.
+
+- Being in distros is helping a lot.
+
+- We had plans for speial maintenance branches in GCC, but these
+  haven't materialized.
+
+** A few improvements in the GCC BPF testsuite.
+
+To cope better with the limitations of BPF.  Not suprisingly along
+with the nvptx port.
+
+: BPF, nvptx: Standardize on 'sorry, unimplemented: dynamic stack allocation not supported'
+: BPF doesn't actually support effective-target 'exceptions' [PR118772]
+
+** stdint.h now wraps the host header in compiler hosted mode
+
+GCC now installs a wrapping stdint.h in hosted mode, which is the
+default.  This alleviates the symptoms of the inclusion of host header
+files in BPF programs.
+
+-f[no-]hosted
+
+: bpf: install a wrapping stdint.h for bpf-none-unknown targets
+
+** CO-RE relocs are now correct for non-pointer struct variables
+
+GCC now generates correct CO-RE strings for non-pointer struct
+variables.  This was brought to our attention during LPC 2024.
+
+  : set index entry for a VAR_DECL in CO-RE relocs
+
+** Status of selftests
+
+PTR ->TYPETAG(KPTR) -> STRUCT
+
+VS
+
+TYPETAG(KPTR) -> PTR -> STRUCT
+
+bpf-next from a few months ago:
+
+: no tags: 410/2534 PASSED, 93 SKIPPED, 188 FAILED
+:    tags: 485/3695 PASSED, 92 SKIPPED, 113 FAILED
+
+curent bpf-next with tags:
+:        494/3748 PASSED, 92 SKIPPED, 113 FAILED
+
+kptr type tag order is problematic
+: $ grep "R1 has no valid kptr" bpf_selftests.2025-03-14_19-33-24.log | wc -l
+: 168
+
+** preserve_access_index in lhs fixed
+
+We fixed a problem in the implementation of preserve_access_index
+related to the propagation of the attribute in accesses.  But this is
+not the end of the problems as we shall see later in the discussion.
+
+: bpf: calls do not promote attr access_index on lhs
+
+** GSOC 2025 project proposal: Tooling for running BPF GCC tests on a live kernel
+
+We have published a project called "Tooling for running BPF GCC tests
+on a live kernel" for GSOC 2025:
+
+1. Write a test tool (probably within the contrib/ directory in the
+   GCC sources) to launch a suitable kernel in some sort of virtual
+   environment (like qemu) and load and execute a given BPF program
+   object. This is similar to what the kernel BPF sefltests
+   infrastructure does. This also requires to write some glue
+   infrastructure for the BPF tests, in order to communicate the
+   result of execution of tests etc.
+
+2. Once we have the test tool, the next step will be to integrate it
+   in the Dejagnu based testing infrastructure in GCC.
+
+3. Finally, using the integrated infrastructure, a new testsuite for
+   the BPF target shall be added to the GCC testsuite, containing an
+   initial set of well choosen tests.
+
+Now waiting for student proposals.  Deadline is April 8.
+
+virtme-ng (andrea righi) may be useful for this.
+
+** BTF decl and type tags _still_ under review upstream
+
+We submitted a new version of the BTF decl tags and type tags patch
+series:
+https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675241.html
+
+Since we are now in Stage 4 for GCC 15, we had to tag the submission
+as STAGE1.  This means that the series won't be likely reviewed until
+Stage 1, which is estimated for end of April/beginning of May.  Good
+news is that this patch series implements the suggestions made by
+global maintainers, so it must not be controversial.
+
+#+BEGIN_EXAMPLE
+int __ttag2 __ttag1 x;
+int         __ttag1 y;
+
+TAG_variable         +->  TAG_base_type       +->  TAG_annotation
+  AT_name: "x"       |      AT_name: "int"    |      AT_name: "btf_type_tag"
+  AT_type:   --------+      AT_annotation  ---+      AT_const_value: "tag2"
+                                                     AT_annotation -----------+
+                                                                              |
+TAG_variable         +->  TAG_base_type            +--------------------------+
+  AT_name: "y"       |      AT_name: "int"         |
+  AT_type:  ---------+      AT_annotation ---------+-> TAG_annotation
+                                                         AT_name: "btf_type_tag"
+                                                         AT_const_value: "tag1"
+#+END_EXAMPLE
+
+
+This version implements the new DWARF format that we agreed on in LPC:
+
+- DW_TAG_annotation
+- DW_AT_annotation
+
+types/decls with tags have an added AT_annotation pointing to a (chain
+of) TAG_annotation DIEs.  Chain formed by additional AT_annotation
+entries on the TAG_annotation DIEs.
+
+The clang side is waiting for GCC to consolidate before implementing
+the same.
+
+** We wrote a CO-RE dumper pk-bpfcoredump
+
+This uses the BPF, CO-RE and BTF pickles of GNU poke.
+Installs with
+
+Human-readable BPF CO-RE relocation dumps for e.g. debugging compiler.
+
+Concise mode: one line per reloc:
+- relo kind, access string, root type, insn offset
+ 
+
+#+BEGIN_EXAMPLE
+$ pk-bpfcoredump test_tcp_custom_syncookie.bpf.o
+
+CO-RE RELOCATION RECORDS FOR [tc]:  148 total
+field:byte_offset "0:15" struct __sk_buff (id=2) @112U#B
+field:byte_offset "0:16" struct __sk_buff (id=2) @136U#B
+field:byte_offset "0:15" struct __sk_buff (id=2) @152U#B
+field:byte_offset "0:2" struct ethhdr (id=19) @192U#B
+field:byte_offset "0:0" struct iphdr (id=24) @256U#B
+field:byte_offset "0:1" struct iphdr (id=24) @280U#B
+field:byte_offset "0:7" struct iphdr (id=24) @320U#B
+...
+field:byte_offset "0:0:2:3" struct in6_addr (id=34) @5440U#B
+...
+#+END_EXAMPLE
+
+
+Verbose mode (-v) adds:
+- print instruction to be patched
+- break down each access for each reloc
+- ends with complete type chain for leaf access:
+ 
+
+#+BEGIN_EXAMPLE
+R field:byte_offset "0:0:2:3"
+    @5440U#B
+    ldxw	%r0, [%r3+12]
+  0: struct in6_addr (id=34)
+  0:   struct in6_addr (id=34).in6_u
+  2:     union <anon> (id=35).u6_addr32
+  3:       array <anon> (id=38) <array access at index=3>
+    typedef __be32 (id=28) -> typedef __u32 (id=3) -> int unsigned int (id=4)
+   
+#+END_EXAMPLE
+
+
+Available in GNU poke master branch.
+
+** Some WIP
+
+- may_goto support in the opcodes/assembler/disassembler
+- memory ordering aware atomic built-ins in GCC
+- preserve_static_offset
+- bpf_fastcall
+  - getting less optional
+
+QUESTION: is compiler support necessary for may_goto?  It is no clear
+          to us.
+answer: no
+QUESTION: any recommended priority?
+1. tags by far
+2. maygoto for inline asm
+2. fastcall
+3. else
+
+FEATURE_MAY_GOTO or so
+
+QUESTION: anything else that is missing?
+
+bpf program address_space
+need to add whole attribute with handling in backend
+
+
+* Discussion points
+** must-pragmas in compiler
+
+- Starting with a "musttail" attribute, which is being added right now
+  to GCC.  There are some problems to converge with clang. GCC PR
+  PR119376.
+
+- GCC maintainers do not oppose to add additional must-pragmas
+  (attributes, options, etc) for the benefit of BPF and other users.
+  Suggestions welcome.
+
+** preserve_access_index and lexical nesting
+
+Clang seems to propagate this attribute into lexically nested struct
+definitions.
+
+#+BEGIN_EXAMPLE
+struct other
+{
+  char c;
+  int i;
+};
+
+struct outer_attr
+{
+  struct other *other;
+
+  struct
+  {
+    int i1;
+    int i2;
+  } attribute();
+
+} __attribute__((preserve_access_index));
+
+__attribute__((section("foosec")))
+void foo (struct outer_attr *o)
+{
+  /* CO-RE relocations:
+     field_byte_offset "0:1" struct outer_attr   @ r2=*(u64*)(r1+8)
+     field_byte_offset "0:1" struct inner_noattr @ *(u32*)(r2+4)=r3 */
+  o->inner->i2 = 3;
+
+  /* CO-RE relocations:
+     field_byte_offset "0:0" struct outer_attr   @ r1=*(u64*)(r1+0) */
+  o->other->i = 5;
+}
+
+$ pk-bpfcoredump coreprop_simple.o.clang
+
+CO-RE RELOCATION RECORDS FOR [foosec]:  3 total
+field:byte_offset "0:1" struct outer_attr (id=2) @0U#B
+field:byte_offset "0:1" struct inner_noattr (id=7) @16U#B
+field:byte_offset "0:0" struct outer_attr (id=2) @24U#B
+#+END_EXAMPLE
+
+
+PROBLEM: GCC and clang behave differently.
+
+PROBLEM: The C language doesn't even have the concept of nested types,
+         even if they look like nested lexicographically (C++ does).
+         This means that we would need to hook in the parser to
+         implement this properly.  We have played with locations, it
+         works most of the time, but corner cases can't be covered.
+
+PROBLEM: The precise intended effect of the preserve_access_index
+         _attribute_ is not documented.
+
+QUESTION: Is this something that is relied on, or in practice
+          preserve_access_index is always applied to all struct types
+          either explicitly or via clang's #pragma attribute push?
+          What behavior we want to settle on in the compilers?
+
+** Possible divergences in datasec entry sizes in compilers
+
+libbpf uses the compiler-reported size in datasec entries for maps
+(structs only):
+
+: BTF_KIND_DATASEC
+:   name -> GCC/clang generate .data, whatever name.
+:   size -> GCC/clang generate 0. BPF loader fills it in.
+:   BTF_Var_SecInfo[]
+:     type    -> GCC/clang generate a type.
+:     offset  -> GCC/clang generate offset.
+:     size    -> GCC/clang generate:
+:                - The size if the type has static size.
+:                - 1 if the type is void.
+:                - Otherwise 0.
+
+For extern entries size should be 0.
+
+POTENTIAL PROBLEM: different optimizing compilers and optimizations
+                   levels can lead to divergences in known/unknown
+                   size?  We think not.
+
+** What is the status of the removal of #pragma attribute push from btftool?
+
+The support for arbitrary __attribute__ encoding is now in the kernel.
+
+** runtime BTF and debug BTF
+
+- One is needed by BPF programs.
+- The other by the kernel.
+
+We could have levels, like -g[0-3]:
+
+:  -gbtf, -bbtf1 => Emit .BTF (runtime)
+:  -gbtf2        => Emit .BTF.debug also
+
+Same format, different sections, different contents.
+
+This way pahole will have visibility of both sets of function
+signatures: pre-optimized and post-optimized.  Suggested by pahole
+co-maintainer.
+
+** Compiler optimizations can change function signatures
+e.g.:
+- Remove unused return values (replace with void)
+- Remove unused parameters
+- Replace aggregate parameters with set of other parameters
+  (e.g. only pass relevant fields of passed-by-value struct)
+
+PROBLEM: both GCC and clang currently emit pre-optimized signatures.
+         This means compiler-emitted BTF is NOT accurately reflecting
+         what is in compiled object.
+         (GCC: patch WIP)
+
+PROBLEM: experimental gcc patch causes new failures in testsuite:
+
+in tailcall_bpf2bpf2.c
+
+#+BEGIN_EXAMPLE
+static __noinline
+int subprog_tail(struct __sk_buff *skb)
+{
+        if (load_byte(skb, 0))
+                bpf_tail_call_static(skb, &jmp_table, 1);
+        else
+                bpf_tail_call_static(skb, &jmp_table, 0);
+        return 1;
+}
+
+int count = 0;
+
+SEC("tc")
+int classifier_0(struct __sk_buff *skb)
+{
+        count++;
+        return subprog_tail(skb);
+}
+#+END_EXAMPLE
+
+Optimizations removed return value of subprog_tail since
+it always returns 1, moved that to return of classifier_0
+
+libbpf: failed to load object 'tailcall_bpf2bpf.bpf.o'
+tail_call is only allowed in functions that return 'int'
+
+** Reflecting function signature changes in DWARF and BTF
+
+Pahole needs to determine whether a signature changed for an optimized
+function (both return value and/or function arguments) and add
+annotations to the BTF it emits, somehow.  Then the BPF based tracing
+infrastructure can use these annotations.
+
+*** DWARF
+
+Right now we convey DWARF to pahole and it generates the BTF.
+Therefore we need to convey the signature change information in DWARF.
+
+QUESTION: Is this the only reason why we need the signature change
+          reflected in DWARF?  Because...
+
+PROBLEM: DWARF doesn't support this.
+
+Proposal, originally from Jakub Jelinek:
+
+Have the signature change of some given function represented in DWARF
+using a DW_TAG_artificial "container" with an inlined subroutine
+reflecting the original signature. Something like:
+
+: foo.original (int a, int b) { foo (1, { a, b }); }
+
+The signature change would be described in the formal parameters of
+the DW_TAG_inlined_subroutine.
+
+*** BTF
+
+If optimizations change func return/args, then suffixed
+version of the function is created and used, e.g.:
+- if IPA-SRA pass changes func return/args of "foo", creates suffixed
+  version of function named like "foo.isra"
+  + the renamed function is what's really in the object
+
+QUESTION: How should we handle this in BTF?
+          Options:
+  1. Modify FUNC_PROTO corresponding to "foo":
+     FUNC("foo") -> FUNC_PROTO (optimized signature)
+
+  2. Since only "foo.isra" actually ends up in compiled object, only
+     represent it via:
+     FUNC("foo.isra") -> FUNC_PROTO (optimized signature)
+
+  3. Represent both?
+     FUNC("foo") -> FUNC_PROTO(_un_-optimized signature)
+     FUNC("foo.isra") -> FUNC_PROTO (optimized signature)
+
+
+PROBLEM: clang does not make name-suffixes and in general (if it did)
+  they would not share the same name as gcc suffixes.
+
+PROBLEM: There may be cases even in GCC where optimizations change the
+  signature but do not create a suffixed variant.
+  For that it seems the only option is:
+    FUNC("foo") -> FUNC_PROTO(optimized signature)
+
+QUESTION: What is the exact information we need from the function
+  signature changes?
+
diff --git a/bpfconf2025/bpfconf2025_material/lsfmmbpf_2025_netkit_borkmann.docx b/bpfconf2025/bpfconf2025_material/lsfmmbpf_2025_netkit_borkmann.docx
new file mode 100644
index 0000000..f6feb48
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/lsfmmbpf_2025_netkit_borkmann.docx differ
diff --git a/bpfconf2025/bpfconf2025_material/lsfmmbpf_2025_netkit_borkmann.pdf b/bpfconf2025/bpfconf2025_material/lsfmmbpf_2025_netkit_borkmann.pdf
new file mode 100644
index 0000000..773e4e2
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/lsfmmbpf_2025_netkit_borkmann.pdf differ
diff --git a/bpfconf2025/bpfconf2025_material/verified-path-exploration-Srinivas-Narayana.pdf b/bpfconf2025/bpfconf2025_material/verified-path-exploration-Srinivas-Narayana.pdf
new file mode 100644
index 0000000..adac5d2
Binary files /dev/null and b/bpfconf2025/bpfconf2025_material/verified-path-exploration-Srinivas-Narayana.pdf differ
diff --git a/netlify.toml b/netlify.toml
index 6d432a0..a039302 100644
--- a/netlify.toml
+++ b/netlify.toml
@@ -4,6 +4,6 @@
 
 [[redirects]]
   from = "/"
-  to = "/bpfconf2024/bpfconf2024.html"
+  to = "/bpfconf2025/bpfconf2025.html"
   status = 200
   force = true
