linux-kernel - Re: [GIT PULL] RISC-V Patches for the 6.6 Merge Window, Part 1

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-=wj3iBTT5mcYvaUH+fX7Y+z=JUbx6O5nvNMkpe2k8Hcokw@mail.gmail.com>
Date:   Fri, 1 Sep 2023 08:21:35 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Palmer Dabbelt <palmer@...osinc.com>
Cc:     linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] RISC-V Patches for the 6.6 Merge Window, Part 1

On Fri, 1 Sept 2023 at 07:41, Palmer Dabbelt <palmer@...osinc.com> wrote:
>
> for the other the result I ended up with was
>
> extern pgd_t early_pg_dir[PTRS_PER_PGD];
> static pgd_t tmp_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
> static p4d_t tmp_p4d[PTRS_PER_P4D] __page_aligned_bss;
> static pud_t tmp_pud[PTRS_PER_PUD] __page_aligned_bss;

That's wrong, you should have removed the 'early_pg_dir' declaration
that is now in <asm/pgtable.h>, as done by commit d2402048bc8a
("riscv: mm: fix 2 instances of -Wmissing-variable-declarations").

> though that's not showing up in the git diff, so I may have something odd going
> on here.

So what's going on is that you resolved the merge conflict by taking
everything from one side (not correct, as above), and then git no
longer considers it a conflict after-the-fact.

Side n ote in case you care about the actual git logic:

The git rules for merge conflicts are different when doing the merge
and when showing the result after doing a merge.

When doing the merge, git will do the expensive history calculations
to figure out the merge base and do a 3-way merge of the base and the
two sides.

So at merge time, git looks back in the history from the two merge
heads, and does the three-way diff based on the history leading up to
the two points.

But after the merge, "git show" will basically do the reverse: it
won't look back in the history, but look at the *result* of the merge.
You are, after all, asking it to show the merge itself.

So then it will again do a three-way diff, but not of the merge base,
but of the merge _result_ and the two sides.

And if the merge result is the same as one of the sides, there's no
conflict remaining, and so no three-way diff.

So that's how conflicts sometimes "disappear" after the merge.

                       Linus