Re: [PATCH v1 3/3] svcrdma: Fix leak of svc_rdma_recv_ctxt objects

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Apr 14, 2020 at 12:20:16PM -0300, Jason Gunthorpe wrote:
> On Tue, Apr 14, 2020 at 11:13:03AM -0400, J. Bruce Fields wrote:
> > On Tue, Apr 14, 2020 at 09:19:31AM -0300, Jason Gunthorpe wrote:
> > > On Mon, Apr 13, 2020 at 03:29:07PM -0400, J. Bruce Fields wrote:
> > > > On Thu, Apr 09, 2020 at 02:47:50PM -0300, Jason Gunthorpe wrote:
> > > > > On Thu, Apr 09, 2020 at 10:33:32AM -0400, Chuck Lever wrote:
> > > > > > The commit ID is what automation should key off of. The short
> > > > > > description is only for human consumption. 
> > > > > 
> > > > > Right, so if the actual commit message isn't included so humans can
> > > > > read it then what was the point of including anything?
> > > > 
> > > > Personally as a human reading commits in a terminal window I prefer the
> > > > abbreviated form.
> > > 
> > > Frankly, I think they are useless, picking one of yours at random:
> > > 
> > >     Fixes: 4e48f1cccab3 "NFSD: allow inter server COPY to have... "
> > > 
> > > And sadly the '4e48f1cccab3' commit doesn't appear in Linus's tree so
> > 
> > Ow, apologies.  Looks like I rebased after writing that Fixes tag.
> > 
> > I wonder if it's possible to make git warn....
> > 
> > Looks like a pre-rebase hook could check the branch being rebased for
> > "Fixes:" lines referencing commits on the rebased branch.
> 
> I have some silly stuff to check patches before pushing them and it
> includes checking the fixes lines because they are very often
> wrong, both with wrong commit IDs and wrong subjects!

I'd be interested in seeing it.

> linux-next now automates complaining about them, but perhaps not
> following the standard format defeats that..

It's managed before:

	https://lore.kernel.org/r/20190704074048.65556740@canb.auug.org.au

though admittedly I was breaking the rule in a different way.  I can't
even be consistently rebellious.

> Use 'git merge-base --is-ancestor fixes_id linus/master' to check
> them.

Oh, yeah, that's better than what I was trying to do, thanks.

--b.