On 04/29/24 at 12:52pm, Greg Kroah-Hartman wrote: > On Wed, Apr 24, 2024 at 11:40:16AM +0800, Mingzheng Xing wrote: > > On 4/23/24 21:12, Greg Kroah-Hartman wrote: > > > On Fri, Apr 19, 2024 at 10:55:44PM +0800, Mingzheng Xing wrote: > > >> On 4/19/24 21:58, Greg Kroah-Hartman wrote: > > >>> On Fri, Apr 19, 2024 at 08:26:07PM +0800, Mingzheng Xing wrote: > > >>>> On 4/19/24 18:44, Greg Kroah-Hartman wrote: > > >>>>> On Tue, Apr 16, 2024 at 04:56:47PM +0800, Mingzheng Xing wrote: > > >>>>>> This reverts commit 1d6cd2146c2b58bc91266db1d5d6a5f9632e14c0 which has been > > >>>>>> merged into the mainline commit 39365395046f ("riscv: kdump: use generic > > >>>>>> interface to simplify crashkernel reservation"), but the latter's series of > > >>>>>> patches are not included in the 6.6 branch. > > >>>>>> > > >>>>>> This will result in the loss of Crash kernel data in /proc/iomem, and kdump > > >>>>>> loading the kernel will also cause an error: > > >>>>>> > > >>>>>> ``` > > >>>>>> Memory for crashkernel is not reserved > > >>>>>> Please reserve memory by passing"crashkernel=Y@X" parameter to kernel > > >>>>>> Then try to loading kdump kernel > > >>>>>> ``` > > >>>>>> > > >>>>>> After revert this patch, verify that it works properly on QEMU riscv. > > >>>>>> > > >>>>>> Link: https://lore.kernel.org/linux-riscv/ZSiQRDGLZk7lpakE@MiWiFi-R3L-srv > > >>>>>> Signed-off-by: Mingzheng Xing <xingmingzheng@xxxxxxxxxxx> > > >>>>>> --- > > >>>>> > > >>>>> I do not understand, what branch is this for? Why have you not cc:ed > > >>>>> any of the original developers here? Why does Linus's tree not have the > > >>>>> same problem? And the first sentence above does not make much sense as > > >>>>> a 6.6 change is merged into 6.7? > > >>>> > > >>>> Sorry, I'll try to explain it more clearly. > > >>>> > > >>>> This commit 1d6cd2146c2b ("riscv: kdump: fix crashkernel reserving problem > > >>>> on RISC-V") should not have existed because this patch has been merged into > > >>>> another larger patch [1]. Here is that complete series: > > >>> > > >>> What "larger patch"? It is in Linus's tree, so it's not part of > > >>> something different, right? I'm confused. > > >>> > > >> > > >> Hi, Greg > > >> > > >> The email Cc:ed to author Chen Jiahao was bounced by the system, so maybe > > >> we can wait for Baoquan He to confirm. > > >> > > >> This is indeed a bit confusing. The Fixes: tag in 1d6cd2146c2b58 is a false > > >> reference. If I understand correctly, this is similar to the following > > >> scenario: > > >> > > >> A Fixes B, B doesn't go into linus mainline. C contains A, C goes into linus > > >> mainline 6.7, and C has more reconstruction code. but A goes into 6.6, so > > >> it doesn't make sense for A to be in the mainline, and there's no C in 6.6 > > >> but there's an A, thus resulting in an incomplete code that creates an error. > > >> > > >> The link I quoted [1] shows that Baoquan had expressed an opinion on this > > >> at the time. > > >> > > >> Link: https://lore.kernel.org/linux-riscv/ZSiQRDGLZk7lpakE@MiWiFi-R3L-srv [1] > > > > > > I'm sorry, but I still do not understand what I need to do here for a > > > stable branch. Do I need to apply something? Revert something? > > > Something else? > > > > Hi, Greg > > > > I saw Baoquan's reply in thread[1], thanks Baoquan for confirming. > > > > So I think the right thing to do would be just to REVERT the commit > > 1d6cd2146c2b ("riscv: kdump: fix crashkernel reserving problem on RISC-V") > > in the 6.6.y branch, which is exactly the patch I submitted. If I need to > > make changes to my commit message, feel free to let me know and I'll post > > the second version. > > > > Link: https://lore.kernel.org/stable/ZihbAYMOI4ylazpt@MiWiFi-R3L-srv [1] > > Can someone just send me a patch series showing EXACTLY what needs to be > done here, as I am _still_ confused. I think Mingzheng's patch is good to apply in the 6.6.y stable branch. Hi Mingzheng, Can you resend this patch to Greg and stable@xxxxxxxxxxxxxxx and CC me? I would like to Ack your patch, but can't find the original patch since you didn't cc me. Thanks Baoquan