Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/12/2018 03:21 AM, Andrew Morton wrote: > On Thu, 11 Jan 2018 14:59:23 +0300 Andrey Ryabinin > wrote: > >> On 01/11/2018 01:31 AM, Andrew Morton wrote: >>> On Wed, 10 Jan 2018 15:43:17 +0300 Andrey Ryabinin >>> wrote: >>> >>>> m

Re: [PATCH 2/2] kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage

On 01/11/2018 06:29 PM, Andrey Konovalov wrote: > diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h > index e266f80e45b7..811643fe7640 100644 > --- a/arch/arm64/include/asm/kasan.h > +++ b/arch/arm64/include/asm/kasan.h > @@ -27,7 +27,8 @@ > * should satisfy the

Re: [PATCH 2/2] kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage

On 01/11/2018 06:29 PM, Andrey Konovalov wrote: > diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h > index e266f80e45b7..811643fe7640 100644 > --- a/arch/arm64/include/asm/kasan.h > +++ b/arch/arm64/include/asm/kasan.h > @@ -27,7 +27,8 @@ > * should satisfy the

Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/11/2018 07:29 PM, Michal Hocko wrote: > On Thu 11-01-18 18:23:57, Andrey Ryabinin wrote: >> On 01/11/2018 03:46 PM, Michal Hocko wrote: >>> On Thu 11-01-18 15:21:33, Andrey Ryabinin wrote: >>>> >>>> >>>> On 01/11/2018 01:42 PM, Mich

Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/11/2018 07:29 PM, Michal Hocko wrote: > On Thu 11-01-18 18:23:57, Andrey Ryabinin wrote: >> On 01/11/2018 03:46 PM, Michal Hocko wrote: >>> On Thu 11-01-18 15:21:33, Andrey Ryabinin wrote: >>>> >>>> >>>> On 01/11/2018 01:42 PM, Mich

Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/11/2018 03:46 PM, Michal Hocko wrote: > On Thu 11-01-18 15:21:33, Andrey Ryabinin wrote: >> >> >> On 01/11/2018 01:42 PM, Michal Hocko wrote: >>> On Wed 10-01-18 15:43:17, Andrey Ryabinin wrote: >>> [...] >>>> @@ -2506,15 +2480,13 @@ static

Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/11/2018 03:46 PM, Michal Hocko wrote: > On Thu 11-01-18 15:21:33, Andrey Ryabinin wrote: >> >> >> On 01/11/2018 01:42 PM, Michal Hocko wrote: >>> On Wed 10-01-18 15:43:17, Andrey Ryabinin wrote: >>> [...] >>>> @@ -2506,15 +2480,13 @@ static

Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/11/2018 01:42 PM, Michal Hocko wrote: > On Wed 10-01-18 15:43:17, Andrey Ryabinin wrote: > [...] >> @@ -2506,15 +2480,13 @@ static int mem_cgroup_resize_limit(struct mem_cgroup >> *memcg, >> if (!ret) >&

Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/11/2018 01:42 PM, Michal Hocko wrote: > On Wed 10-01-18 15:43:17, Andrey Ryabinin wrote: > [...] >> @@ -2506,15 +2480,13 @@ static int mem_cgroup_resize_limit(struct mem_cgroup >> *memcg, >> if (!ret) >&

Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/11/2018 01:31 AM, Andrew Morton wrote: > On Wed, 10 Jan 2018 15:43:17 +0300 Andrey Ryabinin <aryabi...@virtuozzo.com> > wrote: > >> mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) >> pages on each iteration. This makes practically impo

Re: [PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/11/2018 01:31 AM, Andrew Morton wrote: > On Wed, 10 Jan 2018 15:43:17 +0300 Andrey Ryabinin > wrote: > >> mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) >> pages on each iteration. This makes practically impossible to decrease >> li

[PATCH] x86/kasan: panic if there is not enough memory to boot.

ong...@intel.com> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- arch/x86/mm/kasan_init_64.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c index 47388f0c0e59..af6f2f9c6a26 10064

[PATCH] x86/kasan: panic if there is not enough memory to boot.

-by: Andrey Ryabinin --- arch/x86/mm/kasan_init_64.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c index 47388f0c0e59..af6f2f9c6a26 100644 --- a/arch/x86/mm/kasan_init_64.c +++ b/arch/x86/mm

[PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

cho: write error: Device or resource busy Instead of relying on retry_count, keep retrying the reclaim until the desired limit is reached or fail if the reclaim doesn't make any progress or a signal is pending. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Reviewed-by: Sha

[PATCH v4] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

cho: write error: Device or resource busy Instead of relying on retry_count, keep retrying the reclaim until the desired limit is reached or fail if the reclaim doesn't make any progress or a signal is pending. Signed-off-by: Andrey Ryabinin Reviewed-by: Shakeel Butt --- Changes since v3: -

Re: [PATCH v3 2/2] mm/memcg: Consolidate mem_cgroup_resize_[memsw]_limit() functions.

On 01/09/2018 08:10 PM, Shakeel Butt wrote: > On Tue, Jan 9, 2018 at 8:58 AM, Andrey Ryabinin <aryabi...@virtuozzo.com> > wrote: >> mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost >> identical functions. Instead of having two of them, we cou

Re: [PATCH v3 2/2] mm/memcg: Consolidate mem_cgroup_resize_[memsw]_limit() functions.

On 01/09/2018 08:10 PM, Shakeel Butt wrote: > On Tue, Jan 9, 2018 at 8:58 AM, Andrey Ryabinin > wrote: >> mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost >> identical functions. Instead of having two of them, we could pass an >

Re: [PATCH v3 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/09/2018 07:58 PM, Andrey Ryabinin wrote: > mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) > pages on each iteration. This makes practically impossible to decrease > limit of memory cgroup. Tasks could easily allocate back 32 pages, > so we can't r

Re: [PATCH v3 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 01/09/2018 07:58 PM, Andrey Ryabinin wrote: > mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) > pages on each iteration. This makes practically impossible to decrease > limit of memory cgroup. Tasks could easily allocate back 32 pages, > so we can't r

[PATCH v3 2/2] mm/memcg: Consolidate mem_cgroup_resize_[memsw]_limit() functions.

mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost identical functions. Instead of having two of them, we could pass an additional argument to mem_cgroup_resize_limit() and by using it, consolidate all the code in a single function. Signed-off-by: Andrey Ryabinin <ary

[PATCH v3 2/2] mm/memcg: Consolidate mem_cgroup_resize_[memsw]_limit() functions.

mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost identical functions. Instead of having two of them, we could pass an additional argument to mem_cgroup_resize_limit() and by using it, consolidate all the code in a single function. Signed-off-by: Andrey Ryabinin --- mm

[PATCH v3 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

cho: write error: Device or resource busy Instead of relying on retry_count, keep retrying the reclaim until the desired limit is reached or fail if the reclaim doesn't make any progress or a signal is pending. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- Changes since v2:

[PATCH v3 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

cho: write error: Device or resource busy Instead of relying on retry_count, keep retrying the reclaim until the desired limit is reached or fail if the reclaim doesn't make any progress or a signal is pending. Signed-off-by: Andrey Ryabinin --- Changes since v2: - Changelog wording per mhocko

Re: [PATCH] lib/strscpy: remove word-at-a-time optimization.

Attached user space program I used to see the difference. Usage: gcc -02 -o strscpy strscpy_test.c ./strscpy {b|w} src_str_len count src_str_len - length of source string in between 1-4096 count - how many strscpy() to execute. Also I've noticed something strange. I'm not sure

Re: [PATCH] lib/strscpy: remove word-at-a-time optimization.

Attached user space program I used to see the difference. Usage: gcc -02 -o strscpy strscpy_test.c ./strscpy {b|w} src_str_len count src_str_len - length of source string in between 1-4096 count - how many strscpy() to execute. Also I've noticed something strange. I'm not sure

[PATCH] lib/strscpy: remove word-at-a-time optimization.

. Fixes: 30035e45753b7 ("string: provide strscpy()") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: <sta...@vger.kernel.org> --- lib/string.c | 38 -- 1 file changed, 38 deletions(-) diff --git a/lib/string.c b/lib/strin

[PATCH] lib/strscpy: remove word-at-a-time optimization.

. Fixes: 30035e45753b7 ("string: provide strscpy()") Signed-off-by: Andrey Ryabinin Cc: --- lib/string.c | 38 -- 1 file changed, 38 deletions(-) diff --git a/lib/string.c b/lib/string.c index 64a9e33f1daa..6205dd71aa0f 100644 --- a/lib/string.c +++ b/li

[tip:x86/pti] x86/mm: Set MODULES_END to 0xffffffffff000000

Commit-ID: f5a40711fa58f1c109165a4fec6078bf2dfd2bdc Gitweb: https://git.kernel.org/tip/f5a40711fa58f1c109165a4fec6078bf2dfd2bdc Author: Andrey Ryabinin <aryabi...@virtuozzo.com> AuthorDate: Thu, 28 Dec 2017 19:06:20 +0300 Committer: Thomas Gleixner <t...@linutronix.de> Commit

[tip:x86/pti] x86/mm: Set MODULES_END to 0xffffffffff000000

Commit-ID: f5a40711fa58f1c109165a4fec6078bf2dfd2bdc Gitweb: https://git.kernel.org/tip/f5a40711fa58f1c109165a4fec6078bf2dfd2bdc Author: Andrey Ryabinin AuthorDate: Thu, 28 Dec 2017 19:06:20 +0300 Committer: Thomas Gleixner CommitDate: Thu, 4 Jan 2018 23:04:57 +0100 x86/mm: Set

Re: [lkp-robot] [x86/cpu_entry_area] 10043e02db: kernel_BUG_at_arch/x86/mm/physaddr.c

On 12/28/2017 02:54 PM, Dmitry Vyukov wrote: > On Thu, Dec 28, 2017 at 12:51 PM, Thomas Gleixner wrote: >> On Wed, 27 Dec 2017, Dmitry Vyukov wrote: >>> On Wed, Dec 27, 2017 at 7:05 PM, Thomas Gleixner wrote: So this dies simply because

Re: [lkp-robot] [x86/cpu_entry_area] 10043e02db: kernel_BUG_at_arch/x86/mm/physaddr.c

On 12/28/2017 02:54 PM, Dmitry Vyukov wrote: > On Thu, Dec 28, 2017 at 12:51 PM, Thomas Gleixner wrote: >> On Wed, 27 Dec 2017, Dmitry Vyukov wrote: >>> On Wed, Dec 27, 2017 at 7:05 PM, Thomas Gleixner wrote: So this dies simply because kasan_populate_shadow() runs out of memory and

[PATCH] x86/mm: Set MODULES_END to 0xffffffffff000000

;x86/cpu_entry_area: Move it out of the fixmap") the cpu_entry_area is no longer in fixmap, so we could just set MODULES_END to a fixed 8*PAGE_SIZE aligned address. Reported-by: Jakub Kicinski <kubak...@wp.pl> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: <sta...@v

[PATCH] x86/mm: Set MODULES_END to 0xffffffffff000000

;x86/cpu_entry_area: Move it out of the fixmap") the cpu_entry_area is no longer in fixmap, so we could just set MODULES_END to a fixed 8*PAGE_SIZE aligned address. Reported-by: Jakub Kicinski Signed-off-by: Andrey Ryabinin Cc: # 4.14 --- Documentation/x86/x86_64/mm.txt |

Re: [lkp-robot] [x86/cpu_entry_area] 10043e02db: kernel_BUG_at_arch/x86/mm/physaddr.c

On 12/27/2017 09:12 PM, Dmitry Vyukov wrote: >> >> Not really a problem caused by the patch above, it's merily exposing a code >> path which relies blindly on "enough memory available" assumptions. >> >> Throwing more memory at the VM makes the problem go away... > > Hi Thomas, > > We just need

Re: [lkp-robot] [x86/cpu_entry_area] 10043e02db: kernel_BUG_at_arch/x86/mm/physaddr.c

On 12/27/2017 09:12 PM, Dmitry Vyukov wrote: >> >> Not really a problem caused by the patch above, it's merily exposing a code >> path which relies blindly on "enough memory available" assumptions. >> >> Throwing more memory at the VM makes the problem go away... > > Hi Thomas, > > We just need

Re: linux/master crashes on boot with KASAN=y

On 12/24/2017 04:48 AM, Andy Lutomirski wrote: > On Sat, Dec 23, 2017 at 4:41 AM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> On 12/23/2017 11:01 AM, Jakub Kicinski wrote: >>> Hi! >>> >>> I bisected a crash on boot to this: >>> >

Re: linux/master crashes on boot with KASAN=y

On 12/24/2017 04:48 AM, Andy Lutomirski wrote: > On Sat, Dec 23, 2017 at 4:41 AM, Andrey Ryabinin > wrote: >> On 12/23/2017 11:01 AM, Jakub Kicinski wrote: >>> Hi! >>> >>> I bisected a crash on boot to this: >>> >>> commit 215065

Re: [PATCH] [v4] kasan: rework Kconfig settings

n warnings with KASAN=y"). > Two patches in linux-next should be merged first to avoid introducing > warnings in an allmodconfig build: > 3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN") > 16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN

Re: [PATCH] [v4] kasan: rework Kconfig settings

n warnings with KASAN=y"). > Two patches in linux-next should be merged first to avoid introducing > warnings in an allmodconfig build: > 3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN") > 16c3ada89cff ("media: r820t: fix r820t_write_reg for KAS

Re: linux/master crashes on boot with KASAN=y

On 12/23/2017 11:01 AM, Jakub Kicinski wrote: > Hi! > > I bisected a crash on boot to this: > > commit 21506525fb8ddb0342f2a2370812d47f6a1f3833 (HEAD, refs/bisect/bad) > Author: Andy Lutomirski > Date: Mon Dec 4 15:07:16 2017 +0100 > > x86/kasan/64: Teach KASAN about the

Re: linux/master crashes on boot with KASAN=y

On 12/23/2017 11:01 AM, Jakub Kicinski wrote: > Hi! > > I bisected a crash on boot to this: > > commit 21506525fb8ddb0342f2a2370812d47f6a1f3833 (HEAD, refs/bisect/bad) > Author: Andy Lutomirski > Date: Mon Dec 4 15:07:16 2017 +0100 > > x86/kasan/64: Teach KASAN about the cpu_entry_area

Re: [RFC] syzbot process

2017-12-21 15:52 GMT+03:00 Dmitry Vyukov : > Any other proposals, thoughts, ideas? > a) Assume that patches send in replies to the bug report are fixes. b) Almost the same as your "syzbot-fix: HASH" proposal, but slightly closer to normal kernel development workflow.

Re: [RFC] syzbot process

2017-12-21 15:52 GMT+03:00 Dmitry Vyukov : > Any other proposals, thoughts, ideas? > a) Assume that patches send in replies to the bug report are fixes. b) Almost the same as your "syzbot-fix: HASH" proposal, but slightly closer to normal kernel development workflow. Add hash/bug id into

Re: [PATCH 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 12/20/2017 09:15 PM, Shakeel Butt wrote: > On Wed, Dec 20, 2017 at 3:34 AM, Michal Hocko <mho...@kernel.org> wrote: >> On Wed 20-12-17 14:32:19, Andrey Ryabinin wrote: >>> On 12/20/2017 01:33 PM, Michal Hocko wrote: >>>> On Wed 20-1

Re: [PATCH 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 12/20/2017 09:15 PM, Shakeel Butt wrote: > On Wed, Dec 20, 2017 at 3:34 AM, Michal Hocko wrote: >> On Wed 20-12-17 14:32:19, Andrey Ryabinin wrote: >>> On 12/20/2017 01:33 PM, Michal Hocko wrote: >>>> On Wed 20-12-17 13:24:28, Andrey Ryabinin wrote: >>

[PATCH v2 2/2] mm/memcg: Consolidate mem_cgroup_resize_[memsw]_limit() functions.

mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost identical functions. Instead of having two of them, we could pass an additional argument to mem_cgroup_resize_limit() and by using it, consolidate all the code in a single function. Signed-off-by: Andrey Ryabinin <ary

[PATCH v2 2/2] mm/memcg: Consolidate mem_cgroup_resize_[memsw]_limit() functions.

mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost identical functions. Instead of having two of them, we could pass an additional argument to mem_cgroup_resize_limit() and by using it, consolidate all the code in a single function. Signed-off-by: Andrey Ryabinin --- mm

[PATCH v2 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

cho: write error: Device or resource busy Instead of relying on retry_count, keep trying to free required amount of pages until reclaimer makes any progress. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/memcontrol.c | 70 +--

[PATCH v2 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

cho: write error: Device or resource busy Instead of relying on retry_count, keep trying to free required amount of pages until reclaimer makes any progress. Signed-off-by: Andrey Ryabinin --- mm/memcontrol.c | 70 + 1 file changed, 16 ins

Re: [PATCH 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 12/20/2017 01:33 PM, Michal Hocko wrote: > On Wed 20-12-17 13:24:28, Andrey Ryabinin wrote: >> mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) >> pages on each iteration. This makes practically impossible to decrease >> limit of memory cgrou

Re: [PATCH 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

On 12/20/2017 01:33 PM, Michal Hocko wrote: > On Wed 20-12-17 13:24:28, Andrey Ryabinin wrote: >> mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX) >> pages on each iteration. This makes practically impossible to decrease >> limit of memory cgrou

[PATCH 2/2] mm/memcg: Consolidate mem_cgroup_resize_[memsw]_limit() functions.

mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost identical functions. Instead of having two of them, we could pass an additional argument to mem_cgroup_resize_limit() and by using it, consolidate all the code in a single function. Signed-off-by: Andrey Ryabinin <ary

[PATCH 2/2] mm/memcg: Consolidate mem_cgroup_resize_[memsw]_limit() functions.

mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost identical functions. Instead of having two of them, we could pass an additional argument to mem_cgroup_resize_limit() and by using it, consolidate all the code in a single function. Signed-off-by: Andrey Ryabinin --- mm

[PATCH 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

-bash: echo: write error: Device or resource busy Instead of trying to free small amount of pages, it's much more reasonable to free 'usage - limit' pages. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/memcontrol.c | 10 ++ 1 file changed, 6 insertions(+), 4

[PATCH 1/2] mm/memcg: try harder to decrease [memory,memsw].limit_in_bytes

-bash: echo: write error: Device or resource busy Instead of trying to free small amount of pages, it's much more reasonable to free 'usage - limit' pages. Signed-off-by: Andrey Ryabinin --- mm/memcontrol.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/mm/memcon

Re: BUG: unable to handle kernel paging request in do_futex

On 12/14/2017 06:31 PM, Thomas Gleixner wrote: > On Thu, 30 Nov 2017, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on 11fed7829beff10184503fd65e5919926464601a >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master >> compiler: gcc (GCC) 7.1.1 20170620 >>

Re: BUG: unable to handle kernel paging request in do_futex

On 12/14/2017 06:31 PM, Thomas Gleixner wrote: > On Thu, 30 Nov 2017, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on 11fed7829beff10184503fd65e5919926464601a >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master >> compiler: gcc (GCC) 7.1.1 20170620 >>

Re: [PATCH] lib/string: avoid reading beyond src buffer in strscpy

On 12/12/2017 01:19 PM, David Laight wrote: > From: Andrey Ryabinin >> Sent: 11 December 2017 16:44 > ... >> I suppose that depends on which one strscpy() caller you'd want to test. >> Briefly looking at all current users, it doesn't look like they process huge >&

Re: [PATCH] lib/string: avoid reading beyond src buffer in strscpy

On 12/12/2017 01:19 PM, David Laight wrote: > From: Andrey Ryabinin >> Sent: 11 December 2017 16:44 > ... >> I suppose that depends on which one strscpy() caller you'd want to test. >> Briefly looking at all current users, it doesn't look like they process huge >&

[tip:x86/urgent] x86/unwinder/guess: Prevent using CONFIG_UNWINDER_GUESS=y with CONFIG_STACKDEPOT=y

Commit-ID: 0a373d4fc248cb707821d7dad54ce6d5bcb0cdfe Gitweb: https://git.kernel.org/tip/0a373d4fc248cb707821d7dad54ce6d5bcb0cdfe Author: Andrey Ryabinin <aryabi...@virtuozzo.com> AuthorDate: Thu, 30 Nov 2017 15:35:54 +0300 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:x86/urgent] x86/unwinder/guess: Prevent using CONFIG_UNWINDER_GUESS=y with CONFIG_STACKDEPOT=y

Commit-ID: 0a373d4fc248cb707821d7dad54ce6d5bcb0cdfe Gitweb: https://git.kernel.org/tip/0a373d4fc248cb707821d7dad54ce6d5bcb0cdfe Author: Andrey Ryabinin AuthorDate: Thu, 30 Nov 2017 15:35:54 +0300 Committer: Ingo Molnar CommitDate: Mon, 11 Dec 2017 19:07:07 +0100 x86/unwinder/guess

Re: [PATCH] lib/string: avoid reading beyond src buffer in strscpy

On 12/08/2017 11:54 PM, Kees Cook wrote: > On Fri, Dec 8, 2017 at 7:29 AM, Dmitry Vyukov <dvyu...@google.com> wrote: >> On Fri, Dec 8, 2017 at 4:29 PM, Andrey Ryabinin <aryabi...@virtuozzo.com> >> wrote: >>> >>> So, possible solutions are: >>

Re: [PATCH] lib/string: avoid reading beyond src buffer in strscpy

On 12/08/2017 11:54 PM, Kees Cook wrote: > On Fri, Dec 8, 2017 at 7:29 AM, Dmitry Vyukov wrote: >> On Fri, Dec 8, 2017 at 4:29 PM, Andrey Ryabinin >> wrote: >>> >>> So, possible solutions are: >>> >>> 1) Simply disable word-at-a-tim

Re: [PATCH] lib/string: avoid reading beyond src buffer in strscpy

On 12/07/2017 09:26 PM, Kees Cook wrote: > On Thu, Dec 7, 2017 at 3:33 AM, Eryu Guan wrote: >> strscpy() tries to copy sizeof(unsigned long) bytes a time from src >> to dest when possible, and stops the loop when 'max' is less than >> sizeof(unsigned long). But it doesn't check

Re: [PATCH] lib/string: avoid reading beyond src buffer in strscpy

On 12/07/2017 09:26 PM, Kees Cook wrote: > On Thu, Dec 7, 2017 at 3:33 AM, Eryu Guan wrote: >> strscpy() tries to copy sizeof(unsigned long) bytes a time from src >> to dest when possible, and stops the loop when 'max' is less than >> sizeof(unsigned long). But it doesn't check if (src+res) goes

Re: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

On 12/08/2017 02:14 PM, David Laight wrote: > From: Andrey Ryabinin >> Sent: 08 December 2017 10:49 > ... >> CONFIG_UBSAN_ALIGNMENT is already disabled by default for >> HAVE_EFFICIENT_UNALIGNED_ACCESS=y because it's noisy, >> but we still allow users to enable it

Re: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

On 12/08/2017 02:14 PM, David Laight wrote: > From: Andrey Ryabinin >> Sent: 08 December 2017 10:49 > ... >> CONFIG_UBSAN_ALIGNMENT is already disabled by default for >> HAVE_EFFICIENT_UNALIGNED_ACCESS=y because it's noisy, >> but we still allow users to enable it

Re: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

On 12/08/2017 02:24 AM, Andrew Morton wrote: > On Thu, 7 Dec 2017 16:31:23 +0300 Andrey Ryabinin <aryabi...@virtuozzo.com> > wrote: > >> On 12/07/2017 03:49 AM, Andrew Morton wrote: >>> (correcting Andrey's email address) >>> >>> >>>

Re: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

On 12/08/2017 02:24 AM, Andrew Morton wrote: > On Thu, 7 Dec 2017 16:31:23 +0300 Andrey Ryabinin > wrote: > >> On 12/07/2017 03:49 AM, Andrew Morton wrote: >>> (correcting Andrey's email address) >>> >>> >>> From: Ding Tianhong >>>

Re: [RFC PATCH] mm: kasan: suppress soft lockup in slub when !CONFIG_PREEMPT

On 12/08/2017 11:26 AM, Dmitry Vyukov wrote: > On Fri, Dec 8, 2017 at 12:40 AM, Matthew Wilcox wrote: >> On Fri, Dec 08, 2017 at 07:30:07AM +0800, Yang Shi wrote: >>> When running stress test with KASAN enabled, the below softlockup may >>> happen occasionally: >>> >>> NMI

Re: [RFC PATCH] mm: kasan: suppress soft lockup in slub when !CONFIG_PREEMPT

On 12/08/2017 11:26 AM, Dmitry Vyukov wrote: > On Fri, Dec 8, 2017 at 12:40 AM, Matthew Wilcox wrote: >> On Fri, Dec 08, 2017 at 07:30:07AM +0800, Yang Shi wrote: >>> When running stress test with KASAN enabled, the below softlockup may >>> happen occasionally: >>> >>> NMI watchdog: BUG: soft

Re: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

On 12/07/2017 03:49 AM, Andrew Morton wrote: > (correcting Andrey's email address) > > > From: Ding Tianhong > Subject: lib/ubsan.c: don't handle misaligned address when kernel supports > unaligned access > > ubsan reports a warning like: > > UBSAN: Undefined

Re: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

On 12/07/2017 03:49 AM, Andrew Morton wrote: > (correcting Andrey's email address) > > > From: Ding Tianhong > Subject: lib/ubsan.c: don't handle misaligned address when kernel supports > unaligned access > > ubsan reports a warning like: > > UBSAN: Undefined behaviour in

Re: [PATCH v4 5/5] kasan: added functions for unpoisoning stack variables

Signed-off-by: Greg Hackmann <ghackm...@google.com> > Signed-off-by: Paul Lawrence <paullawre...@google.com> > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH v4 5/5] kasan: added functions for unpoisoning stack variables

mented > memset(). > > This fixes linking the Clang-built kernel when using KASAN. > > Signed-off-by: Alexander Potapenko > [ghackm...@google.com: fix memset() parameters, and tweak > commit message to describe new callbacks] > Signed-off-by: Greg Hackmann > Signed-off-

Re: [PATCH v4 4/5] kasan: Add tests for alloca poisoning

On 12/04/2017 10:17 PM, Paul Lawrence wrote: > Signed-off-by: Greg Hackmann <ghackm...@google.com> > Signed-off-by: Paul Lawrence <paullawre...@google.com> > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH v4 4/5] kasan: Add tests for alloca poisoning

On 12/04/2017 10:17 PM, Paul Lawrence wrote: > Signed-off-by: Greg Hackmann > Signed-off-by: Paul Lawrence > --- Acked-by: Andrey Ryabinin

Re: [PATCH v4 3/5] kasan: support alloca() poisoning

e should poison > those too. > > __asan_allocas_unpoison() is just passed the top and bottom of the > dynamic stack area, so unpoisoning is simpler. > > Signed-off-by: Greg Hackmann <ghackm...@google.com> > Signed-off-by: Paul Lawrence <paullawre...@google.com> > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH v4 3/5] kasan: support alloca() poisoning

e should poison > those too. > > __asan_allocas_unpoison() is just passed the top and bottom of the > dynamic stack area, so unpoisoning is simpler. > > Signed-off-by: Greg Hackmann > Signed-off-by: Paul Lawrence > --- Acked-by: Andrey Ryabinin

Re: [PATCH v4 1/5] kasan: add compiler support for clang

ackmann <ghackm...@google.com> > Signed-off-by: Paul Lawrence <paullawre...@google.com> > --- Acked-by: Andrey Ryabinin <aryabi...@virtuozzo.com>

Re: [PATCH v4 1/5] kasan: add compiler support for clang

: Greg Hackmann > Signed-off-by: Paul Lawrence > --- Acked-by: Andrey Ryabinin

Re: [PATCH v3 3/5] kasan: support alloca() poisoning

On 12/04/2017 07:55 PM, Andrey Ryabinin wrote: > > > On 12/04/2017 07:42 PM, Christoph Hellwig wrote: >> I don't think we are using alloca in kernel mode code, and we shouldn't. >> What do I miss? Is this hidden support for on-stack VLAs? I thought >> w

Re: [PATCH v3 3/5] kasan: support alloca() poisoning

On 12/04/2017 07:55 PM, Andrey Ryabinin wrote: > > > On 12/04/2017 07:42 PM, Christoph Hellwig wrote: >> I don't think we are using alloca in kernel mode code, and we shouldn't. >> What do I miss? Is this hidden support for on-stack VLAs? I thought >> w

Re: [PATCH v3 3/5] kasan: support alloca() poisoning

On 12/04/2017 07:42 PM, Christoph Hellwig wrote: > I don't think we are using alloca in kernel mode code, and we shouldn't. > What do I miss? Is this hidden support for on-stack VLAs? I thought > we'd get rid of them as well. > Yes, this is for on-stack VLA. Last time I checked, we still had

Re: [PATCH v3 3/5] kasan: support alloca() poisoning

On 12/04/2017 07:42 PM, Christoph Hellwig wrote: > I don't think we are using alloca in kernel mode code, and we shouldn't. > What do I miss? Is this hidden support for on-stack VLAs? I thought > we'd get rid of them as well. > Yes, this is for on-stack VLA. Last time I checked, we still had

Re: [PATCH v3 2/5] kasan/Makefile: Support LLVM style asan parameters.

On 12/04/2017 07:20 PM, Paul Lawrence wrote: > > > +   # -fasan-shadow-offset fails without -fsanitize > > +   CFLAGS_KASAN_SHADOW := $(call cc-option, -fsanitize=kernel-address \ > > +                     -fasan-shadow-offset=$(KASAN_SHADOW_OFFSET), \ > > +                     

Re: [PATCH v3 2/5] kasan/Makefile: Support LLVM style asan parameters.

On 12/04/2017 07:20 PM, Paul Lawrence wrote: > > > +   # -fasan-shadow-offset fails without -fsanitize > > +   CFLAGS_KASAN_SHADOW := $(call cc-option, -fsanitize=kernel-address \ > > +                     -fasan-shadow-offset=$(KASAN_SHADOW_OFFSET), \ > > +                     

Re: [PATCH v3 2/5] kasan/Makefile: Support LLVM style asan parameters.

On 12/02/2017 12:36 AM, Paul Lawrence wrote: > Missing: From: Andrey Ryabinin <aryabi...@virtuozzo.com> Please, don't change authorship of the patches. > LLVM doesn't understand GCC-style paramters ("--param asan-foo=bar"), > thus we currently we don't

Re: [PATCH v3 2/5] kasan/Makefile: Support LLVM style asan parameters.

On 12/02/2017 12:36 AM, Paul Lawrence wrote: > Missing: From: Andrey Ryabinin Please, don't change authorship of the patches. > LLVM doesn't understand GCC-style paramters ("--param asan-foo=bar"), > thus we currently we don't use inline/globals/stack instrumentat

Re: [PATCH v2 5/5] kasan: add compiler support for clang

On 11/30/2017 12:50 AM, Paul Lawrence wrote: > For now we can hard-code ASAN ABI level 5, since historical clang builds > can't build the kernel anyway. We also need to emulate gcc's > __SANITIZE_ADDRESS__ flag, or memset() calls won't be instrumented. > > Signed-off-by: Greg Hackmann

Re: [PATCH v2 5/5] kasan: add compiler support for clang

On 11/30/2017 12:50 AM, Paul Lawrence wrote: > For now we can hard-code ASAN ABI level 5, since historical clang builds > can't build the kernel anyway. We also need to emulate gcc's > __SANITIZE_ADDRESS__ flag, or memset() calls won't be instrumented. > > Signed-off-by: Greg Hackmann >

Re: [PATCH v2 4/5] kasan: support LLVM-style asan parameters

didn't add asan-instrument-allocas=1 because it has nothing to do with LLVM-style params support. asan-instrument-allocas should probably be in the patch that adds alloca() support. From: Andrey Ryabinin <aryabi...@virtuozzo.com> Subject: [PATCH] kasan/Makefile: Support LLVM style asan paramete

Re: [PATCH v2 4/5] kasan: support LLVM-style asan parameters

to do with LLVM-style params support. asan-instrument-allocas should probably be in the patch that adds alloca() support. From: Andrey Ryabinin Subject: [PATCH] kasan/Makefile: Support LLVM style asan parameters. LLVM doesn't understand GCC-style paramters ("--param asan-foo=bar"), thus

Re: [ 0.003333] BUG: KASAN: use-after-scope in console_unlock+0x605/0xcc0

On 11/30/2017 11:29 AM, Sergey Senozhatsky wrote: > On (11/30/17 09:16), Dmitry Vyukov wrote: > [..] >>> to be honest, this backtrace hardly makes any sense to me. >>> >>> vprintk_emit() >>> reserve_standard_io_resources() >>> __flush_tlb_all() >>>vprintk_emit() >>>

Re: [ 0.003333] BUG: KASAN: use-after-scope in console_unlock+0x605/0xcc0

On 11/30/2017 11:29 AM, Sergey Senozhatsky wrote: > On (11/30/17 09:16), Dmitry Vyukov wrote: > [..] >>> to be honest, this backtrace hardly makes any sense to me. >>> >>> vprintk_emit() >>> reserve_standard_io_resources() >>> __flush_tlb_all() >>>vprintk_emit() >>>

[PATCH] x86/unwind_guess: Prevent using UNWINDER_GUESS=y with STACKDEPOT=y

roblem. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Reported-by: kernel test robot <xiaolong...@intel.com> Reported-by: Fengguang Wu <fengguang...@intel.com> --- arch/x86/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig.debug b/arch

[PATCH] x86/unwind_guess: Prevent using UNWINDER_GUESS=y with STACKDEPOT=y

roblem. Signed-off-by: Andrey Ryabinin Reported-by: kernel test robot Reported-by: Fengguang Wu --- arch/x86/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index 6293a8768a91..672441c008c7 100644 --- a/arch/x86/Kconfig.debug +++

Re: kasan: false use-after-scope warnings with KCOV

On 11/28/2017 08:52 PM, Dmitry Vyukov wrote: > On Tue, Nov 28, 2017 at 4:24 PM, Mark Rutland wrote: > As a heads-up, I'm seeing a number of what appear to be false-positive > use-after-scope warnings when I enable both KCOV and KASAN (inline or > outline), >

Re: kasan: false use-after-scope warnings with KCOV

On 11/28/2017 08:52 PM, Dmitry Vyukov wrote: > On Tue, Nov 28, 2017 at 4:24 PM, Mark Rutland wrote: > As a heads-up, I'm seeing a number of what appear to be false-positive > use-after-scope warnings when I enable both KCOV and KASAN (inline or > outline), > when using the Linaro

Re: kasan: false use-after-scope warnings with KCOV

On 11/28/2017 03:35 PM, Mark Rutland wrote: > Hi, > > As a heads-up, I'm seeing a number of what appear to be false-positive > use-after-scope warnings when I enable both KCOV and KASAN (inline or > outline), > when using the Linaro 17.08 GCC7.1.1 for arm64. So far I haven't spotted these >

<    1   2   3   4   5   6   7   8   9   10   >