lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZR9nYw53O21y0VYM@google.com>
Date:   Thu, 5 Oct 2023 18:48:19 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     paul@....org
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Paul Durrant <pdurrant@...zon.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        David Woodhouse <dwmw2@...radead.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH v2] KVM: x86/xen: ignore the VCPU_SSHOTTMR_future flag

On Thu, Oct 05, 2023, Paul Durrant wrote:
> On 04/10/2023 19:30, Sean Christopherson wrote:
> > On Wed, Oct 04, 2023, Paul Durrant wrote:
> > > ---
> > > Cc: David Woodhouse <dwmw2@...radead.org>
> > > Cc: Sean Christopherson <seanjc@...gle.com>
> > > Cc: Paolo Bonzini <pbonzini@...hat.com>
> > > Cc: Thomas Gleixner <tglx@...utronix.de>
> > > Cc: Ingo Molnar <mingo@...hat.com>
> > > Cc: Borislav Petkov <bp@...en8.de>
> > > Cc: Dave Hansen <dave.hansen@...ux.intel.com>
> > > Cc: "H. Peter Anvin" <hpa@...or.com>
> > > Cc: x86@...nel.org
> > 
> > If you're going to manually Cc folks, put the Cc's in the changelog proper so that
> > there's a record of who was Cc'd on the patch.
> > 
> 
> FTR, the basic list was generated:
> 
> ./scripts/get_maintainer.pl --no-rolestats
> 0001-KVM-xen-ignore-the-VCPU_SSHOTTMR_future-flag.patch | while read line;
> do echo Cc: $line; done
> 
> and then lightly hacked put x86 at the end and remove my own name... so not
> really manual.
> Also not entirely sure why you'd want the Cc list making it into the actual
> commit.

It's useful for Cc's that *don't* come from get_maintainers, as it provides a
record in the commit of who was Cc'd on a patch. 

E.g. if someone encounters an issue with a commit, the Cc records provide additional
contacts that might be able to help sort things out.

Or if a maintainer further up the stream has questions or concerns about a pull
request, they can use the Cc list to grab the right audience for a discussion,
or be more confident in merging the request because the maintainer knows that the
"right" people at least saw the patch.

Lore links provide much of that functionality, but following a link is almost
always slower, and some maintainers are allergic to web browsers :-)

> > Or even better, just use scripts/get_maintainers.pl and only manually Cc people
> > when necessary.
> 
> I guess this must be some other way of using get_maintainers.pl that you are
> expecting?

Ah, I was just assuming that you were handcoding the Cc "list", but it sounds
like you're piping the results into each patch.  That's fine, just a bit noisy
and uncommon.

FWIW, my scripts gather the To/Cc for all patches in a series, and then use the
results for the entire series, e.g.

  git send-email --confirm=always --suppress-cc=all $to $bcc $cc ...

That way everyone that gets sent mail gets all patches in a series.  Most
contributors, myself included, don't like to receive bits and pieces of a series,
e.g. it makes doing quick triage/reviews annoying, especially if the patches I
didn't receive weren't sent to any of the mailing list to which I'm subscribed.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ