- 26 Dec, 2021 28 commits
-
-
Colin Ian King authored
Variable range is being initialized with a value that is never read, it is being re-assigned in the next statement. The assignment is redundant, remove it and initialize range using the second assigned value. Clean up the formatting too by adding missing spaces. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20211204233155.55454-1-colin.i.king@gmail.comSigned-off-by:
Guenter Roeck <linux@roeck-us.net>
-
Dan Carpenter authored
Smatch detects this array overflow: drivers/hwmon/asus_wmi_sensors.c:569 asus_wmi_configure_sensor_setup() error: buffer overflow 'hwmon_attributes' 8 <= 9 The hwmon_attributes[] array should have "hwmon_max" so that it gets larger when more attributes are added. Fixes: 9d07e54a25b8 ("hwmon: (asus_wmi_sensors) Support X370 Asus WMI.") Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211130105117.GH5827@kiliSigned-off-by:
-
Dan Carpenter authored
Smatch detected an array out of bounds error: drivers/hwmon/asus_wmi_ec_sensors.c:562 asus_wmi_ec_configure_sensor_setup() error: buffer overflow 'hwmon_attributes' 8 <= 9 The hwmon_attributes[] array needs to be declared with "hwmon_max" elements. Fixes: c04c7f7bfcbe ("hwmon: (asus_wmi_ec_sensors) Support B550 Asus WMI.") Signed-off-by: -
David Mosberger-Tang authored
This patch enables automatic loading of the sht4x module via a device tree table entry. Signed-off-by:
David Mosberger-Tang <davidm@egauge.net> Link: https://lore.kernel.org/r/20211121160637.2312106-1-davidm@egauge.netSigned-off-by:
-
Linus Walleij authored
Allocate one state container for the device: struct ntc_data. Move all items from struct ntc_thermistor_platform_data into this struct and simplify. Cc: Peter Rosin <peda@axentia.se> Cc: Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211125020841.3616359-5-linus.walleij@linaro.orgSigned-off-by:
-
Linus Walleij authored
The only possible assignment of a function to get a voltage to convert to a resistance is to use the internal function ntc_adc_iio_read() which is only available when using IIO and OF. Bite the bullet and mandate OF and IIO, drop the read_uv() callback abstraction and some ifdefs. As no board is using the platform data, all users are using OF and IIO anyway. Cc: Peter Rosin <peda@axentia.se> Cc: Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
-
Linus Walleij authored
Nothing in the kernel (this driver) is using the callback to read ohms directly. We always read a voltage and convert it to a resistance. Drop this callback. Cc: Peter Rosin <peda@axentia.se> Cc: Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
-
Linus Walleij authored
Platform data is supposed to be used with "board files", device descriptions in C. Since the introduction of the NTC driver in 2011, no such platforms have been submitted to the Linux kernel, and their use is strongly discouraged in favor of Device Tree, ACPI or as last resort software firmware nodes. Drop the external header and copy the platform data into the driver file. Cc: Peter Rosin <peda@axentia.se> Cc: Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
-
Guenter Roeck authored
N34TS04 is a JC42.4 compatible temperature sensor from ONSEMI. Signed-off-by: -
Babu Moger authored
The current driver can read the temperatures from upto 8 CCDs (Core-Complex Die). The newer AMD Family 19h Models 10h-1Fh and A0h-AFh can support up to 12 CCDs. Update the driver to read up to 12 CCDs. Signed-off-by:
Babu Moger <babu.moger@amd.com> Link: https://lore.kernel.org/r/163776976762.904164.5618896687524494215.stgit@bmoger-ubuntuSigned-off-by:
-
Denis Pauk authored
Provides a Linux kernel module "asus_wmi_sensors" that provides sensor readouts via ASUS' WMI interface present in the UEFI of X370/X470/B450/X399 Ryzen motherboards. Supported motherboards: * ROG CROSSHAIR VI HERO, * PRIME X399-A, * PRIME X470-PRO, * ROG CROSSHAIR VI EXTREME, * ROG CROSSHAIR VI HERO (WI-FI AC), * ROG CROSSHAIR VII HERO, * ROG CROSSHAIR VII HERO (WI-FI), * ROG STRIX B450-E GAMING, * ROG STRIX B450-F GAMING, * ROG STRIX B450-I GAMING, * ROG STRIX X399-E GAMING, * ROG STRIX X470-F GAMING, * ROG STRIX X470-I GAMING, * ROG ZENITH EXTREME, * ROG ZENITH EXTREME ALPHA. Co-developed-by:
Ed Brindley <kernel@maidavale.org> Signed-off-by:
Denis Pauk <pauk.denis@gmail.com> [groeck: Squashed: "hwmon: Fix warnings in asus_wmi_sensors.rst documetation."] Signed-off-by:
-
Denis Pauk authored
Linux HWMON sensors driver for ASUS motherboards to read sensors from the embedded controller. Many ASUS motherboards do not publish all the available sensors via the Super I/O chip but the missing ones are available through the embedded controller (EC) registers. This driver implements reading those sensor data via the WMI method BREC, which is known to be present in all ASUS motherboards based on the AMD 500 series chipsets (and probably is available in other models too). The driver needs to know exact register addresses for the sensors and thus support for each motherboard has to be added explicitly. The EC registers do not provide critical values for the sensors and as such they are not published to the HWMON. Supported motherboards: * PRIME X570-PRO * Pro WS X570-ACE * ROG CROSSHAIR VIII HERO * ROG CROSSHAIR VIII DARK HERO * ROG CROSSHAIR VIII FORMULA * ROG STRIX X570-E GAMING * ROG STRIX B550-I GAMING * ROG STRIX B550-E GAMING Co-developed-by:
Eugene Shalygin <eugene.shalygin@gmail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Tor Vic <torvic9@mailbox.org> Tested-by:
Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by:
-
Menghui Wu authored
This adds hardware monitor support the Fintek F81966 Super I/O chip. Testing was done on the Aaeon SSE-IPTI Signed-off-by:
Menghui Wu <Menghui_Wu@aaeon.com.tw> Signed-off-by:
Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Link: https://lore.kernel.org/r/20211117024320.2428144-1-acelan.kao@canonical.comSigned-off-by:
-
Guenter Roeck authored
The adm1021 driver is quite generous with its automatic chip detection and easily misdetects several chips. Strengthen detection of MAX1617, MAX1617A, and LM84 to make the driver less vulnerable to false matches. Signed-off-by: -
Guenter Roeck authored
Since we are using regmap access functions to write into chip registers, we can hide the difference in register write addresses within regmap code. By doing this we do not need to clear the regmap cache on register writes, and the high level code does not need to bother about different read/write register addresses. Signed-off-by: -
Guenter Roeck authored
Use regmap for register accesses to be able to utilize its caching functionality. This also lets us hide register access differences in regmap code. Signed-off-by: -
Guenter Roeck authored
The new API is cleaner and reduces code size significantly. All chip accesses are 'hidden' in chip access to prepare for using regmap. Local caching code is removed, to be replaced by regmap based caching in a follow-up patch. Signed-off-by: -
Guenter Roeck authored
The difference between TMP431 and other chips of this series is that the TMP431 has an additional sensor. The register addresses for other sensors are the same for all chips. It is therefore unnecessary to maintain two different arrays for TMP431 and the other chips. Just use the same array for all chips and add the TMP431 register addresses as third column. Signed-off-by: -
Nathan Rossi authored
The INA238 is a I2C power monitor similar to other INA2xx devices, providing shunt voltage, bus voltage, current, power and temperature measurements. Signed-off-by:
Nathan Rossi <nathan.rossi@digi.com> Link: https://lore.kernel.org/r/20211102052754.817220-3-nathan@nathanrossi.comSigned-off-by:
-
Nathan Rossi authored
Add a property to the binding to define the selected shunt voltage gain. This specifies the range and accuracy that applies to the shunt circuit. This property only applies to devices that have a selectable shunt voltage range via PGA or ADCRANGE register configuration. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211102052754.817220-2-nathan@nathanrossi.comSigned-off-by:
-
Nathan Rossi authored
Document the compatible string for the Texas Instruments INA238, this device is a variant of the existing INA2xx devices and has the same device tree bindings (shunt resistor). Signed-off-by:
-
Babu Moger authored
Add thermal info support for AMD Family 19h Models 10h-1Fh and A0h-AFh. Thermal info is supported via a new PCI device ID at offset 0x300h. Signed-off-by:
-
Babu Moger authored
Usage of these definitions were removed after the commit 0a4e668b ("hwmon: (k10temp) Remove support for displaying voltage and current on Zen CPUs"). So, cleanup them up. Signed-off-by:
-
Yazen Ghannam authored
Add the new PCI Device IDs to support new generation of AMD 19h family of processors. Signed-off-by:
Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by:
Krzysztof Wilczyński <kw@linux.com> Acked-by:
Borislav Petkov <bp@suse.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h Link: https://lore.kernel.org/r/163640828133.955062.18349019796157170473.stgit@bmoger-ubuntuSigned-off-by:
-
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:
-
