On Mon, Jan 07, 2019 at 10:35:30AM +0000, Peter Maydell wrote: > On Mon, 7 Jan 2019 at 10:22, Gerd Hoffmann <kra...@redhat.com> wrote: > > > > On Thu, Jan 03, 2019 at 05:31:13AM -0800, Li Qiang wrote: > > > Spotted by Coverity: CID 1397070 > > > > #ifdef CONFIG_INOTIFY1 > > > @@ -682,6 +683,7 @@ static void usb_mtp_object_readdir(MTPState *s, > > > MTPObject *o) > > > usb_mtp_add_child(s, o, entry->d_name); > > > } > > > closedir(dir); > > > + close(fd); > > > > Not fully sure this is correct. > > > > The fdopendir manpage says the app should not use fd any more after > > successfully calling fdopendir(), and I assumed that includes calling > > close(). > > Yes. The POSIX spec is clearer: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/fdopendir.html > "Upon successful return from fdopendir(), the file descriptor is under > the control of the system, and if any attempt is made to close the file > descriptor, or to modify the state of the associated description, other > than by means of closedir(), readdir(), readdir_r(), rewinddir(), or > seekdir(), the behavior is undefined. Upon calling closedir() the file > descriptor shall be closed."
Thanks for looking it up. Patch added to usb queue, with the second chunk dropped. cheers, Gerd
