提交 · 5.10.0-4.20.0 · openeuler / Kernel

23 4月, 2021 8 次提交

bpf: Fix truncation handling for mod32 dst reg wrt zero · ae334bc7

由 Daniel Borkmann 提交于 3月 09, 2021

stable inclusion
from stable-5.10.19
commit 3320bae8c115863b6f17993c2b7970f7f419da57
bugzilla: 50607
CVE: CVE-2021-3444

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

commit 9b00f1b7 upstream.

Recently noticed that when mod32 with a known src reg of 0 is performed,
then the dst register is 32-bit truncated in verifier:

  0: R1=ctx(id=0,off=0,imm=0) R10=fp0
  0: (b7) r0 = 0
  1: R0_w=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0
  1: (b7) r1 = -1
  2: R0_w=inv0 R1_w=inv-1 R10=fp0
  2: (b4) w2 = -1
  3: R0_w=inv0 R1_w=inv-1 R2_w=inv4294967295 R10=fp0
  3: (9c) w1 %= w0
  4: R0_w=inv0 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0
  4: (b7) r0 = 1
  5: R0_w=inv1 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0
  5: (1d) if r1 == r2 goto pc+1
   R0_w=inv1 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0
  6: R0_w=inv1 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0
  6: (b7) r0 = 2
  7: R0_w=inv2 R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2_w=inv4294967295 R10=fp0
  7: (95) exit
  7: R0=inv1 R1=inv(id=0,umin_value=4294967295,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R2=inv4294967295 R10=fp0
  7: (95) exit

However, as a runtime result, we get 2 instead of 1, meaning the dst
register does not contain (u32)-1 in this case. The reason is fairly
straight forward given the 0 test leaves the dst register as-is:

  # ./bpftool p d x i 23
   0: (b7) r0 = 0
   1: (b7) r1 = -1
   2: (b4) w2 = -1
   3: (16) if w0 == 0x0 goto pc+1
   4: (9c) w1 %= w0
   5: (b7) r0 = 1
   6: (1d) if r1 == r2 goto pc+1
   7: (b7) r0 = 2
   8: (95) exit

This was originally not an issue given the dst register was marked as
completely unknown (aka 64 bit unknown). However, after 468f6eaf
("bpf: fix 32-bit ALU op verification") the verifier casts the register
output to 32 bit, and hence it becomes 32 bit unknown. Note that for
the case where the src register is unknown, the dst register is marked
64 bit unknown. After the fix, the register is truncated by the runtime
and the test passes:

  # ./bpftool p d x i 23
   0: (b7) r0 = 0
   1: (b7) r1 = -1
   2: (b4) w2 = -1
   3: (16) if w0 == 0x0 goto pc+2
   4: (9c) w1 %= w0
   5: (05) goto pc+1
   6: (bc) w1 = w1
   7: (b7) r0 = 1
   8: (1d) if r1 == r2 goto pc+1
   9: (b7) r0 = 2
  10: (95) exit

Semantics also match with {R,W}x mod{64,32} 0 -> {R,W}x. Invalid div
has always been {R,W}x div{64,32} 0 -> 0. Rewrites are as follows:

  mod32:                            mod64:

  (16) if w0 == 0x0 goto pc+2       (15) if r0 == 0x0 goto pc+1
  (9c) w1 %= w0                     (9f) r1 %= r0
  (05) goto pc+1
  (bc) w1 = w1

Fixes: 468f6eaf ("bpf: fix 32-bit ALU op verification")
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Reviewed-by: NJohn Fastabend <john.fastabend@gmail.com>
Acked-by: NAlexei Starovoitov <ast@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>

ae334bc7

vhost-vdpa: fix use-after-free of v->config_ctx · 49171f2b

由 Stefano Garzarella 提交于 3月 31, 2021

stable inclusion
from stable-5.10.26
commit 49ca3100fbaf864853c922c8f7a8fe7090a83860
bugzilla: 51363
CVE: CVE-2021-29266

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

commit f6bbf001 upstream.

When the 'v->config_ctx' eventfd_ctx reference is released we didn't
set it to NULL. So if the same character device (e.g. /dev/vhost-vdpa-0)
is re-opened, the 'v->config_ctx' is invalid and calling again
vhost_vdpa_config_put() causes use-after-free issues like the
following refcount_t underflow:

    refcount_t: underflow; use-after-free.
    WARNING: CPU: 2 PID: 872 at lib/refcount.c:28 refcount_warn_saturate+0xae/0xf0
    RIP: 0010:refcount_warn_saturate+0xae/0xf0
    Call Trace:
     eventfd_ctx_put+0x5b/0x70
     vhost_vdpa_release+0xcd/0x150 [vhost_vdpa]
     __fput+0x8e/0x240
     ____fput+0xe/0x10
     task_work_run+0x66/0xa0
     exit_to_user_mode_prepare+0x118/0x120
     syscall_exit_to_user_mode+0x21/0x50
     ? __x64_sys_close+0x12/0x40
     do_syscall_64+0x45/0x50
     entry_SYSCALL_64_after_hwframe+0x44/0xae

Fixes: 776f3950 ("vhost_vdpa: Support config interrupt in vdpa")
Cc: lingshan.zhu@intel.com
Cc: stable@vger.kernel.org
Signed-off-by: NStefano Garzarella <sgarzare@redhat.com>
Link: https://lore.kernel.org/r/20210311135257.109460-2-sgarzare@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NZhu Lingshan <lingshan.zhu@intel.com>
Acked-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.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>

49171f2b

bpf, x86: Validate computation of branch displacements for x86-32 · 248a2e96

由 Piotr Krysiuk 提交于 4月 20, 2021

stable inclusion
from stable-5.10.29
commit faa30969f66e74910e9424214a4a426c2dc249d8
bugzilla: 51789
CVE: CVE-2021-29154

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

commit 26f55a59 upstream.

The branch displacement logic in the BPF JIT compilers for x86 assumes
that, for any generated branch instruction, the distance cannot
increase between optimization passes.

But this assumption can be violated due to how the distances are
computed. Specifically, whenever a backward branch is processed in
do_jit(), the distance is computed by subtracting the positions in the
machine code from different optimization passes. This is because part
of addrs[] is already updated for the current optimization pass, before
the branch instruction is visited.

And so the optimizer can expand blocks of machine code in some cases.

This can confuse the optimizer logic, where it assumes that a fixed
point has been reached for all machine code blocks once the total
program size stops changing. And then the JIT compiler can output
abnormal machine code containing incorrect branch displacements.

To mitigate this issue, we assert that a fixed point is reached while
populating the output image. This rejects any problematic programs.
The issue affects both x86-32 and x86-64. We mitigate separately to
ease backporting.
Signed-off-by: NPiotr Krysiuk <piotras@gmail.com>
Reviewed-by: NDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.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>

248a2e96

bpf, x86: Validate computation of branch displacements for x86-64 · e32f0551

由 Piotr Krysiuk 提交于 4月 20, 2021

stable inclusion
from stable-5.10.29
commit 3edb8967d91ecbc4c5eee34a65d4124267327574
bugzilla: 51789
CVE: CVE-2021-29154

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

commit e4d4d456 upstream.

The branch displacement logic in the BPF JIT compilers for x86 assumes
that, for any generated branch instruction, the distance cannot
increase between optimization passes.

But this assumption can be violated due to how the distances are
computed. Specifically, whenever a backward branch is processed in
do_jit(), the distance is computed by subtracting the positions in the
machine code from different optimization passes. This is because part
of addrs[] is already updated for the current optimization pass, before
the branch instruction is visited.

And so the optimizer can expand blocks of machine code in some cases.

This can confuse the optimizer logic, where it assumes that a fixed
point has been reached for all machine code blocks once the total
program size stops changing. And then the JIT compiler can output
abnormal machine code containing incorrect branch displacements.

To mitigate this issue, we assert that a fixed point is reached while
populating the output image. This rejects any problematic programs.
The issue affects both x86-32 and x86-64. We mitigate separately to
ease backporting.
Signed-off-by: NPiotr Krysiuk <piotras@gmail.com>
Reviewed-by: NDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.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>

e32f0551

PCI: rpadlpar: Fix potential drc_name corruption in store functions · cb1154bf

由 Tyrel Datwyler 提交于 3月 31, 2021

stable inclusion
from stable-5.10.26
commit be1f58e58f7644ab33f1413685c84173766408d3
bugzilla: 51363
CVE: CVE-2021-28972

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

commit cc7a0bb0 upstream.

Both add_slot_store() and remove_slot_store() try to fix up the
drc_name copied from the store buffer by placing a NUL terminator at
nbyte + 1 or in place of a '\n' if present. However, the static buffer
that we copy the drc_name data into is not zeroed and can contain
anything past the n-th byte.

This is problematic if a '\n' byte appears in that buffer after nbytes
and the string copied into the store buffer was not NUL terminated to
start with as the strchr() search for a '\n' byte will mark this
incorrectly as the end of the drc_name string resulting in a drc_name
string that contains garbage data after the n-th byte.

Additionally it will cause us to overwrite that '\n' byte on the stack
with NUL, potentially corrupting data on the stack.

The following debugging shows an example of the drmgr utility writing
"PHB 4543" to the add_slot sysfs attribute, but add_slot_store()
logging a corrupted string value.

  drmgr: drmgr: -c phb -a -s PHB 4543 -d 1
  add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19

Fix this by using strscpy() instead of memcpy() to ensure the string
is NUL terminated when copied into the static drc_name buffer.
Further, since the string is now NUL terminated the code only needs to
change '\n' to '\0' when present.

Cc: stable@vger.kernel.org
Signed-off-by: NTyrel Datwyler <tyreld@linux.ibm.com>
[mpe: Reformat change log and add mention of possible stack corruption]
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210315214821.452959-1-tyreld@linux.ibm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.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>

cb1154bf

ASoC: qcom: sdm845: Fix array out of bounds access · d6cee437

由 Srinivas Kandagatla 提交于 3月 31, 2021

stable inclusion
from stable-5.10.26
commit 26b08c08a5f3008fe45822d8b163f1516178c42b
bugzilla: 51363
CVE: CVE-2021-28952

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

commit 1c668e1c upstream.

Static analysis Coverity had detected a potential array out-of-bounds
write issue due to the fact that MAX AFE port Id was set to 16 instead
of using AFE_PORT_MAX macro.

Fix this by properly using AFE_PORT_MAX macro.

Fixes: 1b93a884 ("ASoC: qcom: sdm845: handle soundwire stream")
Reported-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210309142129.14182-2-srinivas.kandagatla@linaro.orgSigned-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: N  Weilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d6cee437

staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan() · 262283db

由 Dan Carpenter 提交于 3月 27, 2021

stable inclusion
from stable-5.10.24
commit d972a516958dee489911d9f57ee7a177834ef248
bugzilla: 51348
CVE: CVE-2021-28660

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

commit 74b6b20d upstream.

This code has a check to prevent read overflow but it needs another
check to prevent writing beyond the end of the ->ssid[] array.

Fixes: a2c60d42 ("staging: r8188eu: Add files for new driver - part 16")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/YEHymwsnHewzoam7@mwandaSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.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>

262283db

misc: fastrpc: restrict user apps from sending kernel RPC messages · 10555bb8

由 Dmitry Baryshkov 提交于 3月 27, 2021

stable inclusion
from stable-5.10.24
commit 52feb58f9b5b078b5a39ed8ba8ab3b4546e16ff2
bugzilla: 51348
CVE: CVE-2021-28375

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

commit 20c40794 upstream.

Verify that user applications are not using the kernel RPC message
handle to restrict them from directly attaching to guest OS on the
remote subsystem. This is a port of CVE-2019-2308 fix.

Fixes: c68cfb71 ("misc: fastrpc: Add support for context Invoke method")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Jonathan Marek <jonathan@marek.ca>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210212192658.3476137-1-dmitry.baryshkov@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.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>

10555bb8

19 4月, 2021 2 次提交

kvm: debugfs: add EXIT_REASON_PREEMPTION_TIMER to vcpu_stat · d0ef7980

由 chenjiajun 提交于 4月 07, 2021

virt inclusion
category: feature
bugzilla: 46853
CVE: NA

Export EXIT_REASON_PREEMPTION_TIMER kvm exits to vcpu_stat debugfs.
Add a new column to vcpu_stat, and provide preemption_timer status to
virtualization detection tools.
Signed-off-by: Nchenjiajun <chenjiajun8@huawei.com>
Reviewed-by: NXiangyou Xie <xiexiangyou@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d0ef7980

kvm: debugfs: add fastpath msr_wr exits to debugfs statistics · 8e61276a

由 chenjiajun 提交于 4月 07, 2021

virt inclusion
category: feature
bugzilla: 46853
CVE: NA

At present, there is a flaw in the statistics of KVM exits by debugfs,
which only counts trigger times of exits processing function in kvm_vmx_exit_handlers.
The kvm exits handles in vmx_exit_handlers_fastpath is omitted, so there is a large numerical error
in EXIT_REASON_MSR_WRITE statistics sometimes.
Signed-off-by: Nchenjiajun <chenjiajun8@huawei.com>
Reviewed-by: NXiangyou Xie <xiexiangyou@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8e61276a

16 4月, 2021 1 次提交

arm64: amend config position of park and pmem · 5478e9e3

由 Sang Yan 提交于 3月 24, 2021

hulk inclusion
category: feature
bugzilla: 48159
CVE: N/A

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

Move config of ARM64_CPU_PARK into menu "Kernel features"
and beside CRASH_DUMP.

Move config of ARM64_PMEM_RESERVE ARM64_PMEM_LEGACY_DEVICE
into menu "Kernel features".

Signed-off-by: Sang Yan <sangyan(a)huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5478e9e3

08 4月, 2021 1 次提交

arm64/mpam: fix a possible deadlock in mpam_enable · 875918c3

由 A4D 提交于 3月 25, 2021

hulk inclusion
category: bugfix
bugzilla: 51497
CVE: NA
Reference: https://gitee.com/openeuler/kernel/issues/I3D58V

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

No unlock operation is performed on the mpam_devices_lock
before the return statement, which may lead to a deadlock.

Signed-off-by: Zhang Ming <154842638(a)qq.com>
Reported-by: Jian Cheng <cj.chengjian(a)huawei.com>
Suggested-by: Jian Cheng <cj.chengjian(a)huawei.com>
Reviewed-by: Wang ShaoBo<bobo.shaobowang(a)huawei.com>
Reviewed-by: Xie XiuQi <xiexiuqi(a)huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

875918c3

27 3月, 2021 1 次提交

arm64: mm: fixes reserve_crashkernel twice by mistake · 1e52616c

由 Zheng Zengkai 提交于 3月 27, 2021

hulk inclusion
category: bugfix
bugzilla: 50423
CVE: NA

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

reserve_crashkernel() is called twice by mistake, remove the second one.

Fixes: beb42167 ("arm64: mm: Move reserve_crashkernel() into mem_init()")
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>

1e52616c

24 3月, 2021 2 次提交

scsi: megaraid_sas: Replace undefined MFI_BIG_ENDIAN macro with __BIG_ENDIAN_BITFIELD macro · d6674553

由 Shivasharan S 提交于 5月 08, 2020

mainline inclusion
from mainline-5.8-rc1
commit b9d5e3e7
category: feature
bugzilla: 50800
CVE: NA

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

MFI_BIG_ENDIAN macro used in drivers structure bitfield to check the CPU
big endianness is undefined which would break the code on big endian
machine. __BIG_ENDIAN_BITFIELD kernel macro should be used in places of
MFI_BIG_ENDIAN macro.

Link: https://lore.kernel.org/r/20200508085130.23339-1-chandrakanth.patil@broadcom.com
Fixes: a7faf81d ("scsi: megaraid_sas: Set no_write_same only for Virtual Disk")
Cc: <stable@vger.kernel.org> # v5.6+
Signed-off-by: NShivasharan S <shivasharan.srikanteshwara@broadcom.com>
Signed-off-by: NChandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d6674553

scsi: megaraid_sas: Set no_write_same only for Virtual Disk · 8e2a931d

由 Anand Lodnoor 提交于 1月 14, 2020

mainline inclusion
from mainline-5.6-rc1
commit a7faf81d
category: feature
bugzilla: 50800
CVE: NA

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

Disable WRITE_SAME (no_write_same) for Virtual Disks only.  For System PDs
and EPDs (Enhanced PDs), WRITE_SAME need not be disabled by default.

Link: https://lore.kernel.org/r/1579000882-20246-3-git-send-email-anand.lodnoor@broadcom.comSigned-off-by: NAnand Lodnoor <anand.lodnoor@broadcom.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8e2a931d

20 3月, 2021 2 次提交

Revert "scsi: megaraid_sas: Set no_write_same only for Virtual Disk" · 9d2d1b27

由 Yufen Yu 提交于 3月 20, 2021

This reverts commit a7faf81d.
Signed-off-by: NYufen Yu <yuyufen@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

9d2d1b27

Revert "scsi: megaraid_sas: Replace undefined MFI_BIG_ENDIAN macro with... · f71eee8a

由 Yufen Yu 提交于 3月 20, 2021

Revert "scsi: megaraid_sas: Replace undefined MFI_BIG_ENDIAN macro with __BIG_ENDIAN_BITFIELD macro"

This reverts commit b9d5e3e7.

After commit a7faf81d ("scsi: megaraid_sas: Set no_write_same only
for Virtual Disk"), write_same is support default for some devices.
But we found write zero IO is very slow. So, revert it.
Signed-off-by: NYufen Yu <yuyufen@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f71eee8a

19 3月, 2021 4 次提交

RDMA/hns: Optimize the base address table config for MTR · f8a28dd2

由 Xi Wang 提交于 3月 19, 2021

driver inclusion
category: bugfix
bugzilla: 50786

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

The base address table is allocated by dma allocator, and the size is
always aligned to PAGE_SIZE. If use the fixed size to allocated the table,
the base address entries which stored in table will be smaller than the
actual memory space can store.
Signed-off-by: NXi Wang <wangxi11@huawei.com>
Reviewed-by: NWeihang Li <liweihang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f8a28dd2

fbdev: keep the original function for non-RPi · aa03ec3a

由 Zheng Zengkai 提交于 3月 19, 2021

raspberrypi inclusion
category: feature
bugzilla: 50432

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

This patch adjusts following fbdev related patches for
raspberry pi on non-Raspberry Pi platforms, using specific
config CONFIG_OPENEULER_RASPBERRYPI to distinguish them:

29df1382f6 Speed up console framebuffer imageblit function
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>

aa03ec3a

Speed up console framebuffer imageblit function · 0301415f

由 Harm Hanemaaijer 提交于 6月 20, 2013

raspberrypi inclusion
category: feature
bugzilla: 50432

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

Especially on platforms with a slower CPU but a relatively high
framebuffer fill bandwidth, like current ARM devices, the existing
console monochrome imageblit function used to draw console text is
suboptimal for common pixel depths such as 16bpp and 32bpp. The existing
code is quite general and can deal with several pixel depths. By creating
special case functions for 16bpp and 32bpp, by far the most common pixel
formats used on modern systems, a significant speed-up is attained
which can be readily felt on ARM-based devices like the Raspberry Pi
and the Allwinner platform, but should help any platform using the
fb layer.

The special case functions allow constant folding, eliminating a number
of instructions including divide operations, and allow the use of an
unrolled loop, eliminating instructions with a variable shift size,
reducing source memory access instructions, and eliminating excessive
branching. These unrolled loops also allow much better code optimization
by the C compiler. The code that selects which optimized variant is used
is also simplified, eliminating integer divide instructions.

The speed-up, measured by timing 'cat file.txt' in the console, varies
between 40% and 70%, when testing on the Raspberry Pi and Allwinner
ARM-based platforms, depending on font size and the pixel depth, with
the greater benefit for 32bpp.
Signed-off-by: NHarm Hanemaaijer <fgenfb@yahoo.com>
Signed-off-by: NFang Yafen <yafen@iscas.ac.cn>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0301415f

Revert "Speed up console framebuffer imageblit function" · 9c9b5638

由 Zheng Zengkai 提交于 3月 19, 2021

raspberrypi inclusion
category: feature
bugzilla: 50432

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

This reverts commit 31ac52b8.

The patch being reverted may lead to long stress test failure,
revert it temporarily.
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

9c9b5638

18 3月, 2021 12 次提交

arm64/mpam: fix a memleak in add_schema · f1dd9375

由 Zhang Ming 提交于 3月 17, 2021

openEuler inclusion
category: bugfix
bugzilla: 48265
CVE: NA
Reference: https://gitee.com/openeuler/kernel/issues/I3BPPX

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

The default branch in switch will not run at present,
but there may be related extensions in the future,
which may lead to memory leakage.

Signed-off-by: Zhang Ming <154842638(a)qq.com>
Reported-by: Wang ShaoBo <bobo.shaobowang(a)huawei.com>
Suggested-by: Jian Cheng <cj.chengjian(a)huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
[Zheng Zengkai: adjust commit message]
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f1dd9375

fs: fix files.usage bug when move tasks · 0a960e73

由 Lu Jialin 提交于 3月 17, 2021

hulk inclusion
category: bugfix
bugzilla: 50779
CVE: NA

--------

If parent cgroup files.limit is 0, fail to move a task into child
cgroup. When kill the task, the files.usage of parent cgroup and child
cgroup is abnormal.

/sys/fs/cgroup/parent # ls
cgroup.clone_children  files.limit            tasks
cgroup.procs           files.usage
child                  notify_on_release
/sys/fs/cgroup/parent # echo 0 >files.limit
/sys/fs/cgroup/parent # cd child
/sys/fs/cgroup/parent/child # ls
cgroup.clone_children  files.limit            notify_on_release
cgroup.procs           files.usage            tasks
/sys/fs/cgroup/parent/child # echo 156 >tasks
[  879.564728] Open files limit overcommited
/sys/fs/cgroup/parent/child # kill -9 156
/sys/fs/cgroup/parent/child # [  886.363690] WARNING: CPU: 0 PID: 156 at mm/page_counter.c:62 page_counter_cancel+0x26/0x30
[  886.364093] Modules linked in:
[  886.364093] CPU: 0 PID: 156 Comm: top Not tainted 4.18.0+ #1
[  886.364093] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[  886.365350] RIP: 0010:page_counter_cancel+0x26/0x30
[  886.365350] Code: 0f 1f 40 00 66 66 66 66 90 48 89 f0 53 48 f7 d8 f0 48 0f c1 07 48 29 f0 48 89 c3 48 89 c6 e8 61 ff ff ff 48 85 d5
[  886.365350] RSP: 0018:ffffb754006b7d00 EFLAGS: 00000286
[  886.365350] RAX: 0000000000000000 RBX: ffffffffffffffff RCX: 0000000000000001
[  886.365350] RDX: 0000000000000000 RSI: ffffffffffffffff RDI: ffff9ca61888b930
[  886.365350] RBP: 0000000000000001 R08: 00000000000295c0 R09: ffffffff820597aa
[  886.365350] R10: ffffffffffffffff R11: ffffd78601823508 R12: 0000000000000000
[  886.365350] R13: ffff9ca6181c0628 R14: 0000000000000000 R15: ffff9ca663e9d000
[  886.365350] FS:  0000000000000000(0000) GS:ffff9ca661e00000(0000) knlGS:0000000000000000
[  886.365350] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  886.365350] CR2: 0000000000867fb8 CR3: 0000000017a0a000 CR4: 00000000000006f0
[  886.365350] Call Trace:
[  886.369392]  page_counter_uncharge+0x1d/0x30
[  886.369392]  put_files_struct+0x7c/0xe0
[  886.369392]  do_exit+0x2c7/0xb90
[  886.369392]  ? __schedule+0x2a1/0x900
[  886.369392]  do_group_exit+0x3a/0xa0
[  886.369392]  get_signal+0x15e/0x870
[  886.369392]  do_signal+0x36/0x610
[  886.369392]  ? do_vfs_ioctl+0xa4/0x640
[  886.369392]  ? do_vfs_ioctl+0xa4/0x640
[  886.369392]  ? dput+0x29/0x110
[  886.369392]  exit_to_usermode_loop+0x71/0xe0
[  886.369392]  do_syscall_64+0x181/0x1b0
[  886.369392]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[  886.369392] RIP: 0033:0x4b9b5a
[  886.369392] Code: Bad RIP value.
[  886.369392] RSP: 002b:00007ffe27221968 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[  886.373373] RAX: fffffffffffffe00 RBX: 0000000000000001 RCX: 00000000004b9b5a
[  886.373373] RDX: 00007ffe27221930 RSI: 0000000000005402 RDI: 0000000000000000
[  886.373373] RBP: 0000000000000135 R08: 00007ffe272219a4 R09: 0000000000000010
[  886.373373] R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
[  886.373373] R13: 0000000000000005 R14: 0000000000000135 R15: 0000000000000000
[  886.373373] ---[ end trace 56c4971a753a98c5 ]---

[1]+  Killed                     top
/sys/fs/cgroup/parent/child # ls
cgroup.clone_children  files.limit            notify_on_release
cgroup.procs           files.usage            tasks
/sys/fs/cgroup/parent/child # cat files.usage
18446744073709551613
/sys/fs/cgroup/parent/child # cd ..
/sys/fs/cgroup/parent # ls
cgroup.clone_children  files.limit            tasks
cgroup.procs           files.usage
child                  notify_on_release
/sys/fs/cgroup/parent # cat files.usage
18446744073709551613

The reason is when fail to move a task into child cgroup,the files.usage
of child cgroup and its parent cgroup are the same as before. The struct
files_cgroup points to the dst_css. Therefore, when kill the task, the
page_counter_uncharge() will subtract the files.usage of child cgroup and
its parent cgroup again. The files.usage will be abnormal.

If we just change the struct files_cgroup pointers when charge success in
files_cgroup_attach, problems will occur in some extreme scenario.
1)If we add num_files into original page_counter when fail to charge the
file resource into new cgroup, the files.usage will be larger than
files.limit of the original cgroup when new task moves into the original
cgroup at the same time.
2)If we subtract num_files into original page_counter when success to
charge the file resource into new cgroup, when the parent files.limit
equals to the files.usage and there are two child cgroups of the parent,
it will be failed to move the task from one child cgroup into another
child cgroup.

The patch implements files_cgroup_attach() into files_cgroup_can_attach()
and delete files_cgroup_attach(). This will make move file related resource
into new cgroup before move task. When try_charge is failed, task and its
file resource will be in the original cgroup.The above problems will be
solved.
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0a960e73

files_cgroup: fix error pointer when kvm_vm_worker_thread · b27ad130

由 Zhang Xiaoxu 提交于 3月 17, 2021

hulk inclusion
category: bugfix
bugzilla: 50779
CVE: NA

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

When fix CVE-2018-12207, the kvm_vm_worker_thread will attach all
cgroup subsystem. But the files cgroup doesn't support kernel thread.

Because the init_files doesn't init the files cgroup, when kernel thread
'kvm_vm_worker_thread' attach the files cgroup, the files_cgroup
get from 'init_files' is an error pointer. It lead the kernel panic
as below:
  [  724.842302]  page_counter_uncharge+0x1d/0x30
  [  724.842431]  files_cgroup_attach+0x7c/0x130
  [  724.842564]  ? css_set_move_task+0x12e/0x230
  [  724.842694]  cgroup_migrate_execute+0x2f9/0x3b0
  [  724.842833]  cgroup_attach_task+0x156/0x200
  [  724.843010]  ? kvm_mmu_pte_write+0x490/0x490 [kvm]
  [  724.843153]  cgroup_attach_task_all+0x81/0xd0
  [  724.843289]  ? __schedule+0x294/0x910
  [  724.843419]  kvm_vm_worker_thread+0x4a/0xc0 [kvm]
  [  724.843579]  ? kvm_exit+0x80/0x80 [kvm]
  [  724.843690]  kthread+0x112/0x130
  [  724.843792]  ?kthread_create_worker_on_cpu+0x70/0x70
  [  724.843948]  ret_from_fork+0x35/0x40

So, we add some check, if the task is kernel thread (files is
'init_files'), we doesn't do the more operation about the
files cgroup.

Fixes: baa10bc24e1e ("kvm: Add helper function for creating VM ...")
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b27ad130

fs/filescontrol: add a switch to enable / disable accounting of open fds · bf8f0cc2

由 Yu Kuai 提交于 3月 17, 2021

hulk inclusion
category: bugfix
bugzilla: 50779
CVE: NA

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

Such switch can only set the accounting of open fds in filescontrol from
enable to disable. If it is disabled arealdy, the switch can't enable it.

The counter is enabled by default, and it can be disabled by:
a. echo 1 > /sys/fs/cgroup/files/files.no_acct
b. add "filescontrol.no_acct=1" to boot cmd
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

bf8f0cc2

cgroup/files: use task_get_css() to get a valid css during dup_fd() · c15452ba

由 Hou Tao 提交于 3月 17, 2021

hulk inclusion
category: bugfix
bugzilla: 50779
CVE: NA

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

Process fork and cgroup migration can happen simultaneously, and
in the following case use-after-free of css_set is possible:

CPU 0: process fork    CPU 1: cgroup migration

dup_fd                 __cgroup1_procs_write(threadgroup=false)
  files_cgroup_assign
    // task A
    task_lock
    task_cgroup(current, files_cgrp_id)
      css_set = task_css_set_check()

 			 cgroup_migrate_execute
  			   files_cgroup_can_attach
			   css_set_move_task
			     put_css_set_locked()
  			   files_cgroup_attach
			     // task B which is in the same
			     // thread group as task A
			     task_lock
			 cgroup_migrate_finish
			   // the css_set will be freed
			   put_css_set_locked()

      // use-after-free
      css_set->subsys[files_cgrp_id]

Fix it by using task_get_css() instead to get a valid css.

Fixes: 52cc1eccf6de ("cgroups: Resource controller for open files")
Signed-off-by: NHou Tao <houtao1@huawei.com>
Reviewed-by: Nluojiajun <luojiajun3@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c15452ba

cgroups: Resource controller for open files · 9331053c

由 Binder Makin 提交于 3月 17, 2021

hulk inclusion
category: feature/cgroups
bugzilla: 50779
CVE: NA

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

Add a lockless resource controller for limiting the number of open
file handles.  This allows us to catch misbehaving processes
and return EMFILE instead of ENOMEM for kernel memory limits.

Original link: https://lwn.net/Articles/604129/.After introduced
https://gitlab.indel.ch/thirdparty/linux-indel/commit
/5b1efc02.
All memory accounting and limiting has been switched over to the
lockless page counters. So we convert original resource counters to
lockless page counters.
Signed-off-by: NBinder Makin <merimus@google.com>
Reviewed-by: NQiang Huang <h.huangqiang@huawei.com>
[cm: convert to lockless page counters]
Signed-off-by: Nluojiajun <luojiajun3@huawei.com>

v1->v2
fix some code
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

9331053c

openeuler_defconfig: enable CONFIG_CGROUP_FILES by default · 8b9cff8c

由 Lu Jialin 提交于 3月 17, 2021

hulk inclusion
category: feature/cgroups
bugzilla: 50779
CVE: NA

--------

enable CONFIG_CGROUP_FILES by default on x86 and arm64
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8b9cff8c

ima: fix a memory leak in ima_del_digest_data_entry · 860623b0

由 Zhang Tianxing 提交于 3月 18, 2021

hulk inclusion
category: bugfix
bugzilla: 46797
CVE: NA
Reference: https://gitee.com/openeuler/kernel/issues/I3C03N

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

This patch fix a memory leak problem when deleting digest list.

hlist_del_rcu in ima_del_digest_data_entry only deletes the digest
struct from the linked list without releasing the memory it uses.
Signed-off-by: NZhang Tianxing <zhangtianxing3@huawei.com>
Reviewed-by: NRoberto Sassu <roberto.sassu@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

860623b0

x86: config: disable CONFIG_BOOTPARAM_HOTPLUG_CPU0 by default · f2c5a15f

由 Zheng Zengkai 提交于 3月 18, 2021

hulk inclusion
category: config
bugzilla: 50784
CVE: NA

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

Disable CONFIG_BOOTPARAM_HOTPLUG_CPU0 for x86 openeuler_defconfig
by default.
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>

f2c5a15f

scsi: iscsi: Verify lengths on passthrough PDUs · 4a5a96d7

由 Chris Leech 提交于 2月 23, 2021

stable inclusion
from stable-5.10.21
commit f40bbcb68131f1c17ed22a1e8a471776b4e57bd3
bugzilla: 50783
CVE: CVE-2021-27365

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

commit f9dbdf97 upstream.

Open-iSCSI sends passthrough PDUs over netlink, but the kernel should be
verifying that the provided PDU header and data lengths fall within the
netlink message to prevent accessing beyond that in memory.

Cc: stable@vger.kernel.org
Reported-by: NAdam Nichols <adam@grimm-co.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Reviewed-by: NMike Christie <michael.christie@oracle.com>
Signed-off-by: NChris Leech <cleech@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4a5a96d7

scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE · 340ec940

由 Chris Leech 提交于 2月 23, 2021

stable inclusion
from stable-5.10.21
commit 76d92bf293c36a52ea5552919ac645ef2edee55d
bugzilla: 50783
CVE: CVE-2021-27365

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

commit ec98ea70 upstream.

As the iSCSI parameters are exported back through sysfs, it should be
enforcing that they never are more than PAGE_SIZE (which should be more
than enough) before accepting updates through netlink.

Change all iSCSI sysfs attributes to use sysfs_emit().

Cc: stable@vger.kernel.org
Reported-by: NAdam Nichols <adam@grimm-co.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NMike Christie <michael.christie@oracle.com>
Signed-off-by: NChris Leech <cleech@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

340ec940

scsi: iscsi: Restrict sessions and handles to admin capabilities · 5b7d3bf9

由 Lee Duncan 提交于 2月 23, 2021

stable inclusion
from stable-5.10.21
commit c71edc5d2480774ec2fec62bb84064aed6d582bd
bugzilla: 50783
CVE: CVE-2021-27363/CVE-2021-27364

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

commit 688e8128 upstream.

Protect the iSCSI transport handle, available in sysfs, by requiring
CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
reception of messages to ones sent with CAP_SYS_ADMIN. This disables
normal users from being able to end arbitrary iSCSI sessions.

Cc: stable@vger.kernel.org
Reported-by: NAdam Nichols <adam@grimm-co.com>
Reviewed-by: NChris Leech <cleech@redhat.com>
Reviewed-by: NMike Christie <michael.christie@oracle.com>
Signed-off-by: NLee Duncan <lduncan@suse.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5b7d3bf9

17 3月, 2021 7 次提交

of: unittest: Fix build on architectures without CONFIG_OF_ADDRESS · 1adebbd3

由 Catalin Marinas 提交于 3月 16, 2021

mainline inclusion
from mainline-5.11-rc1
commit aed5041e
category: bugfix
bugzilla: 50423
CVE: NA

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

of_dma_get_max_cpu_address() is not defined if !CONFIG_OF_ADDRESS, so
return early in of_unittest_dma_get_max_cpu_address().

Fixes: 07d13a1d ("of: unittest: Add test for of_dma_get_max_cpu_address()")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Reviewed-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

1adebbd3

mm: Remove examples from enum zone_type comment · ce259e55

由 Nicolas Saenz Julienne 提交于 3月 16, 2021

mainline inclusion
from mainline-5.11-rc1
commit 04435217
category: bugfix
bugzilla: 50423
CVE: NA

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

We can't really list every setup in common code. On top of that they are
unlikely to stay true for long as things change in the arch trees
independently of this comment.
Suggested-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20201119175400.9995-8-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Reviewed-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ce259e55

arm64: mm: Set ZONE_DMA size based on early IORT scan · e196efb0

由 Ard Biesheuvel 提交于 3月 16, 2021

mainline inclusion
from mainline-5.11-rc1
commit 2b865293
category: bugfix
bugzilla: 50423
CVE: NA

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

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

Instructing the DMA layer about these limitations is straight-forward,
even though we had to fix some issues regarding memory limits set in
the IORT for named components, and regarding the handling of ACPI _DMA
methods. However, the DMA layer also needs to be able to allocate
memory that is guaranteed to meet those DMA constraints, for bounce
buffering as well as allocating the backing for consistent mappings.

This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately,
it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes
problems with kdump, and potentially in other places where allocations
cannot cross zone boundaries. Therefore, we should avoid having two
separate DMA zones when possible.

So let's do an early scan of the IORT, and only create the ZONE_DMA
if we encounter any devices that need it. This puts the burden on
the firmware to describe such limitations in the IORT, which may be
redundant (and less precise) if _DMA methods are also being provided.
However, it should be noted that this situation is highly unusual for
arm64 ACPI machines. Also, the DMA subsystem still gives precedence to
the _DMA method if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.

[nsaenz: unified implementation with DT's counterpart]
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: NJeremy Linton <jeremy.linton@arm.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: NHanjun Guo <guohanjun@huawei.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20201119175400.9995-7-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Reviewed-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

e196efb0

arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges · a06deaa7

由 Nicolas Saenz Julienne 提交于 3月 16, 2021

mainline inclusion
from mainline-5.11-rc1
commit 8424ecdd
category: bugfix
bugzilla: 50423
CVE: NA

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

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

The DMA layer also needs to be able to allocate memory that is
guaranteed to meet those DMA constraints, for bounce buffering as well
as allocating the backing for consistent mappings. This is why the 1 GB
ZONE_DMA was introduced recently. Unfortunately, it turns out the having
a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes problems with kdump, and
potentially in other places where allocations cannot cross zone
boundaries. Therefore, we should avoid having two separate DMA zones
when possible.

So, with the help of of_dma_get_max_cpu_address() get the topmost
physical address accessible to all DMA masters in system and use that
information to fine-tune ZONE_DMA's size. In the absence of addressing
limited masters ZONE_DMA will span the whole 32-bit address space,
otherwise, in the case of the Raspberry Pi 4 it'll only span the 30-bit
address space, and have ZONE_DMA32 cover the rest of the 32-bit address
space.
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/20201119175400.9995-6-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Reviewed-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a06deaa7

of: unittest: Add test for of_dma_get_max_cpu_address() · b7795756

由 Nicolas Saenz Julienne 提交于 3月 16, 2021

mainline inclusion
from mainline-5.11-rc1
commit 07d13a1d
category: bugfix
bugzilla: 50423
CVE: NA

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

Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
data as the rest of dma-ranges unit tests.
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201119175400.9995-5-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Reviewed-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b7795756

of/address: Introduce of_dma_get_max_cpu_address() · 13dc4b77

由 Nicolas Saenz Julienne 提交于 3月 16, 2021

mainline inclusion
from mainline-5.11-rc1
commit 964db79d
category: bugfix
bugzilla: 50423
CVE: NA

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

Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201119175400.9995-4-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Reviewed-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

13dc4b77

arm64: mm: Move zone_dma_bits initialization into zone_sizes_init() · 4395648c

由 Nicolas Saenz Julienne 提交于 3月 16, 2021

mainline inclusion
from mainline-5.11-rc1
commit 9804f8c6
category: bugfix
bugzilla: 50423
CVE: NA

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

zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: NJeremy Linton <jeremy.linton@arm.com>
Link: https://lore.kernel.org/r/20201119175400.9995-3-nsaenzjulienne@suse.deSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Reviewed-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4395648c

openeuler / Kernel 大约 2 年 前同步成功

openeuler / Kernel
大约 2 年前同步成功