Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: Fixes tag needs some work in the rdma-fixes tree
@ 2019-10-21  7:41 Stephen Rothwell
  2019-10-21 14:50 ` Doug Ledford
  0 siblings, 1 reply; 11+ messages in thread
From: Stephen Rothwell @ 2019-10-21  7:41 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Potnuri Bharat Teja

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

Hi all,

In commit

  612e0486ad08 ("iw_cxgb4: fix ECN check on the passive accept")

Fixes tag

  Fixes: 92e7ae7172 ("iw_cxgb4: Choose appropriate hw mtu index and ISS for iWARP connections")

has these problem(s):

  - SHA1 should be at least 12 digits long
    Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
    or later) just making sure it is not set (or set to "auto").

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
  2019-10-21  7:41 linux-next: Fixes tag needs some work in the rdma-fixes tree Stephen Rothwell
@ 2019-10-21 14:50 ` Doug Ledford
  2019-10-21 15:15   ` Jason Gunthorpe
  0 siblings, 1 reply; 11+ messages in thread
From: Doug Ledford @ 2019-10-21 14:50 UTC (permalink / raw)
  To: Stephen Rothwell, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Potnuri Bharat Teja

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Mon, 2019-10-21 at 18:41 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> In commit
> 
>   612e0486ad08 ("iw_cxgb4: fix ECN check on the passive accept")
> 
> Fixes tag
> 
>   Fixes: 92e7ae7172 ("iw_cxgb4: Choose appropriate hw mtu index and
> ISS for iWARP connections")
> 
> has these problem(s):
> 
>   - SHA1 should be at least 12 digits long
>     Can be fixed by setting core.abbrev to 12 (or more) or (for git
> v2.11
>     or later) just making sure it is not set (or set to "auto").

I'll leave it to Potnuri to fix his stuff.  As for the rdma tree, the 10
digit hash is still unique as of today, so I won't rebase the official
branch to fix this.  However, I'll see about adding a check for this in
my workflow.  Thanks.

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
  2019-10-21 14:50 ` Doug Ledford
@ 2019-10-21 15:15   ` Jason Gunthorpe
  2019-10-21 15:39     ` Matteo Croce
  0 siblings, 1 reply; 11+ messages in thread
From: Jason Gunthorpe @ 2019-10-21 15:15 UTC (permalink / raw)
  To: Doug Ledford
  Cc: Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Potnuri Bharat Teja, Matteo Croce

On Mon, Oct 21, 2019 at 10:50:33AM -0400, Doug Ledford wrote:
> On Mon, 2019-10-21 at 18:41 +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > In commit
> > 
> >   612e0486ad08 ("iw_cxgb4: fix ECN check on the passive accept")
> > 
> > Fixes tag
> > 
> >   Fixes: 92e7ae7172 ("iw_cxgb4: Choose appropriate hw mtu index and
> > ISS for iWARP connections")
> > 
> > has these problem(s):
> > 
> >   - SHA1 should be at least 12 digits long
> >     Can be fixed by setting core.abbrev to 12 (or more) or (for git
> > v2.11
> >     or later) just making sure it is not set (or set to "auto").
> 
> I'll leave it to Potnuri to fix his stuff.  As for the rdma tree, the 10
> digit hash is still unique as of today, so I won't rebase the official
> branch to fix this.  However, I'll see about adding a check for this in
> my workflow.  Thanks.

I thought I saw that checkpatch was checking this now?

commit a8dd86bf746256fbf68f82bc13356244c5ad8efa
Author: Matteo Croce <mcroce@redhat.com>
Date:   Wed Sep 25 16:46:38 2019 -0700

    checkpatch.pl: warn on invalid commit id

Maybe that check should also check that enough hash is provided and
other details like the correct subject line?

I also use a check that builds the fixes line from the commit id and
requires it to be the same as the patch provided. This catches all
sorts of wrong fixes lines, and sometimes git even recommends 13 chars
:\

Jason

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
  2019-10-21 15:15   ` Jason Gunthorpe
@ 2019-10-21 15:39     ` Matteo Croce
  2019-10-21 17:01       ` Jason Gunthorpe
  0 siblings, 1 reply; 11+ messages in thread
From: Matteo Croce @ 2019-10-21 15:39 UTC (permalink / raw)
  To: Jason Gunthorpe, Joe Perches
  Cc: Doug Ledford, Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Potnuri Bharat Teja

On Mon, Oct 21, 2019 at 5:15 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> On Mon, Oct 21, 2019 at 10:50:33AM -0400, Doug Ledford wrote:
> > On Mon, 2019-10-21 at 18:41 +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > In commit
> > >
> > >   612e0486ad08 ("iw_cxgb4: fix ECN check on the passive accept")
> > >
> > > Fixes tag
> > >
> > >   Fixes: 92e7ae7172 ("iw_cxgb4: Choose appropriate hw mtu index and
> > > ISS for iWARP connections")
> > >
> > > has these problem(s):
> > >
> > >   - SHA1 should be at least 12 digits long
> > >     Can be fixed by setting core.abbrev to 12 (or more) or (for git
> > > v2.11
> > >     or later) just making sure it is not set (or set to "auto").
> >
> > I'll leave it to Potnuri to fix his stuff.  As for the rdma tree, the 10
> > digit hash is still unique as of today, so I won't rebase the official
> > branch to fix this.  However, I'll see about adding a check for this in
> > my workflow.  Thanks.
>
> I thought I saw that checkpatch was checking this now?
>
> commit a8dd86bf746256fbf68f82bc13356244c5ad8efa
> Author: Matteo Croce <mcroce@redhat.com>
> Date:   Wed Sep 25 16:46:38 2019 -0700
>
>     checkpatch.pl: warn on invalid commit id
>
> Maybe that check should also check that enough hash is provided and
> other details like the correct subject line?
>
> I also use a check that builds the fixes line from the commit id and
> requires it to be the same as the patch provided. This catches all
> sorts of wrong fixes lines, and sometimes git even recommends 13 chars
> :\
>
> Jason

Hi,

actually I just call git_commit_info() which checks for validness.
I could also check that the hash is at least 12 digits, would be very easy.

Joe?

-- 
Matteo Croce
per aspera ad upstream

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
  2019-10-21 15:39     ` Matteo Croce
@ 2019-10-21 17:01       ` Jason Gunthorpe
  2019-10-21 17:08         ` Matteo Croce
  0 siblings, 1 reply; 11+ messages in thread
From: Jason Gunthorpe @ 2019-10-21 17:01 UTC (permalink / raw)
  To: Matteo Croce
  Cc: Joe Perches, Doug Ledford, Stephen Rothwell,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Potnuri Bharat Teja

On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote:
> > I thought I saw that checkpatch was checking this now?
> >
> > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa
> > Author: Matteo Croce <mcroce@redhat.com>
> > Date:   Wed Sep 25 16:46:38 2019 -0700
> >
> >     checkpatch.pl: warn on invalid commit id
> >
> > Maybe that check should also check that enough hash is provided and
> > other details like the correct subject line?
> >
> > I also use a check that builds the fixes line from the commit id and
> > requires it to be the same as the patch provided. This catches all
> > sorts of wrong fixes lines, and sometimes git even recommends 13 chars
> > :\
> >
> > Jason
> 
> Hi,
> 
> actually I just call git_commit_info() which checks for validness.
> I could also check that the hash is at least 12 digits, would be very easy.

IMHO you should do

  git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")'

And check that the provided fixes line matches the above output
exactly, or nearly exactly. People do lots of funny things to fixes
lines..

Jason

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
  2019-10-21 17:01       ` Jason Gunthorpe
@ 2019-10-21 17:08         ` Matteo Croce
  2019-10-21 17:11           ` Jason Gunthorpe
  0 siblings, 1 reply; 11+ messages in thread
From: Matteo Croce @ 2019-10-21 17:08 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Joe Perches, Doug Ledford, Stephen Rothwell,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Potnuri Bharat Teja

On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote:
> > > I thought I saw that checkpatch was checking this now?
> > >
> > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa
> > > Author: Matteo Croce <mcroce@redhat.com>
> > > Date:   Wed Sep 25 16:46:38 2019 -0700
> > >
> > >     checkpatch.pl: warn on invalid commit id
> > >
> > > Maybe that check should also check that enough hash is provided and
> > > other details like the correct subject line?
> > >
> > > I also use a check that builds the fixes line from the commit id and
> > > requires it to be the same as the patch provided. This catches all
> > > sorts of wrong fixes lines, and sometimes git even recommends 13 chars
> > > :\
> > >
> > > Jason
> >
> > Hi,
> >
> > actually I just call git_commit_info() which checks for validness.
> > I could also check that the hash is at least 12 digits, would be very easy.
>
> IMHO you should do
>
>   git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")'
>
> And check that the provided fixes line matches the above output
> exactly, or nearly exactly. People do lots of funny things to fixes
> lines..
>

The point in using git_commit_info() instead of calling git directly
is that the latter would generate an error if the working copy is not
a git tree (e.g. a tar.xz downloaded from kernel.org).

-- 
Matteo Croce
per aspera ad upstream

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
  2019-10-21 17:08         ` Matteo Croce
@ 2019-10-21 17:11           ` Jason Gunthorpe
  2019-10-21 17:25             ` Joe Perches
  0 siblings, 1 reply; 11+ messages in thread
From: Jason Gunthorpe @ 2019-10-21 17:11 UTC (permalink / raw)
  To: Matteo Croce
  Cc: Joe Perches, Doug Ledford, Stephen Rothwell,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Potnuri Bharat Teja

On Mon, Oct 21, 2019 at 07:08:21PM +0200, Matteo Croce wrote:
> On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
> >
> > On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote:
> > > > I thought I saw that checkpatch was checking this now?
> > > >
> > > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa
> > > > Author: Matteo Croce <mcroce@redhat.com>
> > > > Date:   Wed Sep 25 16:46:38 2019 -0700
> > > >
> > > >     checkpatch.pl: warn on invalid commit id
> > > >
> > > > Maybe that check should also check that enough hash is provided and
> > > > other details like the correct subject line?
> > > >
> > > > I also use a check that builds the fixes line from the commit id and
> > > > requires it to be the same as the patch provided. This catches all
> > > > sorts of wrong fixes lines, and sometimes git even recommends 13 chars
> > > > :\
> > > >
> > > > Jason
> > >
> > > Hi,
> > >
> > > actually I just call git_commit_info() which checks for validness.
> > > I could also check that the hash is at least 12 digits, would be very easy.
> >
> > IMHO you should do
> >
> >   git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")'
> >
> > And check that the provided fixes line matches the above output
> > exactly, or nearly exactly. People do lots of funny things to fixes
> > lines..
> >
> 
> The point in using git_commit_info() instead of calling git directly
> is that the latter would generate an error if the working copy is not
> a git tree (e.g. a tar.xz downloaded from kernel.org).

Well, it does some checks and calls 'git log' so it seems like it
could learn to call git log with different arguments, right?

Jason 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
  2019-10-21 17:11           ` Jason Gunthorpe
@ 2019-10-21 17:25             ` Joe Perches
  2019-10-21 17:39               ` Jason Gunthorpe
  0 siblings, 1 reply; 11+ messages in thread
From: Joe Perches @ 2019-10-21 17:25 UTC (permalink / raw)
  To: Jason Gunthorpe, Matteo Croce
  Cc: Doug Ledford, Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Potnuri Bharat Teja

On Mon, 2019-10-21 at 17:11 +0000, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 07:08:21PM +0200, Matteo Croce wrote:
> > On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
> > > On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote:
> > > > > I thought I saw that checkpatch was checking this now?
> > > > > 
> > > > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa
> > > > > Author: Matteo Croce <mcroce@redhat.com>
> > > > > Date:   Wed Sep 25 16:46:38 2019 -0700
> > > > > 
> > > > >     checkpatch.pl: warn on invalid commit id
> > > > > 
> > > > > Maybe that check should also check that enough hash is provided and
> > > > > other details like the correct subject line?
> > > > > 
> > > > > I also use a check that builds the fixes line from the commit id and
> > > > > requires it to be the same as the patch provided. This catches all
> > > > > sorts of wrong fixes lines, and sometimes git even recommends 13 chars
> > > > > :\
> > > > > 
> > > > > Jason
> > > > 
> > > > Hi,
> > > > 
> > > > actually I just call git_commit_info() which checks for validness.
> > > > I could also check that the hash is at least 12 digits, would be very easy.
> > > 
> > > IMHO you should do
> > > 
> > >   git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")'
> > > 
> > > And check that the provided fixes line matches the above output
> > > exactly, or nearly exactly. People do lots of funny things to fixes
> > > lines..
> > > 
> > 
> > The point in using git_commit_info() instead of calling git directly
> > is that the latter would generate an error if the working copy is not
> > a git tree (e.g. a tar.xz downloaded from kernel.org).
> 
> Well, it does some checks and calls 'git log' so it seems like it
> could learn to call git log with different arguments, right?

git commit SHA1's are not just 12 chars and could be any length.

And checkpatch already does use specific arguments

	my $output = `${git_command} log --no-color --format='%H %s' -1 $commit 2>&1`;

and then parses that $output.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
  2019-10-21 17:25             ` Joe Perches
@ 2019-10-21 17:39               ` Jason Gunthorpe
  2019-10-21 19:32                 ` Joe Perches
  0 siblings, 1 reply; 11+ messages in thread
From: Jason Gunthorpe @ 2019-10-21 17:39 UTC (permalink / raw)
  To: Joe Perches
  Cc: Matteo Croce, Doug Ledford, Stephen Rothwell,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Potnuri Bharat Teja

On Mon, Oct 21, 2019 at 10:25:41AM -0700, Joe Perches wrote:
> On Mon, 2019-10-21 at 17:11 +0000, Jason Gunthorpe wrote:
> > On Mon, Oct 21, 2019 at 07:08:21PM +0200, Matteo Croce wrote:
> > > On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
> > > > On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote:
> > > > > > I thought I saw that checkpatch was checking this now?
> > > > > > 
> > > > > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa
> > > > > > Author: Matteo Croce <mcroce@redhat.com>
> > > > > > Date:   Wed Sep 25 16:46:38 2019 -0700
> > > > > > 
> > > > > >     checkpatch.pl: warn on invalid commit id
> > > > > > 
> > > > > > Maybe that check should also check that enough hash is provided and
> > > > > > other details like the correct subject line?
> > > > > > 
> > > > > > I also use a check that builds the fixes line from the commit id and
> > > > > > requires it to be the same as the patch provided. This catches all
> > > > > > sorts of wrong fixes lines, and sometimes git even recommends 13 chars
> > > > > > :\
> > > > > > 
> > > > > > Jason
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > actually I just call git_commit_info() which checks for validness.
> > > > > I could also check that the hash is at least 12 digits, would be very easy.
> > > > 
> > > > IMHO you should do
> > > > 
> > > >   git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")'
> > > > 
> > > > And check that the provided fixes line matches the above output
> > > > exactly, or nearly exactly. People do lots of funny things to fixes
> > > > lines..
> > > > 
> > > 
> > > The point in using git_commit_info() instead of calling git directly
> > > is that the latter would generate an error if the working copy is not
> > > a git tree (e.g. a tar.xz downloaded from kernel.org).
> > 
> > Well, it does some checks and calls 'git log' so it seems like it
> > could learn to call git log with different arguments, right?
> 
> git commit SHA1's are not just 12 chars and could be any length.

--abbrev forces a minimum bound to the kernel recommendation if the
user has an old git or misconfigured git. git auto-detects if it needs
more digits beyond 12.

> And checkpatch already does use specific arguments
> 
> 	my $output = `${git_command} log --no-color --format='%H %s' -1 $commit 2>&1`;
> 
> and then parses that $output.

Maybe output format "%H %h %s" and then parse it to check the min
length and verify the subject?

Jason

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
  2019-10-21 17:39               ` Jason Gunthorpe
@ 2019-10-21 19:32                 ` Joe Perches
  0 siblings, 0 replies; 11+ messages in thread
From: Joe Perches @ 2019-10-21 19:32 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Matteo Croce, Doug Ledford, Stephen Rothwell,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Potnuri Bharat Teja

On Mon, 2019-10-21 at 17:39 +0000, Jason Gunthorpe wrote:
> Maybe output format and then parse it to check the min
> length and verify the subject?

I'm not too worried about that for now.
12 should still be good for quite awhile...

$ git log --abbrev=1 --format='%h' --no-merges  | \
  awk '{print length($1);}' | sort -n | uniq -c
     90 5
 463746 6
 320183 7
  26244 8
   1683 9
    118 10
      6 11



^ permalink raw reply	[flat|nested] 11+ messages in thread

* linux-next: Fixes tag needs some work in the rdma-fixes tree
@ 2019-04-22 20:57 Stephen Rothwell
  0 siblings, 0 replies; 11+ messages in thread
From: Stephen Rothwell @ 2019-04-22 20:57 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Guy Levi,
	Leon Romanovsky

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

Hi all,

In commit

  5efda3b6b122 ("IB/mlx5: Fix scatter to CQE in DCT QP creation")

Fixes tag

  Fixes: 5d6ff1babe ("IB/mlx5: Support scatter to CQE for DC transport type")

has these problem(s):

  - SHA1 should be at least 12 digits long
    Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
    or later) just making sure it is not set (or set to "auto").

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-21  7:41 linux-next: Fixes tag needs some work in the rdma-fixes tree Stephen Rothwell
2019-10-21 14:50 ` Doug Ledford
2019-10-21 15:15   ` Jason Gunthorpe
2019-10-21 15:39     ` Matteo Croce
2019-10-21 17:01       ` Jason Gunthorpe
2019-10-21 17:08         ` Matteo Croce
2019-10-21 17:11           ` Jason Gunthorpe
2019-10-21 17:25             ` Joe Perches
2019-10-21 17:39               ` Jason Gunthorpe
2019-10-21 19:32                 ` Joe Perches
  -- strict thread matches above, loose matches on Subject: below --
2019-04-22 20:57 Stephen Rothwell

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git