On Wed, 10 Apr 2019 15:59:55 -0700 Kees Cook wrote:
> On Wed, Apr 10, 2019 at 3:54 PM Matteo Croce wrote:
> >
> > On Thu, Apr 11, 2019 at 12:34 AM Kees Cook wrote:
> > >
> > > On Wed, Apr 10, 2019 at 3:30 PM Matteo Croce wrote:
> > > >
> > > > FYI, this are the stats from my local repo, just
On Tue, 16 Apr 2019 13:54:04 -0700 Dan Williams
wrote:
> When a module option, or core kernel argument, toggles a static-key it
> requires jump labels to be initialized early. While x86, PowerPC, and
> ARM64 arrange for jump_label_init() to be called before parse_args(),
> ARM does not.
>
>
On Tue, 16 Apr 2019 18:14:00 -0500 Kees Cook wrote:
> On Tue, Apr 16, 2019 at 6:04 PM Andrew Morton
> wrote:
> >
> > >
> > > Reported-by: Ali Saidi
> > > Link:
> > > https://lkml.kernel.org/r/CAGXu5jJ5sj3emOT2QPxQkNQk0qbU6zEfu9=omfhx_p0
On Thu, 11 Apr 2019 17:32:12 +0200 Vitaly Wool wrote:
> This patchset implements page migration support and slightly better
> buddy search. To implement page migration support, z3fold has to move
> away from the current scheme of handle encoding. i. e. stop encoding
> page address in handles.
On Mon, 15 Apr 2019 21:23:20 -0700 Kees Cook wrote:
> Commit eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"),
> made changes in the rare case when the ELF loader was directly invoked
> (e.g to set a non-inheritable LD_LIBRARY_PATH, testing new versions of
> the loader), by moving
On Tue, 16 Apr 2019 14:32:48 +0800 Aubrey Li wrote:
> The architecture specific information of the running processes could
> be useful to the userland. Add support to examine process architecture
> specific information externally.
The implementation looks just fine to me. Have you had any
On Tue, 16 Apr 2019 16:52:56 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> On Fri, 29 Mar 2019 13:39:14 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:
> >
> > lib/list_sort.c:17:36:
On Tue, 16 Apr 2019 11:56:21 -0700 Tri Vo wrote:
> On Tue, Apr 16, 2019 at 10:55 AM Tri Vo wrote:
> >
> > On Tue, Apr 16, 2019 at 8:21 AM Jessica Yu wrote:
> > >
> > > +++ Tri Vo [15/04/19 11:18 -0700]:
> > > >Provide stubs for within_module_core(), within_module_init(), and
> > >
On Tue, 9 Apr 2019 12:01:45 +0200 David Hildenbrand wrote:
> __add_pages() doesn't add the memory resource, so __remove_pages()
> shouldn't remove it. Let's factor it out. Especially as it is a special
> case for memory used as system memory, added via add_memory() and
> friends.
>
> We now
On Wed, 10 Apr 2019 06:06:49 +1000 "Tobin C. Harding" wrote:
> On Tue, Apr 09, 2019 at 02:59:52PM +0200, Vlastimil Babka wrote:
> > On 4/3/19 11:13 PM, Tobin C. Harding wrote:
> >
> > > According to 0day test robot this is triggering an error from
> > > CHECK_DATA_CORRUPTION when the kernel is
On Tue, 9 Apr 2019 13:53:40 -0400 jgli...@redhat.com wrote:
> Was using wrong field and wrong enum for read only versus read and
> write mapping.
For thos who were wondering, this fixes
mm-hmm-add-an-helper-function-that-fault-pages-and-map-them-to-a-device-v3.patch,
which is presently queued
On Tue, 9 Apr 2019 13:42:08 -0700 Yury Norov wrote:
> From: Yury Norov
>
> cpumask_parse() finds first occurrence of either \n or \0 by calling
> strchr() and strlen(). We can do it better with a single call of
> strchrnul().
Fair enough.
> --- a/include/linux/cpumask.h
> +++
API
> currently) and altmap for alternative memmap allocator.
>
> This patch shouldn't introduce any functional change.
From: Andrew Morton
Subject:
mm-memory_hotplug-provide-a-more-generic-restrictions-for-memory-hotplug-fix
x86_64 allnoconfig:
In file included from ./include/linux/mmzone.h:74
(resend, cc Andrey)
On Sun, 7 Apr 2019 12:53:25 + Vadim Pasternak wrote:
> The warning is caused by call to rorXX(), if the second parameters of
> this function "shift" is zero. In such case UBSAN reports the warning
> for the next expression: (word << (XX - shift), where XX is
> 64, 32,
On Sun, 7 Apr 2019 12:53:25 + Vadim Pasternak wrote:
> The warning is caused by call to rorXX(), if the second parameters of
> this function "shift" is zero. In such case UBSAN reports the warning
> for the next expression: (word << (XX - shift), where XX is
> 64, 32, 16, 8 for respectively
On Tue, 18 Dec 2018 11:20:03 +0300 Dan Carpenter
wrote:
> The strndup_user() function returns error pointers on error, and then
> in the error handling we pass the error pointers to kfree(). It will
> cause an Oops.
>
Looks good to me.
I guess we should fix this too?
From: A
On Mon, 1 Apr 2019 14:20:44 -0400 Johannes Weiner wrote:
> On Fri, Mar 29, 2019 at 10:46:09AM -0700, Greg Thelen wrote:
> > @@ -3907,10 +3923,10 @@ void mem_cgroup_wb_stats(struct bdi_writeback *wb,
> > unsigned long *pfilepages,
> > struct mem_cgroup *memcg =
On Tue, 2 Apr 2019 15:34:15 +0200 Oscar Salvador wrote:
> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
> first determining whether it should be allocated in the stack or dinamically
> depending on NODES_SHIFT.
> Right now, it goes the dynamic path whenever the
On Tue, 2 Apr 2019 18:25:28 +0200 "Uladzislau Rezki (Sony)"
wrote:
> Changes in v3
> -
> - simplify the __get_va_next_sibling() and __find_va_links() functions;
> - remove "unlikely". Place the WARN_ON_ONCE directly to the "if" condition;
> - replace inline to __always_inline;
> -
On Wed, 3 Apr 2019 06:05:38 +1100 "Tobin C. Harding" wrote:
> > It's regrettable that this fixes
> > slob-respect-list_head-abstraction-layer.patch but doesn't apply to
> > that patch - slob-use-slab_list-instead-of-lru.patch gets in the way.
> > So we end up with a patch series which
On Sat, 30 Mar 2019 13:58:55 -0700 Trent Piepho wrote:
> In some cases the previous algorithm would not return the closest
> approximation. This would happen when a semi-convergent was the
> closest, as the previous algorithm would only consider convergents.
>
> As an example, consider an
On Tue, 2 Apr 2019 14:29:57 +1100 "Tobin C. Harding" wrote:
> Currently we call (indirectly) list_del() then we manually try to combat
> the fact that the list may be in an undefined state by getting 'prev'
> and 'next' pointers in a somewhat contrived manner. It is hard to
> verify that this
On Mon, 1 Apr 2019 13:03:47 +0200 Uladzislau Rezki wrote:
> Hello, Andrew.
>
> >
> > It's a lot of new code. I t looks decent and I'll toss it in there for
> > further testing. Hopefully someone will be able to find the time for a
> > detailed review.
> >
> I have got some proposals and
On Tue, 19 Mar 2019 08:16:00 + George Spelvin wrote:
> Rather than a fixed-size array of pending sorted runs, use the ->prev
> links to keep track of things. This reduces stack usage, eliminates
> some ugly overflow handling, and reduces the code size.
>
> Also:
> * merge() no longer needs
On Tue, 26 Mar 2019 00:07:44 +0300 Yury Norov wrote:
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -477,6 +477,42 @@ int bitmap_print_to_pagebuf(bool list, char *buf, const
> unsigned long *maskp,
> }
> EXPORT_SYMBOL(bitmap_print_to_pagebuf);
>
> +/*
> + * Region 9-38:4/10 describes the
On Fri, 22 Mar 2019 16:03:07 + Chris Down wrote:
> This patch is an incremental improvement on the existing
> memory.{low,min} relative reclaim work to base its scan pressure
> calculations on how much protection is available compared to the current
> usage, rather than how much the current
On Thu, 28 Feb 2019 11:30:17 -0500 Johannes Weiner wrote:
> Instead of adding up the node counters, use memcg_page_state() to get
> the memcg state directly. This is a bit cheaper and more stream-lined.
>
> ...
>
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -746,10 +746,13 @@ static
On Thu, 7 Mar 2019 08:56:32 -0800 Greg Thelen wrote:
> Since commit a983b5ebee57 ("mm: memcontrol: fix excessive complexity in
> memory.stat reporting") memcg dirty and writeback counters are managed
> as:
> 1) per-memcg per-cpu values in range of [-32..32]
> 2) per-memcg atomic counter
> When
On Thu, 21 Mar 2019 09:36:10 +0530 "Aneesh Kumar K.V"
wrote:
> MADV_DONTNEED is handled with mmap_sem taken in read mode.
> We call page_mkclean without holding mmap_sem.
>
> MADV_DONTNEED implies that pages in the region are unmapped and subsequent
> access to the pages in that range is
On Thu, 21 Mar 2019 20:03:26 +0100 "Uladzislau Rezki (Sony)"
wrote:
> Hello.
>
> This is the v2 of the https://lkml.org/lkml/2018/10/19/786 rework. Instead of
> referring you to that link, i will go through it again describing the improved
> allocation method and provide changes between v1 and
On Thu, 21 Mar 2019 10:02:37 -0700 Nick Desaulniers
wrote:
> Shall I send you a cleanup removing the undefs for bcmp, memcmp,
> strcat, strcpy, and strcmp? Of those, I only see memcmp being
> `#defined` in arch/m68k/include/asm/string.h, arch/x86/boot/string.h,
> and
On Wed, 13 Mar 2019 14:13:31 -0700 Nick Desaulniers
wrote:
> A recent optimization in Clang (r355672) lowers comparisons of the
> return value of memcmp against zero to comparisons of the return value
> of bcmp against zero. This helps some platforms that implement bcmp
> more efficiently than
On Wed, 20 Mar 2019 11:23:03 +0530 Souptick Joarder
wrote:
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -447,6 +447,13 @@ static inline bool queue_pages_required(struct page
> > *page,
> > return node_isset(nid, *qp->nmask) == !(flags & MPOL_MF_INVERT);
> > }
> >
> > +/*
>
On Wed, 20 Mar 2019 16:33:38 -0400 Qian Cai wrote:
> In a low-memory situation, cc->fast_search_fail can keep increasing as
> it is unable to find an available page to isolate in
> fast_isolate_freepages(). As the result, it could trigger an error
> below, so just compare with the maximum bits
On Wed, 20 Mar 2019 16:07:32 +0800 Baoquan He wrote:
> In function node_states_check_changes_online(), N_HIGH_MEMORY is used
> to substitute ZONE_HIGHMEM directly. This is not right. N_HIGH_MEMORY
> always has value '3' if CONFIG_HIGHMEM=y, while ZONE_HIGHMEM's value
> is not. It depends on
On Wed, 20 Mar 2019 18:29:29 +0900 Masatake YAMATO wrote:
> Finding endpoints of an IPC channel is one of essential task to
> understand how a user program works. Procfs and netlink socket provide
> enough hints to find endpoints for IPC channels like pipes, unix
> sockets, and pseudo terminals.
On Wed, 20 Mar 2019 01:32:53 +0300 "Dmitry V. Levin" wrote:
> On Tue, Mar 19, 2019 at 12:19:57PM -0700, Andrei Vagin wrote:
> > There are a few system calls (pselect, ppoll, etc) which replace a task
> > sigmask while they are running in a kernel-space
> >
> > When a task calls one of these
On Sun, 17 Mar 2019 11:34:31 -0700 ira.we...@intel.com wrote:
> Resending after rebasing to the latest mm tree.
>
> HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> advantages. These pages can be held for a significant time. But
> get_user_pages_fast() does not protect
On Tue, 19 Mar 2019 11:07:22 +0800 Peter Xu wrote:
> Add a global sysctl knob "vm.unprivileged_userfaultfd" to control
> whether userfaultfd is allowed by unprivileged users. When this is
> set to zero, only privileged users (root user, or users with the
> CAP_SYS_PTRACE capability) will be
On Tue, 19 Mar 2019 12:58:02 -0400 Jerome Glisse wrote:
> > So I think I'll throw up my hands, drop them all and shall await
> > developments :(
>
> What more do you want to see ? I can repost with the ack already given
> and the improve commit wording on some of the patch. But from user point
On Mon, 18 Mar 2019 13:04:04 -0400 Jerome Glisse wrote:
> On Wed, Mar 13, 2019 at 09:10:04AM -0700, Andrew Morton wrote:
> > On Tue, 12 Mar 2019 21:27:06 -0400 Jerome Glisse wrote:
> >
> > > Andrew you will not be pushing this patchset in 5.1 ?
> >
> >
On Tue, 12 Mar 2019 21:27:06 -0400 Jerome Glisse wrote:
> Andrew you will not be pushing this patchset in 5.1 ?
I'd like to. It sounds like we're converging on a plan.
It would be good to hear more from the driver developers who will be
consuming these new features - links to patchsets,
On Tue, 12 Mar 2019 20:10:19 -0400 Jerome Glisse wrote:
> > You're correct. We chose to go this way because the HMM code is so
> > large and all-over-the-place that developing it in a standalone tree
> > seemed impractical - better to feed it into mainline piecewise.
> >
> > This decision very
On Tue, 12 Mar 2019 12:30:52 -0700 Dan Williams
wrote:
> On Tue, Mar 12, 2019 at 12:06 PM Jerome Glisse wrote:
> > On Tue, Mar 12, 2019 at 09:06:12AM -0700, Dan Williams wrote:
> > > On Tue, Mar 12, 2019 at 8:26 AM Jerome Glisse wrote:
> [..]
> > > > Spirit of the rule is better than blind
On Tue, 12 Mar 2019 15:03:52 +0100 Bartosz Golaszewski
wrote:
> wt., 12 mar 2019 o 14:59 Khalid Aziz napisał(a):
> >
> > On 3/12/19 7:28 AM, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski
> > >
> > > The mm variable is set but unused. Remove it.
> >
> > It is used. Look further
> > >
> > > It is not good in my opinion to stick to -Wdeclaration-after-statement.
> >
> > Why?
>
> It is useful to have declarations mixed with code.
Am inclined to agree. Maybe.
> Once kernel will switch to C99 or C11 it _will_ be used to the point of
> requiring it on the coding style
On Tue, 12 Mar 2019 20:24:47 +0300 Alexey Dobriyan wrote:
> On Mon, Mar 11, 2019 at 05:38:45PM -0700, Andrew Morton wrote:
> > On Sun, 10 Mar 2019 16:35:35 +0300 Alexey Dobriyan
> > wrote:
> >
> > > Newly added static_assert() is formally a declaration, which wil
On Tue, 12 Mar 2019 07:08:38 +0100 Dmitry Vyukov wrote:
> On Tue, Mar 12, 2019 at 12:37 AM Andrew Morton
> wrote:
> >
> > On Mon, 11 Mar 2019 06:08:01 -0700 syzbot
> > wrote:
> >
> > > syzbot has bisected this bug to:
> > >
> > > com
in a bitmap memory region.
> >
> > Suggested-by: Andy Shevchenko
> > Suggested-by: Rasmus Villemoes
> > Cc: Arnd Bergmann
> > Cc: Andrew Morton
> > Reviewed-by: Andy Shevchenko
> > Reviewed-by: Linus Walleij
> > Signed-off-by: William Breath
On Sun, 10 Mar 2019 16:35:35 +0300 Alexey Dobriyan wrote:
> Newly added static_assert() is formally a declaration, which will give
> a warning if used in the middle of the function.
>
> ...
>
> --- a/Makefile
> +++ b/Makefile
> @@ -792,9 +792,6 @@ endif
> # arch Makefile may override CC so
On Mon, 11 Mar 2019 06:08:01 -0700 syzbot
wrote:
> syzbot has bisected this bug to:
>
> commit 29a4b8e275d1f10c51c7891362877ef6cffae9e7
> Author: Shakeel Butt
> Date: Wed Jan 9 22:02:21 2019 +
>
> memcg: schedule high reclaim for remote memcgs on high_work
>
> bisection log:
On Mon, 11 Mar 2019 10:20:06 -0700 Linus Torvalds
wrote:
> On Mon, Mar 11, 2019 at 12:43 AM kernel test robot
> wrote:
> >
> > ./run_vmtests: line 217: ./test_vmalloc.sh: Permission denied
>
> I marked that script executable:
>
> 6bc3fe8e7e17 ("tools: mark 'test_vmalloc.sh' executable")
>
3204.GA11405@avx2
Link: http://lkml.kernel.org/r/20190219094722.GB28258@shao2-debian
Fixes: 34aab6bec23e7e9 ("proc: test /proc/*/maps, smaps, smaps_rollup, statm")
Signed-off-by: Alexey Dobriyan
Reported-by: kernel test robot
Cc: Shuah Khan
Signed-off-by: Andrew Morton
On Thu, 7 Mar 2019 16:10:22 +0800 Li RongQing wrote:
> From: Li Rongqing
>
> msgctl10 of ltp triggers the following lockup When CONFIG_KASAN
> is enabled on large memory SMP systems, the pages initialization
> can take a long time, if msgctl10 requests a huge block memory,
> and it will block
On Tue, 5 Mar 2019 20:20:10 -0800 Dan Williams wrote:
> My hesitation would be drastically reduced if there was a plan to
> avoid dangling unconsumed symbols and functionality. Specifically one
> or more of the following suggestions:
>
> * EXPORT_SYMBOL_GPL on all exports to avoid a growing
On Thu, 7 Mar 2019 00:32:09 +0100 Dominique Martinet
wrote:
> Andrew Morton wrote on Wed, Mar 06, 2019:
> > On Wed, 6 Mar 2019 23:48:03 +0100 (CET) Jiri Kosina
> > wrote:
> >
> > > 3/3 is actually waiting for your decision, see
> > >
> > >
On Wed, 6 Mar 2019 23:48:03 +0100 (CET) Jiri Kosina wrote:
> 3/3 is actually waiting for your decision, see
>
> https://lore.kernel.org/lkml/20190212063643.gl15...@dhcp22.suse.cz/
I pity anyone who tried to understand this code by reading this code.
Can we please get some careful
On Wed, 30 Jan 2019 13:44:18 +0100 Vlastimil Babka wrote:
> From: Jiri Kosina
>
> The semantics of what mincore() considers to be resident is not completely
> clear, but Linux has always (since 2.3.52, which is when mincore() was
> initially done) treated it as "page is available in page
On Wed, 6 Mar 2019 13:11:39 +0100 (CET) Jiri Kosina wrote:
> On Wed, 30 Jan 2019, Vlastimil Babka wrote:
>
> > I've collected the patches from the discussion for formal posting. The first
> > two should be settled already, third one is the possible improvement I've
> > mentioned earlier, where
On Wed, 6 Mar 2019 10:49:04 -0500 Jerome Glisse wrote:
> On Tue, Mar 05, 2019 at 02:16:35PM -0800, Andrew Morton wrote:
> > On Wed, 30 Jan 2019 21:44:46 -0800 Dan Williams
> > wrote:
> >
> > > >
> > > > > Another way to help allay these worri
On Wed, 30 Jan 2019 21:44:46 -0800 Dan Williams
wrote:
> >
> > > Another way to help allay these worries is commit to no new exports
> > > without in-tree users. In general, that should go without saying for
> > > any core changes for new or future hardware.
> >
> > I always intend to have an
On Mon, 4 Mar 2019 20:15:40 -0800 Mike Kravetz wrote:
> Andrew, this is on top of Alexandre Ghiti's "hugetlb: allow to free gigantic
> pages regardless of the configuration" patch. Both patches modify
> __nr_hugepages_store_common(). Alex's patch is going to change slightly
> in this area.
On Mon, 4 Mar 2019 23:57:19 +0530 Souptick Joarder wrote:
> Remove duplicate header which is included twice.
>
> Signed-off-by: Sabyasachi Gupta
> Signed-off-by: Souptick Joarder
This signoff order makes me suspect that Sabyasachi was the author. If
so, the patch should have had
On Fri, 1 Mar 2019 16:57:52 -0500 Steven Rostedt wrote:
> Looks good to me.
>
> Acked-by: Steven Rostedt (VMware)
>
> Andrew, you want to take this patch?
Yup.
On Thu, 28 Feb 2019 19:49:03 -0500 Qian Cai wrote:
> The commit a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent
> hugepages") introduced pudp_huge_get_and_clear_full() but no one uses
> its return code, so just make it void.
>
> mm/huge_memory.c: In function 'zap_huge_pud':
>
On Fri, 1 Mar 2019 15:19:50 -0500 Qian Cai wrote:
> When onlining a memory block with DEBUG_PAGEALLOC, it unmaps the pages
> in the block from kernel, However, it does not map those pages while
> offlining at the beginning. As the result, it triggers a panic below
> while onlining on ppc64le as
le the shuffling if the
command line option is not specified.
Link:
http://lkml.kernel.org/r/154943713572.3858443.11206307988382889377.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
Cc: Kees Cook
Cc: Michal Hocko
Cc: Dave Hansen
Cc: Keith Busch
Signed-off-by: Andrew Morton
---
On Fri, 1 Mar 2019 14:52:07 +0200 Jani Nikula wrote:
> While is_power_of_2() is an inline function and likely gets optimized
> for compile time constant arguments, it still doesn't produce an integer
> constant expression that could be used in, say, static data
> initialization or case labels.
On Tue, 26 Feb 2019 16:04:04 -0800 Dan Williams
wrote:
> On Tue, Feb 26, 2019 at 4:00 PM Andrew Morton
> wrote:
> >
> > On Fri, 15 Feb 2019 18:51:51 + Mark Brown wrote:
> >
> > > On Fri, Feb 15, 2019 at 10:43:25AM -0800, Andrew Morton wrote:
> >
On Fri, 22 Feb 2019 14:09:59 +0800 Feng Tang wrote:
> When kernel panic happens, it will first print the panic call stack,
> then the ending msg like:
>
> [ 35.743249] ---[ end Kernel panic - not syncing: Fatal exception
> [ 35.749975] [ cut here ]
>
> The above
On Thu, 28 Feb 2019 05:53:37 -0700 William Kucharski
wrote:
> > On Feb 28, 2019, at 1:33 AM, Andrey Ryabinin
> > wrote:
>
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index a9852ed7b97f..2d081a32c6a8 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1614,8 +1614,8 @@ static
On Fri, 15 Feb 2019 18:51:51 + Mark Brown wrote:
> On Fri, Feb 15, 2019 at 10:43:25AM -0800, Andrew Morton wrote:
> > On Fri, 15 Feb 2019 10:20:10 -0800 (PST) "kernelci.org bot"
> > wrote:
>
> > > Details:https://kernelci.org/boot/id/5c666
[patch 1/4]: OK. I guess. Was this worth consuming our last PF_ flag?
[patch 2/4]: unreviewed
[patch 3/4]: unreviewed, mpe still unhappy, I expect?
[patch 4/4]: unreviewed
ch...@chrisdown.name: handle cgroup_disable=memory when getting memcg
protection]
Link: http://lkml.kernel.org/r/20190201045711.ga18...@chrisdown.name
Link: http://lkml.kernel.org/r/20190124014455.ga6...@chrisdown.name
Signed-off-by: Chris Down
Acked-by: Johannes Weiner
Reviewed-by: Roman Gushchin
C
>
> The number of node specific huge pages can be set via a file such as:
> /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
> When a node specific value is specified, the global number of huge
> pages must also be adjusted. This adjustment is calculated as the
> specified
On Tue, 26 Feb 2019 10:13:14 +0100 Oscar Salvador wrote:
> When using mremap() syscall in addition to MREMAP_FIXED flag,
> mremap() calls mremap_to() which does the following:
>
> 1) unmaps the destination region where we are going to move the map
> 2) If the new region is going to be smaller,
On Tue, 26 Feb 2019 18:58:03 +0900 Tetsuo Handa
wrote:
> Since commit a2e514453861dd39 ("kernel/hung_task.c: allow to set checking
> interval separately from timeout") added hung_task_check_interval_secs,
> setting a value different from hung_task_timeout_secs
>
> echo 0 >
On Thu, 21 Feb 2019 22:18:56 +0300 Dan Carpenter
wrote:
> On Thu, Feb 21, 2019 at 10:54:58AM -0800, Andrew Morton wrote:
> > On Thu, 21 Feb 2019 21:38:26 +0300 Dan Carpenter
> > wrote:
> >
> > > We put an upper bound on "new" but we don't check for
On Thu, 21 Feb 2019 11:11:06 -0800 Mike Kravetz wrote:
>
> Sorry for the churn. As I find and fix one issue I seem to discover another.
> There is still at least one more issue with private pages when COW comes into
> play. I continue to work that. I wanted to send this patch earlier as it
>
On Thu, 21 Feb 2019 06:52:04 -0800 syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:4aa9fc2a435a Revert "mm, memory_hotplug: initialize struct..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1101382f40
> kernel
(cc Jens ;))
On Thu, 21 Feb 2019 06:54:03 -0800 syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:c04e2a780caf Merge tag 'fsnotify_for_v5.0-rc4' of git://gi..
> git tree: upstream
> console output:
On Thu, 21 Feb 2019 21:38:26 +0300 Dan Carpenter
wrote:
> We put an upper bound on "new" but we don't check for negatives.
U8_MAX has unsigned type, so `if (new > U8_MAX)' does check for negative.
> In
> this case the underflow doesn't matter very much, but we may as well
> make the static
On Tue, 12 Feb 2019 14:14:00 -0800 Mike Kravetz wrote:
> hugetlb pages should only be migrated if they are 'active'. The routines
> set/clear_page_huge_active() modify the active state of hugetlb pages.
> When a new hugetlb page is allocated at fault time, set_page_huge_active
> is called
On Tue, 19 Feb 2019 18:28:30 + "Kani, Toshi" wrote:
> On Mon, 2019-02-18 at 13:57 +, YueHaibing wrote:
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > lib/ioremap.c: In function 'ioremap_page_range':
> > lib/ioremap.c:203:16: warning:
> > variable 'start' set but not used
On Fri, 15 Feb 2019 10:20:10 -0800 (PST) "kernelci.org bot"
wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual
On Fri, 15 Feb 2019 18:51:51 + Mark Brown wrote:
> On Fri, Feb 15, 2019 at 10:43:25AM -0800, Andrew Morton wrote:
> > On Fri, 15 Feb 2019 10:20:10 -0800 (PST) "kernelci.org bot"
> > wrote:
>
> > > Details:https://kernelci.org/boot/id/5c666
(cc linux-fsdevel)
On Mon, 11 Feb 2019 15:18:11 +0100 Matej Kupljen
wrote:
> Hi,
>
> it seems that when opening file on file system that is mounted on
> tmpfs with the O_TMPFILE flag and using linkat call after that, it
> uses 2 inodes instead of 1.
>
> This is simple test case:
>
>
On Thu, 14 Feb 2019 15:53:43 -0500 Johannes Weiner wrote:
>
> if (now < expires)
>
> vs.
>
> if (time_before64(now, expires))
>
> These macros always have me double check the argument order.
Yeah, me too.
On Thu, 14 Feb 2019 13:35:21 +0300 Kirill Tkhai wrote:
> Currently, struct reclaim_stat::nr_activate is a local variable,
> used only in shrink_page_list(). This patch introduces another
> local variable pgactivate to use instead of it, and reuses
> nr_activate to account number of active pages.
On Thu, 14 Feb 2019 12:45:51 + Peng Fan wrote:
> In case cma_init_reserved_mem failed, need to free the memblock allocated
> by memblock_reserve or memblock_alloc_range.
>
> ...
>
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -353,12 +353,14 @@ int __init cma_declare_contiguous(phys_addr_t base,
>
On Thu, 14 Feb 2019 15:33:18 +0100 Michal Hocko wrote:
> > Because swapoff() is very rare code path, to make the normal path runs as
> > fast as possible, disabling preemption + stop_machine() instead of
> > reference count is used to implement get/put_swap_device(). From
> > get_swap_device()
On Thu, 14 Feb 2019 09:56:46 -0800 Linus Torvalds
wrote:
> On Wed, Feb 13, 2019 at 3:37 PM Richard Weinberger
> wrote:
> >
> > Your shebang line exceeds BINPRM_BUF_SIZE.
> > Before the said commit the kernel silently truncated the shebang line
> > (and corrupted it),
> > now it tells the user
On Thu, 14 Feb 2019 14:31:57 -0500 Johannes Weiner wrote:
> --- a/kernel/sched/psi.c
> +++ b/kernel/sched/psi.c
> @@ -322,7 +322,7 @@ static bool update_stats(struct psi_group *group)
> expires = group->next_update;
> if (now < expires)
> goto out;
> - if (now -
On Wed, 13 Feb 2019 17:25:18 +1100 Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> fs/io_uring.c: In function 'io_async_list_note':
> fs/io_uring.c:931:16: error: 'VM_MAX_READAHEAD'
On Wed, 13 Feb 2019 23:13:29 +0200 Mike Rapoport wrote:
> > > As a bonus, since memblock_find_in_range() ensures the allocation in the
> > > specified range, the bounds check can be removed.
> >
> > hm, why is this against -mm rather than against mainline?
> >
> > Do the OF maintainers intend
On Wed, 13 Feb 2019 22:11:58 +0100 Jann Horn wrote:
> > This is probably more a davem patch than a -mm one.
>
> Ah, sorry. I assumed that I just should go by which directory the
> patched code is in.
>
> You did just add it to the -mm tree though, right? So I shouldn't
> resend it to davem?
On Wed, 13 Feb 2019 21:41:57 +0100 Jann Horn wrote:
> The basic idea behind ->pagecnt_bias is: If we pre-allocate the maximum
> number of references that we might need to create in the fastpath later,
> the bump-allocation fastpath only has to modify the non-atomic bias value
> that tracks the
On Wed, 13 Feb 2019 14:58:25 +0100 Andrey Konovalov
wrote:
> Changes in v2:
> - Add comments about kmemleak vs KASAN hooks order.
I assume this refers to Vincenzo's review of "kasan, kmemleak: pass
tagged pointers to kmemleak". But v2 of that patch is unchanged.
> - Fix compilation error
On Wed, 13 Feb 2019 09:56:04 -0800 syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:c4f3ef3eb53f Add linux-next specific files for 20190213
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1130a124c0
> kernel
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 =
901 - 1000 of 25530 matches
Mail list logo
