From fd9815d6d884a59684df8d04afe4c32623d4541a Mon Sep 17 00:00:00 2001 From: yooyoyo <11251868+yooyoyo@user.noreply.gitee.com> Date: Sun, 26 Feb 2023 15:01:43 +0000 Subject: [PATCH] update news/README.md. Signed-off-by: yooyoyo <11251868+yooyoyo@user.noreply.gitee.com> --- news/README.md | 897 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 897 insertions(+) diff --git a/news/README.md b/news/README.md index 6fa4519..ab865a4 100644 --- a/news/README.md +++ b/news/README.md @@ -4,6 +4,903 @@ * [2022 年](2022.md) +## 20230226：第 35 期 + +### 内核动态 + +#### RISC-V 架构支持 + +* [v14: -next: riscv: Add vector ISA support](http://lore.kernel.org/linux-riscv/20230224170118.16766-1-andy.chiu@sifive.com/) + + This patchset is implemented based on vector 1.0 spec to add vector support + in riscv Linux kernel. There are some assumptions for this implementations. + +* [v6: RISC-V: Apply Zicboz to clear_page](http://lore.kernel.org/linux-riscv/20230224162631.405473-1-ajones@ventanamicro.com/) + + When the Zicboz extension is available we can more rapidly zero naturally + aligned Zicboz block sized chunks of memory. As pages are always page + aligned and are larger than any Zicboz block size will be, then + clear_page() appears to be a good candidate for the extension. + +* [v1: RESEND: RISC-V: enable rust](http://lore.kernel.org/linux-riscv/20230224135044.2882109-1-conor.dooley@microchip.com/) + + This is a somewhat blind (and maybe foolish) attempt at enabling Rust + for RISC-V. I've tested this on Icicle, and the modules seem to work. + +* [v1: RISC-V: mm: Support huge page in vmalloc_fault()](http://lore.kernel.org/linux-riscv/20230224104001.2743135-1-dylan@andestech.com/) + + RISC-V supports ioremap() with huge page (pud/pmd) mapping, but + vmalloc_fault() assumes that the vmalloc range is limited to pte + mappings. Add huge page support to complete the vmalloc_fault() function. + +* [v7: riscv: Allow to downgrade paging mode from the command line](http://lore.kernel.org/linux-riscv/20230224100218.1824569-1-alexghiti@rivosinc.com/) + + This new version gets rid of the limitation that prevented KASAN kernels + to use the newly introduced parameters. +* [v2: RISC-V: Stop emitting attributes](http://lore.kernel.org/linux-riscv/20230223224605.6995-1-palmer@rivosinc.com/) + + The RISC-V ELF attributes don't contain any useful information. New + toolchains ignore them, but they frequently trip up various older/mixed + toolchains. So just turn them off. + +* [v1: RISC-V: avoid build issues for clang/llvm-17 with binutils 2.35](http://lore.kernel.org/linux-riscv/20230223220546.52879-1-conor@kernel.org/) + + Here's an attempted (interim?) fix for issues on v5.10 due to the + presence of zifencei & zicsr in object files. + +* [v2: Use dma_default_coherent for devicetree default coherency](http://lore.kernel.org/linux-riscv/20230223113644.23356-1-jiaxun.yang@flygoat.com/) + + This series split out second half of my previous series + "v1: MIPS DMA coherence fixes". + + It intends to use dma_default_coherent to determine the default coherency of + devicetree probed devices instead of hardcoding it with Kconfig options. + +* [v2: Add JH7110 MIPI DPHY RX support](http://lore.kernel.org/linux-riscv/20230223015952.201841-1-changhuang.liang@starfivetech.com/) + + This patchset adds mipi dphy rx driver for the StarFive JH7110 SoC. + It is used to transfer CSI camera data. The series has been tested on + the VisionFive 2 board. + +* [v1: MAINTAINERS: add missing clock driver coverage for Microchip FPGAs](http://lore.kernel.org/linux-riscv/20230222124610.257101-1-conor.dooley@microchip.com/) + + When the CCC support was added, the clock binding coverage was + converted to a regex in commit 71c8517e004b ("MAINTAINERS: update + polarfire soc clock binding"), but the coverage for the clock drivers + themselves was not updated. Rectify that now. + +* [v1: RESEND: scripts/gdb: add lx_current support for riscv](http://lore.kernel.org/linux-riscv/20230222093730.1826523-1-suagrfillet@gmail.com/) + + RISC-V uses the tp register to save the current task_struct address + as its current() defines. So lx_current() of riscv just returns the + dereference of the address cast via task_ptr_type. + +* [v17: -next: riscv: Add GENERIC_ENTRY support](http://lore.kernel.org/linux-riscv/20230222033021.983168-1-guoren@kernel.org/) + + The patches convert riscv to use the generic entry infrastructure from + kernel/entry/*. Some optimization for entry.S with new .macro and merge + ret_from_kernel_thread into ret_from_fork. + +* [v3: RISC-V Hardware Probing User Interface](http://lore.kernel.org/linux-riscv/20230221190858.3159617-1-evan@rivosinc.com/) + + There's been a bunch of off-list discussions about this, including at Plumbers. + + Instead this patch set takes a very different approach and provides a set + of key/value pairs that encode various bits about the system. + +* [v1: Add PLL clocks driver for StarFive JH7110](http://lore.kernel.org/linux-riscv/20230221141147.303642-1-xingyu.wu@starfivetech.com/) + + This patch serises are to add PLL clocks driver and modify + the system clock driver to depend on PLL clocks driver for the + StarFive JH7110 RISC-V SoC. + +* [v2: Add DMA driver for StarFive JH7110 SoC](http://lore.kernel.org/linux-riscv/20230221140424.719-1-walker.chen@starfivetech.com/) + + This patch series adds dma support for the StarFive JH7110 RISC-V SoC. + The first patch adds device tree binding. The second patch includes dma + driver. The last patch adds device node of dma to JH7110 dts. + +* [v3: bpf-next: riscv, bpf: Add kfunc support for RV64](http://lore.kernel.org/linux-riscv/20230221140656.3480496-1-pulehui@huaweicloud.com/) + + This patch adds kernel function call support for RV64. Since the offset + from RV64 kernel and module functions to bpf programs is almost within + the range of s32, the current infrastructure of RV64 is already + sufficient for kfunc, so let's turn it on. + +* [v1: Add PTP support for sama7g5](http://lore.kernel.org/linux-riscv/20230221092104.730504-1-durai.manickamkr@microchip.com/) + + This patch series is intended to add PTP capability to the GEM and + EMAC for sama7g5. + +* [v2: Add new partial clock and reset drivers for StarFive JH7110](http://lore.kernel.org/linux-riscv/20230221083323.302471-1-xingyu.wu@starfivetech.com/) + + This patch serises are to add new partial clock drivers and reset + supports about System-Top-Group(STG), Image-Signal-Process(ISP) + and Video-Output(VOUT) for the StarFive JH7110 RISC-V SoC. + +* [v4: Basic clock, reset & device tree support for StarFive JH7110 RISC-V SoC](http://lore.kernel.org/linux-riscv/20230221024645.127922-1-hal.feng@starfivetech.com/) + + This patch series adds basic clock, reset & DT support for StarFive + JH7110 SoC. Patch 17 depends on series [1] which provides pinctrl + dt-bindings. Patch 19 depends on series [2] which provides dt-bindings + of VisionFive 2 board and JH7110 SoC. + +* [v4: RISC-V Hibernation Support](http://lore.kernel.org/linux-riscv/20230221023523.1498500-1-jeeheng.sia@starfivetech.com/) + + This series adds RISC-V Hibernation/suspend to disk support. + Low level Arch functions were created to support hibernation. + +* [v3: Add watchdog driver for StarFive JH7110 RISC-V SoC](http://lore.kernel.org/linux-riscv/20230220081926.267695-1-xingyu.wu@starfivetech.com/) + + This patch serises are to add watchdog driver for the StarFive JH7110 + RISC-V SoC. The first patch adds docunmentation to describe device + tree bindings. The subsequent patch adds watchdog driver and support + JH7110 SoC. And the addition of device tree node will be submitted + after the JH7110 dts merge. This patchset is based on 6.2. + +#### 进程调度 + +* [v1: net: net/sched: cls_api: Move call to tcf_exts_miss_cookie_base_destroy()](http://lore.kernel.org/lkml/20230224-cls_api-wunused-function-v1-1-12c77986dc2d@kernel.org/) + + Move the call to tcf_exts_miss_cookie_base_destroy() in + tcf_exts_destroy() out of the '#ifdef CONFIG_NET_CLS_ACT', so that it + always appears used to the compiler, while not changing any behavior + with any of the various configuration combinations. + +* [v3: sched/fair: Interleave cfs bandwidth timers for improved single thread performance at low utilization](http://lore.kernel.org/lkml/20230223185918.1500132-1-sshegde@linux.vnet.ibm.com/) + + CPU cfs bandwidth controller uses hrtimer. Currently there is no initial + value set. Hence all period timers would align at expiry. + This happens when there are multiple CPU cgroup's. + +* [v1: kernel/sched/core.c: Modified prio_less().](http://lore.kernel.org/lkml/CAHOvCC7yjceArav9Ps0v1EP4CjfkrxbfXFgABK54cdFKNoE8iw@mail.gmail.com/) + + The sched_class structure is defined to be sorted by pointer size. + + This matches the sched class priority. + In the prio_less() function in kernel/sched/core.c, + the less value can be determined by pointer operation as follows. + +#### 内存管理 + +* [v1: cifs: Improve use of filemap_get_folios_tag()](http://lore.kernel.org/linux-mm/2244151.1677251586@warthog.procyon.org.uk/) + + The inefficiency derived from filemap_get_folios_tag() get a batch of + contiguous folios in Vishal's change to afs that got copied into cifs can + be reduced by skipping over those folios that have been passed by the start + position rather than going through the process of locking, checking and + trying to write them. + +* [v1: mm: hugetlb_vmemmap: simplify hugetlb_vmemmap_init() a bit](http://lore.kernel.org/linux-mm/20230223065947.64134-1-songmuchun@bytedance.com/) + + The check of IS_ENABLED(CONFIG_PROC_SYSCTL) is unnecessary since + register_sysctl_init() will be empty in this case. So, there is + no warnings after removing the check. + +* [v1: [nvdimm][crash] pmem memmap dump support](http://lore.kernel.org/linux-mm/3c752fc2-b6a0-2975-ffec-dba3edcf4155@fujitsu.com/) + + This mail raises a pmem memmap dump requirement and possible solutions, but they are all still premature. + I really hope you can provide some feedback. + + pmem memmap can also be called pmem metadata here. + +* [v2: tmpfs: add the option to disable swap](http://lore.kernel.org/linux-mm/20230223024412.3522465-1-mcgrof@kernel.org/) + + This adds noswap support to tmpfs. This follows up the first RFC [0], + you can look at that link for details of the testing done. On this + v2 I've addressed the feedback provided by Matthew Wilcox and Yosry Ahmed. + +* [v1: RFC: mm: pagemap: add vma(VM_PFNMAP) support in pagemap_pte_hole()](http://lore.kernel.org/linux-mm/20230223024332.1337578-1-sunke@kylinos.cn/) + + pagemap currently does not support vma(FIXMAP), add support + in pagemap_pte_hole(). + +* [v2: mm: userfaultfd: refactor and add UFFDIO_CONTINUE_MODE_WP](http://lore.kernel.org/linux-mm/20230223005754.2700663-1-axelrasmussen@google.com/) + + The refactors are sorted by increasing controversial-ness, the idea being we + could drop some of the refactors if they are deemed not worth it. + +* [v2: mm/khugepaged: alloc_charge_hpage() take care of mem charge errors](http://lore.kernel.org/linux-mm/20230222195247.791227-1-peterx@redhat.com/) + + If memory charge failed, instead of returning the hpage but with an error, + allow the function to cleanup the folio properly, which is normally what a + function should do in this case - either return successfully, or return + with no side effect of partial runs with an indicated error. + +* [v1: swiotlb: mark swiotlb_memblock_alloc() as __init](http://lore.kernel.org/linux-mm/20230222070411.6186-1-rdunlap@infradead.org/) + + swiotlb_memblock_alloc() calls memblock_alloc(), which calls + (__init) memblock_alloc_try_nid(). However, swiotlb_membloc_alloc() + can be marked as __init since it is only called by swiotlb_init_remap(), + which is already marked as __init. + +* [v8: tracing/user_events: Remote write ABI](http://lore.kernel.org/linux-mm/20230221211143.574-1-beaub@linux.microsoft.com/) + + As part of the discussions for user_events aligned with user space + tracers, it was determined that user programs should register a aligned + value to set or clear a bit when an event becomes enabled. Currently a + shared page is being used that requires mmap(). Remove the shared page + implementation and move to a user registered address implementation. + +* [v1: dmapool: push new blocks in ascending order](http://lore.kernel.org/linux-mm/20230221165400.1595247-1-kbusch@meta.com/) + + Some users of the dmapool need their allocations to happen in ascending + order. The recent optimizations pushed the blocks in reverse order, so + restore the previous behavior by linking the next available block from + low-to-high. + +* [Sv: v1: mm/memcontrol: add memory.peak in cgroup root](http://lore.kernel.org/linux-mm/DB4PR02MB93344BAA949FA7E25E298C90FEA59@DB4PR02MB9334.eurprd02.prod.outlook.com/) + + Thanks for the quick response! I think we are just trying to get the same value that was available for us in cgroup v1 memory.max_usage_in_bytes. I guess this value also is incomplete for representing the system memory usage. Is it due the incompleteness that the memory.peak has been left out in the root of cgroup v2? + +* [v1: mm/hwpoison: convert TTU_IGNORE_HWPOISON to TTU_HWPOISON](http://lore.kernel.org/linux-mm/20230221085905.1465385-1-naoya.horiguchi@linux.dev/) + + After a memory error happens on a clean folio, a process unexpectedly + receives SIGBUS when it accesses to the error page. This SIGBUS killing + is pointless and simply degrades the level of RAS of the system, because + the clean folio can be dropped without any data lost on memory error + handling as we do for a clean pagecache. + +* [v1: mm: slub: make kobj_type structure constant](http://lore.kernel.org/linux-mm/20230220-kobj_type-mm-slub-v1-1-5ae49b96d9aa@weissschuh.net/) + + Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.") + the driver core allows the usage of const struct kobj_type. + + Take advantage of this to constify the structure definition to prevent + modification at runtime. + +* [v1: mm/zsmalloc: Split zsdesc from struct page](http://lore.kernel.org/linux-mm/20230220132218.546369-1-42.hyeyoo@gmail.com/) + + The purpose of this series is to define own memory descriptor for zsmalloc, + instead of re-using various fields of struct page. This is a part of the + effort to reduce the size of struct page to unsigned long and enable + dynamic allocation of memory descriptors. + +* [v2: Add tests for memblock_alloc_node()](http://lore.kernel.org/linux-mm/59d4745b-7b2-bf6-7b8-f6571d78d336@mail.polimi.it/) + + This test is aimed at verifying the memblock_alloc_node() to work as + expected, so setting the correct NUMA node for the new allocated + region. The memblock_alloc_node() is called directly without using any + stub. The core check is between the requested NUMA node and the `nid` field inside the memblock_region structure. +* [v10: cachestat: a new syscall for page cache state of files](http://lore.kernel.org/linux-mm/20230219073318.366189-1-nphamcs@gmail.com/) + + There is currently no good way to query the page cache state of large + file sets and directory trees. There is mincore(), but it scales poorly: + the kernel writes out a lot of bitmap data that userspace has to + aggregate, when the user really doesn not care about per-page information + in that case. The user also needs to mmap and unmap each file as it goes + along, which can be quite slow as well. + +#### 文件系统 + +* [v1: SSDFS: flash-friendly LFS file system for ZNS SSD](http://lore.kernel.org/linux-fsdevel/20230225010927.813929-1-slava@dubeyko.com/) + + I am completely aware that patchset is big. And I am opened for any + advices how I can split the patchset on reasonable portions with + the goal to introduce SSDFS for the review. Even now, I excluded + the code of several subsystems to make the patchset slightly + smaller. Potentially, I can introduce SSDFS by smaller portions + with limited fucntionality. However, it can confuse and makes it + hard to understand how declared goals are achieved by implemented functionality. + +* [[RESEND v2 PATCH] init/do_mounts.c: add virtiofs root fs support](http://lore.kernel.org/linux-fsdevel/20230224143751.36863-1-david@ixit.cz/) + + Make it possible to boot directly from a virtiofs file system with tag + 'myfs' using the following kernel parameters: + + rootfstype=virtiofs root=myfs rw + + Booting directly from virtiofs makes it possible to use a directory on + the host as the root file system. This is convenient for testing and + situations where manipulating disk image files is cumbersome. + +* [git pull: vfs.git misc bits](http://lore.kernel.org/linux-fsdevel/Y%2FgxyQA+yKJECwyp@ZenIV/) + + That should cover the rest of what I had in -next; I'd been sick for + several weeks, so a lot of pending stuff I hoped to put into -next + is going to miss this window ;-/ + + Al, off to deal with the remaining pile in the mailbox... + +* [GIT PULL: iomap: new code for 6.3](http://lore.kernel.org/linux-fsdevel/167703901677.1909640.1798642413122202835.stg-ugh@magnolia/) + + Please pull this branch with changes for iomap for 6.3-rc1. This is + mostly rearranging things to make life easier for gfs2, nothing all that + mindblowing for this release. + + As usual, I did a test-merge with the main upstream branch as of a few + minutes ago, and didn't see any conflicts. Please let me know if you + encounter any problems. + +* [v1: Minor documentation clean-up in fs](http://lore.kernel.org/linux-fsdevel/20230220170210.15677-1-lukas.bulwahn@gmail.com/) + + please pick this minor documentation clean-up in fs. It is not in the + Documentation directory, but I would consider these README files also some unsorted largely distributed kernel documentation. + + +* [v7: Implement copy offload support](http://lore.kernel.org/linux-fsdevel/20230220105336.3810-1-nj.shetty@samsung.com/) + + The patch series covers the points discussed in November 2021 virtual + call [LSF/MM/BFP TOPIC] Storage: Copy Offload [0]. + We have covered the initial agreed requirements in this patchset and + further additional features suggested by community. + Patchset borrows Mikulas's token based approach for 2 bdev + implementation. + +* [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. + +#### 网络设备 + +* [v12: bpf-next: Add skb + xdp dynptrs](http://lore.kernel.org/netdev/20230226085120.3907863-1-joannelkoong@gmail.com/) + + This patchset is the 2nd in the dynptr series. The 1st can be found here [0]. + + When comparing the differences in runtime for packet parsing without dynptrs + vs. with dynptrs, there is no noticeable difference. Patch 9 contains more + details as well as examples of how to use skb and xdp dynptrs. + +* [v1: r8169: disable ASPM during NAPI poll](http://lore.kernel.org/netdev/af076f1f-a034-82e5-8f76-f3ec32a14eaa@gmail.com/) + + This is a rework of ideas from Kai-Heng on how to avoid the known + ASPM issues whilst still allowing for a maximum of ASPM-related power + savings. As a prerequisite some locking is added first. + +* [v9: net-next: r8169: Temporarily disable ASPM on NAPI poll](http://lore.kernel.org/netdev/20230225034635.2220386-1-kai.heng.feng@canonical.com/) + + The series is to temporarily disable ASPM on NAPI poll, so the NIC can + "regain" the performace loss when ASPM is enabled. The idea is from + Realtek vendor driver's feature "dynamic ASPM" . + + We have "dynamic ASPM" mechanism in Ubuntu 22.04 LTS kernel for quite a + while, and AFAIK it hasn't introduced any regression so far. + +* [v1: iproute2: genl: print caps for all families](http://lore.kernel.org/netdev/20230225003754.1726760-1-kuba@kernel.org/) + + Back in 2006 kernel commit 334c29a64507 ("[GENETLINK]: Move + command capabilities to flags.") removed some attributes and + moved the capabilities to flags. Corresponding iproute2 + commit 26328fc3933f ("Add controller support for new features + exposed") added the ability to print those caps. + + Printing is gated on version of the family, but we're checking + the version of each individual family rather than the control + family. The format of attributes in the control family + is dictated by the version of the control family alone. + +* [v3: Self-encapsulate the thermal zone device structure](http://lore.kernel.org/netdev/20230224210634.3994365-1-daniel.lezcano@linaro.org/) + + The exported thermal headers expose the thermal core structure while those + should be private to the framework. The initial idea was the thermal sensor + drivers use the thermal zone device structure pointer to pass it around from + the ops to the thermal framework API like a handler. + + * v2: [kernel: Clear workqueue to avoid use-after-free](http://lore.kernel.org/netdev/20230224195313.1877313-1-jiangzp@google.com/) + + After the hci_sync rework, cmd_sync_work was cleared when calling + hci_unregister_dev, but not when powering off the adapter. + Use-after-free errors happen when a work is still scheduled + when cmd is freed by __mgmt_power_off. + +* [v5: Another crack at a handshake upcall mechanism](http://lore.kernel.org/netdev/167726551328.5428.13732817493891677975.stgit@91.116.238.104.host.secureserver.net/) + + Here is v5 of a series to add generic support for transport layer + security handshake on behalf of kernel socket consumers (user space consumers use a security library directly, of course). + +* [v1: net: avoid indirect memory pressure calls](http://lore.kernel.org/netdev/20230224184606.7101-1-fw@strlen.de/) + + There is a noticeable tcp performance regression (loopback or cross-netns), + seen with iperf3 -Z (sendfile mode) when generic retpolines are needed. + + With SK_RECLAIM_THRESHOLD checks gone number of calls to enter/leave + memory pressure happen much more often. + +* [v1: net: Regressions in Ocelot switch drivers](http://lore.kernel.org/netdev/20230224155235.512695-1-vladimir.oltean@nxp.com/) + + These are 3 patches which resolve a regression in the Seville driver, + one in the Felix driver and a generic one which affects any kernel + compiled with 2 Kconfig options enabled. All of them have in common my + lack of attention during review/testing. The patches touch the DSA, MFD + and MDIO drivers for Ocelot. I think it would be preferable if all + patches went through netdev (with Lee's Ack). + +* [v1: brcmfmac: pcie: Add 4359C0 firmware definition](http://lore.kernel.org/netdev/20230224-topic-brcm_tone-v1-1-333b0ac67934@linaro.org/) + + Some phones from around 2016, as well as other random devices have + this chip called 43956 or 4359C0 or 43596A0, which is more or less + just a rev bump (v9) of the already-supported 4359. Add a corresponding + firmware definition to allow for choosing the correct blob. + +* [v1: net-next: packet: allow MSG_NOSIGNAL in recvmsg](http://lore.kernel.org/netdev/20230224071745.20717-1-equinox@diac24.net/) + + packet_recvmsg() whitelists a bunch of MSG_* flags, which notably does + not include MSG_NOSIGNAL. Unfortunately, io_uring always sets + MSG_NOSIGNAL, meaning AF_PACKET sockets can't be used in io_uring recvmsg(). + +* [v1: linux-next: selftests: net: udpgso_bench_tx: Add test for IP fragmentation of UDP packets](http://lore.kernel.org/netdev/202302241438536013777@zte.com.cn/) + + The UDP GSO bench only tests the performance of userspace payload splitting + and UDP GSO. But we are also concerned about the performance comparing with I. + +* [v2: net-next: sfc: support offloading TC VLAN push/pop actions to the MAE](http://lore.kernel.org/netdev/20230223235026.26066-1-edward.cree@amd.com/) + + EF100 can pop and/or push up to two VLAN tags. + +* [v1: net-next: ibmvnic: Assign XPS map to correct queue index](http://lore.kernel.org/netdev/20230223153944.44969-1-nnac123@linux.ibm.com/) + + When setting the XPS map value for TX queues, use the index of the + transmit queue. + Previously, the function was passing the index of the loop that iterates + over all queues (RX and TX). This was causing invalid XPS map values. + +* [v1: net: net/sched: act_connmark: handle errno on tcf_idr_check_alloc](http://lore.kernel.org/netdev/20230223141639.13491-1-pctammela@mojatatu.com/) + + Smatch reports that 'ci' can be used uninitialized. + The current code ignores errno coming from tcf_idr_check_alloc, which + will lead to the incorrect usage of 'ci'. Handle the errno as it should. + +* [[net PATCH v2] octeontx2-af: Unlock contexts in the queue context cache in case of fault detection](http://lore.kernel.org/netdev/20230223110125.2172509-1-saikrishnag@marvell.com/) + + NDC caches contexts of frequently used queue's (Rx and Tx queues) + contexts. Due to a HW errata when NDC detects fault/poision while + accessing contexts it could go into an illegal state where a cache + line could get locked forever. To makesure all cache lines in NDC + are available for optimum performance upon fault/lockerror/posion + errors scan through all cache lines in NDC and clear the lock bit. + +* [v5: Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets](http://lore.kernel.org/netdev/20230223103614.4137309-4-neeraj.sanjaykale@nxp.com/) + + This adds a driver based on serdev driver for the NXP BT serial protocol + based on running H:4, which can enable the built-in Bluetooth device + inside an NXP BT chip. + + This driver has Power Save feature that will put the chip into sleep state + whenever there is no activity for 2000ms, and will be woken up when any + activity is to be initiated over UART. + +* [v5: Add support for NXP bluetooth chipsets](http://lore.kernel.org/netdev/20230223103614.4137309-1-neeraj.sanjaykale@nxp.com/) + + This patch adds a driver for NXP bluetooth chipsets. + + The driver is based on H4 protocol, and uses serdev APIs. It supports + host to chip power save feature, which is signalled by the host by + asserting break over UART TX lines, to put the chip into sleep state. + +* [[REGRESSION PATCH RFC] net: phy: don't resume PHY via MDIO when iface is not up](http://lore.kernel.org/netdev/20230223070519.2211-1-wsa+renesas@sang-engineering.com/) + + TLDR; Commit 96fb2077a517 ("net: phy: consider that suspend2ram may cut + off PHY power") caused regressions for us when resuming an interface + which is not up. It turns out the problem is another one, the above + commit only makes it visible. The attached patch is probably not the + right fix, but at least is proving my assumptions AFAICS. + +* [v1: net: add no-op for napi_busy_loop if CONFIG_NET_RX_BUSY_POLL=n](http://lore.kernel.org/netdev/20230223012258.1701175-1-jacob.e.keller@intel.com/) + + Commit 7db6b048da3b ("net: Commonize busy polling code to focus on napi_id + instead of socket") introduced napi_busy_loop and refactored sk_busy_loop + to call this new function. The commit removed the no-op implementation of + sk_busy_loop in the #else block for CONFIG_NET_RX_BUSY_POLL, and placed the + declaration of napi_busy_poll inside the # block where sk_busy_loop used to + be declared. + +* [v2: net-next: mlx5 technical debt of hairpin params](http://lore.kernel.org/netdev/20230222230202.523667-1-saeed@kernel.org/) + + As previously discussed, this series provides the switch from debugfs to devlink + params for hairpin. + + Per the discussion in [1], move the hairpin queues control (number and size) + from debugfs to devlink. + + [1] https://lore.kernel.org/all/20230111194608.7f15b9a1@kernel.org/ + +* [v1: 5.4/5.10: mac80211: mesh: embedd mesh_paths and mpp_paths into ieee80211_if_mesh](http://lore.kernel.org/netdev/20230222200301.254791-1-pchelkin@ispras.ru/) + + The null-ptr-deref problem fixed in the following patch is hit on older + branches. + + The patch failed to be initially backported into stable branches older + than 5.15 due to the fix-spell-comment commit ab4040df6efb ("mac80211: fix + some spelling mistakes"). + +* [v1: net: sunhme: Return an error when we are out of slots](http://lore.kernel.org/netdev/20230222170935.1820939-1-seanga2@gmail.com/) + + We only allocate enough space for four devices when the parent is a QFE. If + we couldn't find a spot (because five devices were created for whatever + reason), we would not return an error from probe(). Return ENODEV, which + was what we did before. + +* [v1: can: esd_usb: Improve code readability by means of replacing struct esd_usb_msg with a union](http://lore.kernel.org/netdev/20230222163754.3711766-1-frank.jungclaus@esd.eu/) + + As suggested by Vincent Mailhol, declare struct esd_usb_msg as a union + instead of a struct. Then replace all msg->msg.something constructs, + that make use of esd_usb_msg, with simpler and prettier looking + msg->something variants. + +* [v2: gro: optimise redundant parsing of packets](http://lore.kernel.org/netdev/20230222145917.GA12590@debian/) + + The first commit frees up space in the GRO CB. The second commit reduces the + redundant parsing during the complete phase, using the freed CB space. + + In addition, the second commit contains a fix for a potential problem in BIG + TCP, which is detailed in the commit message itself. + +* [v3: octeontx2-pf: Use correct struct reference in test condition](http://lore.kernel.org/netdev/Y%2FYYkKddeHOt80cO@ubun2204.myguest.virtualbox.org/) + + Fix the typo/copy-paste error by replacing struct variable ah_esp_mask name + by ah_esp_hdr. + Issue identified using doublebitand.cocci Coccinelle semantic patch. + +* [[net PATCH v2] octeontx2-pf: Recalculate UDP checksum for ptp 1-step sync packet](http://lore.kernel.org/netdev/20230222113600.1965116-1-saikrishnag@marvell.com/) + + When checksum offload is disabled in the driver via ethtool, + the PTP 1-step sync packets contain incorrect checksum, since + the stack calculates the checksum before driver updates + PTP timestamp field in the packet. This results in PTP packets + getting dropped at the other end. This patch fixes the issue by + re-calculating the UDP checksum after updating PTP + timestamp field in the driver. + +* [v3: net-next: net: virtio_net: implement exact header length guest feature](http://lore.kernel.org/netdev/20230222080638.382211-1-jiri@resnulli.us/) + + Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when + which when set implicates that device benefits from knowing the exact + size of the header. For compatibility, to signal to the device that + the header is reliable driver also needs to set this feature. + Without this feature set by driver, device has to figure + out the header size itself. + +* [v3: net: stmmac: Premature loop termination check was ignored](http://lore.kernel.org/netdev/87y1oq5es0.fsf@henneberg-systemdesign.com/) + + The premature loop termination check makes sense only in case of the + jump to read_again where the count may have been updated. But + read_again did not include the check. + +* [[net PATCH] octeontx2-af: Unlock contexts in the queue context cache in case of fault detection](http://lore.kernel.org/netdev/20230222065921.1852686-1-saikrishnag@marvell.com/) + + NDC caches contexts of frequently used queue's (Rx and Tx queues) + contexts. Due to a HW errata when NDC detects fault/poision while + accessing contexts it could go into an illegal state where a cache + line could get locked forever. To makesure all cache lines in NDC + are available for optimum performance upon fault/lockerror/posion + errors scan through all cache lines in NDC and clear the lock bit. + +* [v11: bpf-next: Add skb + xdp dynptrs](http://lore.kernel.org/netdev/20230222060747.2562549-1-joannelkoong@gmail.com/) + + When comparing the differences in runtime for packet parsing without dynptrs + vs. with dynptrs, there is no noticeable difference. Patch 9 contains more + details as well as examples of how to use skb and xdp dynptrs. + +#### 安全增强 + +* [v1: next: usb: host: oxu210hp-hcd: Replace fake flex-array with flexible-array member](http://lore.kernel.org/linux-hardening/Y%2FgynI9Wv8RZTD8M@work/) + + Zero-length arrays as fake flexible arrays are deprecated and we are + moving towards adopting C99 flexible-array members instead. + + Transform zero-length array into flexible-array member in struct ehci_regs. + +* [GIT PULL: flexible-array transformations for 6.3-rc1](http://lore.kernel.org/linux-hardening/Y%2FfnjS5eHNauiUUR@work/) + + The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98: + + Linux 6.2-rc2 (2023-01-01 13:53:16 -0800) + + are available in the Git repository at: + + git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git tags/flex-array-transformations-6.3-rc1 + + for you to fetch changes up to b942a520d9e43bc31f0808d2f2267a1ddba75518: + + bcache: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helper (2023-01-05 17:48:45 -0600) + + flexible-array transformations for 6.3-rc1 + + Please, pull the following patches that transform zero-length arrays, + in unions, into flexible arrays. These patches have been baking in + linux-next for the whole development cycle. + +* [v1: wifi: iwlwifi: dvm: Add struct_group for struct iwl_keyinfo keys](http://lore.kernel.org/linux-hardening/20230218191056.never.374-kees@kernel.org/) + + Function iwlagn_send_sta_key() was trying to write across multiple + structure members in a single memcpy(). Add a struct group "keys" to + let the compiler see the intended bounds of the memcpy, which includes + the tkip keys as well. Silences false positive memcpy() run-time + warning: + + memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16) + +#### 异步 IO + +* [v3: io_uring: Add KASAN support for alloc caches](http://lore.kernel.org/io-uring/20230223164353.2839177-1-leitao@debian.org/) + + This patchset enables KASAN for alloc cache buffers. These buffers are + used by apoll and netmsg code path. These buffers will now be poisoned + when not used, so, if randomly touched, a KASAN warning will pop up. + +* [v1: for-next: io_uring: registered huge buffer optimisations](http://lore.kernel.org/io-uring/cover.1677041932.git.asml.silence@gmail.com/) + + Improve support for registered buffers consisting of huge pages by + keeping them as a single element bvec instead of chunking them into + 4K pages. It improves performance quite a bit cutting CPU cycles on + dma-mapping and promoting a more efficient use of hardware. + +* [v2: Add io_uring & ebpf based methods to implement zero-copy for ublk](http://lore.kernel.org/io-uring/20230222132534.114574-1-xiaoguang.wang@linux.alibaba.com/) + + Normally, userspace block device implementations need to copy data between + kernel block layer's io requests and userspace block device's userspace + daemon. For example, ublk and tcmu both have similar logic, but this + operation will consume cpu resources obviously, especially for large io. + +* [v1: tools/io_uring: tools/io_uring: correctly set "ret" for sq_poll case](http://lore.kernel.org/io-uring/20230221073736.628851-1-ZiyangZhang@linux.alibaba.com/) + + For sq_poll case, "ret" is not initialized or cleared/set. In this way, + output of this test program is incorrect and we can not even stop this + program by pressing CTRL-C. + + Reset "ret" to zero in each submission/completion round, and assign + "ret" to "this_reap". + +* [v1: liburing: test sends with huge pages](http://lore.kernel.org/io-uring/cover.1676941370.git.asml.silence@gmail.com/) + + Add huge pages support for zc send benchmark and huge pages + tests in send-zerocopy.c. + +* [v1: liburing: test/buf-ring: add test for buf ring occupying exactly one page](http://lore.kernel.org/io-uring/20230218184618.70966-1-wlukowicz01@gmail.com/) + + This shows an issue with how the kernel calculates buffer ring sizes + during their registration. + + Allocate two pages, register a buf ring fully occupying the first one, + while protecting the second one to make sure it's not used. The + registration should succeed. + +#### Rust For Linux + +* [v1: rust: xarray: Add an abstraction for XArray](http://lore.kernel.org/rust-for-linux/20230224-rust-xarray-v1-1-80f0904ce5d3@asahilina.net/) + + The XArray is an abstract data type which behaves like a very large + array of pointers. Add a Rust abstraction for this data type. + + The initial implementation uses explicit locking on get operations and + returns a guard which blocks mutation, ensuring that the referenced + object remains alive. + +* [v1: rust: time: New module for timekeeping functions](http://lore.kernel.org/rust-for-linux/20230221-gpu-up-time-v1-1-bf8fe74b7f55@asahilina.net/) + + This module is intended to contain functions related to kernel + timekeeping and time. Initially, this just wraps ktime_get() and + ktime_get_boottime() and returns them as core::time::Duration instances. + This is useful for drivers that need to implement simple retry loops and + timeouts. + +#### BPF + +* [v3: bpf-next: Add support for kptrs in more BPF maps](http://lore.kernel.org/bpf/20230225154010.391965-1-memxor@gmail.com/) + + This set adds support for kptrs in percpu hashmaps, percpu LRU hashmaps, + and local storage maps (covering sk, cgrp, task, inode). + + Tests are expanded to test more existing maps at runtime and also test + the code path for the local storage maps (which is shared by all + implementations). + +* [v2: bpf-next:: Add socket destroy capability](http://lore.kernel.org/bpf/20230223215311.926899-1-aditi.ghag@isovalent.com/) + + This patch adds the capability to destroy sockets in BPF. We plan to use + the capability in Cilium to force client sockets to reconnect when their + remote load-balancing backends are deleted. The other use case is + on-the-fly policy enforcement where existing socket connections prevented + by policies need to be terminated. + +* [v3: blk-ioprio: Introduce promote-to-rt policy](http://lore.kernel.org/bpf/20230223134852.3745349-1-houtao@huaweicloud.com/) + + Since commit a78418e6a04c ("block: Always initialize bio IO priority on + submit"), bio->bi_ioprio will never be IOPRIO_CLASS_NONE when calling + blkcg_set_ioprio(), so there will be no way to promote the io-priority + of one cgroup to IOPRIO_CLASS_RT, because bi_ioprio will always be + greater than or equals to IOPRIO_CLASS_RT. + +* [bpf: RFC for platform specific BPF helper addition](http://lore.kernel.org/bpf/0838bc96-c8a8-c326-a8f0-80240cf6b31a@linux.intel.com/) + + Some background first; on x86 platforms there is a free running TSC + counter which can be used to generate extremely accurate profiling time + stamps. Currently this can be used by BPF programs via hooking into perf + subsystem and reading the value there; however this reduces the accuracy + due to latency + jitter involved with long execution chain, and also the + timebase gets converted into relative from the start of the execution of + the program, instead of getting an absolute system level value. + +* [v2: bpf-next: Transit between BPF TCP congestion controls.](http://lore.kernel.org/bpf/20230223011238.12313-1-kuifeng@meta.com/) + + Previously, BPF struct_ops didn't go off, as even when the user + program creating it was terminated, none of these ever were pinned. + For instance, the TCP congestion control subsystem indirectly + maintains a reference count on the struct_ops of any registered BPF + implemented algorithm. Thus, the algorithm won't be deactivated until + someone deliberately unregisters it. + +* [[RFC/PATCHSET 0/8] perf record: Implement BPF sample filter (v3)](http://lore.kernel.org/bpf/20230222230141.1729048-1-namhyung@kernel.org/) + + There have been requests for more sophisticated perf event sample + filtering based on the sample data. Recently the kernel added BPF + programs can access perf sample data and this is the userspace part + to enable such a filtering. + + This still has some rough edges and needs more improvements. But + I'd like to share the current work and get some feedback for the + directions and idea for further improvements. + +* [v2: bpf-next: bpf: bpf memory usage](http://lore.kernel.org/bpf/20230222014553.47744-1-laoar.shao@gmail.com/) + + Currently we can't get bpf memory usage reliably. bpftool now shows the + bpf memory footprint, which is difference with bpf memory usage. The + +* [v1: bpf-next: bpf: Add bpf_cgroup_from_id() kfunc](http://lore.kernel.org/bpf/Y%2FVA+jP0mB5cMZEz@slm.duckdns.org/) + + cgroup ID is an userspace-visible 64bit value uniquely identifying a given + cgroup. As the IDs are used widely, it's useful to be able to look up the + matching cgroups. Add bpf_cgroup_from_id(). + +* [v1: bpf: Add support for absolute value BPF timers](http://lore.kernel.org/bpf/20230221151846.2218217-1-tero.kristo@linux.intel.com/) + + Add a new flag BPF_F_TIMER_ABS that can be passed to bpf_timer_start() + to start an absolute value timer instead of the default relative value. + This makes the timer expire at an exact point in time, instead of a time + with latencies and jitter induced by both the BPF and timer subsystems. + This is useful e.g. in certain time sensitive profiling cases, where we + need a timer to expire at an exact point in time. + +* [v2: bpf-next: net/smc: Introduce BPF injection capability](http://lore.kernel.org/bpf/1676981919-64884-1-git-send-email-alibuda@linux.alibaba.com/) + + This PATCHes attempt to introduce BPF injection capability for SMC, + and add selftest to ensure code stability. + + As we all know that the SMC protocol is not suitable for all scenarios, + especially for short-lived. However, for most applications, they cannot + guarantee that there are no such scenarios at all. Therefore, apps + may need some specific strategies to decide shall we need to use SMC + or not, for example, apps can limit the scope of the SMC to a specific + IP address or port. + +* [v1: net-next: xsk: add linux/vmalloc.h to xsk.c](http://lore.kernel.org/bpf/20230221075140.46988-1-xuanzhuo@linux.alibaba.com/) + + Fix the failure of the compilation under the sh4. + + Because we introduced remap_vmalloc_range() earlier, this has caused + the compilation failure on the sh4 platform. So this introduction of the + header file of linux/vmalloc.h. + +* [v3: bpf-next: libbpf: allow users to set kprobe/uprobe attach mode](http://lore.kernel.org/bpf/20230221025347.389047-1-imagedong@tencent.com/) + + By default, libbpf will attach the kprobe/uprobe eBPF program in the + latest mode that supported by kernel. In this series, we add the support + to let users manually attach kprobe/uprobe in legacy/perf/link mode in + the 1th patch. + + And in the 2th patch, we split the testing 'attach_probe' into multi + subtests, as Andrii suggested. + + In the 3th patch, we add the testings for loading kprobe/uprobe in + +* [v1: bpf-next: libbpf: Document bpf_{btf,link,map,prog}_get_info_by_fd()](http://lore.kernel.org/bpf/20230220234958.764997-1-iii@linux.ibm.com/) + + Replace the short informal description with the proper doc comments. + +* [v1: bbpf: usdt arm arg parsing support](http://lore.kernel.org/bpf/20230220212233.13229-1-puranjay12@gmail.com/) + + Parsing of USDT arguments is architecture-specific; on arm it is + relatively easy since registers used are r[0-10], fp, ip, sp, lr, + pc. Format is slightly different compared to aarch64; forms are + + - "size @ [ reg, #offset ]" for dereferences, for example + "-8 @ [ sp, #76 ]" ; " -4 @ [ sp ]" + - "size @ reg" for register values; for example + "-4@r0" + - "size @ #value" for raw values; for example + "-8@#1" + + Add support for parsing USDT arguments for ARM architecture. + +* [v1: bpf-next: bpf: Check for helper calls in check_subprogs()](http://lore.kernel.org/bpf/20230220163756.753713-1-iii@linux.ibm.com/) + + The condition src_reg != BPF_PSEUDO_CALL && imm == BPF_FUNC_tail_call + may be satisfied by a kfunc call. This would lead to unnecessarily + setting has_tail_call. Use src_reg == 0 instead. + +* [v2: bpf-next: bpf: Allow reads from uninit stack](http://lore.kernel.org/bpf/20230219200427.606541-1-eddyz87@gmail.com/) + + This patch-set modifies BPF verifier to accept programs that read from + uninitialized stack locations, but only if executed in privileged mode. + This provides significant verification performance gains: 30% to 70% less + processed states for big number of test programs. + +### 周边技术动态 + +#### Qemu + +* [v1: Fourth RISC-V PR for QEMU 8.0, Attempt 2](http://lore.kernel.org/qemu-devel/20230224185908.32706-1-palmer@rivosinc.com/) + + The following changes since commit 417296c8d8588f782018d01a317f88957e9786d6: + + tests/qtest/netdev-socket: Raise connection timeout to 60 seconds (2023-02-09 11:23:53 +0000) + + are available in the Git repository at: + + git@github.com:palmer-dabbelt/qemu.git tags/pull-riscv-to-apply-20230224 + + for you to fetch changes up to 8c89d50c10afdd98da82642ca5e9d7af4f1c18bd: + + target/riscv: Fix vslide1up.vf and vslide1down.vf (2023-02-23 14:21:34 -0800) + + Fourth RISC-V PR for QEMU 8.0, Attempt 2 + +* [v8: riscv: Add support for Zicbo[m,z,p] instructions](http://lore.kernel.org/qemu-devel/20230224132536.552293-1-dbarboza@ventanamicro.com/) + + This version has a change in patch 2, proposed by Weiwei Li, where we're + now triggering virt_instruction_fault before triggering illegal_insn + fault from S mode. + +* [v1: target/riscv: Add support for Svadu extension](http://lore.kernel.org/qemu-devel/20230224040852.37109-1-liweiwei@iscas.ac.cn/) + + This patchset adds support svadu extension. It also fixes some relationship between *envcfg fields and Svpbmt/Sstc extensions. + + Specification for Svadu extension can be found in: + + https://github.com/riscv/riscv-svadu + + The port is available here: + https://github.com/plctlab/plct-qemu/tree/plct-svadu-upstream + +* [v2: NUMA: Apply socket-NUMA-node boundary for aarch64 and RiscV machines](http://lore.kernel.org/qemu-devel/20230223081401.248835-1-gshan@redhat.com/) + + For arm64 and RiscV architecture, the driver (/base/arch_topology.c) is + used to populate the CPU topology in the Linux guest. It's required that + the CPUs in one socket can't span mutiple NUMA nodes. Otherwise, the Linux + scheduling domain can't be sorted out, as the following warning message + indicates. To avoid the unexpected confusion, this series attempts to + rejects such kind of insane configurations. + +* [v1: target/riscv/vector_helper.c: create vext_set_tail_elems_1s()](http://lore.kernel.org/qemu-devel/20230221184525.140704-1-dbarboza@ventanamicro.com/) + + Commit 752614cab8e6 ("target/riscv: rvv: Add tail agnostic for vector + load / store instructions") added code to set the tail elements to 1 in + the end of vext_ldst_stride(), vext_ldst_us(), vext_ldst_index() and + vext_ldff(). Aside from a env->vl versus an evl value being used in the + first loop, the code is being repeated 4 times. + +* [v1: target/riscv: Add support for Zicond extension](http://lore.kernel.org/qemu-devel/20230221091009.36545-1-liweiwei@iscas.ac.cn/) + + The spec can be found in https://github.com/riscv/riscv-zicond. + Two instructions are added: + - czero.eqz: Moves zero to a register rd, if the condition rs2 is + equal to zero, otherwise moves rs1 to rd. + - czero.nez: Moves zero to a register rd, if the condition rs2 is + nonzero, otherwise moves rs1 to rd. + +#### U-Boot + +* [v1: Add StarFive JH7110 PCIe drvier support](http://lore.kernel.org/u-boot/20230223105240.15180-1-minda.chen@starfivetech.com/) + + The PCIe driver depends on gpio, pinctrl, clk and reset driver to do init. + The PCIe dts configuation includes all these setting. + + The PCIe drivers codes has been tested on the VisionFive V2 boards. + The test devices includes M.2 NVMe SSD and Realtek 8169 Ethernet adapter. + +* [Boot from 64-bit memory address?](http://lore.kernel.org/u-boot/BL3PR11MB5713975ADD19187E59776A2389AB9@BL3PR11MB5713.namprd11.prod.outlook.com/) + + Is it possible to boot from a DRAM memory address beyond the 32-bit boundary? I'm trying to configure a new RISC-V board which has 2GB of DRAM starting at offset 0x40_0000_0000. I started from the settings for an existing RISC-V board and made adjustments for my HW, but when I try to boot, I run into an "out of memory" error. + +* [v1: riscv: Support CONFIG_REMAKE_ELF](http://lore.kernel.org/u-boot/20230220060239.42279-1-samuel@sholland.org/) + + Add flags to tell objcopy what kind of ELF to create. + ## 20230219：第 34 期 ### 内核动态 -- Gitee