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-nakah...@iij.ad.jp>