On Jan 18, 2006, at 12:07 PM, Andrew Pinski wrote:
On Wed, Jan 18, 2006 at 11:41:39AM -0600, Perry Smith wrote:
In the course of doing my work last week to get exception handling
working in my device driver, I learned that the exception processing
code calls malloc during the exception. This seems weak to me. It
seems like one of the most critical times to throw an exception is
when malloc fails.
I did not study the code very much to see what happens if the malloc
fails during the exception processing but I assume its not good.
It seems like a better approach would be to pre-allocate storage and
use it during the exception handling. The design objective, to me,
would be to make the exception handling as bullet proof as possible.
I understand that it is not known how many exceptions are going to
stack up but I think taking a reasonable guess, pre-allocating that
space, and then fall back to malloc when that space fills up
would be
much less likely to fail during a critical time.
Has this been considered?
It is a major flaw in the gcc exception handling. I'd like to see it
get fixed.
I actually don't think it is that major, it has worked this way for
more than 5 years and this is the first time someone wrote about it.
Also when I looked into fixing it, it was a major issue to fix as
it allocates
more than one buffer and also there is no guessing how many frames
there are
and if you guess wrong, you would need to allocate more.
Also exceptions in a device driver seems like a very bad idea as it
might
mean you crash the kernel if you don't handle the exception correctly.
The plain old setjmp/longjmp seems like a better idea anyways as at
least
there you know a litle more information about where you are
catching the
jump.
I would say that it is not a "major flaw" -- it just isn't robust.
I'd like to investigate it. Is there any external documentation
about this code except for the source code? I'm thinking I'm going
to need to understand this code anyway.
As far as my driver, I'm in a very special case. My entire stack can
only be 4K on a 32 bit platform and 8K on a 64 bit platform (this is
AIX). So, in my case, I can preallocate a page and be pretty sure
that I'll have enough. That is what I will likely end up doing. The
only calls to malloc and free are from the exception handlers. The
rest of the code will call other allocation services: xmalloc,
net_malloc, etc. But I agree that this may be hard to do in the
general case. But I'd like to look into it.
As far as crsahing the kernel -- I see that as a feature. Pretending
to solve an exception (or even if it was a setjmp/longjmp) that has
not been explicitly thought about is just fooling yourself. So often
code does not really do the right thing in drivers when an allocation
fails (or when anything fails for that matter). That is why I see
exception handling such a beautiful thing. I may rue the day I
branched off into this endeavor but, it won't be the first time :-)
Thanks,
Perry
