linux-kernel - Re: [GIT PULL] RCU changes for v5.14

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: <CAHk-=whSGHOiuv1yARox+P3k2uTLtJ=F51aKoJYVi5UPgjitCQ@mail.gmail.com>
Date:   Sun, 4 Jul 2021 13:01:33 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [GIT PULL] RCU changes for v5.14

On Sun, Jul 4, 2021 at 10:24 AM Paul E. McKenney <paulmck@...nel.org> wrote:
>
> An example merge resolution may be found here:
>
>         4e2b64e124c7 ("Merge remote-tracking branch 'linus/master' into HEAD")

There sommit ID's are completely useless, because I have no idea where
they come from. They aren't in the linux-next tree as far as I can
tell, for example.

So they are just random noise.

Now, none of the conflicts looked in the least complicated, so it's
not like I _need_ the examples, but this "send random shortened SHA1s
to Linus" is simply not useful.

At a guess, it's actually from your merge-example branch in your own tree.

The point being, that a SHA1 may be globally unique, but without
telling me where that SHA1 can be _found_, it is entirely useless.

If you have example merges - which I do like seeing, and I will
compare against just to double-check even when I have no reason to
doubt my own merge - you need to point to it the same way you point to
the actual real branch.

IOW, say something like

  "I've done an example merge, and you can find it in

     git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
rcu-example-merge"

or similar.

Because actual SHA1 names are only useful WHEN THEY ARE IN MY TREE. So
you can point to history that I have (or that was in your actual pull
request), and I can see _those_ just fine.

So when you say

  "The second is a trivial whitespace conflict between these two commits:

        76c8eaafe4f0 ("rcu: Create an unrcu_pointer() to remove __rcu
from a pointer")
        b9964ce74544 ("rcu: Create an unrcu_pointer() to remove __rcu
from a pointer")"

then that makes sense, because those are two commits that I actually
have as part of the merge conflict).

But that example merge? I don't have it, unless you actually tell me
where it is.

Then I can just do

      git fetch <paul-told-me-where-to-fetch>

and can do

    git show FETCH_HEAD

or (more commonly) just compare my merge result with yours:

    git diff FETCH_HEAD kernel/rcu/tree_stall.h

and it's all golden. But if you send me a random SHA1 of somethign
that only exists in your trees, I just go "oh, ok, not useful".

           Linus