I wrote: "PS: it's possible that that commit doesn't actually fix the
underlying kernel crash, it just means that rr isn't triggering it any more,
and that if you modified EFLAGS via the ptrace interface rather than r11 you'd
get the crash back again."
but looking at the kernel I think that is
I've now completed the kernel git bisect. git bisect says the commit
which fixed this issue is 29722cd4ef666705b2eda1c3ba44435488e509eb
("x86/asm/entry/64: Save R11 into pt_regs->flags on SYSCALL64
fastpath").
This fits in with the discovery on the rr side that the rr commit which
started causing
PS: it's possible that that commit doesn't actually fix the underlying
kernel crash, it just means that rr isn't triggering it any more, and
that if you modified EFLAGS via the ptrace interface rather than r11
you'd get the crash back again.
--
You received this bug notification because you are
** Information type changed from Public to Public Security
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1535307
Title:
running 'rr' make check causes kernel "hard LOCKUP"
Status in
** Tags removed: needs-reverse-bisect
** Tags added: cherry-pick reverse-bisect-done
** Changed in: linux (Ubuntu)
Importance: Medium => High
** Changed in: linux (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Kernel
Packages,
Peter Maydell, the next step is to fully reverse commit bisect from
kernel 3.13 to 4.4 in order to identify the last bad commit, followed
immediately by the first good one. Once this good commit has been
identified, it may be reviewed for backporting. Could you please do this
following
I retried with a workaround for the rr bug I described in "caveat (2)"
and the kernel still does not lockup, so I am now confident that this
bug is not present in the upstream kernel.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux
Did this issue start happening after an update/upgrade? Was there a
prior kernel version where you were not having this particular problem?
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.4
No, I don't think this was associated with a kernel upgrade, though it's
hard to say for certain as I hadn't run the test suite in some months. I
suspect it's more that rr's test suite got more complex and included
some stress tests that reveal pre-existing kernel bugs.
I will test the upstream
I tested with linux-headers-4.4.0-040400 / linux-
headers-4.4.0-040400-generic / linux-image-4.4.0-040400-generic
4.4.0-040400.201601101930. The kernel lockups did *not* reproduce.
Two caveats:
(1) I did get this kernel warning in the log:
Jan 21 18:00:08 e104462 kernel: [ 171.577000]
10 matches
Mail list logo
