multi_audio KDL: page fault with interrupts disabled

[umccullough]

Experienced a KDL while compiling some stuff on a machine I use regularly for porting stuff on Haiku.

PANIC: page fault, but interrupts were disabled. Touching address 0x70102f40 from eip 0x832ad165

Welcome to Kernel Debugging Land... Thread 149 "multi_audio audio output" running on CPU 0 kdebug>

Stack trace is attached as jpg. Machine is still sitting at the crash and I'll hook up the serial cable to get text info next. I'll leave it like this as long as possible if anyone has any additional things to check.

The machine has probably been on for > 24 hours, with some compiling here and there, testing of some software, and running of dnetc for a few hours. Was compiling when it happened.

[umccullough]

KDL and backtrace

[umccullough]

Backtrace from serial connection

[korli]

It seems the data parameter passed to the ioctl() is not valid. Maybe it's a bad idea to copy to userland with interrupts disabled.

[umccullough]

Anything further I can get from the KDL (it's still sitting there) - I can run more commands from KDL later on if desired - about 4 hours from now.

[korli]

Could you type "area 0x70102f40" and copy the result here ?

[korli]

even more "area -m 0x70102f40"

[umccullough]

area -m 0x70102f40 output

[umccullough]

I attached the text output from "area -m 0x70102f40" to the ticket.

Let me know if there's anything else that would help

[korli]

"page 0x8217b978" and "page 0x8217b950"

[axeld]

Replying to korli:

Maybe it's a bad idea to copy to userland with interrupts disabled.

I can assure that this is indeed a bad idea. You either need to lock the memory (using lock_memory()) before copying (and turning off interrupts), or use user_memcpy() with enabled interrupts.

[korli]

Replying to axeld:

Maybe it's a bad idea to copy to userland with interrupts disabled.

I can assure that this is indeed a bad idea. You either need to lock the memory (using lock_memory()) before copying (and turning off interrupts), or use user_memcpy() with enabled interrupts.

I can do that, but I don't see many drivers which use user_memcpy(). This might need be reviewed globally then. What do you think ?

[umccullough]

page 0x8217b978 and 0x8217b950

[umccullough]

Added output from the two page commands

[axeld]

You always need to use user_memcpy() in the kernel for memory that has not been locked. The reason is simple that it could go away at any time; since an eventual page could not be resolved, the kernel would crash with memcpy() where it would just return an error with user_memcpy().

And yes, you are right in that we have to review lots of drivers to do that correctly.

We could follow BeOS that locked the buffers for read/write calls. There, only ioctl() was completely unsafe and each app could easily crash the system by passing an invalid buffer to an ioctl. Unfortunately, there is no way to automatically make sure the buffers passed to ioctl are safe to be used.

In any case, if you need to copy a buffer with interrupts disabled, you have to use lock_memory() to protect it from going away at the wrong time.

[umccullough]

Will there be anything else I need to post - or can I reboot that machine tonight? :)

[korli]

Replying to umccullough:

Will there be anything else I need to post - or can I reboot that machine tonight? :)

No, you can reboot. Thanks a lot.

[korli]

Applied a patch in r28861. Could you check please ?

[umccullough]

I'm not sure I can reproduce the error at will - this was the first time I've ever seen it while using this rev of Haiku pretty regularly on this machine for several weeks now.

With that, I'd say close this issue if you believe it's resolved...

[korli]

Replying to umccullough:

I'm not sure I can reproduce the error at will - this was the first time I've ever seen it while using this rev of Haiku pretty regularly on this machine for several weeks now.

Understood

With that, I'd say close this issue if you believe it's resolved...

I'm not sure at all, at least check it still works normally :)

[umccullough]

Listening to audio on that machine at this very moment :)

One thing of note, when I was compiling before, I had no audio playing that I knew of (didn't even have speakers hooked up at the time).

[umccullough]

Oops - forgot to mention that the above comment made while using r28868

[korli]

Nice! Could you also check with r28887?