aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-11-07Documentation/arm64: Fix typos in elf_hwcapsMarielle Novastrider1-3/+3
Small typos in register and field names. Signed-off-by: Marielle Novastrider <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2023-11-07iomap: rename iomap entryChristian Brauner1-10/+9
Since this is now part of the vfs trees rename it accordingly and remove the old tree referencing xfs. Signed-off-by: Christian Brauner <[email protected]>
2023-11-07crypto: ahash - Set using_shash for cloned ahash wrapper over shashDmitry Safonov1-0/+1
The cloned child of ahash that uses shash under the hood should use shash helpers (like crypto_shash_setkey()). The following panic may be observed on TCP-AO selftests: > ================================================================== > BUG: KASAN: wild-memory-access in crypto_mod_get+0x1b/0x60 > Write of size 4 at addr 5d5be0ff5c415e14 by task connect_ipv4/1397 > > CPU: 0 PID: 1397 Comm: connect_ipv4 Tainted: G W 6.6.0+ #47 > Call Trace: > <TASK> > dump_stack_lvl+0x46/0x70 > kasan_report+0xc3/0xf0 > kasan_check_range+0xec/0x190 > crypto_mod_get+0x1b/0x60 > crypto_spawn_alg+0x53/0x140 > crypto_spawn_tfm2+0x13/0x60 > hmac_init_tfm+0x25/0x60 > crypto_ahash_setkey+0x8b/0x100 > tcp_ao_add_cmd+0xe7a/0x1120 > do_tcp_setsockopt+0x5ed/0x12a0 > do_sock_setsockopt+0x82/0x100 > __sys_setsockopt+0xe9/0x160 > __x64_sys_setsockopt+0x60/0x70 > do_syscall_64+0x3c/0xe0 > entry_SYSCALL_64_after_hwframe+0x46/0x4e > ================================================================== > general protection fault, probably for non-canonical address 0x5d5be0ff5c415e14: 0000 [#1] PREEMPT SMP KASAN > CPU: 0 PID: 1397 Comm: connect_ipv4 Tainted: G B W 6.6.0+ #47 > Call Trace: > <TASK> > ? die_addr+0x3c/0xa0 > ? exc_general_protection+0x144/0x210 > ? asm_exc_general_protection+0x22/0x30 > ? add_taint+0x26/0x90 > ? crypto_mod_get+0x20/0x60 > ? crypto_mod_get+0x1b/0x60 > ? ahash_def_finup_done1+0x58/0x80 > crypto_spawn_alg+0x53/0x140 > crypto_spawn_tfm2+0x13/0x60 > hmac_init_tfm+0x25/0x60 > crypto_ahash_setkey+0x8b/0x100 > tcp_ao_add_cmd+0xe7a/0x1120 > do_tcp_setsockopt+0x5ed/0x12a0 > do_sock_setsockopt+0x82/0x100 > __sys_setsockopt+0xe9/0x160 > __x64_sys_setsockopt+0x60/0x70 > do_syscall_64+0x3c/0xe0 > entry_SYSCALL_64_after_hwframe+0x46/0x4e > </TASK> > RIP: 0010:crypto_mod_get+0x20/0x60 Make sure that the child/clone has using_shash set when parent is an shash user. Fixes: 2f1f34c1bf7b ("crypto: ahash - optimize performance when wrapping shash") Cc: David Ahern <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Dmitry Safonov <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Francesco Ruggeri <[email protected]> To: Herbert Xu <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Salam Noureddine <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Dmitry Safonov <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-11-07crypto: jitterentropy - Hide esoteric Kconfig options under FIPS and EXPERTHerbert Xu1-3/+25
As JITTERENTROPY is selected by default if you enable the CRYPTO API, any Kconfig options added there will show up for every single user. Hide the esoteric options under EXPERT as well as FIPS so that only distro makers will see them. Reported-by: Linus Torvalds <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Reviewed-by: Stephan Mueller <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-11-06Merge patch series "riscv: tlb flush improvements"Palmer Dabbelt0-0/+0
Alexandre Ghiti <[email protected]> says: 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?). * b4-shazam-merge: riscv: Improve flush_tlb_kernel_range() riscv: Make __flush_tlb_range() loop over pte instead of flushing the whole tlb riscv: Improve flush_tlb_range() for hugetlb pages riscv: Improve tlb_flush() Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: Improve flush_tlb_kernel_range()Alexandre Ghiti2-15/+30
This function used to simply flush the whole tlb of all harts, be more subtile and try to only flush the range. The problem is that we can only use PAGE_SIZE as stride since we don't know the size of the underlying mapping and then this function will be improved only if the size of the region to flush is < threshold * PAGE_SIZE. Signed-off-by: Alexandre Ghiti <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Tested-by: Lad Prabhakar <[email protected]> # On RZ/Five SMARC Reviewed-by: Samuel Holland <[email protected]> Tested-by: Samuel Holland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: Make __flush_tlb_range() loop over pte instead of flushing the whole tlbAlexandre Ghiti4-81/+72
Currently, when the range to flush covers more than one page (a 4K page or a hugepage), __flush_tlb_range() flushes the whole tlb. Flushing the whole tlb comes with a greater cost than flushing a single entry so we should flush single entries up to a certain threshold so that: threshold * cost of flushing a single entry < cost of flushing the whole tlb. Co-developed-by: Mayuresh Chitale <[email protected]> Signed-off-by: Mayuresh Chitale <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Tested-by: Lad Prabhakar <[email protected]> # On RZ/Five SMARC Reviewed-by: Samuel Holland <[email protected]> Tested-by: Samuel Holland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: Improve flush_tlb_range() for hugetlb pagesAlexandre Ghiti1-1/+28
flush_tlb_range() uses a fixed stride of PAGE_SIZE and in its current form, when a hugetlb mapping needs to be flushed, flush_tlb_range() flushes the whole tlb: so set a stride of the size of the hugetlb mapping in order to only flush the hugetlb mapping. However, if the hugepage is a NAPOT region, all PTEs that constitute this mapping must be invalidated, so the stride size must actually be the size of the PTE. Note that THPs are directly handled by flush_pmd_tlb_range(). Signed-off-by: Alexandre Ghiti <[email protected]> Reviewed-by: Samuel Holland <[email protected]> Tested-by: Lad Prabhakar <[email protected]> # On RZ/Five SMARC Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: Improve tlb_flush()Alexandre Ghiti3-1/+17
For now, tlb_flush() simply calls flush_tlb_mm() which results in a flush of the whole TLB. So let's use mmu_gather fields to provide a more fine-grained flush of the TLB. Signed-off-by: Alexandre Ghiti <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Reviewed-by: Samuel Holland <[email protected]> Tested-by: Lad Prabhakar <[email protected]> # On RZ/Five SMARC Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-07powerpc/rtas: Fix ppc_rtas_rmo_buf_show() kernel-docNathan Lynch1-0/+2
>From a W=1 build: >> arch/powerpc/kernel/rtas-proc.c:771: warning: Function parameter or member 'm' not described in >> 'ppc_rtas_rmo_buf_show' >> arch/powerpc/kernel/rtas-proc.c:771: warning: Function parameter or member 'v' not described in >> 'ppc_rtas_rmo_buf_show' Add the missing parameter descriptions. Signed-off-by: Nathan Lynch <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2023-11-07powerpc/pseries/rtas-work-area: Fix rtas_work_area_reserve_arena() kernel-docNathan Lynch1-0/+1
>From a W=1 build: >> arch/powerpc/platforms/pseries/rtas-work-area.c:189: warning: Function parameter or member 'limit' not >> described in 'rtas_work_area_reserve_arena' Add the missing description of the limit parameter. Signed-off-by: Nathan Lynch <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2023-11-06idpf: fix potential use-after-free in idpf_tso()Eric Dumazet1-2/+4
skb_cow_head() can change skb->head (and thus skb_shinfo(skb)) We must not cache skb_shinfo(skb) before skb_cow_head(). Fixes: 6818c4d5b3c2 ("idpf: add splitq start_xmit") Signed-off-by: Eric Dumazet <[email protected]> Cc: Joshua Hay <[email protected]> Cc: Alan Brady <[email protected]> Cc: Madhu Chittim <[email protected]> Cc: Phani Burra <[email protected]> Cc: Sridhar Samudrala <[email protected]> Cc: Willem de Bruijn <[email protected]> Cc: Pavan Kumar Linga <[email protected]> Cc: Tony Nguyen <[email protected]> Cc: Bailey Forrest <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-11-06tg3: power down device only on SYSTEM_POWER_OFFGeorge Shuklin1-1/+2
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). The actual problem is on Dell side, but this fix allows servers to come back alive after reboot. Signed-off-by: George Shuklin <[email protected]> Fixes: 2ca1c94ce0b6 ("tg3: Disable tg3 device on system reboot to avoid triggering AER") Reviewed-by: Pavan Chebbi <[email protected]> Reviewed-by: Michael Chan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-11-06ice: Fix VF-VF direction matching in drop rule in switchdevMarcin Szycik1-1/+23
When adding a drop rule on a VF, rule direction is not being set, which results in it always being set to ingress (ICE_ESWITCH_FLTR_INGRESS equals 0). Because of this, drop rules added on port representors don't match any packets. To fix it, set rule direction in drop action to egress when netdev is a port representor, otherwise set it to ingress. Fixes: 0960a27bd479 ("ice: Add direction metadata") Reviewed-by: Michal Swiatkowski <[email protected]> Signed-off-by: Marcin Szycik <[email protected]> Tested-by: Sujai Buvaneswaran <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-11-06ice: Fix VF-VF filter rules in switchdev modeAniruddha Paul1-28/+62
Any packet leaving VSI i.e VF's VSI is considered as egress traffic by HW, thus failing to match the added rule. Mark the direction for redirect rules as below: 1. VF-VF - Egress 2. Uplink-VF - Ingress 3. VF-Uplink - Egress 4. Link_Partner-Uplink - Ingress 5. Link_Partner-VF - Ingress Fixes: 0960a27bd479 ("ice: Add direction metadata") Reviewed-by: Przemek Kitszel <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Signed-off-by: Aniruddha Paul <[email protected]> Tested-by: Sujai Buvaneswaran <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-11-06ice: lag: in RCU, use atomic allocationMichal Schmidt1-3/+3
Sleeping is not allowed in RCU read-side critical sections. Use atomic allocations under rcu_read_lock. Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on bonded interface") Fixes: 41ccedf5ca8f ("ice: implement lag netdev event handler") Fixes: 3579aa86fb40 ("ice: update reset path for SRIOV LAG support") Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel) Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-11-06ice: Fix SRIOV LAG disable on non-compliant aggregateDave Ertman1-9/+3
If an attribute of an aggregate interface disqualifies it from supporting SRIOV, the driver will unwind the SRIOV support. Currently the driver is clearing the feature bit for all interfaces in the aggregate, but this is not allowing the other interfaces to unwind successfully on driver unload. Only clear the feature bit for the interface that is currently unwinding. Fixes: bf65da2eb279 ("ice: enforce interface eligibility and add messaging for SRIOV LAG") Signed-off-by: Dave Ertman <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Sujai Buvaneswaran <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-11-06riscv: select ARCH_PROC_KCORE_TEXTAndreas Schwab1-0/+3
This adds a separate segment for kernel text in /proc/kcore, which has a different address than the direct linear map. Signed-off-by: Andreas Schwab <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06i40e: Fix devlink port unregisteringIvan Vecera1-4/+6
Ensure that devlink port is unregistered after unregistering of net device. Reproducer: [root@host ~]# rmmod i40e [ 4742.939386] i40e 0000:02:00.1: i40e_ptp_stop: removed PHC on enp2s0f1np1 [ 4743.059269] ------------[ cut here ]------------ [ 4743.063900] WARNING: CPU: 21 PID: 10766 at net/devlink/port.c:1078 devl_port_unregister+0x69/0x80 ... Fixes: 9e479d64dc58 ("i40e: Add initial devlink support") Signed-off-by: Ivan Vecera <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]>
2023-11-06i40e: Do not call devlink_port_type_clear()Ivan Vecera1-1/+0
Do not call devlink_port_type_clear() prior devlink port unregister and let devlink core to take care about it. Reproducer: [root@host ~]# rmmod i40e [ 4539.964699] i40e 0000:02:00.0: devlink port type for port 0 cleared without a software interface reference, device type not supported by the kernel? [ 4540.319811] i40e 0000:02:00.1: devlink port type for port 1 cleared without a software interface reference, device type not supported by the kernel? Fixes: 9e479d64dc58 ("i40e: Add initial devlink support") Signed-off-by: Ivan Vecera <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]>
2023-11-06Merge branch 'next' into for-linusDmitry Torokhov14863-176041/+538715
Prepare input updates for 6.7 merge window.
2023-11-06Merge tag 'media/v6.7-1' of ↵Linus Torvalds505-18024/+17217
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media updates from Mauro Carvalho Chehab: - the old V4L2 core videobuf kAPI was finally removed. All media drivers should now be using VB2 kAPI - new automotive driver: mgb4 - new platform video driver: npcm-video - new sensor driver: mt9m114 - new TI driver used in conjunction with Cadence CSI2RX IP to bridge TI-specific parts - ir-rx51 was removed and the N900 DT binding was moved to the pwm-ir-tx generic driver - drop atomisp-specific ov5693, using the upstream driver instead - the camss driver has gained RDI3 support for VFE 17x - the atomisp driver now detects ISP2400 or ISP2401 at run time. No need to set it up at build time anymore - lots of driver fixes, cleanups and improvements * tag 'media/v6.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (377 commits) media: nuvoton: VIDEO_NPCM_VCD_ECE should depend on ARCH_NPCM media: venus: Fix firmware path for resources media: venus: hfi_cmds: Replace one-element array with flex-array member and use __counted_by media: venus: hfi_parser: Add check to keep the number of codecs within range media: venus: hfi: add checks to handle capabilities from firmware media: venus: hfi: fix the check to handle session buffer requirement media: venus: hfi: add checks to perform sanity on queue pointers media: platform: cadence: select MIPI_DPHY dependency media: MAINTAINERS: Fix path for J721E CSI2RX bindings media: cec: meson: always include meson sub-directory in Makefile media: videobuf2: Fix IS_ERR checking in vb2_dc_put_userptr() media: platform: mtk-mdp3: fix uninitialized variable in mdp_path_config() media: mediatek: vcodec: using encoder device to alloc/free encoder memory media: imx-jpeg: notify source chagne event when the first picture parsed media: cx231xx: Use EP5_BUF_SIZE macro media: siano: Drop unnecessary error check for debugfs_create_dir/file() media: mediatek: vcodec: Handle invalid encoder vsi media: aspeed: Drop unnecessary error check for debugfs_create_file() Documentation: media: buffer.rst: fix V4L2_BUF_FLAG_PREPARED Documentation: media: gen-errors.rst: fix confusing ENOTTY description ...
2023-11-06io_uring: do not clamp read length for multishot readDylan Yudaken1-1/+8
When doing a multishot read, the code path reuses the old read paths. However this breaks an assumption built into those paths, namely that struct io_rw::len is available for reuse by __io_import_iovec. For multishot this results in len being set for the first receive call, and then subsequent calls are clamped to that buffer length incorrectly. Instead keep len as zero after recycling buffers, to reuse the full buffer size of the next selected buffer. Fixes: fc68fcda0491 ("io_uring/rw: add support for IORING_OP_READ_MULTISHOT") Signed-off-by: Dylan Yudaken <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-11-06io_uring: do not allow multishot read to set addr or lenDylan Yudaken1-0/+4
For addr: this field is not used, since buffer select is forced. But by forcing it to be zero it leaves open future uses of the field. len is actually usable, you could imagine that you want to receive multishot up to a certain length. However right now this is not how it is implemented, and it seems safer to force this to be zero. Fixes: fc68fcda0491 ("io_uring/rw: add support for IORING_OP_READ_MULTISHOT") Signed-off-by: Dylan Yudaken <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-11-06io_uring: indicate if io_kbuf_recycle did recycle anythingDylan Yudaken2-8/+11
It can be useful to know if io_kbuf_recycle did actually recycle the buffer on the request, or if it left the request alone. Signed-off-by: Dylan Yudaken <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-11-06riscv: kernel: Use correct SYM_DATA_*() macro for dataClément Léger1-5/+4
Some data were incorrectly annotated with SYM_FUNC_*() instead of SYM_DATA_*() ones. Use the correct ones. Signed-off-by: Clément Léger <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: Use SYM_*() assembly macros instead of deprecated onesClément Léger17-74/+60
ENTRY()/END()/WEAK() macros are deprecated and we should make use of the new SYM_*() macros [1] for better annotation of symbols. Replace the deprecated ones with the new ones and fix wrong usage of END()/ENDPROC() to correctly describe the symbols. [1] https://docs.kernel.org/core-api/asm-annotations.html Signed-off-by: Clément Léger <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: use ".L" local labels in assembly when applicableClément Léger4-44/+44
For the sake of coherency, use local labels in assembly when applicable. This also avoid kprobes being confused when applying a kprobe since the size of function is computed by checking where the next visible symbol is located. This might end up in computing some function size to be way shorter than expected and thus failing to apply kprobes to the specified offset. Signed-off-by: Clément Léger <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: boot: Fix creation of loader.binGeert Uytterhoeven1-0/+1
When flashing loader.bin for K210 using kflash:     [ERROR] This is an ELF file and cannot be programmed to flash directly: arch/riscv/boot/loader.bin Before, loader.bin relied on "OBJCOPYFLAGS := -O binary" in the main RISC-V Makefile to create a boot image with the right format. With this removed, the image is now created in the wrong (ELF) format. Fix this by adding an explicit rule. Fixes: 505b02957e74f0c5 ("riscv: Remove duplicate objcopy flag") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Link: https://lore.kernel.org/r/1086025809583809538dfecaa899892218f44e7e.1698159066.git.geert+renesas@glider.be Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06nvme: start keep-alive after admin queue setupHannes Reinecke2-3/+9
Setting up I/O queues might take quite some time on larger and/or busy setups, so KATO might expire before all I/O queues could be set up. Fix this by start keep alive from the ->init_ctrl_finish() callback, and stopping it when calling nvme_cancel_admin_tagset(). Signed-off-by: Hannes Reinecke <[email protected]> Tested-by: Mark O'Donovan <[email protected]> [fixed nvme-fc compile error] Signed-off-by: Keith Busch <[email protected]>
2023-11-06kdb: Corrects comment for kdballocenvYuran Pereira1-4/+3
This patch corrects the comment for the kdballocenv function. The previous comment incorrectly described the function's parameters and return values. Signed-off-by: Yuran Pereira <[email protected]> Link: https://lore.kernel.org/r/DB3PR10MB6835B383B596133EDECEA98AE8ABA@DB3PR10MB6835.EURPRD10.PROD.OUTLOOK.COM [[email protected]: fixed whitespace alignment in new lines] Signed-off-by: Daniel Thompson <[email protected]>
2023-11-06nvme-loop: always quiesce and cancel commands before destroying admin qHannes Reinecke1-0/+4
Once ->init_ctrl_finish() is called there may be commands outstanding, so we should quiesce the admin queue and cancel all commands prior to call nvme_loop_destroy_admin_queue(). Signed-off-by: Hannes Reinecke <[email protected]> Tested-by: Mark O'Donovan <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2023-11-06nvme-tcp: avoid open-coding nvme_tcp_teardown_admin_queue()Hannes Reinecke1-5/+1
nvme_tcp_setup_ctrl() has an open-coded version of nvme_tcp_teardown_admin_queue(). Signed-off-by: Hannes Reinecke <[email protected]> Tested-by: Mark O'Donovan <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2023-11-06nvme-auth: always set valid seq_num in dhchap replyMark O'Donovan2-3/+2
Currently a seqnum of zero is sent during uni-directional authentication. The zero value is reserved for the secure channel feature which is not yet implemented. Relevant extract from the spec: The value 0h is used to indicate that bidirectional authentication is not performed, but a challenge value C2 is carried in order to generate a pre-shared key (PSK) for subsequent establishment of a secure channel Signed-off-by: Mark O'Donovan <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]>
2023-11-06nvme-auth: add flag for bi-directional authMark O'Donovan1-1/+4
Introduces an explicit variable for bi-directional auth. The currently used variable chap->s2 is incorrectly zeroed for uni-directional auth. That will be fixed in the next patch so this needs to change to avoid sending unexpected success2 messages Signed-off-by: Mark O'Donovan <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]>
2023-11-06nvme-auth: auth success1 msg always includes respMark O'Donovan2-5/+2
In cases where RVALID is false, the response is still transmitted, but is cleared to zero. Relevant extract from the spec: Response R2, if valid (i.e., if the RVALID field is set to 01h), cleared to 0h otherwise Signed-off-by: Mark O'Donovan <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2023-11-06nvme: fix error-handling for io_uring nvme-passthroughAnuj Gupta1-2/+5
Driver may return an error before submitting the command to the device. Ensure that such error is propagated up. Fixes: 456cba386e94 ("nvme: wire-up uring-cmd support for io-passthru on char-device.") Signed-off-by: Anuj Gupta <[email protected]> Signed-off-by: Kanchan Joshi <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2023-11-06nvme: update firmware version after commitDaniel Wagner1-1/+14
The firmware version sysfs entry needs to be updated after a successfully firmware activation. nvme-cli stopped issuing an Identify Controller command to list the current firmware information and relies on sysfs showing the current firmware version. Reported-by: Kenji Tomonaga <[email protected]> Signed-off-by: Daniel Wagner <[email protected]> Tested-by: Kenji Tomonaga <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> [fixed off-by one afi index] Signed-off-by: Keith Busch <[email protected]>
2023-11-06nvme-tcp: Fix a memory leakChristophe JAILLET1-1/+2
All error handling path end to the error handling path, except this one. Go to the error handling branch as well here, otherwise 'icreq' and 'icresp' will leak. Fixes: 2837966ab2a8 ("nvme-tcp: control message handling for recvmsg()") Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2023-11-06nvme-auth: use crypto_shash_tfm_digest()Eric Biggers1-21/+2
Simplify nvme_auth_augmented_challenge() by using crypto_shash_tfm_digest() instead of an alloc+init+update+final sequence. This should also improve performance. Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2023-11-06Merge patch series "riscv: tlb flush improvements"Palmer Dabbelt5-95/+144
Alexandre Ghiti <[email protected]> says: 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?). * b4-shazam-merge: riscv: Improve flush_tlb_kernel_range() riscv: Make __flush_tlb_range() loop over pte instead of flushing the whole tlb riscv: Improve flush_tlb_range() for hugetlb pages riscv: Improve tlb_flush() Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: Improve flush_tlb_kernel_range()Alexandre Ghiti2-15/+30
This function used to simply flush the whole tlb of all harts, be more subtile and try to only flush the range. The problem is that we can only use PAGE_SIZE as stride since we don't know the size of the underlying mapping and then this function will be improved only if the size of the region to flush is < threshold * PAGE_SIZE. Signed-off-by: Alexandre Ghiti <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Tested-by: Lad Prabhakar <[email protected]> # On RZ/Five SMARC Reviewed-by: Samuel Holland <[email protected]> Tested-by: Samuel Holland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: Make __flush_tlb_range() loop over pte instead of flushing the whole tlbAlexandre Ghiti4-81/+72
Currently, when the range to flush covers more than one page (a 4K page or a hugepage), __flush_tlb_range() flushes the whole tlb. Flushing the whole tlb comes with a greater cost than flushing a single entry so we should flush single entries up to a certain threshold so that: threshold * cost of flushing a single entry < cost of flushing the whole tlb. Co-developed-by: Mayuresh Chitale <[email protected]> Signed-off-by: Mayuresh Chitale <[email protected]> Signed-off-by: Alexandre Ghiti <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Tested-by: Lad Prabhakar <[email protected]> # On RZ/Five SMARC Reviewed-by: Samuel Holland <[email protected]> Tested-by: Samuel Holland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: Improve flush_tlb_range() for hugetlb pagesAlexandre Ghiti1-1/+28
flush_tlb_range() uses a fixed stride of PAGE_SIZE and in its current form, when a hugetlb mapping needs to be flushed, flush_tlb_range() flushes the whole tlb: so set a stride of the size of the hugetlb mapping in order to only flush the hugetlb mapping. However, if the hugepage is a NAPOT region, all PTEs that constitute this mapping must be invalidated, so the stride size must actually be the size of the PTE. Note that THPs are directly handled by flush_pmd_tlb_range(). Signed-off-by: Alexandre Ghiti <[email protected]> Reviewed-by: Samuel Holland <[email protected]> Tested-by: Lad Prabhakar <[email protected]> # On RZ/Five SMARC Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06riscv: Improve tlb_flush()Alexandre Ghiti3-1/+17
For now, tlb_flush() simply calls flush_tlb_mm() which results in a flush of the whole TLB. So let's use mmu_gather fields to provide a more fine-grained flush of the TLB. Signed-off-by: Alexandre Ghiti <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Reviewed-by: Samuel Holland <[email protected]> Tested-by: Lad Prabhakar <[email protected]> # On RZ/Five SMARC Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-11-06io_uring/rw: add separate prep handler for fixed read/writeJens Axboe3-14/+21
Rather than sprinkle opcode checks in the generic read/write prep handler, have a separate prep handler for the vectored readv/writev operation. Signed-off-by: Jens Axboe <[email protected]>
2023-11-06io_uring/rw: add separate prep handler for readv/writevJens Axboe3-9/+18
Rather than sprinkle opcode checks in the generic read/write prep handler, have a separate prep handler for the vectored readv/writev operation. Signed-off-by: Jens Axboe <[email protected]>
2023-11-06drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_initNirmoy Das1-3/+8
Fix below compiler warning: intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 3 [-Werror=format-truncation=] "%c/TC#%d", port_name(port), tc_port + 1); ^~ intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes into a destination of size 8 snprintf(tc->port_name, sizeof(tc->port_name), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%c/TC#%d", port_name(port), tc_port + 1); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v2: use kasprintf(Imre) v3: use const for port_name, and fix tc mem leak(Imre) Fixes: 3eafcddf766b ("drm/i915/tc: Move TC port fields to a new intel_tc_port struct") Cc: Mika Kahola <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Imre Deak <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 70a3cbbe620ee66afb0c066624196077767e61b2) Signed-off-by: Jani Nikula <[email protected]>
2023-11-06drm/i915: Fix potential spectre vulnerabilityKunwu Chan1-0/+1
Fix smatch warning: drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu() warn: potential spectre issue 'pc->user_engines' [r] (local cap) Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Cc: <[email protected]> # v5.15+ Signed-off-by: Kunwu Chan <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 27b086382c22efb7e0a16442f7bdc2e120108ef3) Signed-off-by: Jani Nikula <[email protected]>
2023-11-06drm/i915: Bump GLK CDCLK frequency when driving multiple pipesVille Syrjälä1-0/+12
On GLK CDCLK frequency needs to be at least 2*96 MHz when accessing the audio hardware. Currently we bump the CDCLK frequency up temporarily (if not high enough already) whenever audio hardware is being accessed, and drop it back down afterwards. With a single active pipe this works just fine as we can switch between all the valid CDCLK frequencies by changing the cd2x divider, which doesn't require a full modeset. However with multiple active pipes the cd2x divider trick no longer works, and thus we end up blinking all displays off and back on. To avoid this let's just bump the CDCLK frequency to >=2*96MHz whenever multiple pipes are active. The downside is slightly higher power consumption, but that seems like an acceptable tradeoff. With a single active pipe we can stick to the current more optiomal (from power comsumption POV) behaviour. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9599 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> (cherry picked from commit 451eaa1a614c911f5a51078dcb68022874e4cb12) Signed-off-by: Jani Nikula <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.