In article <20160215212942.ga7...@spathi.chuq.com>,
Chuck Silvers wrote:
>-=-=-=-=-=-
>
>On Fri, Dec 11, 2015 at 12:16:19PM -0500, Christos Zoulas wrote:
>> On Dec 11, 8:54am, c...@chuq.com (Chuck Silvers) wrote:
>> -- Subject: Re: kernel memory allocation failures
&g
On Fri, Dec 11, 2015 at 02:02:08PM -0500, Greg Troxel wrote:
>
> Chuck Silvers writes:
>
> > On Fri, Dec 11, 2015 at 09:44:07AM -0500, Greg Troxel wrote:
> >>
> >> Chuck Silvers writes:
> >>
> >> > how about instead we fix the kmem_alloc() implementation to match the
> >> > man page?
> >> >
On Fri, Dec 11, 2015 at 12:16:19PM -0500, Christos Zoulas wrote:
> On Dec 11, 8:54am, c...@chuq.com (Chuck Silvers) wrote:
> -- Subject: Re: kernel memory allocation failures
>
> | I haven't looked see exactly what the internal conditions are that lead to
> | kmem_alloc(KM_S
On Dec 11, 7:30pm, dholland-t...@netbsd.org (David Holland) wrote:
-- Subject: Re: kernel memory allocation failures
| On Fri, Dec 11, 2015 at 11:00:06AM -0500, Christos Zoulas wrote:
| > Fixing kmem_alloc() and friends not to fail under certain conditions might
| > be possible, but it
On Fri, Dec 11, 2015 at 11:00:06AM -0500, Christos Zoulas wrote:
> Fixing kmem_alloc() and friends not to fail under certain conditions might
> be possible, but it could lead to livelock scenarios where everything is
> stuck in the kernel waiting for resources to be freed.
That's a deadlock, no
Chuck Silvers writes:
> On Fri, Dec 11, 2015 at 09:44:07AM -0500, Greg Troxel wrote:
>>
>> Chuck Silvers writes:
>>
>> > how about instead we fix the kmem_alloc() implementation to match the man
>> > page?
>> > that seems much more practical to me. adding failure checks and recovery
>> > c
On Dec 11, 8:54am, c...@chuq.com (Chuck Silvers) wrote:
-- Subject: Re: kernel memory allocation failures
| I haven't looked see exactly what the internal conditions are that lead to
| kmem_alloc(KM_SLEEP) returning NULL, so it's not clear whether having
| kmem_alloc() retry or pan
On Fri, Dec 11, 2015 at 09:44:07AM -0500, Greg Troxel wrote:
>
> Chuck Silvers writes:
>
> > how about instead we fix the kmem_alloc() implementation to match the man
> > page?
> > that seems much more practical to me. adding failure checks and recovery
> > code
> > to the thousands of *alloc
On Fri, Dec 11, 2015 at 11:00:06AM -0500, Christos Zoulas wrote:
> Fixing kmem_alloc() and friends not to fail under certain conditions might
> be possible, but it could lead to livelock scenarios where everything is
> stuck in the kernel waiting for resources to be freed.
>
> Perhaps we should ju
On Fri, Dec 11, 2015 at 11:00:06AM -0500, Christos Zoulas wrote:
> Perhaps we should just explain that it is not the responsibility of the
> caller to check for the result of kmem_alloc() in the KM_WAIT case, and
> centralize the check in kmem_alloc() to make it panic() if it would
> return NULL? I
On Dec 11, 7:25am, buh...@nfbcal.org (Brian Buhrow) wrote:
-- Subject: Re: kernel memory allocation failures
| Hello. I'm coming to this rather late, but my understanding is that
| if you use malloc() in the kernel, you need to check to make sure you have
| actually gotten that memo
Hello. I'm coming to this rather late, but my understanding is that
if you use malloc() in the kernel, you need to check to make sure you have
actually gotten that memory on return. If you use MALLOC() (upper
case), then, upon return, the memory is guaranteed to have been allocated.
What
Chuck Silvers writes:
> how about instead we fix the kmem_alloc() implementation to match the man
> page?
> that seems much more practical to me. adding failure checks and recovery code
> to the thousands of *alloc() calls in the kernel would be a vast amount of
> work
> for very little benef
On Dec 11, 6:44am, dholland-t...@netbsd.org (David Holland) wrote:
-- Subject: Re: kernel memory allocation failures
| > how about instead we fix the kmem_alloc() implementation to match
| > the man page? that seems much more practical to me. adding
| > failure checks and recover
On Thu, Dec 10, 2015 at 08:41:50PM -0800, Chuck Silvers wrote:
> > | > So I propose to always check the return value of allocators with
> > | > an 'if' and not a KASSERT.
> > |
> > | There are some codes like "foo = kmem_alloc(size, KM_SLEEP);
> > | KASSERT(foo != NULL)".
> > | Should the co
On Thu, Dec 10, 2015 at 11:00:11PM -0500, Christos Zoulas wrote:
> On Dec 11, 11:37am, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: CVS commit: src/sys/net
>
> | Hi,
> |
> | > In article <20151210081103.E0FBBFB83%cvs.NetBSD.org@localhost>,
> | > Kengo NAKAHARA wrote:
> | >>-=-=
16 matches
Mail list logo
