From b986bde8040106b77edd6dbaf1457ef6690d549a Mon Sep 17 00:00:00 2001 From: lucia <11452490+luciafu@user.noreply.gitee.com> Date: Sun, 7 Jan 2024 10:33:38 +0000 Subject: [PATCH] update news/README.md. Signed-off-by: lucia <11452490+luciafu@user.noreply.gitee.com> --- news/README.md | 878 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 878 insertions(+) diff --git a/news/README.md b/news/README.md index b796f04..d246687 100644 --- a/news/README.md +++ b/news/README.md @@ -6,6 +6,884 @@ * [2023 年 - 上半年](2023-1st-half.md) * [2023 年 - 下半年](2023-2nd-half.md) +## 20240107：第 73 期 + +### 内核动态 + +#### RISC-V 架构支持 + +**[v2: RISC-V crypto with reworked asm files](http://lore.kernel.org/linux-riscv/20240105184950.43181-1-ebiggers@kernel.org/)** + +> As discussed previously, the proposed use of the so-called perlasm for +> the RISC-V crypto assembly files makes them difficult to read, and these +> files have some other issues such extensively duplicating source code +> for the different AES key lengths and for the unrolled hash functions. +> There is/was a desire to share code with OpenSSL, but many of the files +> have already diverged significantly; also, for most of the algorithms +> the source code can be quite short anyway, due to the native support for +> them in the RISC-V vector crypto extensions combined with the way the +> RISC-V vector extension naturally scales to arbitrary vector lengths. +> + +**[v1: riscv: Optimize crc32 with Zbc extension](http://lore.kernel.org/linux-riscv/20240105080830.3738117-1-xiao.w.wang@intel.com/)** + +> As suggested by the B-ext spec, the Zbc (carry-less multiplication) +> instructions can be used to accelerate CRC calculations. Currently, the +> crc32 is the most widely used crc function inside kernel, so this patch +> focuses on the optimization of just the crc32 APIs. +> + +**[回复: v13: Refactoring Microchip PCIe driver and add StarFive PCIe](http://lore.kernel.org/linux-riscv/ZQ0PR01MB098128579D86207B4B9BA7D28266A@ZQ0PR01MB0981.CHNPR01.prod.partner.outlook.cn/)** + +> > Minda Chen writes: +> > +> > > This patchset final purpose is add PCIe driver for StarFive JH7110 SoC. +> > > JH7110 using PLDA XpressRICH PCIe IP. Microchip PolarFire Using the +> > > same IP and have commit their codes, which are mixed with PLDA +> > > controller codes and Microchip platform codes. +> > + +**[v1: RISC-V: KVM: Require HAVE_KVM](http://lore.kernel.org/linux-riscv/20240104104307.16019-2-ajones@ventanamicro.com/)** + +> KVM requires EVENTFD, which is selected by HAVE_KVM. Other KVM +> supporting architectures select HAVE_KVM and then their KVM +> Kconfigs ensure its there with a depends on HAVE_KVM. Make RISCV +> consistent with that approach which fixes configs which have KVM +> but not EVENTFD, as was discovered with a randconfig test. +> + +**[v1: perf: RISC-V: Check standard event availability](http://lore.kernel.org/linux-riscv/20240103165438.633054-1-samuel.holland@sifive.com/)** + +> The RISC-V SBI PMU specification defines several standard hardware and +> cache events. Currently, all of these events appear in the `perf list` +> output, even if they are not actually implemented. Add logic to check +> which events are supported by the hardware (i.e. can be mapped to some +> counter), so only usable events are reported to userspace. +> + +**[v1: riscv: Introduce compat-mode helpers & improve arch_get_mmap_end()](http://lore.kernel.org/linux-riscv/20240103160024.70305-2-leobras@redhat.com/)** + +> I just saw the opportunity of optimizing the helper is_compat_task() by +> introducing a compile-time test, and it made possible to remove some +> #ifdef's without any loss of performance. +> + +**[v1: RISC-V: hwprobe: Check for the reserved flags](http://lore.kernel.org/linux-riscv/20240103121220.26506-1-palmer@rivosinc.com/)** + +> This check got dropped when RISCV_HWPROBE_WHICH_CPUS was added, but +> we've still got a bunch of other reserved flags. So check for them, +> just to make sure userspace doesn't get confused later. +> + +**[v4: riscv: ASID-related and UP-related TLB flush enhancements](http://lore.kernel.org/linux-riscv/20240102220134.3229156-1-samuel.holland@sifive.com/)** + +> While reviewing Alexandre Ghiti's "riscv: tlb flush improvements" +> series[1], I noticed that most TLB flush functions end up as a call to +> local_flush_tlb_all() when SMP is disabled. This series resolves that, +> and also optimizes the scenario where SMP is enabled but only one CPU is +> present or online. Along the way, I realized that we should be using +> single-ASID flushes wherever possible, so I implemented that as well. +> + +**[v1: riscv: Add support for BATCHED_UNMAP_TLB_FLUSH](http://lore.kernel.org/linux-riscv/20240102141851.105144-1-alexghiti@rivosinc.com/)** + +> Allow to defer the flushing of the TLB when unmapping pges, which allows +> to reduce the numbers of IPI and the number of sfence.vma. +> + +**[v4: RISC-V: provide some accelerated cryptography implementations using vector extensions](http://lore.kernel.org/linux-riscv/20231231152743.6304-1-jerry.shih@sifive.com/)** + +> This series provides cryptographic implementations using the vector crypto +> extensions[1] including: +> 1. AES cipher +> 2. AES with CBC/CTR/ECB/XTS block modes +> 3. ChaCha20 stream cipher +> 4. GHASH for GCM +> 5. SHA-224/256 and SHA-384/512 hash +> 6. SM3 hash +> 7. SM4 cipher +> + +**[v2: riscv: Add Zicbop & prefetchw support](http://lore.kernel.org/linux-riscv/20231231082955.16516-1-guoren@kernel.org/)** + +> This patch series adds Zicbop support and then enables the Linux +> prefetchw feature. It's based on v6.7-rc7. +> +> PATCH[1] - Add Zicbop support +> PATCH[2] - Add prefetchw support +> PATCH[3] - Enhance xchg_small +> + +#### 进程调度 + +**[v1: sched: save to call pick_eevdf when TIF_NEED_RESCHED is set](http://lore.kernel.org/lkml/20240105040159.5026-1-zegao@tencent.com/)** + +> We now can have TIF_NEED_RESCHED set from update_curr() +> in check_preempt_wakeup_fair(), so check to save to call +> pick_eevdf once it's set and defer the possible picking +> to where schedule() is called. +> + +**[v2: sched/stat: correct the task blocking state](http://lore.kernel.org/lkml/20240103081042.1549189-1-alexs@kernel.org/)** + +> The commit 80ed87c8a9ca ("sched/wait: Introduce TASK_NOLOAD and TASK_IDLE") +> stopped the idle kthreads from contributing to the load average. However, +> the idle state time still contributes to the blocked state time instead of +> the sleep time. As a result, we cannot determine if a task is stopped due +> to some reasons or if it is idle by its own initiative. +> + +**[v1: sched/eevdf: add helper function entity_deadline_is_valid](http://lore.kernel.org/lkml/20240103023205.26344-1-liusong@linux.alibaba.com/)** + +> Add the helper function "entity_deadline_is_valid", then +> corresponding code logic can be inferred from the function +> name, improving readability of the code. +> + +**[v1: sched/tracing: correct the task blocking state](http://lore.kernel.org/lkml/20240102073351.1527503-1-alexs@kernel.org/)** + +> commit 80ed87c8a9ca ("sched/wait: Introduce TASK_NOLOAD and TASK_IDLE") +> stopped the idle kthreads contribution to loadavg. Also task idle should +> separated from blocked state too, otherwise we will get incorrect task +> blocking state from event tracing sched:sched_stat_blocked. +> + +**[v2: sched: use existing helper function for accessing avg_rt, avg_dl and avg_irq](http://lore.kernel.org/lkml/20240101154624.100981-1-sshegde@linux.vnet.ibm.com/)** + +> Split the patches into two since there is subtle change with avg_irq. +> There is no functionality change expected due to first patch, while +> second patch may have. In case of any future regressions it would be +> easy to bisect. +> + +#### 内存管理 + +**[v1: selftests/mm/ksm_functional: prevent unmapping undefined address](http://lore.kernel.org/linux-mm/20240105202401.28851-1-inwardvessel@gmail.com/)** + +> Replace some goto statements with return statements so that unmap() is +> not called on an undefined address. This change is made so that unmap() +> can only be reached after mmap() is called (and the address mentioned is +> defined). Returning MAP_FAILED seems acceptable since client code checks +> for this value. +> + +**[v3: x86/hyperv: Mark CoCo VM pages not present when changing encrypted state](http://lore.kernel.org/linux-mm/20240105183025.225972-1-mhklinux@outlook.com/)** + +> In a CoCo VM, when transitioning memory from encrypted to decrypted, or +> vice versa, the caller of set_memory_encrypted() or set_memory_decrypted() +> is responsible for ensuring the memory isn't in use and isn't referenced +> while the transition is in progress. The transition has multiple steps, +> and the memory is in an inconsistent state until all steps are complete. +> A reference while the state is inconsistent could result in an exception +> that can't be cleanly fixed up. +> + +**[v1: selftest/mm/hugetlb: SIGBUS on stolen page](http://lore.kernel.org/linux-mm/20240105155419.1939484-1-leitao@debian.org/)** + +> This test case triggers a race between madvise(MADV_DONTNEED) and +> mmap() in a single huge page, which got stolen (while reserved). +> +> Once the only page is stolen, the memory previously mmaped (and +> madvise(MADV_DONTNEED) got a SIGBUS when accessed. +> + +**[v6: -next: Make memory reclamation measurable](http://lore.kernel.org/linux-mm/20240105013607.2868-1-cuibixuan@vivo.com/)** + +> When the system memory is low, kswapd reclaims the memory. The key steps +> of memory reclamation include +> 1.shrink_lruvec +> * shrink_active_list, moves folios from the active LRU to the inactive LRU +> * shrink_inactive_list, shrink lru from inactive LRU list +> 2.shrink_slab +> * shrinker->count_objects(), calculates the freeable memory +> * shrinker->scan_objects(), reclaims the slab memory +> + +**[v4: Introduce mseal()](http://lore.kernel.org/linux-mm/20240104185138.169307-1-jeffxu@chromium.org/)** + +> This is V4 of the patch, the patch has improved significantly since V1, +> thanks to diverse inputs, a few discussions remain, please read those +> in the open discussion section of v4 of change history. +> + +**[v1: readahead: Avoid multiple marked readahead pages](http://lore.kernel.org/linux-mm/20240104085839.21029-1-jack@suse.cz/)** + +> ra_alloc_folio() marks a page that should trigger next round of async +> readahead. However it rounds up computed index to the order of page +> being allocated. This can however lead to multiple consecutive pages +> being marked with readahead flag. Consider situation with index == 1, +> mark == 1, order == 0. We insert order 0 page at index 1 and mark it. +> Then we bump order to 1, index to 2, mark (still == 1) is rounded up to +> 2 so page at index 2 is marked as well. Then we bump order to 2, index +> is incremented to 4, mark gets rounded to 4 so page at index 4 is marked +> as well. The fact that multiple pages get marked within a single +> readahead window confuses the readahead logic and results in readahead +> window being trimmed back to 1. This situation is triggered in +> particular when maximum readahead window size is not a power of two (in +> the observed case it was 768 KB) and as a result sequential read +> throughput suffers. +> + +**[v10: mm/gup: Introduce memfd_pin_folios() for pinning memfd folios (v10)](http://lore.kernel.org/linux-mm/20240104072518.807950-1-vivek.kasireddy@intel.com/)** + +> The first two patches were previously reviewed but not yet merged. +> These ones need to be merged first as the fourth patch depends on +> the changes introduced in them and they also fix bugs seen in +> very specific scenarios (running Qemu with hugetlb=on, blob=true +> and rebooting guest VM). +> + +**[v6: mempolicy2, mbind2, and weighted interleave](http://lore.kernel.org/linux-mm/20240103224209.2541-1-gregory.price@memverge.com/)** + +> Weighted interleave is a new interleave policy intended to make +> use of heterogeneous memory environments appearing with CXL. +> +> To implement weighted interleave with task-local weights, we +> need new syscalls capable of passing a weight array. This is +> the justification for mempolicy2/mbind2 - which are designed +> to be extensible to capture future policies as well. +> + +**[v1: netfs, cachefiles, 9p: Additional patches](http://lore.kernel.org/linux-mm/20240103145935.384404-1-dhowells@redhat.com/)** + +> Here are some additional patches for my netfs-lib tree: +> +> (1) Fix __cachefiles_prepare_write() to correctly validate against the DIO +> alignment. +> +> (2) 9p: Fix initialisation of the netfs_inode so that i_size is set before +> netfs_inode_init() is called. +> +> (3) 9p: Do a couple of cleanups (remove a couple of unused vars and turn a +> BUG_ON() into a warning). +> +> (4) 9p: Always update remote_i_size, even if we're asked not to update +> i_size in stat2inode. +> +> (5) 9p: Return the amount written in preference to an error if we wrote +> something. +> + +**[v1: execve: argument list space enlargement](http://lore.kernel.org/linux-mm/20240103130722.1551670-1-alexs@kernel.org/)** + +> Wechat using too long gcc parameters, then get a strace complain: +> execve(...) = -1 E2BIG (Argument list too long) +> Have to increase the parameter space for this, stack has enough +> space for this enlargement. +> + +**[v3: Mitigate a vmap lock contention v3](http://lore.kernel.org/linux-mm/20240102184633.748113-1-urezki@gmail.com/)** + +> This is v3. It is based on the 6.7.0-rc8. +> +> 1. Motivation +> +> - Offload global vmap locks making it scaled to number of CPUS; +> - If possible and there is an agreement, we can remove the "Per cpu kva allocator" +> to make the vmap code to be more simple; +> - There were complains from XFS folk that a vmalloc might be contented +> on the their workloads. +> + +**[v2: swapin refactor for optimization and unified readahead](http://lore.kernel.org/linux-mm/20240102175338.62012-1-ryncsn@gmail.com/)** + +> This series is rebased on latest mm-stable to avoid conflicts. +> +> This series tries to unify and clean up the swapin path, introduce minor +> optimization, and make both shmem swapoff make use of SWP_SYNCHRONOUS_IO +> flag to skip readahead and swapcache for better performance. +> + +**[v1: tools/mm: Add thpmaps script to dump THP usage info](http://lore.kernel.org/linux-mm/20240102153828.1002295-1-ryan.roberts@arm.com/)** + +> With the proliferation of large folios for file-backed memory, and more +> recently the introduction of multi-size THP for anonymous memory, it is +> becoming useful to be able to see exactly how large folios are mapped +> into processes. For some architectures (e.g. arm64), if most memory is +> mapped using contpte-sized and -aligned blocks, TLB usage can be +> optimized so it's useful to see where these requirements are and are not +> being met. +> + +**[v3: hugetlb: parallelize hugetlb page init on boot](http://lore.kernel.org/linux-mm/20240102131249.76622-1-gang.li@linux.dev/)** + +> This series is tested on next-20240102 and can not be applied to v6.7-rc8. +> +> Update Summary: +> - Select CONFIG_PADATA as we use padata_do_multithreaded +> - Fix a race condition in h->next_nid_to_alloc +> - Fix local variable initialization issues +> - Remove RFC tag +> + +**[v1: mm/selftests: hugepage-mremap: conform test to TAP format output](http://lore.kernel.org/linux-mm/20240102081919.2325570-1-usama.anjum@collabora.com/)** + +> Conform the layout, informational and status messages to TAP. No +> functional change is intended other than the layout of output messages. +> + +**[v2: selftests/mm: gup_test: conform test to TAP format output](http://lore.kernel.org/linux-mm/20240102053807.2114200-1-usama.anjum@collabora.com/)** + +> Conform the layout, informational and status messages to TAP. No +> functional change is intended other than the layout of output messages. +> + +**[v1: selftests: mm: hugepage-mmap: conform to TAP format output](http://lore.kernel.org/linux-mm/20240102053223.2099572-1-usama.anjum@collabora.com/)** + +> Conform the layout, informational and status messages to TAP. No +> functional change is intended other than the layout of output messages. +> + +#### 文件系统 + +**[v2: virtiofs: use GFP_NOFS when enqueuing request through kworker](http://lore.kernel.org/linux-fsdevel/20240105105305.4052672-1-houtao@huaweicloud.com/)** + +> When invoking virtio_fs_enqueue_req() through kworker, both the +> allocation of the sg array and the bounce buffer still use GFP_ATOMIC. +> Considering the size of both the sg array and the bounce buffer may be +> greater than PAGE_SIZE, use GFP_NOFS instead of GFP_ATOMIC to lower the +> possibility of memory allocation failure. +> + +**[v1: Improve buffer head documentation](http://lore.kernel.org/linux-fsdevel/20240104163652.3705753-1-willy@infradead.org/)** + +> Having started improving the kernel-doc for __folio_mark_dirty(), I +> then started noticing other improvements that could be made, and this +> is as far as I got before deciding I'd made enough for now. Tested with +> make htmldocs. +> + +**[v1: seq_file: Optimize seq_puts()](http://lore.kernel.org/linux-fsdevel/5c4f7ad7b88f5026940efa9c8be36a58755ec1b3.1704374916.git.christophe.jaillet@wanadoo.fr/)** + +> Most of seq_puts() usages are done with a string literal. In such cases, +> the length of the string car be computed at compile time in order to save +> a strlen() call at run-time. seq_write() can then be used instead. +> + +**[v2: tracefs/eventfs: Use root and instance inodes as default ownership](http://lore.kernel.org/linux-fsdevel/20240103215016.1e0c9811@gandalf.local.home/)** + +> Instead of walking the dentries on mount/remount to update the gid values of +> all the dentries if a gid option is specified on mount, just update the root +> inode. Add .getattr, .setattr, and .permissions on the tracefs inode +> operations to update the permissions of the files and directories. +> + +**[v2: eventfs: Don't use dcache_readdir() for getdents()](http://lore.kernel.org/linux-fsdevel/20240104015247.075935881@goodmis.org/)** + +> After having a "pleasant" conversation with Linus over on the security +> mailing list, we came to the conclusion that eventfs should not be +> using the dcache_readdir() routine for iterating the entries of a +> directory (getdents()). +> + +**[v1: bpf-next: BPF token](http://lore.kernel.org/linux-fsdevel/20240103222034.2582628-1-andrii@kernel.org/)** + +> This patch set is a combination of three BPF token-related patch sets ([0], +> [1], [2]) with fixes ([3]) to kernel-side token_fd passing APIs incorporated +> into relevant patches, and necessary libbpf and BPF selftests side adjustments. +> + +**[v1: bcachefs: factor out thread_with_file, thread_with_stdio](http://lore.kernel.org/linux-fsdevel/20240103215307.3328500-1-kent.overstreet@linux.dev/)** + +> this is some utility code I wrote in bcachefs that might be more widely +> useful - it's used in bcachefs for online fsck, and I was talking to +> Darrick about possibly using it for XFS as well so that we could +> potentially standardize our interfaces for online fsck. +> + +**[v1: Open block devices as files & a bd_inode proposal](http://lore.kernel.org/linux-fsdevel/20240103-vfs-bdev-file-v1-0-6c8ee55fb6ef@kernel.org/)** + +> I've been toying with this idea in between changing diapers essentially +> and I've taken it far enough that I'd like some general input before +> going further and massaging out any corner cases I might've missed. +> +> I wanted to see whether we can make struct bdev_handle completely +> private to the block layer in the next cycle and unexport low-level +> helpers such as bdev_release() - formerly blkdev_put() - completely. +> + +**[v1: virtiofs: limit the length of ITER_KVEC dio by max_nopage_rw](http://lore.kernel.org/linux-fsdevel/20240103105929.1902658-1-houtao@huaweicloud.com/)** + +> The warning happened as follow. In copy_args_to_argbuf(), virtiofs uses +> kmalloc-ed memory as bound buffer for fuse args, but +> fuse_get_user_pages() only limits the length of fuse arg by max_read or +> max_write for IOV_KVEC io (e.g., kernel_read_file from finit_module()). +> For virtiofs, max_read is UINT_MAX, so a big read request which is about +> 10MB is passed to copy_args_to_argbuf(), kmalloc() is called in turn +> with len=10MB, and triggers the warning in __alloc_pages(): +> WARN_ON_ONCE_GFP(order > MAX_ORDER, gfp)). +> + +**[v2: ext4: use iomap for regular file's buffered IO path and enable large foilo](http://lore.kernel.org/linux-fsdevel/20240102123918.799062-1-yi.zhang@huaweicloud.com/)** + +> This is my second version of the RFC patch series that convert ext4 +> regular file's buffered IO path to iomap. I've been fixing a lot of bugs +> in v1 and rebased it on 6.7 and with Christoph's "map multiple blocks +> per ->map_blocks in iomap writeback" series [1]. +> + +**[v1: blk: optimization for classic polling](http://lore.kernel.org/linux-fsdevel/3578876466-3733-1-git-send-email-nj.shetty@samsung.com/)** + +> This removes the dependency on interrupts to wake up task. Set task +> state as TASK_RUNNING, if need_resched() returns true, +> while polling for IO completion. +> Earlier, polling task used to sleep, relying on interrupt to wake it up. +> This made some IO take very long when interrupt-coalescing is enabled in +> NVMe. +> + +#### 网络设备 + +**[v2: RFC: ethtool: switch EEE netlink interface to use EEE linkmode bitmaps](http://lore.kernel.org/netdev/8d8700c8-75b2-49ba-b303-b8d619008e45@gmail.com/)** + +> So far only 32bit legacy bitmaps are passed to userspace. This makes +> it impossible to manage EEE linkmodes beyond bit 32, e.g. manage EEE +> for 2500BaseT and 5000BaseT. This series adds support for passing +> full linkmode bitmaps between kernel and userspace. +> + +**[v1: net-next: Introducing OpenVPN Data Channel Offload](http://lore.kernel.org/netdev/20240106215740.14770-1-antonio@openvpn.net/)** + +> After several months of work, I am finally +> sending a new version of the OpenVPN Data Channel Offload kernel +> module (aka `ovpn`) for official review. +> +> The OpenVPN community has since long been interested in moving the fast path +> to kernel space. `ovpn` finally helps achieving this goal. +> + +**[v1: maketable: Add check for ZERO for variable sigma2](http://lore.kernel.org/netdev/20240106211422.33967-1-maks.mishinFZ@gmail.com/)** + +> If variable `limit` == 1, then `n` == 1 and then second for-loop will +> not do because of variable `sigma2` maybe ZERO. +> Added check for ZERO for `sigma2` before it is used as denominator. +> + +**[v1: ifstat: Add NULL pointer check for result of ll_index_to_name()](http://lore.kernel.org/netdev/20240106201010.29461-1-maks.mishinFZ@gmail.com/)** + +> Result of ll_index_to_name() function do not being checked for NULL +> pointer before using in strdup() function. +> Add intermediate variable `name` for result of ll_index_to_name() +> function. Function result -1 when `name` is NULL. +> + +**[v3: bpf-next: Annotate kfuncs in .BTF_ids section](http://lore.kernel.org/netdev/cover.1704565248.git.dxu@dxuuu.xyz/)** + +> This is a bpf-treewide change that annotates all kfuncs as such inside +> .BTF_ids. This annotation eventually allows us to automatically generate +> kfunc prototypes from bpftool. +> +> We store this metadata inside a yet-unused flags field inside struct +> btf_id_set8 (thanks Kumar!). pahole will be taught where to look. +> + +**[v1: net-next: net: dsa: mt7530: support OF-based registration of switch MDIO bus](http://lore.kernel.org/netdev/20240106122142.235389-1-arinc.unal@arinc9.com/)** + +> Currently the MDIO bus of the switches the MT7530 DSA subdriver controls +> can only be registered as non-OF-based. Bring support for registering the +> bus OF-based. +> + +**[v4: net: mlxbf_gige: Enable the GigE port in mlxbf_gige_open](http://lore.kernel.org/netdev/20240105160014.23353-1-asmaa@nvidia.com/)** + +> At the moment, the GigE port is enabled in the mlxbf_gige_probe +> function. If the mlxbf_gige_open is not executed, this could cause +> pause frames to increase in the case where there is high backgroud +> traffic. This results in clogging the port. +> So move enabling the OOB port to mlxbf_gige_open. +> + +**[v9: Introduce STM32 Firewall framework](http://lore.kernel.org/netdev/20240105130404.301172-1-gatien.chevallier@foss.st.com/)** + +> Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x +> platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers +> register to the framework to offer firewall services such as access +> granting. +> + +**[[net-next PATCH] octeontx2-pf: Add support for offload tc with skbedit mark action](http://lore.kernel.org/netdev/20240105120247.14975-1-gakula@marvell.com/)** + +> Support offloading of skbedit mark action. +> +> For example, to mark with 0x0008, with dest ip 60.60.60.2 on eth2 +> interface: +> +> # tc qdisc add dev eth2 ingress +> # tc filter add dev eth2 ingress protocol ip flower \ +> dst_ip 60.60.60.2 action skbedit mark 0x0008 skip_sw +> + +**[v16: net-next: Add Realtek automotive PCIe driver](http://lore.kernel.org/netdev/20240105112811.380952-1-justinlai0215@realtek.com/)** + +> This series includes adding realtek automotive ethernet driver +> and adding rtase ethernet driver entry in MAINTAINERS file. +> + +**[v1: net-next: add dsa cross-chip port mirroring](http://lore.kernel.org/netdev/cover.1704449760.git.ante.knezic@helmholz.de/)** + +> This patch is an attempt to add cross-chip port mirroring to dsa core and +> mv88e6xxx switches but should apply similarly to other devices as well. +> It is a work in progress so I am posting as RFC hopefully to get some +> feedback on the general idea behind he problem rather than on the quality +> of the code itself, though provided you have the time I would appreciate +> any suggestions to code as well. +> + +**[v2: iwl-next: ixgbe: Convert ret val type from s32 to int](http://lore.kernel.org/netdev/20240105103120.393911-1-jedrzej.jagielski@intel.com/)** + +> Currently big amount of the functions returning standard error codes +> are of type s32. Convert them to regular ints as typdefs here are +> not necessary to return standard error codes. +> + +**[v15: net-next: Add Realtek automotive PCIe driver](http://lore.kernel.org/netdev/20240105090039.377561-1-justinlai0215@realtek.com/)** + +> This series includes adding realtek automotive ethernet driver +> and adding rtase ethernet driver entry in MAINTAINERS file. +> +> This ethernet device driver for the PCIe interface of +> Realtek Automotive Ethernet Switch,applicable to +> RTL9054, RTL9068, RTL9072, RTL9075, RTL9068, RTL9071. +> + +**[v2: net: ethernet: ti: am65-cpsw: Allow for MTU values](http://lore.kernel.org/netdev/20240105085530.14070-1-jorge.sanjuangarcia@duagon.com/)** + +> The am65-cpsw-nuss driver has a fixed definition for the maximum ethernet +> frame length of 1522 bytes (AM65_CPSW_MAX_PACKET_SIZE). This limits the switch +> ports to only operate at a maximum MTU of 1500 bytes. When combining this CPSW +> switch with a DSA switch connected to one of its ports this limitation shows up. +> The extra 8 bytes the DSA subsystem adds internally to the ethernet frame +> create resulting frames bigger than 1522 bytes (1518 for non VLAN + 8 for DSA +> stuff) so they get dropped by the switch. +> + +**[v1: net: phy: micrel: populate .soft_reset for KSZ9131](http://lore.kernel.org/netdev/20240105085242.1471050-1-claudiu.beznea.uj@bp.renesas.com/)** + +> The RZ/G3S SMARC Module has 2 KSZ9131 PHYs. In this setup, the KSZ9131 PHY +> is used with the ravb Ethernet driver. It has been discovered that when +> bringing the Ethernet interface down/up continuously, e.g., with the +> following sh script: +> +> $ while :; do ifconfig eth0 down; ifconfig eth0 up; done +> + +**[v3: net-next: net: ravb: Add suspend to RAM and runtime PM support for RZ/G3S](http://lore.kernel.org/netdev/20240105082339.1468817-1-claudiu.beznea.uj@bp.renesas.com/)** + +> This series adds suspend to RAM and runtime PM support for Ethernet +> IP available on the RZ/G3S (R9A08G045) SoC. +> +> As there are IP versions that switch to module standby when disabling +> the clocks, and because of module standby IP switches to reset and +> the register content is lost, to be able to have runtime PM supported +> for all IP variants, the configuration operations were moved all to +> ravb_open()/ravb_close() letting the ravb_probe() and ravb_remove() +> to deal with resource parsing and allocation/free. +> + +**[v2: net-next: net: stmmac: Enable Per DMA Channel interrupt](http://lore.kernel.org/netdev/20240105070925.2948871-1-leong.ching.swee@intel.com/)** + +> Add Per DMA Channel interrupt feature for DWXGMAC IP. +> +> Patchset (link below) contains per DMA channel interrupt, But it was +> achieved. +> https://lore.kernel.org/lkml/20230821203328.GA2197059- +> robh@kernel.org/t/#m849b529a642e1bff89c05a07efc25d6a94c8bfb4 +> +> Some of the changes in this patchset are based on reviewer comment on +> patchset mentioned beforehand. +> + +**[linux-next: duplicate patch in the vhost tree](http://lore.kernel.org/netdev/20240105150635.2bdc667e@canb.auug.org.au/)** + +> The following commits are also in the net tree as a different commit +> (but the same patch): +> +> d2c4f1928a3f ("virtio_net: fix missing dma unmap for resize") +> +> This is commit +> +> in the net tree. +> +> Cheers, +> Stephen Rothwell +> +> [-- Attachment #2: OpenPGP digital signature --] +> [-- Type: application/pgp-signature, Size: 488 bytes --] +> + +**[v2: iwl-net: idpf: avoid compiler padding in virtchnl2_ptype struct](http://lore.kernel.org/netdev/20240105013232.44996-1-pavan.kumar.linga@intel.com/)** + +> In the arm random config file, kconfig option 'CONFIG_AEABI' is +> disabled which results in adding the compiler flag '-mabi=apcs-gnu'. +> This causes the compiler to add padding in virtchnl2_ptype +> structure to align it to 8 bytes, resulting in the following +> size check failure +> + +**[v4: net-next: There are some features for the HNS3 ethernet driver](http://lore.kernel.org/netdev/20240105010119.2619873-1-shaojijie@huawei.com/)** + +> There are some features for the HNS3 ethernet driver +> + +**[v2: net-next: net/sched: simplify tc_action_load_ops parameters](http://lore.kernel.org/netdev/20240105003810.2056224-1-pctammela@mojatatu.com/)** + +> Instead of using two bools derived from a flags passed as arguments to +> the parent function of tc_action_load_ops, just pass the flags itself +> to tc_action_load_ops to simplify its parameters. +> + +**[v1: net: gre: complete lockless access to dev->needed_headroom](http://lore.kernel.org/netdev/20240104232714.619657-1-xzou017@ucr.edu/)** + +> According to 4b397c06cb9 (net: tunnels: annotate lockless +> accesses to dev->needed_headroom), we need to use lockless +> access to protect dev->needed_headroom from data racing. +> This patch complete the changes in ip(6)_gre. +> + +**[GIT PULL: Networking for v6.7-rc9](http://lore.kernel.org/netdev/20240104182252.1963951-1-kuba@kernel.org/)** + +> We haven't accumulated much over the break. If it wasn't for +> the uninterrupted stream of fixes for Intel drivers this PR +> would be very slim. There was a handful of user reports, however, +> either they stood out because of the lower traffic or users +> have had more time to test over the break. The ones which are +> v6.7-relevant should be wrapped up. +> + +**[v3: net: rtnetlink: allow to enslave with one msg an up interface](http://lore.kernel.org/netdev/20240104164300.3870209-1-nicolas.dichtel@6wind.com/)** + +> The first patch fixes a regression introduced in linux v6.1. The second +> patch adds some tests to verify this API. +> +> Regards, +> Nicolas +> + +**[v1: net-next: taprio: validate TCA_TAPRIO_ATTR_FLAGS through policy instead of open-coding](http://lore.kernel.org/netdev/20240104163856.16699-1-alessandromarcolini99@gmail.com/)** + +> As of now, the field TCA_TAPRIO_ATTR_FLAGS is being validated by manually +> checking its value, using the function taprio_flags_valid(). +> + +**[v1: net-next: geneve: use DEV_STATS_INC()](http://lore.kernel.org/netdev/20240104163633.2070538-1-edumazet@google.com/)** + +> geneve updates dev->stats fields locklessly. +> +> Adopt DEV_STATS_INC() to avoid races. +> + +**[v1: net-next: net: bridge: do not send arp replies if src and target hw addr is the same](http://lore.kernel.org/netdev/20240104142501.81092-1-nbd@nbd.name/)** + +> There are broken devices in the wild that handle duplicate IP address +> detection by sending out ARP requests for the IP that they received from a +> DHCP server and refuse the address if they get a reply. +> When proxyarp is enabled, they would go into a loop of requesting an address +> and then NAKing it again. +> + +**[v1: net-next: net: fill in MODULE_DESCRIPTION()s for CAIF](http://lore.kernel.org/netdev/20240104144855.1320993-1-kuba@kernel.org/)** + +> W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). +> Add descriptions to all the CAIF sub-modules. +> + +**[v1: net-next: net: fill in MODULE_DESCRIPTION()s for DSA tags](http://lore.kernel.org/netdev/20240104143759.1318137-1-kuba@kernel.org/)** + +> W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). +> Add descriptions to all the DSA tag modules. +> +> The descriptions are copy/pasted Kconfig names, with s/^Tag/DSA tag/. +> + +**[v1: net-next: net: fill in MODULE_DESCRIPTION()s for ATM](http://lore.kernel.org/netdev/20240104143737.1317945-1-kuba@kernel.org/)** + +> W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). +> Add descriptions to all the ATM modules and drivers. +> + +**[v1: net-next: selftests: forwarding: Avoid failures to source net/lib.sh](http://lore.kernel.org/netdev/20240104141109.100672-1-bpoirier@nvidia.com/)** + +> The expression "source ../lib.sh" added to net/forwarding/lib.sh in commit +> 25ae948b4478 ("selftests/net: add lib.sh") does not work for tests outside +> net/forwarding which source net/forwarding/lib.sh (1). It also does not +> work in some cases where only a subset of tests are exported (2). +> + +#### 安全增强 + +**[v1: ASoC: ti: Use devm_kcalloc() instead of devm_kzalloc()](http://lore.kernel.org/linux-hardening/20240106162752.18599-1-erick.archer@gmx.com/)** + +> Use 2-factor multiplication argument form devm_kcalloc() instead +> of devm_kzalloc(). +> + +**[v1: PM / QOS: Use kcalloc() instead of kzalloc()](http://lore.kernel.org/linux-hardening/20240105181118.116292-1-erick.archer@gmx.com/)** + +> Use 2-factor multiplication argument form kcalloc() instead +> of kzalloc(). +> + +**[v1: efi: pstore: Allow dynamic initialization based on module parameter](http://lore.kernel.org/linux-hardening/20240103184053.226203-1-gpiccoli@igalia.com/)** + +> The efi-pstore module parameter "pstore_disable" warrants that users +> are able to deactivate such backend. There is also a Kconfig option +> for the default value of this parameter. It was originally added due +> to some bad UEFI FW implementations that could break with many variables +> written. +> + +#### Rust For Linux + +**[v1: rust: sync: `CondVar` rename "wait_list" to "wait_queue_head"](http://lore.kernel.org/rust-for-linux/20240105012930.1426214-1-charmitro@posteo.net/)** + +> Fields named "wait_list" usually are of type "struct list_head". To +> avoid confusion and because it is of type +> "Opaque" we are renaming "wait_list" to +> "wait_queue_head". +> + +#### BPF + +**[v3: bpf-next: bpf: inline bpf_kptr_xchg()](http://lore.kernel.org/bpf/20240105104819.3916743-1-houtao@huaweicloud.com/)** + +> The motivation of inlining bpf_kptr_xchg() comes from the performance +> profiling of bpf memory allocator benchmark [1]. The benchmark uses +> bpf_kptr_xchg() to stash the allocated objects and to pop the stashed +> objects for free. After inling bpf_kptr_xchg(), the performance for +> object free on 8-CPUs VM increases about 2% +> 10%. However the performance +> gain comes with costs: both the kasan and kcsan checks on the pointer +> will be unavailable. Initially the inline is implemented in do_jit() for +> x86-64 directly, but I think it will more portable to implement the +> inline in verifier. +> + +**[v1: bpf-next: PTR_TO_BTF_ID arguments in global subprogs](http://lore.kernel.org/bpf/20240105000909.2818934-1-andrii@kernel.org/)** + +> This patch set follows recent changes that added btf_decl_tag-based argument +> annotation support for global subprogs. This time we add ability to pass +> PTR_TO_BTF_ID (BTF-aware kernel pointers) arguments into global subprograms. +> We support explicitly trusted and untrusted arguments. Legacy semi-trusted +> variant is not supported. +> + +**[v1: bpf-next: selftests/bpf: detect testing prog flags support](http://lore.kernel.org/bpf/20240104223932.1971645-1-andrii@kernel.org/)** + +> Various tests specify extra testing prog_flags when loading BPF +> programs, like BPF_F_TEST_RND_HI32, and more recently also +> BPF_F_TEST_REG_INVARIANTS. While BPF_F_TEST_RND_HI32 is old enough to +> not cause much problem on older kernels, BPF_F_TEST_REG_INVARIANTS is +> very fresh and unconditionally specifying it causes selftests to fail on +> even slightly outdated kernels. +> + +**[v1: bpftool: Add missing libgen.h for basename()](http://lore.kernel.org/bpf/ZZYgMYmb_qE94PUB@kernel.org/)** + +> The header with the prototype for basename() is missing in the gen.c +> file, which breaks the build in distros where that header doesn't get +> include by some of the other includes present in gen.c, by luck, fix it. +> + +**[v12: bpf-next: Relax tracing prog recursive attach rules](http://lore.kernel.org/bpf/20240103190559.14750-1-9erthalion6@gmail.com/)** + +> Currently, it's not allowed to attach an fentry/fexit prog to another +> fentry/fexit. At the same time it's not uncommon to see a tracing +> program with lots of logic in use, and the attachment limitation +> prevents usage of fentry/fexit for performance analysis (e.g. with +> "bpftool prog profile" command) in this case. An example could be +> falcosecurity libs project that uses tp_btf tracing programs for +> offloading certain part of logic into tail-called programs, but the +> use-case is still generic enough -- a tracing program could be +> complicated and heavy enough to warrant its profiling, yet frustratingly +> it's not possible to do so use best tooling for that. +> + +**[v2: bpf-next: inline asm helpers to access array elements](http://lore.kernel.org/bpf/20240103185403.610641-1-brho@google.com/)** + +> Sorry for the delay on this. Discussed in [1]. It's a helper for +> proving to the verifier that your access in the array is valid. Happy +> to change names or whatever. =) +> +> Also added a libbpf helper function for mmapping an mmappable map. +> + +**[v1: bpf-next: bpf: Track aligned st store as imprecise spilled registers](http://lore.kernel.org/bpf/20240102190726.2017424-1-yonghong.song@linux.dev/)** + +> With patch set [1], precision backtracing supports register spill/fill +> to/from the stack. The patch [2] allows initial imprecise register spill +> with content 0. This is a common case for cpuv3 and lower for +> initializing the stack variables with pattern +> r1 = 0 +> *(u64 *)(r10 - 8) = r1 +> and the [2] has demonstrated good verification improvement. +> + +**[v2: bpf-next: Libbpf-side __arg_ctx fallback support](http://lore.kernel.org/bpf/20240102190055.1602698-1-andrii@kernel.org/)** + +> Support __arg_ctx global function argument tag semantics even on older kernels +> that don't natively support it through btf_decl_tag("arg:ctx"). +> +> Patch #1 does a bunch of internal renaming to make internal function naming +> consistent. We were doing it lazily up until now, but mixing single and double +> underscored names are confusing, so let's bite a bullet and get it over the +> finish line in one go. +> + +**[v1: bpf: Improve 11 size determinations](http://lore.kernel.org/bpf/7daa06c8-7d96-4126-a182-ca4c5e67f7a4@web.de/)** + +> Date: Mon, 1 Jan 2024 17:33:55 +0100 +> +> Replace the specification of data structures by pointer dereferences +> as the parameter for the operator “sizeof” to make the corresponding size +> determination a bit safer according to the Linux coding style convention. +> + +### 周边技术动态 + +#### Qemu + +**[v4: target/riscv: deprecate riscv_cpu_options[]](http://lore.kernel.org/qemu-devel/20240105230546.265053-1-dbarboza@ventanamicro.com/)** + +> This new version contains changes due to a rebase with current +> riscv-to-apply.next, after "v13: riscv: RVA22 profiles +> support" was queued. +> +> Most notable change is a new patch (12) that was added to handle +> 'cbop_blocksize' - zicbop was added by the profile work that just got +> queued and was missing from v3. +> + +**[Adding custom CSR to riscv-qemu](http://lore.kernel.org/qemu-devel/MN2PR07MB60808AC0A8A31AF17BE2EBC6C561A@MN2PR07MB6080.namprd07.prod.outlook.com/)** + +> I'm going to add some custom CSRs (Control & Status Registers) to a new RiscV core in qemu. +> Could you please help me understanding if there is any method to do it? +> Should I do it in /target/riscv/cpu_bits.h where all CSRs are defined (and other files, where all standard CSRs implementation reside?) and just put it under a compilation flag for our new core only? +> I don't think so.. as I don't see any similar example for that there. +> Should I add all the related code around these CSRs in dedicated source files and let them built only for our core? +> Please explain.. +> + +#### Buildroot + +**[package/efivar: add BR2_RISCV_64 in _ARCH_SUPPORTS](http://lore.kernel.org/buildroot/20240105130113.45BD8844F1@busybox.osuosl.org/)** + +> commit: https://git.buildroot.net/buildroot/commit/?id=3ab4b55b0a790d4eef105535a0a81410e2c1a842 +> branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master +> +> A RISC-V 64bit EFI defconfig was added in commit 82199551 +> "configs/qemu_riscv64_virt_efi: new defconfig". So efivar can now be +> enabled for this architecture. +> + +**[package/libjxl: bump to version 0.9.0](http://lore.kernel.org/buildroot/20240102085518.6123183C28@busybox.osuosl.org/)** + +> commit: https://git.buildroot.net/buildroot/commit/?id=de8256e3f823307a65494decca8b1cd152819af6 +> branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master +> +> - Drop first patch (not needed since +> https://github.com/libjxl/libjxl/commit/c3a4f9ca89ae59c6265a2f1bf2a6d2a87a71fc16) +> - Drop second patch (already in version) + ## 20231231：第 72 期 ### 内核动态 -- Gitee