From 2b77802ce57874c8b35be3a096561726377963ae Mon Sep 17 00:00:00 2001 From: lucia <11452490+luciafu@user.noreply.gitee.com> Date: Sun, 5 Nov 2023 15:15:43 +0000 Subject: [PATCH] update news/README.md. Signed-off-by: lucia <11452490+luciafu@user.noreply.gitee.com> --- news/README.md | 938 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 938 insertions(+) diff --git a/news/README.md b/news/README.md index 4132946..d1c695f 100644 --- a/news/README.md +++ b/news/README.md @@ -5,6 +5,944 @@ * [2022 年](2022.md) * [2023 年 - 上半年](2023-1st-half.md) +## 20231105：第 67 期 + +### 内核动态 + +#### RISC-V 架构支持 + +**[v1: Solve iommu probe races around iommu_fwspec](http://lore.kernel.org/linux-riscv/0-v1-5f734af130a3+34f-iommu_fwspec_jgg@nvidia.com/)** + +> This is a more complete solution that the first attempt here: +> https://lore.kernel.org/r/1698825902-10685-1-git-send-email-quic_zhenhuah@quicinc.com +> +> I haven't been able to test this on any HW that touches these paths, so if +> some people with HW can help get it in shape it can become non-RFC. +> + +**[v1: DCE/DSE: Add Dead Syscalls Elimination support, part2](http://lore.kernel.org/linux-riscv/cover.1699025537.git.tanyuan@tinylab.org/)** + +> Hi, all +> +> This series aims to add Dead Code Elimination(DCE) based Dead Syscalls +> Elimination(DSE) support, here is the RFC patchset[1]. The whole series +> includes three parts, here is the Part2. +> + +**[v2: perf vendor events riscv: add StarFive Dubhe-80 JSON file](http://lore.kernel.org/linux-riscv/20231103082441.1389842-1-jisheng.teoh@starfivetech.com/)** + +> StarFive's Dubhe-80 supports raw event id 0x00 - 0x22. +> The raw events are enabled through PMU node of DT binding. +> Besides raw event, add standard RISC-V firmware events to +> support monitoring of firmware event. +> + +**[v1: KVM: seftests: Support guest user mode execution and running](http://lore.kernel.org/linux-riscv/20231102155111.28821-1-guang.zeng@intel.com/)** + +> This patch series give a proposal to support guest VM running +> in user mode and in canonical linear address organization as +> well. +> + +**[v3: Add Svadu Extension Support](http://lore.kernel.org/linux-riscv/20231102120129.11261-1-yongxuan.wang@sifive.com/)** + +> Svadu is a RISC-V extension for hardware updating of PTE A/D bits. This +> patch set adds support to enable Svadu extension for both host and guest +> OS. +> + +**[v4: RISC-V: Add MMC support for TH1520 boards](http://lore.kernel.org/linux-riscv/20231101-th1520-mmc-v4-0-86e0216b5994@baylibre.com/)** + +> This series adds support for the MMC controller in the T-Head TH1520 +> SoC, and it enables the eMMC and microSD slot on both the BeagleV +> Ahead and the Sipeed LicheePi 4A. +> +> I tested on top of v6.6 with riscv defconfig. I was able to boot the +> Ahead [1] and LPi4a [2] from eMMC. This patch series also exists as a +> git branch [3]. +> + +**[v10: riscv: Add fine-tuned checksum functions](http://lore.kernel.org/linux-riscv/20231101-optimize_checksum-v10-0-a498577bb969@rivosinc.com/)** + +> Each architecture generally implements fine-tuned checksum functions to +> leverage the instruction set. This patch adds the main checksum +> functions that are used in networking. +> + +**[v9: riscv: Add remaining module relocations and tests](http://lore.kernel.org/linux-riscv/20231101-module_relocations-v9-0-8dfa3483c400@rivosinc.com/)** + +> A handful of module relocations were missing, this patch includes the +> remaining ones. I also wrote some test cases to ensure that module +> loading works properly. Some relocations cannot be supported in the +> kernel, these include the ones that rely on thread local storage and +> dynamic linking. +> + +**[v1: -next: RISC-V: hwprobe: Always use u64 for extension bits](http://lore.kernel.org/linux-riscv/20231101141908.192198-2-ajones@ventanamicro.com/)** + +> Extensions are getting added quickly and their hwprobe bits will soon +> exceed 31 (which pair values accommodate, since they're of type u64). +> However, in one tree, where a bunch of extensions got merged prior to +> zicboz, zicboz already got pushed to bit 32. Pushing it exposed a +> 32-bit compilation bug, since unsigned long was used instead of u64. +> + +**[v1: RISC-V: Provide the frequency of mtime via hwprobe](http://lore.kernel.org/linux-riscv/20231101141103.30682-2-palmer@rivosinc.com/)** + +> A handful of user-visible behavior is based on the frequency of the +> machine-mode time. +> + +**[v1: riscv: Support RANDOMIZE_KSTACK_OFFSET](http://lore.kernel.org/linux-riscv/20231101064423.1906122-1-songshuaishuai@tinylab.org/)** + +> Inspired from arm64's implement -- commit 70918779aec9 +> ("arm64: entry: Enable random_kstack_offset support") +> +> Add support of kernel stack offset randomization while handling syscall, +> the offset is defaultly limited by KSTACK_OFFSET_MAX() (i.e. 10 bits). +> + +**[v2: RT: riscv: add PREEMPT_RT support](http://lore.kernel.org/linux-riscv/20231031143521.441-1-jszhang@kernel.org/)** + +> This series is to add PREEMPT_RT support to riscv. Compared with last +> year's try[1], there are two major changes: +> +> riscv has been converted to Generic Entry. And RT maintainers has +> introduced PREEMPT_AUTO, so its support for riscv as well. +> + +**[v2: soc: sifive: ccache: Add StarFive JH7100 support](http://lore.kernel.org/linux-riscv/20231031141444.53426-1-emil.renner.berthing@canonical.com/)** + +> This series adds support for the StarFive JH7100 SoC to the SiFive cache +> controller driver. The JH7100 was a "development version" of the JH7110 +> used on the BeagleV Starlight and VisionFive V1 boards. It has +> non-coherent peripheral DMAs but was designed before the standard RISC-V +> Zicbom extension, so it neeeds support in this driver for non-standard +> cache management. +> + +**[v10: Refactoring Microchip PCIe driver and add StarFive PCIe](http://lore.kernel.org/linux-riscv/20231031115430.113586-1-minda.chen@starfivetech.com/)** + +> 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: riscv: select ARCH_PROC_KCORE_TEXT](http://lore.kernel.org/linux-riscv/mvmh6m758ao.fsf@suse.de/)** + +> This adds a separate segment for kernel text in /proc/kcore, which has a +> + +**[v6: riscv: tlb flush improvements](http://lore.kernel.org/linux-riscv/20231030133027.19542-1-alexghiti@rivosinc.com/)** + +> This series optimizes the tlb flushes on riscv which used to simply +> flush the whole tlb whatever the size of the range to flush or the size +> of the stride. +> +> Patch 3 introduces a threshold that is microarchitecture specific and +> will very likely be modified by vendors, not sure though which mechanism +> we'll use to do that (dt? alternatives? vendor initialization code?). +> + +**[v4: riscv: Optimize bitops with Zbb extension](http://lore.kernel.org/linux-riscv/20231030063904.2116277-1-xiao.w.wang@intel.com/)** + +> Bitops optimization with specialized instructions is common practice in +> popular ISAs, this patch set uses RISC-V Zbb extension to optimize four +> bitops: __ffs, __fls, ffs and fls. +> +> The first patch rearranges the content in hwcap.h and cpufeature.h, it helps +> to avoid a cyclic header including issue for patch 2. +> + +**[v8: leds: Allwinner A100 LED controller support](http://lore.kernel.org/linux-riscv/20231029212738.7871-1-samuel@sholland.org/)** + +> This series adds bindings and a driver for the RGB LED controller found +> in some Allwinner SoCs, starting with A100. The hardware in the R329 and +> D1 SoCs appears to be identical. +> + +#### 进程调度 + +**[v4: sched/fair: Track current se's EEVDF parameters](http://lore.kernel.org/lkml/20231104090054.124945-1-s921975628@gmail.com/)** + +> I'm sorry that there was an obvious error in the previous submissions +> that caused EEVDF to always be unable to find the eligible se...... +> This patch should address those issues. +> + +**[v5: drm-misc-next: drm/sched: implement dynamic job-flow control](http://lore.kernel.org/lkml/20231102001038.5076-1-dakr@redhat.com/)** + +> Currently, job flow control is implemented simply by limiting the number +> of jobs in flight. Therefore, a scheduler is initialized with a credit +> limit that corresponds to the number of jobs which can be sent to the +> hardware. +> + +**[v1: sched: Don't call any kfree*() API in do_set_cpus_allowed()](http://lore.kernel.org/lkml/20231031001418.274187-1-longman@redhat.com/)** + +> Commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in +> do_set_cpus_allowed()") added a kfree() call to free any user +> provided affinity mask, if present. It was changed later to use +> kfree_rcu() in commit 9a5418bc48ba ("sched/core: Use kfree_rcu() +> in do_set_cpus_allowed()") to avoid a circular locking dependency +> problem. +> + +**[v1: sched/fair: Make the BW replenish timer expire in hardirq context for PREEMPT_RT](http://lore.kernel.org/lkml/20231030145104.4107573-1-vschneid@redhat.com/)** + +> Consider the following scenario under PREEMPT_RT: +> o A CFS task p0 gets throttled while holding read_lock(&lock) +> o A task p1 blocks on write_lock(&lock), making further readers enter the +> slowpath +> o A ktimers or ksoftirqd task blocks on read_lock(&lock) +> +> If the cfs_bandwidth.period_timer to replenish p0's runtime is enqueued on +> the same CPU as one where ktimers/ksoftirqd is blocked on read_lock(&lock), +> this creates a circular dependency. +> + +#### 内存管理 + +**[v1: mm/page_owner: record and dump free_pid and free_tgid](http://lore.kernel.org/linux-mm/20231105071948.44079-1-v-songbaohua@oppo.com/)** + +> While investigating some complex memory allocation and free bugs +> especially in multi-processes and multi-threads cases, from time +> to time, I feel the free stack isn't sufficient as a page can be +> freed by processes or threads other than the one allocating it. +> And other processes and threads which free the page often have +> the exactly same free stack with the one allocating the page. +> + +**[v7: mm: vmscan: try to reclaim swapcache pages if no swap space](http://lore.kernel.org/linux-mm/20231104140313.3418001-1-liushixin2@huawei.com/)** + +> When spaces of swap devices are exhausted, only file pages can be +> reclaimed. But there are still some swapcache pages in anon lru list. +> This can lead to a premature out-of-memory. +> + +**[v2: rfc: mm: convert mm counter to take a folio](http://lore.kernel.org/linux-mm/20231104035522.2418660-1-wangkefeng.wang@huawei.com/)** + +> Make all mm_counter() and mm_counter_file() callers to use a folio, +> then convert mm counter functions to take a folio, which saves lots +> of compound_head() calls. +> + +**[v1: kasan: use stack_depot_put for Generic mode](http://lore.kernel.org/linux-mm/20231103212724.134597-1-andrey.konovalov@linux.dev/)** + +> Evict alloc/free stack traces from the stack depot for Generic KASAN +> once they are evicted from the quaratine. +> +> For auxiliary stack traces, evict the oldest stack trace once a new one +> is saved (KASAN only keeps references to the last two). +> + +**[v1: rfc: mm: convert to use folio mm counter](http://lore.kernel.org/linux-mm/20231103140119.2306578-1-wangkefeng.wang@huawei.com/)** + +> Convert mm counter page functions to folio ones. +> +> mm_counter() -> mm_counter_folio() +> mm_counter_file() -> mm_counter_file_folio() +> +> Maybe it's better to rename folio mm counter function back to mm_counter() +> and mm_counter_file() after all conversion? +> + +**[v2: mm/vmstat: Move pgdemote_* to per-node stats](http://lore.kernel.org/linux-mm/20231103031450.1456523-1-lizhijian@fujitsu.com/)** + +> Demotion will migrate pages across nodes. Previously, only the global +> demotion statistics were accounted for. Changed them to per-node +> statistics, making it easier to observe where demotion occurs on each +> node. +> + +**[v3: zswap: memcontrol: implement zswap writeback disabling](http://lore.kernel.org/linux-mm/20231102234236.1784543-1-nphamcs@gmail.com/)** + +> During our experiment with zswap, we sometimes observe swap IOs due to +> occasional zswap store failures and writebacks-to-swap. These swapping +> IOs prevent many users who cannot tolerate swapping from adopting zswap +> to save memory and improve performance where possible. +> + +**[v9: mm: use memmap_on_memory semantics for dax/kmem](http://lore.kernel.org/linux-mm/20231102-vv-kmem_memmap-v9-0-973d6b3a8f1a@intel.com/)** + +> The dax/kmem driver can potentially hot-add large amounts of memory +> originating from CXL memory expanders, or NVDIMMs, or other 'device +> memories'. There is a chance there isn't enough regular system memory +> available to fit the memmap for this new memory. It's therefore +> desirable, if all other conditions are met, for the kmem managed memory +> to place its memmap on the newly added memory itself. +> + +**[Subject: v1: Demotion Profiling Improvements](http://lore.kernel.org/linux-mm/20231102025648.1285477-1-lizhijian@fujitsu.com/)** + +> With the deployment of high-capacity CXL Type 3 memory, HBM and Nvdimm, +> the kernel now supports memory tiering. Building on this foundation +> and aiming to further enhance memory efficiency, the kernel has +> introduced demotion and promotion features. +> + +**[v1: maple_tree: iterator state changes](http://lore.kernel.org/linux-mm/20231101171629.3612299-1-Liam.Howlett@oracle.com/)** + +> These patches have some general cleanup and a change to separate the +> maple state status tracking from the maple state node. +> +> The maple state status change allows for walks to continue from previous +> places when the status needs to be recorded to make logical sense for +> the next call to the maple state. For instance, it allows for prev/next +> to function in a way that better resembles the linked list. It also +> allows switch statements to be used to detect missed states during +> compile, and the addition of fast-path "active" state is cleaner as an +> enum. +> + +**[v1: mm: memcg: improve vmscan tracepoints](http://lore.kernel.org/linux-mm/20231101102837.25205-1-ddrokosov@salutedevices.com/)** + +> The motivation behind this commit is to enhance the traceability and +> understanding of memcg events. By integrating the function cgroup_name() +> into the existing memcg tracepoints, this patch series introduces a new +> tracepoint template for the begin() and end() events. It utilizes a +> static __array() to store the cgroup name, enabling developers to easily +> identify the cgroup associated with a specific memcg tracepoint event. +> + +**[v1: .mailmap: Add address mapping for Tomeu Vizoso](http://lore.kernel.org/linux-mm/20231031014009.22765-2-bagasdotme@gmail.com/)** + +> He's no longer working in Collabora (and his email address there +> bounces). Map it to his personal address. +> + +**[v3: Weighted Interleave and Node Weights](http://lore.kernel.org/linux-mm/20231031001721.3972-1-gregory.price@memverge.com/)** + +> This patchset implements weighted interleave and adds a new sysfs +> entry: /sys/devices/system/node/nodeN/accessM/il_weight. +> + +**[v2: kpageflags: respect folio head-page flag placement](http://lore.kernel.org/linux-mm/20231030180005.2046-1-gregory.price@memverge.com/)** + +> kpageflags reads page-flags directly from the page, even when the +> respective flag is only updated on the headpage of a folio. +> +> Update bitchecks to use PAGEFLAG() interfaces to check folio for the +> referenced, dirty, lru, active, and unevictable bits. +> + +**[v1: .mailmap: Map Benjamin Poirier's address](http://lore.kernel.org/linux-mm/20231030142454.22127-2-bagasdotme@gmail.com/)** + +> Map out to his gmail address as he had left SUSE some time ago. +> + +**[v1: mm: page_alloc: unreserve highatomic page blocks before oom](http://lore.kernel.org/linux-mm/1698669590-3193-1-git-send-email-quic_charante@quicinc.com/)** + +> __alloc_pages_direct_reclaim() is called from slowpath allocation where +> high atomic reserves can be unreserved after there is a progress in +> reclaim and yet no suitable page is found. Later should_reclaim_retry() +> gets called from slow path allocation to decide if the reclaim needs to +> be retried before OOM kill path is taken. +> + +#### 文件系统 + +**[v2: Handle multi device freezing](http://lore.kernel.org/linux-fsdevel/20231104-vfs-multi-device-freeze-v2-0-5b5b69626eac@kernel.org/)** + +> Now that we can find the owning filesystem of any device if the +> superblock and fs_holder_ops are used we need to handle multi-device +> filesystem freezes. This series does that. Details in the main commit. +> + +**[v9: bpf-next: BPF token and BPF FS-based delegation](http://lore.kernel.org/linux-fsdevel/20231103190523.6353-1-andrii@kernel.org/)** + +> This patch set introduces an ability to delegate a subset of BPF subsystem +> functionality from privileged system-wide daemon (e.g., systemd or any other +> container manager) through special mount options for userns-bound BPF FS to +> a *trusted* unprivileged application. Trust is the key here. This +> functionality is not about allowing unconditional unprivileged BPF usage. +> Establishing trust, though, is completely up to the discretion of respective +> privileged application that would create and mount a BPF FS instance with +> delegation enabled, as different production setups can and do achieve it +> through a combination of different means (signing, LSM, code reviews, etc), +> and it's undesirable and infeasible for kernel to enforce any particular way +> of validating trustworthiness of particular process. +> +> The main motivation for this work is a desire to enable containerized BPF +> applications to be used together with user namespaces. This is currently +> impossible, as CAP_BPF, required for BPF subsystem usage, cannot be namespaced +> or sandboxed, as a general rule. E.g., tracing BPF programs, thanks to BPF +> helpers like bpf_probe_read_kernel() and bpf_probe_read_user() can safely read +> arbitrary memory, and it's impossible to ensure that they only read memory of +> processes belonging to any given namespace. +> + +**[[resend PATCH v4] fuse: share lookup state between submount and its parent](http://lore.kernel.org/linux-fsdevel/20231103173947.GA2059@templeofstupid.com/)** + +> Fuse submounts do not perform a lookup for the nodeid that they inherit +> from their parent. Instead, the code decrements the nlookup on the +> submount's fuse_inode when it is instantiated, and no forget is +> performed when a submount root is evicted. +> + +**[v4: Landlock: IOCTL support](http://lore.kernel.org/linux-fsdevel/20231103155717.78042-1-gnoack@google.com/)** + +> Introduce the LANDLOCK_ACCESS_FS_IOCTL right, which restricts the use +> of ioctl(2) on file descriptors. +> +> We attach IOCTL access rights to opened file descriptors, as we +> already do for LANDLOCK_ACCESS_FS_TRUNCATE. +> +> If LANDLOCK_ACCESS_FS_IOCTL is handled (restricted in the ruleset), +> the LANDLOCK_ACCESS_FS_IOCTL access right governs the use of all IOCTL +> commands. +> + +**[v1: fs: handle freezing from multiple devices](http://lore.kernel.org/linux-fsdevel/20231103-vfs-multi-device-freeze-v1-1-fe922b30bfb6@kernel.org/)** + +> Before [1] freezing a filesystems through the block layer only worked +> for the main block device as the owning superblock of additional block +> devices could not be found. Any filesystem that made use of multiple +> block devices would only be freezable via it's main block device. +> + +**[v1: ida: Allow allocations of contiguous IDs](http://lore.kernel.org/linux-fsdevel/20231102153455.1252-1-michal.wajdeczko@intel.com/)** + +> Some drivers (like i915) may require allocations of contiguous ranges +> of IDs, while current IDA supports only single ID allocation and does +> not guarantee that next returned ID will be next to the previous one. +> + +**[v4: exfat: get file size from DataLength](http://lore.kernel.org/linux-fsdevel/PUZPR04MB6316D39C9404C34756CA368981A6A@PUZPR04MB6316.apcprd04.prod.outlook.com/)** + +> From the exFAT specification, the file size should get from 'DataLength' +> of Stream Extension Directory Entry, not 'ValidDataLength'. +> +> Without this patch set, 'DataLength' is always same with 'ValidDataLength' +> and get file size from 'ValidDataLength'. If the file is created by other +> exFAT implementation and 'DataLength' is different from 'ValidDataLength', +> this exFAT implementation will not be compatible. +> + +**[GIT PULL: sysctl changes for v6.7-rc1](http://lore.kernel.org/linux-fsdevel/ZUKttkQ2%2FhgweOQP@bombadil.infradead.org/)** + +> To help make the move of sysctls out of kernel/sysctl.c not incur a size +> penalty sysctl has been changed to allow us to not require the sentinel, the +> final empty element on the sysctl array. Joel Granados has been doing all this +> work. On the v6.6 kernel we got the major infrastructure changes required to +> support this. For v6.7-rc1 we have all arch/ and drivers/ modified to remove +> the sentinel. +> + +**[v3: 0/7: block: Add config option to not allow writing to mounted devices](http://lore.kernel.org/linux-fsdevel/20231101173542.23597-1-jack@suse.cz/)** + +> This is the third version of the patches to add config option to not allow +> writing to mounted block devices. The new API for block device opening has been +> merged so hopefully this patchset can progress towards being merged. We face +> some issues with necessary btrfs changes (review bandwidth) so this series is +> modified to enable restricting of writes for all other filesystems. Once btrfs +> can merge necessary device scanning changes, enabling the support for +> restricting writes for it is trivial. +> + +**[v1: nilfs2: simplify device handling](http://lore.kernel.org/linux-fsdevel/20231101172739.8676-1-jack@suse.cz/)** + +> We removed all codepaths where s_umount is taken beneath open_mutex and +> bd_holder_lock so don't make things more complicated than they need to +> be and hold s_umount over block device opening. +> + +**[v1: fuse: Introduce sysfs APIs to flush or resend pending requests](http://lore.kernel.org/linux-fsdevel/20231031144043.68534-1-winters.zc@antgroup.com/)** + +> After the fuse daemon crashes, the fuse mount point becomes inaccessible. +> In some production environments, a watchdog daemon is used to preserve +> the FUSE connection's file descriptor (fd). When the FUSE daemon crashes, +> a new FUSE daemon is restarted and takes over the fd from the watchdog +> daemon, allowing it to continue providing services. +> + +**[v1: fs: Clarify "non-RCY" in access_override_creds() comment](http://lore.kernel.org/linux-fsdevel/20231031114728.41485-1-bagasdotme@gmail.com/)** + +> The term is originally intended as a joke that stands for "non-racy". +> This trips new contributors who mistake it for RCU typo [1]. +> +> Replace the term with more-explicit wording. +> + +**[v1: simplifying fast_dput(), dentry_kill() et.al.](http://lore.kernel.org/linux-fsdevel/20231030003759.GW800259@ZenIV/)** + +> Back in 2015 when fast_dput() got introduced, I'd been worried +> about ->d_delete() being exposed to dentries with zero refcount. +> To quote my reply to Linus back then, +> +> "The only potential nastiness I can see here is that filesystem with +> ->d_delete() always returning 1 might be surprised by encountering +> a hashed dentry with zero d_count. I can't recall anything actually +> sensitive to that, and there might very well be no such examples, +> but in principle it might be a problem. Might be a good idea to check +> DCACHE_OP_DELETE before anything else..." +> + +#### 网络设备 + +**[v2: net: ti: icssg-prueth: Add missing icss_iep_put to error path](http://lore.kernel.org/netdev/c8081537-f26a-4147-83f3-0c890e824192@siemens.com/)** + +> Analogously to prueth_remove. +> + +**[v6: net-next: Coalesce mac ocp write/modify calls to reduce spinlock contention](http://lore.kernel.org/netdev/20231104221514.45821-1-mirsad.todorovac@alu.unizg.hr/)** + +> The motivation for these helpers was the locking overhead of 130 consecutive +> r8168_mac_ocp_write() calls in the RTL8411b reset after the NIC gets confused +> if the PHY is powered-down. +> + +**[v4: convert write_threads, write_version and write_ports to netlink commands](http://lore.kernel.org/netdev/cover.1699095665.git.lorenzo@kernel.org/)** + +> Introduce write_threads, write_version and write_ports netlink +> commands similar to the ones available through the procfs. +> + +**[v1: netfilter: nat: add MODULE_DESCRIPTION](http://lore.kernel.org/netdev/20231104034017.14909-1-rdunlap@infradead.org/)** + +> Add a MODULE_DESCRIPTION() to iptable_nat.c to avoid a build warning: +> +> WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/netfilter/iptable_nat.o +> +> This is only exposed when using "W=n". +> + +**[v1: vhost-vdpa: add support for iommufd](http://lore.kernel.org/netdev/20231103171641.1703146-1-lulu@redhat.com/)** + +> This code provides the iommufd support for vdpa device +> This code fixes the bugs from the last version and also add the asid support. rebase on kernel +> v6,6-rc3 +> Test passed in the physical device (vp_vdpa), but there are still some problems in the emulated device (vdpa_sim_net), +> I will continue working on it +> +> The kernel code is +> https://gitlab.com/lulu6/vhost/-/tree/iommufdRFC_v1 +> + +**[v1: iwl-next: ice: periodically kick Tx timestamp interrupt](http://lore.kernel.org/netdev/20231103162943.485467-1-karol.kolacinski@intel.com/)** + +> The E822 hardware for Tx timestamping keeps track of how many +> outstanding timestamps are still in the PHY memory block. It will not +> generate a new interrupt to the MAC until all of the timestamps in the +> region have been read. +> + +**[v1: net: net/sched: act_ct: Always fill offloading tuple iifidx](http://lore.kernel.org/netdev/20231103151410.764271-1-vladbu@nvidia.com/)** + +> Referenced commit doesn't always set iifidx when offloading the flow to +> hardware. Fix the following cases: +> +> - nf_conn_act_ct_ext_fill() is called before extension is created with +> nf_conn_act_ct_ext_add() in tcf_ct_act(). This can cause rule offload with +> unspecified iifidx when connection is offloaded after only single +> original-direction packet has been processed by tc data path. Always fill +> the new nf_conn_act_ct_ext instance after creating it in +> nf_conn_act_ct_ext_add(). +> + +**[v1: Documentation: Document the Netlink spec](http://lore.kernel.org/netdev/20231103135622.250314-1-leitao@debian.org/)** + +> This is a Sphinx extension that parses the Netlink YAML spec files +> (Documentation/netlink/specs/), and generates a rst file to be +> displayed into Documentation pages. +> + +**[v1: net: phy: at803x: add QCA8084 ethernet phy support](http://lore.kernel.org/netdev/20231103123538.15735-1-quic_luoj@quicinc.com/)** + +> Add qca8084 PHY support, which is four-port PHY with maximum +> link capability 2.5G, the features of each port is almost same +> as QCA8081 and slave seed config is not needed. +> + +**[v1: Prevent out-of-bounds read/write in bcmasp_netfilt_rd and bcmasp_netfilt_wr](http://lore.kernel.org/netdev/DB3PR10MB6835E073F668AD24F57AE64AE8A5A@DB3PR10MB6835.EURPRD10.PROD.OUTLOOK.COM/)** + +> The functions `bcmasp_netfilt_rd` and `bcmasp_netfilt_wr` both call +> `bcmasp_netfilt_get_reg_offset` which, when it fails, returns `-EINVAL`. +> This could lead to an out-of-bounds read or write when `rx_filter_core_rl` +> or `rx_filter_core_wl` is called. +> + +**[v2: tg3: power down device only on SYSTEM_POWER_OFF](http://lore.kernel.org/netdev/20231103115029.83273-1-george.shuklin@gmail.com/)** + +> Dell R650xs servers hangs on reboot if tg3 driver calls +> tg3_power_down. +> +> This happens only if network adapters (BCM5720 for R650xs) were +> initialized using SNP (e.g. by booting ipxe.efi). +> + +**[v1: netlink: introduce netlink poll to resolve fast return issue](http://lore.kernel.org/netdev/20231103072209.1005409-1-jongeon.park@samsung.com/)** + +> In very rare cases, there was an issue where a user's poll function +> waiting for a uevent would continuously return very quickly, causing +> excessive CPU usage due to the following scenario. +> + +**[v1: Add Marvell CN10KB/CN10KA B0 support](http://lore.kernel.org/netdev/20231103053306.2259753-1-schalla@marvell.com/)** + +> Marvell OcteonTX2's next gen platform CN10KB/CN10KA B0 +> introduced changes in CPT SG input format(SGv2) to make +> it compatibile with NIX SG input format, to support inline +> IPsec in SG mode. +> + +**[v5: bpf-next: xsk: TX metadata](http://lore.kernel.org/netdev/20231102225837.1141915-1-sdf@google.com/)** + +> This series implements initial TX metadata (offloads) for AF_XDP. +> See patch #2 for the main implementation and mlx5/stmmac ones for the +> example on how to consume the metadata on the device side. +> + +**[v1: drivers/net/ppp: copy userspace array safely](http://lore.kernel.org/netdev/20231102191914.52957-2-pstanner@redhat.com/)** + +> In ppp_generic.c memdup_user() is utilized to copy a userspace array. +> This is done without an overflow check. +> +> Use the new wrapper memdup_array_user() to copy the array more safely. +> + +**[v4: net-next: ethtool: Add ethtool_puts()](http://lore.kernel.org/netdev/20231102-ethtool_puts_impl-v4-0-14e1e9278496@google.com/)** + +> This series aims to implement ethtool_puts() and send out a wave 1 of +> conversions from ethtool_sprintf(). There's also a checkpatch patch +> included to check for the cases listed below. +> + +**[v1: net: nfsd: regenerate user space parsers after ynl-gen changes](http://lore.kernel.org/netdev/20231102185227.2604416-1-kuba@kernel.org/)** + +> Commit 8cea95b0bd79 ("tools: ynl-gen: handle do ops with no input attrs") +> added support for some of the previously-skipped ops in nfsd. +> Regenerate the user space parsers to fill them in. +> + +**[v2: iwl-next: ice: Reset VF on Tx MDD event](http://lore.kernel.org/netdev/20231102155149.2574209-1-pawel.chmielewski@intel.com/)** + +> In cases when VF sends malformed packets that are classified as malicious, +> sometimes it causes Tx queue to freeze. This frozen queue can be stuck +> for several minutes being unusable. This behavior can be reproduced with +> DPDK application, testpmd. +> + +**[v10: net-next: Add Realtek automotive PCIe driver](http://lore.kernel.org/netdev/20231102154505.940783-1-justinlai0215@realtek.com/)** + +> This series includes adding realtek automotive ethernet driver +> and adding rtase ethernet driver entry in MAINTAINERS file. +> + +**[v2: net-next: virtio-net: support dynamic coalescing moderation](http://lore.kernel.org/netdev/cover.1698929590.git.hengqi@linux.alibaba.com/)** + +> Now, virtio-net already supports per-queue moderation parameter +> setting. Based on this, we use the linux dimlib to support +> dynamic coalescing moderation for virtio-net. +> + +**[v1: net/smc: avoid atomic_set and smp_wmb in the tx path when possible](http://lore.kernel.org/netdev/20231102092712.30793-1-lirongqing@baidu.com/)** + +> these is less opportunity that conn->tx_pushing is not 1, since +> tx_pushing is just checked with 1, so move the setting tx_pushing +> to 1 after atomic_dec_and_test() return false, to avoid atomic_set +> and smp_wmb in tx path when possible +> + +**[v1: net: macsec: Abort MACSec Rx offload datapath when skb is not marked with MACSec metadata](http://lore.kernel.org/netdev/20231101200217.121789-1-rrameshbabu@nvidia.com/)** + +> When MACSec is configured on an outer netdev, traffic received directly +> through the underlying netdev should not be processed by the MACSec Rx +> datapath. When using MACSec offload on an outer netdev, traffic with no +> metadata indicator in the skb is mistakenly considered as MACSec traffic +> and incorrectly handled in the handle_not_macsec function. Treat skbs with +> no metadata type as non-MACSec packets rather than assuming they are MACSec +> packets. +> + +**[v1: net: tg3: power down device only on SYSTEM_POWER_OFF](http://lore.kernel.org/netdev/20231101130418.44164-1-george.shuklin@gmail.com/)** + +> Dell R650xs servers hangs if tg3 driver calls tg3_power_down. +> +> This happens only if network adapters (BCM5720 for R650xs) were +> initialized using SNP (e.g. by booting ipxe.efi). +> +> This is partial revert of commit 2ca1c94ce0b. +> + +**[v2: iproute2-next: bridge: mdb: Add get support](http://lore.kernel.org/netdev/20231101074510.1471018-1-idosch@nvidia.com/)** + +> Implement MDB get functionality, allowing user space to query a single +> MDB entry from the kernel instead of dumping all the entries. +> +**[GIT PULL: Networking follow up for 6.7](http://lore.kernel.org/netdev/20231101011812.2653409-1-kuba@kernel.org/)** + +> > Well, I had actually already merged the original pull request, and +> > then started a full allmodconfig build. +> > +> > And because I'm off gallivanting and traveling, that takes 2h on this +> > poor little laptop, so I had left to do more fun things than watch +> > paint dry. +> + +**[v3: net: dsa: tag_rtl4_a: Bump min packet size](http://lore.kernel.org/netdev/20231031-fix-rtl8366rb-v3-1-04dfc4e7d90e@linaro.org/)** + +> It was reported that the "LuCI" web UI was not working properly +> with a device using the RTL8366RB switch. Disabling the egress +> port tagging code made the switch work again, but this is not +> a good solution as we want to be able to direct traffic to a +> certain port. +> + +#### 安全增强 + +**[v7: Initial Marvell PXA1908 support](http://lore.kernel.org/linux-hardening/20231102-pxa1908-lkml-v7-0-cabb1a0cb52b@skole.hr/)** + +> This series adds initial support for the Marvell PXA1908 SoC and +> "samsung,coreprimevelte", a smartphone using the SoC. +> + +**[v2: usb: musb: Check requset->buf before use to avoid crash issue](http://lore.kernel.org/linux-hardening/20231101071421.29462-1-xingxing.luo@unisoc.com/)** + +> When connecting USB to PC, there is a very low probability of kernel +> crash. The reason is that in ep0_txstate(), the buf member of struct +> usb_request used may be a null pointer. Therefore, it needs to +> determine whether it is null before using it. +> + +**[v1: scsi: libfc: replace deprecated strncpy with memcpy](http://lore.kernel.org/linux-hardening/20231030-strncpy-drivers-scsi-libfc-fc_encode-h-v1-1-c08c2be6befa@google.com/)** + +> strncpy() is deprecated [1] and as such we should use different apis to +> copy string data. +> + +#### 异步 IO + +**[v1: io_uring/net: mark socket connected on -EINPROGRESS retry](http://lore.kernel.org/io-uring/8717a010-125e-4f4f-a1e9-8d6ee7b31491@kernel.dk/)** + +> With the removal of the retry on -EINPROGRESS, we're not getting the +> socket marked connected before another connect attempt is made. This +> can result in getting a successful connect completion where we're now +> connected, yet it's not marked as such on the net side. A followup +> connect request would then return '0' rather than -EISCONN, which then +> gets the connectioned marked connected. A second followup would then +> correctly return -EISCONN. +> + +#### Rust For Linux + +**[v3: rust: crates in other kernel directories](http://lore.kernel.org/rust-for-linux/20231104211213.225891-1-yakoyoku@gmail.com/)** + +> This RFC provides makes possible to have bindings for kernel subsystems +> that are compiled as modules. +> +> Previously, if you wanted to have Rust bindings for a subsystem, like +> AMBA for example, you had to put it under `rust/kernel/` so it came +> part of the `kernel` crate, but this came with many downsides. Namely +> if you compiled said subsystem as a module you've a dependency on it +> from `kernel`, which is linked directly on `vmlinux`. +> + +**[v1: Setting up Binder for the future](http://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-0-08ba9197f637@google.com/)** + +> We're generally not proponents of rewrites (nasty uncomfortable things +> that make you late for dinner!). So why rewrite Binder? +> +> Binder has been evolving over the past 15+ years to meet the evolving +> needs of Android. Its responsibilities, expectations, and complexity +> have grown considerably during that time. While we expect Binder to +> continue to evolve along with Android, there are a number of factors +> that currently constrain our ability to develop/maintain it. +> + +**[v1: rust: Ignore preserve-most functions](http://lore.kernel.org/rust-for-linux/20231031201945.1412345-1-mmaurer@google.com/)** + +> Neither bindgen nor Rust know about the preserve-most calling +> convention, and Clang describes it as unstable. Since we aren't using +> functions with this calling convention from Rust, blocklist them. +> +> These functions are only added to the build when list hardening is +> enabled, which is likely why others didn't notice this yet. +> + +**[v1: rust: Suppress searching builtin sysroot](http://lore.kernel.org/rust-for-linux/20231031201752.1189213-1-mmaurer@google.com/)** + +> By default, if Rust is passed `--target=foo` rather than a target.json +> file, it will infer a default sysroot if that component is installed. As +> the proposed aarch64 support uses `aarch64-unknown-none` rather than a +> target.json file, this is needed to prevent rustc from being confused +> between the custom kernel sysroot and the pre-installed one. +> + +#### BPF + +**[v1: bpf: Let BPF verifier consider {task,cgroup} is trusted in bpf_iter_reg](http://lore.kernel.org/bpf/20231105133458.1315620-1-zhouchuyi@bytedance.com/)** + +> The patchset aims to let the BPF verivier consider +> bpf_iter__cgroup->cgroup and bpf_iter__task->task is trused suggested by +> Alexei[1]. +> +> Please see individual patches for more details. And comments are always +> welcome. +> +> Link[1]:https://lore.kernel.org/bpf/20231022154527.229117-1-zhouchuyi@bytedance.com/T/#mb57725edc8ccdd50a1b165765c7619b4d65ed1b0 +> + +**[v1: bpf-next: bpf: Use named fields for certain bpf uapi structs](http://lore.kernel.org/bpf/20231104024900.1539182-1-yonghong.song@linux.dev/)** + +> Martin and Vadim reported a verifier failure with bpf_dynptr usage. +> The issue is mentioned but Vadim workarounded the issue with source +> change ([1]). The below describes what is the issue and why there +> is a verification failure. +> + +**[v1: bpf: Use E2BIG instead of ENOENT](http://lore.kernel.org/bpf/20231104024444.385484-1-chen.dylane@gmail.com/)** + +> Use E2BIG instead of ENOENT when the key size beyond the buckets size, +> it seems more meaningful. +> + +**[v10: bpf-next: Registrating struct_ops types from modules](http://lore.kernel.org/bpf/20231103232202.3664407-1-thinker.li@gmail.com/)** + +> Given the current constraints of the current implementation, +> struct_ops cannot be registered dynamically. This presents a +> significant limitation for modules like coming fuse-bpf, which seeks +> to implement a new struct_ops type. To address this issue, a new API +> is introduced that allows the registration of new struct_ops types +> from modules. +> + +**[v1: selftests: bpf: config.aarch64: disable CONFIG_DEBUG_INFO_REDUCED](http://lore.kernel.org/bpf/20231103220912.333930-1-anders.roxell@linaro.org/)** + +> Building an arm64 kernel and seftests/bpf with defconfig + +> selftests/bpf/config and selftests/bpf/config.aarch64 the fragment +> CONFIG_DEBUG_INFO_REDUCED is enabled in arm64's defconfig, it should be +> disabled in file sefltests/bpf/config.aarch64 since if its not disabled +> CONFIG_DEBUG_INFO_BTF wont be enabled. +> + +**[v1: bpf-next: libbpf: bpftool: Emit aligned(8) attr for empty struct in btf source dump](http://lore.kernel.org/bpf/20231103055218.2395034-1-yonghong.song@linux.dev/)** + +> Martin and Vadim reported a verifier failure with bpf_dynptr usage. +> The issue is mentioned but Vadim workarounded the issue with source +> change ([1]). The below describes what is the issue and why there +> is a verification failure. +> + +**[v1: bpf-next: BPF register bounds range vs range support](http://lore.kernel.org/bpf/20231103000822.2509815-1-andrii@kernel.org/)** + +> This patch set is a continuation of work started in [0]. It adds a big set of +> manual, auto-generated, and now also random test cases validating BPF +> verifier's register bounds tracking and deduction logic. +> + +**[v2: tools/build: Add clang cross-compilation flags to feature detection](http://lore.kernel.org/bpf/20231102103252.247147-1-bjorn@kernel.org/)** + +> When a tool cross-build has LLVM=1 set, the clang cross-compilation +> flags are not passed to the feature detection build system. This +> results in the host's features are detected instead of the targets. +> + +**[v6: bpf-next: BPF register bounds logic and testing improvements](http://lore.kernel.org/bpf/20231102033759.2541186-1-andrii@kernel.org/)** + +> This patch set adds a big set of manual and auto-generated test cases +> validating BPF verifier's register bounds tracking and deduction logic. See +> details in the last patch. +> + +**[v7: Reduce overhead of LSMs with static calls](http://lore.kernel.org/bpf/20231102005521.346983-1-kpsingh@kernel.org/)** + +> LSM hooks (callbacks) are currently invoked as indirect function calls. These +> callbacks are registered into a linked list at boot time as the order of the +> LSMs can be configured on the kernel command line with the "lsm=" command line +> parameter. +> + +**[v1: bpf-next: bpf: handle ldimm64 properly in check_cfg()](http://lore.kernel.org/bpf/20231101205626.119243-1-andrii@kernel.org/)** + +> ldimm64 instructions are 16-byte long, and so have to be handled +> appropriately in check_cfg(), just like the rest of BPF verifier does. +> + +### 周边技术动态 + +#### Qemu + +**[v2: Support RISC-V IOPMP](http://lore.kernel.org/qemu-devel/20231102094015.208588-1-ethan84@andestech.com/)** + +> This series implements IOPMP specification v1.0.0-draft4 rapid-k model. +> +> When IOPMP is enabled, a DMA device ATCDMAC300 is added to RISC-V virt +> platform. This DMA devce is connected to the IOPMP and has the functionalities +> required by IOPMP, including: +> - Support specify source-id (SID) +> - Support asynchronous I/O to handle stall transcations +> + +**[v1: target/riscv/kvm: add zicsr, zifencei, zba, zbs, svnapot](http://lore.kernel.org/qemu-devel/20231031205150.208405-1-dbarboza@ventanamicro.com/)** + +> These regs were added in Linux 6.6. +> + +#### U-Boot + +**[v1: riscv: Add support for AMD/Xilinx MicroBlaze V](http://lore.kernel.org/u-boot/41c2fda5d6f96e44188d912811a63b8a40625e6e.1699027398.git.michal.simek@amd.com/)** + +> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP. +> It is hardware compatible with classic MicroBlaze processor. +> + +**[v2: doc: falcon: riscv: Falcon Mode boot on RISC-V](http://lore.kernel.org/u-boot/20231102111028.1723775-1-randolph@andestech.com/)** + +> Add documentation to introduce the Falcon Mode on RISC-V. +> In this mode, the boot sequence is SPL -> OpenSBI -> Linux kernel. +> + +**[GIT PULL: u-boot-riscv/master](http://lore.kernel.org/u-boot/ZUN-1ADrFIKePtRs@swlinux02/)** + +> The following changes since commit a803f87202aa48974bdff4d8100464a8288931e4: +> +> Merge https://source.denx.de/u-boot/custodians/u-boot-mmc (2023-11-01 09:44:33 -0400) +> + +**[v4: Add support for StarFive JH7110 TRNG driver](http://lore.kernel.org/u-boot/20231101121652.1865516-1-chanho61.park@samsung.com/)** + +> This patchset adds to support StarFive JH7110 TRNG driver. Due to lack +> of readl_relaxed API, the first patch tries to import the +> APIs(read/write_relaxed) from Linux kernel's implementation. The second +> patch adds the missing security clocks which are required by the trng +> IP. +> + +**[v1: Support JTAG for VisionFive2 board](http://lore.kernel.org/u-boot/20231031085600.992544-1-chanho61.park@samsung.com/)** + +> To support JTAG for VisionFive2 board, we need to control JTAG pins by +> S/W. spl_board_init_f function seems to be proper place to initialize +> these pins. +> + +**[v1: riscv: Weakly define invalidate_icache_range()](http://lore.kernel.org/u-boot/20231031053723.64301-1-samuel@sholland.org/)** + +> Some RISC-V CPUs, such as the T-HEAD XuanTie series, have a +> vendor-specific way to invalidate a portion of the instruction cache. +> Allow them to override invalidate_icache_range(). +> + +**[v1: riscv: Align the trap handler to 64 bytes](http://lore.kernel.org/u-boot/20231031053603.64062-1-samuel@sholland.org/)** + +> This is required on CPUs which always operate in CLIC mode, such as the +> T-HEAD E906 and E907. Per the CLIC specification: "In this mode, the +> trap vector base address held in mtvec is constrained to be aligned on a +> 64-byte or larger power-of-two boundary." +> + +**[v1: riscv: Sort target configs alphabetically](http://lore.kernel.org/u-boot/20231031053219.63764-1-samuel@sholland.org/)** + +> Clean things up for the next time somebody adds a target. +> + +**[v1: clk: sunxi: Use the right symbol in the Makefile](http://lore.kernel.org/u-boot/20231031044925.51756-1-samuel@sholland.org/)** + +> CONFIG_ARCH_SUNXI will not be enabled for RISC-V SoCs using this driver. +> Use the symbol for the driver itself instead. +> + ## 20231029：第 66 期 ### 内核动态 -- Gitee