Messages in this thread | | | Date | Mon, 29 Mar 2004 12:23:09 +0530 | From | Maneesh Soni <> | Subject | Re: BUG: Problem with your patches for sysfs from 2 weeks ago |
| |
On Sat, Mar 27, 2004 at 05:25:07PM -0500, Alan Stern wrote: > Maneesh: > > I've been tracing a problem with sysfs that starting showing up just > recently, and it seems likely to have originated with your patches from a > couple of weeks ago. I can't tell exactly what's wrong or fix it because > I don't understand the filesystem layer well enough. > > The problem I found (there may be others) shows up when trying to delete a > nonexistent symlink -- presumably trying to delete a nonexistent file > would have a similar result. The code in sysfs_hash_and_remove() does a > lookup on the nonexistent name and sysfs_get_dentry() returns a > newly-allocated dentry. Creating the new entry increments the parent > directory's d_count, of course. But at the end of the routine, when > dput() is called for the new dentry, the parent's d_count does _not_ get > decremented. The new dentry is placed on the dentry_unused list and the > parent is left with an anomalously large d_count. This doesn't ever seem > to get resolved, and when the directory's kobject is deleted the reference > you added doesn't get dropped. >
I see the problem here. Probably same will happen even if a non-existent regular file is deleted. Negative dentry and the ref. taken on the parent should go away eventually when there is a memory pressure. But the situation here needs immediate removal of the negative dentry.
This could be solved partially if sysfs_hash_and_remove() handles negative dentries as well by unhashing them before calling dput().
Partially because sysfs_hash_and_remove() is called only if some kernel level code (drivers) issues sysfs_remove_file() or sysfs_create_file(). But if a user just goes to the corresponding directory and does rm for a non-existent file, I guess we will have the same situation. This needs some solution.
The patch (sysfs-pin-kobject.patch) I did was required for oops (Use after free) situations like this
============================================================================= Unable to handle kernel paging request at virtual address db368dc0 printing eip: c01f8690 *pde = 5a5a5a5a Oops: 0000 [#1] CPU: 0 EIP: 0060:[<c01f8690>] Not tainted EFLAGS: 00010282 EIP is at kobject_get+0x10/0x50 eax: db368da8 ebx: db368da8 ecx: 00000001 edx: d6d0ff68 esi: db69ee88 edi: db69ee88 ebp: d7ed3f0c esp: d7ed3ef8 ds: 007b es: 007b ss: 0068 Process cat (pid: 30394, threadinfo=d7ed2000 task=d63dc9b0) Stack: c014a447 d6d0ff68 c1fb9aec 00000001 d6d0ff68 d7ed3f30 c019f500 db368da8 d7ed3f30 c016601b d6d0ff68 d6d0ff68 db69ee88 c1fa9c44 d7ed3f50 c01640ec db69ee88 d6d0ff68 ffffffe9 00008000 00008000 d975e000 d7ed3f9c c0163fa6 Call Trace: [<c014a447>] kmem_cache_alloc+0x107/0x240 [<c019f500>] check_perm+0x20/0x190 [<c016601b>] get_empty_filp+0x7b/0x110 [<c01640ec>] dentry_open+0x13c/0x1f0 [<c0163fa6>] filp_open+0x66/0x70 [<c0164545>] sys_open+0x55/0x90 [<c010b651>] sysenter_past_esp+0x52/0x71 Code: 8b 43 18 85 c0 74 0d f0 ff 43 18 89 d8 8b 5d fc 89 ec 5d c3
-- Maneesh Soni Linux Technology Center, IBM Software Lab, Bangalore, India email: maneesh@in.ibm.com Phone: 91-80-25044999 Fax: 91-80-25268553 T/L : 9243696 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |