search for: ports_list

...drvdata.class, port->dev->devt); > + cdev_del(port->cdev); > + > + kfree(port->name); > + > + debugfs_remove(port->debugfs_file); > + > /* > * Locks around here are not necessary - a port can't be > * opened after we removed the port struct from ports_list Should we remove debugfs file before kfree()? Otherwise looks like a use-after-free if user access debugfs after kfree().

...drvdata.class, port->dev->devt); > + cdev_del(port->cdev); > + > + kfree(port->name); > + > + debugfs_remove(port->debugfs_file); > + > /* > * Locks around here are not necessary - a port can't be > * opened after we removed the port struct from ports_list Should we remove debugfs file before kfree()? Otherwise looks like a use-after-free if user access debugfs after kfree().

...cdev); >>> + >>> + kfree(port->name); >>> + >>> + debugfs_remove(port->debugfs_file); >>> + >>> /* >>> * Locks around here are not necessary - a port can't be >>> * opened after we removed the port struct from ports_list >> Should we remove debugfs file before kfree()? Otherwise looks like a >> use-after-free if user access debugfs after kfree(). > It is removed before kfree() -- kfree() is called in remove_port(), > which is called when all the references are dropped. (Did you confuse > kfree...

...cdev); >>> + >>> + kfree(port->name); >>> + >>> + debugfs_remove(port->debugfs_file); >>> + >>> /* >>> * Locks around here are not necessary - a port can't be >>> * opened after we removed the port struct from ports_list >> Should we remove debugfs file before kfree()? Otherwise looks like a >> use-after-free if user access debugfs after kfree(). > It is removed before kfree() -- kfree() is called in remove_port(), > which is called when all the references are dropped. (Did you confuse > kfree...

...gt; + cdev_del(port->cdev); > > + > > + kfree(port->name); > > + > > + debugfs_remove(port->debugfs_file); > > + > > /* > > * Locks around here are not necessary - a port can't be > > * opened after we removed the port struct from ports_list > > Should we remove debugfs file before kfree()? Otherwise looks like a > use-after-free if user access debugfs after kfree(). It is removed before kfree() -- kfree() is called in remove_port(), which is called when all the references are dropped. (Did you confuse kfree(port->name)...

...amp;port_attribute_group); + device_destroy(pdrvdata.class, port->dev->devt); + cdev_del(port->cdev); + + kfree(port->name); + + debugfs_remove(port->debugfs_file); + /* * Locks around here are not necessary - a port can't be * opened after we removed the port struct from ports_list -- 1.8.1.4

...amp;port_attribute_group); + device_destroy(pdrvdata.class, port->dev->devt); + cdev_del(port->cdev); + + kfree(port->name); + + debugfs_remove(port->debugfs_file); + /* * Locks around here are not necessary - a port can't be * opened after we removed the port struct from ports_list -- 1.8.1.4

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a while, and I ensure there are no regressions

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a while, and I ensure there are no regressions

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches

Hey Rusty, These are the patches that rework a few bits to make hot-unplug while ports are open not crash apps (or kernels). The problem is when hot-unplug is performed when a port is open, the cdev struct is kept around by the file pointers and when the app later does a 'close', things go boom-boom. This patch series makes sure port as well as device hot-unplug is now safe to perform

Hey Rusty, These are the patches that rework a few bits to make hot-unplug while ports are open not crash apps (or kernels). The problem is when hot-unplug is performed when a port is open, the cdev struct is kept around by the file pointers and when the app later does a 'close', things go boom-boom. This patch series makes sure port as well as device hot-unplug is now safe to perform