From 2bf86172bdf25317cad5f950b9c8c6bfdf6e9dbf Mon Sep 17 00:00:00 2001
From: lucia <11452490+luciafu@user.noreply.gitee.com>
Date: Wed, 21 Feb 2024 13:24:48 +0000
Subject: [PATCH] update news/README.md.

Signed-off-by: lucia <11452490+luciafu@user.noreply.gitee.com>
---
 news/README.md | 632 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 632 insertions(+)

diff --git a/news/README.md b/news/README.md
index 4447ae3..94e9c1b 100644
--- a/news/README.md
+++ b/news/README.md
@@ -6,6 +6,638 @@
 * [2023 年 - 上半年](2023-1st-half.md)
 * [2023 年 - 下半年](2023-2nd-half.md)
 
+## 20240221：第 79 期
+
+### 内核动态
+
+#### 进程调度
+
+**[v1: sched/clock: Make local_clock() notrace](http://lore.kernel.org/lkml/20240220202002.38fec245@gandalf.local.home/)**
+
+> The "perf" clock in /sys/kernel/tracing/trace_clock enables local_clock(),
+> where on machines that have CONFIG_HAVE_UNSTABLE_SCHED_CLOCK set is a
+> normal function. This function can be traced.
+>
+
+**[v2: sched: cpufreq: Rename map_util_perf to sugov_apply_dvfs_headroom](http://lore.kernel.org/lkml/20240220180820.2597581-1-qyousef@layalina.io/)**
+
+> We are providing headroom for the utilization to grow until the next
+> decision point to pick the next frequency. Give the function a better
+> name and give it some documentation. It is not really mapping anything.
+>
+
+**[v1: sched/core: introduce CPUTIME_FORCEIDLE_TASK](http://lore.kernel.org/lkml/20240219084134.10673-1-CruzZhao@linux.alibaba.com/)**
+
+> As core sched uses rq_clock() as clock source to account forceidle
+> time, irq time will be accounted into forceidle time. However, in
+> some scenarios, forceidle sum will be much larger than exec runtime,
+>
+
+**[v1: net: sched: Annotate struct tc_pedit with __counted_by](http://lore.kernel.org/lkml/20240216232744.work.514-kees@kernel.org/)**
+
+> Prepare for the coming implementation by GCC and Clang of the __counted_by
+> attribute. Flexible array members annotated with __counted_by can have
+> their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
+> (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
+> functions).
+>
+
+#### 安全增强
+
+**[v1: refcount: Annotated intentional signed integer wrap-around](http://lore.kernel.org/linux-hardening/20240221051634.work.287-kees@kernel.org/)**
+
+> Mark the various refcount_t functions with __signed_wrap, as we depend
+> on the wrapping behavior to detect the overflow and perform saturation.
+> Silences warnings seen with the LKDTM REFCOUNT_* tests:
+>
+
+**[v1: arm64: syscall: Direct PRNG kstack randomization](http://lore.kernel.org/linux-hardening/20240221020258.1210148-1-jeremy.linton@arm.com/)**
+
+> The existing arm64 stack randomization uses the kernel rng to acquire
+> 5 bits of address space randomization. This is problematic because it
+> creates non determinism in the syscall path when the rng needs to be
+> generated or reseeded. This shows up as large tail latencies in some
+> benchmarks and directly affects the minimum RT latencies as seen by
+> cyclictest.
+>
+
+**[v4: bpf: Replace bpf_lpm_trie_key 0-length array with flexible array](http://lore.kernel.org/linux-hardening/20240220185421.it.949-kees@kernel.org/)**
+
+> Adjust the kernel code to use struct bpf_lpm_trie_key_u8 through-out,
+> and for the selftest to use struct bpf_lpm_trie_key_hdr. Add a comment
+> to the UAPI header directing folks to the two new options.
+>
+
+**[v1: leaking_addresses: Provide mechanism to scan binary files](http://lore.kernel.org/linux-hardening/20240218173809.work.286-kees@kernel.org/)**
+
+> Introduce --kallsyms argument for scanning binary files for known symbol
+> addresses. This would have found the exposure in /sys/kernel/notes:
+>
+
+**[v1: PM: hibernate: Don't ignore return from set_memory_ro()](http://lore.kernel.org/linux-hardening/be49c794567f3bd00ae16e91b54fe8cfe6cb4999.1708245599.git.christophe.leroy@csgroup.eu/)**
+
+> set_memory_ro() and set_memory_rw() can fail, leaving memory
+> unprotected.
+>
+> Take the returned value into account and abort in case of
+> failure.
+>
+
+**[v4: nbd: null check for nla_nest_start](http://lore.kernel.org/linux-hardening/20240218042534.it.206-kees@kernel.org/)**
+
+> nla_nest_start() may fail and return NULL. Insert a check and set errno
+> based on other call sites within the same source code.
+>
+
+**[v1: bpf-next: bpf: Check return from set_memory_rox() and friends](http://lore.kernel.org/linux-hardening/63322c8e8454de9b240583de58cd730bc97bb789.1708165016.git.christophe.leroy@csgroup.eu/)**
+
+> arch_protect_bpf_trampoline() and alloc_new_pack() call
+> set_memory_rox() which can fail, leading to unprotected memory.
+>
+> Take into account return from set_memory_XX() functions and add
+> __must_check flag to arch_protect_bpf_trampoline().
+>
+
+**[v1: Adjust brk randomness](http://lore.kernel.org/linux-hardening/20240217062035.work.493-kees@kernel.org/)**
+
+> It was recently pointed out[1] that x86_64 brk entropy was not great,
+> and that on all architectures the brk can (when the random offset is 0)
+> be immediately adjacent to .bss, leaving no gap that could stop linear
+> overflows from the .bss. Address both issues.
+>
+
+**[v3: fortify: Add KUnit tests for runtime overflows](http://lore.kernel.org/linux-hardening/20240217043535.make.664-kees@kernel.org/)**
+
+> This series is the rest of the v2 series that was half landed last year,
+> and finally introduces KUnit runtime testing of the CONFIG_FORTIFY_SOURCE
+> APIs. Additionally FORTIFY failure messages are improved to give more
+> context about read/write and sizes.
+>
+
+**[v1: enic: Avoid false positive under FORTIFY_SOURCE](http://lore.kernel.org/linux-hardening/20240216233004.work.012-kees@kernel.org/)**
+
+> FORTIFY_SOURCE has been ignoring 0-sized destinations while the kernel
+> code base has been converted to flexible arrays. In order to enforce
+> the 0-sized destinations (e.g. with __counted_by), the remaining 0-sized
+> destinations need to be handled. Unfortunately, struct vic_provinfo
+> resists full conversion, as it contains a flexible array of flexible
+> arrays, which is only possible with the 0-sized fake flexible array.
+>
+
+**[v2: sock: Use unsafe_memcpy() for sock_copy()](http://lore.kernel.org/linux-hardening/20240216232220.it.450-kees@kernel.org/)**
+
+> While testing for places where zero-sized destinations were still showing
+> up in the kernel, sock_copy() and inet_reqsk_clone() were found, which
+> are using very specific memcpy() offsets for both avoiding a portion of
+> struct sock, and copying beyond the end of it (since struct sock is really
+> just a common header before the protocol-specific allocation). Instead
+> of trying to unravel this historical lack of container_of(), just switch
+> to unsafe_memcpy(), since that's effectively what was happening already
+> (memcpy() wasn't checking 0-sized destinations while the code base was
+> being converted away from fake flexible arrays).
+>
+
+**[v1: fortify: Include more details when reporting overflows](http://lore.kernel.org/linux-hardening/20240216203935.work.829-kees@kernel.org/)**
+
+> When a memcpy() would exceed the length of an entire structure, no
+> detailed WARN would be emitted, making debugging a bit more challenging.
+> Similarly, other buffer overflow reports would have no size information
+> reported.
+>
+
+**[v2: module: Don't ignore errors from set_memory_XX()](http://lore.kernel.org/linux-hardening/21037bf38438a285f5dff9501668f1675bc45989.1708070781.git.christophe.leroy@csgroup.eu/)**
+
+> set_memory_ro(), set_memory_nx(), set_memory_x() and other helpers
+> can fail and return an error. In that case the memory might not be
+> protected as expected and the module loading has to be aborted to
+> avoid security issues.
+>
+
+**[v2: cocci: Add rules to find str_plural() replacements](http://lore.kernel.org/linux-hardening/20240215194834.it.509-kees@kernel.org/)**
+
+> Add rules for finding places where str_plural() can be used. This
+> currently finds:
+>
+
+**[v1: lib/string_choices: Add str_plural() helper](http://lore.kernel.org/linux-hardening/20240214165015.1656-1-michal.wajdeczko@intel.com/)**
+
+> Add str_plural() helper to replace existing open implementations
+> used by many drivers and help improve future user facing messages.
+>
+
+**[v9: Introduce mseal](http://lore.kernel.org/linux-hardening/20240214151130.616240-1-jeffxu@chromium.org/)**
+
+> This is V9 version, with removing MAP_SEALABLE and PROT_SEAL
+> from mmap(), adding perfrmance benchmark and a test
+> to demo the sealing of read-only memory segment of elf mapping.
+>
+
+**[v6: pwm: Improve lifetime tracking for pwm_chips](http://lore.kernel.org/linux-hardening/cover.1707900770.git.u.kleine-koenig@pengutronix.de/)**
+
+> this is v6 of the series introducing better lifetime tracking for
+> pwmchips that addresses (for now theoretic) lifetime issues of pwm
+> chips. Addressing these is a necessary precondition to introduce chardev
+> support for PWMs.
+>
+
+**[v4: Tegra30: add support for LG tegra based phones](http://lore.kernel.org/linux-hardening/20240214091201.17636-1-clamor95@gmail.com/)**
+
+> Bring up Tegra 3 based LG phones Optimus 4X HD and Optimus Vu based
+> on LG X3 board.
+>
+
+#### 异步 IO
+
+**[v4: block atomic writes](http://lore.kernel.org/io-uring/20240219130109.341523-1-john.g.garry@oracle.com/)**
+
+> This series introduces a proposal to implementing atomic writes in the
+> kernel for torn-write protection.
+>
+> This series takes the approach of adding a new "atomic" flag to each of
+> pwritev2() and iocb->ki_flags - RWF_ATOMIC and IOCB_ATOMIC, respectively.
+> When set, these indicate that we want the write issued "atomically".
+>
+> Only direct IO is supported and for block devices here. For this, atomic
+> write HW is required, like SCSI ATOMIC WRITE (16).
+>
+
+**[v9: io_uring: Statistics of the true utilization of sq threads.](http://lore.kernel.org/io-uring/20240219064241.20531-1-xiaobing.li@samsung.com/)**
+
+> Count the running time and actual IO processing time of the sqpoll
+> thread, and output the statistical data to fdinfo.
+>
+> Variable description:
+> "work_time" in the code represents the sum of the jiffies of the sq
+> thread actually processing IO, that is, how many milliseconds it
+> actually takes to process IO. "total_time" represents the total time
+> that the sq thread has elapsed from the beginning of the loop to the
+> current time point, that is, how many milliseconds it has spent in
+> total.
+>
+
+
+**[v1: io_uring/napi: enable even with a timeout of 0](http://lore.kernel.org/io-uring/c7210193-a850-465c-bee2-ade5b36b4e2d@kernel.dk/)**
+
+> 1 usec is not as short as it used to be, and it makes sense to allow 0
+> for a busy poll timeout - this means just do one loop to check if we
+> have anything available. Add a separate ->napi_enabled to check if napi
+> has been enabled or not.
+>
+
+#### Rust For Linux
+
+**[v1: Arc methods for linked list](http://lore.kernel.org/rust-for-linux/20240219-arc-for-list-v1-0-d98cd92c760b@google.com/)**
+
+> This patchset contains two useful methods for the Arc type. They will be
+> used in my Rust linked list implementation, which Rust Binder uses. See
+> the Rust Binder RFC [1] for more information. Both these commits and
+> the linked list that uses them are present in the branch referenced by
+> the RFC.
+>
+
+**[[net-next RFC PATCH 0/3] net: phy: detach PHY driver OPs from phy_driver struct](http://lore.kernel.org/rust-for-linux/20240217194116.8565-1-ansuelsmth@gmail.com/)**
+
+> Posting as RFC due to the massive change to a fundamental struct.
+>
+> While adding some PHY ID for Aquantia, I notice that there is a
+> big problem with duplicating OPs with each PHY.
+>
+
+**[v1: rust: Add `container_of` and `offset_of` macros](http://lore.kernel.org/rust-for-linux/20240217153315.56128-1-mcanal@igalia.com/)**
+
+> Add Rust counterparts to these C macros. `container_of` is useful for C
+> struct subtyping, to recover the original pointer to the container
+> structure. `offset_of` is useful for struct-relative addressing.
+>
+
+**[v1: rust: upgrade to Rust 1.77.0](http://lore.kernel.org/rust-for-linux/20240217002717.57507-1-ojeda@kernel.org/)**
+
+> This is the next upgrade to the Rust toolchain, from 1.76.0 to 1.77.0
+> (i.e. the latest) [1].
+>
+> See the upgrade policy [2] and the comments on the first upgrade in
+> commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2").
+>
+
+**[v1: kbuild: rust: use `-Zdebuginfo-compression`](http://lore.kernel.org/rust-for-linux/20240217002622.57322-1-ojeda@kernel.org/)**
+
+> Rust 1.74.0 introduced (unstable) support for the
+> `-Zdebuginfo-compression` flag, thus use it.
+>
+
+**[v1: kbuild: rust: use `-Zdwarf-version` to support DWARFv5](http://lore.kernel.org/rust-for-linux/20240217002602.57270-1-ojeda@kernel.org/)**
+
+> Rust 1.64.0 introduced (unstable) support for the `-Zdwarf-version`
+> flag, which allows to select DWARFv5, thus use it.
+>
+
+**[v1: rust: bindings: Order headers alphabetically](http://lore.kernel.org/rust-for-linux/20240216152723.993445-1-mika.westerberg@linux.intel.com/)**
+
+> As the comment on top of the file suggests, sort the headers
+> alphabetically.
+>
+> No functional changes.
+>
+
+**[v2: rust: stop using ptr_metadata feature](http://lore.kernel.org/rust-for-linux/20240215104601.1267763-1-aliceryhl@google.com/)**
+
+> The `byte_sub` method was stabilized in Rust 1.75.0. By using that
+> method, we no longer need the unstable `ptr_metadata` feature for
+> implementing `Arc::from_raw`.
+>
+
+**[v3: rust: str: add {make,to}_{upper,lower}case() to CString](http://lore.kernel.org/rust-for-linux/20240214172505.5044-1-dakr@redhat.com/)**
+
+> Add functions to convert a CString to upper- / lowercase, either
+> in-place or by creating a copy of the original CString.
+>
+> Naming followes the one from the Rust stdlib, where functions starting
+> with 'to' create a copy and functions starting with 'make' perform an
+> in-place conversion.
+>
+
+#### BPF
+
+**[v2: bpf-next: selftests/bpf: Move test_dev_cgroup to prog_tests](http://lore.kernel.org/bpf/20240221092248.1945364-1-usama.anjum@collabora.com/)**
+
+> Move test_dev_cgroup.c to prog_tests/dev_cgroup.c to be able to run it
+> with test_progs. Replace dev_cgroup.bpf.o with skel header file,
+> dev_cgroup.skel.h and load program from it accourdingly.
+>
+
+**[v4: bpf-next: Check cfi_stubs before registering a struct_ops type.](http://lore.kernel.org/bpf/20240221075213.2071454-1-thinker.li@gmail.com/)**
+
+> Recently, cfi_stubs were introduced. However, existing struct_ops
+> types that are not in the upstream may not be aware of this, resulting
+> in kernel crashes. By rejecting struct_ops types that do not provide
+> cfi_stubs properly during registration, these crashes can be avoided.
+>
+
+**[v1: bpf: libbpf: clarify batch lookup semantics](http://lore.kernel.org/bpf/20240221010057.1061333-1-martin.kelly@crowdstrike.com/)**
+
+> The batch lookup APIs copy key memory into out_batch, which is then
+> supplied in later calls to in_batch. Thus both parameters need to point
+> to memory large enough to hold a single key (other than an initial NULL
+> in_batch). For many maps, keys are pointer sized or less, but for larger
+> maps, it's important to point to a larger block of memory to avoid
+> memory corruption.
+>
+
+**[v3: bpf-next: Create shadow types for struct_ops maps in skeletons](http://lore.kernel.org/bpf/20240221012329.1387275-1-thinker.li@gmail.com/)**
+
+> This patchset allows skeleton users to change the values of the fields
+> in struct_ops maps at runtime. It will create a shadow type pointer in
+> a skeleton for each struct_ops map, allowing users to access the
+> values of fields through these pointers. For instance, if there is an
+> integer field named "FOO" in a struct_ops map called "testmap", you
+> can access the value of "FOO" in this way.
+>
+
+**[v1: bpf-next: bpf: Shrink size of struct bpf_map/bpf_array.](http://lore.kernel.org/bpf/20240220235001.57411-1-alexei.starovoitov@gmail.com/)**
+
+> Back in 2018 the commit be95a845cc44 ("bpf: avoid false sharing of map refcount with max_entries")
+> refcnt don't share a cache line with max_entries that is used to bounds check
+> map access. That was done to make spectre style attacks harder. The main
+> mitigation is done via code similar to array_index_nospec(), of course.
+> This was an additional precaution.
+> It increased the size of "struct bpf_map" a little, but it's affect
+> on all other maps (like array) is significant, since "struct bpf_map" is
+> typically the first member in other map types.
+>
+
+**[v2: net-next: Change BPF_TEST_RUN use the system page pool for live XDP frames](http://lore.kernel.org/bpf/20240220210342.40267-1-toke@redhat.com/)**
+
+> Now that we have a system-wide page pool, we can use that for the live
+> frame mode of BPF_TEST_RUN (used by the XDP traffic generator), and
+> avoid the cost of creating a separate page pool instance for each
+> syscall invocation. See the individual patches for more details.
+>
+
+**[v1: arm64: mm: support dynamic vmalloc/pmd configuration](http://lore.kernel.org/bpf/20240220203256.31153-1-mbland@motorola.com/)**
+
+> Reworks ARM's virtual memory allocation infrastructure to support
+> dynamic enforcement of page middle directory PXNTable restrictions
+> rather than only during the initial memory mapping. Runtime enforcement
+> of this bit prevents write-then-execute attacks, where malicious code is
+> staged in vmalloc'd data regions, and later the page table is changed to
+> make this code executable.
+>
+
+**[v1: bpf-next: mm: Introduce vm_area_[un]map_pages().](http://lore.kernel.org/bpf/20240220192613.8840-1-alexei.starovoitov@gmail.com/)**
+
+> vmap() API is used to map a set of pages into contiguous kernel virtual space.
+>
+> BPF would like to extend the vmap API to implement a lazily-populated
+> contiguous kernel virtual space which size and start address is fixed early.
+>
+> The vmap API has functions to request and release areas of kernel address space:
+> get_vm_area() and free_vm_area().
+>
+
+**[v1: bpf-next: bpf: probe-read bpf_d_path() and add new acquire/release BPF kfuncs](http://lore.kernel.org/bpf/cover.1708377880.git.mattbobrowski@google.com/)**
+
+> On a number of occasions [0, 1, 2], usage of the pre-existing BPF
+> helper bpf_d_path() under certain circumstances has led to memory
+> corruption issues.
+>
+
+**[v1: bpf-next: bpf: make tracing program support multi-attach](http://lore.kernel.org/bpf/20240220035105.34626-1-dongmenglong.8@bytedance.com/)**
+
+> For now, the BPF program of type BPF_PROG_TYPE_TRACING is not allowed to
+> be attached to multiple hooks, and we have to create a BPF program for
+> each kernel function, for which we want to trace, even through all the
+> program have the same (or similar) logic. This can consume extra memory,
+> and make the program loading slow if we have plenty of kernel function to
+> trace.
+>
+
+**[v1: bpf-next: bpf: Add a generic bits iterator](http://lore.kernel.org/bpf/20240218114818.13585-1-laoar.shao@gmail.com/)**
+
+> Introducing three new kfuncs, namely bpf_iter_bits_{new,next,destroy}, to
+> support the newly added bits iter functionality. These functions enable
+> seamless iteration of bits from a specified memory area.
+>
+
+**[v1: bpf-next: Allow struct_ops maps with a large number of programs](http://lore.kernel.org/bpf/20240216182828.201727-1-thinker.li@gmail.com/)**
+
+> The BPF struct_ops previously only allowed for one page to be used for
+> the trampolines of all links in a map. However, we have recently run
+> out of space due to the large number of BPF program links. By
+> allocating additional pages when we exhaust an existing page, we can
+> accommodate more links in a single map.
+>
+
+**[v2: bpf-next: check bpf_func_state->callback_depth when pruning states](http://lore.kernel.org/bpf/20240216150334.31937-1-eddyz87@gmail.com/)**
+
+> discussion [0]. The details of the fix are in patch #2.
+> A change to the test case test_tcp_custom_syncookie.c is necessary,
+> otherwise updated verifier won't be able to process it due to
+> instruction complexity limit. This change is done in patch #1.
+>
+
+**[v1: selftests/bpf: Move test_dev_cgroup to prog_tests](http://lore.kernel.org/bpf/20240215120233.308986-1-usama.anjum@collabora.com/)**
+
+> Move test_dev_cgroup to prog_tests to be able to run it with test_progs.
+> Replace dev_cgroup.bpf.o with skel header file, dev_cgroup.skel.h and
+> load program from it accourdingly.
+>
+
+**[v5: net-next: Enable SGMII and 2500BASEX interface mode switching for Intel platforms](http://lore.kernel.org/bpf/20240215030500.3067426-1-yong.liang.choong@linux.intel.com/)**
+
+> During the interface mode change, the 'phylink_major_config' function
+> will be triggered in phylink. The modification of the following functions
+> will be triggered to support the switching between SGMII and 2500BASEX
+> interfaces mode for the Intel platform.
+>
+
+**[v1: bpf-next: bpf: Check cfi_stubs before registering a struct_ops type.](http://lore.kernel.org/bpf/20240215022401.1882010-1-thinker.li@gmail.com/)**
+
+> Recently, cfi_stubs were introduced. However, existing struct_ops types
+> that are not in the upstream may not be aware of this, resulting in kernel
+> crashes. By rejecting struct_ops types that do not provide cfi_stubs during
+> registration, these crashes can be avoided.
+>
+
+**[v1: bpf-next: bpf: improve duplicate source code line detection](http://lore.kernel.org/bpf/20240214174100.2847419-1-andrii@kernel.org/)**
+
+> Verifier log avoids printing the same source code line multiple times
+> when a consecutive block of BPF assembly instructions are covered by the
+> same original (C) source code line. This greatly improves verifier log
+> legibility.
+>
+
+**[v5: Combine perf and bpf for fast eval of hw breakpoint conditions]](http://lore.kernel.org/bpf/20240214173950.18570-1-khuey@kylehuey.com/)**
+
+> Currently, rr uses software breakpoints that trap (via ptrace) to the
+> supervisor, and evaluates the condition from the supervisor. If the
+> asynchronous event is delivered in a tight loop (thus requiring the
+> breakpoint condition to be repeatedly evaluated) the overhead can be
+> immense. A patch to rr that uses hardware breakpoints via perf events with
+> an attached BPF program to reject breakpoint hits where the condition is
+> not satisfied reduces rr's replay overhead by 94% on a pathological (but a
+> real customer-provided, not contrived) rr trace.
+>
+
+**[v2: bpf-next: allow HID-BPF to do device IOs](http://lore.kernel.org/bpf/20240214-hid-bpf-sleepable-v2-0-5756b054724d@kernel.org/)**
+
+> [Still a RFC: there are a lot of FIXMEs in the code, and
+> calling the sleepable timer cb actually crashes.]
+> [Also using bpf-next as the base tree as there will be conflicting
+> changes otherwise]
+>
+> This is crashing, and I have a few questions in the code (look for all
+> of the FIXMEs), so sending this now before I become insane :)
+>
+
+**[v3: net-next: dma: skip calling no-op sync ops when possible](http://lore.kernel.org/bpf/20240214162201.4168778-1-aleksander.lobakin@intel.com/)**
+
+> The series grew from Eric's idea and patch at [0]. The idea of using the
+> shortcut for direct DMA as well belongs to Chris.
+>
+> When an architecture doesn't need DMA synchronization and the buffer is
+> not an SWIOTLB buffer, most of times the kernel and the drivers end up
+> calling DMA sync operations for nothing.
+> Even when DMA is direct, this involves a good non-inline call ladder and
+> eats a bunch of CPU time. With IOMMU, this results in calling indirect
+> calls on hotpath just to check what is already known and return.
+> XSk is been using a custom shortcut for that for quite some time.
+> I recently wanted to introduce a similar one for Page Pool. Let's combine
+> all this into one generic shortcut, which would cover all DMA sync ops
+> and all types of DMA (direct, IOMMU, ...).
+>
+
+**[v3: bpf-next: libbpf: make remark about zero-initializing bpf_*_info structs](http://lore.kernel.org/bpf/ZcyEb8x4VbhieWsL@google.com/)**
+
+> In some situations, if you fail to zero-initialize the
+> bpf_{prog,map,btf,link}_info structs supplied to the set of LIBBPF
+> helpers bpf_{prog,map,btf,link}_get_info_by_fd(), you can expect the
+> helper to return an error. This can possibly leave people in a
+> situation where they're scratching their heads for an unnnecessary
+> amount of time. Make an explicit remark about the requirement of
+> zero-initializing the supplied bpf_{prog,map,btf,link}_info structs
+> for the respective LIBBPF helpers.
+>
+
+**[v2: bpf-next: libbpf: make remark about zero-initializing bpf_*_info structs](http://lore.kernel.org/bpf/ZcxsEQ8Ld_hqbi7L@google.com/)**
+
+> In some situations, if you fail to zero-initialize the
+> bpf_{prog,map,btf,link}_info structs supplied to the set of LIBBPF
+> helpers bpf_{prog,map,btf,link}_get_info_by_fd(), you can expect the
+> helper to return an error. This can possibly leave people in a
+> situation where they're scratching their heads for an unnnecessary
+> amount of time. Make an explicit remark about the requirement of
+> zero-initializing the supplied bpf_{prog,map,btf,link}_info structs
+> for the respective LIBBPF helpers.
+>
+
+**[v2: bpf-next: Create shadow variables for struct_ops in skeletons](http://lore.kernel.org/bpf/20240214020836.1845354-1-thinker.li@gmail.com/)**
+
+> This RFC is for gathering feedback/opinions on the design.
+> Based on the feedback received for v1, I made some modifications.
+>
+
+**[v1: bpf-next: bpf: use O(log(N)) binary search to find line info record](http://lore.kernel.org/bpf/20240214002311.2197116-1-andrii@kernel.org/)**
+
+> Real-world BPF applications keep growing in size. Medium-sized production
+> application can easily have 50K+ verified instructions, and its line
+> info section in .BTF.ext has more than 3K entries.
+>
+
+**[v1: Corrected GPL license name](http://lore.kernel.org/bpf/20240213230544.930018-3-glusvardi@posteo.net/)**
+
+> The bpf_doc script refers to the GPL as the "GNU Privacy License".
+> I strongly suspect that the author wanted to refer to the GNU General
+> Public License, under which the Linux kernel is released, as, to the
+> best of my knowledge, there is no license named "GNU Privacy License".
+>
+
+**[v2: bpf-next: libbpf: add support to GCC in CORE macro definitions](http://lore.kernel.org/bpf/20240213173543.1397708-1-cupertino.miranda@oracle.com/)**
+
+> Due to internal differences between LLVM and GCC the current
+> implementation for the CO-RE macros does not fit GCC parser, as it will
+> optimize those expressions even before those would be accessible by the
+> BPF backend.
+>
+
+**[v1: bpf-next: libbpf: make remark about zero-initializing bpf_*_info structs](http://lore.kernel.org/bpf/Zcuj0zHhFMML8-mU@google.com/)**
+
+> In some situations, if you fail to zero-initialize the bpf_*_info
+> buffer supplied to the set of LIBBPF helpers
+> bpf_{prog,map,btf,link}_get_info_by_fd(), you can expect the helper to
+> return an error. This can possibly leave people in a situation where
+> they're scratching their heads for an unnnecessary amount of
+> time. Make an explicit remark about the requirement of
+> zero-initializing the supplied bpf_*_info buffers for the respective
+> LIBBPF helpers to prevent exactly this situation.
+>
+
+**[v1: net-next: Use per-task storage for XDP-redirects on PREEMPT_RT](http://lore.kernel.org/bpf/20240213145923.2552753-1-bigeasy@linutronix.de/)**
+
+> In [0] I introduced explicit locking for resources which are otherwise
+> locked implicit locked by local_bh_disable() and this protections goes
+> away if the lock in local_bh_disable() is removed on PREEMPT_RT.
+>
+
+**[v1: bpf-next: ARC: Add eBPF JIT support](http://lore.kernel.org/bpf/20240213131946.32068-1-list+bpf@vahedi.org/)**
+
+> This will add eBPF JIT support to the 32-bit ARCv2 processors. The
+> implementation is qualified by running the BPF tests on a Synopsys HSDK
+> board with "ARC HS38 v2.1c at 500 MHz" as the 4-core CPU.
+>
+
+### 周边技术动态
+
+#### Qemu
+
+**[v5: riscv: set vstart_eq_zero on mark_vs_dirty](http://lore.kernel.org/qemu-devel/20240221022252.252872-1-dbarboza@ventanamicro.com/)**
+
+> In this new version we removed the remaining brconds() from
+> trans_rvbf16.c.inc like Richard suggested in patch 3. Richard, I kept
+> your ack in that patch.
+>
+
+**[v1: target/riscv: Add missing include guard in pmu.h](http://lore.kernel.org/qemu-devel/20240220110907.10479-1-frank.chang@sifive.com/)**
+
+> Add missing include guard in pmu.h to avoid the problem of double
+> inclusion.
+>
+
+**[v1: RISC-V: Modularize common match conditions for trigger](http://lore.kernel.org/qemu-devel/20240219032559.79665-1-alvinga@andestech.com/)**
+
+> According to RISC-V Debug specification, the enabled privilege levels of
+> the trigger is common match conditions for all the types of the trigger.
+> This series modularize the code for checking the privilege levels of
+> type 2/3/6 triggers by implementing functions trigger_common_match()
+> and trigger_priv_match().
+>
+
+**[v1: RISC-V: Implement CSR tcontrol in debug spec](http://lore.kernel.org/qemu-devel/20240216061332.50229-1-alvinga@andestech.com/)**
+
+> The RISC-V Debug specification defines CSR "tcontrol" in the trigger
+> module:
+>   https://github.com/riscv/riscv-debug-spec
+>
+
+**[v4: riscv: named features riscv,isa, 'svade' rework](http://lore.kernel.org/qemu-devel/20240215223955.969568-1-dbarboza@ventanamicro.com/)**
+
+> This new version is rebased with alistair/riscv-to-apply.next and with
+> more acks added.
+>
+
+**[support for having both 32 and 64 bit RISC-V CPUs in one QEMU machine](http://lore.kernel.org/qemu-devel/BYAPR15MB268082AF727B0C775A4BA7E1C34D2@BYAPR15MB2680.namprd15.prod.outlook.com/)**
+
+> I have a situation when I need to use third-party 32-bit RISC-V CPU when rest is all 64-bit RISC-V CPUs. I have seen that some steps were already made in the direction to enable such configuration (https://riscv.org/blog/2023/01/run-32-bit-applications-on-64-bit-linux-kernel-liu-zhiwei-guo-ren-t-head-division-of-alibaba-cloud/), I am wondering if someone can shed more light on it.
+>
+
+**[v1: Improve the performance of RISC-V vector unit-stride ld/st instructions](http://lore.kernel.org/qemu-devel/20240215192823.729209-1-max.chou@sifive.com/)**
+
+> When glibc with RVV support [1], the memcpy benchmark will run 2x to 60x
+> slower than the scalar equivalent on QEMU and it hurts developer
+> productivity.
+>
+> From the performance analysis result, we can observe that the glibc
+> memcpy spends most of the time in the vector unit-stride load/store
+> helper functions.
+>
+
+**[v1: target: riscv: Add Svvptc extension support](http://lore.kernel.org/qemu-devel/20240213145308.869874-1-alexghiti@rivosinc.com/)**
+
+> The Svvptc extension describes a uarch that does not cache invalid TLB
+> entries: that's the case for qemu so there is nothing particular to
+> implement other than the introduction of this extension, which is done
+> here.
+>
+
+#### U-Boot
+
+**[v1: riscv: mbv: Enhance MB-V support with also enabling SPL](http://lore.kernel.org/u-boot/cover.1707911544.git.michal.simek@amd.com/)**
+
+> enhance MB-V support with SPL configuration to support OpenSBI.
+> All of that changes are out of generic Risc-V support that's why happy to
+> take it via my tree. Please let me know if you want this to take via riscv
+> subtree.
+>
+
 ## 20240213：第 78 期
 
 ### 内核动态
-- 
Gitee