| Message ID | 1449265765-9393-2-git-send-email-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko wrote: > The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of > a probe failure. In the result there might be problems, such as some resources > that had been allocated will continue to be allocated and therefore lead to a > resource leak. > > Introduce a new notification to inform the subscriber that ->probe() failed. Do > the same in case of failed device_bind_driver() call. Ugh, I hate all these notifiers, but this one does make sense... Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko wrote: >> The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of >> a probe failure. In the result there might be problems, such as some resources >> that had been allocated will continue to be allocated and therefore lead to a >> resource leak. >> >> Introduce a new notification to inform the subscriber that ->probe() failed. Do >> the same in case of failed device_bind_driver() call. > > Ugh, I hate all these notifiers, but this one does make sense... Yeah, I'm not a fan of them either. > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> You meant Acked-by, didn't you?
On Sat, Dec 05, 2015 at 06:24:05PM +0200, Andy Shevchenko wrote: > On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko wrote: > >> The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of > >> a probe failure. In the result there might be problems, such as some resources > >> that had been allocated will continue to be allocated and therefore lead to a > >> resource leak. > >> > >> Introduce a new notification to inform the subscriber that ->probe() failed. Do > >> the same in case of failed device_bind_driver() call. > > > > Ugh, I hate all these notifiers, but this one does make sense... > > Yeah, I'm not a fan of them either. > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > You meant Acked-by, didn't you? Either works :) -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday, December 05, 2015 08:36:22 AM Greg Kroah-Hartman wrote: > On Sat, Dec 05, 2015 at 06:24:05PM +0200, Andy Shevchenko wrote: > > On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman > > <gregkh@linuxfoundation.org> wrote: > > > On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko wrote: > > >> The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of > > >> a probe failure. In the result there might be problems, such as some resources > > >> that had been allocated will continue to be allocated and therefore lead to a > > >> resource leak. > > >> > > >> Introduce a new notification to inform the subscriber that ->probe() failed. Do > > >> the same in case of failed device_bind_driver() call. > > > > > > Ugh, I hate all these notifiers, but this one does make sense... > > > > Yeah, I'm not a fan of them either. > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > You meant Acked-by, didn't you? > > Either works :) Thanks! Andy, what about if I put patches [1-6/9] into my queue for v4.5 now and the remaining ones will wait for Vinod to comment? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2015-12-07 at 02:31 +0100, Rafael J. Wysocki wrote: > On Saturday, December 05, 2015 08:36:22 AM Greg Kroah-Hartman wrote: > > On Sat, Dec 05, 2015 at 06:24:05PM +0200, Andy Shevchenko wrote: > > > On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman > > > <gregkh@linuxfoundation.org> wrote: > > > > On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko > > > > wrote: > > > > > The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any > > > > > cleanup in case of > > > > > a probe failure. In the result there might be problems, such > > > > > as some resources > > > > > that had been allocated will continue to be allocated and > > > > > therefore lead to a > > > > > resource leak. > > > > > > > > > > Introduce a new notification to inform the subscriber that > > > > > ->probe() failed. Do > > > > > the same in case of failed device_bind_driver() call. > > > > > > > > Ugh, I hate all these notifiers, but this one does make > > > > sense... > > > > > > Yeah, I'm not a fan of them either. > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > You meant Acked-by, didn't you? > > > > Either works :) > > Thanks! > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now > and > the remaining ones will wait for Vinod to comment? Yes, it's possible, but please don't forget the patch from http://www.s pinics.net/lists/kernel/msg2119229.html. There also formally Acks from Thomas and Ong, Boon Leong. > > Thanks, > Rafael >
On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote: > On Mon, 2015-12-07 at 02:31 +0100, Rafael J. Wysocki wrote: > > On Saturday, December 05, 2015 08:36:22 AM Greg Kroah-Hartman wrote: > > > On Sat, Dec 05, 2015 at 06:24:05PM +0200, Andy Shevchenko wrote: > > > > On Sat, Dec 5, 2015 at 6:14 PM, Greg Kroah-Hartman > > > > <gregkh@linuxfoundation.org> wrote: > > > > > On Fri, Dec 04, 2015 at 11:49:17PM +0200, Andy Shevchenko > > > > > wrote: > > > > > > The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any > > > > > > cleanup in case of > > > > > > a probe failure. In the result there might be problems, such > > > > > > as some resources > > > > > > that had been allocated will continue to be allocated and > > > > > > therefore lead to a > > > > > > resource leak. > > > > > > > > > > > > Introduce a new notification to inform the subscriber that > > > > > > ->probe() failed. Do > > > > > > the same in case of failed device_bind_driver() call. > > > > > > > > > > Ugh, I hate all these notifiers, but this one does make > > > > > sense... > > > > > > > > Yeah, I'm not a fan of them either. > > > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > You meant Acked-by, didn't you? > > > > > > Either works :) > > > > Thanks! > > > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now > > and > > the remaining ones will wait for Vinod to comment? > > Yes, it's possible, but please don't forget the patch from http://www.s > pinics.net/lists/kernel/msg2119229.html. There also formally Acks from > Thomas and Ong, Boon Leong. Well, if Thomas prefers to take this one into tip, I guess the series should go along with it or wait for when that one is merged. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 7 Dec 2015, Rafael J. Wysocki wrote: > On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote: > > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now > > > and > > > the remaining ones will wait for Vinod to comment? > > > > Yes, it's possible, but please don't forget the patch from http://www.s > > pinics.net/lists/kernel/msg2119229.html. There also formally Acks from > > Thomas and Ong, Boon Leong. > > Well, if Thomas prefers to take this one into tip, I guess the series should > go along with it or wait for when that one is merged. Works either way. I have no changes pending against that iosf_mbi stuff. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 8, 2015 at 4:05 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Tuesday, December 08, 2015 02:32:00 PM Thomas Gleixner wrote: >> On Mon, 7 Dec 2015, Rafael J. Wysocki wrote: >> > On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote: >> > > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now >> > > > and >> > > > the remaining ones will wait for Vinod to comment? >> > > >> > > Yes, it's possible, but please don't forget the patch from http://www.s >> > > pinics.net/lists/kernel/msg2119229.html. There also formally Acks from >> > > Thomas and Ong, Boon Leong. >> > >> > Well, if Thomas prefers to take this one into tip, I guess the series should >> > go along with it or wait for when that one is merged. >> >> Works either way. I have no changes pending against that iosf_mbi stuff. > Thanks, Thomas! > Cool. I'll take that patch and the series then. Please, also put patch 5 before patch 4. It will go smoothly, or I can send an updated version.
On Tuesday, December 08, 2015 02:32:00 PM Thomas Gleixner wrote: > On Mon, 7 Dec 2015, Rafael J. Wysocki wrote: > > On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote: > > > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now > > > > and > > > > the remaining ones will wait for Vinod to comment? > > > > > > Yes, it's possible, but please don't forget the patch from http://www.s > > > pinics.net/lists/kernel/msg2119229.html. There also formally Acks from > > > Thomas and Ong, Boon Leong. > > > > Well, if Thomas prefers to take this one into tip, I guess the series should > > go along with it or wait for when that one is merged. > > Works either way. I have no changes pending against that iosf_mbi stuff. Cool. I'll take that patch and the series then. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 9, 2015 at 3:20 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > I've put the entire series (including the three last patches with Vinod's ACKs) > into my bleeding-edge branch, please check it in there and let me know if > anything is not right. I just have checked, everything looks good. Thank you, Rafael!
On Tuesday, December 08, 2015 03:50:06 PM Andy Shevchenko wrote: > On Tue, Dec 8, 2015 at 4:05 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Tuesday, December 08, 2015 02:32:00 PM Thomas Gleixner wrote: > >> On Mon, 7 Dec 2015, Rafael J. Wysocki wrote: > >> > On Monday, December 07, 2015 12:57:33 PM Andy Shevchenko wrote: > >> > > > Andy, what about if I put patches [1-6/9] into my queue for v4.5 now > >> > > > and > >> > > > the remaining ones will wait for Vinod to comment? > >> > > > >> > > Yes, it's possible, but please don't forget the patch from http://www.s > >> > > pinics.net/lists/kernel/msg2119229.html. There also formally Acks from > >> > > Thomas and Ong, Boon Leong. > >> > > >> > Well, if Thomas prefers to take this one into tip, I guess the series should > >> > go along with it or wait for when that one is merged. > >> > >> Works either way. I have no changes pending against that iosf_mbi stuff. > > > > Thanks, Thomas! > > > Cool. I'll take that patch and the series then. > > Please, also put patch 5 before patch 4. It will go smoothly, It didn't, but that's not a big deal. > or I can send an updated version. No need. I've put the entire series (including the three last patches with Vinod's ACKs) into my bleeding-edge branch, please check it in there and let me know if anything is not right. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 8d4eb4d..7399be7 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -299,6 +299,9 @@ int device_bind_driver(struct device *dev) ret = driver_sysfs_add(dev); if (!ret) driver_bound(dev); + else if (dev->bus) + blocking_notifier_call_chain(&dev->bus->p->bus_notifier, + BUS_NOTIFY_DRIVER_NOT_BOUND, dev); return ret; } EXPORT_SYMBOL_GPL(device_bind_driver); @@ -332,7 +335,7 @@ static int really_probe(struct device *dev, struct device_driver *drv) /* If using pinctrl, bind pins now before probing */ ret = pinctrl_bind_pins(dev); if (ret) - goto probe_failed; + goto pinctrl_bind_failed; if (driver_sysfs_add(dev)) { printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n", @@ -376,6 +379,10 @@ static int really_probe(struct device *dev, struct device_driver *drv) goto done; probe_failed: + if (dev->bus) + blocking_notifier_call_chain(&dev->bus->p->bus_notifier, + BUS_NOTIFY_DRIVER_NOT_BOUND, dev); +pinctrl_bind_failed: devres_release_all(dev); driver_sysfs_remove(dev); dev->driver = NULL; @@ -749,7 +756,6 @@ static void __device_release_driver(struct device *dev) blocking_notifier_call_chain(&dev->bus->p->bus_notifier, BUS_NOTIFY_UNBOUND_DRIVER, dev); - } } diff --git a/include/linux/device.h b/include/linux/device.h index b8f411b..f627ba2 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -191,6 +191,7 @@ extern int bus_unregister_notifier(struct bus_type *bus, unbound */ #define BUS_NOTIFY_UNBOUND_DRIVER 0x00000007 /* driver is unbound from the device */ +#define BUS_NOTIFY_DRIVER_NOT_BOUND 0x00000008 /* driver fails to be bound */ extern struct kset *bus_get_kset(struct bus_type *bus); extern struct klist *bus_get_device_klist(struct bus_type *bus);
The users of BUS_NOTIFY_BIND_DRIVER have no chance to do any cleanup in case of a probe failure. In the result there might be problems, such as some resources that had been allocated will continue to be allocated and therefore lead to a resource leak. Introduce a new notification to inform the subscriber that ->probe() failed. Do the same in case of failed device_bind_driver() call. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- drivers/base/dd.c | 10 ++++++++-- include/linux/device.h | 1 + 2 files changed, 9 insertions(+), 2 deletions(-)