On Wed, 26 Jun 2019 15:45:47 + Jason Gunthorpe wrote:
> On Wed, Jun 26, 2019 at 08:38:29AM -0700, Christoph Hellwig wrote:
> > On Wed, Jun 26, 2019 at 01:31:40PM +0100, Mark Rutland wrote:
> > > On Wed, Jun 26, 2019 at 12:35:33AM -0700, Christoph Hellwig wrote:
> > > > Robin, Andrew:
> > >
On Wed, 26 Jun 2019 21:10:00 +0800 Pingfan Liu wrote:
> Both hugetlb and thp locate on the same migration type of pageblock, since
> they are allocated from a free_list[]. Based on this fact, it is enough to
> check on a single subpage to decide the migration type of the whole huge
> page. By
On Wed, 26 Jun 2019 16:20:13 +0200 Marco Elver wrote:
> This refactors common code of ksize() between the various allocators
> into slab_common.c: __ksize() is the allocator-specific implementation
> without instrumentation, whereas ksize() includes the required KASAN
> logic.
>
> ...
>
> /**
On Wed, 26 Jun 2019 12:56:14 -0400 Waiman Long wrote:
> With memory cgroup v1, there is a kmem.slabinfo file that can be
> used to view what slabs are allocated to the memory cgroup. There
> is currently no such equivalent in memory cgroup v2. This file can
> be useful for debugging purpose.
>
On Tue, 25 Jun 2019 15:29:38 -0700 Andrew Morton
wrote:
> On Tue, 25 Jun 2019 15:35:18 +0530 Vinod Koul wrote:
>
> > DIV_ROUND_UP_ULL adds the two arguments and then invokes
> > DIV_ROUND_DOWN_ULL. But on a 32bit system the addition of two 32 bit
> > values can over
UP_ULL
return DIV_ROUND_UP_ULL((u64)nr_pages * this_bw, tot_bw);
From: Andrew Morton
Subject: linux-kernelh-fix-overflow-for-div_round_up_ull-fix
DIV_ROUND_UP_ULL must be an rval
Cc: Bjorn Andersson
Cc: Randy Dunlap
Cc: Vinod Koul
Signed-off-by: Andrew Morton
---
include/linux/kernel.h |
On Thu, 13 Jun 2019 05:56:48 +0800 Yang Shi wrote:
> Currently shrinker is just allocated and can work when memcg kmem is
> enabled. But, THP deferred split shrinker is not slab shrinker, it
> doesn't make too much sense to have such shrinker depend on memcg kmem.
> It should be able to reclaim
On Thu, 13 Jun 2019 05:56:49 +0800 Yang Shi wrote:
> Currently THP deferred split shrinker is not memcg aware, this may cause
> premature OOM with some configuration. For example the below test would
> run into premature OOM easily:
>
> $ cgcreate -g memory:thp
> $ echo 4G >
On Mon, 24 Jun 2019 17:20:51 -0700 Doug Berger wrote:
> The description of the cma_declare_contiguous() function indicates
> that if the 'fixed' argument is true the reserved contiguous area
> must be exactly at the address of the 'base' argument.
>
> However, the function currently allows the
On Tue, 25 Jun 2019 16:28:12 +0300 Andy Shevchenko
wrote:
> On Tue, Jun 25, 2019 at 04:01:04PM +0300, Alexandru Ardelean wrote:
> > The documentation the `__sysfs_match_string()` helper mentions that `n`
> > (the size of the given array) should be:
> > * @n: number of strings in the array or
On Tue, 25 Jun 2019 16:37:13 +0200 Christoph Hellwig wrote:
> +static int gup_huge_pd(hugepd_t hugepd
Naming nitlet: we have hugepd and we also have huge_pd. We have
hugepte and we also have huge_pte. It make things a bit hard to
remember and it would be nice to make it all consistent
On Mon, 24 Jun 2019 21:00:43 +1000 Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> mm/util.c: In function '__account_locked_vm':
> mm/util.c:372:2: error: implicit declaration of function
emoryc-get-rid-of-find_memory_block_hinted-v3-fix
handle zero-length walks
Link: http://lkml.kernel.org/r/1c2edc22-afd7-2211-c4c7-40e54e500...@redhat.com
Reported-by: Qian Cai
Tested-by: Qian Cai
Signed-off-by: Andrew Morton
---
drivers/base/memory.c |3 +++
1 file changed, 3 insertions(+)
-
On Tue, 18 Jun 2019 16:06:22 +0200 Uladzislau Rezki wrote:
> On Tue, Jun 18, 2019 at 09:40:28AM -0400, Joel Fernandes wrote:
> > On Tue, Jun 18, 2019 at 5:27 AM Arnd Bergmann wrote:
> > >
> > > gcc gets confused in pcpu_get_vm_areas() because there are too many
> > > branches that affect
On Tue, 18 Jun 2019 13:43:52 +0100 Colin King wrote:
> From: Colin Ian King
>
> Currently the calcuation of end_pfn can round up the pfn number to
> more than the actual maximum number of pfns, causing an Oops. Fix
> this by ensuring end_pfn is never more than max_pfn.
>
> This can be easily
On Wed, 12 Jun 2019 21:59:03 -0700 Nadav Amit wrote:
> For efficient search of resources, as needed to determine the memory
> type for dax page-faults, introduce a cache of the most recently used
> top-level resource. Caching the top-level should be safe as ranges in
> that level do not overlap
On Wed, 12 Jun 2019 21:59:01 -0700 Nadav Amit wrote:
> Since resources can be removed, locking should ensure that the resource
> is not removed while accessing it. However, find_next_iomem_res() does
> not hold the lock while copying the data of the resource.
Looks right to me.
> Keep holding
On Sat, 15 Jun 2019 10:06:54 +0200 Christophe Leroy
wrote:
>
>
> Le 14/06/2019 à 21:00, Andrew Morton a écrit :
> > On Fri, 14 Jun 2019 12:01:09 +0200 David Hildenbrand
> > wrote:
> >
> >> We are using a mixture of "int" and "unsig
On Mon, 17 Jun 2019 06:23:07 -0700 Shakeel Butt wrote:
> > Here is a patch to use CSS_TASK_ITER_PROCS.
> >
> > From 415e52cf55bc4ad931e4f005421b827f0b02693d Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa
> > Date: Mon, 17 Jun 2019 00:09:38 +0900
> > Subject: [PATCH] mm: memcontrol: Use
On Fri, 14 Jun 2019 12:01:09 +0200 David Hildenbrand wrote:
> We are using a mixture of "int" and "unsigned long". Let's make this
> consistent by using "unsigned long" everywhere. We'll do the same with
> memory block ids next.
>
> ...
>
> - int i, ret, section_count = 0;
> + unsigned
On Thu, 13 Jun 2019 15:37:24 +0530 Anshuman Khandual
wrote:
> Architectures which support kprobes have very similar boilerplate around
> calling kprobe_fault_handler(). Use a helper function in kprobes.h to unify
> them, based on the x86 code.
>
> This changes the behaviour for other
On Thu, 13 Jun 2019 22:07:44 +0800 Xiaoming Ni wrote:
> Registering the same notifier to a hook repeatedly can cause the hook
> list to form a ring or lose other members of the list.
>
> case1: An infinite loop in notifier_chain_register can cause soft lockup
>
On Thu, 13 Jun 2019 10:54:50 -0400 Joel Savitz wrote:
> The kernel provides no architecture-independent mechanism to get the
> size of the virtual address space of a task (userspace process) without
> brute-force calculation. This patch allows a user to easily retrieve
> this value via a new
On Wed, 12 Jun 2019 16:14:28 -0700 Andrei Vagin wrote:
> On Sun, Jun 09, 2019 at 01:09:00PM +0300, Konstantin Khlebnikov wrote:
> > Do not stuck forever if something wrong.
> > Killable lock allows to cleanup stuck tasks and simplifies investigation.
>
> This patch breaks the CRIU project,
On Thu, 13 Jun 2019 00:01:20 +0200 Matteo Croce wrote:
> Commit cefdca0a86be ("userfaultfd/sysctl: add vm.unprivileged_userfaultfd")
> reintroduces a reference to 'zero' and 'one'.
> Use the SYSCTL_{ZERO,ONE} symbols instead.
proc-sysctl-add-shared-variables-for-range-check-fix.patch (which has
On Wed, 12 Jun 2019 13:57:53 -0400 Joel Savitz
wrote:
> In the event of an oom kill, useful information about the killed
> process is printed to dmesg. Users, especially system administrators,
> will find it useful to immediately see the UID of the process.
>
> In the following example,
On Wed, 12 Jun 2019 07:15:30 -0700 Randy Dunlap wrote:
> On 6/11/19 4:59 PM, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2019-06-11-16-59 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for
On Wed, 12 Jun 2019 08:53:33 +0200 David Hildenbrand wrote:
> >>> ...
> >>>
> >>>
> >>> - Rebased on linux-next (next-20190611)
> >>
> >> Yet the patch you've prepared is designed for 5.3. Was that
> >> deliberate, or should we be targeting earlier kernels?
> >
> > It was deliberate for 5.3 as
On Tue, 11 Jun 2019 16:18:04 -0700 Roman Gushchin wrote:
> Subject: [PATCH v7 01/10] mm: postpone kmem_cache memcg pointer
> initialization to memcg_link_cache()]
I think mm is too large a place for patches to be described as
affecting simply "mm". So I'll irritatingly rewrite all these
On Tue, 11 Jun 2019 16:56:13 +0530 Anshuman Khandual
wrote:
> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs
> entries between memory block and node. It first checks pfn validity with
> pfn_valid_within() before fetching nid. With CONFIG_HOLES_IN_ZONE config
> (arm64
On Fri, 7 Jun 2019 16:43:31 -0700 Florian Fainelli
wrote:
> With architectures allowing the kernel to be placed almost arbitrarily
> in memory (e.g.: ARM64), it is possible to have the kernel resides at
> physical addresses above 4GB, resulting in neither the default CMA area,
> nor the atomic
On Mon, 10 Jun 2019 17:18:05 +0900 Naoya Horiguchi
wrote:
> The pass/fail of soft offline should be judged by checking whether the
> raw error page was finally contained or not (i.e. the result of
> set_hwpoison_free_buddy_page()), but current code do not work like that.
> So this patch is
On Mon, 10 Jun 2019 17:33:54 +0100 Mark Rutland wrote:
> The naming of pgtable_page_{ctor,dtor}() seems to have confused a few
> people, and until recently arm64 used these erroneously/pointlessly for
> other levels of pagetable.
>
> To make it incredibly clear that these only apply to the PTE
On Thu, 6 Jun 2019 15:06:26 -0700 Dan Williams wrote:
> On Thu, Jun 6, 2019 at 2:46 PM Andrew Morton
> wrote:
> >
> > On Wed, 05 Jun 2019 14:58:58 -0700 Dan Williams
> > wrote:
> >
> > > At namespace creation time there is the potential for the "
On Wed, 05 Jun 2019 14:58:58 -0700 Dan Williams
wrote:
> At namespace creation time there is the potential for the "expected to
> be zero" fields of a 'pfn' info-block to be filled with indeterminate
> data. While the kernel buffer is zeroed on allocation it is immediately
> overwritten by
On Thu, 6 Jun 2019 09:22:34 +0800 Aubrey Li wrote:
> The architecture specific information of the running processes
> could be useful to the userland. Add /proc//arch_status
> interface support to examine process architecture specific
> information externally.
I'll grab these for some testing.
On Wed, 5 Jun 2019 17:10:19 +0800 Pingfan Liu wrote:
> As for FOLL_LONGTERM, it is checked in the slow path
> __gup_longterm_unlocked(). But it is not checked in the fast path, which
> means a possible leak of CMA page to longterm pinned requirement through
> this crack.
>
> Place a check in
On Thu, 6 Jun 2019 00:48:13 +1000 Nicholas Piggin wrote:
> The kernel currently clamps large system hashes to MAX_ORDER when
> hashdist is not set, which is rather arbitrary.
>
> vmalloc space is limited on 32-bit machines, but this shouldn't
> result in much more used because of small
On Tue, 4 Jun 2019 19:44:44 -0700 Roman Gushchin wrote:
> So instead of trying to find a maybe non-existing balance, let's do reparent
> the accounted slabs to the parent cgroup on cgroup removal.
s/slabs/slab caches/. Take more care with the terminology, please...
> There is a bonus:
On Mon, 3 Jun 2019 14:32:03 +0530 Maninder Singh
wrote:
> currently params structure is passed in all functions, which increases
> stack usage in all the function and lead to stack overflow on target like
> ARM with kernel stack size of 8 KB so better to pass pointer.
>
> Checked for ARM:
>
(ooh, Greg, let me do it!)
On Thu, 30 May 2019 02:58:59 +0200 John Ogness
wrote:
> Commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in
> /proc/PID/stat") stopped reporting eip/esp and commit fd7d56270b52
> ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping")
> reintroduced
On Wed, 29 May 2019 15:06:53 -0400 Qian Cai wrote:
> The commit 0619317ff8ba ("block: add polled wakeup task helper")
> replaced wake_up_process() with blk_wake_io_task() in
> end_swap_bio_read() which triggers a crash when running heavy swapping
> workloads.
>
> [T114538] kernel BUG at
On Wed, 29 May 2019 22:11:10 +0300 Alexey Dobriyan wrote:
> Don't repeat function signatures twice.
>
> This is a kind-of-precursor for "struct proc_ops".
>
> Note:
>
> typeof(pde->proc_fops->...) ...;
>
> can't be used because ->proc_fops is "const struct file_operations *".
> "const"
On Thu, 30 May 2019 00:37:08 +0300 Alexey Dobriyan wrote:
> AT_RANDOM content is always misaligned on x86_64:
>
> $ LD_SHOW_AUXV=1 /bin/true | grep AT_RANDOM
> AT_RANDOM: 0x7fff02101019
>
> glibc copies first few bytes for stack protector stuff, aligned
> access should be
On Wed, 29 May 2019 14:46:24 +0530 Anshuman Khandual
wrote:
> This series enables memory hot remove on arm64 after fixing a memblock
> removal ordering problem in generic __remove_memory() and one possible
> arm64 platform specific kernel page table race condition. This series
> is based on
On Wed, 29 May 2019 10:55:53 +0200 John Ogness
wrote:
> Commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in
> /proc/PID/stat") stopped reporting eip/esp and commit fd7d56270b52
> ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping")
> reintroduced the feature to fix a
On Sun, 26 May 2019 19:33:25 +0200 Sebastian Andrzej Siewior
wrote:
> From: Hugh Dickins
>
> Since commit
>
>d9c9ce34ed5c8 ("x86/fpu: Fault-in user stack if copy_fpstate_to_sigframe()
> fails")
Please add this as a
Fixes: d9c9ce34ed5c8 ("x86/fpu: Fault-in user stack if
On Mon, 27 May 2019 14:29:58 +0200 Geert Uytterhoeven
wrote:
> There is no need to print an error message and backtrace if
> kmalloc_node() fails, as the memory allocation core already takes care
> of that.
>
> ...
>
> --- a/lib/cpumask.c
> +++ b/lib/cpumask.c
> @@ -114,13 +114,6 @@ bool
On Tue, 28 May 2019 12:34:28 -0500 ebied...@xmission.com (Eric W. Biederman)
wrote:
> Didn't someone already provide a fix for this one?
>
> I thought I saw that hit your tree a while ago. I am looking in
> ptrace.c and I don't see anything that would have fixed this issue.
I can't find
On Fri, 24 May 2019 17:49:18 +0200 Vitaly Wool wrote:
> For each page scheduled for compaction (e. g. by z3fold_free()),
> try to apply inter-page compaction before running the traditional/
> existing intra-page compaction. That means, if the page has only one
> buddy, we treat that buddy as a
On Fri, 24 May 2019 13:50:45 -0400 Daniel Jordan
wrote:
> locked_vm accounting is done roughly the same way in five places, so
> unify them in a helper. Standardize the debug prints, which vary
> slightly, but include the helper's caller to disambiguate between
> callsites.
>
> Error codes
On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
> load_flat_shared_library() is broken: It only calls load_flat_file() if
> prepare_binprm() returns zero, but prepare_binprm() returns the number of
> bytes read - so this only happens if the file is empty.
ouch.
> Instead, call into
(Cc Vlastimil)
On Sat, 25 May 2019 15:07:23 +0800 zhong jiang wrote:
> We bind an different node to different vma, Unluckily,
> it will bind different vma to same node by checking the /proc/pid/numa_maps.
>
> Commit 213980c0f23b ("mm, mempolicy: simplify rebinding mempolicies when
>
On Fri, 24 May 2019 11:30:45 +0800 Gen Zhang wrote:
> In dir_add() and do_name(), de->name and vcollected are allocated by
> kstrdup(). And de->name and vcollected are dereferenced in the following
> codes. However, memory allocation functions such as kstrdup() may fail.
> Dereferencing this
is an
Acked-by: Andrew Morton
from a procfs POV and shall let the x86 maintainers worry about it.
I must say I'm a bit surprised that we don't already provide some form
of per-process CPU-specific info anywhere in procfs. Something to
piggy-back this onto. But I can't find such a thing.
I assume w
On Thu, 9 May 2019 19:26:33 -0700 Yury Norov wrote:
> Hi Andy,
>
> Thanks for thorough review.
>
> On Wed, May 08, 2019 at 11:46:32AM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 30, 2019 at 06:06:34PM -0700, Yury Norov wrote:
> > > bitmap_parse() is ineffective and full of opaque variables
On Sat, 4 May 2019 19:33:02 -0400 Michal Hocko wrote:
> CCing Oleg.
>
> On Fri 03-05-19 22:28:00, Alexey Dobriyan wrote:
> [...]
> > add/remove: 0/0 grow/shrink: 8/68 up/down: 49/-1147 (-1098)
> [...]
> > --- a/include/linux/sched/signal.h
> > +++ b/include/linux/sched/signal.h
> > @@ -15,10
On Mon, 20 May 2019 10:54:16 -0700 (PDT) David Rientjes
wrote:
> We are going in circles, *yes* there is a problem for potential swap
> storms today because of the poor interaction between memory compaction and
> directed reclaim but this is a result of a poor API that does not allow
>
On Thu, 23 May 2019 20:57:36 +0300 Alexey Dobriyan wrote:
> Only executable ELF program headers should change ->start_code.
>
> ...
>
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1026,7 +1026,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> }
>
On Wed, 22 May 2019 21:43:54 + Roman Gushchin wrote:
> Is this patchset good to go? Or do you have any remaining concerns?
>
> It has been carefully reviewed by Shakeel; and also Christoph and Waiman
> gave some attention to it.
>
> Since commit 172b06c32b94 ("mm: slowly shrink slabs with
On Thu, 23 May 2019 07:39:25 +1000 Stephen Rothwell
wrote:
> > I put an example patch into my subversion repository:
> >
> > svn checkout https://svn.osdn.net/svnroot/tomoyo/branches/syzbot-patches/
> >
> > To fetch up-to-date debug printk() patches:
> >
> > cd syzbot-patches
> > svn
On Wed, 22 May 2019 23:38:29 +0300 Mike Rapoport wrote:
> (added kvm)
>
> On Wed, May 22, 2019 at 12:21:13PM -0700, Andrew Morton wrote:
> > On Tue, 14 May 2019 17:29:55 +0300 Mike Rapoport wrote:
> >
> > > When get_user_pages*() is called wit
On Tue, 14 May 2019 17:29:55 +0300 Mike Rapoport wrote:
> When get_user_pages*() is called with pages = NULL, the processing of
> VM_FAULT_RETRY terminates early without actually retrying to fault-in all
> the pages.
>
> If the pages in the requested range belong to a VMA that has userfaultfd
>
On Wed, 22 May 2019 13:14:41 +0200 Arnd Bergmann wrote:
> > I thought the preferred approach was to wire up the architectures on
> > which the submitter has tested the syscall, then allow the arch
> > maintainers to enable the syscall independently?
>
> I'm hoping to change that practice now,
es the kernel code grow by ~70k (that's kind
> of a max estimate since not all users will be compiled in).
eep, let's not do that.
> --- a/include/linux/sort.h
> +++ b/include/linux/sort.h
Patch otherwise looks OK. Please include it with the patch series
which uses it. Feel free to add
Acked-by: Andrew Morton
On Wed, 22 May 2019 17:09:39 +0200 "Uladzislau Rezki (Sony)"
wrote:
> Move the BUG_ON()/RB_EMPTY_NODE() check under unlink_va()
> function, it means if an empty node gets freed it is a BUG
> thus is considered as faulty behaviour.
So... this is an expansion of the assertion's coverage?
On Wed, 22 May 2019 17:09:38 +0200 "Uladzislau Rezki (Sony)"
wrote:
> It does not make sense to try to "unlink" the node that is
> definitely not linked with a list nor tree. On the first
> merge step VA just points to the previously disconnected
> busy area.
>
> On the second step, check if
On Wed, 22 May 2019 17:09:37 +0200 "Uladzislau Rezki (Sony)"
wrote:
> Introduce ne_fit_preload()/ne_fit_preload_end() functions
> for preloading one extra vmap_area object to ensure that
> we have it available when fit type is NE_FIT_TYPE.
>
> The preload is done per CPU and with GFP_KERNEL
On Wed, 22 May 2019 18:16:14 +0200 Jan Luebbe wrote:
> Commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in
> /proc/PID/stat") stopped reporting eip/esp and commit fd7d56270b52
> ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping")
> reintroduced the feature to fix a regression
On Thu, 16 May 2019 12:20:50 +0200 Roman Penyaev wrote:
> On 2019-05-16 12:03, Arnd Bergmann wrote:
> > On Thu, May 16, 2019 at 10:59 AM Roman Penyaev
> > wrote:
> >>
> >> epoll_create2() is needed to accept EPOLL_USERPOLL flags
> >> and size, i.e. this patch wires up polling from userspace.
On Sun, 19 May 2019 04:48:21 +0800 kbuild test robot wrote:
> Hi Marco,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v5.1 next-20190517]
> [if your patch is applied to the wrong git tree, please drop us a
s */
> > drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c:* OverView: Read "sepcific
> > bits" from BB register
> > drivers/net/wireless/realtek/rtlwifi/wifi.h:/* Ref: 802.11i sepc D10.0
> > 7.3.2.25.1
>
> Your agreement shouldn't be needed for the patch I s
On Mon, 20 May 2019 11:17:32 +0800 Yang Shi wrote:
> A few new fields were added to mmu_gather to make TLB flush smarter for
> huge page by telling what level of page table is changed.
>
> __tlb_reset_range() is used to reset all these page table state to
> unchanged, which is called by TLB
On Tue, 21 May 2019 09:25:51 + Eric Wong wrote:
> Deepa Dinamani wrote:
> > For all the syscalls that receive a sigmask from the userland,
> > the user sigmask is to be in effect through the syscall execution.
> > At the end of syscall, sigmask of the current process is restored
> > to what
On Fri, 17 May 2019 16:08:34 +0530 Anshuman Khandual
wrote:
> The presence of struct page does not guarantee linear mapping for the pfn
> physical range. Device private memory which is non-coherent is excluded
> from linear mapping during devm_memremap_pages() though they will still
> have
On Fri, 17 May 2019 19:15:07 +0200 Dmitry Vyukov wrote:
> From: Dmitry Vyukov
>
> in_softirq() is a wrong predicate to check if we are in a softirq context.
> It also returns true if we have BH disabled, so objects are falsely
> stamped with "softirq" comm. The correct predicate is
On Tue, 9 Jan 2018 02:10:50 -0800 Yu Zhao wrote:
> > Also what prevents reordering here? There do not seem to be any barriers
> > to prevent __SetPageSwapBacked leak after set_pte_at with your patch.
>
> I assumed mem_cgroup_commit_charge() acted as full barrier. Since you
> explicitly asked
An earlier version of this patch was accused of crashing the kernel:
https://lists.01.org/pipermail/lkp/2019-April/010004.html
does the v4 series address this?
On Mon, 29 Apr 2019 22:33:19 -0700 Timmy Li wrote:
> Hash functions are not needed since idr is used now.
> Let's remove hash header file for cleanup.
>
OK.
And the nice block comment at the start of kernel/pid.c is rather out
of date...
On Fri, 10 May 2019 10:49:34 -0700 Dan Schatzberg wrote:
> Pressure metrics are already recorded and exposed in procfs for the
> entire system, but any tool which monitors cgroup pressure has to
> special case the root cgroup to read from procfs. This patch exposes
> the already recorded
On Wed, 8 May 2019 13:16:09 -0700 Mike Kravetz wrote:
> > I think it is better to add fixes label, like:
> > Fixes: 58b6e5e8f1ad ("hugetlbfs: fix memory leak for resv_map")
> >
> > Since the commit 58b6e5e8f1a has been merged to stable, this patch also be
> > needed.
> >
On Mon, 6 May 2019 22:06:38 +0800 Zhiqiang Liu wrote:
> From: Kai Shen
>
> spinlock recursion happened when do LTP test:
> #!/bin/bash
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
>
> The dtor returned
On Thu, 25 Apr 2019 16:57:47 -0400 Joel Savitz wrote:
> Currently, there is no fast mechanism to get the virtual memory size of
> the current process from userspace. This information is available to the
> user through several means, one being a linear search of the entire address
> space. This
On Thu, 25 Apr 2019 00:40:53 +0100 Mel Gorman
wrote:
> On Wed, Apr 24, 2019 at 03:46:24PM -0700, Andrew Morton wrote:
> > On Wed, 24 Apr 2019 10:04:03 +0100 Mel Gorman
> > wrote:
> >
> > > On Tue, Apr 23, 2019 at 12:01:43PM -0700, Andrew Morton wrote:
> &
On Fri, 1 Feb 2019 21:39:59 +0100 Albert Vaca Cintora
wrote:
> Adds a readonly 'current_inotify_watches' entry to the user sysctl table.
> The handler for this entry is a custom function that ends up calling
> proc_dointvec. Said sysctl table already contains 'max_inotify_watches'
> and it
On Wed, 24 Apr 2019 10:04:03 +0100 Mel Gorman
wrote:
> On Tue, Apr 23, 2019 at 12:01:43PM -0700, Andrew Morton wrote:
> > On Tue, 23 Apr 2019 15:08:06 +0300 Andrey Ryabinin
> > wrote:
> >
> > > Commit 0a79cdad5eb2 ("mm: use alloc_flags to record if kswa
On Tue, 23 Apr 2019 15:08:06 +0300 Andrey Ryabinin
wrote:
> Commit 0a79cdad5eb2 ("mm: use alloc_flags to record if kswapd can wake")
> removed setting of the ALLOC_NOFRAGMENT flag. Bring it back.
What are the runtime effects of this fix?
On Mon, 22 Apr 2019 15:57:27 -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 Sun, 21 Apr 2019 18:02:35 +0100 Al Viro wrote:
> IOW, what sparse has caught here is a genuine endianness bug; images
> created on little-endian host and mounted on big-endian (or vice
> versa) will see csum mismatches when trying to fetch xattrs.
OK, thanks. I'll drop the patch - we
On Fri, 19 Apr 2019 23:03:43 +0300 Alexey Dobriyan wrote:
> Get "current_pt_regs" pointer right before usage.
>
> Space savings on x86_64:
>
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-180 (-180)
> Function old new delta
> load_elf_binary
On Wed, 17 Apr 2019 17:22:00 +0530 Bharath Vedartham
wrote:
> This patch fixes the sparse warning:
>
> fs/reiserfs//xattr.c:453:28: warning: incorrect type in return
> expression (different base types)
> fs/reiserfs//xattr.c:453:28:expected unsigned int
> fs/reiserfs//xattr.c:453:28:
On Wed, 17 Apr 2019 15:15:31 +0200 Matteo Croce wrote:
> In the sysctl code the proc_dointvec_minmax() function is often used to
> validate the user supplied value between an allowed range. This function
> uses the extra1 and extra2 members from struct ctl_table as minimum and
> maximum allowed
On Thu, 18 Apr 2019 04:18:34 -0700 Matthew Wilcox wrote:
> On Wed, Apr 17, 2019 at 02:58:27PM -0700, Andrew Morton wrote:
> > On Wed, 17 Apr 2019 12:40:01 -0700 Roman Gushchin wrote:
> > > +static struct vm_struct *__remove_vm_area(struct vmap_area *va)
> > > +{
&
> for (i = 0; i < ARRAY_SIZE(test_case_array); i++)
> random_array[i] = i;
lgtm.
While we're in there...
From: Andrew Morton
Subject: lib/test_vmalloc.c:test_func(): eliminate local `ret'
Local 'ret' is unneeded and was poorly named: the variable `ret' generally
me
tails on how this works, particularly GCOVProfiler::emitProfileArcs(),
> GCOVProfiler::insertCounterWriteout(), and GCOVProfiler::insertFlush().
checkpatch speaketh truth.
Also, I'll change those Co-authored-by's to the documented Co-developed-by.
From: Andrew Morton
Subject: gcov-clang-support-checkpatch-fixes
On Wed, 17 Apr 2019 12:40:01 -0700 Roman Gushchin wrote:
> __vunmap() calls find_vm_area() twice without an obvious reason:
> first directly to get the area pointer, second indirectly by calling
> remove_vm_area(), which is again searching for the area.
>
> To remove this redundancy, let's
On Wed, 10 Apr 2019 23:37:18 +0800 Feng Tang wrote:
> Currently on panic, kernel will lower the loglevel and print out
> new printk msg only with console_flush_on_panic().
>
> Add an option for users to configure the "panic_print" to see
> all dmesg in buffer, some of which they may have never
On Wed, 10 Apr 2019 10:07:24 +0200 David Hildenbrand wrote:
> Care to fixup both u64 to resource_size_t? Or should I send a patch?
> Whatever you prefer.
Please send along a fixup.
This patch series has no evidence of having been reviewed :(. Can you
suggest who could help us out here?
On Tue, 16 Apr 2019 17:39:03 -0700 Guenter Roeck wrote:
> > > Has it been confirmed that this fixes
> > > mm-shuffle-initial-free-memory-to-improve-memory-side-cache-utilization.patch
> > > on beaglebone-black?
> >
> > This only fixes dynamically enabling the shuffling on 32-bit ARM.
> > Guenter
On Wed, 17 Apr 2019 02:59:43 +0200 Matteo Croce wrote:
> In the sysctl code the proc_dointvec_minmax() function is often used to
> validate the user supplied value between an allowed range. This function
> uses the extra1 and extra2 members from struct ctl_table as minimum and
> maximum allowed
801 - 900 of 25531 matches
Mail list logo
