lkml.org 
[lkml]   [2021]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] char_dev: replace cdev_map with an xarray
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?

> +static struct cdev *cdev_lookup(dev_t dev)
> +{
> + struct cdev *cdev;
> +
> + mutex_lock(&chrdevs_lock);
> + cdev = xa_load(&cdev_map, dev);
> + if (!cdev) {
> + mutex_unlock(&chrdevs_lock);
> + if (request_module("char-major-%d-%d",
> + MAJOR(dev), MINOR(dev)) > 0)
> + /* Make old-style 2.4 aliases work */
> + request_module("char-major-%d", MAJOR(dev));
> + mutex_lock(&chrdevs_lock);
> +
> + cdev = xa_load(&cdev_map, dev);
> + }
> + if (cdev && !cdev_get(cdev))
> + cdev = NULL;
> + mutex_unlock(&chrdevs_lock);
> + return cdev;

What does the mutex protect here? Is it cdev being freed?

> @@ -593,11 +601,16 @@ static void cdev_unmap(dev_t dev, unsigned count)
> */
> void cdev_del(struct cdev *p)
> {
> - cdev_unmap(p->dev, p->count);
> + int i;
> +
> + mutex_lock(&chrdevs_lock);
> + for (i = 0; i < p->count; i++)
> + xa_erase(&cdev_map, p->dev + i);
> + mutex_unlock(&chrdevs_lock);

I don't understand what it's protecting here. It's clearly not cdev_get
as that could happen before we acquire the mutex. This also suggests
I should add an xa_erase_range() to the API.

But there's nothing wrong here, just some places that maybe could be
better, so:

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>

\
 
 \ /
  Last update: 2021-01-11 18:36    [W:0.094 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site