Hi Johan, Srini, On 19 June 2018 at 15:06, Johan Hovold <jo...@kernel.org> wrote: > On Tue, Jun 19, 2018 at 02:32:11PM +0200, Loic Poulain wrote: >> Hi Johan, Srini, >> >> On 18 June 2018 at 11:47, Srinivas Kandagatla >> <srinivas.kandaga...@linaro.org> wrote: >> > On 18/06/18 09:46, Johan Hovold wrote: > >> >> I'm not necessarily against the idea, but nvmem core needs to be fixed >> >> so that it can handle hotplugging before this can be considered for >> >> merging. >> >> >> >> Right now it just returns -EBUSY from nvmem_unregister(), which results >> >> in all kinds of memory leaks, use-after-frees and crashes when user >> >> space holds the character device open while the device is being >> >> unplugged. >> >> Correct me if I'm wrong, but nvmem is just exposed to userspace as a >> simple sysfs device attribute (nvmem), removing a device and its attribute(s) >> dynamically is well managed by sysfs, even if userspace has file open. > > My bad, I misremembered what interface nvmem was using and only saw the > deregistration refusal in nvmem_unregister() during a quick check. > >> The only risk here is when a kernel internal consumer still has a reference >> to >> the nvmem device on removal, which is not the case in our context. > > Right. > >> > I can also suggest you to try devm_nvmem_register(). >> >> Yes, I'm going to send a v2. > > I'll take a closer look soonish too.
I changed my mind here, indeed, in order to avoid any potential use-after-free, we have to manually unregister/release the nvmem device before freeing of the private port structure (used as nvmem context). So I will not send a V2 with nvmem devm usage. You can consider this V1 for review. Regards, Loic -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
