提交 · 93beb33fca5c386d90f445eab712e65e23a36cf3 · openeuler / Kernel

19 4月, 2021 40 次提交

static_call: Allow module use without exposing static_call_key · 93beb33f

由 Josh Poimboeuf 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit a63068e93917927d443e32609dde9298bcd14833
bugzilla: 51493

--------------------------------

[ Upstream commit 73f44fe1 ]

When exporting static_call_key; with EXPORT_STATIC_CALL*(), the module
can use static_call_update() to change the function called.  This is
not desirable in general.

Not exporting static_call_key however also disallows usage of
static_call(), since objtool needs the key to construct the
static_call_site.

Solve this by allowing objtool to create the static_call_site using
the trampoline address when it builds a module and cannot find the
static_call_key symbol. The module loader will then try and map the
trampole back to a key before it constructs the normal sites list.

Doing this requires a trampoline -> key associsation, so add another
magic section that keeps those.
Originally-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lkml.kernel.org/r/20210127231837.ifddpn7rhwdaepiu@trebleSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

93beb33f

static_call: Pull some static_call declarations to the type headers · 729a9bb2

由 Peter Zijlstra 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 433cd7ca386c832a6e165d76f376c29dcac14fbb
bugzilla: 51493

--------------------------------

[ Upstream commit 880cfed3 ]

Some static call declarations are going to be needed on low level header
files. Move the necessary material to the dedicated static call types
header to avoid inclusion dependency hell.
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NFrederic Weisbecker <frederic@kernel.org>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lkml.kernel.org/r/20210118141223.123667-4-frederic@kernel.orgSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

729a9bb2

ia64: fix ptrace(PTRACE_SYSCALL_INFO_EXIT) sign · 6adf7567

由 Sergei Trofimovich 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 533c293f737c68045dd628d6dae05255c9fa1993
bugzilla: 51493

--------------------------------

[ Upstream commit 61bf318e ]

In https://bugs.gentoo.org/769614 Dmitry noticed that
`ptrace(PTRACE_GET_SYSCALL_INFO)` does not return error sign properly.

The bug is in mismatch between get/set errors:

static inline long syscall_get_error(struct task_struct *task,
                                     struct pt_regs *regs)
{
        return regs->r10 == -1 ? regs->r8:0;
}

static inline long syscall_get_return_value(struct task_struct *task,
                                            struct pt_regs *regs)
{
        return regs->r8;
}

static inline void syscall_set_return_value(struct task_struct *task,
                                            struct pt_regs *regs,
                                            int error, long val)
{
        if (error) {
                /* error < 0, but ia64 uses > 0 return value */
                regs->r8 = -error;
                regs->r10 = -1;
        } else {
                regs->r8 = val;
                regs->r10 = 0;
        }
}

Tested on v5.10 on rx3600 machine (ia64 9040 CPU).

Link: https://lkml.kernel.org/r/20210221002554.333076-2-slyfox@gentoo.org
Link: https://bugs.gentoo.org/769614Signed-off-by: NSergei Trofimovich <slyfox@gentoo.org>
Reported-by: NDmitry V. Levin <ldv@altlinux.org>
Reviewed-by: NDmitry V. Levin <ldv@altlinux.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6adf7567

ia64: fix ia64_syscall_get_set_arguments() for break-based syscalls · 9c98bf8f

由 Sergei Trofimovich 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit d76e207991c462d7a8b4f8b7f8dcb6f2387abfe9
bugzilla: 51493

--------------------------------

[ Upstream commit 0ceb1ace ]

In https://bugs.gentoo.org/769614 Dmitry noticed that
`ptrace(PTRACE_GET_SYSCALL_INFO)` does not work for syscalls called via
glibc's syscall() wrapper.

ia64 has two ways to call syscalls from userspace: via `break` and via
`eps` instructions.

The difference is in stack layout:

1. `eps` creates simple stack frame: no locals, in{0..7} == out{0..8}
2. `break` uses userspace stack frame: may be locals (glibc provides
   one), in{0..7} == out{0..8}.

Both work fine in syscall handling cde itself.

But `ptrace(PTRACE_GET_SYSCALL_INFO)` uses unwind mechanism to
re-extract syscall arguments but it does not account for locals.

The change always skips locals registers. It should not change `eps`
path as kernel's handler already enforces locals=0 and fixes `break`.

Tested on v5.10 on rx3600 machine (ia64 9040 CPU).

Link: https://lkml.kernel.org/r/20210221002554.333076-1-slyfox@gentoo.org
Link: https://bugs.gentoo.org/769614Signed-off-by: NSergei Trofimovich <slyfox@gentoo.org>
Reported-by: NDmitry V. Levin <ldv@altlinux.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

9c98bf8f

mm/fork: clear PASID for new mm · 70ae9785

由 Fenghua Yu 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 7077d5e7f07439a45d2b645ba1ed4ca67592a835
bugzilla: 51493

--------------------------------

[ Upstream commit 82e69a12 ]

When a new mm is created, its PASID should be cleared, i.e.  the PASID is
initialized to its init state 0 on both ARM and X86.

This patch was part of the series introducing mm->pasid, but got lost
along the way [1].  It still makes sense to have it, because each address
space has a different PASID.  And the IOMMU code in
iommu_sva_alloc_pasid() expects the pasid field of a new mm struct to be
cleared.

[1] https://lore.kernel.org/linux-iommu/YDgh53AcQHT+T3L0@otcwcpicx3.sc.intel.com/

Link: https://lkml.kernel.org/r/20210302103837.2562625-1-jean-philippe@linaro.orgSigned-off-by: NFenghua Yu <fenghua.yu@intel.com>
Signed-off-by: NJean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: NTony Luck <tony.luck@intel.com>
Cc: Jacob Pan <jacob.jun.pan@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

70ae9785

block: Suppress uevent for hidden device when removed · 55e27551

由 Daniel Wagner 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 07feac84efc65c7d0a4ad44096334766bbe68dcb
bugzilla: 51493

--------------------------------

[ Upstream commit 9ec49144 ]

register_disk() suppress uevents for devices with the GENHD_FL_HIDDEN
but enables uevents at the end again in order to announce disk after
possible partitions are created.

When the device is removed the uevents are still on and user land sees
'remove' messages for devices which were never 'add'ed to the system.

  KERNEL[95481.571887] remove   /devices/virtual/nvme-fabrics/ctl/nvme5/nvme0c5n1 (block)

Let's suppress the uevents for GENHD_FL_HIDDEN by not enabling the
uevents at all.
Signed-off-by: NDaniel Wagner <dwagner@suse.de>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMartin Wilck <mwilck@suse.com>
Link: https://lore.kernel.org/r/20210311151917.136091-1-dwagner@suse.deSigned-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

55e27551

nfs: we don't support removing system.nfs4_acl · 6193c00f

由 J. Bruce Fields 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 9f704608010b94c84948cf4cbdf79994052341e7
bugzilla: 51493

--------------------------------

[ Upstream commit 4f8be1f5 ]

The NFSv4 protocol doesn't have any notion of reomoving an attribute, so
removexattr(path,"system.nfs4_acl") doesn't make sense.

There's no documented return value.  Arguably it could be EOPNOTSUPP but
I'm a little worried an application might take that to mean that we
don't support ACLs or xattrs.  How about EINVAL?
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6193c00f

nvme-pci: add the DISABLE_WRITE_ZEROES quirk for a Samsung PM1725a · dbd3c0be

由 Dmitry Monakhov 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 3dab008e23bdd1807e0a987ebdf6f5dfc673c348
bugzilla: 51493

--------------------------------

[ Upstream commit abbb5f59 ]

This adds a quirk for Samsung PM1725a drive which fixes timeouts and
I/O errors due to the fact that the controller does not properly
handle the Write Zeroes command, dmesg log:

nvme nvme0: I/O 528 QID 10 timeout, aborting
nvme nvme0: I/O 529 QID 10 timeout, aborting
nvme nvme0: I/O 530 QID 10 timeout, aborting
nvme nvme0: I/O 531 QID 10 timeout, aborting
nvme nvme0: I/O 532 QID 10 timeout, aborting
nvme nvme0: I/O 533 QID 10 timeout, aborting
nvme nvme0: I/O 534 QID 10 timeout, aborting
nvme nvme0: I/O 535 QID 10 timeout, aborting
nvme nvme0: Abort status: 0x0
nvme nvme0: Abort status: 0x0
nvme nvme0: Abort status: 0x0
nvme nvme0: Abort status: 0x0
nvme nvme0: Abort status: 0x0
nvme nvme0: Abort status: 0x0
nvme nvme0: Abort status: 0x0
nvme nvme0: Abort status: 0x0
nvme nvme0: I/O 528 QID 10 timeout, reset controller
nvme nvme0: controller is down; will reset: CSTS=0x3, PCI_STATUS=0x10
nvme nvme0: Device not ready; aborting reset, CSTS=0x3
nvme nvme0: Device not ready; aborting reset, CSTS=0x3
nvme nvme0: Removing after probe failure status: -19
nvme0n1: detected capacity change from 6251233968 to 0
blk_update_request: I/O error, dev nvme0n1, sector 32776 op 0x1:(WRITE) flags 0x3000 phys_seg 6 prio class 0
blk_update_request: I/O error, dev nvme0n1, sector 113319936 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 0
Buffer I/O error on dev nvme0n1p2, logical block 1, lost async page write
blk_update_request: I/O error, dev nvme0n1, sector 113319680 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0
Buffer I/O error on dev nvme0n1p2, logical block 2, lost async page write
blk_update_request: I/O error, dev nvme0n1, sector 113319424 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0
Buffer I/O error on dev nvme0n1p2, logical block 3, lost async page write
blk_update_request: I/O error, dev nvme0n1, sector 113319168 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0
Buffer I/O error on dev nvme0n1p2, logical block 4, lost async page write
blk_update_request: I/O error, dev nvme0n1, sector 113318912 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0
Buffer I/O error on dev nvme0n1p2, logical block 5, lost async page write
blk_update_request: I/O error, dev nvme0n1, sector 113318656 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0
Buffer I/O error on dev nvme0n1p2, logical block 6, lost async page write
blk_update_request: I/O error, dev nvme0n1, sector 113318400 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0
blk_update_request: I/O error, dev nvme0n1, sector 113318144 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0
blk_update_request: I/O error, dev nvme0n1, sector 113317888 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0
Signed-off-by: NDmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

dbd3c0be

nvme-rdma: Fix a use after free in nvmet_rdma_write_data_done · 3eb2713e

由 Lv Yunlong 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 8f0534c96ac80bb05dfa74897c151f49b37d6663
bugzilla: 51493

--------------------------------

[ Upstream commit abec6561 ]

In nvmet_rdma_write_data_done, rsp is recoverd by wc->wr_cqe and freed by
nvmet_rdma_release_rsp(). But after that, pr_info() used the freed
chunk's member object and could leak the freed chunk address with
wc->wr_cqe by computing the offset.
Signed-off-by: NLv Yunlong <lyl2019@mail.ustc.edu.cn>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

3eb2713e

nvme-core: check ctrl css before setting up zns · dd21332d

由 Chaitanya Kulkarni 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit c7b3f6db97c2c3969564f270d941d12f6ddbc0eb
bugzilla: 51493

--------------------------------

[ Upstream commit 0ec84df4 ]

Ensure multiple Command Sets are supported before starting to setup a
ZNS namespace.
Signed-off-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
[hch: move the check around a bit]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

dd21332d

nvme-fc: return NVME_SC_HOST_ABORTED_CMD when a command has been aborted · 24e4d580

由 Hannes Reinecke 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 9083dc773d67d41d562ceb6a99a8c2f5160f90c7
bugzilla: 51493

--------------------------------

[ Upstream commit ae3afe63 ]

When a command has been aborted we should return NVME_SC_HOST_ABORTED_CMD
to be consistent with the other transports.
Signed-off-by: NHannes Reinecke <hare@suse.de>
Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NJames Smart <jsmart2021@gmail.com>
Reviewed-by: NDaniel Wagner <dwagner@suse.de>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

24e4d580

nvme-fc: set NVME_REQ_CANCELLED in nvme_fc_terminate_exchange() · 10f5f4dd

由 Hannes Reinecke 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 4d6aea29a795ff8b52e3669447162a1942f0b49d
bugzilla: 51493

--------------------------------

[ Upstream commit 3c7aafbc ]

nvme_fc_terminate_exchange() is being called when exchanges are
being deleted, and as such we should be setting the NVME_REQ_CANCELLED
flag to have identical behaviour on all transports.
Signed-off-by: NHannes Reinecke <hare@suse.de>
Reviewed-by: NKeith Busch <kbusch@kernel.org>
Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NJames Smart <jsmart2021@gmail.com>
Reviewed-by: NDaniel Wagner <dwagner@suse.de>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

10f5f4dd

nvme: add NVME_REQ_CANCELLED flag in nvme_cancel_request() · cc764005

由 Hannes Reinecke 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 7e62a89b51dd927853137eb1b9814b0451535390
bugzilla: 51493

--------------------------------

[ Upstream commit d3589381 ]

NVME_REQ_CANCELLED is translated into -EINTR in nvme_submit_sync_cmd(),
so we should be setting this flags during nvme_cancel_request() to
ensure that the callers to nvme_submit_sync_cmd() will get the correct
error code when the controller is reset.
Signed-off-by: NHannes Reinecke <hare@suse.de>
Reviewed-by: NKeith Busch <kbusch@kernel.org>
Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NChao Leng <lengchao@huawei.com>
Reviewed-by: NDaniel Wagner <dwagner@suse.de>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

cc764005

nvme: simplify error logic in nvme_validate_ns() · 93884b3d

由 Hannes Reinecke 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit d8b17df7bf8052dbdb1503e9066899e679d3bb2d
bugzilla: 51493

--------------------------------

[ Upstream commit d95c1f41 ]

We only should remove namespaces when we get fatal error back from
the device or when the namespace IDs have changed.
So instead of painfully masking out error numbers which might indicate
that the error should be ignored we could use an NVME status code
to indicated when the namespace should be removed.
That simplifies the final logic and makes it less error-prone.
Signed-off-by: NHannes Reinecke <hare@suse.de>
Reviewed-by: NKeith Busch <kbusch@kernel.org>
Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NDaniel Wagner <dwagner@suse.de>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

93884b3d

drm/radeon: fix AGP dependency · 94304ee3

由 Christian König 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit b91230a0013f8a80192be6f0d77bcb89142eff32
bugzilla: 51493

--------------------------------

[ Upstream commit cba2afb6 ]

When AGP is compiled as module radeon must be compiled as module as
well.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

94304ee3

drm/amdgpu: fb BO should be ttm_bo_type_device · aa78486b

由 Nirmoy Das 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 35d4f071282852181582312c47ccdcecbab284d4
bugzilla: 51493

--------------------------------

[ Upstream commit 521f04f9 ]

FB BO should not be ttm_bo_type_kernel type and
amdgpufb_create_pinned_object() pins the FB BO anyway.
Signed-off-by: NNirmoy Das <nirmoy.das@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

aa78486b

drm/amd/display: Revert dram_clock_change_latency for DCN2.1 · ba14fb7a

由 Sung Lee 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit a255d14eb5dc592ad74bfee53adbce63a73fdc50
bugzilla: 51493

--------------------------------

[ Upstream commit b0075d11 ]

[WHY & HOW]
Using values provided by DF for latency may cause hangs in
multi display configurations. Revert change to previous value.
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NSung Lee <sung.lee@amd.com>
Reviewed-by: NHaonan Wang <Haonan.Wang2@amd.com>
Acked-by: NEryk Brol <eryk.brol@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ba14fb7a

block: Fix REQ_OP_ZONE_RESET_ALL handling · 87a6903a

由 Damien Le Moal 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit d27b0964ade97211fa7a8cd0010ddc8737a054a5
bugzilla: 51493

--------------------------------

[ Upstream commit faa44c69 ]

Similarly to a single zone reset operation (REQ_OP_ZONE_RESET), execute
REQ_OP_ZONE_RESET_ALL operations with REQ_SYNC set.
Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

87a6903a

regulator: qcom-rpmh: Correct the pmic5_hfsmps515 buck · 8720ab56

由 satya priya 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit c9d1f6ad1e256fd5b59339bee03bd0e4d0fc3e47
bugzilla: 51493

--------------------------------

[ Upstream commit e610e072 ]

Correct the REGULATOR_LINEAR_RANGE and n_voltges for
pmic5_hfsmps515 buck.
Signed-off-by: Nsatya priya <skakit@codeaurora.org>
Link: https://lore.kernel.org/r/1614155592-14060-4-git-send-email-skakit@codeaurora.orgSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8720ab56

kselftest: arm64: Fix exit code of sve-ptrace · 1215152d

由 Mark Brown 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 6366a5bb888baee5d9f7a5b6168066366e541117
bugzilla: 51493

--------------------------------

[ Upstream commit 07e64488 ]

We track if sve-ptrace encountered a failure in a variable but don't
actually use that value when we exit the program, do so.
Signed-off-by: NMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210309190304.39169-1-broonie@kernel.orgSigned-off-by: NWill Deacon <will@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

1215152d

u64_stats,lockdep: Fix u64_stats_init() vs lockdep · 1317ddfe

由 Peter Zijlstra 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit da5bc0c21c04840b235650b1aac8d4421fdb366a
bugzilla: 51493

--------------------------------

[ Upstream commit d5b0e067 ]

Jakub reported that:

    static struct net_device *rtl8139_init_board(struct pci_dev *pdev)
    {
	    ...
	    u64_stats_init(&tp->rx_stats.syncp);
	    u64_stats_init(&tp->tx_stats.syncp);
	    ...
    }

results in lockdep getting confused between the RX and TX stats lock.
This is because u64_stats_init() is an inline calling seqcount_init(),
which is a macro using a static variable to generate a lockdep class.

By wrapping that in an inline, we negate the effect of the macro and
fold the static key variable, hence the confusion.

Fix by also making u64_stats_init() a macro for the case where it
matters, leaving the other case an inline for argument validation
etc.
Reported-by: NJakub Kicinski <kuba@kernel.org>
Debugged-by: N"Ahmed S. Darwish" <a.darwish@linutronix.de>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: N"Erhard F." <erhard_f@mailbox.org>
Link: https://lkml.kernel.org/r/YEXicy6+9MksdLZh@hirez.programming.kicks-ass.netSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

1317ddfe

staging: rtl8192e: fix kconfig dependency on CRYPTO · 9302b912

由 Julian Braha 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit f89338395545991d176477462ca0f08f36161d5c
bugzilla: 51493

--------------------------------

[ Upstream commit 7c361945 ]

When RTLLIB_CRYPTO_TKIP is enabled and CRYPTO is disabled,
Kbuild gives the following warning:

WARNING: unmet direct dependencies detected for CRYPTO_MICHAEL_MIC
  Depends on [n]: CRYPTO [=n]
  Selected by [m]:
  - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m]

WARNING: unmet direct dependencies detected for CRYPTO_LIB_ARC4
  Depends on [n]: CRYPTO [=n]
  Selected by [m]:
  - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m]
  - RTLLIB_CRYPTO_WEP [=m] && STAGING [=y] && RTLLIB [=m]

This is because RTLLIB_CRYPTO_TKIP selects CRYPTO_MICHAEL_MIC and
CRYPTO_LIB_ARC4, without depending on or selecting CRYPTO,
despite those config options being subordinate to CRYPTO.
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NJulian Braha <julianbraha@gmail.com>
Link: https://lore.kernel.org/r/20210222180607.399753-1-julianbraha@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

9302b912

habanalabs: Call put_pid() when releasing control device · 2f5b6028

由 Tomer Tayar 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit eb4154fb61e210b4a3b3c1a4b0e045c7d516255b
bugzilla: 51493

--------------------------------

[ Upstream commit 27ac5aad ]

The refcount of the "hl_fpriv" structure is not used for the control
device, and thus hl_hpriv_put() is not called when releasing this
device.
This results with no call to put_pid(), so add it explicitly in
hl_device_release_ctrl().
Signed-off-by: NTomer Tayar <ttayar@habana.ai>
Reviewed-by: NOded Gabbay <ogabbay@kernel.org>
Signed-off-by: NOded Gabbay <ogabbay@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2f5b6028

sparc64: Fix opcode filtering in handling of no fault loads · 105aca2d

由 Rob Gardner 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit f2b38f03a3f71c30c77a4516b26c8bea13cc08ce
bugzilla: 51493

--------------------------------

[ Upstream commit e5e8b80d ]

is_no_fault_exception() has two bugs which were discovered via random
opcode testing with stress-ng. Both are caused by improper filtering
of opcodes.

The first bug can be triggered by a floating point store with a no-fault
ASI, for instance "sta %f0, [%g0] #ASI_PNF", opcode C1A01040.

The code first tests op3[5] (0x1000000), which denotes a floating
point instruction, and then tests op3[2] (0x200000), which denotes a
store instruction. But these bits are not mutually exclusive, and the
above mentioned opcode has both bits set. The intent is to filter out
stores, so the test for stores must be done first in order to have
any effect.

The second bug can be triggered by a floating point load with one of
the invalid ASI values 0x8e or 0x8f, which pass this check in
is_no_fault_exception():
     if ((asi & 0xf2) == ASI_PNF)

An example instruction is "ldqa [%l7 + %o7] #ASI 0x8f, %f38",
opcode CF95D1EF. Asi values greater than 0x8b (ASI_SNFL) are fatal
in handle_ldf_stq(), and is_no_fault_exception() must not allow these
invalid asi values to make it that far.

In both of these cases, handle_ldf_stq() reacts by calling
sun4v_data_access_exception() or spitfire_data_access_exception(),
which call is_no_fault_exception() and results in an infinite
recursion.
Signed-off-by: NRob Gardner <rob.gardner@oracle.com>
Tested-by: NAnatoly Pugachev <matorola@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

105aca2d

umem: fix error return code in mm_pci_probe() · 39e0b737

由 Wei Yongjun 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 58b34195b33f675c6bdd49319d4403fe5ae8f422
bugzilla: 51493

--------------------------------

[ Upstream commit eeb05595 ]

Fix to return negative error code -ENOMEM from the blk_alloc_queue()
and dma_alloc_coherent() error handling cases instead of 0, as done
elsewhere in this function.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20210308123501.2573816-1-weiyongjun1@huawei.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

39e0b737

kbuild: dummy-tools: fix inverted tests for gcc · f7a9b964

由 Jiri Slaby 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit feaa91193ad38d1cdeea0fa5e1ec1eeaf1fc9a36
bugzilla: 51493

--------------------------------

[ Upstream commit b3d9fc14 ]

There is a test in Kconfig which takes inverted value of a compiler
check:
* config CC_HAS_INT128
        def_bool !$(cc-option,$(m64-flag) -D__SIZEOF_INT128__=0)

This results in CC_HAS_INT128 not being in super-config generated by
dummy-tools. So take this into account in the gcc script.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f7a9b964

kbuild: add image_name to no-sync-config-targets · 04026950

由 Masahiro Yamada 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit ede8be3ae078113fb536159a548890ecc39fbc87
bugzilla: 51493

--------------------------------

[ Upstream commit 993bdde9 ]

'make image_name' needs include/config/auto.conf to show the correct
output because KBUILD_IMAGE depends on CONFIG options, but should not
attempt to resync the configuration.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

04026950

irqchip/ingenic: Add support for the JZ4760 · fd5c6e53

由 Paul Cercueil 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 264bb27b9fe456cf722bd83d3bdbaca394b801ee
bugzilla: 51493

--------------------------------

[ Upstream commit 5fbecd23 ]

Add support for the interrupt controller found in the JZ4760 SoC, which
works exactly like the one in the JZ4770.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210307172014.73481-2-paul@crapouillou.netSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

fd5c6e53

cifs: change noisy error message to FYI · 7135589c

由 Paulo Alcantara 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit b684c380f0b9cd993ce45673dc9ef852ad6c3739
bugzilla: 51493

--------------------------------

[ Upstream commit e3d100ea ]

A customer has reported that their dmesg were being flooded by

  CIFS: VFS: \\server Cancelling wait for mid xxx cmd: a
  CIFS: VFS: \\server Cancelling wait for mid yyy cmd: b
  CIFS: VFS: \\server Cancelling wait for mid zzz cmd: c

because some processes that were performing statfs(2) on the share had
been interrupted due to their automount setup when certain users
logged in and out.

Change it to FYI as they should be mostly informative rather than
error messages.
Signed-off-by: NPaulo Alcantara (SUSE) <pc@cjr.nz>
Reviewed-by: NAurelien Aptel <aaptel@suse.com>
Reviewed-by: NRonnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: NSteve French <stfrench@microsoft.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

7135589c

atm: idt77252: fix null-ptr-dereference · 85e8194d

由 Tong Zhang 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 758bca385a7916a913be341ffd39e88a1243c4a0
bugzilla: 51493

--------------------------------

[ Upstream commit 4416e985 ]

this one is similar to the phy_data allocation fix in uPD98402, the
driver allocate the idt77105_priv and store to dev_data but later
dereference using dev->dev_data, which will cause null-ptr-dereference.

fix this issue by changing dev_data to phy_data so that PRIV(dev) can
work correctly.
Signed-off-by: NTong Zhang <ztong0001@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

85e8194d

atm: uPD98402: fix incorrect allocation · 2f3739a1

由 Tong Zhang 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit f35954a3961b71e6ad0667cd7bb8f430f3401aaa
bugzilla: 51493

--------------------------------

[ Upstream commit 3153724f ]

dev->dev_data is set in zatm.c, calling zatm_start() will overwrite this
dev->dev_data in uPD98402_start() and a subsequent PRIV(dev)->lock
(i.e dev->phy_data->lock) will result in a null-ptr-dereference.

I believe this is a typo and what it actually want to do is to allocate
phy_data instead of dev_data.
Signed-off-by: NTong Zhang <ztong0001@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2f3739a1

net: enetc: set MAC RX FIFO to recommended value · dd35b9bb

由 Alex Marginean 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 852143ed96e2cac4a973041a24f443cc6315e055
bugzilla: 51493

--------------------------------

[ Upstream commit 1b2395df ]

On LS1028A, the MAC RX FIFO defaults to the value 2, which is too high
and may lead to RX lock-up under traffic at a rate higher than 6 Gbps.
Set it to 1 instead, as recommended by the hardware design team and by
later versions of the ENETC block guide.
Signed-off-by: NAlex Marginean <alexandru.marginean@nxp.com>
Reviewed-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
Reviewed-by: NJason Liu <jason.hui.liu@nxp.com>
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

dd35b9bb

net: davicom: Use platform_get_irq_optional() · 9991fb71

由 Paul Cercueil 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 697082b125b07c57faffd70b12a42891d0803dd1
bugzilla: 51493

--------------------------------

[ Upstream commit 2e269622 ]

The second IRQ line really is optional, so use
platform_get_irq_optional() to obtain it.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

9991fb71

net: wan: fix error return code of uhdlc_init() · 76f005aa

由 Jia-Ju Bai 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit e6946ef438487695fd273294af2375c13e1b3a54
bugzilla: 51493

--------------------------------

[ Upstream commit 62765d39 ]

When priv->rx_skbuff or priv->tx_skbuff is NULL, no error return code of
uhdlc_init() is assigned.
To fix this bug, ret is assigned with -ENOMEM in these cases.
Reported-by: NTOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

76f005aa

net: hisilicon: hns: fix error return code of hns_nic_clear_all_rx_fetch() · 998911e8

由 Jia-Ju Bai 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 184dc037575ca7d47edd5f37d6ada6dc11e8dad9
bugzilla: 51493

--------------------------------

[ Upstream commit 143c253f ]

When hns_assemble_skb() returns NULL to skb, no error return code of
hns_nic_clear_all_rx_fetch() is assigned.
To fix this bug, ret is assigned with -ENOMEM in this case.
Reported-by: NTOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

998911e8

NFS: Correct size calculation for create reply length · 79abcc01

由 Frank Sorenson 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 9d1a5392aca1943bfea6f424346764db75018431
bugzilla: 51493

--------------------------------

[ Upstream commit ad3dbe35 ]

CREATE requests return a post_op_fh3, rather than nfs_fh3. The
post_op_fh3 includes an extra word to indicate 'handle_follows'.

Without that additional word, create fails when full 64-byte
filehandles are in use.

Add NFS3_post_op_fh_sz, and correct the size calculation for
NFS3_createres_sz.
Signed-off-by: NFrank Sorenson <sorenson@redhat.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

79abcc01

nfs: fix PNFS_FLEXFILE_LAYOUT Kconfig default · 2303f2e0

由 Timo Rothenpieler 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 2479c6b9ef36f9fd7ed37dbeb8f220bdeb175710
bugzilla: 51493

--------------------------------

[ Upstream commit a0590473 ]

This follows what was done in 8c2fabc6.
With the default being m, it's impossible to build the module into the
kernel.
Signed-off-by: NTimo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2303f2e0

gpiolib: acpi: Add missing IRQF_ONESHOT · 1a03b2c8

由 Yang Li 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit b48779c863c018bd5ec4ba966cebf2ab656093b8
bugzilla: 51493

--------------------------------

[ Upstream commit 6e5d5791 ]

fixed the following coccicheck:
./drivers/gpio/gpiolib-acpi.c:176:7-27: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT

Make sure threaded IRQs without a primary handler are always request
with IRQF_ONESHOT
Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NYang Li <yang.lee@linux.alibaba.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

1a03b2c8

cpufreq: blacklist Arm Vexpress platforms in cpufreq-dt-platdev · 15d32abb

由 Sudeep Holla 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 9443aef16fca8071032e702e1386d5c40a4a0832
bugzilla: 51493

--------------------------------

[ Upstream commit fbb31cb8 ]

Add "arm,vexpress" to cpufreq-dt-platdev blacklist since the actual
scaling is handled by the firmware cpufreq drivers(scpi, scmi and
vexpress-spc).
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

15d32abb

gfs2: fix use-after-free in trans_drain · 4dd57608

由 Bob Peterson 提交于 4月 07, 2021

stable inclusion
from stable-5.10.27
commit 6d7dce3bdfc4d38d64212f458c6778dcd2bead00
bugzilla: 51493

--------------------------------

[ Upstream commit 1a5a2cfd ]

This patch adds code to function trans_drain to remove drained
bd elements from the ail lists, if queued, before freeing the bd.
If we don't remove the bd from the ail, function ail_drain will
try to reference the bd after it has been freed by trans_drain.

Thanks to Andy Price for his analysis of the problem.
Reported-by: NAndy Price <anprice@redhat.com>
Signed-off-by: NBob Peterson <rpeterso@redhat.com>
Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4dd57608

openeuler / Kernel 接近 2 年 前同步成功

openeuler / Kernel
接近 2 年前同步成功