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, 23 Apr 2015 10:25:43 +0200
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Arnd Bergmann <arnd@...db.de>, Jiri Kosina <jkosina@...e.cz>,
	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [RFC] simple_char: New infrastructure to simplify chardev
 management

On Tue, Feb 10, 2015 at 03:44:05PM -0800, Andy Lutomirski wrote:
> This isn't adequately tested, and I don't have a demonstration (yet).
> It's here for review for whether it's a good idea in the first place
> and for weather the fully_dynamic mechanism is a good idea.

Sorry for the long delay.

I looked at this, and at a first glance, this looks good.  The existing
char interface is a mess, and needs to really be simplified.  I think
this code can go a long way toward making that happen.

But I'm a bit confused as to how to use this.  Can you pick some
in-kernel driver and convert it to this interface to see how it would
"work"?

Ideally, between an interface like this, and the miscdevice interface,
that should be the main way to create character devices, simplifying a
lot of "boilerplate" code we have in drivers today.

Some minor comments on the code:

> +	ret = -ENOMEM;
> +	major = kmalloc(sizeof(struct simple_char_major), GFP_KERNEL);
> +	if (!major)
> +		goto out_unregister;
> +	cdev_init(&major->cdev, &simple_char_fops);
> +	kobject_set_name(&major->cdev.kobj, "%s", name);

The kobject in a cdev isn't a "real" kobject in that the name doesn't
matter, and it's never "registered" with sysfs.  It's only use for the
kobject map code, for looking up the cdev very quickly.  I really would
like to just split the kmap code out from being related to a kobject as
it's something that confuses a lot of people, but never spent the time
to do the work.

So a line like this shouldn't do anything, you don't have to set the
name here.

> +void simple_char_major_free(struct simple_char_major *major)
> +{
> +	BUG_ON(!idr_is_empty(&major->idr));

WARN_ON is best, we never want to add new BUG calls to the kernel.  Or,
if this really can never happen, we don't need to test for it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ