On Fri, 3 Jul 2020 18:28:23 +0530 Srikar Dronamraju
wrote:
> > The memory hotplug changes that somehow because you can hotremove numa
> > nodes and therefore make the nodemask sparse but that is not a common
> > case. I am not sure what would happen if a completely new node was added
> > and
On Wed, 29 Jul 2020 19:10:39 +0200 Michal Koutný wrote:
> Hello.
>
> On Tue, Jun 23, 2020 at 11:45:14AM -0700, Roman Gushchin wrote:
> > Because the size of memory cgroup internal structures can dramatically
> > exceed the size of object or page which is pinning it in the memory, it's
> > not
On Wed, 5 Aug 2020 19:56:21 -0700 Chris Goldsworthy
wrote:
> On mobile devices, failure to allocate from a CMA area constitutes a
> functional failure. Sometimes during CMA allocations, we have observed
> that pages in a CMA area allocated through alloc_pages(), that we're trying
> to migrate
On Thu, 6 Aug 2020 16:38:04 -0700 Roman Gushchin wrote:
> it seems that Hugh and me haven't reached a consensus here.
> Can, you, please, not merge this patch into 5.9, so we would have
> more time to find a solution, acceptable for all?
No probs. I already had a big red asterisk on it ;)
On Thu, 6 Aug 2020 15:45:14 +0800 Muchun Song wrote:
> On Tue, Jul 28, 2020 at 11:49 AM Muchun Song wrote:
> >
> > In the reservation routine, we only check whether the cpuset meets
> > the memory allocation requirements. But we ignore the mempolicy of
> > MPOL_BIND case. If someone mmap
On Sat, 1 Aug 2020 17:08:26 +0800 Wenchao Hao wrote:
> Previous implement called untagged_addr before error check, while
> if the error check failed and return EINVAL, the untagged_addr is
> just useless work.
>
> ...
>
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -1632,11 +1632,11 @@
The mm-of-the-moment snapshot 2020-07-31-16-45 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Fri, 31 Jul 2020 14:24:57 -0700 "Paul E. McKenney"
wrote:
> The reason for this restriction is that in -rt, the spin_lock(>lock)
> in rmqueue_bulk() can sleep.
So if there is runtime overhead, this overhead could be restricted to
-rt kernels with suitable ifdefs?
On Thu, 30 Jul 2020 16:12:05 -0700 "Paul E. McKenney"
wrote:
> So, may we add a GFP_ flag that will cause kmalloc() and friends to return
> NULL when they would otherwise need to acquire their non-raw spinlock?
> This avoids adding any overhead to the slab-allocator fastpaths, but
> allows
On Fri, 31 Jul 2020 03:38:58 +0100 Matthew Wilcox wrote:
> On Fri, Jul 31, 2020 at 10:39:39AM +0800, qiang.zh...@windriver.com wrote:
> > The pool is being destroyed, all page which in the pool,
> > should be free. if some page is still be use by somebody,
> > we should not just output error
On Wed, 29 Jul 2020 14:21:12 -0700 Kees Cook wrote:
> On Sun, Jul 26, 2020 at 01:01:17PM +0200, Alexander A. Klimov wrote:
> > Rationale:
> > Reduces attack surface on kernel devs opening the links for MITM
> > as HTTPS traffic is much harder to manipulate.
> >
> > Signed-off-by: Alexander A.
On Wed, 29 Jul 2020 13:04:21 -0700 syzbot
wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:68845a55 Merge branch 'akpm' into master (patches from And..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17c86c5490
> kernel
On Tue, 28 Jul 2020 15:39:21 -0700 Randy Dunlap wrote:
> On 7/28/20 2:55 PM, Andrew Morton wrote:
> > On Tue, 28 Jul 2020 05:33:58 -0700 Randy Dunlap
> > wrote:
> >
> >> On 7/27/20 6:19 PM, Andrew Morton wrote:
> >>> The mm-of-the-moment s
On Wed, 29 Jul 2020 08:20:53 +1000 Stephen Rothwell
wrote:
> Hi Andrew,
>
> On Tue, 28 Jul 2020 14:55:53 -0700 Andrew Morton
> wrote:
> > config CONTIG_ALLOC
> > def_bool (MEMORY_ISOLATION && COMPACTION) || CMA
> >
> > says this is a
On Tue, 28 Jul 2020 05:33:58 -0700 Randy Dunlap wrote:
> On 7/27/20 6:19 PM, Andrew Morton wrote:
> > The mm-of-the-moment snapshot 2020-07-27-18-18 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
>
The mm-of-the-moment snapshot 2020-07-27-18-18 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Sat, 25 Jul 2020 16:07:49 +0800 Muchun Song wrote:
> In the reservation routine, we only check whether the cpuset meets
> the memory allocation requirements. But we ignore the mempolicy of
> MPOL_BIND case. If someone mmap hugetlb succeeds, but the subsequent
> memory allocation may fail due
On Wed, 22 Jul 2020 06:30:53 +0200 Joerg Vehlow wrote:
> >> About 12 years ago this was not implemented using a mutex, but using xchg.
> >> See: 8c5a1cf0ad3ac5fcdf51314a63b16a440870f6a2
> > Yes, that commit is wrong, because mutex_trylock() is not to be taken in
> > interrupt context, where
On Mon, 27 Jul 2020 08:54:41 +0200 SeongJae Park wrote:
> > > > Unfortunately, the inexperienced _do_ in fact run
> > > > checkpatch on files and submit inappropriate patches.
I don't think I really agree with the "new code only" guideline (where
did this come from, anyway?). 10 years from now
On Fri, 24 Jul 2020 15:44:23 -0400 Rich Felker wrote:
> Andrew, could you drop your copy of this
> patch?
I have done so, thanks.
On Fri, 24 Jul 2020 12:04:02 +0900 Joonsoo Kim wrote:
> 2020년 7월 24일 (금) 오전 11:36, Andrew Morton 님이 작성:
> >
> > On Fri, 24 Jul 2020 11:23:52 +0900 Joonsoo Kim wrote:
> >
> > > > > Second, clearing __GFP_MOVABLE in current_gfp_context() has a side
&
On Tue, 23 Jun 2020 17:30:18 +0800 Wei Yang
wrote:
> On Tue, Jun 23, 2020 at 09:55:43AM +0200, David Hildenbrand wrote:
> >On 23.06.20 09:39, David Hildenbrand wrote:
> >>> Hmm.. I thought this is the behavior for early section, while it looks
> >>> current
> >>> code doesn't work like this:
>
On Wed, 22 Jul 2020 16:46:50 +0200 Uladzislau Rezki wrote:
> > > I can check further, but it can be it was not correctly reverted,
> > > because everything should work just fine even with the revert,
> > > though i i do not understand a reason of reverting.
> >
> > Vlad, how sure are you about
On Fri, 24 Jul 2020 11:23:52 +0900 Joonsoo Kim wrote:
> > > Second, clearing __GFP_MOVABLE in current_gfp_context() has a side effect
> > > to exclude the memory on the ZONE_MOVABLE for allocation target.
> >
> > More whoops.
> >
> > Could we please have a description of the end-user-visible
On Thu, 23 Jul 2020 10:49:02 +0900 js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> Currently, memalloc_nocma_{save/restore} API that prevents CMA area
> in page allocation is implemented by using current_gfp_context(). However,
> there are two problems of this implementation.
>
> First, this
On Thu, 23 Jul 2020 14:29:33 +0800 Feng Tang wrote:
> > > gcc has an option '-falign-functions=n' to force text aligned, and with
> > > that option enabled, some of those performance changes will be gone,
> > > like [1][2][3].
> > >
> > > Add this option so that developers and 0day can easily
On Thu, 23 Jul 2020 11:30:01 +0800 Feng Tang wrote:
> Recently 0day reported many strange performance changes (regression
> or improvement), in which there was no obvious relation between
> the culprit commit and the benchmark at the first look, and it causes
> people to doubt the test itself is
On Tue, 21 Jul 2020 15:04:49 +0200 Christoph Hellwig wrote:
> Add a helper that waits for a pid and stores the status in the passed
> in kernel pointer. Use it to fix the usage of kernel_wait4 in
> call_usermodehelper_exec_sync that only happens to work due to the
> implicit set_fs(KERNEL_DS)
On Tue, 21 Jul 2020 17:41:06 +0200 Peter Zijlstra wrote:
>
> For SMP systems using IPI based TLB invalidation, looking at
> current->active_mm is entirely reasonable. This then presents the
> following race condition:
>
>
> CPU0CPU1
>
> flush_tlb_mm(mm)
The mm-of-the-moment snapshot 2020-07-20-19-06 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Sun, 19 Jul 2020 14:10:19 -0700 syzbot
wrote:
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:4c43049f Add linux-next specific files for 20200716
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=12c5608710
> kernel
On Mon, 20 Jul 2020 13:56:15 +0900 js1...@gmail.com wrote:
> Currently, preventing cma area in page allocation is implemented by using
> current_gfp_context(). However, there are two problems of this
> implementation.
>
> First, this doesn't work for allocation fastpath. In the fastpath,
>
On Mon, 20 Jul 2020 13:56:15 +0900 js1...@gmail.com wrote:
> Currently, preventing cma area in page allocation is implemented by using
> current_gfp_context(). However, there are two problems of this
> implementation.
>
> First, this doesn't work for allocation fastpath. In the fastpath,
>
On Mon, 20 Jul 2020 13:42:45 +0800 Alex Shi wrote:
>
> For couple of vmstat account funcs, the caller usually doesn't check the
> delta value, if delta == 0, irq or atomic operator is a waste. That's
> better to be skipped, also add unlikey() since !delta is less happened.
>
> ...
>
> ---
On Mon, 20 Jul 2020 09:44:29 +0200 Jiri Slaby wrote:
> When addr2line returns more than one location, decode_stacktrace does
> not currently remove base path from the paths. So the result might look
> like (line wrapped here):
> ptrace_stop (include/linux/freezer.h:57
>
>
The mm-of-the-moment snapshot 2020-07-16-22-52 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
pport.amd.com/us/Processor_TechDocs/41322.pdf, Erratum
> > * 383 on page 93. Intel should be safe but is also warns that it's
>
> Well, it was a good opportunity to find out that the link doesn't work anyway.
> The pdf seems to be now at
> http://support.amd.com/TechDocs/41322_10h_R
On Tue, 14 Jul 2020 12:54:59 +0200 Christoph Hellwig wrote:
> Hi all,
>
> in preparation for eventually phasing out direct use of set_fs(), this
> series removes the segment_eq() arch helper that is only used to
> implement or duplicate the uaccess_kernel() API, and then adds
> descriptive
On Tue, 14 Jul 2020 11:07:44 +0800 linmiaohe wrote:
> From: Miaohe Lin
>
> The vm_flags may be changed after call_mmap() because drivers may set some
> flags for their own purpose. As a result, we failed to merge the adjacent
> vma due to the different vm_flags as userspace can't pass in the
ation,
> build using gcc 9 and 10 on x86_64.
Thanks. I queued a reversion patch. I'll go ahead with this if we are
unable to get this fixed in the next week or so.
Are you able to check that the below fixes things up?
Thanks.
From: Andrew Morton
Subject: revert "squashfs: migrate from ll_rw
On Thu, 16 Jul 2020 16:32:00 +0800 kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit db57e98d87908b8837352abe08515e42752270c1
> Author:
On Tue, 14 Jul 2020 11:07:44 +0800 linmiaohe wrote:
> The vm_flags may be changed after call_mmap() because drivers may set some
> flags for their own purpose. As a result, we failed to merge the adjacent
> vma due to the different vm_flags as userspace can't pass in the same one.
> Try to merge
The mm-of-the-moment snapshot 2020-07-13-19-49 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Sat, 11 Jul 2020 01:17:28 -0400 Changming
wrote:
> From: Changming Liu
>
> Since panic_timeout is an integer passed-in through sysctl,
> the loop boundary panic_timeout * 1000 could overflow and
> result in a zero-delay panic when panic_timeout is greater
> than INT_MAX/1000.
>
> Fix this
The mm-of-the-moment snapshot 2020-07-09-21-00 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2020-07-08-19-28 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Tue, 7 Jul 2020 05:36:55 +0530 Anshuman Khandual
wrote:
> Add following new vmstat events which will help in validating THP migration
> without split. Statistics reported through these new VM events will help in
> performance debugging.
>
> 1. THP_MIGRATION_SUCCESS
> 2.
On Tue, 7 Jul 2020 16:02:04 +1200 Barry Song wrote:
> hugetlb_cma[0] can be NULL due to various reasons, for example, node0 has
> no memory. so NULL hugetlb_cma[0] doesn't necessarily mean cma is not
> enabled. gigantic pages might have been reserved on other nodes.
I'm trying to figure out
On Sat, 27 Jun 2020 23:08:40 -0700 Eric Biggers wrote:
> From: Eric Biggers
>
> sb_getblk() can fail, so check its return value.
>
> This fixes a NULL pointer dereference.
>
> Reported-by: syzbot+4a88b2b9dc280f47b...@syzkaller.appspotmail.com
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc:
The mm-of-the-moment snapshot 2020-07-06-18-53 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Mon, 6 Jul 2020 06:34:34 -0700 Andi Kleen wrote:
> > ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> > - if (ret == 0 && write)
> > + if (ret == 0 && write) {
> > + if (sysctl_overcommit_memory == OVERCOMMIT_NEVER)
> > +
On Mon, 6 Jul 2020 22:06:48 + Wei Yang wrote:
> >The patchet looks good to me. I have few nits, but nothing substantial.
> >
> >Acked-by: Kirill A. Shutemov
> >
>
> Hi, Kirill
>
> Thanks for your review.
>
> Andrew,
>
> Do you want me to send another version or you would like to adjust
On Thu, 2 Jul 2020 15:01:56 +0800 wrote:
> From: Zhang Qiang
>
> The "queuing_blocked" func should print warning message and
> returns true when the worker being destroyed.
Why should it do this?
Please prepare a changelog which contains much more information.
On Fri, 3 Jul 2020 08:53:54 -0700 t...@redhat.com wrote:
> From: Tom Rix
>
> clang static analysis reports a garbage return
>
> In file included from mm/memory.c:84:
> mm/memory.c:1612:2: warning: Undefined or garbage value returned to caller
> [core.uninitialized.UndefReturn]
>
On Thu, 2 Jul 2020 09:23:10 +0200 David Hildenbrand wrote:
> >>> ---
> >>> arch/s390/kernel/crash_dump.c | 6 ++--
> >>> include/linux/memblock.h | 28 ++---
> >>> mm/memblock.c | 57 ++-
> >>> 3 files changed, 55 insertions(+),
On Mon, 29 Jun 2020 16:37:37 -0700 Dave Hansen wrote:
> On 6/29/20 4:30 PM, Baoquan He wrote:
> >> The only way I can plausibly think of "cleaning up" the RECLAIM_ZONE bit
> >> would be to raise our confidence that it is truly unused. That takes
> >> time, and probably a warning if we see it
On Mon, 29 Jun 2020 14:09:38 +0200 Pavel Machek wrote:
> > Extend the strings recognised by kstrtobool() to cover:
> >
> > - 1/0
> > - y/n
> > - yes/no (new)
> > - t/f (new)
> > - true/false (new)
> > - on/off
>
> Is it good idea to add more values there? It is easy
On Tue, 30 Jun 2020 12:08:25 -0700 Roman Gushchin wrote:
> On Sun, Jun 28, 2020 at 07:43:45PM +1200, Barry Song wrote:
> > Calling cma_declare_contiguous_nid() with false exact_nid for per-numa
> > reservation can easily cause cma leak and various confusion.
> > For example, mm/hugetlb.c is
On Mon, 29 Jun 2020 12:11:25 -0400 Nitesh Narayan Lal wrote:
>
> On 6/25/20 6:34 PM, Nitesh Narayan Lal wrote:
> > From: Alex Belits
> >
> > The current implementation of cpumask_local_spread() does not respect the
> > isolated CPUs, i.e., even if a CPU has been isolated for Real-Time task,
>
On Mon, 29 Jun 2020 09:57:42 -0700 Tim Chen wrote:
>
>
> I am okay with Matthew's suggestion of keeping the stack pagevec size
> unchanged.
> Andrew, do you have a preference?
>
> I was assuming that for people who really care about saving the kernel memory
> usage, they would make
On Tue, 30 Jun 2020 17:11:55 -0400 Peter Xu wrote:
> On Tue, Jun 30, 2020 at 04:45:01PM -0400, Peter Xu wrote:
> > v4:
> > - rebase to linux-next/akpm
> > - picked one more r-b
>
> I fixed some stuff in the send scripts but definitely broke something else on
> the chaining of the messages.
On Sat, 27 Jun 2020 04:13:04 +0100 Matthew Wilcox wrote:
> On Fri, Jun 26, 2020 at 02:23:03PM -0700, Tim Chen wrote:
> > Enlarge the pagevec size to 31 to reduce LRU lock contention for
> > large systems.
> >
> > The LRU lock contention is reduced from 8.9% of total CPU cycles
> > to 2.2% of
On Fri, 26 Jun 2020 15:09:08 -0700 Randy Dunlap wrote:
> On 6/25/20 8:37 PM, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2020-06-25-20-36 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for
On Wed, 24 Jun 2020 22:36:18 + HORIGUCHI NAOYA(堀口 直也)
wrote:
> On Wed, Jun 24, 2020 at 12:17:42PM -0700, Andrew Morton wrote:
> > On Wed, 24 Jun 2020 15:01:22 + nao.horigu...@gmail.com wrote:
> >
> > > I rebased soft-offline rework patchset [1][
On Wed, 24 Jun 2020 17:26:30 +0800 Bibo Mao wrote:
> update_mmu_cache_pmd is used to update tlb for the pmd entry by
> software. On MIPS system, the tlb entry indexed by page fault
> address maybe exists already, only that tlb entry may be small
> page, also it may be huge page. Before updating
On Tue, 23 Jun 2020 15:23:29 -0400 Nitesh Narayan Lal wrote:
> From: Alex Belits
>
> The current implementation of cpumask_local_spread() does not respect the
> isolated CPUs, i.e., even if a CPU has been isolated for Real-Time task,
> it will return it to the caller for pinning of its IRQ
On Wed, 24 Jun 2020 15:01:22 + nao.horigu...@gmail.com wrote:
> I rebased soft-offline rework patchset [1][2] onto the latest mmotm. The
> rebasing required some non-trivial changes to adjust, but mainly that was
> straightforward. I confirmed that the reported problem doesn't reproduce on
On Wed, 24 Jun 2020 18:01:31 +0100 Matthew Wilcox wrote:
> On Wed, Jun 24, 2020 at 12:49:43PM -0400, Joel Savitz wrote:
> > When I increased the upper bound of the min_free_kbytes value in
> > ee8eb9a5fe863, I forgot to tweak the above comment to reflect
> > the new value. This patch fixes that
On Thu, 25 Jun 2020 01:43:32 +0800 Yang Shi wrote:
> Since commit bbddabe2e436aa7869b3ac5248df5c14ddde0cbf ("mm: filemap:
> only do access activations on reads"), mark_page_accessed() is called
> for reads only. But the idle flag is cleared by mark_page_accessed() so
> the idle flag won't get
On Tue, 9 Jun 2020 00:18:23 +0200 Rikard Falkeborn
wrote:
> Add tests of GENMASK and GENMASK_ULL.
>
> A few test cases that should fail compilation are provided
> under #ifdef TEST_GENMASK_FAILURES
WARNING: modpost: missing MODULE_LICENSE() in lib/test_bits.o
Could you please send a fix?
On Thu, 18 Jun 2020 08:43:06 +0200 Christoph Hellwig wrote:
> Use PAGE_KERNEL_ROX directly instead of allocating RWX and setting the
> page read-only just after the allocation.
>
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -120,15 +120,9 @@ int
On Fri, 19 Jun 2020 16:33:38 +0800 Alex Shi wrote:
> This is a new version which bases on linux-next, merged much suggestion
> from Hugh Dickins, from compaction fix to less TestClearPageLRU and
> comments reverse etc. Thank a lot, Hugh!
>
> Johannes Weiner has suggested:
> "So here is a crazy
On Fri, 19 Jun 2020 14:38:10 -0700 Roman Gushchin wrote:
> Andrew, can you, please, squash the following fix based on Shakeel's
> suggestions?
> Thanks!
Sure. But a changelog, a signoff and an avoidance of tabs-replaced-by-spaces
would still be preferred, please!
On Fri, 19 Jun 2020 12:08:43 -0500 "Gustavo A. R. Silva"
wrote:
> Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
Well. There's only one other Addresses-KSPP-ID: in kernel history and
I'm a bit reluctant to add new signoff tags such as this. People like
to invent new tags an awful
On Sat, 20 Jun 2020 14:47:19 -0400 Waiman Long wrote:
> It was found that running the LTP test on a PowerPC system could produce
> erroneous values in /proc/meminfo, like:
>
> MemTotal: 531915072 kB
> MemFree:507962176 kB
> MemAvailable: 1100020596352 kB
>
> Using
On Tue, 9 Jun 2020 14:05:33 +0200 Joerg Roedel wrote:
> From: Joerg Roedel
>
> The functions are only used in two source files, so there is no need
> for them to be in the global header. Move them to the new
> header and include it only where needed.
>
> ...
>
> new file mode 100644
>
On Tue, 9 Jun 2020 21:36:42 -0400 Kent Overstreet
wrote:
> Convert generic_file_buffered_read() to get pages to read from in
> batches, and then copy data to userspace from many pages at once - in
> particular, we now don't touch any cachelines that might be contended
> while we're in the loop
On Wed, 10 Jun 2020 15:49:18 + "Luis R. Rodriguez"
wrote:
> Tiezhu Yang had sent out a patch set with a slew of kmod selftest
> fixes, and one patch which modified kmod to return 254 when a module
> was not found. This opened up pandora's box about why that was being
> used for and low and
ra...@codeaurora.org: fix suggested by Mel Gorman]
Link:
http://lkml.kernel.org/r/31556793-57b1-1c21-1a9d-22674d9bd...@codeaurora.org
[a...@linux-foundation.org: fix comment grammar, reflow comment]
Link:
http://lkml.kernel.org/r/1589882284-21010-1-git-send-email-chara...@codeaurora.org
Signed-
-by: Roman Gushchin
Reviewed-by: Vlastimil Babka
Signed-off-by: Andrew Morton
---
include/linux/slab.h |2
include/linux/slab_def.h |3
include/linux/slub_def.h | 10 -
mm/memcontrol.c |5
mm/slab.c| 46 ---
mm/slab.h| 176
On Wed, 17 Jun 2020 15:34:14 -0700 Kaiyu Zhang wrote:
> From: Alex Zhang
>
> This function implicitly assumes that the addr passed in is page aligned.
> A non page aligned addr could ultimately cause a kernel bug in
> remap_pte_range as the exit condition in the logic loop may never be
>
On Tue, 16 Jun 2020 13:45:27 -0700 Nitin Gupta wrote:
> For some applications, we need to allocate almost all memory as
> hugepages. However, on a running system, higher-order allocations can
> fail if the memory is fragmented. Linux kernel currently does on-demand
> compaction as we request
On Tue, 16 Jun 2020 14:19:01 -0700 Roman Gushchin wrote:
> >
> > This version is based on top of v6 of the new slab controller
> > patchset. The following patches are actually required by this series:
> > mm: memcg: factor out memcg- and lruvec-level changes out of
> > __mod_lruvec_state()
>
On Wed, 10 Jun 2020 21:27:52 -0700 Vijay Balakrishna
wrote:
> Make kernel GNU build-id available in VMCOREINFO. Having
> build-id in VMCOREINFO facilitates presenting appropriate kernel
> namelist image with debug information file to kernel crash dump
> analysis tools. Currently VMCOREINFO
On Tue, 2 Jun 2020 12:59:52 +0800 Lianbo Jiang wrote:
> Signature verification is an important security feature, to protect
> system from being attacked with a kernel of unknown origin. Kexec
> rebooting is a way to replace the running kernel, hence need be
> secured carefully.
I'm finding
On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport wrote:
> From: Mike Rapoport
>
> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
> level to access a PMD entry. Since 8xx has only 2-level page table this can
> be simplified with pmd_off() shortcut.
>
> Replace
On Mon, 15 Jun 2020 19:19:17 -0400 Peter Xu wrote:
> On Mon, Jun 15, 2020 at 03:32:40PM -0700, Linus Torvalds wrote:
> > On Mon, Jun 15, 2020 at 3:16 PM Peter Xu wrote:
> > >
> > > Provide this helper for doing memory page fault accounting across archs.
> > > It
> > > can be defined
On Tue, 16 Jun 2020 15:16:43 +0900 js1...@gmail.com wrote:
> Subject: [PATCH for v5.8 2/3] mm/swap: fix for "mm: workingset: age
> nonresident information alongside anonymous pages"
I'm having trouble locating such a patch.
> Non-file-lru page could also be activated in mark_page_accessed()
>
On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long wrote:
> As said by Linus:
>
> A symmetric naming is only helpful if it implies symmetries in use.
> Otherwise it's actively misleading.
>
> In "kzalloc()", the z is meaningful and an important part of what the
> caller wants.
>
> In
efinition of
> > 'pte_offset_kernel' was here
> > static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address)
> > ^
> >
> > Caused by commit
> >
> > 292aa65ed13a ("mm: consolidate pte_index() and
The mm-of-the-moment snapshot 2020-06-08-22-35 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2020-06-08-22-33 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
Perhaps something like:
Yup.
From: Joe Perches
Subject: lib/lz4/lz4_decompress.c: document deliberate use of `&'
This operation was intentional, but tools such as smatch will warn that it
might not have been.
Link:
http://lkml.kernel.org/r/3bf931c6ea0cae3e23f3485801986859851b4f04.ca...@per
On Sun, 7 Jun 2020 15:27:49 +0800 kernel test robot
wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 24256c140e59c3431af4918fd4ec892102cbc2f3 ("x86: mm: ptdump: calculate
> effective permissions correctly")
>
_pte(struct vm_fault *vmf, struct
> mem_cgroup *memcg,
>
> flush_icache_page(vma, page);
> entry = mk_pte(page, vma->vm_page_prot);
> - entry = pte_sw_mkyoung(entry);
> if (write)
> entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> /* copy-on-write page */
Only affects mips, so cheerily
Acked-by: Andrew Morton
On Fri, 5 Jun 2020 12:46:55 +0100 Catalin Marinas
wrote:
> On Fri, Jun 05, 2020 at 11:08:13AM +0100, Catalin Marinas wrote:
> > This patch causes a kernel panic on arm64 (and possibly powerpc, I
> > haven't tried). arm64 still uses the 5level-fixup.h and pud_alloc()
> > checks for the empty p4d
On Fri, 5 Jun 2020 20:23:07 +0200 Geert Uytterhoeven
wrote:
> Hi Adrian,
>
> On Fri, Jun 5, 2020 at 7:58 PM John Paul Adrian Glaubitz
> wrote:
> > On 6/5/20 5:59 PM, Rich Felker wrote:
> > >> Ah, sorry, I missed that. You're right, it should probably go through
> > >> someone else's tree
On Fri, 5 Jun 2020 09:00:10 -0700 Kees Cook wrote:
> While looking at the code paths for the proposed O_MAYEXEC flag, I saw
> some things that looked like they should be fixed up.
>
> exec: Change uselib(2) IS_SREG() failure to EACCES
> This just regularizes the return code on
On Fri, 05 Jun 2020 11:24:43 -0700 Joe Perches wrote:
> IS_ENABLED is almost always used with CONFIG_ defines.
>
> Add a test to verify that the #define being tested starts with CONFIG_.
Yay.
I wonder if there's a simple way of testing whether the CONFIG_ thing
can *ever* be enabled. So
if (order_comb_long[i][1] !=
get_count_order_long(order_comb_long[i][0]))
pr_warn("get_count_order_long wrong for %lx\n",
order_comb_long[i][0]);
}
#endif
return 0;
}
From: An
401 - 500 of 25528 matches
Mail list logo
