- 31 Dec, 2021 4 commits
-
-
Alex Deucher authored
If we are the primary adapter (i.e., the one used by the firwmare framebuffer), disable runtime pm. This fixes a regression caused by commit 55285e21 which results in the displays waking up shortly after they go to sleep due to the device coming out of runtime suspend and sending a hotplug uevent. v2: squash in reworked fix from Evan Fixes: 55285e21 ("fbdev/efifb: Release PCI device's runtime PM ref during FB destroy") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215203 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1840Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
Add a function for drivers to check if the a firmware initialized fb is corresponds to their aperture. This allows drivers to check if the device corresponds to what the firmware set up as the display device. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215203 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1840Signed-off-by:
-
Evan Quan authored
To pair with the workaround which always reset the ASIC in suspend. Otherwise, the reset which relies on BACO will fail. Fixes: daf8de08 ("drm/amdgpu: always reset the asic in suspend (v2)") Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
-
ssh://git.freedesktop.org/git/drm/drm-miscDave Airlie authored
This merges two fixes that haven't been sent to me yet, but I wanted to get in. One amdgpu fix, but one nouveau regression fixer. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
- 30 Dec, 2021 2 commits
-
-
Dave Airlie authored
Merge tag 'amd-drm-fixes-5.16-2021-12-29' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.16-2021-12-29: amdgpu: - Fencing fix - XGMI fix - VCN regression fix - IP discovery regression fixes - Fix runpm documentation - Suspend/resume fixes - Yellow Carp display fixes - MCLK power management fix Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-fixes-2021-12-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v5.16: - Fix possible uninitialized variable - Fix composite fence seqno icrement on each fence creation Signed-off-by:
-
- 28 Dec, 2021 7 commits
-
-
Angus Wang authored
[WHY] Current implementation of pipe split policy prevents pipe split with multiple displays connected, which caused the MCLK speed to be stuck at max [HOW] Changed the pipe split policies so that pipe split is allowed for multi-display configurations Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1522 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1709 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1655 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1403 Note this is a backport of this commit from amdgpu drm-next for 5.16. Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
Angus Wang <angus.wang@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] A porting error on a previous patch left the block of code that causes the crash from a NULL pointer dereference. More specifically, we try to access link_enc before it's assigned in the USB4 case in the following assignment: config.dio_output_idx = link_enc->transmitter - TRANSMITTER_UNIPHY_A; [How] That assignment occurs later depending on the ASIC version. It's only needed on DCN31 and only after link_enc is already assigned. Fixes: 98643044 ("drm/amd/display: fix a crash on USB4 over C20 PHY") Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] We'll exit optimized power state to do link detection but we won't enter back into the optimized power state. This could potentially block s2idle entry depending on the sequencing, but it also means we're losing some power during the transition period. [How] Hook up the handler like DCN21. It was also missed like the exit_optimized_pwr_state callback. Fixes: 64b1d0e8 ("drm/amd/display: Add DCN3.1 HWSEQ") Tested-by:
Eric Yang <Eric.Yang2@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] Otherwise SMU won't mark Display as idle when trying to perform s2idle. [How] Mark the bit in the dcn31 codepath, doesn't apply to older ASIC. It needed to be split from phy refclk off to prevent entering s2idle when PSR was engaged but driver was not ready. Fixes: 118a3315 ("drm/amd/display: Add DCN3.1 clock manager support") Tested-by:
-
Lai, Derek authored
[Why] The change of setting a timer callback on boot for 10 seconds is still working, just lacked power down for DCN10. [How] Added power down for DCN10. Tested-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
Derek Lai <Derek.Lai@amd.com> Signed-off-by:
-
Charlene Liu authored
[why] B0 PHY C map to F, D map to G driver use logic instance, dmub does the remap. Driver still need use the right PHY instance to access right HW. [how] use phyical instance when program PHY register. [note] could move resync_control programming to dmub next. Tested-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
Charlene Liu <Charlene.Liu@amd.com> Signed-off-by:
-
Alex Deucher authored
Chips with no display hardware should return false for DC support. v2: drop Arcturus and Aldebaran Fixes: f7f12b25 ("drm/amdgpu: default to true in amdgpu_device_asic_has_dc_support") Reviewed-by:
Tareque Md.Hanif <tarequemd.hanif@yahoo.com> Signed-off-by:
-
- 27 Dec, 2021 5 commits
-
-
Evan Quan authored
By setting mp1_state as PP_MP1_STATE_UNLOAD, MP1 will do some proper cleanups and put itself into a state ready for PNP. That can workaround some random resuming failure observed on BOCO capable platforms. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Alex Deucher authored
If the platform suspend happens to fail and the power rail is not turned off, the GPU will be in an unknown state on resume, so reset the asic so that it will be in a known good state on resume even if the platform suspend failed. v2: handle s0ix Acked-by:
Luben Tuikov <luben.tuikov@amd.com> Acked-by:
-
Prike Liang authored
In the s0ix entry need retain gfx in the gfxoff state,so here need't set gfx cgpg in the S0ix suspend-resume process. Moreover move the S0ix check into SMU12 can simplify the code condition check. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1712Signed-off-by:
Prike Liang <Prike.Liang@amd.com> Reviewed-by:
-
Matthew Brost authored
Increment composite fence seqno on each fence creation. Fixes: 544460c3 ("drm/i915: Multi-BB execbuf") Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Matthew Brost authored
'prev_engine' was declared inside the output loop and checked in the inner after at least 1 pass of either loop. The variable should be declared outside both loops as it needs to be persistent across the entire loop structure. Fixes: e5e32171 ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface") Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 26 Dec, 2021 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Borislav Petkov: - Prevent potential undefined behavior due to shifting pkey constants into the sign bit - Move the EFI memory reservation code *after* the efi= cmdline parsing has happened - Revert two commits which turned out to be the wrong direction to chase when accommodating early memblock reservations consolidation and command line parameters parsing * tag 'x86_urgent_for_v5.16_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/pkey: Fix undefined behaviour with PKRU_WD_BIT x86/boot: Move EFI range reservation after cmdline parsing Revert "x86/boot: Pull up cmdline preparation and early param parsing" Revert "x86/boot: Mark prepare_command_line() __init"
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull objtool fixes from Borislav Petkov: - Prevent clang from reordering the reachable annotation in an inline asm statement without inputs - Fix objtool builds on non-glibc systems due to undefined __always_inline * tag 'objtool_urgent_for_v5.16_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: compiler.h: Fix annotation macro misplacement with Clang uapi: Fix undefined __always_inline on non-glibc systems
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrlLinus Torvalds authored
Pull pin control fixes from Linus Walleij: "Some hopefully final pin control fixes for the v5.16 kernel: - Fix an out-of-bounds bug in the Mediatek driver - Fix an init order bug in the Broadcom BCM2835 driver - Fix a GPIO offset bug in the STM32 driver" * tag 'pinctrl-v5.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: stm32: consider the GPIO offset to expose all the GPIO lines pinctrl: bcm2835: Change init order for gpio hogs pinctrl: mediatek: fix global-out-of-bounds issue
-
- 25 Dec, 2021 12 commits
-
-
Linus Torvalds authored
Merge tag 'hwmon-for-v5.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: "A couple of lm90 driver fixes. None of them are critical, but they should nevertheless be fixed" * tag 'hwmon-for-v5.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (lm90) Do not report 'busy' status bit as alarm hwmom: (lm90) Fix citical alarm status for MAX6680/MAX6681 hwmon: (lm90) Drop critical attribute support for MAX6654 hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations hwmon: (lm90) Fix usage of CONFIG2 register in detect function
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
Pull input fixes from Dmitry Torokhov: "A few small updates to drivers. Of note we are now deferring probes of i8042 on some Asus devices as the controller is not ready to respond to queries first time around when the driver is compiled into the kernel" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: elants_i2c - do not check Remark ID on eKTH3900/eKTH5312 Input: atmel_mxt_ts - fix double free in mxt_read_info_block Input: goodix - fix memory leak in goodix_firmware_upload Input: goodix - add id->model mapping for the "9111" model Input: goodix - try not to touch the reset-pin on x86/ACPI devices Input: i8042 - enable deferred probe quirk for ASUS UM325UA Input: elantech - fix stack out of bound access in elantech_change_report_id() Input: iqs626a - prohibit inlining of channel parsing functions Input: i8042 - add deferred probe support
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton: "9 patches. Subsystems affected by this patch series: mm (kfence, mempolicy, memory-failure, pagemap, pagealloc, damon, and memory-failure), core-kernel, and MAINTAINERS" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page() mm/damon/dbgfs: protect targets destructions with kdamond_lock mm/page_alloc: fix __alloc_size attribute for alloc_pages_exact_nid mm: delete unsafe BUG from page_cache_add_speculative() mm, hwpoison: fix condition in free hugetlb page path MAINTAINERS: mark more list instances as moderated kernel/crash_core: suppress unknown crashkernel parameter warning mm: mempolicy: fix THP allocations escaping mempolicy restrictions kfence: fix memory leak when cat kfence objects
-
Liu Shixin authored
Hulk Robot reported a panic in put_page_testzero() when testing madvise() with MADV_SOFT_OFFLINE. The BUG() is triggered when retrying get_any_page(). This is because we keep MF_COUNT_INCREASED flag in second try but the refcnt is not increased. page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) ------------[ cut here ]------------ kernel BUG at include/linux/mm.h:737! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 5 PID: 2135 Comm: sshd Tainted: G B 5.16.0-rc6-dirty #373 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: release_pages+0x53f/0x840 Call Trace: free_pages_and_swap_cache+0x64/0x80 tlb_flush_mmu+0x6f/0x220 unmap_page_range+0xe6c/0x12c0 unmap_single_vma+0x90/0x170 unmap_vmas+0xc4/0x180 exit_mmap+0xde/0x3a0 mmput+0xa3/0x250 do_exit+0x564/0x1470 do_group_exit+0x3b/0x100 __do_sys_exit_group+0x13/0x20 __x64_sys_exit_group+0x16/0x20 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: ---[ end trace e99579b570fe0649 ]--- RIP: 0010:release_pages+0x53f/0x840 Link: https://lkml.kernel.org/r/20211221074908.3910286-1-liushixin2@huawei.com Fixes: b94e0282 ("mm,hwpoison: try to narrow window race for free pages") Signed-off-by:Liu Shixin <liushixin2@huawei.com> Reported-by:
Hulk Robot <hulkci@huawei.com> Reviewed-by:
Oscar Salvador <osalvador@suse.de> Acked-by:
Naoya Horiguchi <naoya.horiguchi@nec.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
SeongJae Park authored
DAMON debugfs interface iterates current monitoring targets in 'dbgfs_target_ids_read()' while holding the corresponding 'kdamond_lock'. However, it also destructs the monitoring targets in 'dbgfs_before_terminate()' without holding the lock. This can result in a use_after_free bug. This commit avoids the race by protecting the destruction with the corresponding 'kdamond_lock'. Link: https://lkml.kernel.org/r/20211221094447.2241-1-sj@kernel.orgReported-by:
Sangwoo Bae <sangwoob@amazon.com> Fixes: 4bc05954 ("mm/damon: implement a debugfs-based user space interface") Signed-off-by:
SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> [5.15.x] Signed-off-by:
-
Thibaut Sautereau authored
The second parameter of alloc_pages_exact_nid is the one indicating the size of memory pointed by the returned pointer. Link: https://lkml.kernel.org/r/YbjEgwhn4bGblp//@coeus Fixes: abd58f38 ("mm/page_alloc: add __alloc_size attributes for better bounds checking") Signed-off-by:
Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Daniel Micay <danielmicay@gmail.com> Cc: Levente Polyak <levente@leventepolyak.net> Signed-off-by:
-
Hugh Dickins authored
It is not easily reproducible, but on 5.16-rc I have several times hit the VM_BUG_ON_PAGE(PageTail(page), page) in page_cache_add_speculative(): usually from filemap_get_read_batch() for an ext4 read, yesterday from next_uptodate_page() from filemap_map_pages() for a shmem fault. That BUG used to be placed where page_ref_add_unless() had succeeded, but now it is placed before folio_ref_add_unless() is attempted: that is not safe, since it is only the acquired reference which makes the page safe from racing THP collapse or split. We could keep the BUG, checking PageTail only when folio_ref_try_add_rcu() has succeeded; but I don't think it adds much value - just delete it. Link: https://lkml.kernel.org/r/8b98fc6f-3439-8614-c3f3-945c659a1aba@google.com Fixes: 020853b6 ("mm: Add folio_try_get_rcu()") Signed-off-by:
Hugh Dickins <hughd@google.com> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: William Kucharski <william.kucharski@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
-
Naoya Horiguchi authored
When a memory error hits a tail page of a free hugepage, __page_handle_poison() is expected to be called to isolate the error in 4kB unit, but it's not called due to the outdated if-condition in memory_failure_hugetlb(). This loses the chance to isolate the error in the finer unit, so it's not optimal. Drop the condition. This "(p != head && TestSetPageHWPoison(head)" condition is based on the old semantics of PageHWPoison on hugepage (where PG_hwpoison flag was set on the subpage), so it's not necessray any more. By getting to set PG_hwpoison on head page for hugepages, concurrent error events on different subpages in a single hugepage can be prevented by TestSetPageHWPoison(head) at the beginning of memory_failure_hugetlb(). So dropping the condition should not reopen the race window originally mentioned in commit b985194c ("hwpoison, hugetlb: lock_page/unlock_page does not match for handling a free hugepage") [naoya.horiguchi@linux.dev: fix "HardwareCorrupted" counter] Link: https://lkml.kernel.org/r/20211220084851.GA1460264@u2004 Link: https://lkml.kernel.org/r/20211210110208.879740-1-naoya.horiguchi@linux.devSigned-off-by:
Fei Luo <luofei@unicloud.com> Reviewed-by:
Mike Kravetz <mike.kravetz@oracle.com> Cc: <stable@vger.kernel.org> [5.14+] Signed-off-by:
-
Randy Dunlap authored
Some lists that are moderated are not marked as moderated consistently, so mark them all as moderated. Link: https://lkml.kernel.org/r/20211209001330.18558-1-rdunlap@infradead.orgSigned-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Conor Culhane <conor.culhane@silvaco.com> Cc: Ryder Lee <ryder.lee@mediatek.com> Cc: Jianjun Wang <jianjun.wang@mediatek.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Philipp Rudo authored
When booting with crashkernel= on the kernel command line a warning similar to Kernel command line: ro console=ttyS0 crashkernel=256M Unknown kernel command line parameters "crashkernel=256M", will be passed to user space. is printed. This comes from crashkernel= being parsed independent from the kernel parameter handling mechanism. So the code in init/main.c doesn't know that crashkernel= is a valid kernel parameter and prints this incorrect warning. Suppress the warning by adding a dummy early_param handler for crashkernel=. Link: https://lkml.kernel.org/r/20211208133443.6867-1-prudo@redhat.com Fixes: 86d1919a ("init: print out unknown kernel parameters") Signed-off-by:Philipp Rudo <prudo@redhat.com> Acked-by:
Baoquan He <bhe@redhat.com> Cc: Andrew Halaney <ahalaney@redhat.com> Signed-off-by:
-
Andrey Ryabinin authored
alloc_pages_vma() may try to allocate THP page on the local NUMA node first: page = __alloc_pages_node(hpage_node, gfp | __GFP_THISNODE | __GFP_NORETRY, order); And if the allocation fails it retries allowing remote memory: if (!page && (gfp & __GFP_DIRECT_RECLAIM)) page = __alloc_pages_node(hpage_node, gfp, order); However, this retry allocation completely ignores memory policy nodemask allowing allocation to escape restrictions. The first appearance of this bug seems to be the commit ac5b2c18 ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings"). The bug disappeared later in the commit 89c83fb5 ("mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask") and reappeared again in slightly different form in the commit 76e654cc ("mm, page_alloc: allow hugepage fallback to remote nodes when madvised") Fix this by passing correct nodemask to the __alloc_pages() call. The demonstration/reproducer of the problem: $ mount -oremount,size=4G,huge=always /dev/shm/ $ echo always > /sys/kernel/mm/transparent_hugepage/defrag $ cat mbind_thp.c #include <unistd.h> #include <sys/mman.h> #include <sys/stat.h> #include <fcntl.h> #include <assert.h> #include <stdlib.h> #include <stdio.h> #include <numaif.h> #define SIZE 2ULL << 30 int main(int argc, char **argv) { int fd; unsigned long long i; char *addr; pid_t pid; char buf[100]; unsigned long nodemask = 1; fd = open("/dev/shm/test", O_RDWR|O_CREAT); assert(fd > 0); assert(ftruncate(fd, SIZE) == 0); addr = mmap(NULL, SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); assert(mbind(addr, SIZE, MPOL_BIND, &nodemask, 2, MPOL_MF_STRICT|MPOL_MF_MOVE)==0); for (i = 0; i < SIZE; i+=4096) { addr[i] = 1; } pid = getpid(); snprintf(buf, sizeof(buf), "grep shm /proc/%d/numa_maps", pid); system(buf); sleep(10000); return 0; } $ gcc mbind_thp.c -o mbind_thp -lnuma $ numactl -H available: 2 nodes (0-1) node 0 cpus: 0 2 node 0 size: 1918 MB node 0 free: 1595 MB node 1 cpus: 1 3 node 1 size: 2014 MB node 1 free: 1731 MB node distances: node 0 1 0: 10 20 1: 20 10 $ rm -f /dev/shm/test; taskset -c 0 ./mbind_thp 7fd970a00000 bind:0 file=/dev/shm/test dirty=524288 active=0 N0=396800 N1=127488 kernelpagesize_kB=4 Link: https://lkml.kernel.org/r/20211208165343.22349-1-arbn@yandex-team.com Fixes: ac5b2c18 ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings") Signed-off-by:Andrey Ryabinin <arbn@yandex-team.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Mel Gorman <mgorman@techsingularity.net> Acked-by:
David Rientjes <rientjes@google.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Baokun Li authored
Hulk robot reported a kmemleak problem: unreferenced object 0xffff93d1d8cc02e8 (size 248): comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s) hex dump (first 32 bytes): 00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: seq_open+0x2a/0x80 full_proxy_open+0x167/0x1e0 do_dentry_open+0x1e1/0x3a0 path_openat+0x961/0xa20 do_filp_open+0xae/0x120 do_sys_openat2+0x216/0x2f0 do_sys_open+0x57/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 unreferenced object 0xffff93d419854000 (size 4096): comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s) hex dump (first 32 bytes): 6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30 kfence-#250: 0x0 30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d 0000000754bda12- backtrace: seq_read_iter+0x313/0x440 seq_read+0x14b/0x1a0 full_proxy_read+0x56/0x80 vfs_read+0xa5/0x1b0 ksys_read+0xa0/0xf0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 I find that we can easily reproduce this problem with the following commands: cat /sys/kernel/debug/kfence/objects echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak The leaked memory is allocated in the stack below: do_syscall_64 do_sys_open do_dentry_open full_proxy_open seq_open ---> alloc seq_file vfs_read full_proxy_read seq_read seq_read_iter traverse ---> alloc seq_buf And it should have been released in the following process: do_syscall_64 syscall_exit_to_user_mode exit_to_user_mode_prepare task_work_run ____fput __fput full_proxy_release ---> free here However, the release function corresponding to file_operations is not implemented in kfence. As a result, a memory leak occurs. Therefore, the solution to this problem is to implement the corresponding release function. Link: https://lkml.kernel.org/r/20211206133628.2822545-1-libaokun1@huawei.com Fixes: 0ce20dd8 ("mm: add Kernel Electric-Fence infrastructure") Signed-off-by:Baokun Li <libaokun1@huawei.com> Reported-by:
Marco Elver <elver@google.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Yu Kuai <yukuai3@huawei.com> Signed-off-by:
-
- 24 Dec, 2021 3 commits
-
-
git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: - fix nommu after getting rid of mini-stack for ARMv7 - fix Thumb2 bug in iWMMXt exception handling * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9169/1: entry: fix Thumb2 bug in iWMMXt exception handling ARM: 9160/1: NOMMU: Reload __secondary_data after PROCINFO_INITFUNC
-
Linus Torvalds authored
Merge tag 'platform-drivers-x86-v5.16-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Hans de Goede: "Various bug-fixes" * tag 'platform-drivers-x86-v5.16-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: intel_pmc_core: fix memleak on registration failure platform/x86/intel: Remove X86_PLATFORM_DRIVERS_INTEL platform/x86: system76_acpi: Guard System76 EC specific functionality platform/x86: apple-gmux: use resource_size() with res platform/x86: amd-pmc: only use callbacks for suspend platform/mellanox: mlxbf-pmc: Fix an IS_ERR() vs NULL bug in mlxbf_pmc_map_counters
-
git://git.samba.org/ksmbdLinus Torvalds authored
Pull ksmbd fixes from Steve French: "Three ksmbd fixes, all for stable as well. Two fix potential unitialized memory and one fixes a security problem where encryption is unitentionally disabled from some clients" * tag '5.16-rc5-ksmbd-fixes' of git://git.samba.org/ksmbd: ksmbd: disable SMB2_GLOBAL_CAP_ENCRYPTION for SMB 3.1.1 ksmbd: fix uninitialized symbol 'pntsd_size' ksmbd: fix error code in ndr_read_int32()
-
- 23 Dec, 2021 3 commits
-
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Happy Xmas. Nothing major, one mediatek and a couple of i915 locking fixes. There might be a few stragglers over next week or so but I don't expect much before next release. mediatek: - NULL pointer check i915: - guc submission locking fixes" * tag 'drm-fixes-2021-12-24' of git://anongit.freedesktop.org/drm/drm: drm/i915/guc: Only assign guc_id.id when stealing guc_id drm/i915/guc: Use correct context lock when callig clr_context_registered drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull io_uring fix from Jens Axboe: "Single fix for not clearing kiocb->ki_pos back to 0 for a stream, destined for stable as well" * tag 'io_uring-5.16-2021-12-23' of git://git.kernel.dk/linux-block: io_uring: zero iocb->ki_pos for stream file types
-
Linus Torvalds authored
Merge branch 'ucount-rlimit-fixes-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace Pull ucount fix from Eric Biederman: "This fixes a silly logic bug in the ucount rlimits code, where it was comparing against the wrong limit" * 'ucount-rlimit-fixes-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: ucounts: Fix rlimit max values check
-
