On Wed, Aug 26, 2020 at 10:19:05AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 26, 2020 at 08:24:28AM +0200, Christoph Hellwig wrote:
> > None of the complicated overlapping regions bits of the kobj_map are
> > required for the character device lookup, so just a trivial xarray
> > instead.
> >
> > Signed-off-by: Christoph Hellwig <h...@lst.de>
>
> Really? This is ok to use and just as fast? If so, wonderful, it would
> be great to clean up kobj_map users.
Xarrays provide pretty efficient as long as we have a unsigned long
or smaller index (check, dev_t is small) and the indices are reasonable
clustered (check, minors for the same major). Memory usage will go down
vs the probes, and lookup speed up.
> > + mutex_lock(&chrdevs_lock);
> > + for (i = 0; i < count; i++) {
> > + error = xa_insert(&cdev_map, dev + i, p, GFP_KERNEL);
> > + if (error)
> > + goto out_unwind;
> > + }
> > + mutex_unlock(&chrdevs_lock);
> >
> > kobject_get(p->kobj.parent);
>
> Can't you drop this kobject_get() too?
I'll have to drop it or add back the put on the delete side. And
I think the latter is safer for now, because..
>
> And also the "struct kobj" in struct cdev can be gone as well, as the
> kobj_map was the only "real" user of this structure. I know some
> drivers liked to touch that field as well, but it never actually did
> anything for them, so it was pointless, but it will take some 'make
> allmodconfig' builds to flush them out.
I looked at it, but it does get registered and shows up in sysfs.
I don't really dare to touch this for now, as it can have huge
implications. Better done in a separate series (if we can actually do
it at all).
