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: <31b13104-cc37-985a-cdeb-05a9507fa74c@microchip.com>
Date:   Tue, 26 Jul 2022 09:42:50 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <xianting.tian@...ux.alibaba.com>
CC:     <alexandre.ghiti@...onical.com>, <heiko@...ech.de>,
        <palmer@...belt.com>, <mick@....forth.gr>, <guoren@...nel.org>,
        <kexec@...ts.infradead.org>, <bhe@...hat.com>,
        <linux-doc@...r.kernel.org>, <vgoyal@...hat.com>,
        <linux-riscv@...ts.infradead.org>, <dyoung@...hat.com>,
        <linux-kernel@...r.kernel.org>, <crash-utility@...hat.com>,
        <huanyi.xj@...baba-inc.com>, <heinrich.schuchardt@...onical.com>,
        <anup@...infault.org>, <corbet@....net>, <k-hagio-ab@....com>,
        <hschauhan@...ltrace.org>, <paul.walmsley@...ive.com>,
        <aou@...s.berkeley.edu>
Subject: Re: [RESEND PATCH V2 0/5] Fixups to work with crash tool

On 26/07/2022 10:28, Xianting Tian wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> 在 2022/7/26 下午4:16, Xianting Tian 写道:
>>
>> 在 2022/7/26 下午4:01, Conor.Dooley@...rochip.com 写道:
>>> On 26/07/2022 08:54, tianxianting wrote:
>>>> 在 2022/7/26 上午1:13, Conor.Dooley@...rochip.com 写道:
>>>>> That said, this does not apply to riscv/for-next:
>>>>> b4 shazam 20220725014539.1037627-1-xianting.tian@...ux.alibaba.com
>>>>> Grabbing thread from
>>>>> lore.kernel.org/all/20220725014539.1037627-1-xianting.tian%40linux.alibaba.com/t.mbox.gz
>>>>> Checking for newer revisions on https://lore.kernel.org/all/
>>>>> Analyzing 6 messages in the thread
>>>>> Checking attestation on all messages, may take a moment...
>>>>> ---
>>>>>     [PATCH v2 1/5] RISC-V: use __smp_processor_id() instead of
>>>>> smp_processor_id()
>>>>>     [PATCH v2 2/5] RISC-V: Add arch_crash_save_vmcoreinfo support
>>>>>     [PATCH v2 3/5] riscv: Add modules to virtual kernel memory
>>>>> layout dump
>>>>>     [PATCH v2 4/5] RISC-V: Fixup getting correct current pc
>>>>>     [PATCH v2 5/5] riscv: crash_core: Export kernel vm layout,
>>>>> phys_ram_base
>>>>> ---
>>>>> Total patches: 5
>>>>> ---
>>>>> Applying: RISC-V: use __smp_processor_id() instead of
>>>>> smp_processor_id()
>>>>> Applying: RISC-V: Add arch_crash_save_vmcoreinfo support
>>>>> Patch failed at 0002 RISC-V: Add arch_crash_save_vmcoreinfo support
>>>> patch 2 apply is OK for me, I don't know why you failed :(
>>>> Do you have more detals for this?
>>>>
>>> What did you apply it to? It does not apply for me to riscv/for-next:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/log/?h=for-next
>>>
>>
>> This 5 patches are based on the master branch of below git:
>>
>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
>>
>>
>> "git am 0002-RISC-V-Add-arch_crash_save_vmcoreinfo-support.patch" to
>> this git is ok for me.
>>
>> All is correct?
> 
> I figured out the reason, there is one difference in
> arch/riscv/kernel/Makefile between riscv/for-next and torvalds/linux.
> 
> For riscv/for-next, in line 81 of arch/riscv/kernel/Makefile, it is:
> 
>      obj-$(CONFIG_KEXEC)        += kexec_relocate.o crash_save_regs.o
> machine_kexec.o
> 
> But for torvalds/linux, in line 81 of arch/riscv/kernel/Makefile, it is:
> 
>      obj-$(CONFIG_KEXEC_CORE)        += kexec_relocate.o
> crash_save_regs.o machine_kexec.o
> 
> torvalds/linux is newer than riscv/for-next,  commit 3a66a08759
> ("RISC-V: kexec: Fix build error without CONFIG_KEXEC") added
> "CONFIG_KEXEC_CORE" for torvalds/linux, But riscv/for-next
> 
> doesn't contain the commit.

Ah right, since it's late in the cycle (mw is next week) maybe
it's best to wait for rc1 then and rebase when for-next & fixes
have been synced. Conflict doesn't seem to hard to sort out for
those who use kexec ;)

Thanks,
Conor.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ