> On Mon, 29 Oct 2001, Daniel Wagner wrote:
>
> > oskit and not for oskit-mach. So I will write a patch for oskit and then
> > I'll see what happends.
>
> It seems that the oskit wrappers for kmalloc and kfree don't pass the
> right flags to oskit_linux_mem_alloc and oskit_linux_mem_free.
I was in total agreement with you, but then I checked the oskit docs.
The OSENV_NONBLOCKING flag to osenv_mem_free does not have to match the
osenv_mem_alloc call; instead, it says the free call can't block (I don't
know what that's supposed to mean, since it returns void).
This specification seems a little screwy to me, which is why I presumed
when I wrote the oskit-mach code that it meant something else. But I guess
it's my bad. Well, no, not quite. Given the specification, s_kmem.c still
ought to pass OSENV_NONBLOCKING when called from interrupt level, which it
doesn't do (and I don't have a suggestion off hand for how it could). But
that's not the criterion I was expecting when I wrote the assert that's
hitting.
So I think the proper thing to do is to decide just based on the address
which flavor of memory it is. So, just turn off the assert in
free_for_oskit and let it get to the test vs phys_mem_max that's already
there. If it's actually the case that any blocks that were allocated under
conditions such that alloc_for_oskit used virtual memory instead of
direct-mapped physical memory, are then freed from interrupt level, we will
have a problem. Then you'll hit:
panic ("free_for_oskit of virtual memory from interrupt level");
If that happens, we'll have to come up with some hairy solution. That's
because you can't call kfree at interrupt level, so we'd need to maintain a
to-be-freed list at interrupt level and process it later and it would be hair.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
