Re: CVS commit: src/sys/net

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

On 2016/01/13 7:10, David Laight wrote:
> On Fri, Dec 11, 2015 at 11:37:29AM +0900, Kengo NAKAHARA wrote:
>> # Sorry, I forgot to subscribe source-changes-d ml, I reply as
>> # a new mail.
>>
>> Hi,
>>
>>> In article <20151210081103.E0FBBFB83%cvs.NetBSD.org@localhost>,
>>> Kengo NAKAHARA <source-changes-d%NetBSD.org@localhost> wrote:
>>>> -=-=-=-=-=-
>>>>
>>>> Module Name:	src
>>>> Committed By:	knakahara
>>>> Date:		Thu Dec 10 08:11:03 UTC 2015
>>>>
>>>> Modified Files:
>>>> 	src/sys/net: if_gif.c
>>>>
>>>> Log Message:
>>>> kmem_zalloc(, KM_SLEEP) must not return NULL.
>>>
>>> I would like to solicit opinions about this change and form a general
>>> policy.
>>>
>>> 1. I would like to reduce the use of KASSERT in the kernel, specially
>>> in situations like thee above where the test can be centralized (inside
>>> kmem_alloc) and avoided without being fatal.
>>
>> OK, this kmem_zalloc() is not fatal. I should avoid KASSERT here.
> 
> There is no real point using KASSERT() when the immediate
> dereference of NULL will have the same effect and is about as
> easy to debug.
> 
> Whether kmem_alloc(KM_SLEEP) can return NULL is another matter.
> Seems wrong to me - maybe even for impossible allications.
> ISTR a problem waiting for KVA and phys-mem being 'difficult'.
> I know that the Linux equivalent will return NULL, not sure when.
> It would be useful to define that allocation for non-huge
> (maybe even several MB) amounts will always sleep.
> 
> 	David

Have you read this thread?
    http://mail-index.netbsd.org/tech-kern/2015/12/11/msg019762.html

I think Mr. Chuck Silvers points out a similar issue.
    http://mail-index.netbsd.org/tech-kern/2015/12/11/msg019772.html


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>