linux-kernel - Re: [PATCH 01/19] char_dev: replace cdev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 Aug 2020 10:53:53 +0200
From:   Christoph Hellwig <hch@....de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Denis Efremov <efremov@...ux.com>,
        "David S. Miller" <davem@...emloft.net>,
        Song Liu <song@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-ide@...r.kernel.org, linux-raid@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-m68k@...ts.linux-m68k.org
Subject: Re: [PATCH 01/19] char_dev: replace cdev_map with an xarray

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 <hch@....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).