fix redis signal handle failure bug (fixed by mhomidi Hadi Omidi) #1326
Conversation
QuarkContainer
changed the title
| @@ -1310,7 +1310,6 @@ impl Task { | |||
| let signo = info.Signo as u64; | |||
| let currTask = Task::Current(); | |||
| let regs = currTask.GetPtRegs(); | |||
| *regs = PtRegs::default(); | |||
There was a problem hiding this comment.
that means, we are inheriting saved registers from the last interrupt, instead of setting them up from scratch? do you have idea what specific registers are necessary here?
There was a problem hiding this comment.
I have no idea. This is also the behavior of X86 code and I copied from somewhere before. Looks golang signal process relies on that.
There was a problem hiding this comment.
I think reusing the whole trap frame may be a foot gun. Time to read the friendly manual!
For now, I think we may keep this PR open for a while as a temporary fix.
There was a problem hiding this comment.
Probably we just need to keep the register that store the address of g and m structure in the memory in go-runtime. BTW, I agree with @shrik3 and we can keep this PR open for temporary fix.
There was a problem hiding this comment.
@shrik3 If I understand it correctly, for arm64, go initially saves g (Gs,Ms,Ps) in R12. So you don't want to lose that one.
P.S. It may also move it again, before calling sigtrampgo, but I haven't checked it...
|
@QuarkContainer Please change the commit message to something more informative, e.g.
otherwise it's O.K. |
|
I dig it, we should not "reset" the pt_regs on signal delivery. The kernel code doesn't do that. I don't know why it is the case for x86. I'll go ahead and merge this. @QuarkContainer FYI I've rewritten the commit message for you. |
No description provided.