linux-kernel - Re: linux-next: Fixes tags need some work in the dma-mapping-fixes tree

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: <20190123230915.18046ca7@canb.auug.org.au>
Date:   Wed, 23 Jan 2019 23:09:15 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Christoph Hellwig <hch@....de>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ming Lei <ming.lei@...hat.com>
Subject: Re: linux-next: Fixes tags need some work in the dma-mapping-fixes
 tree

Hi Christoph,

On Wed, 23 Jan 2019 08:19:33 +0100 Christoph Hellwig <hch@....de> wrote:
>
> On Wed, Jan 23, 2019 at 07:47:47AM +1100, Stephen Rothwell wrote:
> >   - SHA1 should be at least 12 digits long  
> 
> When did we decide on that?  As far as I know it was bumped to 10
> a while ago.  12 basically makes the line even more unreadable.

From Documentation//process/submitting-patches.rst:

"If your patch fixes a bug in a specific commit, e.g. you found an issue using
``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
the SHA-1 ID, and the one line summary."

Apparently we already have some clashes for 11 digit abbreviations.
Also, the git-config man page has:

"core.abbrev
           Set the length object names are abbreviated to. If unspecified or
           set to "auto", an appropriate value is computed based on the
           approximate number of packed objects in your repository, which
           hopefully is enough for abbreviated object names to stay unique for
           some time."

and when I set mine to "auto" it produces 12 digit SHA1 abbreviations
in the linux-next tree and in Linus' tree. So there has been some
discussion of suggesting core.abbrev not be set (which is the same as
"auto"), or being set to 13 to give some leeway.

> > In commit
> > 
> >   8218a55b6b91 ("sbitmap: Protect swap_lock from hardirq")
> > 
> > This later patch appears to already be in Linus' tree as commit
> > fe76fc6aaf53 (also with an incorrect Fixes tag :-()  
> 
> That commit is not from the dma-mapping tree..

This is in my linux-next tree today:

$ git log --oneline origin/master..dma-mapping-fixes/for-linus 
702e8ed37bed arm64/xen: fix xen-swiotlb cache flushing
eda14f8977df nvme-pci: fix nvme_setup_irqs()
7c6f88f2fb4b nvmet-tcp: fix uninitialized variable access
8218a55b6b91 sbitmap: Protect swap_lock from hardirq
f5ac6c1e96a9 md: Make bio_alloc_mddev use bio_alloc_bioset
2490a5f5f2f8 block, bfq: fix comments on __bfq_deactivate_entity

origin/master is Linus' tree and dma-mapping-fixes is
git://git.infradead.org/users/hch/dma-mapping.git#for-linus

However, the committer of 8218a55b6b91 is Jens Axboe, so have you
accidentally based your for-linus branch on something from Jens?  That
commit does not appear in any other branch in linux-next.
-- 
Cheers,
Stephen Rothwell

Content of type "application/pgp-signature" skipped