Lines Matching refs:that
25 is a dynamic checker that detects and warns about some uses of uninitialized
29 difference between memcheck and kmemcheck is that memcheck works for userspace
33 programmer errors that the compiler is not able to find through static
36 Enabling kmemcheck on a kernel will probably slow it down to the extent that
60 Without this, gcc will use certain optimizations that usually lead to
77 function at the beginning of every function. This means that when the
80 modifies memory that was tracked by kmemcheck, the result is an
147 will get lost in that way instead. Try setting this to 10 or so on
158 bytes that will be saved. So if you pick for example 5 here, kmemcheck
166 This option (when enabled) works around certain GCC optimizations that
176 This option silences warnings that would be generated for bit-field
203 kmemcheck in such a way that the slab caches which are under SLUB debugging
204 will not be tracked by kmemcheck. In order to ensure that this doesn't happen
220 positive warnings to appear. Therefore, try not to use this. If you find that
261 bit) value. This will help us pinpoint exactly which instruction that caused
274 be the vmlinux of the kernel that produced the warning in the first place! If
285 In this case, it's the caller of memcpy() that is interesting, and it can be
321 Here, it is &first->info that is being passed on to copy_siginfo(). The
334 Now we need to follow the "pending" pointer, since that is being passed on to
352 Remember that since these addresses were found on the stack and not as the
379 that executes just before 446. Here we see that what we are looking for is
382 Our next task is now to figure out which function that puts items on this
393 and find that this is indeed where items are being added to the list:
453 We see that this function initializes q->list, q->flags, and q->user. It seems
454 that now is the time to look at the definition of "struct sigqueue", e.g.:
463 And, you might remember, it was a memcpy() on &first->info that caused the
464 warning, so this makes perfect sense. It also seems reasonable to assume that
465 it is the caller of __sigqueue_alloc() that has the responsibility of filling
478 &first->info. Just beware that the start of this dump is NOT the start of the
493 that, we'll need the RIP address again:
516 As expected, it's the "rep movsl" instruction from the memcpy() that causes
517 the warning. We know about REP MOVSL that it uses the register RCX to count
524 By looking at the disassembly, we also see that %ecx is being loaded with the
526 that this is the number of iterations, not bytes. And since this is a "long"
528 that the uninitialized value was encountered at 4 * (0xc - 0x9) = 12 bytes
531 We can now try to figure out which field of the "struct siginfo" that was not
544 On 64-bit, the int is 4 bytes long, so it must the union member that has
552 Actually, it seems that the union member is located at offset 0x10 -- which
553 means that gcc has inserted 4 bytes of padding between the members si_code
566 0x80. Remember that x86 is little endian, so the first 4 bytes "80000000" are
567 really the number 0x00000080. With a bit of research, we find that this is
602 So to sum up: It seems that it is the padding introduced by the compiler
603 between two struct fields that is uninitialized, and this gets reported when
604 we do a memcpy() on the struct. This means that we have identified a false
616 And we clearly see that the destination siginfo object is located on the
639 There are a few different ways to make annotations in the source code that
646 also to other functions that end up calling one of these) to indicate
647 that the allocation should not be tracked because it would lead to
688 Note that kmemcheck_annotate_bitfield() can be used even before the
706 false positives that we can annotate and silence. So whatever you find,
716 kmemcheck works by marking memory pages non-present. This means that whenever
718 fault handler notices that the page was in fact only hidden, and so it calls
726 that we can catch the next access too! Now kmemcheck makes use of a debugging
728 finished the one instruction that generated the memory access, a debug
735 1. Tell kmemcheck about newly allocated pages and pages that are about to
746 memory that can take page faults because of kmemcheck.
751 object in question as being initialized so that no warnings will ever be