On 2/21/19 5:36 PM, Greg Kroah-Hartman wrote:
> 4.19-stable review patch. If anyone has any objections, please let me know.
>
Drop it please. It increases kernel stack up to 4-order which is above
PAGE_ALLOC_COSTLY_ORDER.
This changes behavior of the fork() by making it fail with -ENOMEM due of
On 2/20/19 8:35 PM, Arnd Bergmann wrote:
> On Wed, Feb 20, 2019 at 6:00 PM Andrey Ryabinin
> wrote:
>> On 2/20/19 5:51 PM, Arnd Bergmann wrote:
>>> On Wed, Feb 20, 2019 at 3:45 PM Andrey Konovalov
>>> wrote:
>>> I would have to some more research, b
On 2/20/19 5:51 PM, Arnd Bergmann wrote:
> On Wed, Feb 20, 2019 at 3:45 PM Andrey Konovalov
> wrote:
>>
>> On Tue, Feb 19, 2019 at 10:49 PM Arnd Bergmann wrote:
>>>
>>> Building an arm64 allmodconfig kernel with clang results in over 140
>>> warnings
>>> about overly large stack frames, the
On 2/15/19 1:10 PM, Christophe Leroy wrote:
>
>
> Le 15/02/2019 à 11:01, Andrey Ryabinin a écrit :
>>
>>
>> On 2/15/19 11:41 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 14/02/2019 à 23:04, Daniel Axtens a écrit :
>>>>
On 2/15/19 11:41 AM, Christophe Leroy wrote:
>
>
> Le 14/02/2019 à 23:04, Daniel Axtens a écrit :
>> Hi Christophe,
>>
>>> --- a/arch/powerpc/include/asm/string.h
>>> +++ b/arch/powerpc/include/asm/string.h
>>> @@ -27,6 +27,20 @@ extern int memcmp(const void *,const void
>>> *,__kernel_size_t
On 2/12/19 2:38 PM, Christophe Leroy wrote:
>
>
> Le 12/02/2019 à 02:08, Daniel Axtens a écrit :
>> Andrey Ryabinin writes:
>>
>>>
>>> Christophe, you can specify KASAN_SHADOW_OFFSET either in Kconfig (e.g.
>>> x86_64) or
>>> in Makefi
On 2/12/19 4:08 AM, Daniel Axtens wrote:
> Andrey Ryabinin writes:
>
>> On 2/11/19 3:25 PM, Andrey Konovalov wrote:
>>> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
>>> wrote:
>>>>
>>>> Hi Andrey,
>>>>
>>>> Le
On 2/11/19 3:25 PM, Andrey Konovalov wrote:
> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
> wrote:
>>
>> Hi Andrey,
>>
>> Le 08/02/2019 à 18:40, Andrey Konovalov a écrit :
>>> On Fri, Feb 8, 2019 at 6:17 PM Christophe Leroy
>>> wrote:
Hi Daniel,
Le 08/02/2019 à 17:18,
On 1/30/19 4:36 AM, Andrew Morton wrote:
> 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 mes
check_memory_region+0x22d/0x250
> memset+0x28/0x40
> kernel_poison_pages+0x29e/0x3d5
> __free_pages_ok+0x75f/0x13e0
>
> due to KASAN adds poisoned redzones around slab objects, but the page
> poisoning needs to poison the whole page.
>
> Signed-off-by: Qian Cai
> ---
>
Acked-by: Andrey Ryabinin
On 1/12/19 2:16 PM, Christophe Leroy wrote:
> +KASAN_SANITIZE_early_32.o := n
> +KASAN_SANITIZE_cputable.o := n
> +KASAN_SANITIZE_prom_init.o := n
> +
Usually it's also good idea to disable branch profiling - define
DISABLE_BRANCH_PROFILING
either in top of these files or via Makefile. Branch
On 1/15/19 2:14 PM, Dmitry Vyukov wrote:
> On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy
> wrote:
>> On 01/14/2019 09:34 AM, Dmitry Vyukov wrote:
>>> On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy
>>> wrote:
>>> >
>>> > In kernel/cputable.c, explicitly use memcpy() in order
>>> > to allo
On 1/14/19 4:24 PM, Dmitry Vyukov wrote:
> On Fri, Jan 11, 2019 at 7:58 PM Andrey Ryabinin
> wrote:
>>
>> Use after scope bugs detector seems to be almost entirely useless
>> for the linux kernel. It exists over two years, but I've seen only
>> one valid bu
On 1/3/19 5:59 PM, Roman Penyaev wrote:
> __vmalloc_area_node() calls vfree() on error path, which in turn calls
> kmemleak_free(), but area is not yet accounted by kmemleak_vmalloc().
>
> Signed-off-by: Roman Penyaev
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Andre
range() call instead of finding the area
> (which obviously takes time) after the allocation.
>
> Signed-off-by: Roman Penyaev
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Andrey Ryabinin
> Cc: Joe Perches
> Cc: "Luis R. Rodriguez"
> Cc: linux...@kvack.org
>
ng vmalloc_to_page()
> returns NULL on last guard (non-existing) page.
>
> Signed-off-by: Roman Penyaev
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Andrey Ryabinin
> Cc: Joe Perches
> Cc: "Luis R. Rodriguez"
> Cc: linux...@kvack.org
> Cc: linux-kernel
l that turns
> everything into '=m' or '=y' will turn off UBSAN_ALIGNMENT.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Anders Roxell
> ---
Acked-by: Andrey Ryabinin
> lib/Kconfig.ubsan | 14 +-
> 1 file changed, 9 insertions(+), 5 de
ile preparing this patch I've noticed that we mistakenly enable
use-after-scope detection for clang compiler regardless of
CONFIG_KASAN_EXTRA setting. This is also fixed now.
[1]
http://lkml.kernel.org/r/<20171129052106.rhgbjhhis53hk...@wfg-t540p.sh.intel.com>
Signed-off-by: Andrey Ry
On 1/10/19 12:52 AM, 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 size compiled u
unction.
>
> Fixes: b1864b828644 ("locking/atomics: build atomic headers as required")
> Reported-by: Anders Roxell
> Signed-off-by: Arnd Bergmann
> ---
Acked-by: Andrey Ryabinin
On 1/8/19 1:36 AM, Qian Cai wrote:
>
> diff --git a/mm/page_poison.c b/mm/page_poison.c
> index f0c15e9017c0..e546b70e592a 100644
> --- a/mm/page_poison.c
> +++ b/mm/page_poison.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
>
> static bool want_page_poisoning __re
store shadow entries in page cache")
>> To: Andrew Morton
>> Cc: Johannes Weiner
>> Cc: Mel Gorman
>> Cc: Jan Kara
>> Cc: Matthew Wilcox
>> Cc: Andi Kleen
>> Cc: linux...@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Review
noreturn attribute.
[aryabinin: Add information about GCC bug in changelog]
Signed-off-by: Arnd Bergmann
Signed-off-by: Andrey Ryabinin
---
lib/ubsan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/ubsan.c b/lib/ubsan.c
index 59fee96c29a0..e4162f59a81c 10
On 11/03/2018 12:27 AM, Olof Johansson wrote:
> On Mon, Feb 5, 2018 at 2:31 AM Andrey Ryabinin
> wrote:
>>
>> On 02/05/2018 01:15 PM, Arnd Bergmann wrote:
>>> On Mon, Feb 5, 2018 at 10:02 AM, Andrey Ryabinin
>>> wrote:
>>>>
>>>>
&
On 10/29/2018 01:29 PM, Will Deacon wrote:
> On Thu, Sep 20, 2018 at 04:56:30PM +0300, Andrey Ryabinin wrote:
>> ARM64 has asm implementation of memchr(), memcmp(), str[r]chr(),
>> str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm
>> code, thus it can
On 09/21/2018 04:25 PM, Souptick Joarder wrote:
> On Fri, Sep 21, 2018 at 5:22 PM Andrey Ryabinin
> wrote:
>> On 09/21/2018 01:03 PM, Souptick Joarder wrote:
>>> On Fri, Sep 21, 2018 at 3:06 PM Andrey Ryabinin
>>> wrote:
>>>>
>>&
On 09/21/2018 01:03 PM, Souptick Joarder wrote:
> On Fri, Sep 21, 2018 at 3:06 PM Andrey Ryabinin
> wrote:
>>
>> On 09/20/2018 10:12 PM, Souptick Joarder wrote:
>>> There is a plan to replace vm_insert_page with new API
>>> vmf_insert_page. As part of it,
On 09/20/2018 10:12 PM, Souptick Joarder wrote:
> There is a plan to replace vm_insert_page with new API
> vmf_insert_page. As part of it, converting vm_insert_page
> to use vmf_insert_page.
>
> Signed-off-by: Souptick Joarder
> ---
> kernel/kcov.c | 5 +++--
> 1 file changed, 3 insertions(+), 2
On 09/21/2018 04:50 AM, Andy Lutomirski wrote:
> This patch seems reasonable, but you emailed the wrong people :)
>
> On Thu, Sep 20, 2018 at 5:15 PM Jason A. Donenfeld wrote:
>>
>> It turns out that KASAN in general will bloat stack frames in unexpected
>> ways, not just KASAN_EXTRA. So, this
Hi,
Kirill noticed that the following piece of code from md_alloc(dev, name)
is dead:
if (name && dev)
/*
* Creating /dev/mdNNN via "newarray", so adjust hold_active.
*/
mddev->hold_active = UNTIL_STOP;
md_alloc() is always
Since WEAK() supposed to be used instead of ENTRY() to define weak
symbols, but unlike ENTRY() it doesn't have ALIGN directive.
It seems there is no actual reason to not have, so let's add
ALIGN to WEAK() too.
Signed-off-by: Andrey Ryabinin
---
include/linux/linkage.h | 1 +
1 file
m lib/string.c will be used.
We can't just remove the asm functions because efistub uses them.
And we can't have two non-weak functions either, so declare the asm
functions as weak.
Reported-by: Kyeongdon Kim
Signed-off-by: Andrey Ryabinin
---
Changes since v1:
- Use WEAK() instead of .we
tests for these functions to be sure
that we notice the problem on other architectures.
Signed-off-by: Andrey Ryabinin
---
No changes since v1.
lib/test_kasan.c | 70
1 file changed, 70 insertions(+)
diff --git a/lib/test_kas
ply always kmalloc:
if ((flags & GFP_KERNEL) != GFP_KERNEL)
return kmalloc_node(size, flags, node);
So in the above case, kvfree() always frees kmalloced memory -> and never calls
vfree().
Signed-off-by: Andrey Ryabinin
---
mm/util.c | 2 --
1 file changed, 2
vfree() might sleep if called not in interrupt context. Explain
that in the comment.
Signed-off-by: Andrey Ryabinin
---
mm/vmalloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index a728fc492557..d00d42d6bf79 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
vfree() might sleep if called not in interrupt context.
So does kvfree() too. Fix misleading kvfree()'s comment about
allowed context.
Fixes: 04b8e946075d ("mm/util.c: improve kvfree() kerneldoc")
Signed-off-by: Andrey Ryabinin
---
mm/util.c | 2 +-
1 file changed, 1 insertion
Add might_sleep() calls to vfree(), kvfree() to catch potential
sleep-in-atomic bugs earlier.
Signed-off-by: Andrey Ryabinin
---
mm/util.c| 2 ++
mm/vmalloc.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/mm/util.c b/mm/util.c
index 7f1f165f46af..929ed1795bc1 100644
--- a/mm/util.c
On 09/10/2018 04:06 PM, Will Deacon wrote:
> On Mon, Sep 10, 2018 at 01:53:03PM +0100, Mark Rutland wrote:
>> On Mon, Sep 10, 2018 at 12:33:22PM +0100, Mark Rutland wrote:
>>> On Fri, Sep 07, 2018 at 06:48:10PM +0300, Andrey Ryabinin wrote:
>>>> On 09/07/20
On 09/07/2018 05:56 PM, Will Deacon wrote:
> On Thu, Sep 06, 2018 at 08:05:33PM +0300, Andrey Ryabinin wrote:
>> ARM64 has asm implementations of memchr(), memcmp(), str[r]chr(),
>> str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm
>> code, thus it can
On 09/05/2018 10:44 AM, Kyeongdon Kim wrote:
>
>
> On 2018-09-05 오전 1:24, Andrey Ryabinin wrote:
>>
>>
>> On 09/04/2018 01:10 PM, Andrey Ryabinin wrote:
>> >
>> >
>> > On 09/04/2018 09:59 AM, Kyeongdon Kim wrote:
>> >
>> >
m lib/string.c will be used.
Declare asm functions as weak instead of removing them because they
still can be used by efistub.
Reported-by: Kyeongdon Kim
Signed-off-by: Andrey Ryabinin
---
arch/arm64/include/asm/string.h | 14 --
arch/arm64/kernel/arm64ksyms.c | 7 +--
arch/arm6
tests for these functions to be sure
that we notice the problem on other architectures.
Signed-off-by: Andrey Ryabinin
---
lib/test_kasan.c | 70
1 file changed, 70 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index ec
On 09/04/2018 01:10 PM, Andrey Ryabinin wrote:
>
>
> On 09/04/2018 09:59 AM, Kyeongdon Kim wrote:
>
>>>> +#undef strncmp
>>>> +int strncmp(const char *cs, const char *ct, size_t len)
>>>> +{
>>>> + check_memory_region((unsigne
On 09/04/2018 09:59 AM, Kyeongdon Kim wrote:
>> > +#undef strncmp
>> > +int strncmp(const char *cs, const char *ct, size_t len)
>> > +{
>> > + check_memory_region((unsigned long)cs, len, false, _RET_IP_);
>> > + check_memory_region((unsigned long)ct, len, false, _RET_IP_);
>>
>> This will cause
On 08/23/2018 11:56 AM, Kyeongdon Kim wrote:
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index c3bd520..61ad7f1 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -304,6 +304,29 @@ void *memcpy(void *dest, const void *src, size_t len)
>
> return __memcpy(dest, src, l
g, rewind the stack before
> do_exit()")
> Signed-off-by: Jann Horn
> ---
Acked-by: Andrey Ryabinin
On 08/28/2018 01:38 PM, Jann Horn wrote:
>>
>>
>> Why this has to be done in the rewind_stack_do_exit()?
>> Are there any problems with calling the kasan_unpoison_task_stack(current)
>> from oops_end(), before the rewind_stack_do_exit()?
>
> Ooh, good point! I didn't see that KASAN instrument
On 08/25/2018 02:58 AM, Jann Horn wrote:
> Reset the KASAN shadow state of the task stack when rewinding RSP.
> Without this, a kernel oops will leave parts of the stack poisoned, and
> code running under do_exit() can trip over such poisoned regions and cause
> nonsensical false-positive KASAN rep
On 08/14/2018 10:55 AM, Kyeongdon Kim wrote:
> Assembly optimized string functions cannot detect KASan bug.
> This might have been the intention of the original author.
> (not too much important to catch)
>
> But, I found the obvious uaf problem in strcmp() function.
> - in this case, using 32
d something at NULL (root can do this),
with things like SMAP should catch the issue.
Signed-off-by: Andrey Ryabinin
---
arch/parisc/Kconfig| 1 -
arch/s390/Kconfig | 1 -
lib/Kconfig.ubsan | 11 ---
scripts/Makefile.ubsan | 4
4 files changed, 17 deletions(-)
di
The 'bufs' array contains 'pipe->buffers' elements, but the
fuse_dev_splice_write() uses only 'pipe->nrbufs' elements.
So reduce the allocation size to 'pipe->nrbufs' elements.
Signed-off-by: Andrey Ryabinin
---
fs/fuse/dev.c | 2 +-
1 file cha
x27;bufs' array.
Move the bufs allocations inside pipe_lock()/pipe_unlock() to fix this.
Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device")
Signed-off-by: Andrey Ryabinin
Cc:
---
fs/fuse/dev.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs
't need to be physically contiguous, use
the kvmalloc_array() to allocate memory. If high order
page isn't available, the kvamalloc*() will fallback to 0-order.
Signed-off-by: Andrey Ryabinin
---
fs/fuse/dev.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/
On 07/17/2018 05:47 PM, Miklos Szeredi wrote:
> On Mon, Jul 16, 2018 at 6:03 PM, Andrey Ryabinin
> wrote:
>> The 'bufs' array contains 'pipe->buffers' elements, but the
>> fuse_dev_splice_write() uses only 'pipe->nrbufs' elements.
>
>
The 'bufs' array contains 'pipe->buffers' elements, but the
fuse_dev_splice_write() uses only 'pipe->nrbufs' elements.
So reduce the allocation size to 'pipe->nrbufs' elements.
Signed-off-by: Andrey Ryabinin
---
fs/fuse/dev.c | 2 +-
1 file cha
't need to be physically contiguous, use
the kvmalloc_array() to allocate memory. If high order
page isn't available, the kvamalloc*() will fallback to 0-order.
Signed-off-by: Andrey Ryabinin
---
fs/fuse/dev.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/
On 06/30/2018 05:33 AM, Andrew Morton wrote:
> On Fri, 29 Jun 2018 19:49:32 +0300 Andrey Ryabinin
> wrote:
>
>> KASAN learns about hot added memory via the memory hotplug notifier.
>> The devm_memremap_pages() intentionally skips calling memory hotplug
>> notifier
represented in type 'long long int'
Use unsigned types to do math. Unsigned overflow is defined so UBSAN
will not complain about it. This patch doesn't change generated code.
Reported-by:
Signed-off-by: Andrey Ryabinin
---
mm/fadvise.c | 2 +-
1 file changed, 1 insertion
evice memory.
Reported-by: Dave Chinner
Signed-off-by: Andrey Ryabinin
Cc: Dan Williams
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
---
Changes since v1:
- Compilation fixes.
include/linux/kasan.h | 13 ++-
kernel/memremap.c | 10 ++
mm/kasan/kasan_init.c
Commit-ID: 0e311d237d7f3022b7dafb639b42541bfb42fe94
Gitweb: https://git.kernel.org/tip/0e311d237d7f3022b7dafb639b42541bfb42fe94
Author: Andrey Ryabinin
AuthorDate: Mon, 25 Jun 2018 13:24:27 +0300
Committer: Ingo Molnar
CommitDate: Tue, 26 Jun 2018 09:21:48 +0200
x86/mm: Don't fre
evice memory.
Reported-by: Dave Chinner
Signed-off-by: Andrey Ryabinin
Cc: Dan Williams
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
---
include/linux/kasan.h | 13 ++-
kernel/memremap.c | 10 ++
mm/kasan/kasan_init.c | 316 +++---
3 files ch
gt; ...
> memset(ptr, 0, mod->core_layout.size);//crashed
>
> Unable to handle kernel paging request at virtual address 0f97b000
> ..
> Call trace:
> [] __asan_storeN+0x174/0x1a8
> [] memset+0x24/0x48
> [] layout_and_allocate+0xcd8/0x1800
>
86/mm: Fold p4d page table layer at runtime")
Signed-off-by: Andrey Ryabinin
---
arch/x86/include/asm/pgalloc.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h
index ada6410fd2ec..fbd578daa66e 100644
--- a/arch/x86/include
On 06/20/2018 12:33 AM, Shakeel Butt wrote:
> For !CONFIG_SLUB_DEBUG, SLUB does not maintain the number of slabs
> allocated per node for a kmem_cache. Thus, slabs_node() in
> __kmem_cache_empty() will always return 0. So, in such situation, it is
> required to check per-cpu slabs to make sure i
On 06/19/2018 05:51 AM, Jason A. Donenfeld wrote:
> Hello Shakeel,
>
> It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
> introduced a regression. I've bisected a failing test to this commit,
> and after staring at the my code for a long time, I'm unable to find a
> bug that
On 05/23/2018 12:03 AM, Andrew Morton wrote:
> On Tue, 22 May 2018 19:44:06 +0300 Andrey Ryabinin
> wrote:
>
>>> Obviously we can't call vfree() to free memory that wasn't allocated via
>>> vmalloc(). Use find_vm_area() to see if we can call vfree().
>&
On 05/23/2018 12:07 AM, Andrew Morton wrote:
> On Tue, 22 May 2018 22:50:12 +0300 Andrey Ryabinin
> wrote:
>
>>
>>
>> On 05/22/2018 07:36 PM, David Hildenbrand wrote:
>>> On 22.05.2018 18:26, Andrey Ryabinin wrote:
>>>>
>>>>
>&
On 05/22/2018 07:36 PM, David Hildenbrand wrote:
> On 22.05.2018 18:26, Andrey Ryabinin wrote:
>>
>>
>> On 05/22/2018 01:07 PM, David Hildenbrand wrote:
>>> Using module_init() is wrong. E.g. ACPI adds and onlines memory before
>>> our memory notifier g
On 02/01/2018 07:33 PM, Andrey Ryabinin wrote:
> KASAN uses different routines to map shadow for hot added memory and memory
> obtained in boot process. Attempt to offline memory onlined by normal boot
> process leads to this:
>
> Trying to vfree() nonexistent vm area (0
On 05/22/2018 01:07 PM, David Hildenbrand wrote:
> We have to free memory again when we cancel onlining, otherwise a later
> onlining attempt will fail.
>
> Signed-off-by: David Hildenbrand
> ---
Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
Acke
eproducable with QEMU, just specify a DIMM when starting up.
reproducible
>
> Signed-off-by: David Hildenbrand
> ---
Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
Acked-by: Andrey Ryabinin
Cc:
> mm/kasan/kasan.c | 2 +-
> 1 file changed, 1
spent in the instrumentation.
>
> (A similar change has been previously committed for memcmp())
>
> Signed-off-by: Alexander Potapenko
> Cc: Andrey Ryabinin
> Cc: Dmitry Vyukov
> ---
> lib/stackdepot.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> dif
On 05/04/2018 05:38 PM, Mark Rutland wrote:
> On Fri, May 04, 2018 at 05:36:49PM +0300, Andrey Ryabinin wrote:
>>
>>
>> On 05/04/2018 04:55 PM, Mark Rutland wrote:
>>
>>>
>>> +static void kcov_fault_in_area(struct kcov *kcov)
>>> +{
>
On 05/04/2018 04:55 PM, Mark Rutland wrote:
>
> +static void kcov_fault_in_area(struct kcov *kcov)
> +{
> + unsigned long stride = PAGE_SIZE / sizeof(unsigned long);
> + unsigned long *area = kcov->area;
> + unsigned long offset;
> +
> + for (offset = 0; offset < kcov->size; of
On 05/04/2018 04:55 PM, Mark Rutland wrote:
> +#define kcov_prepare_switch(t) \
> +do { \
> + (t)->kcov_mode |= KCOV_IN_CTXSW;\
> +} while (0)
> +
> +#define kcov_finish_switch(t)\
> +do {
On 04/20/2018 07:45 PM, Yury Norov wrote:
> On Fri, Apr 20, 2018 at 05:08:23PM +0300, Andrey Ryabinin wrote:
>>
>>
>> On 04/19/2018 06:01 AM, Fengguang Wu wrote:
>>> Hello,
>>>
>>> FYI this happens in mainline kernel 4.17.0-rc1.
>>&g
On 04/19/2018 06:01 AM, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in mainline kernel 4.17.0-rc1.
> It at least dates back to v4.8 .
>
> [ 25.697463]
> [ 25.697463] Start testing find_bit() with random-filled bitmap
> [ 25.736615] find_next_bit:30203201 ns, 163965 i
On 04/19/2018 04:35 PM, Andrey Ryabinin wrote:
>
>
> On 04/18/2018 09:37 PM, Linus Torvalds wrote:
>> Ugh, that lustre code is disgusting.
>>
>> I thought we were getting rid of it.
>>
>> Anyway, I started looking at why the stack trace is such an incredi
On 04/18/2018 09:37 PM, Linus Torvalds wrote:
> Ugh, that lustre code is disgusting.
>
> I thought we were getting rid of it.
>
> Anyway, I started looking at why the stack trace is such an incredible
> mess, with lots of stale entries.
>
> The reason (well, _one_ reason) seems to be "ksocknal
On 04/13/2018 08:34 PM, Andrey Konovalov wrote:
> On Fri, Apr 13, 2018 at 5:31 PM, Andrey Ryabinin
> wrote:
>>
>>
>> On 04/12/2018 08:29 PM, Andrey Konovalov wrote:
>>> KASAN uses the __no_sanitize_address macro to disable instrumentation
>>> of particu
On 04/12/2018 08:29 PM, Andrey Konovalov wrote:
> KASAN uses the __no_sanitize_address macro to disable instrumentation
> of particular functions. Right now it's defined only for GCC build,
> which causes false positives when clang is used.
>
> This patch adds a definition for clang.
>
> Note,
user0m0.487s
sys 1m8.505s
According to the tracepoint in wait_iff_congested(), the 'cat' spent 50%
of the time sleeping there.
With the patch, cat don't waste time anymore:
# time cat /dev/sda > /dev/null
real 5m32.911s
user0m0.411s
sys
group reclaim
may alter global pgdat flags too, which is wrong. But that is separate
issue and will be addressed in the next patch.
This change will not have any effect on a systems with all workload
concentrated in a single cgroup.
Signed-off-by: Andrey Ryabinin
Reviewed-by: Shakeel Butt
Cc
On 04/06/2018 07:28 PM, Johannes Weiner wrote:
>
> This isn't quite equivalent to what we have right now.
>
> Yes, nr_dirty, nr_unqueued_dirty and nr_congested apply to file pages
> only. That part is about waking the flushers and avoiding writing
> files in 4k chunks from reclaim context. So t
On 04/06/2018 05:37 PM, Shakeel Butt wrote:
>>
>> @@ -2482,7 +2494,7 @@ static inline bool should_continue_reclaim(struct
>> pglist_data *pgdat,
>> static bool pgdat_memcg_congested(pg_data_t *pgdat, struct mem_cgroup
>> *memcg)
>> {
>> return test_bit(PGDAT_CONGESTED, &pgdat->flags)
laim from node B.
Make congestion state per-cgroup-per-node and record it in
'struct mem_cgroup_per_node'.
Signed-off-by: Andrey Ryabinin
---
include/linux/memcontrol.h | 5 +++--
mm/vmscan.c| 39 +--
2 files changed, 28 insertions
On 04/06/2018 05:13 AM, Shakeel Butt wrote:
> On Fri, Mar 23, 2018 at 8:20 AM, Andrey Ryabinin
> wrote:
>> memcg reclaim may alter pgdat->flags based on the state of LRU lists
>> in cgroup and its children. PGDAT_WRITEBACK may force kswapd to sleep
>> congested_wa
ed-by: syzbot+8a5de3cce7cdc70e9...@syzkaller.appspotmail.com
> Fixes: 00f3ca2c2d66 ("mm: memcontrol: per-lruvec stats infrastructure")
> Signed-off-by: Michal Hocko
Reviewed-by: Andrey Ryabinin
> ---
> mm/memcontrol.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>
v
> Fixes: f5a40711fa58 ("x86/mm: Set MODULES_END to 0xff00")
> Cc: Andrey Ryabinin
> ---
Acked-by: Andrey Ryabinin
> Documentation/x86/x86_64/mm.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/x86/x86_64/
process_one_work
> worker_thread
> kthread
> ret_from_fork
>
> This patch is based on the observation that if the kmem_cache to be
> destroyed is empty then there should not be any objects of this cache in
> the quarantine.
>
> Without the patch the sc
Update some comments that become stale since transiton from per-zone
to per-node reclaim.
Signed-off-by: Andrey Ryabinin
Acked-by: Michal Hocko
---
mm/vmscan.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4390a8d5be41
group reclaim
may alter global pgdat flags too, which is wrong. But that is separate
issue and will be addressed in the next patch.
This change will not have any effect on a systems with all workload
concentrated in a single cgroup.
Signed-off-by: Andrey Ryabinin
---
mm/vmscan.c
rguments is also not very good. Yes,
these numbers could
be obtained from mm_vmscan_lru_isolate tracepoint, but it's easier when
it's all in one place.
- Compare with nr_writeback,dirty, etc only isolated file pages as it always
was.
- Minor changelog tweaks.
Andrey Ryabinin (4):
Only kswapd can have non-zero nr_immediate, and current_may_throttle() is
always true for kswapd (PF_LESS_THROTTLE bit is never set) thus it's
enough to check stat.nr_immediate only.
Signed-off-by: Andrey Ryabinin
Acked-by: Michal Hocko
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(
real10m15.054s
user0m0.487s
sys 1m8.505s
According to the tracepoint in wait_iff_congested(), the 'cat' spent 50%
of the time sleeping there.
With the patch, cat don't waste time anymore:
# time cat /dev/sda > /dev/null
real5m32.911s
us
On 03/23/2018 12:10 AM, Andrew Morton wrote:
> On Thu, 22 Mar 2018 12:10:03 -0400 Steven Rostedt wrote:
>
>>
>> The trace event trace_mm_vmscan_lru_shrink_inactive() currently has 12
>> parameters! Seven of them are from the reclaim_stat structure. This
>> structure is currently local to mm/vms
On 03/21/2018 02:43 PM, Michal Hocko wrote:
> On Wed 21-03-18 14:14:35, Andrey Ryabinin wrote:
>>
>>
>> On 03/20/2018 06:29 PM, Michal Hocko wrote:
>>
>>>> Leave all pgdat->flags manipulations to kswapd. kswapd scans the whole
>>>> pgdat, so
On 03/21/2018 02:32 PM, Michal Hocko wrote:
> On Wed 21-03-18 13:40:32, Andrey Ryabinin wrote:
>> On 03/20/2018 06:25 PM, Michal Hocko wrote:
>>> On Thu 15-03-18 19:45:52, Andrey Ryabinin wrote:
>>>> We have separate LRU list for each memory cgroup. Memory reclaim
ng to the tracepoint in wait_iff_congested(), the 'cat' spent 50%
>> of the time sleeping there.
>>
>> With the patch, cat don't waste time anymore:
>>
>> # time cat /dev/sda > /dev/null
>> real5m32.911s
>> user0m0.41
On 03/20/2018 06:25 PM, Michal Hocko wrote:
> On Thu 15-03-18 19:45:52, Andrey Ryabinin wrote:
>> We have separate LRU list for each memory cgroup. Memory reclaim iterates
>> over cgroups and calls shrink_inactive_list() every inactive LRU list.
>> Based on the
101 - 200 of 1010 matches
Mail list logo
