- 29 1月, 2021 3 次提交
-
-
由 zhangyi (F) 提交于
maillist inclusion category: bugfix bugzilla: 47445 CVE: NA Reference: https://lore.kernel.org/lkml/1564451504-27906-1-git-send-email-yi.zhang@huawei.com/ --------------------------- io_[p]getevents syscall should return -EINVAL if timeout is out of range, add this validity check. Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com> Reviewed-by: NJeff Moyer <jmoyer@redhat.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Deepa Dinamani <deepa.kernel@gmail.com> Signed-off-by: Nyangerkun <yangerkun@huawei.com> Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Arnd Bergmann 提交于
maillist inclusion category: bugfix bugzilla: 47440 CVE: NA Reference: https://lore.kernel.org/patchwork/patch/877882/ ------------------------------------------------- Recent versions of binutils always warn about test-arm.s: arch/arm/probes/kprobes/test-arm.s:18262: Warning: using r15 results in unpredictable behaviour arch/arm/probes/kprobes/test-arm.s:18337: Warning: using r15 results in unpredictable behaviour We could work around this using the __inst_arm() macro for passing the two instruction as a hexadecimal literal number, but as Ard pointed out, there is no reason to leave the warnings enabled for this file in general, we intentionally test for an instruction that is not recommended to be used. For consistency, this turns off the warning in both the ARM and Thumb2 versions of this file. Suggested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de> [KF: from https://lore.kernel.org/patchwork/patch/877882/] Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com> Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 yangerkun 提交于
hulk inclusion category: bugfix bugzilla: 47438 CVE: NA --------------------------- UBSAN has reported a overflow with mem_lseek. And it's fine with mem_open set file mode with FMODE_UNSIGNED_OFFSET(memory_lseek). However, another file use mem_lseek do lseek can have not FMODE_UNSIGNED_OFFSET(proc_kpagecount_operations/proc_pagemap_operations), fix it by checking overflow and FMODE_UNSIGNED_OFFSET. Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com> ================================================================== UBSAN: Undefined behaviour in ../fs/proc/base.c:941:15 signed integer overflow: 4611686018427387904 + 4611686018427387904 cannot be represented in type 'long long int' CPU: 4 PID: 4762 Comm: syz-executor.1 Not tainted 4.4.189 #3 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: [<ffffff90080a5f28>] dump_backtrace+0x0/0x590 arch/arm64/kernel/traps.c:91 [<ffffff90080a64f0>] show_stack+0x38/0x60 arch/arm64/kernel/traps.c:234 [<ffffff9008986a34>] __dump_stack lib/dump_stack.c:15 [inline] [<ffffff9008986a34>] dump_stack+0x128/0x184 lib/dump_stack.c:51 [<ffffff9008a2d120>] ubsan_epilogue+0x34/0x9c lib/ubsan.c:166 [<ffffff9008a2d8b8>] handle_overflow+0x228/0x280 lib/ubsan.c:197 [<ffffff9008a2da2c>] __ubsan_handle_add_overflow+0x4c/0x68 lib/ubsan.c:204 [<ffffff900862b9f4>] mem_lseek+0x12c/0x130 fs/proc/base.c:941 [<ffffff90084ef78c>] vfs_llseek fs/read_write.c:260 [inline] [<ffffff90084ef78c>] SYSC_lseek fs/read_write.c:285 [inline] [<ffffff90084ef78c>] SyS_lseek+0x164/0x1f0 fs/read_write.c:276 [<ffffff9008093c80>] el0_svc_naked+0x30/0x34 ================================================================== Signed-off-by: Nyangerkun <yangerkun@huawei.com> Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com> (cherry picked from commit a422358aa04c53a08b215b8dcd6814d916ef5cf1) Conflicts: fs/read_write.c Signed-off-by: NLi Ming <limingming.li@huawei.com> Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 28 1月, 2021 37 次提交
-
-
由 Dinghao Liu 提交于
stable inclusion from stable-5.10.9 commit 88a5c90f39b0f8f4a747f24bb68d8b22d558daa7 bugzilla: 47457 -------------------------------- commit 869f4fda upstream. When register_pernet_subsys() fails, nf_nat_bysource should be freed just like when nf_ct_extend_register() fails. Fixes: 1cd472bf ("netfilter: nf_nat: add nat hook register functions to nf_nat") Signed-off-by: NDinghao Liu <dinghao.liu@zju.edu.cn> Acked-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jesper Dangaard Brouer 提交于
stable inclusion from stable-5.10.9 commit f14e31c169dc689f47929bc3729ac019eea02d89 bugzilla: 47457 -------------------------------- commit f6351c3f upstream. The old way of changing the conntrack hashsize runtime was through changing the module param via file /sys/module/nf_conntrack/parameters/hashsize. This was extended to sysctl change in commit 3183ab89 ("netfilter: conntrack: allow increasing bucket size via sysctl too"). The commit introduced second "user" variable nf_conntrack_htable_size_user which shadow actual variable nf_conntrack_htable_size. When hashsize is changed via module param this "user" variable isn't updated. This results in sysctl net/netfilter/nf_conntrack_buckets shows the wrong value when users update via the old way. This patch fix the issue by always updating "user" variable when reading the proc file. This will take care of changes to the actual variable without sysctl need to be aware. Fixes: 3183ab89 ("netfilter: conntrack: allow increasing bucket size via sysctl too") Reported-by: NYoel Caspersen <yoel@kviknet.dk> Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com> Acked-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Geert Uytterhoeven 提交于
stable inclusion from stable-5.10.9 commit 5b984e538bdf2a9ba1c1b147c35ee191953f2b86 bugzilla: 47457 -------------------------------- commit 9f65df9c upstream. As snd_fw_async_midi_port.consume_bytes is unsigned int, and NSEC_PER_SEC is 1000000000L, the second multiplication in port->consume_bytes * 8 * NSEC_PER_SEC / 31250 always overflows on 32-bit platforms, truncating the result. Fix this by precalculating "NSEC_PER_SEC / 31250", which is an integer constant. Note that this assumes port->consume_bytes <= 16777. Fixes: 531f4718 ("ALSA: firewire-lib/firewire-tascam: localize async midi port") Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210111130251.361335-3-geert+renesas@glider.beSigned-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Geert Uytterhoeven 提交于
stable inclusion from stable-5.10.9 commit c0e1ac275f1f617a36d5d187c919985842249136 bugzilla: 47457 -------------------------------- commit e7c22eea upstream. As snd_ff.rx_bytes[] is unsigned int, and NSEC_PER_SEC is 1000000000L, the second multiplication in ff->rx_bytes[port] * 8 * NSEC_PER_SEC / 31250 always overflows on 32-bit platforms, truncating the result. Fix this by precalculating "NSEC_PER_SEC / 31250", which is an integer constant. Note that this assumes ff->rx_bytes[port] <= 16777. Fixes: 19174295 ("ALSA: fireface: add transaction support") Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210111130251.361335-2-geert+renesas@glider.beSigned-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Mike Snitzer 提交于
stable inclusion from stable-5.10.9 commit 0eb56457d239f5ee555ad9dc0c086a0abd933f1b bugzilla: 47457 -------------------------------- commit 0378c625 upstream. There wasn't ever a real need to log an error in the kernel log for ioctls issued with insufficient permissions. Simply return an error and if an admin/user is sufficiently motivated they can enable DM's dynamic debugging to see an explanation for why the ioctls were disallowed. Reported-by: NNir Soffer <nsoffer@redhat.com> Fixes: e980f623 ("dm: don't allow ioctls to targets that don't map to whole devices") Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Chen Yi 提交于
stable inclusion from stable-5.10.9 commit 26865769ed8f03c49106c3e2e588733ca55c3525 bugzilla: 47457 -------------------------------- commit fab336b4 upstream. Fix nft_conntrack_helper.sh false fail report: 1) Conntrack tool need "-f ipv6" parameter to show out ipv6 traffic items. 2) Sleep 1 second after background nc send packet, to make sure check is after this statement executed. False report: FAIL: ns1-lkjUemYw did not show attached helper ip set via ruleset PASS: ns1-lkjUemYw connection on port 2121 has ftp helper attached ... After fix: PASS: ns1-2hUniwU2 connection on port 2121 has ftp helper attached PASS: ns2-2hUniwU2 connection on port 2121 has ftp helper attached ... Fixes: 619ae8e0 ("selftests: netfilter: add test case for conntrack helper assignment") Signed-off-by: NChen Yi <yiche@redhat.com> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 j.nixdorf@avm.de 提交于
stable inclusion from stable-5.10.9 commit f0cd3fba4eaeecac987bd490ad5efc6e54507511 bugzilla: 47457 -------------------------------- commit 86b53fbf upstream. A return value of 0 means success. This is documented in lib/kstrtox.c. This was found by trying to mount an NFS share from a link-local IPv6 address with the interface specified by its index: mount("[fe80::1%1]:/srv/nfs", "/mnt", "nfs", 0, "nolock,addr=fe80::1%1") Before this commit this failed with EINVAL and also caused the following message in dmesg: [...] NFS: bad IP address specified: addr=fe80::1%1 The syscall using the same address based on the interface name instead of its index succeeds. Credits for this patch go to my colleague Christian Speich, who traced the origin of this bug to this line of code. Signed-off-by: NJohannes Nixdorf <j.nixdorf@avm.de> Fixes: 00cfaa94 ("replace strict_strto calls") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Lu Baolu 提交于
stable inclusion from stable-5.10.9 commit a9bc9c9320accce897e82147c61c63d5d00b28e2 bugzilla: 47457 -------------------------------- commit 2d6ffc63 upstream. The VT-d hardware will ignore those Addr bits which have been masked by the AM field in the PASID-based-IOTLB invalidation descriptor. As the result, if the starting address in the descriptor is not aligned with the address mask, some IOTLB caches might not invalidate. Hence people will see below errors. [ 1093.704661] dmar_fault: 29 callbacks suppressed [ 1093.704664] DMAR: DRHD: handling fault status reg 3 [ 1093.712738] DMAR: [DMA Read] Request device [7a:02.0] PASID 2 fault addr 7f81c968d000 [fault reason 113] SM: Present bit in first-level paging entry is clear Fix this by using aligned address for PASID-based-IOTLB invalidation. Fixes: 1c4f88b7 ("iommu/vt-d: Shared virtual address in scalable mode") Reported-and-tested-by: NGuo Kaijie <Kaijie.Guo@intel.com> Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20201231005323.2178523-2-baolu.lu@linux.intel.comSigned-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Atish Patra 提交于
stable inclusion from stable-5.10.9 commit ff2ca5439c50456e09c11be187048f840df490f2 bugzilla: 47457 -------------------------------- commit 7cd1af10 upstream. We should call irq trace only if interrupt is going to be enabled during excecption handling. Otherwise, it results in following warning during boot with lock debugging enabled. [ 0.000000] ------------[ cut here ]------------ [ 0.000000] DEBUG_LOCKS_WARN_ON(early_boot_irqs_disabled) [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:4085 lockdep_hardirqs_on_prepare+0x22a/0x22e [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-00022-ge20097fb37e2-dirty #548 [ 0.000000] epc: c005d5d4 ra : c005d5d4 sp : c1c01e80 [ 0.000000] gp : c1d456e0 tp : c1c0a980 t0 : 00000000 [ 0.000000] t1 : ffffffff t2 : 00000000 s0 : c1c01ea0 [ 0.000000] s1 : c100f360 a0 : 0000002d a1 : c00666ee [ 0.000000] a2 : 00000000 a3 : 00000000 a4 : 00000000 [ 0.000000] a5 : 00000000 a6 : c1c6b390 a7 : 3ffff00e [ 0.000000] s2 : c2384fe8 s3 : 00000000 s4 : 00000001 [ 0.000000] s5 : c1c0a980 s6 : c1d48000 s7 : c1613b4c [ 0.000000] s8 : 00000fff s9 : 80000200 s10: c1613b40 [ 0.000000] s11: 00000000 t3 : 00000000 t4 : 00000000 [ 0.000000] t5 : 00000001 t6 : 00000000 Fixes: 3c469798 ("riscv:Enable LOCKDEP_SUPPORT & fixup TRACE_IRQFLAGS_SUPPORT") Signed-off-by: NAtish Patra <atish.patra@wdc.com> Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jann Horn 提交于
stable inclusion from stable-5.10.9 commit c8c01da728ef65ad20d26a338819639a2ee25a13 bugzilla: 47457 -------------------------------- commit 8ff60eb0 upstream. acquire_slab() fails if there is contention on the freelist of the page (probably because some other CPU is concurrently freeing an object from the page). In that case, it might make sense to look for a different page (since there might be more remote frees to the page from other CPUs, and we don't want contention on struct page). However, the current code accidentally stops looking at the partial list completely in that case. Especially on kernels without CONFIG_NUMA set, this means that get_partial() fails and new_slab_objects() falls back to new_slab(), allocating new pages. This could lead to an unnecessary increase in memory fragmentation. Link: https://lkml.kernel.org/r/20201228130853.1871516-1-jannh@google.com Fixes: 7ced3719 ("slub: Acquire_slab() avoid loop") Signed-off-by: NJann Horn <jannh@google.com> Acked-by: NDavid Rientjes <rientjes@google.com> Acked-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Chris Wilson 提交于
stable inclusion from stable-5.10.9 commit ecca0c675bdecebdeb2f2eb76fb33520c441dacf bugzilla: 47457 -------------------------------- commit 09aa9e45 upstream. The mitigation is required for all gen7 platforms, now that it does not cause GPU hangs, restore it for Ivybridge and Baytrail. Fixes: 47f8253d ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Bloomfield Jon <jon.bloomfield@intel.com> Reviewed-by: NAkeem G Abodunrin <akeem.g.abodunrin@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-2-chris@chris-wilson.co.uk (cherry picked from commit 008ead6e) Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Imre Deak 提交于
stable inclusion from stable-5.10.9 commit de3f572607c29f7fdd1bfd754646d08e32db0249 bugzilla: 47457 -------------------------------- commit 2af52681 upstream. For an enabled DSC during HW readout the corresponding power reference is taken along the CRTC power domain references in get_crtc_power_domains(). Remove the incorrect get ref from the DSI encoder hook. Fixes: 2b68392e ("drm/i915/dsi: add support for DSC") Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201209153952.3397959-1-imre.deak@intel.com (cherry picked from commit 3a9ec563) Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Hans de Goede 提交于
drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence stable inclusion from stable-5.10.9 commit 54c9246a47fa8559c3ec6da2048e976a4b8750f6 bugzilla: 47457 -------------------------------- commit 00cb645f upstream. Commit 25b4620e ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode") added an intel_dsi_msleep() helper which skips sleeping if the MIPI-sequences have a version of 3 or newer and the panel is in vid-mode; and it moved a bunch of msleep-s over to this new helper. This was based on my reading of the big comment around line 730 which starts with "Panel enable/disable sequences from the VBT spec.", where the "v3 video mode seq" column does not have any wait t# entries. Given that this code has been used on a lot of different devices without issues until now, it seems that my interpretation of the spec here is mostly correct. But now I have encountered one device, an Acer Aspire Switch 10 E SW3-016, where the panel will not light up unless we do actually honor the panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence. What seems to set this model apart is that it is lacking a MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on delay usually happens. Fix the panel not lighting up on this model by using an unconditional msleep(panel_on_delay) instead of intel_dsi_msleep() when there is no MIPI_SEQ_DEASSERT_RESET sequence. Fixes: 25b4620e ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode") Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201118124058.26021-1-hdegoede@redhat.com (cherry picked from commit 6fdb335f) Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Arnd Bergmann 提交于
stable inclusion from stable-5.10.9 commit f6de06406411bfae3c1b7d4dad3fbab10a81e426 bugzilla: 47457 -------------------------------- commit b690bd54 upstream. Without crc32 support, this driver fails to link: arm-linux-gnueabi-ld: drivers/md/dm-zoned-metadata.o: in function `dmz_write_sb': dm-zoned-metadata.c:(.text+0xe98): undefined reference to `crc32_le' arm-linux-gnueabi-ld: drivers/md/dm-zoned-metadata.o: in function `dmz_check_sb': dm-zoned-metadata.c:(.text+0x7978): undefined reference to `crc32_le' Fixes: 3b1a94c8 ("dm zoned: drive-managed zoned block device target") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NDamien Le Moal <damien.lemoal@wdc.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Al Viro 提交于
stable inclusion from stable-5.10.9 commit c6dc4f8e617b4c12c519d2e01305fe5e3343f01d bugzilla: 47457 -------------------------------- commit a0a6df9a upstream. Unfortunately, there's userland code that used to rely upon these checks being done before anything else to check for UMOUNT_NOFOLLOW support. That broke in 41525f56 ("fs: refactor ksys_umount"). Separate those from the rest of checks and move them to ksys_umount(); unlike everything else in there, this can be sanely done there. Reported-by: NSargun Dhillon <sargun@sargun.me> Fixes: 41525f56 ("fs: refactor ksys_umount") Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Parav Pandit 提交于
stable inclusion from stable-5.10.9 commit 5cd483a7e78800b56a20530ad7da209b11b41df0 bugzilla: 47457 -------------------------------- commit 2cb091f6 upstream. When set_has_smi_cap() fails, multiport master cleanup is missed. Fix it by doing the correct error unwinding goto. Fixes: a989ea01 ("RDMA/mlx5: Move SMI caps logic") Link: https://lore.kernel.org/r/20210113121703.559778-3-leon@kernel.orgSigned-off-by: NParav Pandit <parav@nvidia.com> Signed-off-by: NLeon Romanovsky <leonro@nvidia.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Mark Bloch 提交于
stable inclusion from stable-5.10.9 commit bc296e43233ab8ac2250dcc8c9aa62baed54742f bugzilla: 47457 -------------------------------- commit 1c3aa6bd upstream. If the allocation of the fast path blue flame register fails, the driver should free the regular blue flame register allocated a statement above, not the one that it just failed to allocate. Fixes: 16c1975f ("IB/mlx5: Create profile infrastructure to add and remove stages") Link: https://lore.kernel.org/r/20210113121703.559778-6-leon@kernel.orgReported-by: NHans Petter Selasky <hanss@nvidia.com> Signed-off-by: NMark Bloch <mbloch@nvidia.com> Signed-off-by: NLeon Romanovsky <leonro@nvidia.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Michael Chan 提交于
stable inclusion from stable-5.10.9 commit 44693384c32462eb20a09e8eb6bce3ce343927e0 bugzilla: 47457 -------------------------------- commit 869c4d5e upstream. The function bnxt_get_ulp_stat_ctxs() does not count the stats contexts used by the RDMA driver correctly when the RDMA driver is freeing the MSIX vectors. It assumes that if the RDMA driver is registered, the additional stats contexts will be needed. This is not true when the RDMA driver is about to unregister and frees the MSIX vectors. This slight error leads to over accouting of the stats contexts needed after the RDMA driver has unloaded. This will cause some firmware warning and error messages in dmesg during subsequent config. changes or ifdown/ifup. Fix it by properly accouting for extra stats contexts only if the RDMA driver is registered and MSIX vectors have been successfully requested. Fixes: c027c6b4 ("bnxt_en: get rid of num_stat_ctxs variable") Reviewed-by: NYongping Zhang <yongping.zhang@broadcom.com> Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Dinghao Liu 提交于
stable inclusion from stable-5.10.9 commit 3090af5d1fb2357e987b777ea3e312d3899bec28 bugzilla: 47457 -------------------------------- commit a306aba9 upstream. If usnic_ib_qp_grp_create() fails at the first call, dev_list will not be freed on error, which leads to memleak. Fixes: e3cf00d0 ("IB/usnic: Add Cisco VIC low-level hardware driver") Link: https://lore.kernel.org/r/20201226074248.2893-1-dinghao.liu@zju.edu.cnSigned-off-by: NDinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: NLeon Romanovsky <leonro@nvidia.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Leon Romanovsky 提交于
stable inclusion from stable-5.10.9 commit 35694924a60a543d5c0840a57a16856f3f23653c bugzilla: 47457 -------------------------------- commit 3c638cdb upstream. xa_alloc_cyclic() call returns positive number if ID allocation succeeded but wrapped. It is not an error, so normalize the "ret" variable to zero as marker of not-an-error. drivers/infiniband/core/restrack.c:261 rdma_restrack_add() warn: 'ret' can be either negative or positive Fixes: fd47c2f9 ("RDMA/restrack: Convert internal DB from hash to XArray") Link: https://lore.kernel.org/r/20201216100753.1127638-1-leon@kernel.orgReported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NLeon Romanovsky <leonro@nvidia.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jan Kara 提交于
stable inclusion from stable-5.10.9 commit cd223237e792e86ae8b1c37df6e262a870ae11bc bugzilla: 47457 -------------------------------- commit dfd56c2c upstream. When setting password salt in the superblock, we forget to recompute the superblock checksum so it will not match until the next superblock modification which recomputes the checksum. Fix it. CC: Michael Halcrow <mhalcrow@google.com> Reported-by: NAndreas Dilger <adilger@dilger.ca> Fixes: 9bd8212f ("ext4 crypto: add encryption policy and password salt support") Signed-off-by: NJan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20201216101844.22917-8-jack@suse.czSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Stanley Chu 提交于
stable inclusion from stable-5.10.9 commit 4351cf25cb5204c13d5edfa5074417c6988b5ce6 bugzilla: 47457 -------------------------------- commit 1d53864c upstream. Currently if device needs to do flush or BKOP operations, the device VCC power is kept during runtime-suspend period. However, if system suspend is happening while device is runtime-suspended, such power may not be disabled successfully. The reasons may be, 1. If current PM level is the same as SPM level, device will keep runtime-suspended by ufshcd_system_suspend(). 2. Flush recheck work may not be scheduled successfully during system suspend period. If it can wake up the system, this is also not the intention of the recheck work. To fix this issue, simply runtime-resume the device if the flush is allowed during runtime suspend period. Flush capability will be disabled while leaving runtime suspend, and also not be allowed in system suspend period. Link: https://lore.kernel.org/r/20201222072905.32221-2-stanley.chu@mediatek.com Fixes: 51dd905b ("scsi: ufs: Fix WriteBooster flush during runtime suspend") Reviewed-by: NChaotian Jing <chaotian.jing@mediatek.com> Reviewed-by: NCan Guo <cang@codeaurora.org> Signed-off-by: NStanley Chu <stanley.chu@mediatek.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Trond Myklebust 提交于
stable inclusion from stable-5.10.9 commit 51121ea1d1e85c9ec2236c66a4c3fc9443cad1bf bugzilla: 47457 -------------------------------- commit 896567ee upstream. Before referencing the inode, we must ensure that the superblock can be referenced. Otherwise, we can end up with iput() calling superblock operations that are no longer valid or accessible. Fixes: ea7c38fe ("NFSv4: Ensure we reference the inode for return-on-close in delegreturn") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Trond Myklebust 提交于
stable inclusion from stable-5.10.9 commit b4689562fa95100caf31b2190bba84cb0e10770f bugzilla: 47457 -------------------------------- commit 113aac6d upstream. Before referencing the inode, we must ensure that the superblock can be referenced. Otherwise, we can end up with iput() calling superblock operations that are no longer valid or accessible. Fixes: e39d8a18 ("NFSv4: Fix an Oops during delegation callbacks") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Trond Myklebust 提交于
stable inclusion from stable-5.10.9 commit 01a12a24f9238024f69ee0b15ffa73511ba6c95f bugzilla: 47457 -------------------------------- commit cb2856c5 upstream. If we exit _lgopen_prepare_attached() without setting a layout, we will currently leak the plh_outstanding counter. Fixes: 411ae722 ("pNFS: Wait for stale layoutget calls to complete in pnfs_update_layout()") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Trond Myklebust 提交于
stable inclusion from stable-5.10.9 commit b666f394d6b8858c579df5dbe906d59517d82889 bugzilla: 47457 -------------------------------- commit 46c9ea1d upstream. We must ensure that we pass a layout segment to nfs_retry_commit() when we're cleaning up after pnfs_bucket_alloc_ds_commits(). Otherwise, requests that should be committed to the DS will get committed to the MDS. Do so by ensuring that pnfs_bucket_get_committing() always tries to return a layout segment when it returns a non-empty page list. Fixes: c84bea59 ("NFS/pNFS: Simplify bucket layout segment reference counting") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Trond Myklebust 提交于
stable inclusion from stable-5.10.9 commit 067aefcdfc1e50662b9ac80d3662c4fff3075313 bugzilla: 47457 -------------------------------- commit 1757655d upstream. In pnfs_generic_clear_request_commit(), we try calling pnfs_free_bucket_lseg() before we remove the request from the DS bucket. That will always fail, since the point is to test for whether or not that bucket is empty. Fixes: c84bea59 ("NFS/pNFS: Simplify bucket layout segment reference counting") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Scott Mayhew 提交于
stable inclusion from stable-5.10.9 commit e6ae16467af19d2572a48af59946223bd089a06e bugzilla: 47457 -------------------------------- commit c98e9daa upstream. Several existing dprink()/dfprintk() calls were converted to use the new mount API logging macros by commit ce8866f0 ("NFS: Attach supplementary error information to fs_context"). If the fs_context was not created using fsopen() then it will not have had a log buffer allocated for it, and the new mount API logging macros will wind up calling printk(). This can result in syslog messages being logged where previously there were none... most notably "NFS4: Couldn't follow remote path", which can happen if the client is auto-negotiating a protocol version with an NFS server that doesn't support the higher v4.x versions. Convert the nfs_errorf(), nfs_invalf(), and nfs_warnf() macros to check for the existence of the fs_context's log buffer and call dprintk() if it doesn't exist. Add nfs_ferrorf(), nfs_finvalf(), and nfs_warnf(), which do the same thing but take an NFS debug flag as an argument and call dfprintk(). Finally, modify the "NFS4: Couldn't follow remote path" message to use nfs_ferrorf(). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207385Signed-off-by: NScott Mayhew <smayhew@redhat.com> Reviewed-by: NBenjamin Coddington <bcodding@redhat.com> Fixes: ce8866f0 ("NFS: Attach supplementary error information to fs_context.") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Trond Myklebust 提交于
stable inclusion from stable-5.10.9 commit 06f58dbc49a23c99e5c0f246879ed16667f7bf8f bugzilla: 47457 -------------------------------- commit 2c8d5fc3 upstream. If a layout return is in progress, we should wait for it to complete, in case the layout segment we are picking up gets returned too. Fixes: 30cb3ee2 ("pNFS: Handle NFS4ERR_OLD_STATEID on layoutreturn by bumping the state seqid") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Trond Myklebust 提交于
stable inclusion from stable-5.10.9 commit ecaaad18013317f8f5bbfd20a6bb77fb8e3c9380 bugzilla: 47457 -------------------------------- commit 67bbceed upstream. If the layout return-on-close failed because the layoutreturn was never sent, then we should mark the layout for return again. Fixes: 9c47b18c ("pNFS: Ensure we do clear the return-on-close layout stateid on fatal errors") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Trond Myklebust 提交于
stable inclusion from stable-5.10.9 commit f128de17c8d46a0dba5db32206d198551b111e17 bugzilla: 47457 -------------------------------- commit 078000d0 upstream. If the inode is being evicted, it should be safe to run return-on-close, so we should do it to ensure we don't inadvertently leak layout segments. Fixes: 1c5bd76d ("pNFS: Enable layoutreturn operation for return-on-close") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Dave Wysochanski 提交于
stable inclusion from stable-5.10.9 commit 1b42712e43e5d574a985661e336e48b0f6ba06b6 bugzilla: 47457 -------------------------------- commit 3d1a90ab upstream. It is only safe to call the tracepoint before rpc_put_task() because 'data' is freed inside nfs4_lock_release (rpc_release). Fixes: 48c9579a ("Adding stateid information to tracepoints") Signed-off-by: NDave Wysochanski <dwysocha@redhat.com> Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Sagi Grimberg 提交于
stable inclusion from stable-5.10.9 commit 76600f633bb977eb758a7c9bc710b28f3bde3670 bugzilla: 47457 -------------------------------- commit ada83177 upstream. We shouldn't call smp_processor_id() in a preemptible context, but this is advisory at best, so instead call __smp_processor_id(). Fixes: db5ad6b7 ("nvme-tcp: try to send request in queue_rq context") Reported-by: NOr Gerlitz <gerlitz.or@gmail.com> Reported-by: NYi Zhang <yi.zhang@redhat.com> Signed-off-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Sagi Grimberg 提交于
stable inclusion from stable-5.10.9 commit b1e9f635a5e3a2f2ba7461f73426ad54d247ac9c bugzilla: 47457 -------------------------------- commit ca1ff67d upstream. When a bio merges, we can get a request that spans multiple bios, and the overall request payload size is the sum of all bios. When we calculate how much we need to send from the existing bio (and bvec), we did not take into account the iov_iter byte count cap. Since multipage bvecs support, bvecs can split in the middle which means that when we account for the last bvec send we should also take the iov_iter byte count cap as it might be lower than the last bvec size. Reported-by: NHao Wang <pkuwangh@gmail.com> Fixes: 3f2304f8 ("nvme-tcp: add NVMe over TCP host driver") Tested-by: NHao Wang <pkuwangh@gmail.com> Signed-off-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Sagi Grimberg 提交于
stable inclusion from stable-5.10.9 commit c09af1ee7c232d22b0264fbc69b997b1b851ade8 bugzilla: 47457 -------------------------------- commit 5ab25a32 upstream. Discovery controllers usually don't support smart log page command. So when we connect to the discovery controller we see this warning: nvme nvme0: Failed to read smart log (error 24577) nvme nvme0: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 192.168.123.1:8009 nvme nvme0: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" Introduce a new helper to understand if the controller is a discovery controller and use this helper to skip nvme_init_hwmon (also use it in other places that we check if the controller is a discovery controller). Fixes: 400b6a7b ("nvme: Add hardware monitoring support") Signed-off-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Israel Rukshin 提交于
stable inclusion from stable-5.10.9 commit a60c7aaaccf65c075aca32565c9d06a12fb0a95e bugzilla: 47457 -------------------------------- commit 7a846656 upstream. When setting port traddr to INADDR_ANY, the listening cm_id->device is NULL. The associate IB device is known only when a connect request event arrives, so checking T10-PI device capability should be done at this stage. Fixes: b09160c3 ("nvmet-rdma: add metadata/T10-PI support") Signed-off-by: NIsrael Rukshin <israelr@nvidia.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Reviewed-by: NMax Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Dan Carpenter 提交于
stable inclusion from stable-5.10.9 commit a835cff329a52583cf48c67a46229ca524e418b3 bugzilla: 47457 -------------------------------- commit f373a811 upstream. Return -ETIMEDOUT if the dsp boot times out instead of returning success. Fixes: cb6a5528 ("ASoC: Intel: cnl: Add sst library functions for cnl platform") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NCezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/X9NEvCzuN+IObnTN@mwandaSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-