Bug 128794 (IT_45140)
Summary: | [RHEL3]Oops in de_put due to proc_dir_entry inconsistencies | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Kevin W. Rudd <solgato> |
Component: | kernel | Assignee: | Alexander Viro <aviro> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | anderson, petrides, riel, tao |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-12-20 20:55:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 123574 |
Description
Kevin W. Rudd
2004-07-29 17:01:49 UTC
Dave, This issue also reported via support channel.... The difficulty here is that this piece of code is terribly designed and implemented. First, the proc_dir_entry is allocated via "malloc". That's a very bad start - should use a fixed set of slab cache objects rather than a general purpose one (I think). Now let's examine one possible race condition: thread A calls remove_proc_entry() thread A does an atomic_read(&de->count) and finds it is zero thread B calls proc_get_inode() and got the "de" pionter thread A does a "free_proc_entry" - which does a free(de). ("de" now "returns" to malloc pool - God knows who gets it and what it has done to that piece of memory) thread B still has the "de" so it'll trash someone's memory by either thread B does de_get() which incrases de->count (trashes someone's memory) or. thread B does a de_put() which'll either crash and/or trashes someone's memory. The "de" needs to get from a fixed set of slab cache and we need a lock to protect the structure. What do you think ? First of all, we shouldn't be using any proc_dir_entry for per-process stuff. What's more, exclusion should *prevent* proc_get_inode() after we have removed the entry from lists, which happens before the final de_put(). BKL used to provide that exclusion, IIRC. Whether it still does so or not is the question. Special slab vs. kmalloc() is a red herring - either we get it right (in which case it doesn't matter) or we do not (in which case nasty stuff will happen anyway). A fix for this problem has just been committed to the RHEL3 U4 patch pool this evening (in kernel version 2.4.21-20.11.EL). An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-550.html |