提交 · 3bf501c87ffe1f045f86af89e8958fed62c02c94 · openeuler / Kernel

08 11月, 2022 1 次提交

ascend agent smmu: an implementation of ARM SMMUv3 ATOS feature · 3bf501c8

由 Binfeng Wu 提交于 8月 17, 2022

ascend inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5JSWJ
CVE: NA

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

To support HCCS bus using in Ascend series accelerators, the SMMU ATOS
(a software-accessible Address Translation Operations facility) feature
is enabled for a special SMMU aka Agent SMMU in the Ascend accelerator.

In the VM scenario, the hypervisor creates Stage1 page table for the
Agent SMMU. The Agent SMMU provides an interface for components in
accelerator to translate addresses from IPA to PA. This allows the
components to DMA on the HCCS bus using PA.

The origin SMMU ATOS feature only support translation of only a single
group of addresses at a time. Ascend Agent SMMUs use the IMPLEMENTATION
DEFINED region to implement translation of max 32 groups of addresses at
the same time which can greatly improve the efficiency.
Reviewed-by: NYingtai Xie <xieyingtai@huawei.com>
Reviewed-by: NXiaoyang Xu <xuxiaoyang2@huawei.com>
Signed-off-by: NBinfeng Wu <wubinfeng@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Signed-off-by: Nyezengruan <yezengruan@huawei.com>

3bf501c8

14 10月, 2022 12 次提交

init/Kconfig: Add SMP to the dependencies of QOS_SCHED · 96921e00

由 Xia Fukun 提交于 10月 14, 2022

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

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

After CONFIG_SMP is disabled during kernel compilation,
CONFIG_QOS_SCHED is not disabled.
As a result, the following error occurs:

kernel/sched/fair.c: In function ‘check_qos_cfs_rq’:
kernel/sched/fair.c:7324:4: error: implicit declaration of function
‘sched_idle_cpu’; did you mean ‘sched_idle_rq’?
[-Werror=implicit-function-declaration]
 7324 |   !sched_idle_cpu(smp_processor_id()) &&
      |    ^~~~~~~~~~~~~~
./include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
      |                                          ^
  CC      mm/highmem.o
kernel/sched/fair.c: In function ‘pick_next_task_fair’:
kernel/sched/fair.c:7599:43: error: ‘struct rq’ has no member named ‘online’
 7599 |   if (cfs_rq->idle_h_nr_running != 0 && rq->online)
      |                                           ^~
  AR      arch/x86/mm/pat/built-in.a
  CC      kernel/sched/stats.o
kernel/sched/fair.c:7790:7: error: ‘struct rq’ has no member named ‘idle_stamp’;
did you mean ‘idle_state’?
 7790 |   rq->idle_stamp = 0;
      |       ^~~~~~~~~~
      |       idle_state

This is because the definitions of the corresponding functions
and variables depend on the SMP configuration.
So add SMP to the dependencies of QOS_SCHED.
Signed-off-by: NXia Fukun <xiafukun@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Reviewed-by: Nzheng zucheng <zhengzucheng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

96921e00

iommu/arm-smmu-v3: Disable ECMDQ before the system is suspended · 959ffe13

由 Zhen Lei 提交于 10月 14, 2022

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

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

We are currently not doing anything in arm_smmu_suspend(), but ECMDQ may
have executed some commands. In arm_smmu_device_reset(), we assume that
the index value of prod and cons are zero. Therefore, when ecmdq is
enabled again, the index values of prod and cons are inconsistent. As a
result, the hardware mistakenly considers that there are commands in the
queue and executes them and reports invalid commands.

On the other hand, when we disable ecmdq, we need to wait for ENACK to
become 0 before writing cons.

Disable ECMDQ in arm_smmu_suspend() to save energy.

Fixes: 4b009f70 ("iommu/arm-smmu-v3: Add suspend and resume support")
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Tested-by: NLiyan Liu <liuliyan6@h-partners.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

959ffe13

tty: fix deadlock caused by calling printk() under tty_port->lock · f71394ae

由 Qi Zheng 提交于 10月 14, 2022

mainline inclusion
from mainline-v5.19-rc1
commit 6b9dbedb
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5T1KJ
CVE: NA

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

pty_write() invokes kmalloc() which may invoke a normal printk() to print
failure message.  This can cause a deadlock in the scenario reported by
syz-bot below:

       CPU0              CPU1                    CPU2
       ----              ----                    ----
                         lock(console_owner);
                                                 lock(&port_lock_key);
  lock(&port->lock);
                         lock(&port_lock_key);
                                                 lock(&port->lock);
  lock(console_owner);

As commit dbdda842 ("printk: Add console owner and waiter logic to
load balance console writes") said, such deadlock can be prevented by
using printk_deferred() in kmalloc() (which is invoked in the section
guarded by the port->lock).  But there are too many printk() on the
kmalloc() path, and kmalloc() can be called from anywhere, so changing
printk() to printk_deferred() is too complicated and inelegant.

Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
that printk() will not be called, and this deadlock problem can be
avoided.

Syzbot reported the following lockdep error:
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>

======================================================
WARNING: possible circular locking dependency detected
5.4.143-00237-g08ccc19a-dirty #10 Not tainted
------------------------------------------------------
syz-executor.4/29420 is trying to acquire lock:
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023

but task is already holding lock:
ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&port->lock){-.-.}-{2:2}:
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
       tty_port_tty_get drivers/tty/tty_port.c:288 [inline]          		<-- lock(&port->lock);
       tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
       serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
       serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
       serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] 	<-- lock(&port_lock_key);
       serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
       serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
       __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
       [...]

-> #1 (&port_lock_key){-.-.}-{2:2}:
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
       serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
										<-- lock(&port_lock_key);
       call_console_drivers kernel/printk/printk.c:1819 [inline]
       console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
       vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024			<-- lock(console_owner);
       vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
       printk+0xba/0xed kernel/printk/printk.c:2084
       register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
       univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
       console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
       start_kernel+0x5e9/0x879 init/main.c:713
       secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241

-> #0 (console_owner){....}-{0:0}:
       [...]
       lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
       console_trylock_spinning kernel/printk/printk.c:1773 [inline]		<-- lock(console_owner);
       vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023
       vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
       printk+0xba/0xed kernel/printk/printk.c:2084
       fail_dump lib/fault-inject.c:45 [inline]
       should_fail+0x67b/0x7c0 lib/fault-inject.c:144
       __should_failslab+0x152/0x1c0 mm/failslab.c:33
       should_failslab+0x5/0x10 mm/slab_common.c:1224
       slab_pre_alloc_hook mm/slab.h:468 [inline]
       slab_alloc_node mm/slub.c:2723 [inline]
       slab_alloc mm/slub.c:2807 [inline]
       __kmalloc+0x72/0x300 mm/slub.c:3871
       kmalloc include/linux/slab.h:582 [inline]
       tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175
       __tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273
       tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318
       tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
       pty_write+0x126/0x1f0 drivers/tty/pty.c:122				<-- lock(&port->lock);
       n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356
       do_tty_write drivers/tty/tty_io.c:961 [inline]
       tty_write+0x512/0x930 drivers/tty/tty_io.c:1045
       __vfs_write+0x76/0x100 fs/read_write.c:494
       [...]

other info that might help us debug this:

Chain exists of:
  console_owner --> &port_lock_key --> &port->lock

Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com
Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com
Fixes: b6da31b2 ("tty: Fix data race in tty_insert_flip_string_fixed_flag")
Signed-off-by: NQi Zheng <zhengqi.arch@bytedance.com>
Acked-by: NJiri Slaby <jirislaby@kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

conflict:
	drivers/tty/tty_buffer.c
Signed-off-by: NYi Yang <yiyang13@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f71394ae

netfilter: nf_conntrack_irc: Fix forged IP logic · cbe66835

由 David Leadbeater 提交于 10月 14, 2022

stable inclusion
from stable-v5.10.143
commit e12ce30fe593dd438c5b392290ad7316befc11ca
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5OWZ7
CVE: CVE-2022-2663

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e12ce30fe593dd438c5b392290ad7316befc11ca

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

[ Upstream commit 0efe125c ]

Ensure the match happens in the right direction, previously the
destination used was the server, not the NAT host, as the comment
shows the code intended.

Additionally nf_nat_irc uses port 0 as a signal and there's no valid way
it can appear in a DCC message, so consider port 0 also forged.

Fixes: 869f37d8 ("[NETFILTER]: nf_conntrack/nf_nat: add IRC helper port")
Signed-off-by: NDavid Leadbeater <dgl@dgl.cx>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

cbe66835

ext4: fix dir corruption when ext4_dx_add_entry() fails · 56d4a7df

由 Zhihao Cheng 提交于 10月 14, 2022

mainline inclusion
from mainline-v6.0-rc8
commit 7177dd00
category: bugfix
bugzilla: 187586, https://gitee.com/openeuler/kernel/issues/I5V3VI
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ext4/namei.c?h=next-20221011&id=7177dd009c7c04290891e9a534cd47d1b620bd04

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

Following process may lead to fs corruption:
1. ext4_create(dir/foo)
 ext4_add_nondir
  ext4_add_entry
   ext4_dx_add_entry
     a. add_dirent_to_buf
      ext4_mark_inode_dirty
      ext4_handle_dirty_metadata   // dir inode bh is recorded into journal
     b. ext4_append    // dx_get_count(entries) == dx_get_limit(entries)
       ext4_bread(EXT4_GET_BLOCKS_CREATE)
        ext4_getblk
         ext4_map_blocks
          ext4_ext_map_blocks
            ext4_mb_new_blocks
             dquot_alloc_block
              dquot_alloc_space_nodirty
               inode_add_bytes    // update dir's i_blocks
            ext4_ext_insert_extent
	     ext4_ext_dirty  // record extent bh into journal
              ext4_handle_dirty_metadata(bh)
	      // record new block into journal
       inode->i_size += inode->i_sb->s_blocksize   // new size(in mem)
     c. ext4_handle_dirty_dx_node(bh2)
	// record dir's new block(dx_node) into journal
     d. ext4_handle_dirty_dx_node((frame - 1)->bh)
     e. ext4_handle_dirty_dx_node(frame->bh)
     f. do_split    // ret err!
     g. add_dirent_to_buf
	 ext4_mark_inode_dirty(dir)  // update raw_inode on disk(skipped)
2. fsck -a /dev/sdb
 drop last block(dx_node) which beyonds dir's i_size.
  /dev/sdb: recovering journal
  /dev/sdb contains a file system with errors, check forced.
  /dev/sdb: Inode 12, end of extent exceeds allowed value
	(logical block 128, physical block 3938, len 1)
3. fsck -fn /dev/sdb
 dx_node->entry[i].blk > dir->i_size
  Pass 2: Checking directory structure
  Problem in HTREE directory inode 12 (/dir): bad block number 128.
  Clear HTree index? no
  Problem in HTREE directory inode 12: block #3 has invalid depth (2)
  Problem in HTREE directory inode 12: block #3 has bad max hash
  Problem in HTREE directory inode 12: block #3 not referenced

Fix it by marking inode dirty directly inside ext4_append().
Fetch a reproducer in [Link].

Link: https://bugzilla.kernel.org/show_bug.cgi?id=216466
Cc: stable@vger.kernel.org
Conflicts:
  fs/ext4/namei.c
  [ 188c299e("ext4: Support for checksumming from journal
    triggers") is not applied. ]
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20220911045204.516460-1-chengzhihao1@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

56d4a7df

ext4: fix check for block being out of directory size · 5bca35fb

由 Jan Kara 提交于 10月 14, 2022

mainline inclusion
from mainline-v6.1-rc1
commit 61a1d87a
category: bugfix
bugzilla: 186639, https://gitee.com/src-openeuler/kernel/issues/I58WSQ
CVE: CVE-2022-1184

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=61a1d87a324ad5e3ed27c6699dfc93218fcf3201

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

The check in __ext4_read_dirblock() for block being outside of directory
size was wrong because it compared block number against directory size
in bytes. Fix it.

Fixes: 65f8ea4c ("ext4: check if directory block is within i_size")
CVE: CVE-2022-1184
CC: stable@vger.kernel.org
Signed-off-by: NJan Kara <jack@suse.cz>
Reviewed-by: NLukas Czerner <lczerner@redhat.com>
Link: https://lore.kernel.org/r/20220822114832.1482-1-jack@suse.czSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5bca35fb

ext4: make sure ext4_append() always allocates new block · 5f42a36c

由 Lukas Czerner 提交于 10月 14, 2022

mainline inclusion
from mainline-v6.0-rc1
commit b8a04fe7
category: bugfix
bugzilla: 186639, https://gitee.com/src-openeuler/kernel/issues/I58WSQ
CVE: CVE-2022-1184

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b8a04fe77ef1360fbf73c80fddbdfeaa9407ed1b

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

ext4_append() must always allocate a new block, otherwise we run the
risk of overwriting existing directory block corrupting the directory
tree in the process resulting in all manner of problems later on.

Add a sanity check to see if the logical block is already allocated and
error out if it is.

Cc: stable@kernel.org
Signed-off-by: NLukas Czerner <lczerner@redhat.com>
Reviewed-by: NAndreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20220704142721.157985-2-lczerner@redhat.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5f42a36c

ext4: check if directory block is within i_size · 43036ac6

由 Lukas Czerner 提交于 10月 14, 2022

mainline inclusion
from mainline-v6.0-rc1
commit 65f8ea4c
category: bugfix
bugzilla: 186639, https://gitee.com/src-openeuler/kernel/issues/I58WSQ
CVE: CVE-2022-1184

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65f8ea4cd57dbd46ea13b41dc8bac03176b04233

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

Currently ext4 directory handling code implicitly assumes that the
directory blocks are always within the i_size. In fact ext4_append()
will attempt to allocate next directory block based solely on i_size and
the i_size is then appropriately increased after a successful
allocation.

However, for this to work it requires i_size to be correct. If, for any
reason, the directory inode i_size is corrupted in a way that the
directory tree refers to a valid directory block past i_size, we could
end up corrupting parts of the directory tree structure by overwriting
already used directory blocks when modifying the directory.

Fix it by catching the corruption early in __ext4_read_dirblock().

Addresses Red-Hat-Bugzilla: #2070205
CVE: CVE-2022-1184
Signed-off-by: NLukas Czerner <lczerner@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: NAndreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20220704142721.157985-1-lczerner@redhat.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

43036ac6

ext4: make variable "count" signed · 2e9cd9b8

由 Ding Xiang 提交于 10月 14, 2022

stable inclusion
from stable-v5.10.124
commit 0ca74dacfd478a9c03361b7512be48ea6b22e8a5
category: bugfix
bugzilla: 186639, https://gitee.com/src-openeuler/kernel/issues/I58WSQ
CVE: CVE-2022-1184

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0ca74dacfd478a9c03361b7512be48ea6b22e8a5

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

commit bc75a6eb upstream.

Since dx_make_map() may return -EFSCORRUPTED now, so change "count" to
be a signed integer so we can correctly check for an error code returned
by dx_make_map().

Fixes: 46c116b9 ("ext4: verify dir block before splitting it")
Cc: stable@kernel.org
Signed-off-by: NDing Xiang <dingxiang@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20220530100047.537598-1-dingxiang@cmss.chinamobile.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2e9cd9b8

iommu: Fix compliation failure caused by iommu_device_register · 6713bdf0

由 Kunkun Jiang 提交于 10月 14, 2022

virt inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5UN39
CVE: NA

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

Two redundant arguements are added to 'iommu_device_register' of
'include/linux/iommu.h' in the commit bbf3b39e ("iommu:
Introduce dirty log tracking framework"). As a result, compiling
the kernel fails when the CONFIG_IOMMU_API is disabled. Delete the
two redundant arguements to solve this problem.

Fixes: bbf3b39e ("iommu: Introduce dirty log tracking framework")
Reported-by: NYejian Zheng <zhengyejian1@huawei.com>
Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>
Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6713bdf0

ALSA: pcm: oss: Fix race at SNDCTL_DSP_SYNC · f07d2287

由 Sasha Levin 提交于 10月 14, 2022

stable inclusion
from stable-v5.4.215
commit 4051324a6dafd7053c74c475e80b3ba10ae672b0
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5T9C3
CVE: CVE-2022-3303

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs?h=v6.0-rc5&id=8423f0b6d513b259fdab9c9bf4aaa6188d054c2d

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

[ Upstream commit 8423f0b6 ]

There is a small race window at snd_pcm_oss_sync() that is called from
OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls
snd_pcm_oss_make_ready() at first, then takes the params_lock mutex
for the rest.  When the stream is set up again by another thread
between them, it leads to inconsistency, and may result in unexpected
results such as NULL dereference of OSS buffer as a fuzzer spotted
recently.

The fix is simply to cover snd_pcm_oss_make_ready() call into the same
params_lock mutex with snd_pcm_oss_make_ready_locked() variant.
Reported-and-tested-by: Nbutt3rflyh4ck <butterflyhuangxx@gmail.com>
Reviewed-by: NJaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA@mail.gmail.com
Link: https://lore.kernel.org/r/20220905060714.22549-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NXia Longlong <xialonglong1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f07d2287

blk-iocost: don't ignore vrate_min on QD contention · ec1a0406

由 Tejun Heo 提交于 10月 14, 2022

mainline inclusion
from mainline-v5.13-rc1
commit f46ec84b
category: bugfix
bugzilla: 187443, https://gitee.com/openeuler/kernel/issues/I5PFPV
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46ec84b5acbf8d7067d71a6bbdde213d4b86036

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

ioc_adjust_base_vrate() ignored vrate_min when rq_wait_pct indicates that
there is QD contention. The reasoning was that QD depletion always reliably
indicates device saturation and thus it's safe to override user specified
vrate_min. However, this sometimes leads to unnecessary throttling,
especially on really fast devices, because vrate adjustments have delays and
inertia. It also confuses users because the behavior violates the explicitly
specified configuration.

This patch drops the special case handling so that vrate_min is always
applied.
Signed-off-by: NTejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/YIIo1HuyNmhDeiNx@slm.duckdns.orgSigned-off-by: NJens Axboe <axboe@kernel.dk>

confilict:
	block/blk-iocost.c
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ec1a0406

11 10月, 2022 27 次提交

crypto: hisilicon/zip - Use the bitmap API to allocate bitmaps · 4e66e336

由 Christophe JAILLET 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit 11364d61
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11364d61314e

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

Use bitmap_zalloc()/bitmap_free() instead of hand-writing them.
It is less verbose and it improves the semantic.

While at it, add an explicit include <linux/bitmap.h>.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4e66e336

crypto: hisilicon/sec - fix auth key size error · 56e301c7

由 Kai Ye 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit 45f5d017
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=45f5d0176d84

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

The authentication algorithm supports a maximum of 128-byte keys.
The allocated key memory is insufficient.

Fixes: 2f072d75 ("crypto: hisilicon - Add aead support on SEC2")
Signed-off-by: NKai Ye <yekai13@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

56e301c7

crypto: hisilicon/hpre - don't use GFP_KERNEL to alloc mem during softirq · a37d3b54

由 Zhengchao Shao 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit 98dfa934
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=98dfa9343f37

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

The hpre encryption driver may be used to encrypt and decrypt packets
during the rx softirq, it is not allowed to use GFP_KERNEL.

Fixes: c8b4b477 ("crypto: hisilicon - add HiSilicon HPRE accelerator")
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a37d3b54

crypto: hisilicon - Kunpeng916 crypto driver don't sleep when in softirq · f3d257b5

由 Zhengchao Shao 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit 68740ab5
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68740ab50543

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

When kunpeng916 encryption driver is used to deencrypt and decrypt
packets during the softirq, it is not allowed to use mutex lock.

Fixes: 915e4e84 ("crypto: hisilicon - SEC security accelerator driver")
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f3d257b5

crypto: hisilicon/sec - fix inconsistent argument · 0f7f6985

由 Jianglei Nie 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit 32c0f7d4
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32c0f7d4194c

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

The argument passed to sec_queue_aw_alloc() should be
SEC_QUEUE_AW_FROCE_NOALLOC instead of SEC_QUEUE_AR_FROCE_NOALLOC.
Signed-off-by: NJianglei Nie <niejianglei2021@163.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0f7f6985

crypto: hisilicon/sec - only HW V2 needs to change the BD err detection · a6772153

由 Kai Ye 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit bffa1fc0
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bffa1fc06589

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

The base register address of V2 and V3 are different. HW V3 not needs
to change the BD err detection.
Signed-off-by: NKai Ye <yekai13@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a6772153

crypto: hisilicon/qm - modify event irq processing · 62efb773

由 Weili Qian 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit d64de977
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d64de9773c18

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

When the driver receives an event interrupt, the driver will enable
the event interrupt after handling all completed tasks on the function,
tasks on the function are parsed through only one thread. If the task's
user callback takes time, other tasks on the function will be blocked.

Therefore, the event irq processing is modified as follows:
1. Obtain the ID of the queue that completes the task.
2. Enable event interrupt.
3. Parse the completed tasks in the queue and call the user callback.
Enabling event interrupt in advance can quickly report pending event
interrupts and process tasks in multiple threads.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

62efb773

crypto: hisilicon/qm - move alloc qm->wq to qm.c · 936687ee

由 Weili Qian 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit 3099fc9c
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3099fc9c2b3a

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

Before stopping the function, the driver needs to flush all the remaining
work about event irq. Therefore, accelerator drivers use a private
workqueue(qm->wq) to handle event irq instead of the system workqueue.
This patch moves alloc workqueue from sec_main.c and zip_main.c to qm.c.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

936687ee

crypto: hisilicon/qm - add functions for releasing resources · d8b7f8f2

由 Weili Qian 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit bf081d6f
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bf081d6fa8e9

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

The resources allocated by hisi_qm_memory_init() are released by
hisi_qm_uninit(). Add hisi_qm_memory_uninit() to release resources,
no functional change.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

conficts:
	drivers/crypto/hisilicon/qm.c
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d8b7f8f2

crypto: hisilicon/trng - fix local variable type · 07e594c8

由 Weili Qian 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit 00856e53
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00856e5391fb

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

The return value of 'readl_poll_timeout' is '0' or '-ETIMEDOUT'. Therefore,
change the local variable 'ret' type from 'u32' to 'int'.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

07e594c8

crypto: hisilicon/sec - fix typos in comment · 2c38e2c7

由 Julia Lawall 提交于 10月 11, 2022

mainline inclusion
from mainline-master
commit 3f3bbf22
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MK7S
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f3bbf22a592

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

Spelling mistakes (triple letters) in comment.
Detected with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2c38e2c7

net: hns3: add judge fd ability for sync and clear process of flow director · 84244f85

由 Guangbin Huang 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc4
commit 236b8f5d
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=236b8f5dc75d

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

Currently, driver will always clear user defined field of flow director
in uninit process and sync flow director table in periodic task. However,
if hardware does not support flow director driver should not do those
processes, so add fd ability judgement.

The fd ability judgement in function hclge_clear_fd_rules_in_list() is
redundant, so delete it.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

84244f85

net: hns3: refactor function hclge_mbx_handler() · 92f52e28

由 Hao Lan 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc4
commit 09431ed8
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09431ed8de87

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

Currently, the function hclge_mbx_handler() has too many switch-case
statements, it makes this function too long. To improve code readability,
refactor this function and use lookup table instead.
Signed-off-by: NHao Lan <lanhao@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

92f52e28

net: hns3: optimize converting dscp to priority process of hns3_nic_select_queue() · 3f0019a0

由 Guangbin Huang 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc4
commit dfea275e
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dfea275e06c2

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

Currently, when function hns3_nic_select_queue() converts dscp to priority,
it calls an indirect callback ae_algo->ops->get_dscp_prio to get priority.

However as function hns3_nic_select_queue() is in fast path, the indirect
call may cause degradation of performance. For optimization, this patch
moves dscp_app_cnt and dscp_prio from struct hclge_tm_info to struct
hnae3_knic_private_info, so they can be used in both hclge and hns3 layers.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

3f0019a0

net: hns3: add support for external loopback test · 8cc9c7a9

由 Yonglong Liu 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc4
commit 04b6ba14
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04b6ba143521

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

This patch add support for external loopback test.
The successful test need the link is up with duplex full. The
driver do external loopback first, and then the whole offline
test.
Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8cc9c7a9

net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO · 64d5d4ce

由 Hangbin Liu 提交于 10月 11, 2022

mainline inclusion
from mainline-v5.19-rc1
commit dfed913e
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dfed913e8b55

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

Currently, the kernel drops GSO VLAN tagged packet if it's created with
socket(AF_PACKET, SOCK_RAW, 0) plus virtio_net_hdr.

The reason is AF_PACKET doesn't adjust the skb network header if there is
a VLAN tag. Then after virtio_net_hdr_set_proto() called, the skb->protocol
will be set to ETH_P_IP/IPv6. And in later inet/ipv6_gso_segment() the skb
is dropped as network header position is invalid.

Let's handle VLAN packets by adjusting network header position in
packet_parse_headers(). The adjustment is safe and does not affect the
later xmit as tap device also did that.

In packet_snd(), packet_parse_headers() need to be moved before calling
virtio_net_hdr_set_proto(), so we can set correct skb->protocol and
network header first.

There is no need to update tpacket_snd() as it calls packet_parse_headers()
in tpacket_fill_skb(), which is already before calling virtio_net_hdr_*
functions.

skb->no_fcs setting is also moved upper to make all skb settings together
and keep consistency with function packet_sendmsg_spkt().
Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
Acked-by: NWillem de Bruijn <willemb@google.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Link: https://lore.kernel.org/r/20220425014502.985464-1-liuhangbin@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

64d5d4ce

net: hns3: debugfs add dump dscp map info · da7620f6

由 Guangbin Huang 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc3
commit fddc02eb
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fddc02eb583a

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

This patch add dump the map relation for dscp, priority and TC, and
the current tc map mode.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

da7620f6

net: hns3: support ndo_select_queue() · 757d2e9b

由 Guangbin Huang 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc3
commit f6e32724
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f6e32724ca13

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

To support tx packets to select queue according to its dscp field after
setting dscp and tc map relationship, this patch implements
ndo_select_queue() to set skb->priority according to the user's setting
dscp and priority map relationship.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

757d2e9b

net: hns3: add support config dscp map to tc · 7a1313b3

由 Guangbin Huang 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc3
commit 0ba22bcb
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ba22bcb222d

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

This patch add support config dscp map to tc by implementing ieee_setapp
and ieee_delapp of struct dcbnl_rtnl_ops. Driver will convert mapping
relationship from dscp-prio to dscp-tc.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

7a1313b3

net: hns3: net: hns3: add querying and setting fec off mode from firmware · 845a54ea

由 Guangbin Huang 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc2
commit 08aa17a0
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=08aa17a0c185

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

For some new devices, the FEC mode can not be set to OFF in speed 200G.
In order to flexibly adapt to all types of devices, driver queries
fec ability from firmware to decide whether OFF mode can be supported.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

845a54ea

net: hns3: add querying and setting fec llrs mode from firmware · 20ec0aa8

由 Hao Lan 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc2
commit 5c4f7284
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c4f72842d1d

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

This patch supports llrs fec mode in speed 200G for some new devices, and
suppoprts querying llrs fec ability from firmware.
Signed-off-by: NHao Lan <lanhao@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

20ec0aa8

net: hns3: add querying fec ability from firmware · 5538b273

由 Guangbin Huang 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc2
commit eaf83ae5
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eaf83ae59e18

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

For some new devices, driver can queries fec ability from firmware to
decide which FEC mode can be supported.

If devices of old version which not support querying fec ability, driver
sets fixed ability according to current speed.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5538b273

net: hns3: add getting capabilities of gro offload and fd from firmware · 72b042b4

由 Guangbin Huang 提交于 10月 11, 2022

mainline inclusion
from mainline-v6.0-rc2
commit 507e46ae
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QIIF
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=507e46ae26ea

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

As some new devices may not support GRO offload and flow table director,
to support these devices, driver needs to querying capabilities of GRO
offload and flow table director from firmware. Whether the driver
supports these two features depends on capabilities.

For old device of version HNAE3_DEVICE_VERSION_V2, driver sets their
capabilities of these two features to fixed value.

Setting default features of netdev and debugfs also need to identify
whether support these two features.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
Reviewed-by: NJian Shen <shenjian15@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

72b042b4

RDMA/hns: Support MR's restrack raw ops for hns driver · 4d20406b

由 Wenpeng Liang 提交于 10月 11, 2022

mainline inclusion
from mainline-for-next
commit 3d67e7e2
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5TAQ5
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=3d67e7e236ad

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

The MR raw restrack attributes come from the queue context maintained by
the ROCEE.

For example:

$ rdma res show mr dev hns_0 mrn 6 -dd -jp -r
[ {
        "ifindex": 4,
        "ifname": "hns_0",
        "data": [ 1,0,0,0,2,0,0,0,0,3,0,0,0,0,2,0,0,0,0,0,32,0,0,0,2,0,0,0,
		  2,0,0,0,0,0,0,0 ]
    } ]

Link: https://lore.kernel.org/r/20220822104455.2311053-8-liangwenpeng@huawei.comSigned-off-by: NWenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: NLeon Romanovsky <leon@kernel.org>
Signed-off-by: NZhengfeng Luo <luozhengfeng@h-partners.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4d20406b

RDMA/hns: Support MR's restrack ops for hns driver · 98b07261

由 Wenpeng Liang 提交于 10月 11, 2022

mainline inclusion
from mainline-for-next
commit dc9981ef
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5TAQ5
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=dc9981ef17c6

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

The MR restrack attributes come from the queue information maintained by
the driver.

For example:

$ rdma res show mr dev hns_0 mrn 6 -dd -jp
[ {
        "ifindex": 4,
        "ifname": "hns_0",
        "mrn": 6,
        "rkey": "300",
        "lkey": "300",
        "mrlen": 131072,
        "pdn": 8,
        "pid": 1524,
        "comm": "ib_send_bw"
    },
    "drv_pbl_hop_num": 2,
    "drv_ba_pg_shift": 14,
    "drv_buf_pg_shift": 12
}

Link: https://lore.kernel.org/r/20220822104455.2311053-7-liangwenpeng@huawei.comSigned-off-by: NWenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: NLeon Romanovsky <leon@kernel.org>
Signed-off-by: NZhengfeng Luo <luozhengfeng@h-partners.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

98b07261

RDMA/hns: Support QP's restrack raw ops for hns driver · 0480d2ff

由 Wenpeng Liang 提交于 10月 11, 2022

mainline inclusion
from mainline-for-next
commit 3e89d78b
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5TAQ5
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=3e89d78b21a8

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

The QP raw restrack attributes come from the queue context maintained by
the ROCEE.

For example:

$ rdma res show qp link hns_0 -jp -dd -r
[ {
        "ifindex": 4,
        "ifname": "hns_0",
        "data": [ 2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,0,0,0,
		  5,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,255,156,0,0,63,156,0,0,
		  7,0,0,0,1,0,0,0,9,0,0,0,0,0,0,0,2,0,0,0,2,0,0,0,0,0,0,
		  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
		  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,63,156,0,
		  0,0,0,0,0 ]
    } ]

Link: https://lore.kernel.org/r/20220822104455.2311053-6-liangwenpeng@huawei.comSigned-off-by: NWenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: NLeon Romanovsky <leon@kernel.org>
Signed-off-by: NZhengfeng Luo <luozhengfeng@h-partners.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0480d2ff

RDMA/hns: Support QP's restrack ops for hns driver · 78425b64

由 Wenpeng Liang 提交于 10月 11, 2022

mainline inclusion
from mainline-for-next
commit e198d65d
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5TAQ5
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=e198d65d76e9

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

The QP restrack attributes come from the queue information maintained by
the driver.

For example:

$ rdma res show qp link hns_0 lqpn 41 -jp -dd
[ {
        "ifindex": 4,
        "ifname": "hns_0",
        "port": 1,
        "lqpn": 41,
        "rqpn": 40,
        "type": "RC",
        "state": "RTR",
        "rq-psn": 12474738,
        "sq-psn": 0,
        "path-mig-state": "ARMED",
        "pdn": 9,
        "pid": 1523,
        "comm": "ib_send_bw"
    },
    "drv_sq_wqe_cnt": 128,
    "drv_sq_max_gs": 1,
    "drv_rq_wqe_cnt": 512,
    "drv_rq_max_gs": 2,
    "drv_ext_sge_sge_cnt": 0
}

Link: https://lore.kernel.org/r/20220822104455.2311053-5-liangwenpeng@huawei.comSigned-off-by: NWenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: NLeon Romanovsky <leon@kernel.org>
Signed-off-by: NZhengfeng Luo <luozhengfeng@h-partners.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

78425b64

openeuler / Kernel 1 年多 前同步成功

openeuler / Kernel
1 年多前同步成功