Re: [PATCH 3/3] mm/hugetlb: Introduce HAVE_ARCH_CLEAR_HUGEPAGE_FLAGS

On Tue, 5 May 2020 08:21:34 +0530 Anshuman Khandual wrote: > >>> static inline void arch_clear_hugepage_flags(struct page *page) > >>> { > >>> > >>> } > >>> #define arch_clear_hugepage_flags arch_clear_hugepage_flags > >>> > >>> It's a small difference - mainly to avoid adding two variables

Re: [PATCH 1/1] epoll: call final ep_events_available() check under the lock

On Tue, 05 May 2020 10:42:05 +0200 Roman Penyaev wrote: > May I ask you to remove "epoll: ensure ep_poll() doesn't miss wakeup > events" from your -mm queue? Jason lately found out that the patch > does not fully solve the problem and this one patch is a second > attempt to do things correctly

Re: [PATCH v2] checkpatch: use patch subject when reading from stdin

On Tue, 5 May 2020 15:26:13 +0200 Geert Uytterhoeven wrote: > While "git am" can apply an mbox file containing multiple patches (e.g. > as created by b4[1], or a patch bundle downloaded from patchwork), > checkpatch does not have proper support for that. When operating on an > mbox,

Re: [PATCH] mm: Limit boost_watermark on small zones.

On Mon, 4 May 2020 13:44:09 +0100 Mel Gorman wrote: > On Fri, May 01, 2020 at 03:57:29PM -0700, Andrew Morton wrote: > > On Thu, 30 Apr 2020 17:49:08 -0700 Henry Willard > > wrote: > > > > > Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an

Re: [PATCH] slub: limit count of partial slabs scanned to gather statistics

On Mon, 04 May 2020 19:07:39 +0300 Konstantin Khlebnikov wrote: > To get exact count of free and used objects slub have to scan list of > partial slabs. This may take at long time. Scanning holds spinlock and > blocks allocations which move partial slabs to per-cpu lists and back. > > Example

Re: [PATCH] mm: Limit boost_watermark on small zones.

On Thu, 30 Apr 2020 17:49:08 -0700 Henry Willard wrote: > Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external > fragmentation event occurs") adds a boost_watermark() function which > increases the min watermark in a zone by at least pageblock_nr_pages or > the number of

Re: [PATCH 3/3] mm/swapfile.c: count won't be bigger than SWAP_MAP_MAX

On Fri, 1 May 2020 01:52:59 + Wei Yang wrote: > When the condition is true, there are two possibilities: I'm struggling with this one. >1. count == SWAP_MAP_BAD >2. count == (SWAP_MAP_MAX & COUNT_CONTINUED) == SWAP_MAP_SHMEM I'm not sure what 2. is trying to say. For a start,

Re: [PATCH 21/29] mm: remove the pgprot argument to __vmalloc

On Thu, 30 Apr 2020 22:38:10 -0400 John Dorminy wrote: > the change > description refers to PROT_KERNEL, which is a symbol which does not > appear to exist; perhaps PAGE_KERNEL was meant? Yes, thanks, fixed.

Re: [PATCH 2/2] exec: open code copy_string_kernel

On Fri, 1 May 2020 22:30:48 +0100 Al Viro wrote: > On Fri, May 01, 2020 at 02:19:03PM -0700, Andrew Morton wrote: > > On Fri, 1 May 2020 12:41:05 +0200 Christoph Hellwig wrote: > > > > > Currently copy_string_kernel is just a wrapper around copy_strings that >

Re: [PATCH] mm: slub: add panic_on_error to the debug facilities

On Fri, 1 May 2020 17:15:40 -0400 Rafael Aquini wrote: > Sometimes it is desirable to override SLUB's debug facilities > default behavior upon stumbling on a cache or object error > and just stop the execution in order to grab a coredump, at > the error-spotting time, instead of trying to fix

Re: [PATCH 2/2] exec: open code copy_string_kernel

On Fri, 1 May 2020 12:41:05 +0200 Christoph Hellwig wrote: > Currently copy_string_kernel is just a wrapper around copy_strings that > simplifies the calling conventions and uses set_fs to allow passing a > kernel pointer. But due to the fact the we only need to handle a single > kernel

Re: mm: mkfs.ext4 invoked oom-killer on i386 - pagecache_get_page

On Fri, 1 May 2020 18:08:28 +0530 Naresh Kamboju wrote: > mkfs -t ext4 invoked oom-killer on i386 kernel running on x86_64 device > and started happening on linux -next master branch kernel tag next-20200430 > and next-20200501. We did not bisect this problem. It would be wonderful if you

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand wrote: > > > > Why does the firmware map support hotplug entries? > > I assume: > > The firmware memmap was added primarily for x86-64 kexec (and still, is > mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs > get

Re: [PATCH] percpu: make pcpu_alloc() aware of current gfp context

On Thu, 30 Apr 2020 17:43:56 +0100 fdman...@kernel.org wrote: > From: Filipe Manana > > Since 5.7-rc1, on btrfs we have a percpu counter initialization for which > we always pass a GFP_KERNEL gfp_t argument (this happens since commit > 2992df73268f78 ("btrfs: Implement DREW lock")). That is

Re: [PATCH 0/7] padata: parallelize deferred page init

On Thu, 30 Apr 2020 16:11:18 -0400 Daniel Jordan wrote: > Sometimes the kernel doesn't take full advantage of system memory > bandwidth, leading to a single CPU spending excessive time in > initialization paths where the data scales with memory size. > > Multithreading naturally addresses this

Re: [PATCH] mm/gup.c: Handle error at earliest for incorrect nr_pages value

On Fri, 1 May 2020 01:41:58 +0530 Souptick Joarder wrote: > As per documentation, pin_user_pages_fast() & get_user_pages_fast() > will return 0, if nr_pages <= 0. But this can be figure out only after > going inside the internal_get_user_pages_fast(). > > This can be handled early. Adding a

Re: [PATCH v2 00/10] change the implementation of the PageHighMem()

On Wed, 29 Apr 2020 12:26:33 +0900 js1...@gmail.com wrote: > From: Joonsoo Kim > > Changes on v2 > - add "acked-by", "reviewed-by" tags > - replace PageHighMem() with use open-code, instead of using > new PageHighMemZone() macro. Related file is "include/linux/migrate.h" > > Hello, > > This

Re: [PATCH -next] ipc: use GFP_ATOMIC under spin lock

On Tue, 28 Apr 2020 04:14:03 -0700 Matthew Wilcox wrote: > On Tue, Apr 28, 2020 at 03:47:36AM +, Wei Yongjun wrote: > > The function ipc_id_alloc() is called from ipc_addid(), in which > > a spin lock is held, so we should use GFP_ATOMIC instead. > > > > Fixes: de5738d1c364 ("ipc: convert

Re: [PATCH v2 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline

On Tue, 28 Apr 2020 15:08:36 +0530 Srikar Dronamraju wrote: > Currently Linux kernel with CONFIG_NUMA on a system with multiple > possible nodes, marks node 0 as online at boot. However in practice, > there are systems which have node 0 as memoryless and cpuless. > > This can cause

Re: [PATCH v6 RESEND 0/2] vfs: have syncfs() return error when there are writeback errors

On Tue, 28 Apr 2020 09:51:53 -0400 Jeff Layton wrote: > Just a resend since this hasn't been picked up yet. No real changes > from the last set (other than adding Jan's Reviewed-bys). Latest > cover letter follows: I see no cover letter here. > >

Re: linux-next test error: WARNING in collapse_file

nel.org/r/20191022191006.411277-1-songliubrav...@fb.com Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS") Signed-off-by: Song Liu Acked-by: Johannes Weiner Cc: Kirill A. Shutemov Cc: Hugh Dickins Cc: William Kucharski Signed-off-by: Andrew Morton --- mm/

Re: [PATCH v12 3/6] mm: Introduce Reported pages

On Tue, 22 Oct 2019 15:28:12 -0700 Alexander Duyck wrote: > From: Alexander Duyck > > In order to pave the way for free page reporting in virtualized > environments we will need a way to get pages out of the free lists and > identify those pages after they have been returned. To accomplish

Re: [PATCH v12 0/6] mm / virtio: Provide support for unused page reporting

On Tue, 22 Oct 2019 15:27:52 -0700 Alexander Duyck wrote: > Below are the results from various benchmarks. I primarily focused on two > tests. The first is the will-it-scale/page_fault2 test, and the other is > a modified version of will-it-scale/page_fault1 that was enabled to use > THP. I did

Re: [PATCH 2/5] ipc/mqueue.c: Remove duplicated code

On Sun, 20 Oct 2019 14:33:02 +0200 Manfred Spraul wrote: > Patch from Davidlohr, I just added this change log. > pipelined_send() and pipelined_receive() are identical, so merge them. > > Signed-off-by: Davidlohr Bueso > Signed-off-by: Manfred Spraul I redid the changelog as below: From:

Re: [PATCH] scripts: fix memleak error in read_file

On Tue, 22 Oct 2019 11:47:59 + linfeilong wrote: > An error is found by the static code analysis tool: "memleak" > Fix this by add free before return. > > Signed-off-by: Feilong Lin > --- > scripts/insert-sys-cert.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH] mm/vmstat: Reduce zone lock hold time when reading /proc/pagetypeinfo

On Tue, 22 Oct 2019 12:21:56 -0400 Waiman Long wrote: > The pagetypeinfo_showfree_print() function prints out the number of > free blocks for each of the page orders and migrate types. The current > code just iterates the each of the free lists to get counts. There are > bug reports about hard

Re: [PATCH 1/1] mm/gup_benchmark: fix MAP_HUGETLB case

On Tue, 22 Oct 2019 12:39:53 -0700 John Hubbard wrote: > Admin note: this already went into mmotm, so I'm hoping Andrew will notice > this > email and add the Reviewed-by tag, please? Always. (Well, almost ;))

Re: [PATCH v2 2/2] mm/memory-failure.c: Don't access uninitialized memmaps in memory_failure()

On Thu, 10 Oct 2019 09:17:42 +0200 David Hildenbrand wrote: > >> - pgmap = get_dev_pagemap(pfn, NULL); > >> - if (pgmap) > >> - return memory_failure_dev_pagemap(pfn, flags, pgmap); > >> - > >> - p = pfn_to_page(pfn); > > > > This change seems to assume that

Re: [PATCH v3 2/3] mm/vmalloc: respect passed gfp_mask when do preloading

8.12391-2-ure...@gmail.com Signed-off-by: Uladzislau Rezki (Sony) Acked-by: Michal Hocko Cc: Daniel Wagner Cc: Hillf Danton Cc: Matthew Wilcox Cc: Oleksiy Avramchenko Cc: Peter Zijlstra Cc: Sebastian Andrzej Siewior Cc: Steven Rostedt Cc: Thomas Gleixner Signed-off-by: Andrew Morton ---

Re: [PATCH 2/3] mm, meminit: Recalculate pcpu batch and high limits after init completes

Matt Fleming Acked-by: Michal Hocko Cc: Vlastimil Babka Cc: Thomas Gleixner Cc: Borislav Petkov Cc: [4.1+] Signed-off-by: Andrew Morton --- mm/page_alloc.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/mm/page_alloc.c~mm-meminit-recalculate-pcpu-batch

Re: [PATCH v3] mm,thp: recheck each page before collapsing file THP

On Fri, 18 Oct 2019 11:03:45 -0700 Song Liu wrote: > In collapse_file(), after locking the page, it is necessary to recheck > that the page is up-to-date. Add PageUptodate() check for both shmem THP > and file THP. > > Current khugepaged should not try to collapse dirty file THP, because it >

Re: [PATCH] mm: Unsigned 'nr_pages' always larger than zero

On Wed, 16 Oct 2019 17:07:44 +0800 zhong jiang wrote: > >> --- a/mm/gup.c~a > >> +++ a/mm/gup.c > >> @@ -1450,6 +1450,7 @@ static long check_and_migrate_cma_pages( > >> bool drain_allow = true; > >> bool migrate_allow = true; > >> LIST_HEAD(cma_page_list); > >> +long ret; >

Re: [PATCH linux-kselftest/test v2] lib/list-test: add a test for the 'list' doubly linked list

On Wed, 16 Oct 2019 14:48:59 -0700 David Gow wrote: > Since KUnit is not yet in Linus' branch, though, it probably makes > sense to put this test into the linux-kselftest/test branch, so that > there aren't any chances of the list test getting in without the KUnit > infrastructure. Ultimately,

Re: [PATCH] checkpatch.pl: Don't complain about nominal authors if there isn't one

On Fri, 13 Sep 2019 08:34:28 -0700 Joe Perches wrote: > On Fri, 2019-09-13 at 10:22 -0400, Alan Stern wrote: > > On Thu, 12 Sep 2019, Joe Perches wrote: > > > > > On Thu, 2019-09-12 at 16:55 -0400, Alan Stern wrote: > > > > checkpatch.pl shouldn't warn about a "Missing Signed-off-by: line by >

Re: [PATCH] mm: memblock: do not enforce current limit for memblock_phys* family

On Sun, 13 Oct 2019 00:31:01 +0300 Mike Rapoport wrote: > Until commit 92d12f9544b7 ("memblock: refactor internal allocation > functions") the maximal address for memblock allocations was forced to > memblock.current_limit only for the allocation functions returning virtual > address. The

Re: kernel BUG at include/linux/rmap.h:LINE!

g Acked-by: Konstantin Khlebnikov Cc: Kirill A. Shutemov Cc: "Jérôme Glisse" Cc: Mike Kravetz Cc: Rik van Riel Cc: Qian Cai Cc: Shakeel Butt Signed-off-by: Andrew Morton --- mm/rmap.c | 13 + 1 file changed, 13 insertions(+) --- a/mm/rmap.c~mm-rmapc-reus

Re: [PATCH v6 04/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span()

On Mon, 14 Oct 2019 11:32:13 +0200 David Hildenbrand wrote: > > Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug") > > @Andrew, can you convert that to > > Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded > memory to zones until online") # visible after

Re: [Patch v4 2/2] linux/bits.h: Add compile time sanity check of GENMASK inputs

On Wed, 9 Oct 2019 23:45:02 +0200 Rikard Falkeborn wrote: > GENMASK() and GENMASK_ULL() are supposed to be called with the high bit > as the first argument and the low bit as the second argument. Mixing > them will return a mask with zero bits set. > > Recent commits show getting this wrong

Re: [PATCH 1/1] mm/vmalloc: remove preempt_disable/enable when do preloading

On Thu, 10 Oct 2019 17:17:49 +0200 Uladzislau Rezki wrote: > > > : * The preload is done in non-atomic context, thus it allows us > > > : * to use more permissive allocation masks to be more stable > > > under > > > : * low memory condition and high memory pressure. >

Re: [PATCH v1] drivers/base/memory.c: Don't access uninitialized memmaps in soft_offline_page_store()

On Thu, 10 Oct 2019 16:12:00 +0200 David Hildenbrand wrote: > Uninitialized memmaps contain garbage and in the worst case trigger kernel > BUGs, especially with CONFIG_PAGE_POISONING. They should not get > touched. > > Right now, when trying to soft-offline a PFN that resides on a memory >

Re: [PATCH linux-kselftest/test v2] lib/list-test: add a test for the 'list' doubly linked list

On Fri, 11 Oct 2019 14:37:25 -0700 David Gow wrote: > On Fri, Oct 11, 2019 at 2:05 PM Andrew Morton > wrote: > > > > > > > > Given that everything runs at late_initcall time, shouldn't everything > > be __init, __initdata etc so all the code and d

Re: [PATCH] mm: annotate refault stalls from swap_readpage

On Thu, 10 Oct 2019 15:17:47 -0400 Johannes Weiner wrote: > On Thu, Oct 10, 2019 at 08:21:34AM -0700, Minchan Kim wrote: > > From: Minchan Kim > > > > If block device supports rw_page operation, it doesn't submit bio > > so annotation in submit_bio for refault stall doesn't work. > > It

Re: [PATCH linux-kselftest/test v2] lib/list-test: add a test for the 'list' doubly linked list

On Thu, 10 Oct 2019 11:56:31 -0700 David Gow wrote: > Add a KUnit test for the kernel doubly linked list implementation in > include/linux/list.h > > Each test case (list_test_x) is focused on testing the behaviour of the > list function/macro 'x'. None of the tests pass invalid lists to these

Re: [PATCH linux-kselftest/test v2] lib/list-test: add a test for the 'list' doubly linked list

On Thu, 10 Oct 2019 11:56:31 -0700 David Gow wrote: > Add a KUnit test for the kernel doubly linked list implementation in > include/linux/list.h > > Each test case (list_test_x) is focused on testing the behaviour of the > list function/macro 'x'. None of the tests pass invalid lists to these

Re: "reuse mergeable anon_vma as parent when fork" causes a crash on s390

On Wed, 9 Oct 2019 15:21:11 -0700 Shakeel Butt wrote: > On Wed, Oct 9, 2019 at 2:30 PM Qian Cai wrote: > > > > The linux-next commit "mm/rmap.c: reuse mergeable anon_vma as parent when > > fork" > > [1] causes a crash on s390 while compiling some C code. Reverted it fixes > > the > > issue. >

Re: [PATCH v4 0/2] mm/memory-failure: Poison read receives SIGKILL instead of SIGBUS issue

On Tue, 8 Oct 2019 23:18:31 + Naoya Horiguchi wrote: > I think that this patchset is good enough and ready to be merged. > Andrew, could you consider queuing this series into your tree? I'll treat that as an acked-by:. Do you think 2/2 should be backported into -stable trees?

Re: [PATCH 1/1] mm/vmalloc: remove preempt_disable/enable when do preloading

On Wed, 9 Oct 2019 18:49:34 +0200 "Uladzislau Rezki (Sony)" wrote: > Get rid of preempt_disable() and preempt_enable() when the > preload is done for splitting purpose. The reason is that > calling spin_lock() with disabled preemtion is forbidden in > CONFIG_PREEMPT_RT kernel. > > Therefore,

Re: [PATCH v18 01/14] bitops: Introduce the for_each_set_clump8 macro

On Wed, 9 Oct 2019 13:14:37 -0400 William Breathitt Gray wrote: > This macro iterates for each 8-bit group of bits (clump) with set bits, > within a bitmap memory region. For each iteration, "start" is set to the > bit offset of the found clump, while the respective clump value is > stored to

Re: [PATCH v2] mm/slub: fix a deadlock in show_slab_objects()

On Mon, 7 Oct 2019 10:16:21 +0200 Michal Hocko wrote: > On Fri 04-10-19 14:57:01, Michal Hocko wrote: > > On Fri 04-10-19 08:31:49, Qian Cai wrote: > > > Long time ago, there fixed a similar deadlock in show_slab_objects() > > > [1]. However, it is apparently due to the commits like 01fb58bcba63

Re: [PATCH] mm/page_isolation: fix a deadlock with printk()

On Sat, 5 Oct 2019 20:10:47 -0400 Qian Cai wrote: > > > >> the existing dependency chain (in reverse order) is: > >> > >> -> #2 (&(>lock)->rlock){-.-.}: > >> lock_acquire+0x21a/0x468 > >> _raw_spin_lock+0x54/0x68 > >> get_page_from_freelist+0x8b6/0x2d28 > >>

Re: [PATCH] mm/page_isolation: fix a deadlock with printk()

On Fri, 4 Oct 2019 12:42:26 -0400 Qian Cai wrote: > It is unsafe to call printk() while zone->lock was held, i.e., > > zone->lock --> console_sem > > because the console could always allocate some memory in different code > paths and form locking chains in an opposite order, > > console_sem

Re: [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages()

On Fri, 4 Oct 2019 16:41:50 +0200 Michal Hocko wrote: > > > This is just insane. The hotplug code is in no way special wrt printk. > > > It is never called from the printk code AFAIK and thus there is no real > > > reason why this particular code should be any special. Not to mention > > > it

Re: [PATCH v2] mm/swap: piggyback lru_add_drain_all() calls

On Fri, 04 Oct 2019 16:09:22 +0300 Konstantin Khlebnikov wrote: > This is very slow operation. There is no reason to do it again if somebody > else already drained all per-cpu vectors while we waited for lock. > > Piggyback on drain started and finished while we waited for lock: > all pages

Re: [PATCH v1] kernel.h: Split out mathematical helpers

On Tue, 10 Sep 2019 13:51:05 +0300 Andy Shevchenko wrote: > kernel.h is being used as a dump for all kinds of stuff for a long time. > Here is the attempt to start cleaning it up by splitting out mathematical > helpers. > > Signed-off-by: Andy Shevchenko > --- > fs/nfs/callback_proc.c

Re: [PATCH v6 0/3] mm, slab: Make kmalloc_info[] contain all types of names

On Mon, 23 Sep 2019 20:27:25 +0800 Pengfei Li wrote: > Changes in v6 > -- > 1. abandon patch 4-7 (Because there is not enough reason to explain > that they are beneficial) So http://lkml.kernel.org/r/20190923004022.GC15734@shao2-debian can no longer occur? > Changes in v5 > -- > 1. patch 1/7:

Re: [PATCH v7 1/1] memory_hotplug: Add a bounds check to __add_pages

ay remap pages that is not physically addressable, resulting in bogus section numbers being returned from __section_nr(). Link: http://lkml.kernel.org/r/20190917010752.28395-3-alast...@au1.ibm.com Signed-off-by: Alastair D'Silva Acked-by: David Hildenbrand Cc: Dan Williams Cc: Ira Weiny Cc:

Re: [PATCH] panic: Ensure preemption is disabled during panic()

On Wed, 2 Oct 2019 13:35:38 +0100 Will Deacon wrote: > Calling 'panic()' on a kernel with CONFIG_PREEMPT=y can leave the > calling CPU in an infinite loop, but with interrupts and preemption > enabled. From this state, userspace can continue to be scheduled, > despite the system being "dead" as

Re: [PATCH] mm, vmpressure: Fix a signedness bug in vmpressure_register_event()

On Sat, 28 Sep 2019 14:47:02 -0700 Matthew Wilcox wrote: > On Sat, Sep 28, 2019 at 02:23:56PM -0700, Andrew Morton wrote: > > How about doing it this way? Only copy the int to the enum once we > > know it's within range? > > This will return a positive integer on success i

Re: [PATCH] mm, vmpressure: Fix a signedness bug in vmpressure_register_event()

On Wed, 25 Sep 2019 14:04:49 +0300 Dan Carpenter wrote: > The "mode" and "level" variables are enums and in this context GCC will > treat them as unsigned ints so the error handling is never triggered. > > I also removed the bogus initializer because it isn't required any more > and it's sort

Re: [PATCH RESEND v4] fs/epoll: Remove unnecessary wakeups of nested epoll that in ET mode

On Wed, 25 Sep 2019 09:56:03 +0800 hev wrote: > From: Heiher > > Take the case where we have: > > t0 > | (ew) > e0 > | (et) > e1 > | (lt) > s0 > > t0: thread 0 > e0: epoll fd 0 > e1: epoll fd 1 > s0: socket fd 0 > ew: epoll_wait >

Re: [PATCH] mm/page_alloc: fix a crash in free_pages_prepare()

On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai wrote: > > > > So I think you've moved the arch_free_page() to be after the final > > thing which can access page contents, yes? If so, we should have a > > comment in free_pages_prepare() to attmept to prevent this problem from > > reoccurring as

Re: [PATCH] mm/page_alloc: fix a crash in free_pages_prepare()

On Fri, 27 Sep 2019 15:47:03 -0400 Qian Cai wrote: > On architectures like s390, arch_free_page() could mark the page unused > (set_page_unused()) and any access later would trigger a kernel panic. > Fix it by moving arch_free_page() after all possible accessing calls. > > Hardware name: IBM

Re: [PATCH] mm/page_alloc: fix a crash in free_pages_prepare()

On Fri, 27 Sep 2019 15:47:03 -0400 Qian Cai wrote: > On architectures like s390, arch_free_page() could mark the page unused > (set_page_unused()) and any access later would trigger a kernel panic. > Fix it by moving arch_free_page() after all possible accessing calls. > > Hardware name: IBM

Re: [PATCH] z3fold: claim page in the beginning of free

On Thu, 26 Sep 2019 10:48:44 +0200 Vitaly Wool wrote: > There's a really hard to reproduce race in z3fold between > z3fold_free() and z3fold_reclaim_page(). z3fold_reclaim_page() > can claim the page after z3fold_free() has checked if the page > was claimed and z3fold_free() will then schedule

Re: [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms

On Tue, 23 Jul 2019 06:51:36 -0700 Joe Perches wrote: > Several uses of strlcpy and strscpy have had defects because the > last argument of each function is misused or typoed. > > Add macro mechanisms to avoid this defect. > > stracpy (copy a string to a string array) must have a string >

Re: [PATCH] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory()

> > Reverse sequence should be followed during memory hot removal which already > > is being followed in add_memory_resource() error path. This now ensures > > required re-order between memblock_[free|remove]() and arch_remove_memory() > > during memory hot-remove. >

Re: [PATCH] uaccess: Disallow > INT_MAX copy sizes

On Mon, 23 Sep 2019 16:08:54 -0700 Kees Cook wrote: > On Sun, Aug 25, 2019 at 04:18:56PM -0700, Kees Cook wrote: > > As we've done with VFS, string operations, etc, reject usercopy sizes > > larger than INT_MAX, which would be nice to have for catching bugs > > related to size calculation

Re: [PATCH] memcg, kmem: do not fail __GFP_NOFAIL charges

c: Thomas Lindroth Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton --- mm/memcontrol.c | 10 ++ 1 file changed, 10 insertions(+) --- a/mm/memcontrol.c~memcg-kmem-do-not-fail-__gfp_nofail-charges +++ a/mm/memcontrol.c @@ -2943,6 +2943,16 @@ int __memcg_kmem_charge_memcg(s

Re: [RESEND PATCH v2] mm/oom_killer: Add task UID to info message on an oom kill

On Thu, 13 Jun 2019 10:23:18 +0200 Michal Hocko wrote: > On Wed 12-06-19 13:57:53, Joel Savitz wrote: > > In the event of an oom kill, useful information about the killed > > process is printed to dmesg. Users, especially system administrators, > > will find it useful to immediately see the UID

Re: [PATCH v2 0/4] debug_pagealloc improvements through page_owner

On Thu, 22 Aug 2019 16:03:44 -0700 Andrew Morton wrote: > On Tue, 20 Aug 2019 15:18:24 +0200 Vlastimil Babka wrote: > > > v2: also fix THP split handling (added Patch 1) per Kirill > > > > The debug_pagealloc functionality serves a similar purpose on the

Re: [PATCH -next] mm/kmemleak: record the current memory pool size

On Thu, 15 Aug 2019 11:02:16 +0100 Catalin Marinas wrote: > On Wed, Aug 14, 2019 at 03:07:11PM -0400, Qian Cai wrote: > > The only way to obtain the current memory pool size for a running kernel > > is to check back the kernel config file which is inconvenient. Record it > > in the kernel

Re: [PATCH] connector: report comm change event when modifying /proc/pid/task/tid/comm

On Wed, 18 Sep 2019 22:43:21 -0400 KeMeng Shi wrote: > It's indeed necessary to fix the concurrence problem. I will submit > a v2 patch when I fix this. Even though this is a procfs change, connector patches are usually handled by davem. So please cc himself, Evgeniy Polyakov and

Re: threads-max observe limits

On Thu, 19 Sep 2019 09:59:11 +0200 Michal Hocko wrote: > On Wed 18-09-19 09:15:41, Michal Hocko wrote: > > On Tue 17-09-19 12:26:18, Eric W. Biederman wrote: > [...] > > > b) Not being able to bump threads_max to the physical limit of > > >the machine is very clearly a regression. > > > >

Re: [PATCH] memcg, kmem: do not fail __GFP_NOFAIL charges

On Wed, 11 Sep 2019 14:00:02 +0200 Michal Hocko wrote: > On Mon 09-09-19 13:22:45, Michal Hocko wrote: > > On Fri 06-09-19 11:24:55, Shakeel Butt wrote: > [...] > > > I wonder what has changed since > > > . > > > > I have

Re: [PATCH] mm: avoid slub allocation while holding list_lock

On Mon, 9 Sep 2019 00:10:16 -0600 Yu Zhao wrote: > If we are already under list_lock, don't call kmalloc(). Otherwise we > will run into deadlock because kmalloc() also tries to grab the same > lock. > > Instead, allocate pages directly. Given currently page->objects has > 15 bits, we only

Re: [PATCH v2] fork: check exit_signal passed in clone3() call

On Tue, 10 Sep 2019 18:58:52 +0100 Eugene Syromiatnikov wrote: > Previously, higher 32 bits of exit_signal fields were lost when > copied to the kernel args structure (that uses int as a type for the > respective field). Moreover, as Oleg has noted[1], exit_signal is used > unchecked, so it has

Re: [PATCH] mm: Unsigned 'nr_pages' always larger than zero

On Wed, 4 Sep 2019 13:24:58 +0200 Vlastimil Babka wrote: > On 9/4/19 12:26 PM, zhong jiang wrote: > > With the help of unsigned_lesser_than_zero.cocci. Unsigned 'nr_pages"' > > compare with zero. And __get_user_pages_locked will return an long value. > > Hence, Convert the long to compare with

Re: [PATCH] mm: Unsigned 'nr_pages' always larger than zero

On Wed, 4 Sep 2019 13:24:58 +0200 Vlastimil Babka wrote: > On 9/4/19 12:26 PM, zhong jiang wrote: > > With the help of unsigned_lesser_than_zero.cocci. Unsigned 'nr_pages"' > > compare with zero. And __get_user_pages_locked will return an long value. > > Hence, Convert the long to compare with

Re: [PATCH] mm/vmalloc: move 'area->pages' after if statement

On Fri, 30 Aug 2019 12:57:16 +0900 Austin Kim wrote: > If !area->pages statement is true where memory allocation fails, > area is freed. > > In this case 'area->pages = pages' should not executed. > So move 'area->pages = pages' after if statement. > > ... > > --- a/mm/vmalloc.c > +++

Re: [PATCH] mm/z3fold.c: remove useless code in z3fold_page_isolate

On Thu, 29 Aug 2019 14:13:12 -0500 "Gustavo A. R. Silva" wrote: > Remove duplicate and useless code. > > ... > > --- a/mm/z3fold.c > +++ b/mm/z3fold.c > @@ -1400,15 +1400,13 @@ static bool z3fold_page_isolate(struct page *page, > isolate_mode_t mode) >* can call the

Re: cleanup the walk_page_range interface

On Tue, 27 Aug 2019 01:34:13 + Jason Gunthorpe wrote: > On Sat, Aug 24, 2019 at 03:26:55PM -0700, Christoph Hellwig wrote: > > On Fri, Aug 23, 2019 at 01:43:12PM +, Jason Gunthorpe wrote: > > > > So what is the plan forward? Probably a little late for 5.3, > > > > so queue it up in -mm

Re: [PATCH] mm/z3fold.c: fix lock/unlock imbalance in z3fold_page_isolate

On Sun, 25 Aug 2019 22:06:34 -0500 "Gustavo A. R. Silva" wrote: > Fix lock/unlock imbalance by unlocking *zhdr* before return. > > Addresses-Coverity-ID: 1452811 ("Missing unlock") > Fixes: d776aaa9895e ("mm/z3fold.c: fix race between migration and > destruction") > Signed-off-by: Gustavo A.

Re: [PATCH v3 0/3] vmstats/vmevents flushing

On Fri, 23 Aug 2019 00:33:51 + Roman Gushchin wrote: > On Thu, Aug 22, 2019 at 04:27:09PM -0700, Andrew Morton wrote: > > On Mon, 19 Aug 2019 16:00:51 -0700 Roman Gushchin wrote: > > > > > v3: > > > 1) rearranged patches [2/3] and [3/3] to make [1/2] and

Re: [PATCH v3] psi: get poll_work to run when calling poll syscall next time

On Fri, 23 Aug 2019 08:53:09 +0800 Joseph Qi wrote: > > Should this be backported into -stable kernels? > > > Sorry for missing that, should I resend it with cc stable tag? I added cc:stable to this patch.

Re: [PATCHv2] lib/test_kasan: add roundtrip tests

On Fri, 23 Aug 2019 11:41:08 +0100 Mark Rutland wrote: > > > > /* > > > > which is really kinda wrong. We should strictly include linux/io.h for > > things like virt_to_phys(). > > > > So I think I'll stick with v1 plus my fixlet: > > > > ---

Re: [PATCH] Partially revert "mm/memcontrol.c: keep local VM counters in sync with the hierarchical ones"

On Sat, 17 Aug 2019 19:15:23 + Roman Gushchin wrote: > > > Fixes: 766a4c19d880 ("mm/memcontrol.c: keep local VM counters in sync > > > with the hierarchical ones") > > > Signed-off-by: Roman Gushchin > > > Cc: Yafang Shao > > > Cc: Johannes Weiner > > > --- > > > mm/memcontrol.c | 8

Re: [PATCHv2] lib/test_kasan: add roundtrip tests

On Mon, 19 Aug 2019 17:14:49 +0100 Mark Rutland wrote: > In several places we need to be able to operate on pointers which have > gone via a roundtrip: > > virt -> {phys,page} -> virt > > With KASAN_SW_TAGS, we can't preserve the tag for SLUB objects, and the > {phys,page} -> virt

Re: [PATCH v3 0/3] vmstats/vmevents flushing

On Mon, 19 Aug 2019 16:00:51 -0700 Roman Gushchin wrote: > v3: > 1) rearranged patches [2/3] and [3/3] to make [1/2] and [2/2] suitable > for stable backporting > > v2: > 1) fixed !CONFIG_MEMCG_KMEM build by moving memcg_flush_percpu_vmstats() > and memcg_flush_percpu_vmevents() out of

Re: [PATCH 2/2 v2] mm/zsmalloc.c: Fix race condition in zs_destroy_pool

On Tue, 20 Aug 2019 11:59:39 +0900 Sergey Senozhatsky wrote: > On (08/09/19 11:17), Henry Burns wrote: > > In zs_destroy_pool() we call flush_work(>free_work). However, we > > have no guarantee that migration isn't happening in the background > > at that time. > > > > Since migration can't

Re: [PATCH v3] psi: get poll_work to run when calling poll syscall next time

On Thu, 22 Aug 2019 16:11:15 -0700 Suren Baghdasaryan wrote: > On Thu, Aug 22, 2019 at 3:21 PM Andrew Morton > wrote: > > > > On Wed, 21 Aug 2019 11:26:25 +0800 Joseph Qi > > wrote: > > > > > Only when calling the poll syscall the first time can user

Re: [PATCH] parisc: fix compilation errrors

On Thu, 22 Aug 2019 16:04:38 -0700 Guenter Roeck wrote: > >>> Fixes: 0cfaee2af3a0 ("include/asm-generic/5level-fixup.h: fix variable > >>> 'p4d' set but not used") > >>> Reported-by: Guenter Roeck > >>> Signed-off-by: Qian Cai > >> > >> Tested-by: Guenter Roeck > > > > Acked-by: Helge

Re: [PATCH v2 0/4] debug_pagealloc improvements through page_owner

On Tue, 20 Aug 2019 15:18:24 +0200 Vlastimil Babka wrote: > v2: also fix THP split handling (added Patch 1) per Kirill > > The debug_pagealloc functionality serves a similar purpose on the page > allocator level that slub_debug does on the kmalloc level, which is to detect > bad users. One

Re: [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler

On Tue, 20 Aug 2019 09:47:55 -0700 Kees Cook wrote: > Reply-To: 20190819234111.9019-8-keesc...@chromium.org Really? > Subject: [PATCH v2 7/7] bug: Move WARN_ON() "cut here" into exception handler It's strange to receive a standalone [7/7] patch. > Date: Tue, 20 Aug 2019 09:47:55 -0700 >

Re: [PATCH v3] psi: get poll_work to run when calling poll syscall next time

On Wed, 21 Aug 2019 11:26:25 +0800 Joseph Qi wrote: > Only when calling the poll syscall the first time can user > receive POLLPRI correctly. After that, user always fails to > acquire the event signal. > > Reproduce case: > 1. Get the monitor code in Documentation/accounting/psi.txt > 2. Run

Re: [PATCH v2 2/3] mm: memcontrol: flush percpu slab vmstats on kmem offlining

On Mon, 19 Aug 2019 13:23:37 -0700 Roman Gushchin wrote: > I've noticed that the "slab" value in memory.stat is sometimes 0, > even if some children memory cgroups have a non-zero "slab" value. > The following investigation showed that this is the result > of the kmem_cache reparenting in

Re: tmpfs: fixups to use of the new mount API

On Mon, 19 Aug 2019 15:09:14 -0700 (PDT) Hugh Dickins wrote: > Several fixups to shmem_parse_param() and tmpfs use of new mount API: > > mm/shmem.c manages filesystem named "tmpfs": revert "shmem" to "tmpfs" > in its mount error messages. > > /sys/kernel/mm/transparent_hugepage/shmem_enabled

Re: cleanup the walk_page_range interface

On Fri, 16 Aug 2019 14:32:58 +0200 Christoph Hellwig wrote: > On Fri, Aug 16, 2019 at 11:57:40AM +, Jason Gunthorpe wrote: > > Are there conflicts with trees other than hmm? > > > > We can put it on a topic branch and merge to hmm to resolve. If hmm > > has problems then send the topic on

Re: [PATCH 1/4] resource: add a not device managed request_free_mem_region variant

On Fri, 16 Aug 2019 08:54:31 +0200 Christoph Hellwig wrote: > Just add a simple macro that passes a NULL dev argument to > dev_request_free_mem_region, and call request_mem_region in the > function for that particular case. Nit: > +struct resource *request_free_mem_region(struct resource

Re: [PATCH 4/4] memremap: provide a not device managed memremap_pages

On Fri, 16 Aug 2019 08:54:34 +0200 Christoph Hellwig wrote: > The kvmppc ultravisor code wants a device private memory pool that is > system wide and not attached to a device. Instead of faking up one > provide a low-level memremap_pages for it. Note that this function is > not exported, and

Re: [PATCH RFC 3/2] fstests: check that we can't write to swap files

On Thu, 15 Aug 2019 09:34:34 -0700 "Darrick J. Wong" wrote: > While active, the media backing a swap file is leased to the kernel. > Userspace has no business writing to it. Make sure we can't do this. I don't think this tests the case where a file was already open for writing and someone

<    2   3   4   5   6   7   8   9   10   11   >