char_dev: add cdev->release() and convert cdev_alloc() to use it
PATCH RESEND 1/1 char_dev: add cdev->release() and convert cdev_alloc() to use it
Add cdev->release() so that cdev can be considered in more involved object lifetime management. cdev_alloc() used a separate ktype for auto-free release(). This patch converts it to use cdev->release() so that there's no need for separate ktype and cdev_init() can be used for auto-free variant too.
---
This one is also for CUSE. Oops, forgot lkml. Resending. Thanks.
fs/char_dev.c | 30 +++++++++++++----------------- include/linux/cdev.h | 1 + 2 files changed, 14 insertions(+), 17 deletions(-)
fs/char_dev.c +13 -17
@@ -478,26 +478,22 @@ void cdev_del(struct cdev *p) } -static void cdev_default_release (struct kobject *kobj) +static void cdev_release (struct kobject *kobj) { struct cdev *p = container_of(kobj, struct cdev, kobj);cdev_purge (p); +if (p->release) + p->release (p); } -static void cdev_dynamic_release (struct kobject *kobj) -{ - struct cdev *p = container_of(kobj, struct cdev, kobj); -cdev_purge (p); -kfree (p); -} - -static struct kobj_type ktype_cdev_default = { - .release = cdev_default_release, +static struct kobj_type cdev_ktype = { + .release = cdev_release, }; -static struct kobj_type ktype_cdev_dynamic = { - .release = cdev_dynamic_release, -}; +static void cdev_alloc_release (struct cdev *cdev) +{ +kfree (cdev); +}/** * cdev_alloc() - allocate a cdev structure
@@ -506,10 +502,10 @@ static struct kobj_type ktype_cdev_dynamic = {*/ struct cdev *cdev_alloc (void ) { -struct cdev *p =kzalloc (sizeof (struct cdev ),GFP_KERNEL ); +struct cdev *p =kmalloc (sizeof (struct cdev ),GFP_KERNEL );if (p) { -INIT_LIST_HEAD (&p->list); -kobject_init (&p->kobj, &ktype_cdev_dynamic); +cdev_init (p,NULL ); + p->release = cdev_alloc_release; }return p; }
@@ -526,7 +522,7 @@ void cdev_init(struct cdev *cdev, const struct file_operations *fops) {memset (cdev,0 ,sizeof *cdev);INIT_LIST_HEAD (&cdev->list); -kobject_init (&cdev->kobj, &ktype_cdev_default); +kobject_init (&cdev->kobj, &cdev_ktype); cdev->ops = fops; }
include/linux/cdev.h +1 -0
@@ -16,6 +16,7 @@ struct cdev {struct list_head list;dev_t dev;unsigned int count; +void (*release)(struct cdev *); };void cdev_init (struct cdev *,const struct file_operations *);
Signature · 1 line
1.5.4.5
Quoted 7 lines · Tejun Heo
Add
cdev->release()so that cdev can be considered in more involved object lifetime management.cdev_alloc()used a separate ktype for auto-freerelease(). This patch converts it to usecdev->release()so that there's no need for separate ktype andcdev_init()can be used for auto-free variant too.Signed-off-by Tejun Heo <[email protected]>
Ick, I really don't want struct cdev to be used for lifecycle management, as it is only for major:minor stuff. Why do you want to make this change?
thanks,
greg k-h
Quoted 3 lines · Greg KH
Ick, I really don't want struct cdev to be used for lifecycle management, as it is only for major:minor stuff. Why do you want to make this change?
Well, as cdev can be referenced from userspace, ->release is required for most purposes. The reason why devices have been getting by without it is because most chardevs are created on module load and destroyed on module unload and in the meantime cdev refcount virtually equals module refcnt, but I'm fairly sure we have cases where cdev can be destroyed for other reasons then module unloading and it's very likely those cases are buggy in the current code (backing structure gone bug cdev still hanging around).
As CUSE can create and destroy devices regardless of module reference count, it falls in the second category and needs cdev->release() to make sure the backing structure doesn't go away till cdev is released.
Thanks.
Signature · 1 line
tejun
Quoted 5 lines · Tejun Heo
Quoted 3 lines · Greg KH
Ick, I really don't want struct cdev to be used for lifecycle management, as it is only for major:minor stuff. Why do you want to make this change?
Quoted 8 lines
Well, as cdev can be referenced from userspace, ->release is required for most purposes. The reason why devices have been getting by without it is because most chardevs are created on module load and destroyed on module unload and in the meantime cdev refcount virtually equals module refcnt, but I'm fairly sure we have cases where cdev can be destroyed for other reasons then module unloading and it's very likely those cases are buggy in the current code (backing structure gone bug cdev still hanging around).
Hm, I thought Al covered that when he created the cdev interface, I would be a bit supprised if this was the case.
Quoted 3 lines
As CUSE can create and destroy devices regardless of module reference count, it falls in the second category and needs
cdev->release()to make sure the backing structure doesn't go away till cdev is released.
But CUSE should be it's own module, right? And it would "own" the cdev, so the module and cdev count should be fine and matching. The userspace code could go away but the CUSE code should handle that with a different reference count. This is the way that hardware drivers handle the issue.
thanks,
greg k-h
Quoted 14 lines · Greg KH
Quoted 4 lines · Tejun Heo
Quoted 3 lines · Greg KH
Ick, I really don't want struct cdev to be used for lifecycle management, as it is only for major:minor stuff. Why do you want to make this change?
Quoted 8 lines
Well, as cdev can be referenced from userspace, ->release is required for most purposes. The reason why devices have been getting by without it is because most chardevs are created on module load and destroyed on module unload and in the meantime cdev refcount virtually equals module refcnt, but I'm fairly sure we have cases where cdev can be destroyed for other reasons then module unloading and it's very likely those cases are buggy in the current code (backing structure gone bug cdev still hanging around).
Quoted 2 lines
Hm, I thought Al covered that when he created the cdev interface, I would be a bit supprised if this was the case.
Hmmm.... I've never actually audited the code so... it could be that no chardev is created and destroyed that way, I guess.
Quoted 9 lines
Quoted 3 lines
As CUSE can create and destroy devices regardless of module reference count, it falls in the second category and needs
cdev->release()to make sure the backing structure doesn't go away till cdev is released.But CUSE should be it's own module, right? And it would "own" the cdev, so the module and cdev count should be fine and matching. The userspace code could go away but the CUSE code should handle that with a different reference count. This is the way that hardware drivers handle the issue.
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.
Thanks.
Signature · 1 line
tejun
Quoted 31 lines · Tejun Heo
Quoted 14 lines · Greg KH
Quoted 4 lines · Tejun Heo
Quoted 3 lines · Greg KH
Ick, I really don't want struct cdev to be used for lifecycle management, as it is only for major:minor stuff. Why do you want to make this change?
Quoted 8 lines
Well, as cdev can be referenced from userspace, ->release is required for most purposes. The reason why devices have been getting by without it is because most chardevs are created on module load and destroyed on module unload and in the meantime cdev refcount virtually equals module refcnt, but I'm fairly sure we have cases where cdev can be destroyed for other reasons then module unloading and it's very likely those cases are buggy in the current code (backing structure gone bug cdev still hanging around).
Quoted 2 lines
Hm, I thought Al covered that when he created the cdev interface, I would be a bit supprised if this was the case.
Hmmm.... I've never actually audited the code so... it could be that no chardev is created and destroyed that way, I guess.
Quoted 9 lines
Quoted 3 lines
As CUSE can create and destroy devices regardless of module reference count, it falls in the second category and needs
cdev->release()to make sure the backing structure doesn't go away till cdev is released.But CUSE should be it's own module, right? And it would "own" the cdev, so the module and cdev count should be fine and matching. The userspace code could go away but the CUSE code should handle that with a different reference count. This is the way that hardware drivers handle the issue.
Quoted 6 lines
The problem is not the device to talk to CUSE (
/dev/cuseas 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/cusewhich 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...)
thanks,
greg k-h
Quoted 11 lines · Greg KH
Quoted 6 lines
The problem is not the device to talk to CUSE (
/dev/cuseas 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/cusewhich 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.
Quoted 7 lines
So, you tie the cdev lifespan to the module lifespan with the
MODULE_OWNERin 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.
Thanks.
Signature · 1 line
tejun
Quoted 17 lines · Tejun Heo
Quoted 16 lines · Greg KH
Quoted 6 lines
The problem is not the device to talk to CUSE (
/dev/cuseas 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/cusewhich 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_OWNERin 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?
Quoted 8 lines
Quoted 2 lines
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
Hello, Greg.
I'm now trying to convert the cdev thing for CUSE and it just ain't feel right.
Quoted 8 lines · Greg KH
Quoted 5 lines
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.
That "normally" is from the days when only a single or fixed number of devices are associated with single module or driver.
Quoted 4 lines
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.
Yes, it requires all drivers to have global device table and check whether the device is still available at ->open. For most, drivers usually have certain fixed number of devices which can directly be indexed with minor. For CUSE, it gotta be a hash table or a b-tree. I don't really see any point in not adding ->release. Time has changed and everybody is playing with reference counts and ->release methods. Plus, cdev_alloc() interface is half-baked anyway (no free function for cases where cdev_add() fails, drivers call cdev_del() in those cases risking unregistering other driver's map). It's perfectly okay to keep it around for compatibility but there just is no reason to cling to it.
Quoted 4 lines
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 :)
Heh... CUSE did that too. Removing it.
Thanks.
Signature · 1 line
tejun
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
(lkml was missing, adding it back and quoting whole body for reference)
Quoted 19 lines · Tejun Heo
Quoted 6 lines · Greg KH
Quoted 3 lines · Tejun Heo
(this is a private message)
PING. :-)
Heh.
Quoted 7 lines
I've lost this out of my tree, as I didn't know you still wanted this applied. If you need it for your char-fuse code, then I don't have an objection to it, and you can take it through your tree.
Or do you want me to take it through mine?
Your choice :)
I'll push it through Miklos' tree w/ your ACK then.
Thanks. :-)
Signature · 1 line
tejun
Quoted 23 lines · Tejun Heo
(lkml was missing, adding it back and quoting whole body for reference)
Quoted 18 lines · Tejun Heo
Quoted 6 lines · Greg KH
Quoted 3 lines · Tejun Heo
(this is a private message)
PING. :-)
Heh.
Quoted 7 lines
I've lost this out of my tree, as I didn't know you still wanted this applied. If you need it for your char-fuse code, then I don't have an objection to it, and you can take it through your tree.
Or do you want me to take it through mine?
Your choice :)
I'll push it through Miklos' tree w/ your ACK then.
Thanks. :-)
Tejun Hi.
I just saw this thread for the first time and it left me confused. What was the final verdict. Is this patch going in at the end? Which incarnation of it? is there a public git tree I can try?
The reason I ask is because I have just the same principal work in one of my test trees. What I have is a Filesystem, osdfs, that is mounted on an OSD scsi-device, which is a char-device. Now the osdfs when mounting an OSD device does not use __open, like user mode it needs some kernel reference counting to keep the char-device up. On the other hand the actual teardown and unmap of the char-device is done from the scsi-ml remove vector. So just like in sd, sr and other scsi ULDs I need to unmap the device but keep the memory allocated and available until the last reference. All this is usually done using the Release() of the block-device. But for me I only have a char-device. Currently what I had to do is keep another kref to govern the device's lifecycle and sync every thing together. A Release() at the char-dev would let me reuse what's there and let me clean all that code up.
While Investigating the problem and compering what was done on the block-device side, I've seen more then a few places that private reference counting could be dropped completely, and the char-dev could be used. Off my head some of these places are:
- UBI used by UBIFS
- sg.c which does not have a Kernel user but needs it's char device until scsi-Remove and/or __close()
and other places as well.
Thanks for doing this
Boaz
Hello,
Quoted 3 lines · Boaz Harrosh
I just saw this thread for the first time and it left me confused. What was the final verdict. Is this patch going in at the end? Which incarnation of it? is there a public git tree I can try?
Yes it is and as posted and no there isn't no public git tree yet, I was planning on pushing it through Miklos' tree.
Quoted 21 lines
The reason I ask is because I have just the same principal work in one of my test trees. What I have is a Filesystem, osdfs, that is mounted on an OSD scsi-device, which is a char-device. Now the osdfs when mounting an OSD device does not use
__open, like user mode it needs some kernel reference counting to keep the char-device up. On the other hand the actual teardown and unmap of the char-device is done from the scsi-ml remove vector. So just like in sd, sr and other scsi ULDs I need to unmap the device but keep the memory allocated and available until the last reference. All this is usually done using theRelease()of the block-device. But for me I only have a char-device. Currently what I had to do is keep another kref to govern the device's lifecycle and sync every thing together. ARelease()at the char-dev would let me reuse what's there and let me clean all that code up.While Investigating the problem and compering what was done on the block-device side, I've seen more then a few places that private reference counting could be dropped completely, and the char-dev could be used. Off my head some of these places are:
- UBI used by UBIFS
-sg.cwhich does not have a Kernel user but needs it's char device until scsi-Remove and/or__close()
Quoted 1 line
and other places as well.
Hmmm... if you can use this change, I think you can push it through whatever tree you push patches through, things can be taken care of when merging or we can put it in Greg's tree and ask Miklos to pull from the tree first but Greg doesn't keep a stable tree. Hmm... if your patches are gonna go through some public tree, I think we can ask Miklos pull from the tree too. Guys, what do you think?
Thanks.
Signature · 1 line
tejun
Quoted 6 lines · Tejun Heo
Hmmm... if you can use this change, I think you can push it through whatever tree you push patches through, things can be taken care of when merging or we can put it in Greg's tree and ask Miklos to pull from the tree first but Greg doesn't keep a stable tree. Hmm... if your patches are gonna go through some public tree, I think we can ask Miklos pull from the tree too. Guys, what do you think?
Sure, since this is not fuse specific, it better not go through my tree anyway.
Thanks,
Miklos
Quoted 31 lines · Tejun Heo
Hello,
Quoted 3 lines · Boaz Harrosh
I just saw this thread for the first time and it left me confused. What was the final verdict. Is this patch going in at the end? Which incarnation of it? is there a public git tree I can try?
Yes it is and as posted and no there isn't no public git tree yet, I was planning on pushing it through Miklos' tree.
Quoted 21 lines
The reason I ask is because I have just the same principal work in one of my test trees. What I have is a Filesystem, osdfs, that is mounted on an OSD scsi-device, which is a char-device. Now the osdfs when mounting an OSD device does not use
__open, like user mode it needs some kernel reference counting to keep the char-device up. On the other hand the actual teardown and unmap of the char-device is done from the scsi-ml remove vector. So just like in sd, sr and other scsi ULDs I need to unmap the device but keep the memory allocated and available until the last reference. All this is usually done using theRelease()of the block-device. But for me I only have a char-device. Currently what I had to do is keep another kref to govern the device's lifecycle and sync every thing together. ARelease()at the char-dev would let me reuse what's there and let me clean all that code up.While Investigating the problem and compering what was done on the block-device side, I've seen more then a few places that private reference counting could be dropped completely, and the char-dev could be used. Off my head some of these places are:
- UBI used by UBIFS
-sg.cwhich does not have a Kernel user but needs it's char device until scsi-Remove and/or__close()
Quoted 6 lines
Quoted 1 line
and other places as well.
Hmmm... if you can use this change, I think you can push it through whatever tree you push patches through, things can be taken care of when merging or we can put it in Greg's tree and ask Miklos to pull from the tree first but Greg doesn't keep a stable tree.
I don't keep a stable tree? What do you mean? It's a quilt tree, and it does get included in -next, so I think it does work :)
Send it to me again and I'll push it through my tree if no one else objects.
thanks,
greg k-h
Quoted 7 lines · Greg KH
Quoted 4 lines
Hmmm... if you can use this change, I think you can push it through whatever tree you push patches through, things can be taken care of when merging or we can put it in Greg's tree and ask Miklos to pull from the tree first but Greg doesn't keep a stable tree.
I don't keep a stable tree? What do you mean? It's a quilt tree, and it does get included in -next, so I think it does work :)
Heh... I meant stable (in the sense that it doesn't get rebased) git tree which Miklos can pull from.
Quoted 2 lines
Send it to me again and I'll push it through my tree if no one else objects.
Yeap, will resend it and let you and Miklos sort it out.
Thanks.
Signature · 1 line
tejun
PATCH RESEND 1/1 char_dev: add cdev->release() and convert cdev_alloc() to use it
Add cdev->release() so that cdev can be considered in more involved object lifetime management. cdev_alloc() used a separate ktype for auto-free release(). This patch converts it to use cdev->release() so that there's no need for separate ktype and cdev_init() can be used for auto-free variant too.
--- fs/char_dev.c | 30 +++++++++++++----------------- include/linux/cdev.h | 1 + 2 files changed, 14 insertions(+), 17 deletions(-)
fs/char_dev.c +13 -17
@@ -482,26 +482,22 @@ void cdev_del(struct cdev *p) } -static void cdev_default_release (struct kobject *kobj) +static void cdev_release (struct kobject *kobj) { struct cdev *p = container_of(kobj, struct cdev, kobj);cdev_purge (p); +if (p->release) + p->release (p); } -static void cdev_dynamic_release (struct kobject *kobj) -{ - struct cdev *p = container_of(kobj, struct cdev, kobj); -cdev_purge (p); -kfree (p); -} - -static struct kobj_type ktype_cdev_default = { - .release = cdev_default_release, +static struct kobj_type cdev_ktype = { + .release = cdev_release, }; -static struct kobj_type ktype_cdev_dynamic = { - .release = cdev_dynamic_release, -}; +static void cdev_alloc_release (struct cdev *cdev) +{ +kfree (cdev); +}/** * cdev_alloc() - allocate a cdev structure
@@ -510,10 +506,10 @@ static struct kobj_type ktype_cdev_dynam*/ struct cdev *cdev_alloc (void ) { -struct cdev *p =kzalloc (sizeof (struct cdev ),GFP_KERNEL ); +struct cdev *p =kmalloc (sizeof (struct cdev ),GFP_KERNEL );if (p) { -INIT_LIST_HEAD (&p->list); -kobject_init (&p->kobj, &ktype_cdev_dynamic); +cdev_init (p,NULL ); + p->release = cdev_alloc_release; }return p; }
@@ -530,7 +526,7 @@ void cdev_init(struct cdev *cdev, const {memset (cdev,0 ,sizeof *cdev);INIT_LIST_HEAD (&cdev->list); -kobject_init (&cdev->kobj, &ktype_cdev_default); +kobject_init (&cdev->kobj, &cdev_ktype); cdev->ops = fops; }
include/linux/cdev.h +1 -0
@@ -16,6 +16,7 @@ struct cdev {struct list_head list;dev_t dev;unsigned int count; +void (*release)(struct cdev *); };void cdev_init (struct cdev *,const struct file_operations *);