On Mon, 18 Jan 1999, Mike Smith wrote:
> > >If the system is simply low on memory, kmem_malloc() will block.
> > >
> > >So malloc() will generally not return NULL even in low memory
> > > situations
> > >unless the KVM map fills up, which isn't supposed to happen but can in
> > >c
On Tue, 19 Jan 1999, Bruce Evans wrote:
> >Look at the void () functions that call malloc/MALLOC. Also, commit the
> >attached patch; it was OKed by Bruce to disallow this, but he seems to forget
> >to commit it.
>
> It is queued behind 10-100 other patches.
>
> >--- src/sys/kern/vfs_syscalls.c.
> >If the system is simply low on memory, kmem_malloc() will block.
> >
> >So malloc() will generally not return NULL even in low memory situations
> >unless the KVM map fills up, which isn't supposed to happen but can in
> >certain severe circumstances. Callers should therefore ch
>Look at the void () functions that call malloc/MALLOC. Also, commit the
>attached patch; it was OKed by Bruce to disallow this, but he seems to forget
>to commit it.
It is queued behind 10-100 other patches.
>--- src/sys/kern/vfs_syscalls.c.orig Fri Dec 25 22:27:21 1998
>+++ src/sys/kern/vfs_s
> On Mon, 18 Jan 1999, Mike Smith wrote:
>
> > > > So malloc() will generally not return NULL even in low memory
> > > > situations
> > > > unless the KVM map fills up, which isn't supposed to happen but can
> > > > in
> > > > certain severe circumstances. Callers should therefore c
>> Of course not. It is fundamental that malloc(..., M_WAITOK) either
>> succeeds or panics. Most callers depend on this and don't check for
>> success. The others are bogus.
>
>actually it turns out to be true..
Actually not.
>see other email from matt.
See my corrections to that mail.
Bruc
>It looks like malloc() can return NULL if the kmem_malloc() fails.
Not for the M_WAITOK case.
>kmem_malloc() can only fail in the M_WAITOK case if the KVM map is full.
kmem_malloc() panics in this case (except for map == mb_map; the mbuf
allocator has special handling for this problem).
On Tue, 19 Jan 1999, Bruce Evans wrote:
> >There was some talk about the fact that malloc(..M_CANWAIT)
> >can now return with a failure.
>
> You mean M_WAITOK.
yes.. a braino..
(I corrected in later mail)
>
> >Is that true?
>
> Of course not. It is fundamental that malloc(..., M_WAITOK) eit
> > why not just put it in a loop and block on lbolt?
> > (or call panic)
>
> Because you shouldn't panic unless there's no alternative. Panicking
> on resource starvation is just totally lame.
We haven't used up the kernel name space yet. This sort of
fundamental change should be enabled by a
>There was some talk about the fact that malloc(..M_CANWAIT)
>can now return with a failure.
You mean M_WAITOK.
>Is that true?
Of course not. It is fundamental that malloc(..., M_WAITOK) either
succeeds or panics. Most callers depend on this and don't check for
success. The others are bogus.
On Mon, 18 Jan 1999, Mike Smith wrote:
> > > So malloc() will generally not return NULL even in low memory
> > > situations
> > > unless the KVM map fills up, which isn't supposed to happen but can in
> > > certain severe circumstances. Callers should therefore check for
> > > NULL.
> > So malloc() will generally not return NULL even in low memory situations
> > unless the KVM map fills up, which isn't supposed to happen but can in
> > certain severe circumstances. Callers should therefore check for NULL.
>
> why not just put it in a loop and block on lbolt?
> (o
> > > There was some talk about the fact that malloc(..M_CANWAIT)
> oops M_WAITOK..
>
> > > can now return with a failure. Is that true?
> >
> > Yes; it's necessary to do this to allow some chance of avoiding
> > deadlock.
>
> I can't find this in the archives.. can you remember
> a keyword th
On Mon, 18 Jan 1999, Matthew Dillon wrote:
> :> > There was some talk about the fact that malloc(..M_CANWAIT)
> :> > can now return with a failure. Is that true?
> :>
> :> Yes; it's necessary to do this to allow some chance of avoiding
> :> deadlock.
> :
> :Ouch! Is everything in src-sys already
On Mon, 18 Jan 1999, Mike Smith wrote:
> >
> > Here at whistle we are trying to remember about a conversation
> > regarding malloc that occured recently. Maybe others can help.
> >
> > There was some talk about the fact that malloc(..M_CANWAIT)
oops M_WAITOK..
> > can now return with a failur
:> > There was some talk about the fact that malloc(..M_CANWAIT)
:> > can now return with a failure. Is that true?
:>
:> Yes; it's necessary to do this to allow some chance of avoiding
:> deadlock.
:
:Ouch! Is everything in src-sys already checking the return value of an
M_WAITOK?
:
: Brian Feld
On Mon, 18 Jan 1999, Mike Smith wrote:
> > On Mon, 18 Jan 1999, Mike Smith wrote:
> >
> > > >
> > > > Here at whistle we are trying to remember about a conversation
> > > > regarding malloc that occured recently. Maybe others can help.
> > > >
> > > > There was some talk about the fact that mal
> On Mon, 18 Jan 1999, Mike Smith wrote:
>
> > >
> > > Here at whistle we are trying to remember about a conversation
> > > regarding malloc that occured recently. Maybe others can help.
> > >
> > > There was some talk about the fact that malloc(..M_CANWAIT)
> > > can now return with a failure.
On Mon, 18 Jan 1999, Mike Smith wrote:
> >
> > Here at whistle we are trying to remember about a conversation
> > regarding malloc that occured recently. Maybe others can help.
> >
> > There was some talk about the fact that malloc(..M_CANWAIT)
> > can now return with a failure. Is that true?
>
>
> Here at whistle we are trying to remember about a conversation
> regarding malloc that occured recently. Maybe others can help.
>
> There was some talk about the fact that malloc(..M_CANWAIT)
> can now return with a failure. Is that true?
Yes; it's necessary to do this to allow some chance o
20 matches
Mail list logo
