linux-kernel - Re: [PATCH RESEND] char_dev: add cdev->release() and convert 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080828181720.GB23898@kroah.com>
Date:	Thu, 28 Aug 2008 11:17:20 -0700
From:	Greg KH <greg@...ah.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RESEND] char_dev: add cdev->release() and convert
	cdev_alloc() to use it

On Thu, Aug 28, 2008 at 07:55:39PM +0200, Tejun Heo wrote:
> Greg KH wrote:
> >> The problem is not the device to talk to CUSE (/dev/cuse as in
> >> /dev/fuse), for which module refcount and device refcount match fine.
> >> But the whole point of CUSE is allowing CUSE clients to create arbitrary
> >> character devices, so in addition to /dev/cuse which clients use to talk
> >> to CUSE, CUSE hosts character devices for its clients and they come and
> >> go dynamically and thus requires proper lifetime management.
> > 
> > That's fine, it's just like a USB device that uses a cdev, right?  Or a
> > PCI device, or any other type of device that can come and go independant
> > of the cdev or module lifespan.
> > 
> > So, you tie the cdev lifespan to the module lifespan with the
> > MODULE_OWNER in the file operations.  As the cuse.ko module will own the
> > cdev, it can handle that reference, and it can not be removed as long as
> > userspace has the cdev open, right?
> > 
> > It really isn't any different from any other type of removable device
> > (i.e. any type of device...)
> 
> Ah.. right, but taking cdev refcount out of the picture requires adding
> 'severing' operation on cdev f_ops, which certainly is doable but isn't
> it just cleaner to make cdev follow the usual lifetime management rules?
>  An object which is referenced counted requires ->release if it's gonna
> be used in any non-simplistic way.

Yes, but as you "normally" tie the cdev to the module itself, that
handles the lifetime rules.

Now I really dont' like the current cdev interface, it's a bit too
complex as it needed to support the old-style interfaces without any
build time changes, but I think your change isn't needed as somehow all
the current drivers that support dynamic devices don't need it.

Actually, the kobject in cdev shouldn't be an kobject, it's not used for
registering with sysfs at all, it should just be a kref.  I sweep the
tree for code that sets the name of the cdev every few months as people
don't seem to realize this :)

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/