+rcu for archives Hi,
Following up about our gpwrap discussions, I did some tracing of rdp->gpwrap with just boot testing. I actually never see it set because rdp->gp_seq and rnp->gp_seq are usually very close. Example trace: # rnp->gp_seq starts with -1200 on boot and then right around the wrap: 178.096329: rcu_gpnum_ovf: CPU: 2, rnp->gp_seq: -3 (0xfffffffffffffffd), rdp->gp_seq: -3 (0xfffffffffffffffd), wrap before: 0 178.096330: rcu_gpnum_ovf: CPU: 2, rnp->gp_seq: -3 (0xfffffffffffffffd), rdp->gp_seq: -3 (0xfffffffffffffffd), wrap after: 0 178.100327: rcu_gpnum_ovf: CPU: 2, rnp->gp_seq: 1 (0x1), rdp->gp_seq: 1 (0x1), wrap before: 0 178.100328: rcu_gpnum_ovf: CPU: 2, rnp->gp_seq: 1 (0x1), rdp->gp_seq: 1 (0x1), wrap after: 0 The wrap "before" and "after" are the value of gpwrap before and after calling rcu_gpnum_ovf(). Closer look at the _ovf() shows it should be only set if rdp->gp_seq and rnp->gp_seq are quite a distance apart (say if the CPU was idle for too long and many GPs have passed. This can happen both with/without wrap. So imminent wrapping seems not necessary for ->gpwrap to be even set AFAICS. I think the problem is ULONG_CMP_LT is not really "<" so even after wrap, it can false. i.e if rdp->gpseq + ULONG/4 wraps, it could still return false. >From a testing POV, the example shows it is not set even when around when a wrap actually happened. So may be, we are not testing gpwrap much, or at all, with rcutorture? But before that, I am feeling it is not behaving correctly. I'd expect it to be set even if rnp and rdp values are close but we are actually about to wrap. So most likely I am missing something. thanks, - Joel
