checks.
Signed-off-by: Andrey Ryabinin
---
- This was noticed by code review. It seems like a bug to me,
but if I'm wrong and current behavior is correct, I think we need
at least better comment here.
security/keys/keyctl.c | 15 +--
1 file changed, 1 insertion(+), 14
iommu/amd: Fix race in increase_address_space()")
Signed-off-by: Andrey Ryabinin
Acked-by: Will Deacon
Link: https://lore.kernel.org/r/20210217143004.19165-1-a...@yandex-team.com
Signed-off-by: Joerg Roedel
Signed-off-by: Andrey Ryabinin
---
drivers/iommu/amd/iommu.c | 10 ++
1 file
iommu/amd: Fix race in increase_address_space()")
Signed-off-by: Andrey Ryabinin
Acked-by: Will Deacon
Link: https://lore.kernel.org/r/20210217143004.19165-1-a...@yandex-team.com
Signed-off-by: Joerg Roedel
Signed-off-by: Andrey Ryabinin
---
drivers/iommu/amd_iommu.c | 10 ++
1 file
iommu/amd: Fix race in increase_address_space()")
Signed-off-by: Andrey Ryabinin
Acked-by: Will Deacon
Link: https://lore.kernel.org/r/20210217143004.19165-1-a...@yandex-team.com
Signed-off-by: Joerg Roedel
Signed-off-by: Andrey Ryabinin
---
drivers/iommu/amd_iommu.c | 10 ++
1 file
iommu/amd: Fix race in increase_address_space()")
Signed-off-by: Andrey Ryabinin
Acked-by: Will Deacon
Link: https://lore.kernel.org/r/20210217143004.19165-1-a...@yandex-team.com
Signed-off-by: Joerg Roedel
Signed-off-by: Andrey Ryabinin
---
drivers/iommu/amd_iommu.c | 10 ++
1 file
On 3/4/21 3:19 PM, Joerg Roedel wrote:
> On Wed, Feb 17, 2021 at 06:10:02PM +, Will Deacon wrote:
>>> drivers/iommu/amd/iommu.c | 10 ++
>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> Acked-by: Will Deacon
>
> Applied for v5.12, thanks.
>
> There were some conflicts
Signed-off-by: Andrey Ryabinin
Cc:
---
drivers/iommu/amd/iommu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index f0adbc48fd17..9256f84f5ebf 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
cpuacct.stat shows user time based on raw random precision tick
based counters. Use cputime_addjust() to scale these values against the
total runtime accounted by the scheduler, like we already do
for user/system times in /proc//stat.
Signed-off-by: Andrey Ryabinin
---
kernel/sched/cpuacct.c
stime statistics")
Signed-off-by: Andrey Ryabinin
Cc:
---
kernel/sched/cputime.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 5f611658eeab..95a9c5603d29 100644
--- a/kernel/sched/cputime.c
+++ b/ke
Global CPUTIME_USER counter already includes CPUTIME_GUEST
Also CPUTIME_NICE already includes CPUTIME_GUEST_NICE.
Remove additions of CPUTIME_GUEST[_NICE] to total ->sum_exec_runtime
to not account them twice.
Fixes: 936f2a70f207 ("cgroup: add cpu.stat file to root cgroup")
Signed-o
in cpuacct_account_field() as the source
of user/sys times for cpuacct.usage* files. Make cpuacct_charge()
to account only summary execution time.
Fixes: d740037fac70 ("sched/cpuacct: Split usage accounting into user_usage and
sys_usage")
Signed-off-by: Andrey Ryabinin
Cc:
---
kernel/sched/cpua
mit
cdf8a76fda4a ("ubsan: move cc-option tests into Kconfig"),
but it never worked (kernel doesn't boot). And unsigned overflows
are allowed by C standard, so it just pointless.
Signed-off-by: Andrey Ryabinin
Cc: Peter Zijlstra
Cc: Josh Poimboeuf
Cc: Randy Dunlap
Cc: Stephen Rothwel
Update my email, @virtuozzo.com will stop working shortly.
Signed-off-by: Andrey Ryabinin
---
.mailmap| 1 +
MAINTAINERS | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index 632700cee55c..b325d3c79725 100644
--- a/.mailmap
+++ b/.mailmap
@@ -40,6
On 1/14/21 1:59 PM, Peter Zijlstra wrote:
> On Mon, Jan 04, 2021 at 04:13:17PM +0100, Peter Zijlstra wrote:
>> On Tue, Dec 22, 2020 at 11:04:54PM -0600, Josh Poimboeuf wrote:
>>> GCC 7 has a known bug where UBSAN ignores '-fwrapv' and generates false
>>> signed-overflow-UB warnings. The type
On 10/16/19 4:22 PM, Mark Rutland wrote:
> Hi Andrey,
>
> On Wed, Oct 16, 2019 at 03:19:50PM +0300, Andrey Ryabinin wrote:
>> On 10/14/19 4:57 PM, Daniel Axtens wrote:
>>>>> + /*
>>>>> + * Ensure poisoning is visible before the sh
On 10/14/19 4:57 PM, Daniel Axtens wrote:
> Hi Andrey,
>
>
>>> + /*
>>> +* Ensure poisoning is visible before the shadow is made visible
>>> +* to other CPUs.
>>> +*/
>>> + smp_wmb();
>>
>> I'm not quite understand what this barrier do and why it needed.
>> And if it's really
On 10/1/19 9:58 AM, Daniel Axtens wrote:
> core_initcall(kasan_memhotplug_init);
> #endif
> +
> +#ifdef CONFIG_KASAN_VMALLOC
> +static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
> + void *unused)
> +{
> + unsigned long page;
> +
. Rather than trying to
> accomodate RT-system by switching to a raw_spin_lock(), the lock is now
> completely dropped.
>
> Reported-by: Andre Przywara
> Signed-off-by: Julien Grall
> ---
Acked-by: Andrey Ryabinin
> lib/ubsan.c | 64
> ++
On 9/23/19 11:20 AM, Vlastimil Babka wrote:
> On 9/16/19 5:57 PM, Andrey Ryabinin wrote:
>> I'd rather keep all logic in one place, i.e. "if (!page_owner_disabled &&
>> (IS_ENABLED(CONFIG_KASAN) || debug_pagealloc_enabled())"
>> With this no chan
On 9/16/19 12:42 PM, Vlastimil Babka wrote:
> On 9/12/19 7:05 PM, Andrey Ryabinin wrote:
>>
>> Or another alternative option (and actually easier one to implement), leave
>> PAGE_OWNER as is (no "select"s in Kconfigs)
>> Make PAGE_OWNER_FREE_STACK like this
On 9/12/19 5:31 PM, Vlastimil Babka wrote:
> On 9/12/19 4:08 PM, Walter Wu wrote:
>>
>>> extern void __reset_page_owner(struct page *page, unsigned int order);
>>> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
>>> index 6c9682ce0254..dc560c7562e8 100644
>>> --- a/lib/Kconfig.kasan
>>>
On 9/12/19 4:53 PM, Vlastimil Babka wrote:
> On 9/11/19 5:19 PM, Qian Cai wrote:
>>
>> The new config looks redundant and confusing. It looks to me more of a
>> document update
>> in Documentation/dev-tools/kasan.txt to educate developers to select
>> PAGE_OWNER and
>> DEBUG_PAGEALLOC if
On 9/9/19 4:07 PM, Vlastimil Babka wrote:
> On 9/9/19 10:24 AM, walter-zh...@mediatek.com wrote:
>> From: Walter Wu
>>
>> This patch is KASAN report adds the alloc/free stacks for page allocator
>> in order to help programmer to see memory corruption caused by page.
>>
>> By default, KASAN
On 8/27/19 12:07 PM, Nick Hu wrote:
> Hi Andrey
>
> On Thu, Aug 22, 2019 at 11:59:02PM +0800, Andrey Ryabinin wrote:
>> On 8/7/19 10:19 AM, Nick Hu wrote:
>>> There are some features which need this string operation for compilation,
>>> like KASA
On 8/14/19 10:44 AM, Nick Hu wrote:
>>
>>> diff --git a/arch/riscv/kernel/vmlinux.lds.S
>>> b/arch/riscv/kernel/vmlinux.lds.S
>>> index 23cd1a9..9700980 100644
>>> --- a/arch/riscv/kernel/vmlinux.lds.S
>>> +++ b/arch/riscv/kernel/vmlinux.lds.S
>>> @@ -46,6 +46,7 @@ SECTIONS
>>>
On 8/7/19 10:19 AM, Nick Hu wrote:
> There are some features which need this string operation for compilation,
> like KASAN. So the purpose of this porting is for the features like KASAN
> which cannot be compiled without it.
>
Compilation error can be fixed by diff bellow (I didn't test it).
If
ion can be identified whether it's
"use-after-free" or "out-of-bound".
[aryabi...@virtuozzo.com: simplify & clenup code:
https://lkml.kernel.org/r/3318f9d7-a760-3cc8-b700-f06108ae7...@virtuozzo.com]
Signed-off-by: Walter Wu
Signed-off-by: Andrey Ryabinin
---
== C
On 8/20/19 8:37 AM, Walter Wu wrote:
> On Tue, 2019-08-06 at 13:43 +0800, Walter Wu wrote:
>> This patch adds memory corruption identification at bug report for
>> software tag-based mode, the report show whether it is "use-after-free"
>> or "out-of-bound" error instead of "invalid-access"
double-free and it doesn't matter what tag the pointer have.
2) If pointer tag is different from 0xFF, make sure that tag in the shadow
is the same as in the pointer.
Fixes: 7f94ffbc4c6a ("kasan: add hooks implementation for tag-based mode")
Signed-off-by: Andrey Ryabinin
.@mediatek.com/
> [2]
> https://lore.kernel.org/linux-arm-kernel/20190819132347.gb9...@lakrids.cambridge.arm.com/
>
> Signed-off-by: Mark Rutland
> Reviewed-by: Andrey Konovalov
> Tested-by: Andrey Konovalov
> Cc: Alexander Potapenko
> Cc: Andrew Morton
> Cc: Andrey
On 8/19/19 4:34 PM, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 02:23:48PM +0100, Mark Rutland wrote:
>> On Mon, Aug 19, 2019 at 01:56:26PM +0100, Will Deacon wrote:
>>> On Mon, Aug 19, 2019 at 07:44:20PM +0800, Walter Wu wrote:
__arm_v7s_unmap() call iopte_deref() to translate
On 7/26/19 4:19 PM, Walter Wu wrote:
> On Fri, 2019-07-26 at 15:52 +0300, Andrey Ryabinin wrote:
>>
>> On 7/26/19 3:28 PM, Walter Wu wrote:
>>> On Fri, 2019-07-26 at 15:00 +0300, Andrey Ryabinin wrote:
>>>>
>>>
>>>>>
>>>&
On 7/26/19 3:28 PM, Walter Wu wrote:
> On Fri, 2019-07-26 at 15:00 +0300, Andrey Ryabinin wrote:
>>
>
>>>
>>>
>>> I remember that there are already the lists which you concern. Maybe we
>>> can try to solve those problems one by one.
>>&
On 7/22/19 12:52 PM, Walter Wu wrote:
> On Thu, 2019-07-18 at 19:11 +0300, Andrey Ryabinin wrote:
>>
>> On 7/15/19 6:06 AM, Walter Wu wrote:
>>> On Fri, 2019-07-12 at 13:52 +0300, Andrey Ryabinin wrote:
>>>>
>>>> On 7/11/19 1:06 PM, Walter W
On 7/23/19 11:13 AM, Nicolas Boichat wrote:
> On Tue, Jul 23, 2019 at 3:46 PM Dmitry Vyukov wrote:
>>
>> On Tue, Jul 23, 2019 at 9:26 AM Nicolas Boichat
>> wrote:
>>>
>>> When KASan is enabled, a lot of memory is allocated early on,
>>> and kmemleak complains (this is on a 4GB RAM system):
ready
> attempt to disable it, but this fails on clang because the check is
> mixed with the gcc specific -fno-conserve-stack option. According
> to Andrey Ryabinin, that option is not even needed, dropping it here
> fixes the stackprotector issue.
>
> Fixes: d08965a27e84 ("x86/ua
identally enabling it once they update to clang-9, and
> to help automated build testing with clang-9.
>
> Link: https://bugs.llvm.org/show_bug.cgi?id=38809
> Fixes: 6baec880d7a5 ("kasan: turn off asan-stack for clang-8 and earlier")
> Signed-off-by: Arnd Bergmann
> ---
Reviewed-by: Andrey Ryabinin
h an #ifdef.
>
> Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via
> pagealloc")
> Link: https://lore.kernel.org/lkml/20190618095347.3850490-1-a...@arndb.de/
> Reviewed-by: Andrey Konovalov
> Signed-off-by: Arnd Bergmann
Reviewed-by: Andrey Ryabinin
On 7/22/19 12:10 PM, Arnd Bergmann wrote:
> objtool points out several conditions that it does not like, depending
> on the combination with other configuration options and compiler
> variants:
>
> stack protector:
> lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0xbf: call to
On 7/18/19 6:51 PM, Dmitry Vyukov wrote:
> On Mon, Jul 8, 2019 at 5:05 PM Dennis Zhou wrote:
>>
>> Hi Andrey, Alexander, and Dmitry,
>>
>> It was reported to me that when percpu is ran with param
>> percpu_alloc=page or the embed allocation scheme fails and falls back to
>> page that a double
On 7/18/19 5:14 PM, Arnd Bergmann wrote:
> asan-stack mode still uses dangerously large kernel stacks of
> tens of kilobytes in some drivers, and it does not seem that anyone
> is working on the clang bug.
>
> Let's push this back to clang-10 for now so users don't run into
> this by accident,
On 7/15/19 6:06 AM, Walter Wu wrote:
> On Fri, 2019-07-12 at 13:52 +0300, Andrey Ryabinin wrote:
>>
>> On 7/11/19 1:06 PM, Walter Wu wrote:
>>> On Wed, 2019-07-10 at 21:24 +0300, Andrey Ryabinin wrote:
>>>>
>>>> On 7/9/19 5:53 AM, Walter Wu wrote:
On 7/11/19 1:06 PM, Walter Wu wrote:
> On Wed, 2019-07-10 at 21:24 +0300, Andrey Ryabinin wrote:
>>
>> On 7/9/19 5:53 AM, Walter Wu wrote:
>>> On Mon, 2019-07-08 at 19:33 +0300, Andrey Ryabinin wrote:
>>>>
>>>> On 7/5/19 4:34 PM, Dmitry Vyukov wro
heck_{read,write}
> mm/kasan: Change kasan_check_{read,write} to return boolean
> lib/test_kasan: Add test for double-kzfree detection
> mm/slab: Refactor common ksize KASAN logic into slab_common.c
> mm/kasan: Add object validation in ksize()
>
Reviewed-by: Andrey Ryabinin
On 7/9/19 5:53 AM, Walter Wu wrote:
> On Mon, 2019-07-08 at 19:33 +0300, Andrey Ryabinin wrote:
>>
>> On 7/5/19 4:34 PM, Dmitry Vyukov wrote:
>>> On Mon, Jul 1, 2019 at 11:56 AM Walter Wu wrote:
>>>
>>> Sorry for delays. I am overwhelm by some urge
On 7/5/19 4:34 PM, Dmitry Vyukov wrote:
> On Mon, Jul 1, 2019 at 11:56 AM Walter Wu wrote:
> This patch adds memory corruption identification at bug report for
> software tag-based mode, the report show whether it is
> "use-after-free"
> or "out-of-bound" error
On 6/18/19 6:30 PM, Arnd Bergmann wrote:
> On Tue, Jun 18, 2019 at 4:30 PM Andrey Ryabinin
> wrote:
>> On 6/18/19 12:53 PM, Arnd Bergmann wrote:
>>> ARM64 randdconfig builds regularly run into a build error, especially
>>> when NUMA_BALAN
On 6/18/19 12:53 PM, Arnd Bergmann wrote:
> ARM64 randdconfig builds regularly run into a build error, especially
> when NUMA_BALANCING and SPARSEMEM are enabled but not SPARSEMEM_VMEMMAP:
>
> #error "KASAN: not enough bits in page flags for tag"
>
> The last-cpuid bits are already
On 6/18/19 3:56 PM, Arnd Bergmann wrote:
> On Mon, Jun 17, 2019 at 4:02 PM Peter Zijlstra wrote:
>>
>> On Mon, Jun 17, 2019 at 02:31:09PM +0200, Arnd Bergmann wrote:
>>> objtool points out a condition that it does not like:
>>>
>>> lib/ubsan.o: warning: objtool:
Commit-ID: f3176ec9420de0c385023afa3e4970129444ac2f
Gitweb: https://git.kernel.org/tip/f3176ec9420de0c385023afa3e4970129444ac2f
Author: Andrey Ryabinin
AuthorDate: Fri, 14 Jun 2019 17:31:49 +0300
Committer: Thomas Gleixner
CommitDate: Fri, 14 Jun 2019 16:37:30 +0200
x86/kasan: Fix
N_MASK wasn't enough to mask out all of them. So we've got
wrong not even canonical address and crash on the attempt to dereference it.
Fixes: 12a8cc7fcf54 ("x86/kasan: Use the same shadow offset for 4- and 5-level
paging")
Reported-by: Kirill A. Shutemov
Signed-off-by: Andrey Ryab
On 6/12/19 11:57 AM, Vlastimil Babka wrote:
> On 7/17/18 6:00 PM, Andrey Ryabinin wrote:
>> fuse_dev_splice_write() reads pipe->buffers to determine the size of
>> 'bufs' array before taking the pipe_lock(). This is not safe as
>> another thread might change the
On 6/13/19 4:05 PM, Dmitry Vyukov wrote:
> On Thu, Jun 13, 2019 at 2:27 PM Andrey Ryabinin
> wrote:
>> On 6/13/19 11:13 AM, Walter Wu wrote:
>>> This patch adds memory corruption identification at bug report for
>>> software tag-based mode, the report show
h bitops tests (pre-requisite patch).
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198439
> Signed-off-by: Marco Elver
Reviewed-by: Andrey Ryabinin
e be flagged by objtool.
>
> For consistency, kernel/signal.c was changed to mirror this change,
> however, is never instrumented with KASAN (currently unsupported under
> x86 32bit).
>
> Signed-off-by: Marco Elver
> Suggested-by: H. Peter Anvin
Reviewed-by: Andrey Ryabinin
On 6/13/19 11:13 AM, Walter Wu wrote:
> This patch adds memory corruption identification at bug report for
> software tag-based mode, the report show whether it is "use-after-free"
> or "out-of-bound" error instead of "invalid-access" error.This will make
> it easier for programmers to see the
oks implementation for tag-based mode")
Cc:
Reviewed-by: Andrey Ryabinin
> ---
>
> v1 -> v2:
>
> * Initialize tag to 0xff at Andrey's request
>
> mm/kasan/common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/kasan/common.c b/mm
he buggy address:
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198435
> Signed-off-by: Marco Elver
Reviewed-by: Andrey Ryabinin
On 5/21/19 7:07 PM, Marco Elver wrote:
> On Tue, 21 May 2019 at 17:53, Alexander Potapenko wrote:
>>
>> On Tue, May 21, 2019 at 5:43 PM Andrey Ryabinin
>> wrote:
>>>
>>> On 5/20/19 6:47 PM, Marco Elver wrote:
>>>
>>>> +s
On 5/20/19 6:47 PM, Marco Elver wrote:
> +static void print_decoded_frame_descr(const char *frame_descr)
> +{
> + /*
> + * We need to parse the following string:
> + *"n alloc_1 alloc_2 ... alloc_n"
> + * where alloc_i looks like
> + *"offset size len name"
> +
On 5/20/19 8:38 AM, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -7.6% regression of netperf.Throughput_total_tps due to
> commit:
>
>
> commit: f0996bc2978e02d2ea898101462b960f6119b18f ("ubsan: Fix nasty
> -Wbuiltin-declaration-mismatch GCC-9 warnings")
>
On 5/6/19 6:10 PM, Greg Kroah-Hartman wrote:
> On Mon, May 06, 2019 at 05:55:54PM +0300, Andrey Ryabinin wrote:
>>
>>
>> On 5/6/19 5:32 PM, Greg Kroah-Hartman wrote:
>>> From: Andrey Ryabinin
>>>
>>> commit c5caf21ab0cf884ef15b25af234f620e4a23313
On 5/6/19 5:32 PM, Greg Kroah-Hartman wrote:
> From: Arnd Bergmann
>
> commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream.
>
This is a fix/workaround for the previous patch c5caf21ab0cf "kasan: turn on
-fsanitize-address-use-after-scope"
which shouldn't be in the -stable. So without
On 5/6/19 5:32 PM, Greg Kroah-Hartman wrote:
> From: Andrey Ryabinin
>
> commit c5caf21ab0cf884ef15b25af234f620e4a233139 upstream.
>
> In the upcoming gcc7 release, the -fsanitize=kernel-address option at
> first implied new -fsanitize-address-use-after-scope option. This
of __ubsan_handle_*() often uses 'unsigned long'
types in parameters while GCC these parameters as 'void *' types,
hence the mismatch.
Fix this by using 'void *' to match GCC's declarations.
Reported-by: Linus Torvalds
Signed-off-by: Andrey Ryabinin
Fixes: c6d308534aef ("UBSAN: run-time undefined beh
The kernel the kernel is built with -Wvla for some time, so is not supposed
to have any variable length arrays. Remove vla bounds checking from ubsan
since it's useless now.
Signed-off-by: Andrey Ryabinin
---
lib/ubsan.c| 18 --
lib/ubsan.h| 5
Commit 0a79cdad5eb2 ("mm: use alloc_flags to record if kswapd can wake")
removed setting of the ALLOC_NOFRAGMENT flag. Bring it back.
Fixes: 0a79cdad5eb2 ("mm: use alloc_flags to record if kswapd can wake")
Signed-off-by: Andrey Ryabinin
---
mm/page_alloc.c | 6 +++--
ows compiler to optimize away all accesses to
'zone'.
Fixes: 6bb154504f8b ("mm, page_alloc: spread allocations across zones before
introducing fragmentation")
Signed-off-by: Andrey Ryabinin
---
mm/page_alloc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/page_alloc.c b/mm
On 4/19/19 4:41 PM, Eric Dumazet wrote:
> On 04/19/2019 06:17 AM, Andrey Ryabinin wrote:
>>
>
>> I don't see why that would be a problem. If refill failed because we didn't
>> have
>> access to reserves, then there going to be an another refill attempt, right?
of absence memalloc sockets in the system. Do this by adding
the __GFP_MEMALLOC only when such socket is present in the system.
Fixes: 0614002bb5f7 ("netvm: propagate page->pfmemalloc from skb_alloc_page to
skb")
Signed-off-by: Andrey Ryabinin
---
include/linux/skbuff.h | 17 ++
lloc_skb()). Such allocations have greater
chances
to succeed because plain GFP_ATOMIC can use 1/4 of memory reserves, while
GFP_ATOMIC|__GFP_NOMEMALLOC can't. So it's seems more reasonable to add
__GFP_NOMEMALLOC only if we have fallback to memory reserves.
Signed-off-by: Andrey Ryabinin
---
net
nge as a result of this patch.
>
> Signed-off-by: Torsten Duwe
>
Acked-by: Andrey Ryabinin
herry-pick this patch pre-5.2.
>
> My preference is for option 2, but that requires permission from
> ubsan's owner. Andrey?
>
Fine by me:
Acked-by: Andrey Ryabinin
> Signed-off-by: George Spelvin
> Cc: Andrey Ryabinin
> Cc: linux-s...@vger.kernel.org
> Cc: Heiko Ca
On 3/7/19 11:33 PM, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 11:15:42PM +0300, Andrey Ryabinin wrote:
>>
>>
>> On 3/7/19 8:41 PM, Peter Zijlstra wrote:
>>> On Thu, Mar 07, 2019 at 08:33:26AM -0800, Linus Torvalds wrote:
>>>> On Thu, Ma
On 3/7/19 8:41 PM, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 08:33:26AM -0800, Linus Torvalds wrote:
>> On Thu, Mar 7, 2019 at 3:52 AM Peter Zijlstra wrote:
>>>
>>> XXX: are we sure we want __memset marked AC-safe?
>>
>> It's certainly one of the safer functions to call with AC set, but
ONE_DEVICE with work with
> KASAN")
> Reported-by: kbuild test robot
> Signed-off-by: Andrey Konovalov
> ---
Acked-by: Andrey Ryabinin
> mm/kasan/init.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/mm/kasan/init.c b/mm/kasan/init.c
>
On 3/2/19 1:20 AM, Johannes Weiner wrote:
> On Fri, Mar 01, 2019 at 10:46:34PM +0300, Andrey Ryabinin wrote:
>> On 3/1/19 8:49 PM, Johannes Weiner wrote:
>>> On Fri, Mar 01, 2019 at 01:38:26PM +0300, Andrey Ryabinin wrote:
>>>> On 2/26/19 3:50 PM, Andrey Ryabinin
On 3/1/19 8:49 PM, Johannes Weiner wrote:
> Hello Andrey,
>
> On Fri, Mar 01, 2019 at 01:38:26PM +0300, Andrey Ryabinin wrote:
>> On 2/26/19 3:50 PM, Andrey Ryabinin wrote:
>>> On 2/22/19 10:15 PM, Johannes Weiner wrote:
>>>> On Fri, Feb 22, 2019 at 08:
A slightly better version of __split_huge_page();
Signed-off-by: Andrey Ryabinin
Cc: Vlastimil Babka
Cc: Mel Gorman
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Rik van Riel
Cc: William Kucharski
Cc: John Hubbard
---
mm/huge_memory.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions
On 3/1/19 12:44 AM, John Hubbard wrote:
> On 2/28/19 12:33 AM, Andrey Ryabinin wrote:
>> We have common pattern to access lru_lock from a page pointer:
>> zone_lru_lock(page_zone(page))
>>
>> Which is silly, because it unfolds to this:
>>
>&g
On 2/26/19 3:50 PM, Andrey Ryabinin wrote:
>
>
> On 2/22/19 10:15 PM, Johannes Weiner wrote:
>> On Fri, Feb 22, 2019 at 08:58:25PM +0300, Andrey Ryabinin wrote:
>>> In a presence of more than 1 memory cgroup in the system our reclaim
>>> logic is just suck.
On 2/28/19 6:52 PM, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 4:46 PM Peter Zijlstra wrote:
>>
>> On Thu, Feb 28, 2019 at 04:22:04PM +0100, Dmitry Vyukov wrote:
>>> On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote:
Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get
Since commit 9092c71bb724 ("mm: use sc->priority for slab shrink targets")
the argument 'unsigned long *lru_pages' passed around with no purpose.
Remove it.
Signed-off-by: Andrey Ryabinin
Acked-by: Johannes Weiner
Acked-by: Vlastimil Babka
Cc: Michal Hocko
Cc: Rik van Riel
C
_nid(page))->lru_lock
Remove zone_lru_lock() function, since it's only complicate things.
Use 'page_pgdat(page)->lru_lock' pattern instead.
Signed-off-by: Andrey Ryabinin
Acked-by: Vlastimil Babka
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Rik van Riel
Cc: Mel Gorman
---
Changes since v
too_many_isolated() in mm/compaction.c looks only at node state,
so it makes more sense to change argument to pgdat instead of zone.
Signed-off-by: Andrey Ryabinin
Acked-by: Vlastimil Babka
Acked-by: Rik van Riel
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Mel Gorman
---
Changes since v1
workingset_eviction() doesn't use and never did use the @mapping argument.
Remove it.
Signed-off-by: Andrey Ryabinin
Acked-by: Johannes Weiner
Acked-by: Rik van Riel
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Mel Gorman
---
Changes since v1:
- s/@mapping/@page->mapping in comment
- A
On 2/27/19 5:08 PM, Peter Zijlstra wrote:
> On Mon, Feb 25, 2019 at 01:43:35PM +0100, Peter Zijlstra wrote:
>> It is important that UACCESS regions are as small as possible;
>> furthermore the UACCESS state is not scheduled, so doing anything that
>> might directly call into the scheduler will
et, the option remains invisible, so allmodconfig and randconfig builds
> (which are normally done with a forced CONFIG_COMPILE_TEST) will still result
> in a mostly clean build.
>
> Cc: Andrey Ryabinin
> Cc: Dmitry Vyukov
> Cc: Nick Desaulniers
> Cc: Mark Brown
> Cc: Qian C
On 2/25/19 7:03 AM, Roman Gushchin wrote:
> On Fri, Feb 22, 2019 at 08:58:25PM +0300, Andrey Ryabinin wrote:
>> In a presence of more than 1 memory cgroup in the system our reclaim
>> logic is just suck. When we hit memory limit (global or a limit on
>> cgroup with subgr
On 2/22/19 10:15 PM, Johannes Weiner wrote:
> On Fri, Feb 22, 2019 at 08:58:25PM +0300, Andrey Ryabinin wrote:
>> In a presence of more than 1 memory cgroup in the system our reclaim
>> logic is just suck. When we hit memory limit (global or a limit on
>> cgroup with subgr
On 2/25/19 3:01 PM, Vlastimil Babka wrote:
> On 2/22/19 6:43 PM, Andrey Ryabinin wrote:
>> workingset_eviction() doesn't use and never did use the @mapping argument.
>> Remove it.
>>
>> Signed-off-by: Andrey Ryabinin
>> Cc: Johannes Weiner
>> Cc: Mich
On 2/22/19 9:22 PM, Johannes Weiner wrote:
> On Fri, Feb 22, 2019 at 08:43:37PM +0300, Andrey Ryabinin wrote:
>> shrink_node_memcg() always forcely shrink active anon list.
>> This doesn't seem like correct behavior. If system/memcg has no swap, it's
>> absolutely pointless
ust imagine something more sophisticated
than just 'dd', the job that would benefit from occupying all available
memory. The best limit for such job would be something like
'total_memory' - 'sample size' which is again unknown.
Signed-off-by: Andrey Ryabinin
Cc: Johannes Weiner
Cc: Michal Hocko
. If there are cases when we want more
aggressive scan of the anon lru we should just change the scan target
in get_scan_count() (and better explain such cases in the comments).
Remove this force shrink and let get_scan_count() to decide how
much of active anon we want to shrink.
Signed-off-by: Andrey
workingset_eviction() doesn't use and never did use the @mapping argument.
Remove it.
Signed-off-by: Andrey Ryabinin
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Rik van Riel
Cc: Mel Gorman
---
include/linux/swap.h | 2 +-
mm/vmscan.c | 2 +-
mm/workingset.c
The argument 'unsigned long *lru_pages' passed around with no purpose,
remove it.
Signed-off-by: Andrey Ryabinin
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Rik van Riel
Cc: Mel Gorman
---
mm/vmscan.c | 17 +
1 file changed, 5 insertions(+), 12 deletions
_nid(page))->lru_lock
Remove zone_lru_lock() function, since it's only complicate things.
Use 'page_pgdat(page)->lru_lock' pattern instead.
Signed-off-by: Andrey Ryabinin
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Rik van Riel
Cc: Mel Gorman
---
Documentation/cgroup-v1/memc
too_many_isolated() in mm/compaction.c looks only at node state,
so it makes more sense to change argument to pgdat instead of zone.
Signed-off-by: Andrey Ryabinin
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Rik van Riel
Cc: Mel Gorman
---
mm/compaction.c | 19
On 2/21/19 6:19 PM, Arnd Bergmann wrote:
> On Thu, Feb 21, 2019 at 11:06 AM Andrey Ryabinin
> wrote:
>> 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
On 2/21/19 6:26 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 21, 2019 at 06:00:06PM +0300, Andrey Ryabinin wrote:
>> 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.
>>>
>>
>> Dr
1 - 100 of 2765 matches
Mail list logo
