I hit this when we had a bug in IDR for a few days. Basically sysfs would
fail to create new inodes since it uses an IDR and therefore class_create would
fail.
While we are unlikely to see this fail we may as well handle it instead of
oopsing.
Signed-off-by: Anton Blanchard <[email protected]>
---
Index: linux-2.6/drivers/char/mem.c
===================================================================
--- linux-2.6.orig/drivers/char/mem.c 2010-02-02 22:18:02.000000000 -0600
+++ linux-2.6/drivers/char/mem.c 2010-02-02 22:18:15.000000000 -0600
@@ -901,6 +901,9 @@ static int __init chr_dev_init(void)
printk("unable to get major %d for memory devs\n", MEM_MAJOR);
mem_class = class_create(THIS_MODULE, "mem");
+ if (IS_ERR(mem_class))
+ return PTR_ERR(mem_class);
+
mem_class->devnode = mem_devnode;
for (minor = 1; minor < ARRAY_SIZE(devlist); minor++) {
if (!devlist[minor].name)
Looks good to me. Thanks!
Reviewed-by: Wu Fengguang <[email protected]>
On Fri, Apr 02, 2010 at 06:29:20PM +1100, Anton Blanchard wrote:
>
> I hit this when we had a bug in IDR for a few days. Basically sysfs would
> fail to create new inodes since it uses an IDR and therefore class_create would
> fail.
>
> While we are unlikely to see this fail we may as well handle it instead of
> oopsing.
Is this something that we need for .34? How were you getting this to
fail in the first place?
thanks,
greg k-h
Hi Greg,
> Is this something that we need for .34? How were you getting this to
> fail in the first place?
I hit this when we broke the IDR allocator for a few days. The bug got
introduced in commit 859ddf09743a8cc680af33f7259ccd0fd36bfe9d (idr: fix a
critical misallocation bug), and was backed out a few days later in commit
6f14a668f1a8b715a6e855f4e32705e54a6e86a1 (idr: revert misallocation bug fix).
The sysfs inode allocator which uses IDR was getting back a bogus ENOSPC
return code. I think the chances of seeing this fail otherwise would be pretty
remote, you'd have to use up 2^31 sysfs inodes before hitting the real IDR
limit.
Anton