[desc]:
can use cmdline in grub to:
1). custom set sleep time after device reset.
e.g. pcireset_quirk=timeout,vid1:did1=t1,vid2:did2=t2
this will set t1 second sleep after vid1:did1 device reset and so do vid2:did2
use to solve zixiao gpu reset problem.
2). return 0 directly when device reset.
e.g. pcireset_quirk=noreset,vid1:did1,vid2:did2
this will return 0 when vid1:did1 device reset and so do vid2:did2
use to solve 2080Ti & 3070 GPU reset cause ff problem.
Signed-off-by: leolingli <leolingli@tencent.com>
Signed-off-by: snailzhao <snailzhao@tencent.com>
[upstream]
7332dec0 sched/fair: Only immediately migrate tasks due to interrupts
if prev and target CPUs share cache
806486c3 sched/fair: Do not migrate if the prev_cpu is idle
082f764a sched/fair: Do not migrate on wake_affine_weight() if weights
are equal
d8fcb81f sched/fair: Check for idle core in wake_affine
Signed-off-by: yongduan <yongduan@tencent.com>
upstream: 51c48b310183ab6ba5419edfc6a8de889cc04521
pci_bridge_check_ranges() determines whether a bridge supports the optional
I/O and prefetchable memory windows and sets the flag bits in the bridge
resources. This *could* be done once during enumeration except that the
resource allocation code completely clears the flag bits, e.g., in the
pci_assign_unassigned_bridge_resources() path.
The problem with pci_bridge_check_ranges() in the resource allocation path
is that we may allocate resources after devices have been claimed by
drivers, and pci_bridge_check_ranges() *changes* the window registers to
determine whether they're writable. This may break concurrent accesses to
devices behind the bridge.
Add a new pci_read_bridge_windows() to determine whether a bridge supports
the optional windows, call it once during enumeration, remember the
results, and change pci_bridge_check_ranges() so it doesn't touch the
bridge windows but sets the flag bits based on those remembered results.
Signed-off-by: Lei Chen <lennychen@tencent.com>
In the virtualization scenario, you can use pvipi to optimize the sending of
IPI interrupts and reduce the number of vmexit.
rps_using_pvipi test
Test guest: 32 core, 64G memory, virtio-net 8 queues, rss interrupt is bound
to 24-31 core. Observe the number of vmexit of 31 cores.
1. 1000000pps
100 iperf instances, 10000pps per instance.
disable rps_using_pvipi 68077 vmexit/s
enable rps_using_pvipi 21138 vmexit/s
2. 2000000pps
1000 iperf instances, 2000pps per instance.
disable rps_using_pvipi 40879 vmexit/s
enable rps_using_pvipi 9195 vmexit/s
3. 2000000pps
2000 iperf instances, 1000pps per instance.
disable rps_using_pvipi 24746 vmexit/s
enable rps_using_pvipi 7292 vmexit/s
Enabling rps_using_pvipi can greatly reduce the number of vmexit.
Signed-off-by: yongduan <yongduan@tencent.com>
Run an asynchronous function on a many cpus.
smp_call_function_many_async_begin
for_each_csd
smp_call_function_many_async
smp_call_function_many_async_end
Signed-off-by: yongduan <yongduan@tencent.com>
reason: in ipvs_mode ==1 , skb_rtable is ip_vs_nat_xmit is null.
Test case: test bpf mode nodeport ok!
Signed-off-by: jianmingfan <jianmingfan@tencent.com>
Without preemption, if syscall excutes too long it will significantly
affect performance of other important processes. So add a shceduling
point when showing root memcg usage.
Signed-off-by: yongduan <yongduan@tencent.com>
Signed-off-by: charliecgxu <charliecgxu@tencent.com>
upstream: acf69c9
Using tp_reserve to calculate netoff can overflow as
tp_reserve is unsigned int and netoff is unsigned short.
This may lead to macoff receiving a smaller value then
sizeof(struct virtio_net_hdr), and if po->has_vnet_hdr
is set, an out-of-bounds write will occur when
calling virtio_net_hdr_from_skb.
The bug is fixed by converting netoff to unsigned int
and checking if it exceeds USHRT_MAX.
This addresses CVE-2020-14386
Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
Signed-off-by: Or Cohen <orcohen@paloaltonetworks.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Fuhai Wang <fuhaiwang@tencent.com>
commit <7062884546a14d785c9ff6152964058211436999>
This issue came up with NFSv4 as the lower layer, which generates
"system.nfs4_acl" xattrs (even for plain old unix permissions). Prior to
this patch this prevented copy-up from succeeding.
The overlayfs permission model mandates that permissions are checked
locally for the task and remotely for the mounter(*). NFS4 ACLs are not
supported by the Linux kernel currently, hence they cannot be enforced
locally. Which means it is indifferent whether this attribute is copied or
not.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
commit <ffa358dcaae1f2f00926484e712e06daa8953cb4>
commit <b78820937b4762b7d30b807d7156bec1d89e4dd3>
commit <c45e6a037a536530bd25781ac7c989e52deb2a63>
commit <38cfb5a45ee013bfab5d1ae4c4738815e744b440>
We have two potential issues:
1) After commit 2887e41b910b, we only wake one process at the time when
we finish an IO. We really want to wake up as many tasks as can
queue IO. Before this commit, we woke up everyone, which could cause
a thundering herd issue.
2) A task can potentially consume two wakeups, causing us to (in
practice) miss a wakeup.
Fix both by providing our own wakeup function, which stops
__wake_up_common() from waking up more tasks if we fail to get a
queueing token. With the strict ordering we have on the wait list, this
wakes the right tasks and the right amount of tasks.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
commit <2887e41b910bb14fd847cf01ab7a5993db989d88>
At present, wbt's wake-up mechanism for wait_queue can induce
thundering herd issue and intense lock competition. In the
context of ipi, this may induce hard lockup.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Don't pass error pointers to brelse().
commit 7159a986b420 ("ext4: fix some error pointer dereferences") has fixed
some cases, fix the remaining one case.
Once ext4_xattr_block_find()->ext4_sb_bread() failed, error pointer is
stored in @bs->bh, which will be passed to brelse() in the cleanup
routine of ext4_xattr_set_handle(). This will then cause a NULL panic
crash in __brelse().
BUG: unable to handle kernel NULL pointer dereference at 000000000000005b
RIP: 0010:__brelse+0x1b/0x50
Call Trace:
ext4_xattr_set_handle+0x163/0x5d0
ext4_xattr_set+0x95/0x110
__vfs_setxattr+0x6b/0x80
__vfs_setxattr_noperm+0x68/0x1b0
vfs_setxattr+0xa0/0xb0
setxattr+0x12c/0x1a0
path_setxattr+0x8d/0xc0
__x64_sys_setxattr+0x27/0x30
do_syscall_64+0x60/0x250
entry_SYSCALL_64_after_hwframe+0x49/0xbe
In this case, @bs->bh stores '-EIO' actually.
Fixes: fb265c9cb49e ("ext4: add ext4_sb_bread() to disambiguate ENOMEM cases")
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: stable@kernel.org # 2.6.19
Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/1587628004-95123-1-git-send-email-jefflexu@linux.alibaba.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
We have limited the length of the inode prealloc list, and here are
some optimizations for the calculation of the length of the list.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
In the scenario of writing sparse files, the Per-inode prealloc list may
be very long, resulting in high overhead for ext4_mb_use_preallocated().
To circumvent this problem, we limit the maximum length of per-inode
prealloc list to 512 and allow users to modify it.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
frankjpliu