NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/50810: Kernel page fault trap in ugenclose()

The following reply was made to PR kern/50810; it has been noted by GNATS.

From: Nick Hudson <>
To: Andreas Gustafsson <>,
Subject: Re: kern/50810: Kernel page fault trap in ugenclose()
Date: Sat, 20 Feb 2016 17:12:24 +0000

 On 02/20/16 11:11, Andreas Gustafsson wrote:
 > Nick Hudson wrote:
 >>   The ioctl (USB_SET_ALTINTERFACE) is blatting edesc and making it fail
 >>   Not sure why it's doing this before closing the endpoints.
 >>   Maybe the ioctl should fail here?
 > I'm having some trouble following your comment.
 Sorry for being unclear....
 > - What do you mean by "blatting"?  The dictionary
 >    I consulted was not helpful.
 overwriting / erasing
 > - In "why it's doing this", what does "it" refer to?
 > - At what point should the ioctl fail, and why would it make
 >    a difference?
 > I see there is a comment in ugen_set_interface() saying /* XXX should
 > only do this after setting new altno has succeeded */, which seems to
 > point at a possible cause of the bug: If setting the new altno fails,
 > sce->edesc will be NULL, but sce->pipeh has not been cleared, so if it
 > was not NULL to begin, with we have the exact combination of
 > conditions (sce->pipeh != NULL && sce->edesc == NULL) that triggers
 > the crash in ugenclose().
 You got what I meant here.
 > Also, there are several places checking for sce == NULL, for example:
 >     sce = &sc->sc_endpoints[UGENENDPOINT(dev)][IN];
 >     if (sce == NULL)
 > None of these make any sense - sce is a pointer into the middle of a
 > the ugen_softc struct, so it can *never* be NULL by definition.
 > Should they all say "sce->sc == NULL"?  What is the canonical way
 > of distinguishing a valid endpoint from an invalid one?
 I guess edesc and/or iface get populated with something after 

Home | Main Index | Thread Index | Old Index