Re: cvs commit: src/sys/netinet sctp_input.c

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

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 of
>     malloc has migrated to other projects.  In FreeBSD, M_NOWAIT 
> mallocs
>     usually do not fail and these cases tend to slide by.  But in 
> DragonFly
>     M_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   / \

Attachment: PGP.sig
Description: This is a digitally signed message part