Lines Matching refs:we

132 	any context, we need a temporary storage area which is guaranteed not
264 If your kernel was compiled with CONFIG_DEBUG_INFO=y, then all we have to do
300 of calls, we move upwards to see where "from" was allocated or initialized,
334 Now we need to follow the "pending" pointer, since that is being passed on to
335 collect_signal() as "list". At this point, we've run out of lines from the
336 "addr2line" output. Not to worry, we just paste the next addresses from the
354 addresses). This becomes obvious when we look at the code for line 446:
364 436                  * itimers are process shared and we restart periodic
378 So instead of looking at 446, we should be looking at 431, which is the line
379 that executes just before 446. Here we see that what we are looking for is
419 In the first case, the list element we are looking for, "q", is being returned
433 197          * we use RCU protection here
492 uninitialized memory was located, we have to look at the disassembly. For
493 that, we'll need the RIP address again:
519 again (from the kmemcheck report), we can figure out how many bytes were left
524 By looking at the disassembly, we also see that %ecx is being loaded with the
525 value $0xc just before (ffffffff8104edd8), so we are very lucky. Keep in mind
527 operation, we need to multiply by 4 to get the number of bytes. So this means
567 really the number 0x00000080. With a bit of research, we find that this is
599 we found earlier when looking for where siginfo_t objects are enqueued on the
604 we do a memcpy() on the struct. This means that we have identified a false
608 when both the source and destination addresses are tracked. (Instead, we copy
616 And we clearly see that the destination siginfo object is located on the
631 Now, even though we didn't find an actual error here, the example is still a
650 	particular field in a struct, for example, we will now lose the
696 As we have seen, kmemcheck will produce false positive reports. Therefore, it
705 That said, we (the kmemcheck maintainers) will always be on the lookout for
706 false positives that we can annotate and silence. So whatever you find,
725 But after the instruction has been executed, we should hide the page again, so
726 that we can catch the next access too! Now kmemcheck makes use of a debugging
729 exception is raised. From here, we simply hide the page again and continue