Hi Finn,
Am 06.05.2023 um 12:36 schrieb Finn Thain:
On Sat, 6 May 2023, Michael Schmitz wrote:
Am 05.05.2023 um 17:05 schrieb Michael Schmitz:
Am 05.05.2023 um 15:14 schrieb Finn Thain:
On Fri, 5 May 2023, Michael Schmitz wrote:
In terms of fixing the bus error bug, I think we'll need to fix this
regression first (only first patch of yours applied):
That patch came from Andreas, maybe he can comment.
I'll try with your second patch applied as well.
I think patch 2/2 should be tested alone since 1/2 was nak'd.
I'm trying to find out whether patch 2 mitigates the effect of patch
1.
It didn't - hung without printing an Oops message, on the first stress
iteration using the --stack 2 --stack-fill stressor.
In my mind, at the time I sent them, patch 1 was expected to mitigate the
impact of patch 2. It would have been surprising if the reverse had
somehow happened.
I did wonder if delaying signal delivery would cause fewer signals to be
delivered in total, and whether the remaining bus faults that do cause
signal delivery (format a) still cause any trouble because of eventual
unreliable USP.
Adding your patch 2 then might have mitigated these problems while not
placing too much of a burden on the stack.
Anyway, I'm still in the dark as to why patch 1 is interesting. Was that
because you wanted to delay signal delivery to try to put more pressure on
stack memory by delivering multiple signals? You and I did come up with an
No - it just eliminates temporary stack growth due to the format b bus
faults as entry into signal delivery.
alternative patch for bypassing signal delivery after certain exceptions.
Maybe that would work better.
Meaning skipping signal delivery on any bus fault? I haven't tried that
one yet. But I suspect the same problem exists with that as with your
patch 1 - if the bus fault wasn't handled, and the signal to be
delivered to the process is SIGKILL or SIGSEGV, completing the execption
without signal delivery will just cause the same bus fault again, ad
infinitum.
Cheers,
Michael
