On Wed, 13 Feb 2019 20:19:22 +0200 Mike Rapoport wrote:
>
> Marc Gonzalez reported the following kmemleak crash:
>
> Unable to handle kernel paging request at virtual address ffc021e0
> Mem abort info:
> ESR = 0x9606
> Exception class = DABT (current EL), IL = 32 bits
> SET =
On Wed, 13 Feb 2019 17:49:28 +1100 Stephen Rothwell
wrote:
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> scripts/atomic/check-atomics.sh
>
> between commit:
>
> 4ad119545d78 ("locking/atomics: Check atomic headers with sha1sum")
>
> from the tip tree
On Wed, 13 Feb 2019 08:50:28 +1100 Stephen Rothwell
wrote:
> > > It's definitely going to conflict with the proposed patch
> > > over drivers/of/of_reserved_mem.c
> > >
> > > Rob, what's the next step then?
> >
> > Rebase it on top of what's in linux-next and apply it to the tree
> > which
On Mon, 11 Feb 2019 22:59:53 +0100 Andrey Konovalov
wrote:
> With tag based KASAN page_address() looks at the page flags to see
> whether the resulting pointer needs to have a tag set. Since we don't
> want to set a tag when page_address() is called on SLAB pages, we call
>
On Tue, 12 Feb 2019 11:21:29 +0100 Michal Hocko wrote:
> Tetsuo has reported that creating a thousands of processes sharing MM
> without SIGHAND (aka alien threads) and setting
> /proc//oom_score_adj will swamp the kernel log and takes ages [1]
> to finish. This is especially worrisome that all
On Tue, 12 Feb 2019 13:47:24 -0500 Johannes Weiner wrote:
> On Tue, Feb 12, 2019 at 09:56:45AM -0800, Roman Gushchin wrote:
> > The patchset contains few changes to the vmalloc code, which are
> > leading to some performance gains and code simplification.
> >
> > Also, it exports a number of
On Sat, 9 Feb 2019 12:35:03 +0200 Andy Shevchenko
wrote:
> On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton
> wrote:
> > On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko
> > wrote:
> > > On Tue, Oct 30, 2018 at 5:22 PM David Engraf
> > > wrote:
> >
On Mon, 11 Feb 2019 14:08:22 -0500 Johannes Weiner wrote:
> On Wed, Dec 19, 2018 at 09:37:48AM -0800, Roman Gushchin wrote:
> > The patchset contains few changes to the vmalloc code, which are
> > leading to some performance gains and code simplification.
> >
> > Also, it exports a number of
On Fri, 8 Feb 2019 17:46:39 -0500 Waiman Long wrote:
> On 02/08/2019 05:32 PM, Andrew Morton wrote:
> > On Fri, 08 Feb 2019 14:48:03 +0100 Thomas Gleixner
> > wrote:
> >
> >> Waiman reported that on large systems with a large amount of interrupts the
> >
re deleted in 'readdir' order.
OK, thanks.
I guess we need a rethink on Roman's fixes. I'll queued the reverts.
BTW, one thing I don't think has been discussed (or noticed) is the
effect of "mm: don't reclaim inodes with many attached pages" on 32-bit
highmem machines. Look why someon
On Fri, 8 Feb 2019 13:45:47 +0200 Mike Rapoport wrote:
> * Remove comments mentioning bootmem
> * Extend "DOC: memblock overview"
> * Add kernel-doc comments for several more functions
>
> ...
>
> @@ -1400,6 +1413,19 @@ phys_addr_t __init
> memblock_phys_alloc_range(phys_addr_t size,
>
On Fri, 08 Feb 2019 14:48:03 +0100 Thomas Gleixner wrote:
> Waiman reported that on large systems with a large amount of interrupts the
> readout of /proc/stat takes a long time to sum up the interrupt
> statistics. In principle this is not a problem. but for unknown reasons
> some enterprise
On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko
wrote:
> On Tue, Oct 30, 2018 at 5:22 PM David Engraf wrote:
> >
> > Unpacking an external initrd may fail e.g. not enough memory. This leads
> > to an incomplete rootfs because some files might be extracted already.
> > Fixed by cleaning the
On Wed, 6 Feb 2019 15:10:16 -0800 john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> This combines the common elements of these routines:
>
> page_cache_get_speculative()
> page_cache_add_speculative()
>
> This was anticipated by the original author, as shown by the comment
> in
cts")
Signed-off-by: Rik van Riel
Tested-by: Chris Mason
Acked-by: Roman Gushchin
Acked-by: Johannes Weiner
Cc: Dave Chinner
Cc: Jonathan Lemon
Cc: Jan Kara
Cc:
Signed-off-by: Andrew Morton
---
---
a/include/linux/shrinker.h~mmslabvmscan-accumulate-gradual-pressure-on-small-slabs
+
On Thu, 7 Feb 2019 14:11:16 -0500 "Michael S. Tsirkin" wrote:
> mm/debug-pagealloc.c is no more, so of course header now needs to be
> updated. This seems like something checkpatch should be
> able to catch - worth looking into?
>
> Cc: triv...@kernel.org
> Cc: linux...@kvack.org
> Cc: Linus
On Thu, 10 Jan 2019 16:05:11 -0800 Joe Perches wrote:
> Using SPDX commenting style // or /* is specified for
> various file types in Documentation/process/license-rules.rst
> so add an appropriate test for .[chsS] files because many
> proposed file additions and patches do not use the correct
On Thu, 31 Jan 2019 21:15:17 -0800 Dan Williams
wrote:
> +config SHUFFLE_PAGE_ALLOCATOR
> + bool "Page allocator randomization"
> + default SLAB_FREELIST_RANDOM && ACPI_NUMA
> + help
SLAB_FREELIST_RANDOM is default n, so this patchset won't get much
runtime testing.
How about you
On Fri, 1 Feb 2019 18:42:29 -0800 Andy Lutomirski wrote:
> On Fri, Feb 1, 2019 at 12:54 PM Chang S. Bae wrote:
> >
> > For testing (or root-only) purposes, the new flag will serve to tag the
> > kernel taint accurately.
> >
> > When adding a new feature support, patches need to be incrementally
On Mon, 4 Feb 2019 18:53:08 -0800 Ivan Delalande wrote:
> We were seeing unexplained segfaults in coreutils processes and other
> basic utilities on systems with print-fatal-signals enabled:
>
> [ 311.001986] potentially unexpected fatal signal 11.
> [ 311.001993] CPU: 3 PID: 4565
On Tue, 5 Feb 2019 21:24:13 +0300 Andrey Abramov wrote:
> Replaced heap sort algorithm with faster introspective sort algorithm.
>
> Signed-off-by: Andrey Abramov
> ---
> v1: The introspective sort algorithm is faster the heap sort (for example on
> my machine on a 100MB of random data it
t vocal, user of ancient userspace to build new kernels. Are you
> okay with this?
Acked-by: Andrew Morton
That little initiative got beaten into submission :(
On Mon, 4 Feb 2019 15:09:16 -0800 Andrew Morton
wrote:
> On Sun, 3 Feb 2019 20:24:00 +0100 Rasmus Villemoes
> wrote:
>
> > BUILD_BUG_ON() is a little annoying, since it cannot be used outside
> > function scope. So one cannot put assertions about the sizeof() a
> >
On Sun, 3 Feb 2019 20:24:00 +0100 Rasmus Villemoes
wrote:
> BUILD_BUG_ON() is a little annoying, since it cannot be used outside
> function scope. So one cannot put assertions about the sizeof() a
> struct next to the struct definition, but has to hide that in some
> more or less arbitrary
On Mon, 4 Feb 2019 11:57:10 +1100 "Tobin C. Harding" wrote:
> Here is v2 of the comments fixes [to single SLUB header file]
Thanks. I think I'll put these into a single patch.
On Thu, 31 Jan 2019 18:43:10 -0800 Matthew Wilcox wrote:
> On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> > Currently when displaying /proc/slabinfo if any cache names are too long
> > then the output columns are not aligned. We could do something fancy to
> > get the
On Fri, 1 Feb 2019 11:58:38 +1100 "Tobin C. Harding" wrote:
> On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> [snip]
>
> This applies on top of Linus' tree
>
> commit e74c98ca2d6a ('gfs2: Revert "Fix loop in gfs2_rbm_find"')
>
> For this patch I doubt very much that
On Thu, 31 Jan 2019 22:51:52 + Liviu Dudau wrote:
> On Wed, Jan 30, 2019 at 08:51:42PM -0500, Qian Cai wrote:
> >
> >
> > On 1/30/19 7:05 PM, Stephen Rothwell wrote:
> > > In commit
> > >
> > > 6e9ed490d190 ("mm/page_owner: fix for deferred struct page init")
> > >
> > > Fixes tag
> >
On Tue, 29 Jan 2019 21:02:16 -0800 Dan Williams
wrote:
> Randomization of the page allocator improves the average utilization of
> a direct-mapped memory-side-cache. Memory side caching is a platform
> capability that Linux has been previously exposed to in HPC
> (high-performance computing)
On Tue, 29 Jan 2019 21:02:26 -0800 Dan Williams
wrote:
> When freeing a page with an order >= shuffle_page_order randomly select
> the front or back of the list for insertion.
>
> While the mm tries to defragment physical pages into huge pages this can
> tend to make the page allocator more
On Thu, 31 Jan 2019 11:10:46 +1100 Stephen Rothwell
wrote:
> Hi all,
>
> Commits
>
> 7a738192604a ("mm/page_owner: align with pageblock_nr_pages")
> ed2205fd9fc0 ("filemap-drop-the-mmap_sem-for-all-blocking-operations-fix")
> d5b0dce6cd86
>
On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse wrote:
> Andrew what is your plan for this ? I had a discussion with Peter Xu
> and Andrea about change_pte() and kvm. Today the change_pte() kvm
> optimization is effectively disabled because of invalidate_range
> calls. With a minimal couple
On Wed, 30 Jan 2019 13:31:30 +0100 Thomas Gleixner wrote:
> Waiman reported that on large systems with a large amount of interrupts the
> readout of /proc/stat takes a long time to sum up the interrupt
> statistics. In principle this is not a problem. but for unknown reasons
> some enterprise
On Wed, 30 Jan 2019 10:07:15 +0800 Ian Kent wrote:
> On Tue, 2019-01-29 at 17:16 -0800, Andrew Morton wrote:
> > On Sat, 12 Jan 2019 08:00:40 +0800 Ian Kent wrote:
> >
> > > Add an autofs file system mount option that can be used to provide
> > > a
On Fri, 11 Jan 2019 22:01:16 +0300 Andrey Ryabinin
wrote:
>
>
> On 12/17/18 6:03 PM, Anders Roxell wrote:
> > When booting an allmodconfig kernel, there are a lot of false-positives.
> > With a message like this 'UBSAN: Undefined behaviour in...' with a call
> > trace that follows.
> >
> >
On Sat, 12 Jan 2019 08:00:40 +0800 Ian Kent wrote:
> Add an autofs file system mount option that can be used to provide
> a generic indicator to applications that the mount entry should be
> ignored when displaying mount information.
What is the reason for adding this feature?
On Mon, 14 Jan 2019 15:19:17 +0900 William Breathitt Gray
wrote:
> While adding GPIO get_multiple/set_multiple callback support for various
> drivers, I noticed a pattern of looping manifesting that would be useful
> standardized as a macro.
>
> This patchset introduces the for_each_set_clump8
On Mon, 14 Jan 2019 15:24:32 +0530 "Aneesh Kumar K.V"
wrote:
> ppc64 use CMA area for the allocation of guest page table (hash page table).
> We won't
> be able to start guest if we fail to allocate hash page table. We have
> observed
> hash table allocation failure because we failed to
On Mon, 14 Jan 2019 15:24:33 +0530 "Aneesh Kumar K.V"
wrote:
> This patch adds PF_MEMALLOC_NOCMA which make sure any allocation in that
> context
> is marked non-movable and hence cannot be satisfied by CMA region.
>
> This is useful with get_user_pages_longterm where we want to take a page
On Mon, 14 Jan 2019 23:04:23 +0300 Alexey Dobriyan wrote:
> Compilers like to transform loops like
>
> for (i = 0; i < n; i++) {
> [use p[i]]
> }
>
> into
> for (p = p0; p < end; p++) {
> ...
> }
>
> Do it by hand, so that it results in
On Tue, 29 Jan 2019 17:17:54 +0100 Uladzislau Rezki wrote:
> > > + resched_threshold = (int) lazy_max_pages() << 1;
> >
> > Is the typecast really needed?
> >
> > Perhaps resched_threshold shiould have unsigned long type and perhaps
> > vmap_lazy_nr should be atomic_long_t?
> >
> I think so.
On Fri, 18 Jan 2019 14:11:30 +0100 Jürg Billeter wrote:
> This introduces a new thread group flag that can be set by calling
>
> prctl(PR_SET_KILL_DESCENDANTS_ON_EXIT, 1, 0, 0, 0)
>
> When a thread group exits with this flag set, it will send SIGKILL to
> all descendant processes. This
On Sun, 20 Jan 2019 17:10:49 -0800 Sandeep Patil wrote:
> The 'pss_locked' field of smaps_rollup was being calculated incorrectly
> as it accumulated the current pss everytime a locked VMA was found.
>
> Fix that by making sure we record the current pss value before each VMA
> is walked. So, we
On Tue, 22 Jan 2019 09:50:48 +0900 Tetsuo Handa
wrote:
> Al Viro wrote:
> > On Mon, Jan 21, 2019 at 07:14:39PM +0900, Tetsuo Handa wrote:
> > > On Tue, Dec 12, 2017 at 2:06 PM, Eric Biggers wrote:
> > > > I'm not sure what the fix will be. Maybe the proc handlers should take
> > > > a
> > >
On Wed, 16 Jan 2019 14:35:01 -0500 Johannes Weiner wrote:
> psi has provisions to shut off the periodic aggregation worker when
> there is a period of no task activity - and thus no data that needs
> aggregating. However, while developing psi monitoring, Suren noticed
> that the aggregation
On Mon, 28 Jan 2019 14:53:09 -0800 Andrew Morton
wrote:
> On Fri, 25 Jan 2019 08:58:33 +0100 Oscar Salvador wrote:
>
> > On Wed, Jan 23, 2019 at 11:33:56AM +0100, David Hildenbrand wrote:
> > > If you use {} for the else case, please also do so for the if case.
head)) - (page - head);
pfn += skip - 1;
}
}
return 0;
}
From: Andrew Morton
Subject: mmmemory_hotplug-fix-scan_movable_pages-for-gigantic-hugepages-fix
fix brace layout, per David. Also reduce indentation
Cc: Anthony Yznaga
Cc: David Hild
On Tue, 22 Jan 2019 16:44:07 +0100 Oscar Salvador wrote:
> This is the same sort of error we saw in [1].
I'll replace "[1]" with 17e2e7d7e1b83 ("mm, page_alloc: fix
has_unmovable_pages for HugePages").
> Signed-off-by: Oscar Salvador
And I'll add cc:stable.
On Wed, 16 Jan 2019 14:35:01 -0500 Johannes Weiner wrote:
> psi has provisions to shut off the periodic aggregation worker when
> there is a period of no task activity - and thus no data that needs
> aggregating. However, while developing psi monitoring, Suren noticed
> that the aggregation
On Wed, 23 Jan 2019 11:33:53 -0700 Jason Gunthorpe wrote:
> On Mon, Jan 21, 2019 at 09:42:15AM -0800, Davidlohr Bueso wrote:
> > Taking a sleeping lock to _only_ increment a variable is quite the
> > overkill, and pretty much all users do this. Furthermore, some drivers
> > (ie: infiniband and
On Thu, 24 Jan 2019 15:00:23 +0800 wrote:
> From: Miles Chen
>
> When debugging slab errors in slub.c, sometimes we have to trigger
> a panic in order to get the coredump file. Add a debug option
> SLAB_WARN_ON_ERROR to toggle WARN_ON() when the option is set.
>
> Change since v1:
> 1. Add a
On Mon, 28 Jan 2019 15:03:28 -0500 Rik van Riel wrote:
> On Mon, 2019-01-28 at 11:54 -0800, Andrew Morton wrote:
> > On Mon, 28 Jan 2019 14:35:35 -0500 Rik van Riel
> > wrote:
> >
> > > /*
> > >* Make sure we apply some minimal pressure on de
On Thu, 24 Jan 2019 12:56:48 +0100 "Uladzislau Rezki (Sony)"
wrote:
> commit 763b218ddfaf ("mm: add preempt points into
> __purge_vmap_area_lazy()")
>
> introduced some preempt points, one of those is making an
> allocation more prioritized over lazy free of vmap areas.
>
> Prioritizing an
On Mon, 28 Jan 2019 14:35:35 -0500 Rik van Riel wrote:
> There are a few issues with the way the number of slab objects to
> scan is calculated in do_shrink_slab. First, for zero-seek slabs,
> we could leave the last object around forever. That could result
> in pinning a dying cgroup into
.@kernel.org
> > > Signed-off-by: Michal Hocko
> > > Cc: Tetsuo Handa
> > > Cc: Johannes Weiner
> > > Signed-off-by: Andrew Morton
> >
> > It looks like this problem is happening in production systems:
> >
> > https://www.spinics.net/
On Fri, 25 Jan 2019 09:38:27 -0800 Matthew Wilcox wrote:
> It's never appropriate to map a page allocated by SLAB into userspace.
> A buggy device driver might try this, or an attacker might be able to
> find a way to make it happen.
It wouldn't surprise me if someone somewhere is doing this.
On Sun, 27 Jan 2019 23:57:38 +0900 Tetsuo Handa
wrote:
> Arkadiusz reported that enabling memcg's group oom killing causes
> strange memcg statistics where there is no task in a memcg despite
> the number of tasks in that memcg is not 0. It turned out that there
> is a bug in wake_oom_reaper()
On Mon, 28 Jan 2019 09:49:59 +0100 Vincent Whitchurch
wrote:
> Add a sysctl which asks the kernel to panic when any userspace process
> receives a fatal signal which would trigger a core dump. This has
> proven to be quite useful when debugging problems seen during testing of
> embedded
On Mon, 28 Jan 2019 15:45:04 +0100 Michal Hocko wrote:
> Mikhail has posted fixes for the two bugs quite some time ago [1]. I
> have pushed back on those fixes because I believed that it is much
> better to plug the problem at the initialization time rather than play
> whack-a-mole all over the
On Mon, 28 Jan 2019 15:49:04 +0100 Stanislaw Gruszka
wrote:
> fls counts bits starting from 1 to 32 (returns 0 for zero argument).
> If we add 1 we shift right one bit more and loose precision from
> divisor, what cause function incorect results with some numbers.
>
> Corrected code was tested
On Thu, 10 Jan 2019 14:13:44 +0100 peter enderborg
wrote:
> On 1/7/19 11:56 PM, Andrew Morton wrote:
> > On Sat, 5 Jan 2019 13:35:33 -0800 Linus Torvalds
> > wrote:
> >
> >> On Sat, Jan 5, 2019 at 1:21 PM Olof Johansson wrote:
> >>> Fixe
from exit_ptrace()
> to forget_original_parent()")
>
> Cc: "Eric W. Biederman"
> Cc: Andrew Morton
> Signed-off-by: Oleg Nesterov
> Signed-off-by: Andrei Vagin
Does this warrant a -stable backport? 7c8bd2322c7f was 4+ years ago...
On Fri, 4 Jan 2019 03:27:52 +0800 Yang Shi wrote:
> Swap readahead would read in a few pages regardless if the underlying
> device is busy or not. It may incur long waiting time if the device is
> congested, and it may also exacerbate the congestion.
>
> Use inode_read_congested() to check if
On Fri, 4 Jan 2019 03:27:52 +0800 Yang Shi wrote:
> Swap readahead would read in a few pages regardless if the underlying
> device is busy or not. It may incur long waiting time if the device is
> congested, and it may also exacerbate the congestion.
>
> Use inode_read_congested() to check if
On Wed, 9 Jan 2019 16:52:09 -0500 Qian Cai wrote:
> If the kernel is configured with KASAN_EXTRA, the stack size is
> increasted significantly due to enable this option will set
> "-fstack-reuse" to "none" in GCC [1]. As the results, it could trigger
> stack overrun quite often with 32k stack
On Wed, 9 Jan 2019 11:13:44 + Mel Gorman
wrote:
> Full compaction of a node passes in negative orders which can lead to array
> boundary issues. While it could be addressed in the control flow of the
> primary loop, it would be fragile so explicitly check for the condition.
> This is a fix
On Wed, 09 Jan 2019 16:36:36 +0530 Arun KS wrote:
> On 2019-01-09 16:27, Michal Hocko wrote:
> > On Wed 09-01-19 16:12:48, Arun KS wrote:
> > [...]
> >> It will be called once per online of a section and the arg value is
> >> always
> >> set to 0 while entering online_pages_range.
> >
> > You
On Thu, 10 Jan 2019 00:07:42 +0530 Souptick Joarder
wrote:
> Convert to use vm_fault_t type for last argument of do_sigbus().
>
> kbuild reported a warning during testing of final vm_fault_t patch
> integrated in mm tree.
Please be more specific when identifying patches.
> [auto build test
On Wed, 9 Jan 2019 17:40:22 +0200 Andy Shevchenko
wrote:
> Since string_escape_str() does not support overlapping buffer first we check
> if
> there is enough room in the buffer and then update a path. The side effect of
> this change is in case of failure the buffer is left unchanged.
>
>
[1] https://lore.kernel.org/lkml/20181220060303.38686-1-...@lca.pw/
Link: http://lkml.kernel.org/r/20181220203156.43441-1-...@lca.pw
Fixes: fe53ca54270 (mm: use early_pfn_to_nid in page_ext_init)
Signed-off-by: Qian Cai
Suggested-by: Michal Hocko
Reviewed-by: Andrew Morton
Cc: Pasha Tatashin
Cc: I
On Tue, 8 Jan 2019 12:26:35 -0800 Matthew Wilcox wrote:
> > Would it be excessively cautious to put a WARN_ON_ONCE() in there for a
> > while?
>
> I think it would ... it'd get in the way of a subsequent patch to store
> only head pages in the page cache.
OK, shall grab. Perhaps the changelog
On Tue, 8 Jan 2019 10:21:06 +0530 "Aneesh Kumar K.V"
wrote:
> ppc64 use CMA area for the allocation of guest page table (hash page table).
> We won't
> be able to start guest if we fail to allocate hash page table. We have
> observed
> hash table allocation failure because we failed to
On Tue, 8 Jan 2019 07:37:44 + (UTC) Christophe Leroy
wrote:
> In powerpc code, there are several places implementing safe
> access to user data. This is sometimes implemented using
> probe_kernel_address() with additional access_ok() verification,
> sometimes with get_user() enclosed in a
On Tue, 8 Jan 2019 12:09:44 +0100 Roman Penyaev wrote:
> This patch repeats the original one from David S. Miller:
>
> 2dca6999eed5 ("mm, perf_event: Make vmalloc_user() align base kernel
> virtual address to SHMLBA")
>
> but for missed vmalloc_32_user() case, which also requires correct
>
On Tue, 8 Jan 2019 02:37:20 +0300 Alexey Dobriyan wrote:
> On Mon, Jan 07, 2019 at 02:36:09PM -0800, a...@linux-foundation.org wrote:
> > Subject: proc-fix-proc-net-after-setns2-checkpatch-fixes
> >
> > WARNING: Block comments use * on subsequent lines
> > #56: FILE: fs/proc/proc_net.c:44:
> >
On Fri, 4 Jan 2019 12:49:46 + Mel Gorman
wrote:
> This series reduces scan rates and success rates of compaction, primarily
> by using the free lists to shorten scans, better controlling of skip
> information and whether multiple scanners can target the same block and
> capturing
On Mon, 7 Jan 2019 14:39:35 -0800 Matthew Wilcox wrote:
> On Mon, Jan 07, 2019 at 02:33:19PM -0800, Andrew Morton wrote:
> > On Mon, 7 Jan 2019 12:02:24 -0800 Matthew Wilcox
> > wrote:
> >
> > > After we establish a reference on the page,
On Sat, 5 Jan 2019 00:47:29 -0500 Qian Cai wrote:
> Running the trinity fuzzer triggered this,
>
> UBSAN: Undefined behaviour in kernel/signal.c:2946:7
> shift exponent 4294967295 is too large for 64-bit type 'long unsigned
> int'
> [ 3752.406618] dump_stack+0xe0/0x17a
> [ 3752.419817]
On Sat, 5 Jan 2019 13:35:33 -0800 Linus Torvalds
wrote:
> On Sat, Jan 5, 2019 at 1:21 PM Olof Johansson wrote:
> >
> > Fixes build break on most ARM/ARM64 defconfigs:
>
> Interesting.
>
> Andrew, I thought ARM was one of the platforms that your tree compiled
> against? Or was some other
On Mon, 7 Jan 2019 11:47:12 +0530 Souptick Joarder wrote:
> > Do I need to make any further improvement for this patch ?
>
> If no further comment, can we get this patch in queue for 5.0-rcX ?
I stopped paying attention a while ago, sorry.
Please resend everything which you believe is ready
ommitDate: Thu Jan 13 17:32:32 2011 -0800
mm: find_get_pages_contig fixlet
Testing ->mapping and ->index without a ref is not stable as the page
may have been reused at this point.
Signed-off-by: Nick Piggin
Reviewed-by: Wu Fengguang
Reviewed-by: Minchan Kim
On Fri, 4 Jan 2019 09:50:31 +0100 Vlastimil Babka wrote:
> > Yes, it doesn't and it's not trivial to do. The tool reports uses of
> > unint _values_. Values don't necessary reside in memory. It can be a
> > register, that come from another register that was calculated as a sum
> > of two other
On Wed, 2 Jan 2019 18:36:06 +0100 Andrey Konovalov
wrote:
> Instead of changing cache->align to be aligned to KASAN_SHADOW_SCALE_SIZE
> in kasan_cache_create() we can reuse the ARCH_SLAB_MINALIGN macro.
>
> ...
>
> --- a/arch/arm64/include/asm/kasan.h
> +++ b/arch/arm64/include/asm/kasan.h
>
On Thu, 13 Dec 2018 18:29:08 +0300 Kirill Tkhai wrote:
> This patch adds an optimization for KSM pages almost
> in the same way, that we have for ordinary anonymous
> pages. If there is a write fault in a page, which is
> mapped to an only pte, and it is not related to swap
> cache; the page may
On Fri, 28 Dec 2018 17:31:47 -0800 Shakeel Butt wrote:
> __alloc_percpu_gfp() can be called from atomic context, so, make
> pcpu_get_pages use the gfp provided to the higher layer.
Does this fix any user-visible issues?
On Sat, 22 Dec 2018 05:40:19 +0800 Yang Shi wrote:
> Swap readahead would read in a few pages regardless if the underlying
> device is busy or not. It may incur long waiting time if the device is
> congested, and it may also exacerbate the congestion.
>
> Use inode_read_congested() to check if
On Fri, 28 Dec 2018 00:18:29 +0800 Peng Wang wrote:
> Introduce bitmap alloc/free helpers when contiguous
> memory is not necessary.
That's a large bitmap you have there. What code needs this?
On Fri, 28 Dec 2018 09:48:34 +0100 Christoph Hellwig wrote:
> On Fri, Dec 28, 2018 at 04:39:50PM +0800, Huang Shijie wrote:
> > Follow the kernel conventions, rename addr_in_gen_pool to
> > gen_pool_has_addr.
>
> Which convention?
That symbols from subsystem foo should be called foo_*. Not
On Fri, 28 Dec 2018 23:48:53 +0100 Christian Brauner
wrote:
> The kill() syscall operates on process identifiers (pid). After a process
> has exited its pid can be reused by another process. If a caller sends a
> signal to a reused pid it will end up signaling the wrong process. This
> issue
On Fri, 28 Dec 2018 12:51:04 -0800 syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
uh-oh. Josef, could you please take a look?
: page = find_get_page(mapping, offset);
: if (likely(page) && !(vmf->flags & FAULT_FLAG_TRIED)) {
: /*
:*
On Mon, 24 Dec 2018 15:06:22 +0800 Huang Shijie wrote:
> We may use the addr_in_gen_pool() in the driver module.
> So export the addr_in_gen_pool for the compiling.
>
> ...
>
> --- a/lib/genalloc.c
> +++ b/lib/genalloc.c
> @@ -450,6 +450,7 @@ bool addr_in_gen_pool(struct gen_pool *pool,
On Mon, 24 Dec 2018 16:03:12 -0500 Qian Cai wrote:
> Some code in 9b31cf493ff was lost during merging into the -mmotm tree
> for some reasons,
>
> In file included from ./arch/arm64/include/asm/processor.h:46,
> from ./include/linux/rcupdate.h:43,
> from
On Wed, 26 Dec 2018 16:31:59 +0100 Ard Biesheuvel
wrote:
> Please stop sending EFI patches if you can't be bothered to
> test/reproduce against the EFI tree.
um, sorry, but that's a bit strong. Finding (let alone fixing) a bug
in EFI is a great contribution (thanks!) and the EFI maintainers
On Wed, 26 Dec 2018 13:15:22 +0800 Huang Ying wrote:
> KSM pages may be mapped to the multiple VMAs that cannot be reached
> from one anon_vma. So during swapin, a new copy of the page need to
> be generated if a different anon_vma is needed, please refer to
> comments of
z
Subject: hugetlbfs-use-i_mmap_rwsem-for-more-pmd-sharing-synchronization-fix
It would be better to make an explicit check for mapping != null before
calling i_mmap_lock_write/try_to_unmap. In this way, unrelated changes to
code above will not potentially lead to the possibility of mapping ==
On Fri, 9 Nov 2018 16:34:29 +0530 Anshuman Khandual
wrote:
> >
> > Do you see any problems with the patch as is?
>
> No, this patch does remove an erroneous node-cpu map update which help solve
> a real crash.
I think I'll take that as an ack.
Link:
http://lkml.kernel.org/r/1541618201-120667-1-git-send-email-yang@linux.alibaba.com
Signed-off-by: Yang Shi
Cc: Vlastimil Babka
Cc: Johannes Weiner
Cc: Hugh Dickins
Cc: Michal Hocko
Cc: Andrea Arcangeli
Signed-off-by: Andrew Morton
---
mm/vmscan.c | 23 +--
1 fil
On Tue, 18 Dec 2018 14:35:55 -0800 Mike Kravetz wrote:
> There are two primary issues addressed here:
> 1) For shared pmds, huge PTE pointers returned by huge_pte_alloc can become
>invalid via a call to huge_pmd_unshare by another thread.
> 2) hugetlbfs page faults can race with truncation
On Mon, 17 Dec 2018 16:17:52 -0800 Mike Kravetz wrote:
> ...
>
> > As you suggested in a comment to the subsequent patch, it would be better to
> > combine the patches and remove the dead code when it becomes dead. I will
> > work on that. Actually some of the code in patch 3 applies to patch
On Tue, 18 Dec 2018 08:36:55 +0100 Michal Hocko wrote:
> > > Signed-off-by: Oscar Salvador
>
> Acked-by: Michal Hocko
Thanks.
> > cc:stable?
>
> See http://lkml.kernel.org/r/20181217152936.gr30...@dhcp22.suse.cz. I
> believe nobody is simply using gigantic pages and hotplug at the same
>
1001 - 1100 of 25531 matches
Mail list logo
