Messages in this thread | | | Date | Mon, 9 Oct 2017 19:37:34 +0100 | From | Mark Rutland <> | Subject | Re: [PATCH v2 1/3] kcov: support comparison operands collection |
| |
On Mon, Oct 09, 2017 at 08:15:10PM +0200, 'Dmitry Vyukov' via syzkaller wrote: > On Mon, Oct 9, 2017 at 5:46 PM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Mon, Oct 09, 2017 at 05:05:19PM +0200, Alexander Potapenko wrote:
> > ... I note that a few places in the kernel use a 128-bit type. Are > > 128-bit comparisons not instrumented? > > Yes, they are not instrumented. > How many are there? Can you give some examples?
From a quick scan, it doesn't looks like there are currently any comparisons.
It's used as a data type in a few places under arm64:
arch/arm64/include/asm/checksum.h: __uint128_t tmp; arch/arm64/include/asm/checksum.h: tmp = *(const __uint128_t *)iph; arch/arm64/include/asm/fpsimd.h: __uint128_t vregs[32]; arch/arm64/include/uapi/asm/ptrace.h: __uint128_t vregs[32]; arch/arm64/include/uapi/asm/sigcontext.h: __uint128_t vregs[32]; arch/arm64/kernel/signal32.c: __uint128_t raw; arch/arm64/kvm/guest.c: __uint128_t tmp;
[...]
> >> + area = t->kcov_area; > >> + /* The first 64-bit word is the number of subsequent PCs. */ > >> + pos = READ_ONCE(area[0]) + 1; > >> + if (likely(pos < t->kcov_size)) { > >> + area[pos] = ip; > >> + WRITE_ONCE(area[0], pos); > > > > Not a new problem, but if the area for one thread is mmap'd, and read by > > another thread, these two writes could be seen out-of-order, since we > > don't have an smp_wmb() between them. > > > > I guess Syzkaller doesn't read the mmap'd kcov file from another thread? > > > Yes, that's the intention. If you read coverage from another thread, > you can't know coverage from what exactly you read. So the usage > pattern is: > > reset coverage; > do something; > read coverage;
Ok. I guess without a use-case for reading this from another thread it doesn't really matter.
Thanks, Mark.
| |