linux-kernel - Re: [PATCH] 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]

Message-ID: <X/yZ6wtNYJEniwC0@kroah.com>
Date:   Mon, 11 Jan 2021 19:33:15 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] char_dev: replace cdev_map with an xarray

On Mon, Jan 11, 2021 at 06:20:29PM +0000, Matthew Wilcox wrote:
> On Mon, Jan 11, 2021 at 07:11:25PM +0100, Greg KH wrote:
> > On Mon, Jan 11, 2021 at 05:35:00PM +0000, Matthew Wilcox wrote:
> > > On Mon, Jan 11, 2021 at 06:05:13PM +0100, 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.
> > > 
> > > Thanks for doing this.  We could make it more efficient for chardevs
> > > that occupy 64 or more consecutive/aligned devices -- is it worth doing?
> > 
> > efficient in what way?  Space or faster lookup?
> 
> Both, but primarily space.
> 
> The radix tree underlying the xarray allows N consecutive entries with
> the same value to be represented as a single entry; if there are at
> least 64 entries then we get to skip an entire level of the tree (saving
> 1/7 of a page).  Of course, we'd need to go from the 'head' pointer to
> the correct pointer, something like p += rdev - p->rdev.

How much "space" are you talking about here?

A "normal" machine has about 100-200 char devices.  Servers, maybe more,
but probably not.

The kobject being used previously wasn't really "small" at all, so odds
are any conversion to not use it like this will be better overall.

> > THis shouldn't be on a "fast" lookup path, so I doubt that's worth
> > optimizing for.  Space, maybe, for systems with thousands of scsi
> > devices, but usually they just stick to the block device, not a char
> > device from what I remember.
> 
> /dev/sgX is a chardev?

I sure hope no one is using /dev/sgX for tens of thousands of block
device accesses, if so, they have bigger problems than this :)

thanks,

greg k-h