Re: [PATCH] [v2] kasan: avoid -Wmaybe-uninitialized warning

On 07/25/2017 10:17 AM, Arnd Bergmann wrote: > On Mon, Jul 24, 2017 at 1:35 PM, Alexander Potapenko > wrote: >> On Fri, Jul 21, 2017 at 11:02 PM, Arnd Bergmann wrote: > >>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c >>> index 04bb1d3eb9ec..28fb222ab149 100644 >>> ---

Re: [PATCH] x86/mm/dump_pagetables: Speed up page tables dump for CONFIG_KASAN=y

On 07/24/2017 06:37 PM, Kirill A. Shutemov wrote: > On Mon, Jul 24, 2017 at 06:25:58PM +0300, Andrey Ryabinin wrote: >> KASAN fills kernel page tables with repeated values to map several >> TBs of the virtual memory to the single kasan_zero_page: >> kasan_zero_p4d -&g

Re: [PATCH] x86/mm/dump_pagetables: Speed up page tables dump for CONFIG_KASAN=y

On 07/24/2017 06:37 PM, Kirill A. Shutemov wrote: > On Mon, Jul 24, 2017 at 06:25:58PM +0300, Andrey Ryabinin wrote: >> KASAN fills kernel page tables with repeated values to map several >> TBs of the virtual memory to the single kasan_zero_page: >> kasan_zero_p4d -&g

[PATCH] x86/mm/dump_pagetables: Speed up page tables dump for CONFIG_KASAN=y

0.054s Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- arch/x86/mm/dump_pagetables.c | 64 +++ 1 file changed, 41 insertions(+), 23 deletions(-) diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c index b371ab68f2d4..5e3ac6

[PATCH] x86/mm/dump_pagetables: Speed up page tables dump for CONFIG_KASAN=y

0.054s Signed-off-by: Andrey Ryabinin --- arch/x86/mm/dump_pagetables.c | 64 +++ 1 file changed, 41 insertions(+), 23 deletions(-) diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c index b371ab68f2d4..5e3ac6fe6c9e 100644 --- a/arch/x86/mm

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/24/2017 03:13 PM, Kirill A. Shutemov wrote: > On Thu, Jul 13, 2017 at 05:19:22PM +0300, Andrey Ryabinin wrote: >>>> https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?h=la57/boot-switching/v2=13327fec85ffe95d9c8a3f57ba174bf5d5c1fb01 >>>>

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/24/2017 03:13 PM, Kirill A. Shutemov wrote: > On Thu, Jul 13, 2017 at 05:19:22PM +0300, Andrey Ryabinin wrote: >>>> https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?h=la57/boot-switching/v2=13327fec85ffe95d9c8a3f57ba174bf5d5c1fb01 >>>>

Re: WARN_ON_ONCE(work > weight) in napi_poll()

On 07/18/2017 09:47 AM, Ryan Hsu wrote: > On 07/11/2017 06:19 PM, Igor Mitsyanko wrote: > >> On 07/11/2017 10:28 AM, Andrey Ryabinin wrote: >>> >>> It gave me this: >>> >>> [118648.825347] #1 quota too big 72 64 16 >>> [11

Re: WARN_ON_ONCE(work > weight) in napi_poll()

On 07/18/2017 09:47 AM, Ryan Hsu wrote: > On 07/11/2017 06:19 PM, Igor Mitsyanko wrote: > >> On 07/11/2017 10:28 AM, Andrey Ryabinin wrote: >>> >>> It gave me this: >>> >>> [118648.825347] #1 quota too big 72 64 16 >>> [11

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On 07/20/2017 11:56 PM, Josh Poimboeuf wrote: > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote: >> FWIW bellow is my understanding of what's going on. >> >> It seems clang treats local named register almost the same as ordinary >> local variab

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

On 07/20/2017 11:56 PM, Josh Poimboeuf wrote: > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote: >> FWIW bellow is my understanding of what's going on. >> >> It seems clang treats local named register almost the same as ordinary >> local variab

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

2017-07-20 18:18 GMT+03:00 Josh Poimboeuf <jpoim...@redhat.com>: > On Thu, Jul 20, 2017 at 01:01:39PM +0300, Andrey Ryabinin wrote: >> 2017-07-19 20:46 GMT+03:00 Josh Poimboeuf <jpoim...@redhat.com>: >> >> > >> > After doing some testing, I don't think

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

2017-07-20 18:18 GMT+03:00 Josh Poimboeuf : > On Thu, Jul 20, 2017 at 01:01:39PM +0300, Andrey Ryabinin wrote: >> 2017-07-19 20:46 GMT+03:00 Josh Poimboeuf : >> >> > >> > After doing some testing, I don't think this approach is going to work >> > after al

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

2017-07-19 20:46 GMT+03:00 Josh Poimboeuf : > > After doing some testing, I don't think this approach is going to work > after all. In addition to forcing the stack frame, it also causes GCC > to add an unnecessary extra instruction to the epilogue of each affected >

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

2017-07-19 20:46 GMT+03:00 Josh Poimboeuf : > > After doing some testing, I don't think this approach is going to work > after all. In addition to forcing the stack frame, it also causes GCC > to add an unnecessary extra instruction to the epilogue of each affected > function: > > lea

Re: [PATCH] lib/strscpy: avoid KASAN false positive

On 07/19/2017 12:31 AM, Andrey Ryabinin wrote: > On 07/18/2017 11:26 PM, Linus Torvalds wrote: >> On Tue, Jul 18, 2017 at 1:15 PM, Andrey Ryabinin >> <aryabi...@virtuozzo.com> wrote: >>> >>> No, it does warn about valid users. The report that Dave posted

Re: [PATCH] lib/strscpy: avoid KASAN false positive

On 07/19/2017 12:31 AM, Andrey Ryabinin wrote: > On 07/18/2017 11:26 PM, Linus Torvalds wrote: >> On Tue, Jul 18, 2017 at 1:15 PM, Andrey Ryabinin >> wrote: >>> >>> No, it does warn about valid users. The report that Dave posted wasn't >>> about wrong

Re: [PATCH] lib/strscpy: avoid KASAN false positive

On 07/18/2017 11:26 PM, Linus Torvalds wrote: > On Tue, Jul 18, 2017 at 1:15 PM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> No, it does warn about valid users. The report that Dave posted wasn't about >> wrong strscpy() usage >> it was about

Re: [PATCH] lib/strscpy: avoid KASAN false positive

On 07/18/2017 11:26 PM, Linus Torvalds wrote: > On Tue, Jul 18, 2017 at 1:15 PM, Andrey Ryabinin > wrote: >> >> No, it does warn about valid users. The report that Dave posted wasn't about >> wrong strscpy() usage >> it was about reading 8-bytes from 5-bytes

Re: [PATCH] lib/strscpy: avoid KASAN false positive

On 07/18/2017 08:22 PM, Linus Torvalds wrote: > On Tue, Jul 18, 2017 at 10:15 AM, Andrey Ryabinin > <aryabi...@virtuozzo.com> wrote: >> >> + /* >> +* KASAN won't be happy about word-at-a-time >> +* o

Re: [PATCH] lib/strscpy: avoid KASAN false positive

On 07/18/2017 08:22 PM, Linus Torvalds wrote: > On Tue, Jul 18, 2017 at 10:15 AM, Andrey Ryabinin > wrote: >> >> + /* >> +* KASAN won't be happy about word-at-a-time >> +* optimistic reads, so let's avoid them. >> +*/ &g

[PATCH] lib/strscpy: avoid KASAN false positive

that so it will complain. Let's just fallback to the byte-at-a-time reads under CONFIG_KASAN=y to avoid false-positives. Reported-by: Dave Jones <da...@codemonkey.org.uk> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- lib/string.c | 7 +++ 1 file changed, 7 inserti

[PATCH] lib/strscpy: avoid KASAN false positive

that so it will complain. Let's just fallback to the byte-at-a-time reads under CONFIG_KASAN=y to avoid false-positives. Reported-by: Dave Jones Signed-off-by: Andrey Ryabinin --- lib/string.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/lib/string.c b/lib/string.c index ebbb99c775bd

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

On 07/14/2017 10:05 PM, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 7:25 AM, Dave Jones wrote: >> On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote: >> > >> > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1 >> >> Since this

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

On 07/14/2017 10:05 PM, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 7:25 AM, Dave Jones wrote: >> On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote: >> > >> > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1 >> >> Since this landed, I'm seeing this

Re: [PATCH 1/4] kasan: support alloca() poisoning

On 07/14/2017 01:49 AM, Greg Hackmann wrote: > On 07/10/2017 03:30 AM, Andrey Ryabinin wrote: >> gcc now supports this too. So I think this patch should enable it. >> It's off by default so you'll have to add --param asan-instrument-allocas=1 >> into cflags >>

Re: [PATCH 1/4] kasan: support alloca() poisoning

On 07/14/2017 01:49 AM, Greg Hackmann wrote: > On 07/10/2017 03:30 AM, Andrey Ryabinin wrote: >> gcc now supports this too. So I think this patch should enable it. >> It's off by default so you'll have to add --param asan-instrument-allocas=1 >> into cflags >>

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/13/2017 05:15 PM, Kirill A. Shutemov wrote: >> >> Hm. I don't see this: >> >> ... >> [0.247532] 0xff9e9380-0xff9f 04G >>p4d >> [0.247733] 0xff9f-0x 24P >>

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/13/2017 05:15 PM, Kirill A. Shutemov wrote: >> >> Hm. I don't see this: >> >> ... >> [0.247532] 0xff9e9380-0xff9f 04G >>p4d >> [0.247733] 0xff9f-0x 24P >>

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 10:05 PM, Kirill A. Shutemov wrote: >>> Can use your Signed-off-by for a [cleaned up version of your] patch? >> >> Sure. > > Another KASAN-releated issue: dumping page tables for KASAN shadow memory > region takes unreasonable time due to kasan_zero_p?? mapped there. > > The patch

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 10:05 PM, Kirill A. Shutemov wrote: >>> Can use your Signed-off-by for a [cleaned up version of your] patch? >> >> Sure. > > Another KASAN-releated issue: dumping page tables for KASAN shadow memory > region takes unreasonable time due to kasan_zero_p?? mapped there. > > The patch

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 08:03 PM, Kirill A. Shutemov wrote: > On Tue, Jul 11, 2017 at 07:45:48PM +0300, Andrey Ryabinin wrote: >> On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: >>> >>> I reproduced this, and this is kasan bug: >>> >>>│0x8486

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 08:03 PM, Kirill A. Shutemov wrote: > On Tue, Jul 11, 2017 at 07:45:48PM +0300, Andrey Ryabinin wrote: >> On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: >>> >>> I reproduced this, and this is kasan bug: >>> >>>│0x848

Re: WARN_ON_ONCE(work > weight) in napi_poll()

On 07/11/2017 12:24 AM, Ryan Hsu wrote: > On 07/04/2017 08:59 AM, Andrey Ryabinin wrote: > >> On 07/04/2017 04:49 PM, Kalle Valo wrote: >>> Andrey Ryabinin <aryabi...@virtuozzo.com> writes: >>> >>>> I occasionally hit WARN_ON_ONCE(work > weight

Re: WARN_ON_ONCE(work > weight) in napi_poll()

On 07/11/2017 12:24 AM, Ryan Hsu wrote: > On 07/04/2017 08:59 AM, Andrey Ryabinin wrote: > >> On 07/04/2017 04:49 PM, Kalle Valo wrote: >>> Andrey Ryabinin writes: >>> >>>> I occasionally hit WARN_ON_ONCE(work > weight); in

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: > > I reproduced this, and this is kasan bug: > >│0x84864897 <x86_early_init_platform_quirks+5> mov > $0x83f1d0b8,%rdi >│0x8486489e <x86_early_init_platform_quirks+12> mova

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: > > I reproduced this, and this is kasan bug: > >│0x84864897mov > $0x83f1d0b8,%rdi >│0x8486489e movabs > $0xdc00,%rax >│0x848648a8 push %rbp >

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 06:06 PM, Andy Lutomirski wrote: > On Tue, Jul 11, 2017 at 3:35 AM, Kirill A. Shutemov > wrote: >> On Mon, Jul 10, 2017 at 05:30:38PM -0700, Andy Lutomirski wrote: >>> On Mon, Jul 10, 2017 at 2:24 PM, Kirill A. Shutemov >>> wrote:

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 06:06 PM, Andy Lutomirski wrote: > On Tue, Jul 11, 2017 at 3:35 AM, Kirill A. Shutemov > wrote: >> On Mon, Jul 10, 2017 at 05:30:38PM -0700, Andy Lutomirski wrote: >>> On Mon, Jul 10, 2017 at 2:24 PM, Kirill A. Shutemov >>> wrote: On Mon, Jul 10, 2017 at 01:07:13PM -0700,

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/10/2017 03:33 PM, Kirill A. Shutemov wrote: > > [Sorry for loong delay.] > > The patch works for me for legacy boot. But it breaks EFI boot with > 5-level paging. And I struggle to understand why. > > What I see is many page faults at mm/kasan/kasan.c:758 -- >

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/10/2017 03:33 PM, Kirill A. Shutemov wrote: > > [Sorry for loong delay.] > > The patch works for me for legacy boot. But it breaks EFI boot with > 5-level paging. And I struggle to understand why. > > What I see is many page faults at mm/kasan/kasan.c:758 -- >

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

On 07/07/2017 01:01 AM, Greg Hackmann 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 4/4] kasan: add compiler support for clang

On 07/07/2017 01:01 AM, Greg Hackmann 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 2/4] kasan: added functions for unpoisoning stack variables

On 07/07/2017 01:01 AM, Greg Hackmann wrote: > From: Alexander Potapenko > > As a code-size optimization, LLVM builds since r279383 may > bulk-manipulate the shadow region when (un)poisoning large memory > blocks. This requires new callbacks that simply do an uninstrumented

Re: [PATCH 2/4] kasan: added functions for unpoisoning stack variables

On 07/07/2017 01:01 AM, Greg Hackmann wrote: > From: Alexander Potapenko > > As a code-size optimization, LLVM builds since r279383 may > bulk-manipulate the shadow region when (un)poisoning large memory > blocks. This requires new callbacks that simply do an uninstrumented > memset(). > >

Re: [PATCH 1/4] kasan: support alloca() poisoning

On 07/07/2017 01:01 AM, Greg Hackmann wrote: > clang's AddressSanitizer implementation adds redzones on either side of > alloca()ed buffers. These redzones are 32-byte aligned and at least 32 > bytes long. gcc now supports this too. So I think this patch should enable it. It's off by default so

Re: [PATCH 1/4] kasan: support alloca() poisoning

On 07/07/2017 01:01 AM, Greg Hackmann wrote: > clang's AddressSanitizer implementation adds redzones on either side of > alloca()ed buffers. These redzones are 32-byte aligned and at least 32 > bytes long. gcc now supports this too. So I think this patch should enable it. It's off by default so

Re: [GIT PULL] gcc-plugins updates for v4.13-rc1

2017-07-06 0:56 GMT+03:00 Linus Torvalds : > On Wed, Jul 5, 2017 at 2:48 PM, Arnd Bergmann wrote: >> >> This particular example should be handled by >> scripts/gcc-plugins/structleak_plugin.c, right? > > .. probably. But we have a ton of other uses

Re: [GIT PULL] gcc-plugins updates for v4.13-rc1

2017-07-06 0:56 GMT+03:00 Linus Torvalds : > On Wed, Jul 5, 2017 at 2:48 PM, Arnd Bergmann wrote: >> >> This particular example should be handled by >> scripts/gcc-plugins/structleak_plugin.c, right? > > .. probably. But we have a ton of other uses that just pass in > "result" pointers (not

Re: WARN_ON_ONCE(work > weight) in napi_poll()

On 07/04/2017 04:49 PM, Kalle Valo wrote: > Andrey Ryabinin <aryabi...@virtuozzo.com> writes: > >> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a >> laptop with ath10k card. >> >> >> [37207.593370] [ cut here ]

Re: WARN_ON_ONCE(work > weight) in napi_poll()

On 07/04/2017 04:49 PM, Kalle Valo wrote: > Andrey Ryabinin writes: > >> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a >> laptop with ath10k card. >> >> >> [37207.593370] [ cut here ] >> [37207.593380] WAR

WARN_ON_ONCE(work > weight) in napi_poll()

I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a laptop with ath10k card. [37207.593370] [ cut here ] [37207.593380] WARNING: CPU: 0 PID: 7 at ../net/core/dev.c:5274 net_rx_action+0x258/0x360 [37207.593381] Modules linked in: snd_hda_codec_realtek

WARN_ON_ONCE(work > weight) in napi_poll()

I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a laptop with ath10k card. [37207.593370] [ cut here ] [37207.593380] WARNING: CPU: 0 PID: 7 at ../net/core/dev.c:5274 net_rx_action+0x258/0x360 [37207.593381] Modules linked in: snd_hda_codec_realtek

Re: [PATCH] mm/memory-hotplug: Switch locking to a percpu rwsem

On 06/30/2017 04:00 PM, Thomas Gleixner wrote: > On Fri, 30 Jun 2017, Andrey Ryabinin wrote: >> On 06/30/2017 01:15 PM, Thomas Gleixner wrote: >>> On Fri, 30 Jun 2017, Michal Hocko wrote: >>>> So I like this simplification a lot! Even if we can get rid of th

Re: [PATCH] mm/memory-hotplug: Switch locking to a percpu rwsem

On 06/30/2017 04:00 PM, Thomas Gleixner wrote: > On Fri, 30 Jun 2017, Andrey Ryabinin wrote: >> On 06/30/2017 01:15 PM, Thomas Gleixner wrote: >>> On Fri, 30 Jun 2017, Michal Hocko wrote: >>>> So I like this simplification a lot! Even if we can get rid of th

Re: [PATCH] mm/memory-hotplug: Switch locking to a percpu rwsem

On 06/30/2017 01:15 PM, Thomas Gleixner wrote: > On Fri, 30 Jun 2017, Michal Hocko wrote: >> So I like this simplification a lot! Even if we can get rid of the >> stop_machine eventually this patch would be an improvement. A short >> comment on why the per-cpu semaphore over the regular one is

Re: [PATCH] mm/memory-hotplug: Switch locking to a percpu rwsem

On 06/30/2017 01:15 PM, Thomas Gleixner wrote: > On Fri, 30 Jun 2017, Michal Hocko wrote: >> So I like this simplification a lot! Even if we can get rid of the >> stop_machine eventually this patch would be an improvement. A short >> comment on why the per-cpu semaphore over the regular one is

cpu_hotplug_lock.rw_sem + memhotplug = possible deadlock

On linux -next, after onlining hotpluged memory: == WARNING: possible circular locking dependency detected 4.12.0-rc6-next-20170626+ #761 Not tainted -- kworker/u8:0/5 is trying to acquire

cpu_hotplug_lock.rw_sem + memhotplug = possible deadlock

On linux -next, after onlining hotpluged memory: == WARNING: possible circular locking dependency detected 4.12.0-rc6-next-20170626+ #761 Not tainted -- kworker/u8:0/5 is trying to acquire

Re: [PATCH] locking/atomics: don't alias ____ptr

On 06/28/2017 04:20 PM, Thomas Gleixner wrote: > On Wed, 28 Jun 2017, Sebastian Andrzej Siewior wrote: >> On 2017-06-28 14:15:18 [+0300], Andrey Ryabinin wrote: >>> The main problem here is that arch_cmpxchg64_local() calls cmpxhg_local() >>> instead of using arch_

Re: [PATCH] locking/atomics: don't alias ____ptr

On 06/28/2017 04:20 PM, Thomas Gleixner wrote: > On Wed, 28 Jun 2017, Sebastian Andrzej Siewior wrote: >> On 2017-06-28 14:15:18 [+0300], Andrey Ryabinin wrote: >>> The main problem here is that arch_cmpxchg64_local() calls cmpxhg_local() >>> instead of using arch_

Re: [PATCH] locking/atomics: don't alias ____ptr

On 06/28/2017 01:16 PM, Dmitry Vyukov wrote: > On Wed, Jun 28, 2017 at 12:02 PM, Sebastian Andrzej Siewior > wrote: >> Trying to boot tip/master resulted in: >> |DMAR: dmar0: Using Queued invalidation >> |DMAR: dmar1: Using Queued invalidation >> |DMAR: Setting RMRR: >>

Re: [PATCH] locking/atomics: don't alias ____ptr

On 06/28/2017 01:16 PM, Dmitry Vyukov wrote: > On Wed, Jun 28, 2017 at 12:02 PM, Sebastian Andrzej Siewior > wrote: >> Trying to boot tip/master resulted in: >> |DMAR: dmar0: Using Queued invalidation >> |DMAR: dmar1: Using Queued invalidation >> |DMAR: Setting RMRR: >> |DMAR: Setting identity

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

On 06/16/2017 06:41 PM, Arnd Bergmann wrote: > On Fri, Jun 16, 2017 at 3:02 PM, Greg Kroah-Hartman > wrote: >> On Fri, Jun 16, 2017 at 02:01:57PM +0200, Arnd Bergmann wrote: >>> On Thu, Jun 15, 2017 at 6:53 AM, Greg Kroah-Hartman >>> wrote:

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

On 06/16/2017 06:41 PM, Arnd Bergmann wrote: > On Fri, Jun 16, 2017 at 3:02 PM, Greg Kroah-Hartman > wrote: >> On Fri, Jun 16, 2017 at 02:01:57PM +0200, Arnd Bergmann wrote: >>> On Thu, Jun 15, 2017 at 6:53 AM, Greg Kroah-Hartman >>> wrote: On Thu, Jun 15, 2017 at 06:52:21AM +0200, Greg

Re: [PATCH v3 7/7] asm-generic, x86: add comments for atomic instrumentation

utl...@arm.com> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: kasan-..

Re: [PATCH v3 7/7] asm-generic, x86: add comments for atomic instrumentation

ill Deacon > Cc: Andrew Morton > Cc: Andrey Ryabinin > Cc: Ingo Molnar > Cc: kasan-...@googlegroups.com > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > Cc: x...@kernel.org > --- > arch/x86/include/asm/atomic.h | 7 ++

Re: [PATCH v3 6/7] asm-generic: add KASAN instrumentation to atomic operations

et...@infradead.org> > Cc: Will Deacon <will.dea...@arm.com>, > Cc: Andrew Morton <a...@linux-foundation.org>, > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com>, > Cc: Ingo Molnar <mi...@redhat.com>, > Cc: kasan-...@googlegroups.com > Cc: linux...@kvack.org

Re: [PATCH v3 6/7] asm-generic: add KASAN instrumentation to atomic operations

ce decrement is the last access to an > object and a good candidate for a racy use-after-free. > > Add manual KASAN checks to atomic operations. > > Signed-off-by: Dmitry Vyukov > Cc: Mark Rutland > Cc: Peter Zijlstra > Cc: Will Deacon , > Cc: Andrew Morton , > Cc:

Re: [PATCH v3 5/7] kasan: allow kasan_check_read/write() to accept pointers to volatiles

ry Vyukov <dvyu...@google.com> > Cc: Mark Rutland <mark.rutl...@arm.com> > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: Peter Zijlstra <pet...@infradea

Re: [PATCH v3 5/7] kasan: allow kasan_check_read/write() to accept pointers to volatiles

ry Vyukov > Cc: Mark Rutland > Cc: Andrey Ryabinin > Cc: Thomas Gleixner > Cc: "H. Peter Anvin" > Cc: Peter Zijlstra > Cc: Andrew Morton > Cc: linux-kernel@vger.kernel.org > Cc: x...@kernel.org > Cc: linux...@kvack.org > Cc: kasan-...@googlegroups.com Reviewed-by: Andrey Ryabinin

Re: [PATCH v3 4/7] x86: switch atomic.h to use atomic-instrumented.h

> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: kasan-...@google

Re: [PATCH v3 4/7] x86: switch atomic.h to use atomic-instrumented.h

gt; Cc: Andrew Morton > Cc: Andrey Ryabinin > Cc: Ingo Molnar > Cc: kasan-...@googlegroups.com > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > Cc: x...@kernel.org > > --- > -static __always_inline void atomic_set(atomic_t *v, int i) > +stati

Re: [PATCH v3 3/7] asm-generic: add atomic-instrumented.h

ra <pet...@infradead.org> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: kasan-...@googlegroups.com > Cc: linux...@kvac

Re: [PATCH v3 3/7] asm-generic: add atomic-instrumented.h

On 06/06/2017 01:11 PM, Dmitry Vyukov wrote: > The new header allows to wrap per-arch atomic operations > and add common functionality to all of them. > > Signed-off-by: Dmitry Vyukov > Cc: Mark Rutland > Cc: Peter Zijlstra > Cc: Will Deacon > Cc: Andrew Morton >

Re: [PATCH v3 2/7] x86: use s64* for old arg of atomic64_try_cmpxchg()

> Change type of old arg to s64*. > > Signed-off-by: Dmitry Vyukov <dvyu...@google.com> > Cc: Mark Rutland <mark.rutl...@arm.com> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Andrew Morton <a...@linux-found

Re: [PATCH v3 2/7] x86: use s64* for old arg of atomic64_try_cmpxchg()

> Change type of old arg to s64*. > > Signed-off-by: Dmitry Vyukov > Cc: Mark Rutland > Cc: Peter Zijlstra > Cc: Will Deacon > Cc: Andrew Morton > Cc: Andrey Ryabinin > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: kasan-...@googlegroups.com > Cc:

Re: [PATCH v3 1/7] x86: un-macro-ify atomic ops implementation

nel.org> > Cc: Mark Rutland <mark.rutl...@arm.com> > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Andrew Mor

Re: [PATCH v3 1/7] x86: un-macro-ify atomic ops implementation

On 06/06/2017 01:11 PM, Dmitry Vyukov wrote: > CPP turns perfectly readable code into an unreadable, > unmaintainable mess. Ingo suggested to write them out as-is. > Do this. > > Signed-off-by: Dmitry Vyukov > Suggested-by: Ingo Molnar > Cc: Mark Rutland > Cc: Andre

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 06/08/2017 05:40 AM, Joonsoo Kim wrote: >>> >>> I don't understand why we trying to invent some hacky/complex schemes when >>> we already have >>> a simple one - scaling shadow to 1/32. It's easy to implement and should be >>> more performant comparing >>> to suggested schemes. >> >> >> If

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 06/08/2017 05:40 AM, Joonsoo Kim wrote: >>> >>> I don't understand why we trying to invent some hacky/complex schemes when >>> we already have >>> a simple one - scaling shadow to 1/32. It's easy to implement and should be >>> more performant comparing >>> to suggested schemes. >> >> >> If

Re: [PATCHv6 06/10] x86/mm: Add sync_global_pgds() for configuration with 5-level paging

On 05/24/2017 12:54 PM, Kirill A. Shutemov wrote: > This basically restores slightly modified version of original > sync_global_pgds() which we had before folded p4d was introduced. > > The only modification is protection against 'addr' overflow. > > Signed-off-by: Kirill A. Shutemov

Re: [PATCHv6 06/10] x86/mm: Add sync_global_pgds() for configuration with 5-level paging

On 05/24/2017 12:54 PM, Kirill A. Shutemov wrote: > This basically restores slightly modified version of original > sync_global_pgds() which we had before folded p4d was introduced. > > The only modification is protection against 'addr' overflow. > > Signed-off-by: Kirill A. Shutemov > --- >

Re: [PATCH 3/4] arm64/kasan: don't allocate extra shadow memory

On 06/01/2017 07:59 PM, Andrey Ryabinin wrote: > > > On 06/01/2017 07:52 PM, Mark Rutland wrote: >> On Thu, Jun 01, 2017 at 06:45:32PM +0200, Dmitry Vyukov wrote: >>> On Thu, Jun 1, 2017 at 6:34 PM, Mark Rutland <mark.rutl...@arm.com> wrote: >>>>

Re: [PATCH 3/4] arm64/kasan: don't allocate extra shadow memory

On 06/01/2017 07:59 PM, Andrey Ryabinin wrote: > > > On 06/01/2017 07:52 PM, Mark Rutland wrote: >> On Thu, Jun 01, 2017 at 06:45:32PM +0200, Dmitry Vyukov wrote: >>> On Thu, Jun 1, 2017 at 6:34 PM, Mark Rutland wrote: >>>> On Thu, Jun 01, 2017 at 07:

Re: [PATCH 3/4] arm64/kasan: don't allocate extra shadow memory

On 06/01/2017 07:52 PM, Mark Rutland wrote: > On Thu, Jun 01, 2017 at 06:45:32PM +0200, Dmitry Vyukov wrote: >> On Thu, Jun 1, 2017 at 6:34 PM, Mark Rutland <mark.rutl...@arm.com> wrote: >>> On Thu, Jun 01, 2017 at 07:23:37PM +0300, Andrey Ryabinin wrote: >>&g

Re: [PATCH 3/4] arm64/kasan: don't allocate extra shadow memory

On 06/01/2017 07:52 PM, Mark Rutland wrote: > On Thu, Jun 01, 2017 at 06:45:32PM +0200, Dmitry Vyukov wrote: >> On Thu, Jun 1, 2017 at 6:34 PM, Mark Rutland wrote: >>> On Thu, Jun 01, 2017 at 07:23:37PM +0300, Andrey Ryabinin wrote: >>>> We used to read seve

[PATCH 2/4] x86/kasan: don't allocate extra shadow memory

. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: x...@kernel.org --- arch/x86/mm/kasan_init_64.c | 7 +-- 1 file changed, 1 insertion(+),

[PATCH 3/4] arm64/kasan: don't allocate extra shadow memory

. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: Catalin Marinas <catalin.mari...@arm.com> Cc: Will Deacon <will.dea...@arm.com> Cc: linux-arm-ker...@lists.infradead.org --- arch/arm64/mm/kasan_init.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --g

[PATCH 2/4] x86/kasan: don't allocate extra shadow memory

. Signed-off-by: Andrey Ryabinin Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org --- arch/x86/mm/kasan_init_64.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c index 0c

[PATCH 3/4] arm64/kasan: don't allocate extra shadow memory

. Signed-off-by: Andrey Ryabinin Cc: Catalin Marinas Cc: Will Deacon Cc: linux-arm-ker...@lists.infradead.org --- arch/arm64/mm/kasan_init.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c index 687a358a3733

[PATCH 4/4] mm/kasan: Add support for memory hotplug

after the memory offlined. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/Kconfig | 1 - mm/kasan/kasan.c | 40 +++- 2 files changed, 35 insertions(+), 6 deletions(-) diff --git a/mm/Kconfig b/mm/Kconfig index f1fbde17d45d..c8df94

[PATCH 4/4] mm/kasan: Add support for memory hotplug

after the memory offlined. Signed-off-by: Andrey Ryabinin --- mm/Kconfig | 1 - mm/kasan/kasan.c | 40 +++- 2 files changed, 35 insertions(+), 6 deletions(-) diff --git a/mm/Kconfig b/mm/Kconfig index f1fbde17d45d..c8df94059974 100644 --- a/mm/Kconfig

[PATCH 1/4] mm/kasan: get rid of speculative shadow checks

degradation with this patch. So these speculative loads is just a pain with no gain, let's remove them. Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> --- mm/kasan/kasan.c | 98 +--- 1 file changed, 16 insertions(+), 82 del

[PATCH 1/4] mm/kasan: get rid of speculative shadow checks

degradation with this patch. So these speculative loads is just a pain with no gain, let's remove them. Signed-off-by: Andrey Ryabinin --- mm/kasan/kasan.c | 98 +--- 1 file changed, 16 insertions(+), 82 deletions(-) diff --git a/mm/kasan

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 05/29/2017 03:46 PM, Andrey Ryabinin wrote: > On 05/29/2017 02:45 PM, Andrey Ryabinin wrote: >>>>>> Looks like KASAN will be a problem for boot-time paging mode switching. >>>>>> It wants to know CONFIG_KASAN_SHADOW_OFFSET at compile-time to

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 05/29/2017 03:46 PM, Andrey Ryabinin wrote: > On 05/29/2017 02:45 PM, Andrey Ryabinin wrote: >>>>>> Looks like KASAN will be a problem for boot-time paging mode switching. >>>>>> It wants to know CONFIG_KASAN_SHADOW_OFFSET at compile-time to

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 05/31/2017 08:50 AM, Joonsoo Kim wrote: >>> But the main win as I see it is that that's basically complete support >>> for 32-bit arches. People do ask about arm32 support: >>> https://groups.google.com/d/msg/kasan-dev/Sk6BsSPMRRc/Gqh4oD_wAAAJ >>>

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 05/31/2017 08:50 AM, Joonsoo Kim wrote: >>> But the main win as I see it is that that's basically complete support >>> for 32-bit arches. People do ask about arm32 support: >>> https://groups.google.com/d/msg/kasan-dev/Sk6BsSPMRRc/Gqh4oD_wAAAJ >>>

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On 05/29/2017 06:29 PM, Dmitry Vyukov wrote: > Joonsoo, > > I guess mine (and Andrey's) main concern is the amount of additional > complexity (I am still struggling to understand how it all works) and > more arch-dependent code in exchange for moderate memory win. > > Joonsoo, Andrey, > > I

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