Besides wrong (malloc(9) doesn't fail with M_WAITOK unless M_CANFAIL
is specified; it panic(9)s instead if the request is too big, FSVO
"too big", or hangs ~forever), at least the uipc_syscalls.c:sockargs()
change is completely bogus and should be backed off; buflen is
checked to be <= PAGE_SIZE on start of the function.

The change for uipc_usrreq.c seems to be only partially bogus.
Two of the three changed MEXTMALLOC() can only try to allocate up
to 256 bytes due to limited size of sun_len field (u_int8_t). The
third in unp_addsockcred() requires a bit of analysis to decide
whether or not the 'space' is bounded. My guess is that the size
is guaranteed to be <= PAGE_SIZE too, since the mbuf should be created by
sockargs() when the sender passes the message to kernel. But apparently
a bit of analysis must be done here to be sure.

Can you please back the change off and explain what exactly this
attempts to fix?

Jaromir

Jun-ichiro itojun Hagino wrote:
> 
> Module Name:	syssrc
> Committed By:	itojun
> Date:		Mon Nov 25 06:32:39 UTC 2002
> 
> Modified Files:
> 	syssrc/sys/kern: uipc_syscalls.c uipc_usrreq.c
> 
> Log Message:
> MEXTMALLOC() can fail even if M_WAITOK, if arg is too big for malloc().
> 
> 
> To generate a diff of this commit:
> cvs rdiff -r1.71 -r1.72 syssrc/sys/kern/uipc_syscalls.c
> cvs rdiff -r1.54 -r1.55 syssrc/sys/kern/uipc_usrreq.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 


-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-