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 <anton@samba.org>
---

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)
--

[ message continues ]

Looks good to me.  Thanks!

Reviewed-by: Wu Fengguang <fengguang.wu@intel.com>
--

[ message continues ]

Is this something that we need for .34?  How were you getting this to
fail in the first place?

thanks,

greg k-h
--

[ message continues ]

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
--

[ message continues ]