On Wed, 11 Jun 2008, James Carlson wrote: > [EMAIL PROTECTED] writes: >> and since then (1999), most such panics, if they occurred, have been >> caused by drivers passing e.g. uninitialized / unvalidated values into >> kmem_alloc() - and were fixed by fixing the driver bug. > > The distinction would be between considering -1 to be a design flaw on > the part of the caller, or part of the input range requiring a valid > response.
In the case of the driver I'm talking about, it's part of the input range (which here truly spans 0...UINTMAX_MAX, per specification). > >> to allow KM_NOSLEEP users graceful recovery ? > > I think you might need to back up a bit: who is calling this caller? > And where did the erroneous -1 come from originally? Input from a file, and the size field in question, as per specification of the file format, can have any value allowed for an unsigned 64bit integer. It seems to me that the driver, from its point of view, does the right thing - do a best-possible attempt via KM_NOSLEEP if it finds the size field too large. Adding another "way too large" check seems wrong, who says what's "way too large" ... FrankH. _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
