- 27 Dec, 2021 14 commits
-
-
Bob Moore authored
ACPICA commit 86c919d2bad08491fc91ffa53e9b169092de8622 Repaired with casts. Link: https://github.com/acpica/acpica/commit/86c919d2Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Bob Moore authored
ACPICA commit ff803279dde7a3e068a6a698d8c69503cd159ad7 To simply return (AE_BAD_PARAMETER); to fix compilation on MSVC. Link: https://github.com/acpica/acpica/commit/ff803279Signed-off-by:
-
Kirill A. Shutemov authored
ACPICA commit 3dd7e1f3996456ef81bfe14cba29860e8d42949e According to ACPI 6.4, Section 16.2, the CPU cache flushing is required on entering to S1, S2, and S3, but the ACPICA code flushes the CPU cache regardless of the sleep state. Blind cache flush on entering S5 causes problems for TDX. Flushing happens with WBINVD that is not supported in the TDX environment. TDX only supports S5 and adjusting ACPICA code to conform to the spec more strictly fixes the issue. Link: https://github.com/acpica/acpica/commit/3dd7e1f3Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> [ rjw: Subject and changelog edits ] Signed-off-by:
-
Sudeep Holla authored
ACPICA commit 55526e8a6133cbf5a9cc0fb75a95dbbac6eb98e6 PCC Opregion added in ACPIC 6.3 requires special context data similar to GPIO and Generic Serial Bus as it needs to know the internal PCC buffer and its length as well as the PCC channel index when the opregion handler is being executed by the OSPM. Lets add support for the special context data needed by PCC Opregion. Link: https://github.com/acpica/acpica/commit/55526e8aSigned-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Sudeep Holla authored
ACPICA commit 41be6afacfdaec2dba3a5ed368736babc2a7aa5c With the PCC Opregion in the firmware and we are hitting below kernel crash: -->8 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Workqueue: pm pm_runtime_work pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x54/0x260 lr : acpi_ex_write_data_to_field+0xb8/0x194 Call trace: __memcpy+0x54/0x260 acpi_ex_store_object_to_node+0xa4/0x1d4 acpi_ex_store+0x44/0x164 acpi_ex_opcode_1A_1T_1R+0x25c/0x508 acpi_ds_exec_end_op+0x1b4/0x44c acpi_ps_parse_loop+0x3a8/0x614 acpi_ps_parse_aml+0x90/0x2f4 acpi_ps_execute_method+0x11c/0x19c acpi_ns_evaluate+0x1ec/0x2b0 acpi_evaluate_object+0x170/0x2b0 acpi_device_set_power+0x118/0x310 acpi_dev_suspend+0xd4/0x180 acpi_subsys_runtime_suspend+0x28/0x38 __rpm_callback+0x74/0x328 rpm_suspend+0x2d8/0x624 pm_runtime_work+0xa4/0xb8 process_one_work+0x194/0x25c worker_thread+0x260/0x49c kthread+0x14c/0x30c ret_from_fork+0x10/0x20 Code: f9000006 f81f80a7 d65f03c0 361000c2 (b9400026) ---[ end trace 24d8a032fa77b68a ]--- The reason for the crash is that the PCC channel index passed via region.address in acpi_ex_store_object_to_node is interpreted as the channel subtype incorrectly. Assuming the PCC op_region support is not used by any other type, let us remove the subtype check as the AML has no access to the subtype information. Once we remove it, the kernel crash disappears and correctly complains about missing PCC Opregion handler. ACPI Error: No handler for Region [PFRM] ((____ptrval____)) [PCC] (20210730/evregion-130) ACPI Error: Region PCC (ID=10) has no handler (20210730/exfldio-261) ACPI Error: Aborting method \_SB.ETH0._PS3 due to previous error (AE_NOT_EXIST) (20210730/psparse-531) Link: https://github.com/acpica/acpica/commit/41be6afaSigned-off-by:
-
Rafael J. Wysocki authored
ACPICA commit d984f12041392fa4156b52e2f7e5c5e7bc38ad9e If Operand[0] is a reference of the ACPI_REFCLASS_REFOF class, acpi_ex_opcode_1A_0T_1R () calls acpi_ns_get_attached_object () to obtain return_desc which may require additional resolution with the help of acpi_ex_read_data_from_field (). If the latter fails, the reference counter of the original return_desc is decremented which is incorrect, because acpi_ns_get_attached_object () does not increment the reference counter of the object returned by it. This issue may lead to premature deletion of the attached object while it is still attached and a use-after-free and crash in the host OS. For example, this may happen when on evaluation of ref_of() a local region field where there is no registered handler for the given Operation Region. Fix it by making acpi_ex_opcode_1A_0T_1R () return Status right away after a acpi_ex_read_data_from_field () failure. Link: https://github.com/acpica/acpica/commit/d984f120 Link: https://github.com/acpica/acpica/pull/685Reported-by:
Lenny Szubowicz <lszubowi@redhat.com> Signed-off-by:
-
Rafael J. Wysocki authored
ACPICA commit c11af67d8f7e3d381068ce7771322f2b5324d687 If original_count is 0 in acpi_ut_update_ref_count (), acpi_ut_delete_internal_obj () is invoked for the target object, which is incorrect, because that object has been deleted once already and the memory allocated to store it may have been reclaimed and allocated for a different purpose by the host OS. Moreover, a confusing debug message following the "Reference Count is already zero, cannot decrement" warning is printed in that case. To fix this issue, make acpi_ut_update_ref_count () return after finding that original_count is 0 and printing the above warning. Link: https://github.com/acpica/acpica/commit/c11af67d Link: https://github.com/acpica/acpica/pull/652Reported-by:
Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by:
-
Shuuichirou Ishii authored
ACPICA commit 13b9327761955f6e1e5dbf748b3112940c0dc539 The byte length of the Data field in the AEST Processor generic resource substructure defined in ACPI for the Armv8 RAS Extensions 1.1 is 4Byte. However, it is defined as a pointer type, and on a 64-bit machine, it is interpreted as 8 bytes. Therefore, it is changed from a pointer type unsigned integer 1 byte to an unsigned integer 4 bytes. Link: https://github.com/acpica/acpica/commit/13b93277Signed-off-by:
Shuuichirou Ishii <ishii.shuuichir@fujitsu.com> Signed-off-by:
-
Bob Moore authored
ACPICA commit 0420852ffc520b81960e877852703b739c16025c Added support for Vendor-defined microphone arrays and SNR (signal-to-noise) extension. Link: https://github.com/acpica/acpica/commit/0420852fSigned-off-by:
-
Jessica Clarke authored
ACPICA commit 6bb72909c1e3d415aee214104a01bc9834b2d4ce Since the Signature member is accessed through an struct acpi_table_header, the pointer to it is only to a 4-char array, and so trying to read past the 4th character, as will be done when it is an RSDP, reads beyond the bounds of the accessed member. On CHERI, and thus Arm's experimental Morello prototype architecture, pointers are represented as capabilities, which are unforgeable bounded pointers, providing always-on fine-grained spatial memory safety. By default, subobject bounds enforcement is not enabled, only bounds on allocations, but it is enabled in the cheri_BSD (a port of free_BSD) kernel as intra-object overflow attacks are common on operating system kernels, and so this overflow is detected there and traps. Link: https://github.com/acpica/acpica/commit/6bb72909Signed-off-by:
-
Jessica Clarke authored
ACPICA commit 52abebd410945ec55afb4dd8b7150e8a39b5c960 This macro was only ever used when stuffing pointers into physical addresses and trying to later reconstruct the pointer, which is implementation-defined as to whether that can be done. Now that all such operations are gone, the macro is unused, and should be removed to avoid such practices being reintroduced. Link: https://github.com/acpica/acpica/commit/52abebd4Signed-off-by:
-
Jessica Clarke authored
ACPICA commit dfa3feffa8f760b686207d09dc880cd2f26c72af Currently the pointer to the table is cast to acpi_physical_address and later cast back to a pointer to be dereferenced. Whether or not this is supported is implementation-defined. On CHERI, and thus Arm's experimental Morello prototype architecture, pointers are represented as capabilities, which are unforgeable bounded pointers, providing always-on fine-grained spatial memory safety. This means that any pointer cast to a plain integer will lose all its associated metadata, and when cast back to a pointer it will give a null-derived pointer (one that has the same metadata as null but an address equal to the integer) that will trap on any dereference. As a result, this is an implementation where acpi_physical_address cannot be used as a hack to store real pointers. Thus, alter the lifecycle of table descriptors. Internal physical tables keep the current behaviour where only the address is set on install, and the pointer is set on acquire. Virtual tables (internal and external) now store the pointer on initialisation and use that on acquire (which will redundantly set *table_ptr to itself, but changing that is both unnecessary and overly complicated as acpi_tb_acquire_table is called with both a pointer to a variable and a pointer to Table->Pointer itself). This requires propagating the (possible) table pointer everywhere in order to make sure pointers make it through to acpi_tb_acquire_temp_table, which requires a change to the acpi_install_table interface. Instead of taking an ACPI_PHYSADDR_TYPE and a boolean indicating whether it's physical or virtual, it is now split into acpi_install_table (that takes an external virtual table pointer) and acpi_install_physical_table (that takes an ACPI_PHYSADDR_TYPE for an internal physical table address). This also has the benefit of providing a cleaner API. Link: https://github.com/acpica/acpica/commit/dfa3feffSigned-off-by:
-
Jessica Clarke authored
ACPICA commit d9eb82bd7515989f0b29d79deeeb758db4d6529c Currently the pointer to the table is cast to acpi_physical_address and later cast back to a pointer to be dereferenced. Whether or not this is supported is implementation-defined. On CHERI, and thus Arm's experimental Morello prototype architecture, pointers are represented as capabilities, which are unforgeable bounded pointers, providing always-on fine-grained spatial memory safety. This means that any pointer cast to a plain integer will lose all its associated metadata, and when cast back to a pointer it will give a null-derived pointer (one that has the same metadata as null but an address equal to the integer) that will trap on any dereference. As a result, this is an implementation where acpi_physical_address cannot be used as a hack to store real pointers. Thus, add a new field to struct acpi_object_region to store the pointer for table regions, and propagate it to acpi_ex_data_table_space_handler via the region context, to use a more portable implementation that supports CHERI. Link: https://github.com/acpica/acpica/commit/d9eb82bdSigned-off-by:
-
Mark Langsdorf authored
ACPICA commit bc02c76d518135531483dfc276ed28b7ee632ce1 The current ACPI_ACCESS_*_WIDTH defines do not provide a way to test that size is small enough to not cause an overflow when applied to a 32-bit integer. Rather than adding more magic numbers, add ACPI_ACCESS_*_SHIFT, ACPI_ACCESS_*_MAX, and ACPI_ACCESS_*_DEFAULT #defines and redefine ACPI_ACCESS_*_WIDTH in terms of the new #defines. This was inititally reported on Linux where a size of 102 in ACPI_ACCESS_BIT_WIDTH caused an overflow error in the SPCR initialization code. Link: https://github.com/acpica/acpica/commit/bc02c76dSigned-off-by:
Mark Langsdorf <mlangsdo@redhat.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:
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 7 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
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from Jakub Kicinski: "Including fixes from netfilter. Current release - regressions: - revert "tipc: use consistent GFP flags" Previous releases - regressions: - igb: fix deadlock caused by taking RTNL in runtime resume path - accept UFOv6 packages in virtio_net_hdr_to_skb - netfilter: fix regression in looped (broad|multi)cast's MAC handling - bridge: fix ioctl old_deviceless bridge argument - ice: xsk: do not clear status_error0 for ntu + nb_buffs descriptor, avoid stalls when multiple sockets use an interface Previous releases - always broken: - inet: fully convert sk->sk_rx_dst to RCU rules - veth: ensure skb entering GRO are not cloned - sched: fix zone matching for invalid conntrack state - bonding: fix ad_actor_system option setting to default - nf_tables: fix use-after-free in nft_set_catchall_destroy() - lantiq_xrx200: increase buffer reservation to avoid mem corruption - ice: xsk: avoid leaking app buffers during clean up - tun: avoid double free in tun_free_netdev" * tag 'net-5.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (45 commits) net: stmmac: dwmac-visconti: Fix value of ETHER_CLK_SEL_FREQ_SEL_2P5M r8152: sync ocp base r8152: fix the force speed doesn't work for RTL8156 net: bridge: fix ioctl old_deviceless bridge argument net: stmmac: ptp: fix potentially overflowing expression net: dsa: tag_ocelot: use traffic class to map priority on injected header veth: ensure skb entering GRO are not cloned. asix: fix wrong return value in asix_check_host_enable() asix: fix uninit-value in asix_mdio_read() sfc: falcon: Check null pointer of rx_queue->page_ring sfc: Check null pointer of rx_queue->page_ring net: ks8851: Check for error irq drivers: net: smc911x: Check for error irq fjes: Check for error irq bonding: fix ad_actor_system option setting to default igb: fix deadlock caused by taking RTNL in RPM resume path gve: Correct order of processing device options net: skip virtio_net_hdr_set_proto if protocol already set net: accept UFOv6 packages in virtio_net_hdr_to_skb docs: networking: replace skb_hwtstamp_tx with skb_tstamp_tx ... -
Johan Hovold authored
In case device registration fails during module initialisation, the platform device structure needs to be freed using platform_device_put() to properly free all resources (e.g. the device name). Fixes: 938835aa ("platform/x86: intel_pmc_core: do not create a static struct device") Cc: stable@vger.kernel.org # 5.9 Signed-off-by:
Johan Hovold <johan@kernel.org> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20211222105023.6205-1-johan@kernel.orgSigned-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Nobuhiro Iwamatsu authored
ETHER_CLK_SEL_FREQ_SEL_2P5M is not 0 bit of the register. This is a value, which is 0. Fix from BIT(0) to 0. Reported-by:
Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp> Fixes: b38dd98f ("net: stmmac: Add Toshiba Visconti SoCs glue driver") Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Link: https://lore.kernel.org/r/20211223073633.101306-1-nobuhiro1.iwamatsu@toshiba.co.jpSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Hayes Wang says: ==================== r8152: fix bugs Patch #1 fix the issue of force speed mode for RTL8156. Patch #2 fix the issue of unexpected ocp_base. ==================== Link: https://lore.kernel.org/r/20211223092702.23841-386-nic_swsd@realtek.comSigned-off-by:
-
