aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-11-02amdgpu: Add mmhub MGCG and MGLS for vangoghJinzhou.Su1-0/+2
Add AMD_CG_SUPPORT_MC_MGCG and AMD_CG_SUPPORT_MC_LS Signed-off-by: Jinzhou.Su <[email protected]> Reviewed-by: Huang Rui <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Tune min clk values for MPO for RVPratik Vishwakarma1-3/+27
[Why] Incorrect values were resulting in flash lines when MPO was enabled and system was left idle. [How] Increase min clk values only when MPO is enabled and display is active to not affect S3 power. Signed-off-by: Pratik Vishwakarma <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amdgpu: disable gfxoff if VCN is busyJiansong Chen1-1/+4
Toggle on/off gfxoff during video playback to fix gpu hang. v2: change sequence to be more compatible with original code. Signed-off-by: Jiansong Chen <[email protected]> Reviewed-by: James Zhu <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: fix recout calculation for left side clipDmytro Laktyushkin1-0/+4
Recout calculation does not corrrectly handle plane clip rect that extends beyond the left most border of stream source rect. This change adds handling by truncating the invisible clip rect. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Hersen Wu <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: 3.2.110Aric Cyr1-1/+1
Signed-off-by: Aric Cyr <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: [FW Promotion] Release 0.0.40Anthony Koo1-2/+9
[Header Changes] - Add command for retrieving PSR residency - Add command for forcing PSR static Signed-off-by: Anthony Koo <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Add missing pflip irqBhawanpreet Lakha1-2/+2
If we have more than 4 displays we will run into dummy irq calls or flip timout issues. Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Charlene Liu <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: set hdcp1 wa re-auth delay to 200msJake Wang1-1/+1
[Why] Fail and restart timing for HDCP1 retry occurs too quickly. This would cause some MST monitors to show black screen. [How] Adjusted timing of fail and restart to 200ms. Signed-off-by: Jake Wang <[email protected]> Reviewed-by: Wenjing Liu <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Revert HUBP blank behaviour for nowJoshua Aberback2-26/+3
[Why] Commit "Blank HUBP during pixel data blank for DCN30 v2" modifies HW behaviour during blank, which might have OS dependencies. We need to assess the impact on amdgpu_dm and only re-enable HUBP blanking when all necessary changes are understood. [How] - revert functional changes - leave architectural changes intact Signed-off-by: Joshua Aberback <[email protected]> Reviewed-by: Jun Lei <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: WA to ensure MUX chip gets SUPPORTED_LINK_RATES of eDPDale Zhao1-0/+10
[Why] Customer make a request to add this WA by driver. Some MUX chips will power down with eDP 1.4 panel and lose previous supported link rates(DPCD 0x010) in customer's hybrid-GPU designs. As a result, during sleep resuming and screen turns on from idle, link training will be performed incorrectly and eDP will flicker or black screen. These MUX chips need source to read DPCD 0x010 again during LKT so that it can restore supported link rates of panel. For driver side, supported link rate set is fetched when link detection, no need to update but just read again as WA. [How] Read DPCD 0x010 again during link training for eDP 1.4. Signed-off-by: Dale Zhao <[email protected]> Reviewed-by: Wenjing Liu <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Calculate CRC on specific frame regionWayne Lin3-3/+15
[why] Currently, we only support calculating CRC on whole frame. We want to extend the capability to calculate CRC on specific frame area. [how] Calculate CRC on specific area once it's specified from the input parameter. Signed-off-by: Wayne Lin <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Do not warn NULL dc_sink if forcing connectorVictor Lu1-1/+2
[why] There is a DRM_ERROR when the dc_sink is NULL and there should not be this warning when the connector is forced. [how] Do not warn if dc_sink is NULL if the connector is forced. Signed-off-by: Victor Lu <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Blank HUBP during pixel data blank for DCN30 v2Joshua Aberback9-108/+100
[Why] Prior commit "Blank HUBP during pixel data blank for DCN30" missed the call to set_disp_pattern_generator from set_crtc_test_pattern, which re-exposed the issue for which we initially blocked active-only p-state switching. [How] - remove dcn30_blank_pixel_data, set dcn30 back to dcn20 version - new hwss funciton set_disp_pattern_generator - dcn20 version just calls opp_set_disp_pattern_generator - dcn30 version implements the HUBP blank Signed-off-by: Joshua Aberback <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Reset flip_immediate to topmost planeAlvin Lee1-0/+3
[Why] When checking if we want to disable GSL or not, we should reset flip_immediate to be the flip type of the topmost plane before looping through the other planes. [How] Set flip_immediate to be the flip type of the topmost plane before looping through the other planes. Signed-off-by: Alvin Lee <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Update connector on DSC property changeEryk Brol3-1/+130
[Why] We want to trigger atomic check on connector when DSC debugfs properties are changed. The previous method was reverted because it accessed connector properties unsafely and would also heavily impact performance. [How] Add a flag for forcing DSC update in CRTC state and add connector to the state if the flag is set. Signed-off-by: Eryk Brol <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: correct eDP T9 delayHugo Hu3-13/+17
[Why] The current end of T9 delay is relay on polling sink status by DPCD. But the polling for sink status change after NoVideoStream_flag set to 0. [How] Add function edp_add_delay_for_T9 to add T9 delay. Move the sink status polling after blank. Signed-off-by: Hugo Hu <[email protected]> Reviewed-by: Charlene Liu <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Add OPTC memory low power supportJacky Liao4-10/+32
[Why] The OPTC memory blocks should be powered down when they are not in use. This will reduce power consumption. [How] 1. Set ODM_MEM_UNASSIGNED_PWR_MODE to shutdown memory when unassigned 2. Set ODM_MEM_VBLANK_PWR_MODE to light sleep mode when in vblank 3. Added a debug option to allow this behaviour to be turned off 4. Restructured debug options to use a bitfield in a way that's more clear Signed-off-by: Jacky Liao <[email protected]> Reviewed-by: Eric Yang <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Update panel registerChris Park1-1/+1
[Why] Incorrect panel register settings are applied for power sequence because the register macro is not defined in resource. [How] Implement same register space to future resource files. Signed-off-by: Chris Park <[email protected]> Reviewed-by: Joshua Aberback <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: fail instead of div by zero/bugcheckAshley Thomas3-0/+7
[why] If pbn_per_slot is 0, fail instead of dividing by zero and bugchecking. [how] Check for zero divisor before division operation. Signed-off-by: Ashley Thomas <[email protected]> Reviewed-by: Wyatt Wood <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: 3.2.109Aric Cyr1-1/+1
Signed-off-by: Aric Cyr <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Blank HUBP during pixel data blank for DCN30Joshua Aberback4-2/+87
[Why] There are some timings for which we support p-state switching in active, but not in blank. There was a previous issue where a timing that had active-only support would hang a p-state request when we were in an extended blanking period. The workaround for that issue was to block active-only p-state switching, but that resulted in a lack of p-state support for some common timings such as 1440p60. We want to fix that issue properly by un-blocking p-state requests while the display is blanked, so that we can re-enable active-only p-state switching. [How] - new version of blank_pixel_data for DCN30 - call hubp->set_blank from dcn30_blank_pixel_data - blank every hubp in the mpcc tree, and odm tree - on blank enable, wait until the next frame before blanking HUBP Signed-off-by: Joshua Aberback <[email protected]> Reviewed-by: Jun Lei <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: stop top_mgr when type change to non-MST during s3Lewis Huang1-0/+8
[Why] Driver keeps the invalid information cause report the incorrect monitor which save in remote sink to OS [How] When connector type change from MST to non-MST, stop the topology manager. Signed-off-by: Lewis Huang <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: [FW Promotion] Release 0.0.39Anthony Koo1-2/+2
Signed-off-by: Anthony Koo <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Keep GSL for full updates with planes that flip VSYNCAlvin Lee1-0/+19
[Why] When enabling PIP in Heaven, the PIP planes are VSYNC flip and is also the top-most pipe. In this case GSL will be disabled because we only check immediate flip for the top pipe. However, the desktop planes are still flip immediate so we should at least keep GSL on until the full update. [How] Check each pipe in the tree to see if any planes are flip immediate. Maintain the GSL lock if yes, and take it down after when unlocking if any planes are flipping VSYNC. Keeping GSL on with VSYNC + flip immediate planes causes corruption. Signed-off-by: Alvin Lee <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Force prefetch mode to 0Isabel Zhang1-1/+3
[Why] On APU should be always using prefetch mode 0. Currently, sometimes prefetch mode 1 is being used causing system to hard hang due to minTTUVBlank being too low. [How] Any ASIC running DCN21 will by default allow self refresh and mclk switch. This sets both min and max prefetch mode to 0 by default. Signed-off-by: Isabel Zhang <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: only check available pipe to disable vbios mode.Yongqiang Sun1-1/+5
[Why & How] 1. only need to check first ODM pipe. 2. Only need to check eDP which is on. Signed-off-by: Yongqiang Sun <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Add MPC memory shutdown support for DCN3Jacky Liao3-3/+63
[Why] The MPC memory blocks in DCN3 should be powered down completely when they are not in use. This will reduce power consumption. [How] This commits changes behaviour for dcn3 and does the following: 1. Write to MPC_RMU<X>_LOW_PWR_MODE and MPCC_OGAM_MEM_LOW_PWR_MODE to automatically shut down memory when not in use 2. mpc3_power_on_shaper_3dlut and mpc3_power_on_ogam_lut are called to disable force power on when configuration finishes 3. Added a debug option to allow this behaviour to be turned off Signed-off-by: Jacky Liao <[email protected]> Reviewed-by: Jun Lei <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02drm/amd/display: Fix compilation errorTao.Huang3-6/+6
[Why] The C standard does not specify whether an enum is signed or unsigned. In the function prototype, one of the argument is defined as an enum but its declaration was unit32_t. Fix this by changing the function argument to enum in the declaration. Signed-off-by: Tao.Huang <[email protected]> Signed-off-by: Florin Iucha <[email protected]> Reviewed-by: Dmytro Laktyushkin <[email protected]> Acked-by: Qingqing Zhuo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-11-02kernel/hung_task.c: make type annotations consistentLukas Bulwahn1-2/+1
Commit 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler") removed various __user annotations from function signatures as part of its refactoring. It also removed the __user annotation for proc_dohung_task_timeout_secs() at its declaration in sched/sysctl.h, but not at its definition in kernel/hung_task.c. Hence, sparse complains: kernel/hung_task.c:271:5: error: symbol 'proc_dohung_task_timeout_secs' redeclared with different type (incompatible argument 3 (different address spaces)) Adjust the annotation at the definition fitting to that refactoring to make sparse happy again, which also resolves this warning from sparse: kernel/hung_task.c:277:52: warning: incorrect type in argument 3 (different address spaces) kernel/hung_task.c:277:52: expected void * kernel/hung_task.c:277:52: got void [noderef] __user *buffer No functional change. No change in object code. Signed-off-by: Lukas Bulwahn <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Tetsuo Handa <[email protected]> Cc: Al Viro <[email protected]> Cc: Andrey Ignatov <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02epoll: add a selftest for epoll timeout raceSoheil Hassas Yeganeh1-0/+95
Add a test case to ensure an event is observed by at least one poller when an epoll timeout is used. Signed-off-by: Guantao Liu <[email protected]> Signed-off-by: Soheil Hassas Yeganeh <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: Khazhismel Kumykov <[email protected]> Acked-by: Willem de Bruijn <[email protected]> Cc: Al Viro <[email protected]> Cc: Davidlohr Bueso <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02mm: always have io_remap_pfn_range() set pgprot_decrypted()Jason Gunthorpe2-4/+9
The purpose of io_remap_pfn_range() is to map IO memory, such as a memory mapped IO exposed through a PCI BAR. IO devices do not understand encryption, so this memory must always be decrypted. Automatically call pgprot_decrypted() as part of the generic implementation. This fixes a bug where enabling AMD SME causes subsystems, such as RDMA, using io_remap_pfn_range() to expose BAR pages to user space to fail. The CPU will encrypt access to those BAR pages instead of passing unencrypted IO directly to the device. Places not mapping IO should use remap_pfn_range(). Fixes: aca20d546214 ("x86/mm: Add support to make use of Secure Memory Encryption") Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Tom Lendacky <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brijesh Singh <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: "Dave Young" <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Larry Woodman <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Toshimitsu Kani <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02mm, oom: keep oom_adj under or at upper limit when printingCharles Haithcock1-0/+2
For oom_score_adj values in the range [942,999], the current calculations will print 16 for oom_adj. This patch simply limits the output so output is inline with docs. Signed-off-by: Charles Haithcock <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Alexey Dobriyan <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02kthread_worker: prevent queuing delayed work from timer_fn when it is being ↵Zqiang1-1/+2
canceled There is a small race window when a delayed work is being canceled and the work still might be queued from the timer_fn: CPU0 CPU1 kthread_cancel_delayed_work_sync() __kthread_cancel_work_sync() __kthread_cancel_work() work->canceling++; kthread_delayed_work_timer_fn() kthread_insert_work(); BUG: kthread_insert_work() should not get called when work->canceling is set. Signed-off-by: Zqiang <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Acked-by: Tejun Heo <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02mm/truncate.c: make __invalidate_mapping_pages() staticJason Yan1-1/+1
Fix the following sparse warning: mm/truncate.c:531:15: warning: symbol '__invalidate_mapping_pages' was not declared. Should it be static? Fixes: eb1d7a65f08a ("mm, fadvise: improve the expensive remote LRU cache draining after FADV_DONTNEED") Signed-off-by: Jason Yan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Yafang Shao <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02lib/crc32test: remove extra local_irq_disable/enableVasily Gorbik1-4/+0
Commit 4d004099a668 ("lockdep: Fix lockdep recursion") uncovered the following issue in lib/crc32test reported on s390: BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1 caller is lockdep_hardirqs_on_prepare+0x48/0x270 CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.9.0-next-20201015-15164-g03d992bd2de6 #19 Hardware name: IBM 3906 M04 704 (LPAR) Call Trace: lockdep_hardirqs_on_prepare+0x48/0x270 trace_hardirqs_on+0x9c/0x1b8 crc32_test.isra.0+0x170/0x1c0 crc32test_init+0x1c/0x40 do_one_initcall+0x40/0x130 do_initcalls+0x126/0x150 kernel_init_freeable+0x1f6/0x230 kernel_init+0x22/0x150 ret_from_fork+0x24/0x2c no locks held by swapper/0/1. Remove extra local_irq_disable/local_irq_enable helpers calls. Fixes: 5fb7f87408f1 ("lib: add module support to crc32 tests") Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Link: https://lkml.kernel.org/r/patch.git-4369da00c06e.your-ad-here.call-01602859837-ext-1679@work.hours Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02ptrace: fix task_join_group_stop() for the case when current is tracedOleg Nesterov1-9/+10
This testcase #include <stdio.h> #include <unistd.h> #include <signal.h> #include <sys/ptrace.h> #include <sys/wait.h> #include <pthread.h> #include <assert.h> void *tf(void *arg) { return NULL; } int main(void) { int pid = fork(); if (!pid) { kill(getpid(), SIGSTOP); pthread_t th; pthread_create(&th, NULL, tf, NULL); return 0; } waitpid(pid, NULL, WSTOPPED); ptrace(PTRACE_SEIZE, pid, 0, PTRACE_O_TRACECLONE); waitpid(pid, NULL, 0); ptrace(PTRACE_CONT, pid, 0,0); waitpid(pid, NULL, 0); int status; int thread = waitpid(-1, &status, 0); assert(thread > 0 && thread != pid); assert(status == 0x80137f); return 0; } fails and triggers WARN_ON_ONCE(!signr) in do_jobctl_trap(). This is because task_join_group_stop() has 2 problems when current is traced: 1. We can't rely on the "JOBCTL_STOP_PENDING" check, a stopped tracee can be woken up by debugger and it can clone another thread which should join the group-stop. We need to check group_stop_count || SIGNAL_STOP_STOPPED. 2. If SIGNAL_STOP_STOPPED is already set, we should not increment sig->group_stop_count and add JOBCTL_STOP_CONSUME. The new thread should stop without another do_notify_parent_cldstop() report. To clarify, the problem is very old and we should blame ptrace_init_task(). But now that we have task_join_group_stop() it makes more sense to fix this helper to avoid the code duplication. Reported-by: [email protected] Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Christian Brauner <[email protected]> Cc: "Eric W . Biederman" <[email protected]> Cc: Zhiqiang Liu <[email protected]> Cc: Tejun Heo <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02mm: mempolicy: fix potential pte_unmap_unlock pte errorShijie Luo1-3/+3
When flags in queue_pages_pte_range don't have MPOL_MF_MOVE or MPOL_MF_MOVE_ALL bits, code breaks and passing origin pte - 1 to pte_unmap_unlock seems like not a good idea. queue_pages_pte_range can run in MPOL_MF_MOVE_ALL mode which doesn't migrate misplaced pages but returns with EIO when encountering such a page. Since commit a7f40cfe3b7a ("mm: mempolicy: make mbind() return -EIO when MPOL_MF_STRICT is specified") and early break on the first pte in the range results in pte_unmap_unlock on an underflow pte. This can lead to lockups later on when somebody tries to lock the pte resp. page_table_lock again.. Fixes: a7f40cfe3b7a ("mm: mempolicy: make mbind() return -EIO when MPOL_MF_STRICT is specified") Signed-off-by: Shijie Luo <[email protected]> Signed-off-by: Miaohe Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Oscar Salvador <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Miaohe Lin <[email protected]> Cc: Feilong Lin <[email protected]> Cc: Shijie Luo <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02kasan: adopt KUNIT tests to SW_TAGS modeAndrey Konovalov1-42/+107
Now that we have KASAN-KUNIT tests integration, it's easy to see that some KASAN tests are not adopted to the SW_TAGS mode and are failing. Adjust the allocation size for kasan_memchr() and kasan_memcmp() by roung it up to OOB_TAG_OFF so the bad access ends up in a separate memory granule. Add a new kmalloc_uaf_16() tests that relies on UAF, and a new kasan_bitops_tags() test that is tailored to tag-based mode, as it's hard to adopt the existing kmalloc_oob_16() and kasan_bitops_generic() (renamed from kasan_bitops()) without losing the precision. Add new kmalloc_uaf_16() and kasan_bitops_uaf() tests that rely on UAFs, as it's hard to adopt the existing kmalloc_oob_16() and kasan_bitops_oob() (rename from kasan_bitops()) without losing the precision. Disable kasan_global_oob() and kasan_alloca_oob_left/right() as SW_TAGS mode doesn't instrument globals nor dynamic allocas. Signed-off-by: Andrey Konovalov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Tested-by: David Gow <[email protected]> Link: https://lkml.kernel.org/r/76eee17b6531ca8b3ca92b240cb2fd23204aaff7.1603129942.git.andreyknvl@google.com Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02mm: memcg: link page counters to root if use_hierarchy is falseRoman Gushchin1-5/+10
Richard reported a warning which can be reproduced by running the LTP madvise6 test (cgroup v1 in the non-hierarchical mode should be used): WARNING: CPU: 0 PID: 12 at mm/page_counter.c:57 page_counter_uncharge (mm/page_counter.c:57 mm/page_counter.c:50 mm/page_counter.c:156) Modules linked in: CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.9.0-rc7-22-default #77 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812d-rebuilt.opensuse.org 04/01/2014 Workqueue: events drain_local_stock RIP: 0010:page_counter_uncharge (mm/page_counter.c:57 mm/page_counter.c:50 mm/page_counter.c:156) Call Trace: __memcg_kmem_uncharge (mm/memcontrol.c:3022) drain_obj_stock (./include/linux/rcupdate.h:689 mm/memcontrol.c:3114) drain_local_stock (mm/memcontrol.c:2255) process_one_work (./arch/x86/include/asm/jump_label.h:25 ./include/linux/jump_label.h:200 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2274) worker_thread (./include/linux/list.h:282 kernel/workqueue.c:2416) kthread (kernel/kthread.c:292) ret_from_fork (arch/x86/entry/entry_64.S:300) The problem occurs because in the non-hierarchical mode non-root page counters are not linked to root page counters, so the charge is not propagated to the root memory cgroup. After the removal of the original memory cgroup and reparenting of the object cgroup, the root cgroup might be uncharged by draining a objcg stock, for example. It leads to an eventual underflow of the charge and triggers a warning. Fix it by linking all page counters to corresponding root page counters in the non-hierarchical mode. Please note, that in the non-hierarchical mode all objcgs are always reparented to the root memory cgroup, even if the hierarchy has more than 1 level. This patch doesn't change it. The patch also doesn't affect how the hierarchical mode is working, which is the only sane and truly supported mode now. Thanks to Richard for reporting, debugging and providing an alternative version of the fix! Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") Reported-by: <[email protected]> Signed-off-by: Roman Gushchin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Shakeel Butt <[email protected]> Reviewed-by: Michal Koutný <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Debugged-by: Richard Palethorpe <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02mm: memcontrol: correct the NR_ANON_THPS counter of hierarchical memcgzhongjiang-ali1-2/+8
memcg_page_state will get the specified number in hierarchical memcg, It should multiply by HPAGE_PMD_NR rather than an page if the item is NR_ANON_THPS. [[email protected]: fix printk warning] [[email protected]: use u64 cast, per Michal] Fixes: 468c398233da ("mm: memcontrol: switch to native NR_ANON_THPS counter") Signed-off-by: zhongjiang-ali <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Johannes Weiner <[email protected]> Acked-by: Michal Hocko <[email protected]> Link: https://lkml.kernel.org/r/1603722395-72443-1-git-send-email-zhongjiang-ali@linux.alibaba.com Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02hugetlb_cgroup: fix reservation accountingMike Kravetz1-9/+11
Michal Privoznik was using "free page reporting" in QEMU/virtio-balloon with hugetlbfs and hit the warning below. QEMU with free page hinting uses fallocate(FALLOC_FL_PUNCH_HOLE) to discard pages that are reported as free by a VM. The reporting granularity is in pageblock granularity. So when the guest reports 2M chunks, we fallocate(FALLOC_FL_PUNCH_HOLE) one huge page in QEMU. WARNING: CPU: 7 PID: 6636 at mm/page_counter.c:57 page_counter_uncharge+0x4b/0x50 Modules linked in: ... CPU: 7 PID: 6636 Comm: qemu-system-x86 Not tainted 5.9.0 #137 Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS PRO/X570 AORUS PRO, BIOS F21 07/31/2020 RIP: 0010:page_counter_uncharge+0x4b/0x50 ... Call Trace: hugetlb_cgroup_uncharge_file_region+0x4b/0x80 region_del+0x1d3/0x300 hugetlb_unreserve_pages+0x39/0xb0 remove_inode_hugepages+0x1a8/0x3d0 hugetlbfs_fallocate+0x3c4/0x5c0 vfs_fallocate+0x146/0x290 __x64_sys_fallocate+0x3e/0x70 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Investigation of the issue uncovered bugs in hugetlb cgroup reservation accounting. This patch addresses the found issues. Fixes: 075a61d07a8e ("hugetlb_cgroup: add accounting for shared mappings") Reported-by: Michal Privoznik <[email protected]> Co-developed-by: David Hildenbrand <[email protected]> Signed-off-by: David Hildenbrand <[email protected]> Signed-off-by: Mike Kravetz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Tested-by: Michal Privoznik <[email protected]> Reviewed-by: Mina Almasry <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Cc: <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Muchun Song <[email protected]> Cc: "Aneesh Kumar K . V" <[email protected]> Cc: Tejun Heo <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02mm/mremap_pages: fix static key devmap_managed_key updatesRalph Campbell1-23/+16
commit 6f42193fd86e ("memremap: don't use a separate devm action for devmap_managed_enable_get") changed the static key updates such that we now call devmap_managed_enable_put() without doing the equivalent devmap_managed_enable_get(). devmap_managed_enable_get() is only called for MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_FS_DAX, But memunmap_pages() get called for other pgmap types too. This results in the below warning when switching between system-ram and devdax mode for devdax namespace. jump label: negative count! WARNING: CPU: 52 PID: 1335 at kernel/jump_label.c:235 static_key_slow_try_dec+0x88/0xa0 Modules linked in: .... NIP static_key_slow_try_dec+0x88/0xa0 LR static_key_slow_try_dec+0x84/0xa0 Call Trace: static_key_slow_try_dec+0x84/0xa0 __static_key_slow_dec_cpuslocked+0x34/0xd0 static_key_slow_dec+0x54/0xf0 memunmap_pages+0x36c/0x500 devm_action_release+0x30/0x50 release_nodes+0x2f4/0x3e0 device_release_driver_internal+0x17c/0x280 bus_remove_device+0x124/0x210 device_del+0x1d4/0x530 unregister_dev_dax+0x48/0xe0 devm_action_release+0x30/0x50 release_nodes+0x2f4/0x3e0 device_release_driver_internal+0x17c/0x280 unbind_store+0x130/0x170 drv_attr_store+0x40/0x60 sysfs_kf_write+0x6c/0xb0 kernfs_fop_write+0x118/0x280 vfs_write+0xe8/0x2a0 ksys_write+0x84/0x140 system_call_exception+0x120/0x270 system_call_common+0xf0/0x27c Reported-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Ralph Campbell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Tested-by: Sachin Sant <[email protected]> Reviewed-by: Aneesh Kumar K.V <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Cc: Dan Williams <[email protected]> Cc: Jason Gunthorpe <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-11-02ARC: [plat-hsdk] Remap CCMs super early in asm boot trampolineVineet Gupta2-18/+16
ARC HSDK platform stopped booting on released v5.10-rc1, getting stuck in startup of non master SMP cores. This was bisected to upstream commit 7fef431be9c9ac25 "(mm/page_alloc: place pages to tail in __free_pages_core())" That commit itself is harmless, it just exposed a subtle assumption in our platform code (hence CC'ing linux-mm just as FYI in case some other arches / platforms trip on it). The upstream commit is semantically disruptive as it reverses the order of page allocations (actually it can be good test for hardware verification to exercise different memory patterns altogether). For ARC HSDK platform that meant a remapped memory region (pertaining to unused Closely Coupled Memory) started getting used early for dynamice allocations, while not effectively remapped on all the cores, triggering memory error exception on those cores. The fix is to move the CCM remapping from early platform code to to early core boot code. And while it is undesirable to riddle common boot code with platform quirks, there is no other way to do this since the faltering code involves setting up stack itself so even function calls are not allowed at that point. If anyone is interested, all the gory details can be found at Link below. Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/32 Cc: David Hildenbrand <[email protected]> Cc: [email protected] Signed-off-by: Vineet Gupta <[email protected]>
2020-11-02ARC: stack unwinding: avoid indefinite loopingVineet Gupta1-1/+6
Currently stack unwinder is a while(1) loop which relies on the dwarf unwinder to signal termination, which in turn relies on dwarf info to do so. This in theory could cause an infinite loop if the dwarf info was somehow messed up or the register contents were etc. This fix thus detects the excessive looping and breaks the loop. | Mem: 26184K used, 1009136K free, 0K shrd, 0K buff, 14416K cached | CPU: 0.0% usr 72.8% sys 0.0% nic 27.1% idle 0.0% io 0.0% irq 0.0% sirq | Load average: 4.33 2.60 1.11 2/74 139 | PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND | 133 2 root SWN 0 0.0 3 22.9 [rcu_torture_rea] | 132 2 root SWN 0 0.0 0 22.0 [rcu_torture_rea] | 131 2 root SWN 0 0.0 3 21.5 [rcu_torture_rea] | 126 2 root RW 0 0.0 2 5.4 [rcu_torture_wri] | 129 2 root SWN 0 0.0 0 0.2 [rcu_torture_fak] | 137 2 root SW 0 0.0 0 0.2 [rcu_torture_cbf] | 127 2 root SWN 0 0.0 0 0.1 [rcu_torture_fak] | 138 115 root R 1464 0.1 2 0.1 top | 130 2 root SWN 0 0.0 0 0.1 [rcu_torture_fak] | 128 2 root SWN 0 0.0 0 0.1 [rcu_torture_fak] | 115 1 root S 1472 0.1 1 0.0 -/bin/sh | 104 1 root S 1464 0.1 0 0.0 inetd | 1 0 root S 1456 0.1 2 0.0 init | 78 1 root S 1456 0.1 0 0.0 syslogd -O /var/log/messages | 134 2 root SW 0 0.0 2 0.0 [rcu_torture_sta] | 10 2 root IW 0 0.0 1 0.0 [rcu_preempt] | 88 2 root IW 0 0.0 1 0.0 [kworker/1:1-eve] | 66 2 root IW 0 0.0 2 0.0 [kworker/2:2-eve] | 39 2 root IW 0 0.0 2 0.0 [kworker/2:1-eve] | unwinder looping too long, aborting ! Cc: <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
2020-11-02IB/srpt: Fix memory leak in srpt_add_oneMaor Gottlieb1-5/+8
Failure in srpt_refresh_port() for the second port will leave MAD registered for the first one, however, the srpt_add_one() will be marked as "failed" and SRPT will leak resources for that registered but not used and released first port. Unregister the MAD agent for all ports in case of failure. Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maor Gottlieb <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-11-02Merge branch 'dpaa_eth-buffer-layout-fixes'Jakub Kicinski1-10/+18
Camelia Groza says: ==================== dpaa_eth: buffer layout fixes The patches are related to the software workaround for the A050385 erratum. The first patch ensures optimal buffer usage for non-erratum scenarios. The second patch fixes a currently inconsequential discrepancy between the FMan and Ethernet drivers. Changes in v3: - refactor defines for clarity in 1/2 - add more details on the user impact in 1/2 - remove unnecessary inline identifier in 2/2 Changes in v2: - make the returned value for TX ports explicit in 2/2 - simplify the buf_layout reference in 2/2 ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-02dpaa_eth: fix the RX headroom size alignmentCamelia Groza1-5/+9
The headroom reserved for received frames needs to be aligned to an RX specific value. There is currently a discrepancy between the values used in the Ethernet driver and the values passed to the FMan. Coincidentally, the resulting aligned values are identical. Fixes: 3c68b8fffb48 ("dpaa_eth: FMan erratum A050385 workaround") Acked-by: Willem de Bruijn <[email protected]> Signed-off-by: Camelia Groza <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-02dpaa_eth: update the buffer layout for non-A050385 erratum scenariosCamelia Groza1-6/+10
Impose a larger RX private data area only when the A050385 erratum is present on the hardware. A smaller buffer size is sufficient in all other scenarios. This enables a wider range of linear Jumbo frame sizes in non-erratum scenarios, instead of turning to multi buffer Scatter/Gather frames. The maximum linear frame size is increased by 128 bytes for non-erratum arm64 platforms. Cleanup the hardware annotations header defines in the process. Fixes: 3c68b8fffb48 ("dpaa_eth: FMan erratum A050385 workaround") Signed-off-by: Camelia Groza <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-02RDMA: Fix software RDMA drivers for dma mapping errorParav Pandit3-5/+15
The commit f959dcd6ddfd ("dma-direct: Fix potential NULL pointer dereference") made dma_mask as mandetory field to be setup even for dma_virt_ops based dma devices. The commit in the fixes tag omitted setting up the dma_mask on virtual devices triggering the below trace when they were combined during the merge window. Fix it by setting empty DMA MASK for software based RDMA devices. WARNING: CPU: 1 PID: 8488 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x493/0x700 CPU: 1 PID: 8488 Comm: syz-executor144 Not tainted 5.9.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dma_map_page_attrs+0x493/0x700 kernel/dma/mapping.c:149 Trace: dma_map_single_attrs include/linux/dma-mapping.h:279 [inline] ib_dma_map_single include/rdma/ib_verbs.h:3967 [inline] ib_mad_post_receive_mads+0x23f/0xd60 drivers/infiniband/core/mad.c:2715 ib_mad_port_start drivers/infiniband/core/mad.c:2862 [inline] ib_mad_port_open drivers/infiniband/core/mad.c:3016 [inline] ib_mad_init_device+0x72b/0x1400 drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:680 enable_device_and_get+0x1d5/0x3c0 drivers/infiniband/core/device.c:1301 ib_register_device drivers/infiniband/core/device.c:1376 [inline] ib_register_device+0x7a7/0xa40 drivers/infiniband/core/device.c:1335 rxe_register_device+0x46d/0x570 drivers/infiniband/sw/rxe/rxe_verbs.c:1182 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:507 rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldev_newlink+0x30e/0x540 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x367/0x690 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x2f2/0x440 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x443699 Link: https://lore.kernel.org/r/[email protected] Reported-by: [email protected] Fixes: e0477b34d9d1 ("RDMA: Explicitly pass in the dma_device to ib_register_device") Signed-off-by: Parav Pandit <[email protected]> Tested-by: Guoqing Jiang <[email protected]> Tested-by: Dennis Dalessandro <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Zhu Yanjun <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-11-02Revert "nvme-pci: remove last_sq_tail"Keith Busch1-4/+19
Multiple CPUs may be mapped to the same hctx, allowing mulitple submission contexts to attempt commit_rqs(). We need to verify we're not writing the same doorbell value multiple times since that's a spec violation. Revert commit 54b2fcee1db041a83b52b51752dade6090cf952f. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1878596 Reported-by: "B.L. Jones" <[email protected]> Signed-off-by: Keith Busch <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.