diff --git a/news/README.md b/news/README.md index 32d463ed44a980ba17e0a88baa7ab3b3d9206ed5..40be486a12335804dc053d644e105ca70e377dd2 100644 --- a/news/README.md +++ b/news/README.md @@ -6,6 +6,430 @@ * [2023 年 - 上半年](2023-1st-half.md) * [2023 年 - 下半年](2023-2nd-half.md) +## 20240414：第 87 期 + +### 内核动态 + +#### RISC-V 架构支持 + +**[v2: of: property: Add fw_devlink support for interrupt-map property](http://lore.kernel.org/linux-riscv/20240413091942.316054-1-apatel@ventanamicro.com/)** + +> Some of the PCI controllers (such as generic PCI host controller) +> use "interrupt-map" DT property to describe the mapping between +> PCI endpoints and PCI interrupt pins. This the only case where +> the interrupts are not described in DT. +> + +**[v10: Add timer driver for StarFive JH7110 RISC-V SoC](http://lore.kernel.org/linux-riscv/20240412084543.7243-1-ziv.xu@starfivetech.com/)** + +> This patch serises are to add timer driver for the StarFive JH7110 +> RISC-V SoC. The first patch adds documentation to describe device +> tree bindings. The subsequent patch adds timer driver and support +> JH7110 SoC. The last patch adds device node about timer in JH7110 +> dts. +> + +**[v8: riscv: sophgo: add dmamux support for Sophgo CV1800/SG2000 SoCs](http://lore.kernel.org/linux-riscv/IA1PR20MB495359880A3A8C4947702BB5BB042@IA1PR20MB4953.namprd20.prod.outlook.com/)** + +> Add dma multiplexer support for the Sophgo CV1800/SG2000 SoCs. +> +> As the syscon device of CV1800 have a usb phy subdevices. The +> binding of the syscon can not be complete without the usb phy +> is finished. As a result, the binding of syscon is removed +> and will be evolved in its original series after the usb phy +> binding is fully explored. +> + +**[v4: Support Zve32[xf] and Zve64[xfd] Vector subextensions](http://lore.kernel.org/linux-riscv/20240412-zve-detection-v4-0-e0c45bb6b253@sifive.com/)** + +> The series composes of two parts. The first part provides a quick fix for +> the issue on a recent thread[1]. The issue happens when a platform has +> ununified vector register length across multiple cores. Specifically, +> patch 1 adds a comment at a callsite of riscv_setup_vsize to clarify how +> vlenb is observed by the system. Patch 2 fixes the issue by failing the +> boot process of a secondary core if vlenb mismatches. +> + +**[v4: mm: jit/text allocator](http://lore.kernel.org/linux-riscv/20240411160051.2093261-1-rppt@kernel.org/)** + +> Since v3 I looked into making execmem more of an utility toolbox, as we +> discussed at LPC with Mark Rutland, but it was getting more hairier than +> having a struct describing architecture constraints and a type identifying +> the consumer of execmem. +> + +**[v6: RISC-V SBI v2.0 PMU improvements and Perf sampling in KVM guest](http://lore.kernel.org/linux-riscv/20240411000752.955910-1-atishp@rivosinc.com/)** + +> This series implements SBI PMU improvements done in SBI v2.0[1] i.e. PMU snapshot +> and fw_read_hi() functions. +> +> SBI v2.0 introduced PMU snapshot feature which allows the SBI implementation +> to provide counter information (i.e. values/overflow status) via a shared +> memory between the SBI implementation and supervisor OS. This allows to minimize +> the number of traps in when perf being used inside a kvm guest as it relies on +> SBI PMU + trap/emulation of the counters. +> + +**[v5: riscv: hwprobe: export highest virtual userspace address](http://lore.kernel.org/linux-riscv/20240410144558.1104006-1-cleger@rivosinc.com/)** + +> Some userspace applications (OpenJDK for instance) uses the free MSBs +> in pointers to insert additional information for their own logic and +> need to get this information from somewhere. Currently they rely on +> parsing /proc/cpuinfo "mmu=svxx" string to obtain the current value of +> virtual address usable bits [1]. +> + +**[v3: riscv: improve nommu and timer-clint](http://lore.kernel.org/linux-riscv/20240410142347.964-1-jszhang@kernel.org/)** + +> As is known, the sophgo CV1800B contains so called little core, which +> is C906 w/o MMU, so I want to run nommu linux on it. This series is +> the result of the bring up. After this series, w/ proper dts, we can +> run nommu linux on milkv duo's little core. +> + +**[v3: add initial Milk-V Duo S board support](http://lore.kernel.org/linux-riscv/20240410062254.2955647-1-michael.opdenacker@bootlin.com/)** + +> This adds an initial device tree for the Milk-V Duo S board. +> Last tested on linux-next as a May 9, 2024. +> + +**[v4: Add notifier for PLL0 clock and set it 1.5GHz on](http://lore.kernel.org/linux-riscv/20240410033148.213991-1-xingyu.wu@starfivetech.com/)** + +> This patch is to add the notifier for PLL0 clock and set the PLL0 rate +> to 1.5GHz to fix the lower rate of CPUfreq on the JH7110 SoC. +> + +**[v3: RISC-V: enable rust](http://lore.kernel.org/linux-riscv/20240409-unsaddle-skittle-c93eb77732bb@spud/)** + +> I've intentionally not turned on the gcc support, as discussed on +> v1. I've also switched over to using the target, but it is a bit heavier +> than the one arm64 seems to be using. RISC-V has fewer targets available +> and this was the closest. I preserved the redzone disabling, just moved +> into the Makefile. +> + +**[v3: RISC-V: Test th.sxstatus.MAEE bit before enabling MAEE](http://lore.kernel.org/linux-riscv/20240407213236.2121592-1-christoph.muellner@vrull.eu/)** + +> Currently, the Linux kernel suffers from a boot regression when running +> on the c906 QEMU emulation. Details have been reported here by Björn Töpel: +> https://lists.gnu.org/archive/html/qemu-devel/2024-01/msg04766.html +> + +**[v8: RESEND: riscv: add initial support for Canaan Kendryte K230](http://lore.kernel.org/linux-riscv/tencent_22BA0425B4DF1CA1713B62E4423C1BFBF809@qq.com/)** + +> K230 is an ideal chip for RISC-V Vector 1.0 evaluation now. Add initial +> support for it to allow more people to participate in building drivers +> to mainline for it. +> + +#### 进程调度 + +**[v2: sched/topology: Optimize topology_span_sane()](http://lore.kernel.org/lkml/20240410213311.511470-1-kyle.meyer@hpe.com/)** + +> A soft lockup is being detected in build_sched_domains() on 32 socket +> Sapphire Rapids systems with 3840 processors. +> + +**[v2: net-next: net: sched: cake: Optimize the number of function calls and branches in heap construction](http://lore.kernel.org/lkml/20240408174716.751069-1-visitorckw@gmail.com/)** + +> When constructing a heap, heapify operations are required on all +> non-leaf nodes. Thus, determining the index of the first non-leaf node +> is crucial. +> + +#### 内存管理 + +**[v2: mm/shrinker: add SHRINKER_NO_DIRECT_RECLAIM](http://lore.kernel.org/linux-mm/20240413015410.30951-1-lipeifeng@oppo.com/)** + +> In the case of insufficient memory, threads will be in direct_reclaim to +> reclaim memory, direct_reclaim will call shrink_slab to run sequentially +> each shrinker callback. +> + +**[v6: IOMMU memory observability](http://lore.kernel.org/linux-mm/20240413002522.1101315-1-pasha.tatashin@soleen.com/)** + +> Description +> IOMMU subsystem may contain state that is in gigabytes. Majority of that +> state is iommu page tables. Yet, there is currently, no way to observe +> how much memory is actually used by the iommu subsystem. +> + +**[v6: mm/madvise: enhance lazyfreeing with mTHP in madvise_free](http://lore.kernel.org/linux-mm/20240413002219.71246-1-ioworker0@gmail.com/)** + +> This patchset adds support for lazyfreeing multi-size THP (mTHP) without +> needing to first split the large folio via split_folio(). However, we +> still need to split a large folio that is not fully mapped within the +> target range. +> + +**[v6: mm: add per-order mTHP alloc and swpout counters](http://lore.kernel.org/linux-mm/20240412114858.407208-1-21cnbao@gmail.com/)** + +> The patchset introduces a framework to facilitate mTHP counters, starting +> with the allocation and swap-out counters. Currently, only four new nodes +> are appended to the stats directory for each mTHP size. +> + +**[v2: slub: Clear __GFP_COMP flag when allocating 0 order page](http://lore.kernel.org/linux-mm/20240412095431.612839-1-haifeng.xu@shopee.com/)** + +> We encounter warning messages when failing to create a new slab like +> this: +> +> page allocation failure: order:0, mode:0x1004000(GFP_NOWAIT|__GFP_COMP), +> nodemask=(null) +> + +**[v3: mm: batch mm counter updating in filemap_map_pages()](http://lore.kernel.org/linux-mm/20240412064751.119015-1-wangkefeng.wang@huawei.com/)** + +> Let's batch mm counter updating to accelerate filemap_map_pages(). +> + +**[v2: tracing: Add sched_prepare_exec tracepoint](http://lore.kernel.org/linux-mm/20240411102158.1272267-1-elver@google.com/)** + +> Add "sched_prepare_exec" tracepoint, which is run right after the point +> of no return but before the current task assumes its new exec identity. +> + +**[v14: mm/gup: Introduce memfd_pin_folios() for pinning memfd folios](http://lore.kernel.org/linux-mm/20240411070157.3318425-1-vivek.kasireddy@intel.com/)** + +> Currently, some drivers (e.g, Udmabuf) that want to longterm-pin +> the pages/folios associated with a memfd, do so by simply taking a +> reference on them. This is not desirable because the pages/folios +> may reside in Movable zone or CMA block. +> + +**[v5: transfer page to folio in KSM](http://lore.kernel.org/linux-mm/20240411061713.1847574-1-alexs@kernel.org/)** + +> This is the first part of page to folio transfer on KSM. Since only +> single page could be stored in KSM, we could safely transfer stable tree +> pages to folios. +> This patchset could reduce ksm.o 57kbytes from 2541776 bytes on latest +> akpm/mm-stable branch with CONFIG_DEBUG_VM enabled. It pass the KSM testing +> in LTP and kernel selftest. +> + +#### 文件系统 + +**[v2: ext4: support adding multi-delalloc blocks](http://lore.kernel.org/linux-fsdevel/20240410034203.2188357-1-yi.zhang@huaweicloud.com/)** + +> This patch series is the part 2 prepartory changes of the buffered IO +> iomap conversion, I picked them out from my buffered IO iomap conversion +> RFC series v3[1], add a fix for an issue found in current ext4 code,and +> also add bigalloc feature support. Please look the following patches for +> details. +> + +**[v2: exfat: move extend valid_size into ->page_mkwrite()](http://lore.kernel.org/linux-fsdevel/PUZPR04MB63160EDE1B2FB47D80B717D481002@PUZPR04MB6316.apcprd04.prod.outlook.com/)** + +> It is not a good way to extend valid_size to the end of the +> mmap area by writing zeros in mmap. Because after calling mmap, +> no data may be written, or only a small amount of data may be +> written to the head of the mmap area. +> + +#### 网络设备 + +**[v2: net-next: Read PHY address of switch from device tree on MT7530 DSA subdriver](http://lore.kernel.org/netdev/20240414-b4-for-netnext-mt7530-phy-addr-from-dt-and-simplify-core-ops-v2-0-1a7649c4d3b6@arinc9.com/)** + +> This patch series makes the driver read the PHY address the switch listens +> on from the device tree which, in result, brings support for MT7530 +> switches listening on a different PHY address than 31. And the patch series +> simplifies the core operations. +> + +**[v6: net-next: net/smc: SMC intra-OS shortcut with loopback-ism](http://lore.kernel.org/netdev/20240414040304.54255-1-guwen@linux.alibaba.com/)** + +> This patch set acts as the second part of the new version of [1] (The first +> part can be referred from [2]), the updated things of this version are listed +> at the end. +> + +**[v7: net-next: virtio_net: Support RX hash XDP hint](http://lore.kernel.org/netdev/20240413041035.7344-1-liangchen.linux@gmail.com/)** + +> The RSS hash report is a feature that's part of the virtio specification. +> Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost +> (still a work in progress as per [1]) support this feature. While the +> capability to obtain the RSS hash has been enabled in the normal path, +> it's currently missing in the XDP path. Therefore, we are introducing +> XDP hints through kfuncs to allow XDP programs to access the RSS hash. +> + +**[v2: net-next: af_unix: Try not to hold unix_gc_lock during accept().](http://lore.kernel.org/netdev/20240413021928.20946-1-kuniyu@amazon.com/)** + +> Commit dcf70df2048d ("af_unix: Fix up unix_edge.successor for embryo +> socket.") added spin_lock(&unix_gc_lock) in accept() path, and it +> caused regression in a stress test as reported by kernel test robot. +> + +**[v3: udp: Avoid call to compute_score on multiple sites](http://lore.kernel.org/netdev/20240412212004.17181-1-krisman@suse.de/)** + +> We've observed a 7-12% performance regression in iperf3 UDP ipv4 and +> ipv6 tests with multiple sockets on Zen3 cpus, which we traced back to +> commit f0ea27e7bfe1 ("udp: re-score reuseport groups when connected +> sockets are present"). The failing tests were those that would spawn +> UDP sockets per-cpu on systems that have a high number of cpus. +> + +**[v3: bpf-next: Replace mono_delivery_time with tstamp_type](http://lore.kernel.org/netdev/20240412210125.1780574-1-quic_abchauha@quicinc.com/)** + +> Patch 1 :- This patch takes care of only renaming the mono delivery +> timestamp to tstamp_type with no change in functionality of +> existing available code in kernel also +> Starts assigning tstamp_type with either mono or real and +> introduces a new enum in the skbuff.h, again no change in functionality +> of the existing available code in kernel , just making the code scalable. +> + +**[v2: bpf-next: selftests/bpf: Add sockaddr tests for kernel networking](http://lore.kernel.org/netdev/20240412165230.2009746-1-jrife@google.com/)** + +> This patch series adds test coverage for BPF sockaddr hooks and their +> interactions with kernel socket functions (i.e. kernel_bind(), +> kernel_connect(), kernel_sendmsg(), sock_sendmsg(), +> kernel_getpeername(), and kernel_getsockname()) while also rounding out +> IPv4 and IPv6 sockaddr hook coverage in prog_tests/sock_addr.c. +> + +**[v7: net-next: net: gro: move p->{flush/flush_id} calculations to L4](http://lore.kernel.org/netdev/20240412155533.115507-1-richardbgobert@gmail.com/)** + +> This patch series depends on commits in the series submitted to net. +> (https://lore.kernel.org/netdev/20240412152120.115067-1-richardbgobert@gmail.com/) +> + +**[v9: net-next: Add minimal XDP support to TI AM65 CPSW Ethernet driver](http://lore.kernel.org/netdev/20240223-am65-cpsw-xdp-basic-v9-0-2c194217e325@baylibre.com/)** + +> This patch adds XDP support to TI AM65 CPSW Ethernet driver. +> + +**[v2: net-next: selftests: net: exercise page pool reporting via netlink](http://lore.kernel.org/netdev/20240412141436.828666-1-kuba@kernel.org/)** + +> Add a basic test for page pool netlink reporting. +> + +**[v8: iwl-next: Introduce ETH56G PHY model for E825C products](http://lore.kernel.org/netdev/20240412131104.322851-14-karol.kolacinski@intel.com/)** + +> E825C products have a different PHY model than E822, E823 and E810 products. +> This PHY is ETH56G and its support is necessary to have functional PTP stack +> for E825C products. +> + +**[v10: GenieZone hypervisor drivers](http://lore.kernel.org/netdev/20240412065718.29105-1-yi-de.wu@mediatek.com/)** + +> This series is based on linux-next, tag: next-20240411. +> + +#### 安全增强 + +**[v2: xfs: replace deprecated strncpy with memtostr_pad](http://lore.kernel.org/linux-hardening/20240410-strncpy-xfs-split1-v2-1-7c651502bcb0@google.com/)** + +> strncpy() is deprecated for use on NUL-terminated destination strings +> [1] and as such we should prefer more robust and less ambiguous string +> interfaces. +> + +#### 异步 IO + +**[v2: liburing: improve sendzc tests](http://lore.kernel.org/io-uring/cover.1712594147.git.asml.silence@gmail.com/)** + +> There is enough of special handling for DEFER_TASKRUN, so we want +> to test sendzc with DEFER_TASKRUN as well. Apart from that, probe +> zc support at the beginning and do some more cleanups. +> + +**[v2: io_uring: return void from io_put_kbuf_comp()](http://lore.kernel.org/io-uring/20240407132759.4056167-1-ming.lei@redhat.com/)** + +> The only caller doesn't handle the return value of io_put_kbuf_comp(), so +> change its return type into void. +> + +#### Rust For Linux + +#### BPF + +**[v2: bpf-next: Enable BPF programs to declare arrays of kptr, bpf_rb_root, and bpf_list_head.](http://lore.kernel.org/bpf/20240412210814.603377-1-thinker.li@gmail.com/)** + +> The arrays of kptr, bpf_rb_root, and bpf_list_head didn't work as +> global variables. This was due to these types being initialized and +> verified in a special manner in the kernel. This patchset allows BPF +> programs to declare arrays of kptr, bpf_rb_root, and bpf_list_head in +> the global namespace. +> + +**[v6: Combine perf and bpf for fast eval of hw breakpoint conditions](http://lore.kernel.org/bpf/20240412015019.7060-1-khuey@kylehuey.com/)** + +> rr, a userspace record and replay debugger[0], replays asynchronous events +> such as signals and context switches by essentially[1] setting a breakpoint +> at the address where the asynchronous event was delivered during recording +> with a condition that the program state matches the state when the event +> was delivered. +> + +**[v2: bpf-next: net: Add additional bit to support userspace timestamp type](http://lore.kernel.org/bpf/20240411230506.1115174-3-quic_abchauha@quicinc.com/)** + +> tstamp_type can be real, mono or userspace timestamp. +> +> This commit adds userspace timestamp and sets it if there is +> valid transmit_time available in socket coming from userspace. +> + +**[v6: net-next: allocate dummy device dynamically](http://lore.kernel.org/bpf/20240411135952.1096696-1-leitao@debian.org/)** + +> struct net_device shouldn't be embedded into any structure, instead, +> the owner should use the private space to embed their state into +> net_device. +> + +**[v6: bpf-next: bpf: Add a generic bits iterator](http://lore.kernel.org/bpf/20240411131127.73098-1-laoar.shao@gmail.com/)** + +> Three new kfuncs, namely bpf_iter_bits_{new,next,destroy}, have been +> added for the new bpf_iter_bits functionality. These kfuncs enable the +> iteration of the bits from a given address and a given number of bits. +> + +**[v3: bpf-next: Add check for bpf lsm return value](http://lore.kernel.org/bpf/20240411122752.2873562-1-xukuohai@huaweicloud.com/)** + +> A bpf prog returning positive number attached to file_alloc_security hook +> will make kernel panic. +> + +**[v16: net-next: Introducing P4TC (series 1)](http://lore.kernel.org/bpf/20240410140141.495384-1-jhs@mojatatu.com/)** + +> This is the first patchset of two. In this patch we are submitting 15 which +> cover the minimal viable P4 PNA architecture. +> Please, if you want to discuss a slightly tangential subject like offload or +> even your politics then start another thread with a different subject line. +> + +### 周边技术动态 + +#### Buildroot + +**[package/uclibc: bump to 1.0.47](http://lore.kernel.org/buildroot/20240410194546.DD63B85E99@busybox.osuosl.org/)** + +> commit: https://git.buildroot.net/buildroot/commit/?id=3b7f8f8d226c8f5b08edb5a7a8ad746ba04c34c5 +> branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master +> + +**[toolchain/toolchain-external/toolchain-external-bootlin: bump to 2024.02](http://lore.kernel.org/buildroot/20240407153141.D84C481266@busybox.osuosl.org/)** + +> commit: https://git.buildroot.net/buildroot/commit/?id=345ccb523e412b390d42073cd976a3288b0733c1 +> branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master +> + +#### U-Boot + +**[v4: cmd: bootm: add ELF file support](http://lore.kernel.org/u-boot/20240411085738.31779-1-Maxim.Moskalets@kaspersky.com/)** + +> Some operating systems (e.g. seL4) and embedded applications are ELF +> images. It is convenient to use FIT-images to implement trusted boot. +> Added "elf" image type for booting using bootm command. +> + +**[GIT PULL: xilinx patches for v2024.07-rc1](http://lore.kernel.org/u-boot/5559177c-9db3-4470-be0b-90562422de72@monstr.eu/)** + +> please apply these patches to your tree. Gitlab CI is not showing any issue and +> buildman for our platforms is also not showing any issue. +> + + ## 20240407：第 86 期 ### 内核动态