[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZtH8yv5AabMEpBoj@google.com>
Date: Fri, 30 Aug 2024 10:09:30 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: James Houghton <jthoughton@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>,
Paolo Bonzini <pbonzini@...hat.com>, Ankit Agrawal <ankita@...dia.com>,
Axel Rasmussen <axelrasmussen@...gle.com>, Catalin Marinas <catalin.marinas@....com>,
David Matlack <dmatlack@...gle.com>, David Rientjes <rientjes@...gle.com>,
James Morse <james.morse@....com>, Jonathan Corbet <corbet@....net>, Marc Zyngier <maz@...nel.org>,
Oliver Upton <oliver.upton@...ux.dev>, Raghavendra Rao Ananta <rananta@...gle.com>,
Ryan Roberts <ryan.roberts@....com>, Shaoqin Huang <shahuang@...hat.com>,
Suzuki K Poulose <suzuki.poulose@....com>, Wei Xu <weixugc@...gle.com>,
Will Deacon <will@...nel.org>, Yu Zhao <yuzhao@...gle.com>, Zenghui Yu <yuzenghui@...wei.com>,
kvmarm@...ts.linux.dev, kvm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v6 02/11] KVM: x86: Relax locking for kvm_test_age_gfn and kvm_age_gfn
On Fri, Aug 30, 2024, Jason Gunthorpe wrote:
> On Thu, Aug 29, 2024 at 08:47:59PM -0700, Sean Christopherson wrote:
> > On Thu, Aug 29, 2024, James Houghton wrote:
> > > On Fri, Aug 16, 2024 at 6:05 PM Sean Christopherson <seanjc@...gle.com> wrote:
> > > > > +static __always_inline bool kvm_tdp_mmu_handle_gfn_lockless(
> > > > > + struct kvm *kvm,
> > > > > + struct kvm_gfn_range *range,
> > > > > + tdp_handler_t handler)
> > > >
> > > > Please burn all the Google3 from your brain, and code ;-)
> > >
> > > I indented this way to avoid going past the 80 character limit. I've
> > > adjusted it to be more like the other functions in this file.
> > >
> > > Perhaps I should put `static __always_inline bool` on its own line?
> >
> > Noooo. Do not wrap before the function name. Linus has a nice explanation/rant
> > on this[1].
>
> IMHO, run clang-format on your stuff and just be happy with 99% of
> what it spits out. Saves *so much time* and usually arguing..
Heh, nope, not bending on this one. The time I spend far hunting for implementations
because of wraps before the function name far exceeds the time it takes me to
push back on these warts in review.
Powered by blists - more mailing lists