On Thu, Jul 30, 2020 at 10:44 AM Jim Quinlan <james.quin...@broadcom.com> wrote: > > On Wed, Jul 29, 2020 at 10:28 AM Rob Herring <robh...@kernel.org> wrote: > > > > On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig <h...@lst.de> wrote: > > > > > > On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote: > > > > I started using devm_kcalloc() but at least two reviewers convinced me > > > > to just use kcalloc(). In addition, when I was using devm_kcalloc() > > > > it was awkward because 'dev' is not available to this function. > > > > > > > > It comes down to whether unbind/binding the device N times is actually > > > > a reasonable usage. As for my experience I've seen two cases: (1) my > > > > overnight "bind/unbind the PCIe RC driver" script, and we have a > > > > customer who does an unbind/bind as a hail mary to bring back life to > > > > their dead EP device. If the latter case happens repeatedly, there > > > > are bigger problems. > > > > > > We can't just leak the allocations. Do you have a pointer to the > > > arguments against managed resources? I'm generally not a huge fan > > > of the managed resources, but for a case like this they actually seem > > > useful. If we don't use the managed resources we'll at leat need > > > to explicitly free the resources when freeing the device. > > > > The lifetime for devm_kcalloc may not be what we want here. devm > > allocs are freed on probe fail or remove, not on freeing the device > > (there is a just in case free there too though). > > What do you suggest doing as an alternative?
I believe I gave it already. Put a kfree in the struct device release function. But you can't be passing the pointer from device to device if you go that route. You'd have to either copy the struct or check if it's the same as the parent's and skip the kfree in that case. Rob _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
