On Thu, Oct 27, 2022, Colton Lewis wrote:
> Sean Christopherson <seanjc@xxxxxxxxxx> writes:
>
> > On Wed, Oct 19, 2022, Colton Lewis wrote:
> > > Signed-off-by: Colton Lewis <coltonlewis@xxxxxxxxxx>
> > > Reviewed-by: Ricardo Koller <ricarkol@xxxxxxxxxx>
> > > Reviewed-by: David Matlack <dmatlack@xxxxxxxxxx>
>
> > This patch has changed a fair bit since David and Ricardo gave their
> > reviews, their Reviewed-by's should be dropped. Alternatively, if a patch
> > has is on the fence so to speak, i.e. has changed a little bit but not
> > thaaaaat much, you can add something in the cover letter, e.g.
> > "David/Ricardo, I kept your reviews, let me know if that's not ok". But in
> > this case, I think the code has changed enough that their reviews should be
> > dropped.
>
>
> I talked to Ricardo privately and he thought it was ok to leave the
> names in this borderline case.
Heh, damned if you do, damned if you don't. On a more serious note, this is why
I avoid doing off-list reviews except for the most basic sanity checks. Ask two
people for their opinion and inevitably you'll get two different answers :-)
By asking and responding on-list, there's is (a) a paper trail and (b) a chance
for others to object before the decision is "finalized".
> IMO, changing this interface doesn't change anything important of what the
> patch is doing.
Right, but the code is different. E.g. hypothetically, if you botched something
while reworking the code to fit the new interace, then it looks as if multiple
people gave a thumbs up to broken code, which can cause a maintainer to not give
the patch as much scrutiny as that might to a patch without reviews.
A recent example that's somewhat similar is commit 4293ddb788c1 ("KVM: x86/mmu:
Remove redundant spte present check in mmu_set_spte"), where a conflict during a
rebase of a relatively simple patch was mishandled and resulted in a buggy commit
with three Reviewed-by tags where none of the reviews were given for the buggy
code. There's no guarantee the bug would have been caught if the Reviewed-by
tags had been dropped, but a "hey, I dropped your reviews from patch XYZ" likely
would have drawn eyeballs to the patch in question.
> Nevertheless, I'll drop the names and ask them to reconfirm.
FWIW, if you've confirmed offline that someone is ok keeping _their_ review, that's
totally fine, though throwing a comment in the cover letter is probably a good
idea in that case. That's a decent rule of thumb in general; if a decision was
made off-list, make a note of it on-list to keep others in the loop.
> > I think it makes sense to introduce "struct guest_random_state" separately
> > from the usage in perf_test_util and dirty_log_perf_test. E.g. so that if
> > we need to revert the perf_test_util changes (extremely unlikely), we can
> > do so without having to wipe out the pRNG at the same time. Or so that
> > someone can pull in the pRNG to their series without having to take a
> > dependency on the other changes.
>
> Will do. Was attempting to avoid adding unused code in its own commit
> according to
> https://www.kernel.org/doc/html/latest/process/5.Posting.html
>
> "Whenever possible, a patch which adds new code should make that code
> active immediately."
Yeah, this is another "rule" that is sometimes subjective, e.g. in this case it
conflicts with the "one change per patch" rule. Since the RNG code can't be made
completely active without pulling in yet more code (the guest_random_u32() usage
in the next path), the intended benefit of the "use immediately" rule isn't really
achieved, and so forcing the issue is a net negative.
> > > diff --git a/tools/testing/selftests/kvm/lib/perf_test_util.c
> > > b/tools/testing/selftests/kvm/lib/perf_test_util.c
> > > index 9618b37c66f7..5f0eebb626b5 100644
> > > --- a/tools/testing/selftests/kvm/lib/perf_test_util.c
> > > +++ b/tools/testing/selftests/kvm/lib/perf_test_util.c
> > > @@ -49,6 +49,7 @@ void perf_test_guest_code(uint32_t vcpu_idx)
> > > uint64_t gva;
> > > uint64_t pages;
> > > int i;
> > > + struct guest_random_state rand_state =
> > > new_guest_random_state(pta->random_seed + vcpu_idx);
>
> > lib/perf_test_util.c: In function ‘perf_test_guest_code’:
> > lib/perf_test_util.c:52:35: error: unused variable ‘rand_state’
> > [-Werror=unused-variable]
> > 52 | struct guest_random_state rand_state =
> > new_guest_random_state(pta->random_seed + vcpu_idx);
> > | ^~~~~~~~~~
>
> > This belongs in the next path. I'd also prefer to split the declaration
> > from the
> > initialization as this is an unnecessarily long line, e.g.
>
> Understood that this is implied by the previous comment. As for the line
> length, checkpatch doesn't complain.
Checkpatch now only complains if the line length is >100, but there is still an 80
column "soft" limit that is preferred by most of the kernel, KVM included.
Checkpatch was relaxed because too many people were wrapping code in really weird
places "because checkpatch complained", but preferred style is still to say under
the soft limit.
In other words, stay under the soft limit unless the alternative sucks worse :-)
