page fault when enabling interrupts in syscalls

[RayanMargham]

Hello,

I've been working on my kernel nyaux for a while now and i require interruptible syscalls for reasons, while yield works fine enabling interrupts with sti causes a cr2 0x0, rip 0x0 and the page fault being 0x14.

i do not know why this is the case but i do know that somehow the syscall tmp variable stored in GS is being thrashed, ive been stuck at this for a while and really need some help here.

the repo: https://github.com/rayanmargham/NyauxKC

the syscall code https://github.com/rayanmargham/NyauxKC ... /syscall.c

thank you and i look forward to hearing any responses!

[RayanMargham]

umm okay some developments

sometimes the slab allocator shits the bed because someone returns the same address twice when freeing

sometimes the process lock deadlocks :c

please help anybody :c

[Octocontrabass]

i require interruptible syscalls for reasons

Can you explain those reasons? If you're using interruptible syscalls to solve some other problem, maybe you don't really need interruptible syscalls.

You may be able to fix some of the problems you're having if you delete yield.asm. Yes, pretty much all if it is wrong. You really only need a function that pushes the callee-saved registers, saves and loads RSP, pops the callee-saved registers, and returns. The wiki has a pretty good example (though I'd argue even this example makes it too complicated - most of the stuff with TCBs and CR3 could be handled by the caller). No memcpy, no iretq, and only one function instead of three.

[RayanMargham]

i need interruptible syscalls cause one thread could hold a memlock and another could be preempted

also ive explained that it either process lock deadlocks or the slab allocator shits the bead because its given the same address twice


id rather keep yield as is. i recreate my interrupt stackframe and it works fine

[Octocontrabass]

i need interruptible syscalls cause one thread could hold a memlock and another could be preempted

Why does that mean you need to enable interrupts? You shouldn't need interrupts to switch to another task while a syscall is blocked.

[RayanMargham]

because when u switch, the memlock is still held be some thread and u attempt to allocate in some syscall on some other thread causing a deadlcok.

but this way of design isnt the issue here, the issue is the issue i described eariler

[iProgramInCpp]

Can you explain those reasons? If you're using interruptible syscalls to solve some other problem, maybe you don't really need interruptible syscalls.

Why wouldn't you allow interruptible syscalls? On the kernel's side, a syscall should be as simple as calling a function from a kernel mode. And don't tell me you can't call functions from kernel mode without disabling interrupts. In my design, at least, issuing the "syscall" instruction temporarily upgrades a thread to kernel mode (and each of my threads has a separate kernel stack) so that it can perform the actual function call in the kernel.

You may be able to fix some of the problems you're having if you delete yield.asm. Yes, pretty much all if it is wrong.

Kinda aggressive, don't you think? However, you are not exactly wrong, it's very possible to switch threads with significantly less complicated machinery. Here's how I switch threads (namely, their stacks. The actual per-CPU switch is performed earlier): https://github.com/iProgramMC/Boron/blo ... c.asm#L105

[iProgramInCpp]

because when u switch, the memlock is still held be some thread

Then unlock the memory lock before yielding