cvs commit: src/sys/netinet sctp_input.c

[Simon 'corecode' Schubert]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00011.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: This is a digitally signed message part"
URL: <http://lists.dragonflybsd.org/pipermail/commits/attachments/20050811/8efc3c4e/attachment-0022.obj>