On 11.08.2005, at 19:30, Matthew Dillon wrote:
I think Joerg is right... the functionality of the code should
not be changed in cases where we do not completely understand the
context in which the code operates.
Of course. This is the reason why I read all important surounding code.
In this case the code clearly has a bug... it is calling MALLOC
with M_NOWAIT and not bothering to check for a NULL result. The
original code clearly intends the malloc to succeed, and we have
no idea what to do if it didn't, so that M_NOWAIT should be changed
to M_INTWAIT for now. It's better to do it this way then change
the code paths and have to track down weird bugs n the sctp state
later on.
This code is being called from sctp_input(), and I'm not sure if we can block in there. Could somebody enlighten me? Other protocol handlers usually drop the packets. One thing is sure: panicing is not appropriate.
There is a great deal of code inherited from FreeBSD that made similar assumptions and I would not be surprised if the misuse ofmalloc has migrated to other projects. In FreeBSD, M_NOWAIT mallocs usually do not fail and these cases tend to slide by. But in DragonFlyM_NOWAIT mallocs can easily fail.
Yes I know, this is why I started auditing the kernel for such malloc bugs.
cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low $$$ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
PGP.sig
Description: This is a digitally signed message part
