On Wed, 10 Mar 2021 10:46:13 + Mel Gorman
wrote:
> This series introduces a bulk order-0 page allocator with sunrpc and
> the network page pool being the first users.
Right now, the [0/n] doesn't even tell us that it's a performance
patchset!
The whole point of this patchset appears to a
On Wed, 10 Mar 2021 10:46:15 + Mel Gorman
wrote:
> This patch adds a new page allocator interface via alloc_pages_bulk,
> and __alloc_pages_bulk_nodemask. A caller requests a number of pages
> to be allocated and added to a list. They can be freed in bulk using
> free_pages_bulk().
Why am I
On Wed, 10 Mar 2021 10:01:04 -0800 Minchan Kim wrote:
> Currently, debugging CMA allocation failures is quite limited.
> The most commong source of these failures seems to be page
> migration which doesn't provide any useful information on the
> reason of the failure by itself. alloc_contig_range
On Mon, 1 Mar 2021 07:27:57 + (GMT) Phillip Lougher
wrote:
> The checks for maximum metadata block size is
> missing SQUASHFS_BLOCK_OFFSET (the two byte length
> count).
There is no definition of SQUASHFS_BLOCK_OFFSET. Makes compiler unhappy.
On Mon, 8 Mar 2021 12:20:47 -0800 Minchan Kim wrote:
> alloc_contig_range is usually used on cma area or movable zone.
> It's critical if the page migration fails on those areas so
> dump more debugging message.
>
> page refcount, mapcount with page flags on dump_page are
> helpful information
On Mon, 8 Mar 2021 20:47:31 + Matthew Wilcox wrote:
> On Mon, Mar 08, 2021 at 12:42:27PM -0800, Andrew Morton wrote:
> > On Mon, 8 Mar 2021 09:41:38 +0100 Michal Hocko wrote:
> >
> > > On Fri 05-03-21 15:58:40, Andrew Morton wrote:
> > > > On Fri, 5
On Mon, 8 Mar 2021 09:41:38 +0100 Michal Hocko wrote:
> On Fri 05-03-21 15:58:40, Andrew Morton wrote:
> > On Fri, 5 Mar 2021 12:52:52 +0100 Michal Hocko wrote:
> >
> > > On Thu 04-03-21 07:40:53, Zhou Guanghui wrote:
> > > > As described in the spli
On Sat, 6 Mar 2021 00:54:32 +0100 Andrey Konovalov
wrote:
> On Sat, Mar 6, 2021 at 12:50 AM Andrew Morton
> wrote:
> >
> > On Sat, 6 Mar 2021 00:36:33 +0100 Andrey Konovalov
> > wrote:
> >
> > > Currently, kasan_free_nondeferred_pages()-&g
On Mon, 15 Feb 2021 22:26:34 +0200 Topi Miettinen wrote:
> Memory mappings inside kernel allocated with vmalloc() are in
> predictable order and packed tightly toward the low addresses, except
> for per-cpu areas which start from top of the vmalloc area. With
> new kernel boot parameter 'randomiz
On Thu, 18 Feb 2021 15:57:44 -0800 Saravanan D wrote:
> To help with debugging the sluggishness caused by TLB miss/reload,
> we introduce monotonic hugepage [direct mapped] split event counts since
> system state: SYSTEM_RUNNING to be displayed as part of
> /proc/vmstat in x86 servers
>
> ...
>
>
On Fri, 5 Mar 2021 12:52:52 +0100 Michal Hocko wrote:
> On Thu 04-03-21 07:40:53, Zhou Guanghui wrote:
> > As described in the split_page function comment, for the non-compound
> > high order page, the sub-pages must be freed individually. If the
> > memcg of the fisrt page is valid, the tail pag
On Sat, 6 Mar 2021 00:36:33 +0100 Andrey Konovalov
wrote:
> Currently, kasan_free_nondeferred_pages()->kasan_free_pages() is called
> after debug_pagealloc_unmap_pages(). This causes a crash when
> debug_pagealloc is enabled, as HW_TAGS KASAN can't set tags on an
> unmapped page.
>
> This patc
On Thu, 4 Mar 2021 22:05:48 +0100 Alexander Potapenko wrote:
> On Thu, Mar 4, 2021 at 9:53 PM Marco Elver wrote:
> >
> > cache_alloc_debugcheck_after() performs checks on an object, including
> > adjusting the returned pointer. None of this should apply to KFENCE
> > objects. While for non-bulk
On Thu, 4 Mar 2021 13:41:27 +0100 Daniel Lezcano
wrote:
> > Also, why make them signed types? Negative Hz is physically
> > nonsensical. If that upsets some code somewhere because it was dealing
> > with signed types then, well, that code needed fixing anyway.
> >
> > Ditto MILLIWATT_PER_WATT
On Wed, 3 Mar 2021 17:38:12 -0800 Minchan Kim wrote:
> > > #endif
> > > char name[CMA_MAX_NAME];
> > > +#ifdef CONFIG_CMA_SYSFS
> > > + struct cma_stat *stat;
> > > +#endif
> > > };
> >
> > Why aren't the stat fields simply placed directly into struct cma_stat?
>
> It have a related long di
On Tue, 23 Feb 2021 23:11:43 +0800 Eric Gao wrote:
> sometimes, we need the msgsnd or msgrcv syscall can return after a limited
> time, so that the business thread do not be blocked here all the time. In
> this case, I add the msgsnd_timed and msgrcv_timed syscall that with time
> parameter, whic
On Wed, 24 Feb 2021 10:39:36 +0200 Andy Shevchenko
wrote:
> On Wednesday, February 24, 2021, Andy Shevchenko
> wrote:
>
> >
> >
> > On Tuesday, February 23, 2021, Daniel Lezcano
> > wrote:
> >
> >> The macro for the unit conversion for frequency is duplicated in
> >> different places.
> >>
>
On Fri, 26 Feb 2021 02:25:37 +0100 Andrey Konovalov
wrote:
> Currently, kasan_free_nondeferred_pages()->kasan_free_pages() is called
> after debug_pagealloc_unmap_pages(). This causes a crash when
> debug_pagealloc is enabled, as HW_TAGS KASAN can't set tags on an
> unmapped page.
>
> This patc
On Wed, 3 Mar 2021 19:38:30 +0100 Borislav Petkov wrote:
> On Tue, Mar 02, 2021 at 04:09:35PM -0800, Andrew Morton wrote:
> > > arch/x86/mm/init_64.c | 189
> > > +++---
> >
> > Perhaps a better route would be via an
On Wed, 3 Mar 2021 12:50:53 -0800 Minchan Kim wrote:
> Since CMA is getting used more widely, it's more important to
> keep monitoring CMA statistics for system health since it's
> directly related to user experience.
>
> This patch introduces sysfs statistics for CMA, in order to provide
> som
On Sun, 28 Feb 2021 14:44:14 -0800 Lior Ribak wrote:
> There is a deadlock in bm_register_write:
> First, in the beggining of the function, a lock is taken on the
> binfmt_misc root inode with inode_lock(d_inode(root))
> Then, if the user used the MISC_FMT_OPEN_FILE flag, the function will
> call
On Mon, 1 Mar 2021 07:27:57 + (GMT) Phillip Lougher
wrote:
> The checks for maximum metadata block size is
> missing SQUASHFS_BLOCK_OFFSET (the two byte length
> count).
What are the user visible consequences of this bug?
> Cc: sta...@vger.kernel.org
> Signed-off-by: Phillip Lougher
Fixe
On Tue, 2 Mar 2021 15:53:39 -0800 Suren Baghdasaryan wrote:
> Hi Andrew,
> A friendly reminder to please include this patch into mm tree.
> There seem to be no more questions or objections.
> The man page you requested is accepted here:
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.gi
On Mon, 1 Mar 2021 09:32:27 +0100 Oscar Salvador wrote:
> Hi Andrew,
>
> Now that 5.12-rc1 is out, and as discussed, here there is a new version on top
> of it.
> Please, consider picking up the series.
>
I grabbed them, but...
>
> arch/x86/mm/init_64.c | 189
>
On Mon, 1 Mar 2021 20:57:01 +0800 Wang Qing wrote:
> Smatch gives the warning:
> do_numa_page() warn: assigning (-11) to unsigned variable 'migrated'
>
> ...
>
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4102,7 +4102,6 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
> int
On Mon, 1 Mar 2021 09:11:51 -0500 Peter Xu wrote:
> On Wed, Feb 17, 2021 at 06:35:42PM -0500, Peter Xu wrote:
> > v5:
> > - patch 4: change "int cow" into "bool cow"
> > - collect r-bs for Jason
>
> Andrew,
>
> I just noticed 5.12-rc1 has released; is this series still possible to make it
> for
On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt wrote:
> From: Palmer Dabbelt
>
> This is only useful under CONFIG_NUMA. IIUC skipping the check is the
> right thing to do here, as without CONFIG_NUMA there will never be any
> large node distances on non-NUMA systems.
>
> I expected this to
On Fri, 26 Feb 2021 00:43:51 +0200 Mike Rapoport wrote:
> From: Mike Rapoport
>
> There could be struct pages that are not backed by actual physical memory.
> This can happen when the actual memory bank is not a multiple of
> SECTION_SIZE or when an architecture does not register memory holes
>
On Thu, 25 Feb 2021 12:03:48 -0800 Kees Cook wrote:
> On Thu, Feb 25, 2021 at 05:45:09PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > Separating compiler-clang.h from compiler-gcc.h inadventently dropped the
> > definitions of the three HAVE_BUILTIN_BSWAP macros, which requires f
On Wed, 24 Feb 2021 10:09:25 -0800 Doug Anderson wrote:
> On Wed, Feb 24, 2021 at 12:17 AM Sumit Garg wrote:
> >
> > Currently breakpoints in kernel .init.text section are not handled
> > correctly while allowing to remove them even after corresponding pages
> > have been freed.
> >
> > Fix it v
On Wed, 24 Feb 2021 01:48:07 -0700 Yu Zhao wrote:
> Currently page_lru() uses Page{Active,Unevictable} to determine which
> lru list a page belongs to. Page{Active,Unevictable} contain
> compound_head() and therefore page_lru() essentially tests
> PG_{active,unevictable} against compound_head(pag
On Tue, 23 Feb 2021 17:29:48 -0800 Mike Kravetz wrote:
> >> I will do a bit more verification and put together a patch (it should
> >> be simple).
> >
> > There's also Michel's documentation request:
> > https://lkml.kernel.org/r/20210127102645.gh...@dhcp22.suse.cz
> >
>
> Thanks Andrew, I for
On Tue, 23 Feb 2021 16:12:17 +0100 Johannes Berg
wrote:
> On Thu, 2020-12-17 at 09:31 +0100, Jan Kiszka wrote:
> > On 17.12.20 09:17, Johannes Berg wrote:
> > > From: Johannes Berg
> > >
> > > If we store the relative path, the user might later cd to a
> > > different directory, and that would
On Tue, 23 Feb 2021 10:06:12 -0800 Mike Kravetz wrote:
> On 2/23/21 6:57 AM, Gerald Schaefer wrote:
> > Hi,
> >
> > LTP triggered a panic on s390 in hugepage_subpool_put_pages() with
> > linux-next 5.12.0-20210222, see below.
> >
> > It crashes on the spin_lock(&spool->lock) at the beginning, b
Do you feel this patchset is ready to merge up?
https://lore.kernel.org/linux-mm/f6914405b49d9...@google.com/
was addressed by 0060ef3b4e6dd ("mm: support THPs in
zero_user_segments"), yes?
"mm/truncate,shmem: Handle truncates that split THPs" and "mm/filemap:
Return only head pages f
On Tue, 26 Jan 2021 15:14:38 -0700 Yu Zhao wrote:
> On Tue, Jan 26, 2021 at 10:01:11PM +, Matthew Wilcox wrote:
> > On Fri, Jan 22, 2021 at 03:05:53PM -0700, Yu Zhao wrote:
> > > +++ b/mm/swap.c
> > > @@ -231,7 +231,7 @@ static void pagevec_move_tail_fn(struct page *page,
> > > struct lruvec
On Fri, 19 Feb 2021 01:54:30 + Anton Altaparmakov wrote:
> Hi Andrew,
>
> Can you please push this one upstream? Thanks a lot in advance!
The changelog is a bit brief...
>
> > On 17 Feb 2021, at 15:59, Rustam Kovhaev wrote:
> >
> > we should check for valid STANDARD_INFORMATION attribu
On Thu, 18 Feb 2021 14:36:31 -0700 Jens Axboe wrote:
> Currently we cap the batch count at max(32, 2*nr_online_cpus), which these
> days is kind of silly as systems have gotten much bigger than in 2009 when
> this heuristic was introduced.
>
> Bump it to capping it at 256 instead. This has a not
On Mon, 15 Feb 2021 11:32:01 -0800 Daniel Gimpelevich
wrote:
> On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote:
> > On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker wrote:
> > > On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote:
> > > > The pa
On Wed, 17 Feb 2021 10:49:25 -0800 Mike Kravetz wrote:
> page structs are not guaranteed to be contiguous for gigantic pages. The
> routine update_and_free_page can encounter a gigantic page, yet it assumes
> page structs are contiguous when setting page flags in subpages.
>
> If update_and_fre
On Fri, 12 Feb 2021 22:01:38 +0100 Andrey Konovalov
wrote:
> On Fri, Feb 12, 2021 at 9:54 PM Andrew Morton
> wrote:
> >
> > On Fri, 12 Feb 2021 21:21:39 +0100 Andrey Konovalov
> > wrote:
> >
> > > > > The wrappers aren't defined when tests
On Fri, 12 Feb 2021 21:21:39 +0100 Andrey Konovalov
wrote:
> > > The wrappers aren't defined when tests aren't enabled to avoid misuse.
> > > The mte_() functions aren't exported directly to avoid having low-level
> > > KASAN ifdefs in the arch code.
> > >
> >
> > Please confirm that this is app
On Fri, 12 Feb 2021 21:08:52 +0100 Andrey Konovalov
wrote:
> Currently, building KASAN-KUnit tests as a module fails with:
>
> ERROR: modpost: "mte_enable_kernel" [lib/test_kasan.ko] undefined!
> ERROR: modpost: "mte_set_report_once" [lib/test_kasan.ko] undefined!
>
> This change adds KASAN wr
On Wed, 10 Feb 2021 16:33:07 -0800 Ira Weiny wrote:
> > Signed-off-by: Ira Weiny
>
> This already has my signed off by so I'm not going to 'review'. With Prathu's
> testing information I hope this can land.
>
> Andrew did you see this patch?
I did now ;)
Tossed onto the post-rc1 pile, thank
On Tue, 9 Feb 2021 14:03:29 -0800 Ira Weiny wrote:
> On Tue, Feb 09, 2021 at 01:58:37PM -0800, Andrew Morton wrote:
> > On Tue, 9 Feb 2021 13:52:29 -0800 Ira Weiny wrote:
> >
> > > >
> > > > Let's please queue this up separately.
> > >
&
On Tue, 9 Feb 2021 13:52:29 -0800 Ira Weiny wrote:
> >
> > Let's please queue this up separately.
>
> Ok can I retain your Ack on the move part of the patch?
I missed that.
> Note that it does change kmap_atomic() to kmap_local_page() currently.
>
> Would you prefer a separate change for th
On Tue, 9 Feb 2021 12:52:49 -0800 Ira Weiny wrote:
> On Tue, Feb 09, 2021 at 11:09:31AM -0800, Andrew Morton wrote:
> > On Tue, 9 Feb 2021 16:11:23 +0100 David Sterba wrote:
> >
> > > On Fri, Feb 05, 2021 at 03:23:00PM -0800, ira.we...@intel.com wrote:
On Tue, 9 Feb 2021 15:21:28 +0900 Naoya Horiguchi
wrote:
> Currently hwpoison code checks PageAnon() for thp and refuses to handle
> errors on non-anonymous thps (just for historical reason). We now
> support non-anonymou thp like shmem one, so this patch suggests to enable
> to handle shmem t
the upcoming merge
> window and then I can prepare a separate pull with just the cleanups.
> Removing an inter-tree patch dependency was a sufficient reason for
> Linus in the past for such pull requests.
It would be best to merge [1/4] via the btrfs tree. Please add my
Acked-by: Andr
On Tue, 9 Feb 2021 17:02:56 + Catalin Marinas
wrote:
> On Tue, Feb 09, 2021 at 04:32:30PM +0100, Andrey Konovalov wrote:
> > diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> > index a66c2806fc4d..788ef0c3a25e 100644
> > --- a/arch/arm64/kernel/mte.c
> > +++ b/arch/arm64/kerne
On Mon, 8 Feb 2021 13:08:20 +0200 Mike Rapoport wrote:
> There could be struct pages that are not backed by actual physical memory.
> This can happen when the actual memory bank is not a multiple of
> SECTION_SIZE or when an architecture does not register memory holes
> reserved by the firmware
On Mon, 8 Feb 2021 07:06:58 -0600 Seth Forshee
wrote:
> On Sun, Feb 07, 2021 at 05:48:31PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Feb 05, 2021 at 05:06:20PM -0600, Seth Forshee wrote:
> > > This feature requires ino_t be 64-bits, which is true for every
> > > 64-bit architecture but s390,
On Sat, 6 Feb 2021 14:29:24 -0800 Jakub Kicinski wrote:
> On Fri, 5 Feb 2021 14:35:50 -0800 Andrew Morton wrote:
> > On Fri, 05 Feb 2021 11:36:30 +1100 NeilBrown wrote:
> >
> > > A recent change to seq_file broke some users which were using seq_file
> > > in
On Fri, 5 Feb 2021 12:22:18 -0800 Nick Desaulniers
wrote:
> We expect toolchains to produce these new debug info sections as part of
> DWARF v5. Add explicit placements to prevent the linker warnings from
> --orphan-section=warn.
>
> Compilers may produce such sections with explicit -gdwarf-5,
30620.518245-1-seth.fors...@canonical.com
Fixes: ea3271f7196c ("tmpfs: support 64-bit inums per-sb")
Signed-off-by: Seth Forshee
Cc: Chris Down
Cc: Hugh Dickins
Cc: Amir Goldstein
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: [5.9+]
Signed-off-by: Andrew Morton
---
On Wed, 3 Feb 2021 14:14:50 +0800 Shaokun Zhang
wrote:
> From: Yang Guo
>
> clear_buffer_new() is used to clear buffer new stat. When PAGE_SIZE
> is 64K, most buffer heads in the list are not needed to clear.
> clear_buffer_new() has an enpensive atomic modification operation,
> Let's add chec
On Fri, 05 Feb 2021 11:36:30 +1100 NeilBrown wrote:
> A recent change to seq_file broke some users which were using seq_file
> in a non-"standard" way ... though the "standard" isn't documented, so
> they can be excused. The result is a possible leak - of memory in one
> case, of references to
On Fri, 5 Feb 2021 14:55:43 -0600 Seth Forshee
wrote:
> On Fri, Feb 05, 2021 at 12:41:57PM -0800, Andrew Morton wrote:
> > On Fri, 5 Feb 2021 14:21:59 -0600 Seth Forshee
> > wrote:
> >
> > > Currently there seems to be an assumption in tmpfs that 64-bit
>
On Fri, 5 Feb 2021 12:00:05 -0700 Nathan Chancellor wrote:
> > > > Reviewed-by: Nathan Chancellor
> > >
> > > Ping? It is pretty late into the 5.11 cycle and this is still broken.
> >
> > I think we should just do the __always_inline. Who can take this?
>
> This should probably go through -mm
On Fri, 5 Feb 2021 14:21:59 -0600 Seth Forshee
wrote:
> Currently there seems to be an assumption in tmpfs that 64-bit
> architectures also have a 64-bit ino_t. This is not true; s390 at
> least has a 32-bit ino_t. With CONFIG_TMPFS_INODE64=y tmpfs
> mounts will get 64-bit inode numbers and dis
On Thu, 4 Feb 2021 13:02:46 + Phillip Lougher
wrote:
> This is a regression introduced by the patch "migrate from ll_rw_block
> usage to BIO".
Fixes: 93e72b3c612adc ("squashfs: migrate from ll_rw_block usage to BIO")
> Sysbot/Syskaller has reported a number of "out of bounds writes" and
>
On Tue, 2 Feb 2021 10:03:47 -0500 Pavel Tatashin
wrote:
> The same problem as fixed here:
> https://lore.kernel.org/linux-mm/CA+CK2bBjC8=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@mail.gmail.com/
>
We're seeing a number of build errors from this series, all of them
confusing.
I'll drop this vers
On Wed, 3 Feb 2021 10:19:44 + (UTC) Christophe Leroy
wrote:
> Commit 83d116c53058 ("mm: fix double page fault on arm64 if PTE_AF
> is cleared") introduced arch_faults_on_old_pte() helper to identify
> platforms that don't set page access bit in HW and require a page
> fault to set it.
>
>
On Mon, 1 Feb 2021 22:55:47 -0800 Chris Goldsworthy
wrote:
> Pages containing buffer_heads that are in the buffer_head LRU cache
> will be pinned and thus cannot be migrated. Correspondingly,
> invalidate the BH LRU before a migration starts and stop any
> buffer_head from being cached in the
On Mon, 1 Feb 2021 06:43:19 -0500 Miaohe Lin wrote:
> The condition (A && !C && !D) || !A is equivalent to !A || (A && !C && !D)
> and can be further simplified to !A || (!C && !D).
>
> ..
>
> --- a/mm/pgtable-generic.c
> +++ b/mm/pgtable-generic.c
> @@ -135,8 +135,8 @@ pmd_t pmdp_huge_clear_flu
On Mon, 1 Feb 2021 20:43:34 +0100 Andrey Konovalov
wrote:
> This change provides a simpler implementation of mte_get_mem_tag(),
> mte_get_random_tag(), and mte_set_mem_tag_range().
>
> Simplifications include removing system_supports_mte() checks as these
> functions are onlye called from KASA
On Thu, 28 Jan 2021 14:00:29 -0800 Mike Kravetz wrote:
> On 1/28/21 1:37 PM, Andrew Morton wrote:
> > On Thu, 28 Jan 2021 06:52:21 +0100 Oscar Salvador wrote:
> >
> >> On Wed, Jan 27, 2021 at 03:36:41PM -0800, Mike Kravetz wrote:
> >>> Yes, this patch i
On Thu, 28 Jan 2021 06:52:21 +0100 Oscar Salvador wrote:
> On Wed, Jan 27, 2021 at 03:36:41PM -0800, Mike Kravetz wrote:
> > Yes, this patch is somewhat optional. It should be a minor improvement
> > in cases where we are dealing with hpages in a non-migratable hstate.
> > Although, I do not bel
On Thu, 28 Jan 2021 16:18:23 +0100 Vlastimil Babka wrote:
> On 1/28/21 3:17 PM, Colin King wrote:
> > From: Colin Ian King
> >
> > In the case where zpool_can_sleep_mapped(pool) returns 0
> > then tmp is not allocated and tmp is then an uninitialized
> > pointer. Later if entry is null, tmp is
On Wed, 27 Jan 2021 17:36:38 +0530 vji...@codeaurora.org wrote:
> Add a kernel parameter stack_depot_disable to disable
> stack depot. So that stack hash table doesn't consume
> any memory when stack depot is disabled.
>
> The usecase is CONFIG_PAGE_OWNER without page_owner=on.
> Without this pat
On Wed, 27 Jan 2021 10:08:22 +0800 Miaohe Lin wrote:
> On 2021/1/27 8:06, Mike Kravetz wrote:
> > On 1/26/21 3:55 AM, Miaohe Lin wrote:
> >> When subpool max_hpages accounting is not enabled, used_hpages is always 0
> >> and might lead to release subpool prematurely because it indicates no pages
On Wed, 27 Jan 2021 04:33:49 -0500 Miaohe Lin wrote:
> For PMD-mapped page (usually THP), pvmw->pte is NULL. For PTE-mapped THP,
> pvmw->pte is mapped. But for HugeTLB pages, pvmw->pte is not mapped and set
> to the relevant page table entry. So in page_vma_mapped_walk_done(), we may
> do pte_unm
On Tue, 26 Jan 2021 19:54:12 +0100 Piotr Figiel wrote:
> For userspace checkpoint and restore (C/R) some way of getting process
> state containing RSEQ configuration is needed.
>
> There are two ways this information is going to be used:
> - to re-enable RSEQ for threads which had it enabled be
On Mon, 25 Jan 2021 20:47:49 +0800 Zou Wei wrote:
> Fix the following versioncheck warning:
>
> kernel/sys.c:42:1: unused including
>
> ...
>
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -39,7 +39,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
>
x86 all
On Mon, 25 Jan 2021 11:20:02 +0800 Baolin Wang
wrote:
> We've already set the variable 'i' 's initial value before using it,
> thus remove redundant previous assignment of variable 'i'.
>
> ...
>
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2472,7 +2472,6 @@ ssize_t generic_file_buffered_rea
On Mon, 25 Jan 2021 09:12:56 -0500 Waiman Long wrote:
> Yes, this patch should go to stable. I think the stable tree maintainers
> will automatically pick up patches with the "Fixes" tag. That is why I
> don't explicitly put a "cc:stable" line in the patch.
No. Both the Fixes: and the cc:stab
On Fri, 4 Dec 2020 13:38:25 +0100 Marco Elver wrote:
> On Fri, Dec 04, 2020 at 01:18PM +0100, Anders Roxell wrote:
> > When building kfence the following error shows up:
> >
> > In file included from mm/kfence/report.c:13:
> > arch/arm64/include/asm/kfence.h: In function ‘kfence_protect_page’:
>
On Fri, 22 Jan 2021 01:37:14 -0300 Thiago Jung Bauermann
wrote:
> Mike Rapoport writes:
>
> > > Signed-off-by: Roman Gushchin
> >
> > Reviewed-by: Mike Rapoport
>
> I've seen a couple of spurious triggers of the WARN_ONCE() removed by this
> patch. This happens on some ppc64le bare metal (
On Fri, 22 Jan 2021 16:27:23 +0800 Miaohe Lin wrote:
> Hi Andrew:
> On 2021/1/14 10:51, Miaohe Lin wrote:
> > Hi:
> > On 2021/1/11 1:14, Andi Kleen wrote:
> >> On Sat, Jan 09, 2021 at 03:01:18AM -0500, Miaohe Lin wrote:
> >>> Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileg
On Wed, 20 Jan 2021 16:29:20 +0200 Jarkko Sakkinen wrote:
>
>
> On Mon, Jan 18, 2021 at 09:33:10PM +0800, Tianjia Zhang wrote:
> > Obviously, the error variable detection of the if statement is
> > for the mprotect callback function, so it is also put into the
> > scope of calling callbck.
> >
On Thu, 21 Jan 2021 14:27:12 +0200 Mike Rapoport wrote:
> @Andrew, this is based on v5.11-rc4-mmots-2021-01-19-13-54 with secretmem
> patches dropped from there, I can rebase whatever way you prefer.
Thanks. I merged this version.
Silently, to avoid spraying out all those emails again ;)
soft-offline: convert parameter to pfn")
> Cc: Andrew Morton
> Cc: Naoya Horiguchi
> Cc: Michal Hocko
> Reviewed-by: David Hildenbrand
> Reviewed-by: Oscar Salvador
> Cc:
> Signed-off-by: Dan Williams
A cc:stable patch in the middle is awkward. I'll make this a
On Thu, 14 Jan 2021 15:15:16 -0800 Florian Fainelli
wrote:
> On systems with large amounts of reserved memory we may fail to
> successfully complete unpack_to_rootfs() and be left with:
>
> Kernel panic - not syncing: write error
>
> this is not too helpful to understand what happened, so let
On Wed, 13 Jan 2021 19:33:06 +0530 Charan Teja Reddy
wrote:
> should_proactive_compact_node() returns true when sum of the
> fragmentation score of all the zones in the node is greater than the
> wmark_high of compaction which then triggers the proactive compaction
> that operates on the individ
On Wed, 13 Jan 2021 10:16:55 +0100 Alexander Potapenko
wrote:
> With the introduction of various production error-detection tools, such as
> MTE-based KASAN and KFENCE, the need arises to efficiently notify the
> userspace OS components about kernel errors. Currently, no facility exists
> to not
On Tue, 12 Jan 2021 17:47:20 +0800 Rokudo Yan wrote:
> In fast_isolate_freepages, high_pfn will be used if a prefered one(PFN >=
> low_fn) not found. But the high_pfn
> is not reset before searching an free area, so when it was used as freepage,
> it may from another free area searched before.
On Tue, 12 Jan 2021 12:38:18 -0800 Randy Dunlap wrote:
> On 1/12/21 1:58 AM, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2021-01-12-01-57 has been uploaded to
> >
> >https://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for mm-of-the-moment
On Tue, 12 Jan 2021 14:24:05 +0800 Xiaoming Ni wrote:
> On 2021/1/12 12:33, Andrew Morton wrote:
> > On Tue, 12 Jan 2021 11:31:55 +0800 Xiaoming Ni
> > wrote:
> >
> >> The process_sysctl_arg() does not check whether val is empty before
> >> in
On Sun, 10 Jan 2021 13:03:49 +0100 Linus Walleij
wrote:
> On Sun, Jan 10, 2021 at 11:21 AM hailong wrote:
>
> > >> +#ifndef PTE_HWTABLE_PTRS
> > >> +#define PTE_HWTABLE_PTRS 0
> > >> +#endif
> > >
> > >Can this even happen? We have either pgtable-2level.h or
> > >pgtable-3level.h, both of whic
On Tue, 12 Jan 2021 11:31:55 +0800 Xiaoming Ni wrote:
> The process_sysctl_arg() does not check whether val is empty before
> invoking strlen(val). If the command line parameter () is incorrectly
> configured and val is empty, oops is triggered.
>
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/
On Mon, 11 Jan 2021 11:10:56 +0100 Petr Mladek wrote:
> Adding Kees into CC because it is security related.
> Adding Andrew into CC because he usually takes patches for hexdump.
>
> On Wed 2021-01-06 15:35:47, Timur Tabi wrote:
> > Hashed addresses are useless in hexdumps unless you're comparing
On Mon, 11 Jan 2021 09:06:22 -0800 Suren Baghdasaryan wrote:
> process_madvise currently requires ptrace attach capability.
> PTRACE_MODE_ATTACH gives one process complete control over another
> process. It effectively removes the security boundary between the
> two processes (in one direction).
On Mon, 11 Jan 2021 21:40:15 +0200 Mike Rapoport wrote:
> Commit 73a6e474cb37 ("mm: memmap_init: iterate over
> memblock regions rather that check each PFN") exposed several issues with
> the memory map initialization and these patches fix those issues.
>
> Initially there were crashes during co
eclaration of function
> > 'in_compat_syscall'; did you mean 'in_ia32_syscall'?
> > [-Werror=implicit-function-declaration]
>
> Other build failures are piling behind this.
>
> #syz fix: mm/process_vm_access: Add missing #include
For some
On Fri, 8 Jan 2021 21:10:25 +0100 Michal Hocko wrote:
> > > Why would that matter? A missing value is clearly a error path and it
> > > should be reported.
> >
> > This test is in the correct place. I think it's just a question of the
> > return values.
>
> I was probably not clear. The test fo
On Thu, 7 Jan 2021 11:59:38 -0800 Mike Kravetz wrote:
> On 1/7/21 4:32 AM, Miaohe Lin wrote:
> > In hugetlb_sysfs_add_hstate(), we would do kobject_put() on hstate_kobjs
> > when failed to create sysfs group but forget to set hstate_kobjs to NULL.
> > Then in hugetlb_register_node() error path, w
(cc's added)
On Tue, 5 Jan 2021 16:43:38 -0800 Sudarshan Rajagopalan
wrote:
> Ensure that shrinkers are given the option to completely drop
> their caches even when their caches are smaller than the batch size.
> This change helps improve memory headroom by ensuring that under
> significant me
On Tue, 5 Jan 2021 17:16:03 -0800 "Paul E. McKenney" wrote:
> This is v4 of the series the improves diagnostics by providing access
> to additional information including the return addresses, slab names,
> offsets, and sizes collected by the sl*b allocators and by vmalloc().
Looks reasonable. A
On Wed, 6 Jan 2021 12:18:36 -0800 (PST) Hugh Dickins wrote:
> On Wed, 6 Jan 2021, Andrea Arcangeli wrote:
> >
> > I'd be surprised if the kernel can boot with BUG_ON() defined as "do
> > {}while(0)" so I guess it doesn't make any difference.
>
> I had been afraid of that too, when CONFIG_BUG is
On Tue, 5 Jan 2021 20:22:39 -0800 Roman Gushchin wrote:
> Imran Khan reported a regression in hackbench results caused by the
> commit f2fe7b09a52b ("mm: memcg/slab: charge individual slab objects
> instead of pages").
How large was the regression?
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.
101 - 200 of 11108 matches
Mail list logo
