New tag cycle/cadence #48
Comments
|
----- Original Message -----
Hi Dave, I'd like to ask you about the cadence of tagging in the project.
What triggers this question is that we wanna bump Ubuntu's version, and for
that we'd like to bump Debian version first (the process works this way).
But I've checked the upstream (which I believe corresponds to this repo),
and we are at 7.2.7 for 4 months with about ~30 commits on top of it.
Given the repo history, you seem to be bumping versions within a 4-month
cycle - if that's true and a bump to 7.2.8 comes soon, I'd prefer to wait
for it and ask debian to bump to 7.2.8 directly.
Thanks in advance!
--
I have been waiting for:
(1) Linux 5.5 to be released upstream,
(2) for it to then be built into a Red Hat kernel package in-house, and
(3) for the latest crash sources to be verified against that kernel.
Since the kernel was released upstream just today, I do expect to be doing a
crash release shortly. However, step (2) is out of my control, and sometimes
it takes several days.
Dave
|
|
Thanks a lot for your prompt response Dave. I'll wait your release since it's expected soon - this way, we can have a recent upstream version in Debian and Ubuntu! Guilherme |
|
Thanks Dave, new tag 7.2.8 is up! Will close this one =) |
k-hagio
pushed a commit
that referenced
this issue
Dec 9, 2022
We met "bt" command on KASAN kernel vmcore display truncated backtraces like this: crash> bt PID: 4131 TASK: ffff8001521df000 CPU: 3 COMMAND: "bash" #0 [ffff2000224b0cb0] machine_kexec_prepare at ffff2000200bff4c After digging the root cause, it turns out that arm64_in_kdump_text() found wrong bt->bptr at "machine_kexec" branch. Disassemble machine_kexec() of KASAN vmlinux (gcc 7.3.0): crash> dis -x machine_kexec 0xffff2000200bff50 <machine_kexec>: stp x29, x30, [sp,#-208]! 0xffff2000200bff54 <machine_kexec+0x4>: mov x29, sp 0xffff2000200bff58 <machine_kexec+0x8>: stp x19, x20, [sp,#16] 0xffff2000200bff5c <machine_kexec+0xc>: str x24, [sp,#56] 0xffff2000200bff60 <machine_kexec+0x10>: str x26, [sp,#72] 0xffff2000200bff64 <machine_kexec+0x14>: mov x2, #0x8ab3 0xffff2000200bff68 <machine_kexec+0x18>: add x1, x29, #0x70 0xffff2000200bff6c <machine_kexec+0x1c>: lsr x1, x1, #3 0xffff2000200bff70 <machine_kexec+0x20>: movk x2, #0x41b5, lsl #16 0xffff2000200bff74 <machine_kexec+0x24>: mov x19, #0x200000000000 0xffff2000200bff78 <machine_kexec+0x28>: adrp x3, 0xffff2000224b0000 0xffff2000200bff7c <machine_kexec+0x2c>: movk x19, #0xdfff, lsl #48 0xffff2000200bff80 <machine_kexec+0x30>: add x3, x3, #0xcb0 0xffff2000200bff84 <machine_kexec+0x34>: add x4, x1, x19 0xffff2000200bff88 <machine_kexec+0x38>: stp x2, x3, [x29,#112] 0xffff2000200bff8c <machine_kexec+0x3c>: adrp x2, 0xffff2000200bf000 <swsusp_arch_resume+0x1e8> 0xffff2000200bff90 <machine_kexec+0x40>: add x2, x2, #0xf50 0xffff2000200bff94 <machine_kexec+0x44>: str x2, [x29,#128] 0xffff2000200bff98 <machine_kexec+0x48>: mov w2, #0xf1f1f1f1 0xffff2000200bff9c <machine_kexec+0x4c>: str w2, [x1,x19] 0xffff2000200bffa0 <machine_kexec+0x50>: mov w2, #0xf200 0xffff2000200bffa4 <machine_kexec+0x54>: mov w1, #0xf3f3f3f3 0xffff2000200bffa8 <machine_kexec+0x58>: movk w2, #0xf2f2, lsl #16 0xffff2000200bffac <machine_kexec+0x5c>: stp w2, w1, [x4,#4] We notice that: 1. machine_kexec() start address is 0xffff2000200bff50 2. the instruction at machine_kexec+0x44 stores the same value 0xffff2000200bff50 (comes from 0xffff2000200bf000 + 0xf50) into stack postion [x29,#128]. When arm64_in_kdump_text() searches for LR from stack, it met 0xffff2000200bff50 firstly, so got wrong bt->bptr. We know that the real LR is always greater than the start address of a function, so let's fix it by changing the search conditon to (*ptr > xxx_start) && (*ptr < xxx_end). Signed-off-by: Ding Hui <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi Dave, I'd like to ask you about the cadence of tagging in the project.
What triggers this question is that we wanna bump Ubuntu's version, and for that we'd like to bump Debian version first (the process works this way). But I've checked the upstream (which I believe corresponds to this repo), and we are at 7.2.7 for 4 months with about ~30 commits on top of it.
Given the repo history, you seem to be bumping versions within a 4-month cycle - if that's true and a bump to 7.2.8 comes soon, I'd prefer to wait for it and ask debian to bump to 7.2.8 directly.
Thanks in advance!
The text was updated successfully, but these errors were encountered: