Problems with use of M_NOWWAIT in ATA

[Matthew Dillon]

:On Fri, Dec 05, 2003 at 11:15:20AM -0500, Dwayne MacKinnon wrote:
:> Hi,
:>=20
:> I'm wondering if this could possibly be related to a problem I was=20
:> having with my 4.9-RELEASE box. Twice in two days it hung on me=20
:> completely, and started spouting the following error messages:
:
:Well, the error condition Matt is talking about only occurs if you had
:run your system completely out of kernel memory.  That's not likely;
:far more likely is that you have a dodgy drive, controller or cabling.
:
:Kris

    Dwayne's problem is not likely to be related unless there is another
    memory related bug that I haven't found yet.

    --

    Actually Kris's comment isn't quite correct.  You don't have to run the
    system completely out of memory for malloc(M_NOWAIT) to fail.  The system
    simply needs to run out of free pages (if called from an interrupt), or
    free+cache pages (if called from a non-interrupt).  Also, non-interrupt
    allocations will not eat into the free page list beyond a certain
    point because a number of pages have to be reserved for interrupt based
    allocations.

    For example, you could have a ton of pages in the cache but not a one
    of these can be touched by an interrupt, and you could have minimal or
    no pages in the cache but a ton of inactive pages and M_NOWAIT will
    return NULL because, obviously, it isn't going to wait for the 
    page daemon to recycle some pages.

    So it is far easier to temporarily run the system out of memory such
    that M_NOWAIT causes malloc() to return NULL then I guess most people
    expect.  That's why M_NOWAIT should only be used in situations where
    NULL can actually be returned without fragging the system up.  That is
    not how it is being used in the ATA driver.

    Now it is possible that the SLAB allocator works somewhat differently
    in 5.x, but I think the VM page queue issues still stand even there.

						-Matt