From: Andrey Ryabinin <ryabinin.a.a@gmail.com> To: Dmitry Vyukov <dvyukov@google.com> Cc: syzkaller <syzkaller@googlegroups.com>, Andrew Morton <akpm@linux-foundation.org>, David Drysdale <drysdale@google.com>, Kees Cook <keescook@google.com>, Quentin Casasnovas <quentin.casasnovas@oracle.com>, Sasha Levin <sasha.levin@oracle.com>, Vegard Nossum <vegard.nossum@oracle.com>, LKML <linux-kernel@vger.kernel.org>, Eric Dumazet <edumazet@google.com>, Tavis Ormandy <taviso@google.com>, Bjorn Helgaas <bhelgaas@google.com>, Kostya Serebryany <kcc@google.com>, Alexander Potapenko <glider@google.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2] kernel: add kcov code coverage Date: Mon, 18 Jan 2016 16:34:33 +0300 [thread overview] Message-ID: <CAPAsAGxpntZ-H+SEc3BNfOdS5Ciqn+esXmypD0e3h4oucxdoJw@mail.gmail.com> (raw) In-Reply-To: <CACT4Y+YvL_L9a2dBfoXQ0AKpKmnypfObtt7k97j_i2Qiu=wnQg@mail.gmail.com> 2016-01-15 17:07 GMT+03:00 Dmitry Vyukov <dvyukov@google.com>: >>>> Note that this works only for cache-coherent architectures. >>>> For incoherent arches you'll need to flush_dcache_page() somewhere. >>>> Perhaps it could be done on exit to userspace, since flushing here is >>>> certainly an overkill. >>> >>> I can say that I understand the problem. Does it have to do with the >>> fact that the buffer is shared between kernel and user-space? >>> Current code is OK from the plain multi-threading side, as user must >>> not read buffer concurrently with writing (that would not yield >>> anything useful). >> >> It's not about SMP. >> This problem is about virtually indexed aliasing D-caches and could be >> observed on uniprocessor system. >> You have 3 virtual addresses (user-space, linear mapping and vmalloc) >> mapped to the same physical page. >> With aliasing cache it's possible to have multiple cache-lines >> representing the same physical page. >> So the kernel might not see the update made by userspace and vise >> versa because kernel/userspace use different virtual addresses. >> >> And btw, flush_dcache_page() would be a wrong choice, since kcov_area >> is a vmalloc address, not a linear address. >> So we need something that flushes vmalloc addresses. >> >> Alternatively we could simply mlock that memory and talk to user space >> via get/put_user(). No flush will be required. >> And we will avoid another potential problem - lack of vmalloc address >> space on 32-bits. > > Do you mean that user-space allocates a buffer and passes this buffer > to ioctl(KCOV_INIT); kernel locks this range and then directly writes > to it? > It's one of the ways of doing this. Another possible way is to allocate, mmap and pin pages in kcov_mmap(). > I afraid it becomes prohibitively expensive with put_user/get_user: > https://gist.githubusercontent.com/dvyukov/568f2e4a61afc910f880/raw/540cc071f1d561b9a3f9e50183d681be265af8c3/gistfile1.txt > Right, but it should be better with __get_user/__put_user. > Also, won't it require the same flush since the region is mmaped into > several processes (and process that reads is not the one that setups > the region)? But it's only child process that could inherit kcov mapping from parent, so it's be the same physical->virtual mapping as in parent. > Size of coverage buffer that I currently use is 64K. I hope it is not > a problem for 32-bit archs. > 64K - per process. It's hard to whether this is a real problem or not, since it depends on how many processes collect coverage, size of vmalloc and vmalloc's utilization by the rest of the kernel.
WARNING: multiple messages have this Message-ID (diff)
From: ryabinin.a.a@gmail.com (Andrey Ryabinin) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2] kernel: add kcov code coverage Date: Mon, 18 Jan 2016 16:34:33 +0300 [thread overview] Message-ID: <CAPAsAGxpntZ-H+SEc3BNfOdS5Ciqn+esXmypD0e3h4oucxdoJw@mail.gmail.com> (raw) In-Reply-To: <CACT4Y+YvL_L9a2dBfoXQ0AKpKmnypfObtt7k97j_i2Qiu=wnQg@mail.gmail.com> 2016-01-15 17:07 GMT+03:00 Dmitry Vyukov <dvyukov@google.com>: >>>> Note that this works only for cache-coherent architectures. >>>> For incoherent arches you'll need to flush_dcache_page() somewhere. >>>> Perhaps it could be done on exit to userspace, since flushing here is >>>> certainly an overkill. >>> >>> I can say that I understand the problem. Does it have to do with the >>> fact that the buffer is shared between kernel and user-space? >>> Current code is OK from the plain multi-threading side, as user must >>> not read buffer concurrently with writing (that would not yield >>> anything useful). >> >> It's not about SMP. >> This problem is about virtually indexed aliasing D-caches and could be >> observed on uniprocessor system. >> You have 3 virtual addresses (user-space, linear mapping and vmalloc) >> mapped to the same physical page. >> With aliasing cache it's possible to have multiple cache-lines >> representing the same physical page. >> So the kernel might not see the update made by userspace and vise >> versa because kernel/userspace use different virtual addresses. >> >> And btw, flush_dcache_page() would be a wrong choice, since kcov_area >> is a vmalloc address, not a linear address. >> So we need something that flushes vmalloc addresses. >> >> Alternatively we could simply mlock that memory and talk to user space >> via get/put_user(). No flush will be required. >> And we will avoid another potential problem - lack of vmalloc address >> space on 32-bits. > > Do you mean that user-space allocates a buffer and passes this buffer > to ioctl(KCOV_INIT); kernel locks this range and then directly writes > to it? > It's one of the ways of doing this. Another possible way is to allocate, mmap and pin pages in kcov_mmap(). > I afraid it becomes prohibitively expensive with put_user/get_user: > https://gist.githubusercontent.com/dvyukov/568f2e4a61afc910f880/raw/540cc071f1d561b9a3f9e50183d681be265af8c3/gistfile1.txt > Right, but it should be better with __get_user/__put_user. > Also, won't it require the same flush since the region is mmaped into > several processes (and process that reads is not the one that setups > the region)? But it's only child process that could inherit kcov mapping from parent, so it's be the same physical->virtual mapping as in parent. > Size of coverage buffer that I currently use is 64K. I hope it is not > a problem for 32-bit archs. > 64K - per process. It's hard to whether this is a real problem or not, since it depends on how many processes collect coverage, size of vmalloc and vmalloc's utilization by the rest of the kernel.
next prev parent reply other threads:[~2016-01-18 13:34 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-13 12:48 [PATCH v2] kernel: add kcov code coverage Dmitry Vyukov 2016-01-13 22:31 ` kbuild test robot 2016-01-14 9:03 ` Kirill A. Shutemov 2016-01-14 9:10 ` Dmitry Vyukov 2016-01-14 9:23 ` Kirill A. Shutemov 2016-01-14 12:21 ` Dmitry Vyukov 2016-01-14 12:35 ` Kirill A. Shutemov 2016-01-14 12:49 ` Kirill A. Shutemov 2016-01-14 14:24 ` Dmitry Vyukov 2016-01-14 10:50 ` Andrey Ryabinin 2016-01-14 14:30 ` Dmitry Vyukov 2016-01-15 13:05 ` Andrey Ryabinin 2016-01-15 13:05 ` Andrey Ryabinin 2016-01-15 13:42 ` Will Deacon 2016-01-15 13:42 ` Will Deacon 2016-01-15 14:07 ` Dmitry Vyukov 2016-01-15 14:07 ` Dmitry Vyukov 2016-01-18 13:34 ` Andrey Ryabinin [this message] 2016-01-18 13:34 ` Andrey Ryabinin 2016-01-18 19:31 ` Dmitry Vyukov 2016-01-18 19:31 ` Dmitry Vyukov 2016-01-18 14:13 ` Mark Rutland 2016-01-18 14:13 ` Mark Rutland 2016-01-18 19:44 ` Dmitry Vyukov 2016-01-18 19:44 ` Dmitry Vyukov 2016-01-18 20:09 ` Dmitry Vyukov 2016-01-18 20:09 ` Dmitry Vyukov 2016-01-22 11:55 ` Mark Rutland 2016-01-22 11:55 ` Mark Rutland 2016-01-22 12:15 ` Dmitry Vyukov 2016-01-22 12:15 ` Dmitry Vyukov 2016-01-22 12:52 ` Mark Rutland 2016-01-22 12:52 ` Mark Rutland
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAPAsAGxpntZ-H+SEc3BNfOdS5Ciqn+esXmypD0e3h4oucxdoJw@mail.gmail.com \ --to=ryabinin.a.a@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=bhelgaas@google.com \ --cc=catalin.marinas@arm.com \ --cc=drysdale@google.com \ --cc=dvyukov@google.com \ --cc=edumazet@google.com \ --cc=glider@google.com \ --cc=kcc@google.com \ --cc=keescook@google.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=quentin.casasnovas@oracle.com \ --cc=sasha.levin@oracle.com \ --cc=syzkaller@googlegroups.com \ --cc=taviso@google.com \ --cc=vegard.nossum@oracle.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.