> ----- Original Message ----- > From: "Alan Stern" <stern@xxxxxxxxxxxxxxxxxxx> > To: "Erin Teran" <erin_teran@xxxxxxxxxxxxx> > Cc: postme1@xxxxxxx, "USB list" <linux-usb@xxxxxxxxxxxxxxx> > Subject: Re: USB gadget problem with close of a gadgetfs device > Date: Mon, 9 Feb 2009 10:18:53 -0500 (EST) > > > On Mon, 9 Feb 2009, Erin Teran wrote: > > > Hello, > > > > I had a look into the poll() fix and the open file descriptor issue. > > > > I added the fix, but the section with the fix is never called. > > > > I also found a way to get the open count in dev_open() of inode.c. > > Using atom_read(&fd->f_count) I see a count of 1 when the problem occurs. > > Is that good or bad? What do you see when the problem doesn't occur? Well if the problem doesnt occur I see nothing, meaning the count is 0. > > > Anyone got a clue when this counter is increased - only when > > dev_open() returns successfully or when the app calls open()? > > It probably gets incremented when a process forks or clones itself. > The only way to find out for sure is to search through the kernel > source for occurrences of f_count. I feared that would be the answer ;). Better asume the application is doing things wrong than start browsing the kernel for days. > > > So it seems I have to find a missing open fd. > > Yes. Well, nothing new here. I cant find the missing fd. There is no forking or cloning in my code. The only way I can see that an aditional reference to the fd is created is the poll() call. If poll() does a dup of the fd provided it increases the reference count in the kernel. Shouldn't this duped fd be freed again after leaving the poll() system call? I'm kinda lost here. > Alan Stern > = -- Powered by Outblaze -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
