Since it's totally backwards compatible and serves a need we have
I say go for it.  :)

    -- Lennart

Jaromir Dolecek wrote:

> Hi,
> I'd like to add a flag which would say malloc(9) to fail
> in M_WAITOK case, if the memory can't ever be allocated (we currently
> panic() in this case).
>
> In almost every case, it's a kernel code problem if it tries to allocate
> huge chunks of memory. In majority of such cases, kernel code failed
> to do proper bound checking and let invalid values slip through. Thus,
> the panic in malloc(9) for M_WAITOK case when uvm_km_kmemalloc() fails
> is reasonable and should stay.
>
> However, in some cases, we don't want to use any arbitrary
> limits, and can recover easily if the memory is not available.
>
> One such case is e.g. the thing reported in kern/14721. The problem
> there is that we generally want to allow as many open files per-process
> as configured by administrator and physically possible by available
> resources. However, if the code which expands the process file descriptor
> array would hit the physical memory barrier, malloc() would just panic
> ATM. Rather than panic, it would be preferable if the code would fail
> gracefully in such case.
>
> Opinions about this flag? Of course, it's use would be discouradged,
> since it can hide real kernel bugs. However something like that would
> be useful option to have in some special cases.
>
> One thing to consider is whether we want a userland process
> to cut considerable amount of KVA for it's structures.
>
> Jaromir