driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6NPLN
CVE: NA

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

If an NCQ error occurs when the IPTT is valid and slot->abort flag is set
in completion path, sas_task_abort() will be called to abort only one NCQ
command now, and the host would be set to SHOST_RECOVERY state. But this
may not kick-off EH Immediately until other outstanding QCs timeouts. As a
result, the host may remain in the SHOST_RECOVERY state for up to 30
seconds, such as follows:

[7972317.645234] hisi_sas_v3_hw 0000:74:04.0: erroneous completion iptt=3264 task=00000000466116b8 dev id=2 sas_addr=0x5000000000000502 CQ hdr: 0x1883 0x20cc0 0x40000 0x20420000 Error info: 0x0 0x0 0x200000 0x0
[7972341.508264] sas: Enter sas_scsi_recover_host busy: 32 failed: 32
[7972341.984731] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 32 tries: 1

So all NCQ commands that are in the queue should be aborted when an NCQ
error occurs In this scenario.

Fixes: 05d91b55 ("scsi: hisi_sas: Directly trigger SCSI error handling for completion errors")
Signed-off-by: NXingui Yang <yangxingui@huawei.com>
Reviewed-by: NXiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

mainline inclusion
from mainline-v6.2-rc4
commit a67aad57
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6NPLN
CVE: NA

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

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

Grab the ATA port lock in sas_ata_device_link_abort() before calling
ata_link_abort() as outlined in this function's locking requirements.

Fixes: 44112922 ("scsi: libsas: Add sas_ata_device_link_abort()")
Signed-off-by: NXingui Yang <yangxingui@huawei.com>
Reviewed-by: NJohn Garry <john.g.garry@oracle.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit cc22efbe
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6NPLN
CVE: NA

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

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

In sas_ata_task_done(), for commands which complete with error we set the
SATA dev FIS status field with ATA_ERR. In ata_eh_analyze_tf() this would
be interpreted as a HSM error. Set ATA_DRDY, which will lead libata to
judge as a device error, which is a safer bet.
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1665998435-199946-9-git-send-email-john.garry@huawei.comReviewed-by: NNiklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

mainline inclusion
from mainline-v6.2-rc4
commit 037b4805
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6NPLN
CVE: NA

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

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

Currently clear task set is used to abort all commands remaining in the
disk when the SAS disk is discovered, and if the disk is discovered by two
initiators, other I_T nexuses are also affected. So use abort task set
instead and take effect only on the specified I_T nexus.
Signed-off-by: NXingui Yang <yangxingui@huawei.com>
Signed-off-by: NXiang Chen <chenxiang66@hisilicon.com>
Link: https://lore.kernel.org/r/1672805000-141102-2-git-send-email-chenxiang66@hisilicon.comSigned-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 930d97da
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6NPLN
CVE: NA

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

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

When CQ header dw3 SATA_DISK_ERR is set it means this SATA disk is in error
state and the current IPTT is invalid. An invalid IPTT does not correspond
to any slot.

In this scenario, new I/Os that delivered to disk will be rejected by the
controller and all I/Os remaining in the disk should be aborted, which we
add here with the sas_ata_device_link_abort() call.

In hisi_sas_abort_task() we don't want to issue a soft reset as it may
cause info to be lost in the target disk for the ATA EH autopsy. In this
case, just release resources - the disk won't return other I/Os normally
after NCQ Error, so this is safe.
Signed-off-by: NXingui Yang <yangxingui@huawei.com>
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1665998435-199946-4-git-send-email-john.garry@huawei.comSigned-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 4b329abc
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6NPLN
CVE: NA

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

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

Each branch currently defines a slot variable independently, and it is
neater to move it to the function head.
Signed-off-by: NXingui Yang <yangxingui@huawei.com>
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1665998435-199946-3-git-send-email-john.garry@huawei.comSigned-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 44112922
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6NPLN
CVE: NA

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

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

Similar to how AHCI handles NCQ errors in ahci_error_intr() ->
ata_port_abort() -> ata_do_link_abort(), add an NCQ error handler for LLDDs
to call to initiate a link abort.

This will mark all outstanding QCs as failed and kick-off EH.

Note:

A "force reset" argument is added for drivers which require the ATA error
handling to always reset the device.

A driver may require this feature for when SATA device per-SCSI cmnd
resources are only released during reset for ATA EH. As such, we need an
option to force reset to be done, regardless of what any EH autopsy
decides.

The SATA device FIS fields are set to indicate a device error from
ata_eh_analyze_tf().
Suggested-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
Suggested-by: NNiklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1665998435-199946-2-git-send-email-john.garry@huawei.comTested-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Niklas Cassel <niklas.cassel@wdc.com> # pm80xx
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

Merge Pull Request from: @Hongchen_Zhang 
 
fix some pci/pcie problems of LS7A.
After apply this PR and https://gitee.com/openeuler/kernel/pulls/476
, the following test passed:
1. boot 3A5000+7A2000 machine with integrated GPU
2. SUCCESS to login with tty0
3. echo mem >/sys/power/state
4. press powerbutton
5. machine resumed success 
 
Link:https://gitee.com/openeuler/kernel/pulls/448 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @zhangjialin11 
 
Pull new CVEs:
CVE-2023-1074

scsi bugfixes from Zhong Jinghua
ring-buffer bugfix from Zheng Yejian
block bugfixes from Yu Kuai
fs bugfixes from Zhihao Cheng, Long Li and Zhang Yi 
 
Link:https://gitee.com/openeuler/kernel/pulls/486 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @Hongchen_Zhang 
 
when compile x86_64 using make ARCH=x86_64,error occurred,the reason is
ARCH is a command-line argument.So split loongarch architecture from others. 
 
Link:https://gitee.com/openeuler/kernel/pulls/477 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

hulk inclusion
category: bugfix
bugzilla: 188150, https://gitee.com/openeuler/kernel/issues/I643OL

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

Cancel the inflight async device probe when removing scsi_target, so
no new disk will be added when __scsi_target_remove() returns.
Signed-off-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.150
commit 0cf6c09dafeeb6f3d92cc19ea9e024640448c42e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6LCWQ
CVE: NA

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

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

commit a0fcaaed upstream.

The ring buffer is broken up into sub buffers (currently of page size).
Each sub buffer has a pointer to its "tail" (the last event written to the
sub buffer). When a new event is requested, the tail is locally
incremented to cover the size of the new event. This is done in a way that
there is no need for locking.

If the tail goes past the end of the sub buffer, the process of moving to
the next sub buffer takes place. After setting the current sub buffer to
the next one, the previous one that had the tail go passed the end of the
sub buffer needs to be reset back to the original tail location (before
the new event was requested) and the rest of the sub buffer needs to be
"padded".

The race happens when a reader takes control of the sub buffer. As readers
do a "swap" of sub buffers from the ring buffer to get exclusive access to
the sub buffer, it replaces the "head" sub buffer with an empty sub buffer
that goes back into the writable portion of the ring buffer. This swap can
happen as soon as the writer moves to the next sub buffer and before it
updates the last sub buffer with padding.

Because the sub buffer can be released to the reader while the writer is
still updating the padding, it is possible for the reader to see the event
that goes past the end of the sub buffer. This can cause obvious issues.

To fix this, add a few memory barriers so that the reader definitely sees
the updates to the sub buffer, and also waits until the writer has put
back the "tail" of the sub buffer back to the last event that was written
on it.

To be paranoid, it will only spin for 1 second, otherwise it will
warn and shutdown the ring buffer code. 1 second should be enough as
the writer does have preemption disabled. If the writer doesn't move
within 1 second (with preemption disabled) something is horribly
wrong. No interrupt should last 1 second!

Link: https://lore.kernel.org/all/20220830120854.7545-1-jiazi.li@transsion.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216369
Link: https://lkml.kernel.org/r/20220929104909.0650a36c@gandalf.local.home

Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@vger.kernel.org
Fixes: c7b09308 ("ring-buffer: prevent adding write in discarded area")
Reported-by: NJiazi.Li <jiazi.li@transsion.com>
Signed-off-by: NSteven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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

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

'ios' and 'sectors' is counted in bio_start_io_acct() while io is
started insted of io is done. Hence switch to precise io accounting to
count them when io is done.
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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

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

Currently, for bio-based device, 'ios' and 'sectors' is counted while
io is started, while 'nsecs' is counted while io is done.

This behaviour is obviously wrong, however we can't fix exist kapis
because this will require new parameter, which will cause kapi broken.
Hence this patch add some new apis, which will make sure io accounting
for bio-based device is precise.
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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

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

In the error path of raid10_run(), 'conf' need be freed, however,
'conf->bio_split' is missed and memory will be leaked.

Since there are 3 places to free 'conf', factor out a helper to fix the
problem.

Fixes: fc9977dd ("md/raid10: simplify the splitting of requests.")
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 188355, https://gitee.com/openeuler/kernel/issues/I6E4JF

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

A use-after-free problem like below:

BUG: KASAN: use-after-free in scsi_target_reap+0x6c/0x70

Workqueue: scsi_wq_1 __iscsi_unbind_session [scsi_transport_iscsi]
Call trace:
 dump_backtrace+0x0/0x320
 show_stack+0x24/0x30
 dump_stack+0xdc/0x128
 print_address_description+0x68/0x278
 kasan_report+0x1e4/0x308
 __asan_report_load4_noabort+0x30/0x40
 scsi_target_reap+0x6c/0x70
 scsi_remove_target+0x430/0x640
 __iscsi_unbind_session+0x164/0x268 [scsi_transport_iscsi]
 process_one_work+0x67c/0x1350
 worker_thread+0x370/0xf90
 kthread+0x2a4/0x320
 ret_from_fork+0x10/0x18

The problem is caused by a concurrency scenario:

T0: delete target
// echo 1 > /sys/devices/platform/host1/session1/target1:0:0/1:0:0:1/delete
T1: logout
// iscsiadm -m node --logout

T0							T1
 sdev_store_delete
  scsi_remove_device
   device_remove_file
    __scsi_remove_device
        					__iscsi_unbind_session
        					 scsi_remove_target
						  spin_lock_irqsave
        					  list_for_each_entry
     scsi_target_reap
     // starget->reap_ref 1 -> 0
     						  kref_get(&starget->reap_ref);
						  // warn use-after-free.
						  spin_unlock_irqrestore
      scsi_target_reap_ref_release
	scsi_target_destroy
	... // delete starget
						  scsi_target_reap
						  // UAF

When T0 reduces the reference count to 0, but has not been released,
T1 can still enter list_for_each_entry, and then kref_get reports UAF.

Fix it by using kref_get_unless_zero() to check for a reference count of
0.
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.165
commit 6ef652f35dcfaa1ab2b2cf6c1694718595148eee
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6I7U3
CVE: CVE-2023-1074

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

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

[ Upstream commit 458e279f ]

Currently, if you bind the socket to something like:
        servaddr.sin6_family = AF_INET6;
        servaddr.sin6_port = htons(0);
        servaddr.sin6_scope_id = 0;
        inet_pton(AF_INET6, "::1", &servaddr.sin6_addr);

And then request a connect to:
        connaddr.sin6_family = AF_INET6;
        connaddr.sin6_port = htons(20000);
        connaddr.sin6_scope_id = if_nametoindex("lo");
        inet_pton(AF_INET6, "fe88::1", &connaddr.sin6_addr);

What the stack does is:
 - bind the socket
 - create a new asoc
 - to handle the connect
   - copy the addresses that can be used for the given scope
   - try to connect

But the copy returns 0 addresses, and the effect is that it ends up
trying to connect as if the socket wasn't bound, which is not the
desired behavior. This unexpected behavior also allows KASLR leaks
through SCTP diag interface.

The fix here then is, if when trying to copy the addresses that can
be used for the scope used in connect() it returns 0 addresses, bail
out. This is what TCP does with a similar reproducer.
Reported-by: NPietro Borrello <borrello@diag.uniroma1.it>
Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Reviewed-by: NXin Long <lucien.xin@gmail.com>
Link: https://lore.kernel.org/r/9fcd182f1099f86c6661f3717f63712ddd1c676c.1674496737.git.marcelo.leitner@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

maillist inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6K53I

Reference: https://patchwork.ozlabs.org/project/linux-ext4/patch/20230116020015.1506120-1-yebin@huaweicloud.com/

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

Syzbot found the following issue:

EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!
EXT4-fs (loop0): orphan cleanup on readonly fs
------------[ cut here ]------------
WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30
Modules linked in:
CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869
RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293
RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0
RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040
RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402
R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000
R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc
FS:  0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307
 ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735
 ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605
 ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286
 ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651
 ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864
 ext4_bread+0x2a/0x170 fs/ext4/inode.c:920
 ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105
 write_blk fs/quota/quota_tree.c:64 [inline]
 get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130
 do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340
 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
 dq_insert_tree fs/quota/quota_tree.c:401 [inline]
 qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420
 v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358
 dquot_acquire+0x348/0x670 fs/quota/dquot.c:444
 ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740
 dqget+0x999/0xdc0 fs/quota/dquot.c:914
 __dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492
 ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329
 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474
 __ext4_fill_super fs/ext4/super.c:5516 [inline]
 ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644
 get_tree_bdev+0x400/0x620 fs/super.c:1282
 vfs_get_tree+0x88/0x270 fs/super.c:1489
 do_new_mount+0x289/0xad0 fs/namespace.c:3145
 do_mount fs/namespace.c:3488 [inline]
 __do_sys_mount fs/namespace.c:3697 [inline]
 __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Add some debug information:
mb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/1@3735929054 64 64 7
block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Acctually, blocks per group is 64, but block bitmap indicate at least has
128 blocks. Now, ext4_validate_block_bitmap() didn't check invalid block's
bitmap if set.
To resolve above issue, add check like fsck "Padding at end of block bitmap is
not set".

Reported-by: syzbot+68223fe9f6c95ad43bed@syzkaller.appspotmail.com
Signed-off-by: NYe Bin <yebin10@huawei.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.2-rc6
commit f484a794
category: bugfix
bugzilla: 188443, https://gitee.com/openeuler/kernel/issues/I6I8YD
CVE: NA

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

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

If during iscsi_sw_tcp_session_create() iscsi_tcp_r2tpool_alloc() fails,
userspace could be accessing the host's ipaddress attr. If we then free the
session via iscsi_session_teardown() while userspace is still accessing the
session we will hit a use after free bug.

Set the tcp_sw_host->session after we have completed session creation and
can no longer fail.

Link: https://lore.kernel.org/r/20230117193937.21244-3-michael.christie@oracle.comSigned-off-by: NMike Christie <michael.christie@oracle.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Acked-by: NDing Hui <dinghui@sangfor.com.cn>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.2-rc6
commit 6f1d64b1
category: bugfix
bugzilla: 188443, https://gitee.com/openeuler/kernel/issues/I6I8YD
CVE: NA

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

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

Bug report and analysis from Ding Hui.

During iSCSI session logout, if another task accesses the shost ipaddress
attr, we can get a KASAN UAF report like this:

[  276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0
[  276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088
[  276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G            E      6.1.0-rc8+ #3
[  276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[  276.944470] Call Trace:
[  276.944943]  <TASK>
[  276.945397]  dump_stack_lvl+0x34/0x48
[  276.945887]  print_address_description.constprop.0+0x86/0x1e7
[  276.946421]  print_report+0x36/0x4f
[  276.947358]  kasan_report+0xad/0x130
[  276.948234]  kasan_check_range+0x35/0x1c0
[  276.948674]  _raw_spin_lock_bh+0x78/0xe0
[  276.949989]  iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp]
[  276.951765]  show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi]
[  276.952185]  dev_attr_show+0x3f/0x80
[  276.953005]  sysfs_kf_seq_show+0x1fb/0x3e0
[  276.953401]  seq_read_iter+0x402/0x1020
[  276.954260]  vfs_read+0x532/0x7b0
[  276.955113]  ksys_read+0xed/0x1c0
[  276.955952]  do_syscall_64+0x38/0x90
[  276.956347]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  276.956769] RIP: 0033:0x7f5d3a679222
[  276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[  276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[  276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222
[  276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003
[  276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000
[  276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000
[  276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58
[  276.960536]  </TASK>
[  276.961357] Allocated by task 2209:
[  276.961756]  kasan_save_stack+0x1e/0x40
[  276.962170]  kasan_set_track+0x21/0x30
[  276.962557]  __kasan_kmalloc+0x7e/0x90
[  276.962923]  __kmalloc+0x5b/0x140
[  276.963308]  iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi]
[  276.963712]  iscsi_session_setup+0xda/0xba0 [libiscsi]
[  276.964078]  iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp]
[  276.964431]  iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi]
[  276.964793]  iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi]
[  276.965153]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[  276.965546]  netlink_unicast+0x4d5/0x7b0
[  276.965905]  netlink_sendmsg+0x78d/0xc30
[  276.966236]  sock_sendmsg+0xe5/0x120
[  276.966576]  ____sys_sendmsg+0x5fe/0x860
[  276.966923]  ___sys_sendmsg+0xe0/0x170
[  276.967300]  __sys_sendmsg+0xc8/0x170
[  276.967666]  do_syscall_64+0x38/0x90
[  276.968028]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  276.968773] Freed by task 2209:
[  276.969111]  kasan_save_stack+0x1e/0x40
[  276.969449]  kasan_set_track+0x21/0x30
[  276.969789]  kasan_save_free_info+0x2a/0x50
[  276.970146]  __kasan_slab_free+0x106/0x190
[  276.970470]  __kmem_cache_free+0x133/0x270
[  276.970816]  device_release+0x98/0x210
[  276.971145]  kobject_cleanup+0x101/0x360
[  276.971462]  iscsi_session_teardown+0x3fb/0x530 [libiscsi]
[  276.971775]  iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp]
[  276.972143]  iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi]
[  276.972485]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[  276.972808]  netlink_unicast+0x4d5/0x7b0
[  276.973201]  netlink_sendmsg+0x78d/0xc30
[  276.973544]  sock_sendmsg+0xe5/0x120
[  276.973864]  ____sys_sendmsg+0x5fe/0x860
[  276.974248]  ___sys_sendmsg+0xe0/0x170
[  276.974583]  __sys_sendmsg+0xc8/0x170
[  276.974891]  do_syscall_64+0x38/0x90
[  276.975216]  entry_SYSCALL_64_after_hwframe+0x63/0xcd

We can easily reproduce by two tasks:
1. while :; do iscsiadm -m node --login; iscsiadm -m node --logout; done
2. while :; do cat \
/sys/devices/platform/host*/iscsi_host/host*/ipaddress; done

            iscsid              |        cat
--------------------------------+---------------------------------------
|- iscsi_sw_tcp_session_destroy |
  |- iscsi_session_teardown     |
    |- device_release           |
      |- iscsi_session_release  ||- dev_attr_show
        |- kfree                |  |- show_host_param_
                                |             ISCSI_HOST_PARAM_IPADDRESS
                                |    |- iscsi_sw_tcp_host_get_param
                                |      |- r/w tcp_sw_host->session (UAF)
  |- iscsi_host_remove          |
  |- iscsi_host_free            |

Fix the above bug by splitting the session removal into 2 parts:

 1. removal from iSCSI class which includes sysfs and removal from host
    tracking.

 2. freeing of session.

During iscsi_tcp host and session removal we can remove the session from
sysfs then remove the host from sysfs. At this point we know userspace is
not accessing the kernel via sysfs so we can free the session and host.

Link: https://lore.kernel.org/r/20230117193937.21244-2-michael.christie@oracle.comSigned-off-by: NMike Christie <michael.christie@oracle.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Acked-by: NDing Hui <dinghui@sangfor.com.cn>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
conflicts:
	drivers/scsi/iscsi_tcp.c
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.14-rc1
commit a1f3486b
category: bugfix
bugzilla: 188443, https://gitee.com/openeuler/kernel/issues/I6I8YD
CVE: NA

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

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

This doesn't fix any bugs, but it makes more sense to free the pool after
we have removed the session. At that time we know nothing is touching any
of the session fields, because all devices have been removed and scans are
stopped.

Link: https://lore.kernel.org/r/20210525181821.7617-19-michael.christie@oracle.comReviewed-by: NLee Duncan <lduncan@suse.com>
Signed-off-by: NMike Christie <michael.christie@oracle.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.17-rc6
commit d2d7c047
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KIAO
CVE: NA

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

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

Most buffer io list operations are run with the bp->b_lock held, but
xfs_iflush_abort() can be called without the buffer lock being held
resulting in inodes being removed from the buffer list while other
list operations are occurring. This causes problems with corrupted
bp->b_io_list inode lists during filesystem shutdown, leading to
traversals that never end, double removals from the AIL, etc.

Fix this by passing the buffer to xfs_iflush_abort() if we have
it locked. If the inode is attached to the buffer, we're going to
have to remove it from the buffer list and we'd have to get the
buffer off the inode log item to do that anyway.

If we don't have a buffer passed in (e.g. from xfs_reclaim_inode())
then we can determine if the inode has a log item and if it is
attached to a buffer before we do anything else. If it does have an
attached buffer, we can lock it safely (because the inode has a
reference to it) and then perform the inode abort.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
Signed-off-by: NDarrick J. Wong <djwong@kernel.org>

conflicts:
	fs/xfs/xfs_icache.c
Signed-off-by: NLong Li <leo.lilong@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

maillist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D5XF

Reference: https://lore.kernel.org/linux-ext4/20230130111138.76tp6pij3yhh4brh@quack3/T/#t

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

Current _ext4_show_options() do not distinguish MOPT_2 flag, so it mixed
extend sbi->s_mount_opt2 options with sbi->s_mount_opt, it could lead to
show incorrect options, e.g. show fc_debug_force if we mount with
errors=continue mode and miss it if we set.

  $ mkfs.ext4 /dev/pmem0
  $ mount -o errors=remount-ro /dev/pmem0 /mnt
  $ cat /proc/fs/ext4/pmem0/options | grep fc_debug_force
    #empty
  $ mount -o remount,errors=continue /mnt
  $ cat /proc/fs/ext4/pmem0/options | grep fc_debug_force
    fc_debug_force
  $ mount -o remount,errors=remount-ro,fc_debug_force /mnt
  $ cat /proc/fs/ext4/pmem0/options | grep fc_debug_force
    #empty

Fixes: 995a3ed6 ("ext4: add fast_commit feature and handling for extended mount options")
Signed-off-by: NZhang Yi <yi.zhang@huawei.com>

Conflict:
  fs/ext4/super.c
Reviewed-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

LoongArch inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6MV9N

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

when compile kernel using the following steps:

make allmodconfig ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu-
make oldconfig ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu-
make -j64 ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu-

we get error:

  DESCEND  objtool
  HOSTCC  scripts/sorttable
In file included from scripts/sorttable.c:195:
scripts/sorttable.h:89:10: fatal error: asm/orc_types.h: No such file or directory
   89 | #include <asm/orc_types.h>
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.host:95: scripts/sorttable] Error 1
make: *** [Makefile:1215: scripts] Error 2
make: *** Waiting for unfinished jobs....

the reason is ARCH a command-line variable,the normal assignment is
ignored.So split loongarch architecture from others.

Fixes: 4efd0de6 ("tools/perf: Add basic support for LoongArch")
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

Fix patch "LoongArch: Add PCI controller support"
Signed-off-by: NTianli Xiong <xiongtianli@loongson.cn>
Change-Id: If6084f05cc42ac33b44a7b6aeabdd1366a0bccdd

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

According to PCI-to-PCI bridge spec, bit 3 of Bridge Control Register
is VGA Enable bit which modifies the response by the bridge to VGA
compatible addresses.

The Bridge Control register provides extensions to the Command register
that are specific to a bridge. The Bridge Control register provides
many of the same controls for the secondary interface that are provided
by the Command register for the primary interface. There are some bits
that affect the operation of both interfaces of the bridge.

If the VGA Enable bit is set, the bridge will positively decode
and forward the following accesses on the primary interface to
the secondary interface (and, conversely, block the forwarding
of these addresses from the secondary to primary interface)

Forwarding of these accesses is qualified by the I/O Enable and
Memory Enable bits in the Command register.) The default state of
this bit after reset must be 0.

Bit 3 of Bridge Control Register is VGA Enable bit which modifies the
response by the bridge to VGA compatible addresses.

 when 0: do not forward VGA compatible memory and I/O addresses from
         the primary to secondary interface (addresses defined below)
         unless they are enabled for forwarding by the defined I/O
 when 1: forward VGA compatible memory and I/O addresses (addresses
         defined below) from the primary interface to the secondary
		 interface (if the I/O Enable and Memory Enable bits are set)
         independent of the I/O and memory address ranges and
         independent of the ISA Enable bit

 * memory accesses in the range 000A 0000h to 000B FFFFh

 * I/O addresses in the first 64 KB of the I/O address space
   (AD[31:16] are 0000h) where AD[9:: 0] are in the ranges
   3B0h to 3BBh and 3C0h to 3DFh (inclusive of ISA address
   aliases - AD[15::10] are not decoded)

If the VGA Enable bit is set, forwarding of these accesses is
independent of the I/O address range and memory address ranges
defined by the I/O Base and Limit registers, the Memory Base
and Limit registers, and the Prefetchable Memory Base and Limit
registers of the bridge.

Forwarding of these accesses is also independent of the settings
of the ISA Enable bit (in the Bridge Control register) or VGA
Palette Snoop bits (in the Command register).

The AST2500 hardward we are using do not set the VGA Enable bit on
its bridge control reg, this cause vgaarb subsystem don't think the
VGA card behind this pridge as a valid boot vga device which made
X server choose wrong video card to use when multiple video card
present in the system.

Its seems more vgaarb's fault than the ast2500 bmc itself.
even through bit 3 of Bridge Control Register is 0, it should still
allow to forward the accesses when the addresses is in the range of
IO/MEM Base and Limit registers.

Nevertheless, in order to support loongson CPU product line, we
provide a workaround to this bug for the Sugon L620-G30 and Sugon
L820-G30 server.

see similar bug:

https://patchwork.kernel.org/project/linux-pci/patch/20170619023528.11532-1-dja@axtens.net/Signed-off-by: Nsuijingfeng <suijingfeng@loongson.cn>
Change-Id: I53b6dee11c17b06866bdd927ac82cd6db88e16aa

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

Add window to solve GPU access error
Signed-off-by: NBaoqi Zhang <zhangbaoqi@loongson.cn>
Change-Id: Idb607fa22e68e06fc4448af57247bd4e51616a7d

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

--------------------------------
Signed-off-by: NJianmin Lv <lvjianmin@loongson.cn>
Change-Id: Ie2c78cc46aa7bde00395906f7e6ab6a09e09a190

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

Fix some pcie card not scanning properly when
bus number is inconsistent during firmware and
kernel scan phases.
Signed-off-by: Nliuyun <liuyun@loongson.cn>
Signed-off-by: NTianli Xiong <xiongtianli@loongson.cn>
Change-Id: Iac9c07463569ca08da93ab0fa279b1880206e816

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

fix kabi error caused by pm_suspend_target_state,used only
by loongson devices.
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

Don't limit mmrs during resume, so that saved value can be
restored.

Fix patch "PCI: loongson: Improve the MRRS quirk for LS7A"
Signed-off-by: NJianmin Lv <lvjianmin@loongson.cn>
Change-Id: I63c49e5c1d7e2a0a6eb3de9faa13cef1f94a4462

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

Fix patch "PCI: loongson: Use generic 8/16/32-bit
config ops on LS2K/LS7A"
Signed-off-by: NTianli Xiong <xiongtianli@loongson.cn>
Change-Id: I59f2de29370d5d9085254d8c4337f4bbcae99de0

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

Fix patch "LoongArch: Add PCI controller support"
Signed-off-by: NTianli Xiong <xiongtianli@loongson.cn>
Change-Id: I796b1224d8990fed952643adac491228d6541696

Merge Pull Request from: @Hongchen_Zhang 
 
add architecture related perf support for loongarch 
 
Link:https://gitee.com/openeuler/kernel/pulls/447 

Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Acked-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @Hongchen_Zhang 
 
Added simulation of csr devices, interrupt controller devices, mmu, 
timers, etc. in kvm under loongarch structure.
kvm-based acceleration for qemu applications on 5000 servers or 5000 
desktops with loongarch cpu

Characteristic Details: 
1) cpu 
  - Support up to 64 vcpu, support vcpu hot-plug
2) memory
  - Back-end memory supports normal huge pages and transparent huge pages
  - Support balloon 
  - Support memory hot-swap
3) Peripherals
  - Support standard interfaces PCI, SATA, SCSI, USB, virtio devices
  - Support multiple NICs, multiple disks
  - Supports hot-plug of devices
4) boot
  - Support UEFI bios boot
  - Support boot order
  - Direct kernel boot support
  - Support tpm
5) Migration
  - Support for virtual machine snapshots
  - Support for virtual machine saving and recovery
  - Support for shared storage migration
  - Support for incremental migration
  - Supports full copy migration of storage

Test passed with below step:
1、Install virt-manager
2、Install libvirt
3、Install qemu
4、Download loongarch's qcow2 file
5、Create a virtual machine on virtu-manager using the qcow2 file
6、Start the virtual machine and find that the virtual machine can run normally 
 
Link:https://gitee.com/openeuler/kernel/pulls/449 

Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> 
Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

KVM adapts to 5.10 kernel based on 4.19 kernel KVM code.
Signed-off-by: NXiangLai Li <lixianglai@loongson.cn>
Signed-off-by: NBibo Mao <maobibo@loongson.cn>

Change-Id: Iea4333d8e0905ab5c04c725defd0e4c421bfe916

mainline inclusion
from mainline-v6.1
commit 143d64bd
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP
CVE: NA

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

From upstream commit 143d64bd

Function smp_send_reschedule() is standard kernel API, which is defined
in header file include/linux/smp.h. However, on LoongArch it is defined
as an inline function, this is confusing and kernel modules can not use
this function.

Now we define smp_send_reschedule() as a general function, and add a
EXPORT_SYMBOL_GPL on this function, so that kernel modules can use it.
Signed-off-by: NBibo Mao <maobibo@loongson.cn>
Signed-off-by: NHuacai Chen <chenhuacai@loongson.cn>
Change-Id: Iafc643ec9282b60ad211f86d66804f30f9932304

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BWFP

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

add initial kvm support.
Signed-off-by: Nqemudev <qemudev@loongson.cn>
Change-Id: I1f6d361dd54299d97748a360686171e2c34a203c

Merge Pull Request from: @Hongchen_Zhang 
 
1. when compile for arm platform using make allmodconfig,compile error occurred at drivers/gpu/drm/loongson/lsdc_i2c.o.
So we add the required io.h to make it fine.
2. fix drivers/vfio/pci/vfio_pci_rdwr.c compile error on LoongArch by change the 
  definition of iounmap. 
 
Link:https://gitee.com/openeuler/kernel/pulls/466 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

LoongArch inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6LL93

----------------------------------------
1. when compiling at arm32 using make allmodconfig,error occurred
  caused by no including the required header file, so force to
  include the required file.
2. fix drivers/vfio/pci/vfio_pci_rdwr.c compile error on LoongArch
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>