On Fri, 2 Nov 2018 12:25:16 -0700 Rick Edgecombe
wrote:
> This is V8 of the "KASLR feature to randomize each loadable module" patchset.
> The purpose is to increase the randomization and also to make the modules
> randomized in relation to each other instead of just the base, so that if one
> m
On Fri, 2 Nov 2018 12:25:17 -0700 Rick Edgecombe
wrote:
> Create __vmalloc_node_try_addr function that tries to allocate at a specific
> address without triggering any lazy purging. In order to support this behavior
> a try_addr argument was plugged into several of the static helpers.
Please e
On Sat, 3 Nov 2018 11:33:39 -0700 Olof Johansson wrote:
> The existing code triggered an invalid warning about 'rq' possibly being
> used uninitialized. Instead of doing the silly warning suppression by
> initializa it to NULL, refactor the code to bail out early instead.
>
> Warning was:
>
>
page or a page was already
released in z3fold_free(). So, the wrong page is encoded in headless, or
test_bit does not work properly in z3fold_reclaim_page(). This patch
fixed these problems.
Link:
http://lkml.kernel.org/r/1530853846-30215-1-git-send-email-ks7...@gmail.com
Signed-off-by: Jongseok
On Mon, 5 Nov 2018 13:23:15 -0800 Mike Kravetz wrote:
> This bug has been experienced several times by Oracle DB team.
> The BUG is in the routine remove_inode_hugepages() as follows:
> /*
>* If page is mapped, it was faulted in after being
>* unmapped in caller. Unmap (ag
On Mon, 5 Nov 2018 12:40:00 -0800 Bart Van Assche wrote:
> This patch suppresses the following sparse warning:
>
> ./include/linux/slab.h:332:43: warning: dubious: x & !y
>
> ...
>
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -329,7 +329,7 @@ static __always_inline enum kmall
On Mon, 5 Nov 2018 11:29:55 -0800 Sean Christopherson
wrote:
> ...and update its comment to explicitly reference its association with
> mmu_notifier_call_srcu().
>
> Contrary to its name, mmu_notifier_synchronize() does not synchronize
> the notifier's SRCU instance, but rather waits for RCU c
On Fri, 2 Nov 2018 01:00:07 +0800 wrote:
> From: Miles Chen
>
> The page owner read might allocate a large size of memory with
> a large read count. Allocation fails can easily occur when doing
> high order allocations.
>
> Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation
> an
On Wed, 31 Oct 2018 13:58:40 +0100 Michal Hocko wrote:
> From: Michal Hocko
>
> We have received a bug report that unbinding a large pmem (>1TB)
> can result in a soft lockup:
>
> ...
>
> It has been reported on an older (4.12) kernel but the current upstream
> code doesn't cond_resched in the
On Mon, 29 Oct 2018 21:15:01 +0800 kernel test robot
wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 68c37ccedcde10514898f4ba3b28c0de85c590d1 ("mm: nobootmem: remove
> bootmem allocation APIs")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git mas
On Thu, 25 Oct 2018 11:23:52 +0200 Michal Hocko wrote:
> On Wed 24-10-18 15:19:50, Andrew Morton wrote:
> > On Tue, 23 Oct 2018 16:43:29 + Roman Gushchin wrote:
> >
> > > Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs
> > > wit
On Thu, 25 Oct 2018 11:28:21 +0200 Vitaly Wool wrote:
> Reclaim and free can race on an object (which is basically ok) but
> in order for reclaim to be able to map "freed" object we need to
> encode object length in the handle. handle_to_chunks() is thus
> introduced to extract object length fro
On October 25, 2018 9:14:10 AM PDT, Michal Hocko wrote:
>Andrew. Do you want me to repost the patch or you plan to update the
>changelog yourself?
Please send a replacement changelog and I'll paste it in?
On Mon, 22 Oct 2018 15:27:54 +0200 Vlastimil Babka wrote:
> > : Moreover the oriinal code allowed to trigger
> > : WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));
> > : in policy_node if the requested node (e.g. cpu local one) was outside of
> > : the mbind nodemask. This is
off-by: Ralph Campbell
> Reviewed-by: John Hubbard
> Reviewed-by: Jérôme Glisse
> Reviewed-by: Balbir Singh
> Cc: Andrew Morton
> Cc: sta...@vger.kernel.org
I added your Signed-off-by: to this one. It's required since you were
on the patch delivery path.
On Fri, 19 Oct 2018 19:35:36 +0200 "Uladzislau Rezki (Sony)"
wrote:
> improving vmalloc allocator
It's about time ;)
Are you aware of https://lwn.net/Articles/285341/ ? If not, please do
take a look through Nick's work and see if there are any good things
there which can be borrowed.
On Mon, 22 Oct 2018 14:11:10 -0700 (PDT) David Rientjes
wrote:
> > Michal has been refusing timeout based approach, but I don't think this
> > is something we have to be frayed around the edge about possibility of
> > overlooking races/bugs just because Michal does not want to use timeout.
> > I
On Mon, 22 Oct 2018 10:13:48 -0700 Dan Williams
wrote:
> [ added Andrew ]
>
> Patch here: https://lore.kernel.org/patchwork/patch/1002234/
>
> On Sun, Oct 21, 2018 at 8:00 AM Sebastien Boisvert
> wrote:
> >
> > Tracing the event "fs_dax:dax_pmd_insert_mapping" with perf produces this
> > warn
On Tue, 23 Oct 2018 16:43:29 + Roman Gushchin wrote:
> Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs
> with a relatively small number of objects") leads to a regression on
> his setup: periodically the majority of the pagecache is evicted
> without an obvious reason, w
On Tue, 23 Oct 2018 16:43:29 + Roman Gushchin wrote:
> Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs
> with a relatively small number of objects") leads to a regression on
> his setup: periodically the majority of the pagecache is evicted
> without an obvious reason, w
On Wed, 26 Sep 2018 16:22:27 +0200 Michal Hocko wrote:
> > MPOL_PREFERRED is handled by policy_node() before we call
> > __alloc_pages_nodemask.
> > __GFP_THISNODE is applied only when we are not using
> > __GFP_DIRECT_RECLAIM which is handled in alloc_hugepage_direct_gfpmask
> > now.
> > Lastly
On Tue, 28 Aug 2018 13:22:49 -0400 Johannes Weiner wrote:
> This version 4 of the PSI series incorporates feedback from Peter and
> fixes two races in the lockless aggregator that Suren found in his
> testing and which caused the sample calculation to sometimes underflow
> and record bogusly larg
On Thu, 18 Oct 2018 20:46:21 -0400 Andrea Arcangeli wrote:
> On Thu, Oct 18, 2018 at 04:16:40PM -0700, Mike Kravetz wrote:
> > I was not sure about this, and expected someone could come up with
> > something better. It just seems there are filesystems like huegtlbfs,
> > where it makes no sense
On Wed, 17 Oct 2018 21:10:22 -0700 Mike Kravetz wrote:
> Some test systems were experiencing negative huge page reserve
> counts and incorrect file block counts. This was traced to
> /proc/sys/vm/drop_caches removing clean pages from hugetlbfs
> file pagecaches. When non-hugetlbfs explicit code
On Wed, 17 Oct 2018 16:21:08 -0600 Jeffrey Hugo wrote:
> On 10/17/2018 4:05 PM, Andrew Morton wrote:
> > On Wed, 17 Oct 2018 16:03:10 +0200 Anders Roxell
> > wrote:
> >
> >> Cc: Arnd Bergmann
> >> Co-developed-by: Arnd Bergmann
> >> Signed-
On Wed, 17 Oct 2018 09:36:00 +0800 kernel test robot
wrote:
> FYI, we noticed the following commit (built with gcc-6):
>
> commit: 6558038e4540a22ee4f99a5def74791189102bc0 ("mm/memory.c: recheck page
> table entry with page table lock held")
> https://git.kernel.org/cgit/linux/kernel/git/next/
On Wed, 17 Oct 2018 16:03:11 +0200 Anders Roxell
wrote:
> When enabling CONFIG_DEBUG_TEST_DRIVER_REMOVE devtmpfs gets killed
> because we try to remove a file and decrement the wb reference count
> before the noop_backing_device_info gets initialized.
>
> Since arch_initcall(pl011_init) came be
On Wed, 17 Oct 2018 16:03:10 +0200 Anders Roxell
wrote:
> Cc: Arnd Bergmann
> Co-developed-by: Arnd Bergmann
> Signed-off-by: Anders Roxell
This should have Arnd's Signed-off-by: as well.
On Tue, 16 Oct 2018 19:11:49 -0400 Andrea Arcangeli wrote:
> This was a severe regression
> compared to previous kernels that made important workloads unusable
> and it starts when __GFP_THISNODE was added to THP allocations under
> MADV_HUGEPAGE. It is not a significant risk to go to the previou
On Tue, 16 Oct 2018 08:46:06 +0100 Mel Gorman wrote:
> On Mon, Oct 15, 2018 at 03:44:59PM -0700, Andrew Morton wrote:
> > On Mon, 15 Oct 2018 15:30:17 -0700 (PDT) David Rientjes
> > wrote:
> >
> > > At the risk of beating a dead horse that has already been beat
On Tue, 16 Oct 2018 09:49:23 +0100 Mel Gorman
wrote:
> > Can we do this?
> >
> > --- a/mm/workingset.c~mm-workingset-add-vmstat-counter-for-shadow-nodes-fix
> > +++ a/mm/workingset.c
> > @@ -377,6 +377,8 @@ void workingset_update_node(struct radix
> > * already where they should be. The li
On Sat, 13 Oct 2018 15:50:58 +0200 Peter Zijlstra wrote:
> The whole raw_spinlock_t is for RT, no other reason.
Oh. I never realised that.
Is this documented anywhere? Do there exist guidelines which tell
non-rt developers and reviewers when it should be used?
On Mon, 15 Oct 2018 15:30:17 -0700 (PDT) David Rientjes
wrote:
> At the risk of beating a dead horse that has already been beaten, what are
> the plans for this patch when the merge window opens?
I'll hold onto it until we've settled on something. Worst case,
Andrea's original is easily backp
On Wed, 10 Oct 2018 23:49:45 +0200 Sebastian Andrzej Siewior
wrote:
> On 2018-10-10 11:57:41 [+0200], Dmitry Vyukov wrote:
> > Yes. Clark's patch looks good to me. Probably would be useful to add a
> > comment as to why raw spinlock is used (otherwise somebody may
> > refactor it back later).
>
On Fri, 12 Oct 2018 14:24:57 -0700 (PDT) David Rientjes
wrote:
> The slab allocator has a heuristic that checks whether the internal
> fragmentation is satisfactory and, if not, increases cachep->gfporder to
> try to improve this.
>
> If the amount of waste is the same at higher cachep->gfporde
On Fri, 12 Oct 2018 14:15:45 -0400 Jerome Glisse wrote:
> On Fri, Aug 24, 2018 at 03:25:42PM -0400, jgli...@redhat.com wrote:
> > From: Jérôme Glisse
> >
> > Few fixes that only affect HMM users. Improve the synchronization call
> > back so that we match was other mmu_notifier listener do and a
On Mon, 8 Oct 2018 08:32:28 -0600 Jonathan Corbet wrote:
> On Mon, 8 Oct 2018 10:38:29 +0200
> David Hildenbrand wrote:
>
> > > I can do the renaming and add the patch
> > >
> > > "memory-hotplug.txt: add some details about locking internals"
> > >
> > > on top of the jc_docs tree.
> > >
>
On Tue, 9 Oct 2018 17:42:09 -0700 John Hubbard wrote:
> > Also, maintainability. What happens if someone now uses put_page() by
> > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > this from occurring as code evolves? Is there a cheap way of detecting
> > this bug at r
On Tue, 9 Oct 2018 17:32:16 -0700 John Hubbard wrote:
> > I'm not really understanding. Patch 3/3 changes just one infiniband
> > driver to use put_user_page(). But the changelogs here imply (to me)
> > that every user of get_user_pages() needs to be converted to
> > s/put_page/put_user_page/.
On Tue, 2 Oct 2018 10:38:19 -0400 Masayoshi Mizuma
wrote:
> From: Naoya Horiguchi
>
> ...
>
> Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
> Signed-off-by: Naoya Horiguchi
> Tested-by: Oscar Salvador
> Tested-by: Masayoshi Mizuma
This patch and [2/3] should
On Wed, 10 Oct 2018 16:28:43 -0600 Keith Busch wrote:
> > > struct gup_benchmark {
> > > - __u64 delta_usec;
> > > + __u64 get_delta_usec;
> > > + __u64 put_delta_usec;
> > > __u64 addr;
> > > __u64 size;
> > > __u32 nr_pages_per_call;
> >
> > If we move put_delta_usec to the end of this
On Wed, 10 Oct 2018 13:56:03 -0600 Keith Busch wrote:
> This patch allows a user to specify a file to map by adding a new option,
> '-f', providing a means to test various file backings.
>
> If not specified, the benchmark will use a private mapping of /dev/zero,
> which produces an anonymous ma
On Wed, 10 Oct 2018 13:56:00 -0600 Keith Busch wrote:
> We'd like to measure time to unpin user pages, so this adds a second
> benchmark timer on put_page, separate from get_page.
>
> Adding the field will breaks this ioctl ABI, but should be okay since
> this an in-tree kernel selftest.
>
> ..
@gmail.com
> Signed-off-by: Pingfan Liu
> Acked-by: Christoph Lameter
> Cc: Pekka Enberg
> Cc: David Rientjes
> Cc: Joonsoo Kim
> Signed-off-by: Andrew Morton
> Signed-off-by: Stephen Rothwell
>
> list_add double add: new=
On Tue, 9 Oct 2018 10:30:25 +0200 Jan Kara wrote:
> > Also, maintainability. What happens if someone now uses put_page() by
> > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > this from occurring as code evolves? Is there a cheap way of detecting
> > this bug at runti
On Tue, 9 Oct 2018 16:28:11 +0200 Jack Wang wrote:
> From: Florian-Ewald Mueller
>
> During testing, I have configured 128 md/raid1's and, while under
> heavy IO, I started a check on each of them
> (echo check > /sys/block/mdx/md/sync_action).
>
> The CPU utilization went through the ceiling
On Tue, 9 Oct 2018 15:15:56 -0700 Andrew Morton
wrote:
> Seems sane, but I'm somewhat worried about unexpected effects on other
> workloads. So I think I'll hold this over for 4.20. Or shouldn't I?
Meant 4.21. But on reflection this is perhaps excessively cautious.
On Tue, 9 Oct 2018 14:47:33 -0400 Johannes Weiner wrote:
> The page cache and most shrinkable slab caches hold data that has been
> read from disk, but there are some caches that only cache CPU work,
> such as the dentry and inode caches of procfs and sysfs, as well as
> the subset of radix tree
On Tue, 9 Oct 2018 14:47:32 -0400 Johannes Weiner wrote:
> --- a/mm/workingset.c
> +++ b/mm/workingset.c
> @@ -378,11 +378,17 @@ void workingset_update_node(struct xa_node *node)
>* as node->private_list is protected by the i_pages lock.
>*/
> if (node->count && node->count
On Tue, 9 Oct 2018 14:47:32 -0400 Johannes Weiner wrote:
> Make it easier to catch bugs in the shadow node shrinker by adding a
> counter for the shadow nodes in circulation.
>
> Signed-off-by: Johannes Weiner
> ---
> include/linux/mmzone.h | 1 +
> mm/vmstat.c| 1 +
> mm/workin
On Tue, 9 Oct 2018 13:14:00 -0700 "Joel Fernandes (Google)"
wrote:
> Android needs to mremap large regions of memory during memory management
> related operations. The mremap system call can be really slow if THP is
> not enabled. The bottleneck is move_page_tables, which is copying each
> pte
On Mon, 8 Oct 2018 14:16:22 -0700 john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Introduces put_user_page(), which simply calls put_page().
> This provides a way to update all get_user_pages*() callers,
> so that they call put_user_page(), instead of put_page().
>
> Also introduces put
gt; This also gets rid of two shadowed variable declarations, as a
> tiny beneficial a side effect.
Reviewed-by: Andrew Morton
`i' is a pretty crappy identifier as well, but we'll live.
On Fri, 5 Oct 2018 13:56:39 -0700 (PDT) David Rientjes
wrote:
> If move_freepages() returns 0 because zone_spans_pfn(), *num_movable can
move_free_pages_block()? !zone_spans_pfn()?
> hold the value from the stack because it does not get initialized in
> move_freepages().
>
> Mo
On Fri, 5 Oct 2018 12:27:27 -0700 "Joel Fernandes (Google)"
wrote:
> To support the usecase, this patch adds a new F_SEAL_FS_WRITE seal which
> prevents any future mmap and write syscalls from succeeding while
> keeping the existing mmap active. The following program shows the seal
> working in
On Fri, 5 Oct 2018 15:45:26 +1000 Dave Chinner wrote:
> From: Dave Chinner
>
> We've recently seen a workload on XFS filesystems with a repeatable
> deadlock between background writeback and a multi-process
> application doing concurrent writes and fsyncs to a small range of a
> file.
>
> ...
On Fri, 28 Sep 2018 14:49:47 -0500 Mihir Mehta wrote:
> The file namei.c seems to have been renamed to namei_msdos.c, so I
> decided to update the comment with the correct name, and expand it a bit
> to tell the reader what to look for.
Please send us a Signed-off-by: for this patch, as per
Docu
31.21356-1-nixiaom...@huawei.com
Signed-off-by: nixiaoming
Cc: Jan Kara
Cc: Amir Goldstein
Cc: Kees Cook
Cc: Joel Fernandes
Cc: Geliang Tang
Signed-off-by: Andrew Morton
---
fs/pstore/ram.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/fs/pstore/ram
On Fri, 28 Sep 2018 14:28:32 +0300 Kirill Tkhai wrote:
> do_shrink_slab() returns unsigned long value, and
> the placing into int variable cuts high bytes off.
> Then we compare ret and 0xfffe (since SHRINK_EMPTY
> is converted to ret type).
>
> Thus, big number of objects returned by do_shr
On Thu, 27 Sep 2018 17:33:16 +0200 Jann Horn wrote:
> Restrict the ability to inspect kernel stacks of arbitrary tasks to root
> in order to prevent a local attacker from exploiting racy stack unwinding
> to leak kernel task stack contents.
> See the added comment for a longer rationale.
>
> The
On Wed, 26 Sep 2018 08:36:47 -0700 Dave Hansen wrote:
> On 09/26/2018 12:38 AM, Michal Hocko wrote:
> > Why cannot you simply go with [no]vm_page_poison[=on/off]?
>
> I was trying to look to the future a bit, if we end up with five or six
> more other options we want to allow folks to enable/dis
On Wed, 26 Sep 2018 15:14:45 +0200 Michal Hocko wrote:
> > Does anybody have good enough archive of the list to get started?
>
> Maybe Andrew has. Mine is incomplete for sure.
fwiw, I have everything going back to 2001. For some reason.
On Tue, 25 Sep 2018 14:45:19 -0700 (PDT) David Rientjes
wrote:
> > > It is also used in
> > > automated testing to ensure that vmas get disabled for thp appropriately
> > > and we used "nh" since that is how PR_SET_THP_DISABLE previously enforced
> > > this, and those tests now break.
> >
>
On Mon, 24 Sep 2018 16:24:08 +0200 Michal Hocko wrote:
> On Sat 22-09-18 22:53:32, zhe...@windriver.com wrote:
> > From: He Zhe
> >
> > debug_guardpage_minorder_setup and cmdline_parse_kernelcore do not check
> > input argument before using it. The argument would be a NULL pointer if
> > "debug
On Thu, 20 Sep 2018 21:00:16 +0100 Aaron Tomlin wrote:
> Extend the slub_debug syntax to "slub_debug=[,]*", where
> may contain an asterisk at the end. For example, the following would poison
> all kmalloc slabs:
>
> slub_debug=P,kmalloc*
>
> and the following would apply the default fl
On Thu, 20 Sep 2018 19:33:15 -0400 Joel Fernandes
wrote:
> On Thu, Sep 20, 2018 at 5:12 PM Todd Kjos wrote:
> >
> > +Joel Fernandes
> >
> > On Thu, Sep 20, 2018 at 2:11 PM Andrew Morton
> > wrote:
> > >
> > >
> > > Thanks. Let
Thanks. Let's cc the ashmem folks.
On Thu, 20 Sep 2018 14:04:05 -0700 syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a0cb0cabe4bb Add linux-next specific files for 20180920
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/l
heck into the calling code
(presumably in init/main.c) to print a warning if we have kernel
command line arguments such as "kernelcore=". That way, users will see
the warning immediately before the oops and will know how to fix things
up.
> --- a/mm/page_alloc.c
> +++ b/mm/page_a
On Sat, 15 Sep 2018 09:23:02 -0700 Dan Williams
wrote:
> Data exfiltration attacks via speculative execution and
> return-oriented-programming attacks rely on the ability to infer the
> location of sensitive data objects. The kernel page allocator, has
> predictable first-in-first-out behavior f
On Thu, 13 Sep 2018 15:32:25 -0700 "prakash.sangappa"
wrote:
> >> https://marc.info/?t=15252407341&r=1&w=2
> > It would be really great to give a short summary of the previous
> > discussion. E.g. why do we need a proc interface in the first place when
> > we already have an API to query for
On Tue, 28 Aug 2018 13:22:53 -0400 Johannes Weiner wrote:
> There are several definitions of those functions/macros in places that
> mess with fixed-point load averages. Provide an official version.
missed blk-iolatency.c for some reason?
---
a/block/blk-iolatency.c~sched-loadavg-consolidate-
On Wed, 12 Sep 2018 18:33:35 +0200 Oleg Nesterov wrote:
> Usage:
>
> rcu_read_lock();
> for_each_process_thread(p, t) {
> do_something_slow(p, t);
>
> if (SPENT_TOO_MUCH_TIME) {
> for_each_process_thread_break(p, t);
>
On Mon, 10 Sep 2018 00:00:18 +0200 Eugene Syromiatnikov wrote:
> On Tue, Aug 28, 2018 at 04:34:04PM -0700, Randy Dunlap wrote:
> > From: Randy Dunlap
> >
> > Since this header is in "include/uapi/linux/", apparently people
> > want to use it in userspace programs -- even in C++ ones.
> > Howeve
On Fri, 3 Aug 2018 16:40:21 +0200 Jürg Billeter wrote:
> PR_SET_KILLABLE clears the SIGNAL_UNKILLABLE flag. This allows
> CLONE_NEWPID tasks to restore normal signal behavior, opting out of the
> special signal protection for init processes. This prctl does not allow
> setting the SIGNAL_UNKILLA
On Wed, 5 Sep 2018 14:35:11 -0700 Mike Kravetz wrote:
> >so perhaps we could put some
> > stopgap workaround into that site and add a runtime warning into the
> > put_page() code somewhere to detect puttage of huge pages from hardirq
> > and softirq con
On Wed, 22 Aug 2018 11:07:14 +0800 Jia He wrote:
> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
> where possible") optimized the loop in memmap_init_zone(). But it causes
> possible panic bug. So Daniel Vacek reverted it later.
>
> But as suggested by Daniel Vacek, it
On Wed, 29 Aug 2018 14:33:19 -0700 Roman Gushchin wrote:
> >From d8237d3df222e6c5a98a74baa04bc52edf8a3677 Mon Sep 17 00:00:00 2001
> From: Roman Gushchin
> Date: Wed, 29 Aug 2018 14:14:48 -0700
> Subject: [PATCH] math64: prevent double calculation of DIV64_U64_ROUND_UP()
> arguments
>
> Cause
On Wed, 5 Sep 2018 00:38:22 +0200 Dominique Martinet
wrote:
> The 'm' kcore_list item could point to kclist_head, and it is incorrect to
> look at m->addr / m->size in this case.
> There is no choice but to run through the list of entries for every address
> if we did not find any entry in the
On Tue, 4 Sep 2018 15:47:07 -0700 Roman Gushchin wrote:
> Commit 9092c71bb724 ("mm: use sc->priority for slab shrink targets")
> changed the way how the target slab pressure is calculated and
> made it priority-based:
>
> delta = freeable >> priority;
> delta *= 4;
> do_div(delta, sh
On Wed, 5 Sep 2018 06:48:48 -0700 Matthew Wilcox wrote:
> > I didn't. The reason I looked at current patch is to enable the usage of
> > put_page() from irq context. We do allow that for non hugetlb pages. So was
> > not sure adding that additional restriction for hugetlb
> > is really needed. Fu
On Tue, 4 Sep 2018 12:45:28 +0100 Will Deacon wrote:
> This series builds on the core changes I previously posted here:
>
> rfc:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-August/597821.html
> v1:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-August
(cc linux-mm).
And thanks.
On Tue, 04 Sep 2018 17:08:34 +0200 Jacek Tomaka wrote:
> Hello,
>
> I was trying to track down the performance differences of one of my
> applications
> between running it on kernel used in Centos 7.4 and the latest 4.x version.
> On 4.x kernels its performance d
On Fri, 31 Aug 2018 11:33:48 +0530 Souptick Joarder
wrote:
> > > Return type of block_page_mkwrite_return() is also changed
> > > to use new vm_fault_t type.
> > > --- a/fs/nilfs2/file.c
> > > +++ b/fs/nilfs2/file.c
> > > @@ -51,13 +51,14 @@ int nilfs_sync_file(struct file *file, loff_t start,
On Mon, 3 Sep 2018 04:10:16 -0700 ktsanaktsi...@zendesk.com wrote:
> From: KJ Tsanaktsidis
>
> Make the clone and fork syscalls return EAGAIN when the limit on the
> number of pids /proc/sys/kernel/pid_max is exceeded.
>
> Currently, when the pid_max limit is exceeded, the kernel will return
>
On Thu, 30 Aug 2018 09:29:40 +0200 Vincent Whitchurch
wrote:
> On Tue, Aug 28, 2018 at 04:28:04PM -0700, Andrew Morton wrote:
> > On Tue, 28 Aug 2018 12:39:14 +0200 Vincent Whitchurch
> > wrote:
> >
> > > Add a script which converts /sys/kernel/debug/kmemleak
On Thu, 30 Aug 2018 22:55:47 +0530 Souptick Joarder
wrote:
> Return type for fault handlers in ext4 and nilfs are
> changed to use vm_fault_t.
>
> Return type of block_page_mkwrite() is changed from
> int to vm_fault_t. The function signature of
> block_page_mkwrite() is changed to add one new
On Thu, 30 Aug 2018 22:55:47 +0530 Souptick Joarder
wrote:
> Return type for fault handlers in ext4 and nilfs are
> changed to use vm_fault_t.
>
> Return type of block_page_mkwrite() is changed from
> int to vm_fault_t. The function signature of
> block_page_mkwrite() is changed to add one new
On Thu, 30 Aug 2018 12:44:36 -0700 Eric Biggers wrote:
> From: Eric Biggers
>
> This simplifies the code. No change in behavior.
>
> ...
>
> --- a/lib/parser.c
> +++ b/lib/parser.c
> @@ -327,10 +327,6 @@ EXPORT_SYMBOL(match_strlcpy);
> */
> char *match_strdup(const substring_t *s)
> {
> -
On Tue, 28 Aug 2018 22:35:02 +0300 Alexey Dobriyan wrote:
> > Are we really in a super hot path to justify all that?
>
> /proc is very slow, try profiling just about anything involving /proc.
So how much does this patchset help? Some timing measurements would
really help things along, if they
On Tue, 28 Aug 2018 12:20:46 +0800 Jia He wrote:
> Hi Andrew
> FYI,I watched a lockdep warning based on your mmotm master branch[1]
Thanks. We'll need help from ARM peeps on this please.
> [6.692731] [ cut here ]
> [6.696391] DEBUG_LOCKS_WARN_ON(!current->hardir
On Tue, 28 Aug 2018 19:42:24 -0700 Greg KH wrote:
> > --- lnx-416.orig/include/uapi/linux/keyctl.h
> > +++ lnx-416/include/uapi/linux/keyctl.h
> > @@ -65,7 +65,7 @@
> >
> > /* keyctl structures */
> > struct keyctl_dh_params {
> > - __s32 private;
> > + __s32 dh_private;
>
> Ick ick ick,
On Tue, 28 Aug 2018 12:39:14 +0200 Vincent Whitchurch
wrote:
> Add a script which converts /sys/kernel/debug/kmemleak_all to the pprof
> format, which can be used for analysing memory usage. See
> https://github.com/google/pprof.
Why is this better than /proc/slabinfo?
> $ ./kmemleak2pprof.p
On Tue, 28 Aug 2018 23:01:58 +0200 Oscar Salvador
wrote:
> From: Oscar Salvador
>
> check_for_memory looks a bit confusing.
> First of all, we have this:
>
> if (N_MEMORY == N_NORMAL_MEMORY)
> return;
>
> Checking the ENUM declaration, looks like N_MEMORY canot be equal to
> N_NORMAL_M
On Mon, 27 Aug 2018 15:55:33 +0800 Huang Ying wrote:
> The code path to reclaim the swap entry in free_swap_and_cache() is
> almost same as that of __try_to_reclaim_swap(). The largest
> difference is just coding style. So the support to the additional
> requirement of free_swap_and_cache() is
On Mon, 27 Aug 2018 10:38:21 +0200 Vincent Whitchurch
wrote:
> Currently, kmemleak only prints the number of suspected leaks to dmesg
> but requires the user to read a debugfs file to get the actual stack
> traces of the objects' allocation points. Add an option to print the
> full object infor
On Mon, 27 Aug 2018 09:26:21 -0700 Roman Gushchin wrote:
> I've noticed, that dying memory cgroups are often pinned
> in memory by a single pagecache page. Even under moderate
> memory pressure they sometimes stayed in such state
> for a long time. That looked strange.
>
> My investigation show
On Mon, 27 Aug 2018 09:26:19 -0700 Roman Gushchin wrote:
> If CONFIG_VMAP_STACK is set, kernel stacks are allocated
> using __vmalloc_node_range() with __GFP_ACCOUNT. So kernel
> stack pages are charged against corresponding memory cgroups
> on allocation and uncharged on releasing them.
>
> The
On Tue, 21 Aug 2018 14:14:30 +0800 Jia He wrote:
> Hi Pasha
>
> On 8/17/2018 9:08 AM, Pasha Tatashin Wrote:
> >
> >> Signed-off-by: Jia He
> >> ---
> >> mm/memblock.c | 37 +
> >> 1 file changed, 29 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/mm/me
On Tue, 21 Aug 2018 14:30:24 +0200 Oscar Salvador
wrote:
> On Tue, Aug 21, 2018 at 02:17:34PM +0200, Michal Hocko wrote:
> > We do have CONFIG_NODES_SHIFT=10 in our SLES kernels for quite some
> > time (around SLE11-SP3 AFAICS).
> >
> > Anyway, isn't NODES_ALLOC over engineered a bit? Does actu
On Tue, 21 Aug 2018 18:21:22 +0200 Oscar Salvador
wrote:
> On Fri, Aug 17, 2018 at 11:00:13AM +0200, Oscar Salvador wrote:
> > From: Oscar Salvador
> >
> > v3 -> v4:
> > - Make nodemask_t a stack variable
> > - Added Reviewed-by from David and Pavel
> >
> > v2 -> v3:
> >
1201 - 1300 of 12574 matches
Mail list logo
