linux-kernel - Re: linux-next: manual merge of the akpm-current tree with the risc-v 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] [day] [month] [year] [list]

Date:   Thu, 17 Dec 2020 09:06:23 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     andy.shevchenko@...il.com
CC:     Stephen Rothwell <sfr@...b.auug.org.au>, brendanhiggins@...gle.com,
        skhan@...uxfoundation.org, Paul Walmsley <paul@...an.com>,
        akpm@...ux-foundation.org, andriy.shevchenko@...ux.intel.com,
        linux-kernel@...r.kernel.org, linux-next@...r.kernel.org
Subject:     Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

On Thu, 17 Dec 2020 01:40:51 PST (-0800), andy.shevchenko@...il.com wrote:
> On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>>
>> Hi all,
>>
>> On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>> >
>> > Today's linux-next merge of the akpm-current tree got a conflict in:
>> >
>> >   lib/Makefile
>> >
>> > between commit:
>> >
>> >   527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
>> >
>> > from the risc-v tree and commits:
>> >
>> >   8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit tests")
>> >   17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for KUnit tests")
>> >   23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit tests")
>> >   1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
>
> AFAIU Linus rejected the above patches. I hope kselftest/kunit tree
> can pick them up.
>
>> > diff --cc lib/Makefile
>> > index bcedd691ef63,dc623561ef9d..000000000000
>> > --- a/lib/Makefile
>> > +++ b/lib/Makefile
>> > @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
>> >
>> >   # KUnit tests
>> >   obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
>> > - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
>> > - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
>> > - obj-$(CONFIG_BITS_TEST) += test_bits.o
>> > + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
>> > + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
>> > + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
>> > + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
>> >  +
>> >  +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
>>
>> This is now a conflict between the risc-v tree and Linus' tree.
>
> Yeah, and it's slightly different. Perhaps RISC-V tree can handle this
> by moving Makefile entry somewhere else in the file.

I was planning on just posting the merge conflict along with the PR, which I
was going to do this morning (though in practice that means this afternoon...
;)).  I'd been considering fixing this stuff as I was likely going to have to
rewrite history to sort out our boot bug, but as it's only manifesting on
old-ish QEMU versions I've decided that it's not really worth making it a
blocker.

If you think that's an issue then I'm happy to rewrite my history, but I do
generally try to stay away from that and for this sort of thing I've yet to
have any complaints.  I probably will put it up near the other GENERIC_LIB
stuff in my conflict resolution, though.