Messages in this thread | | | Date | Wed, 15 May 2002 15:42:00 -0700 | From | Mike Kravetz <> | Subject | Re: Bug with shared memory. |
| |
On Tue, May 14, 2002 at 12:33:23PM -0700, Andrew Morton wrote: > Martin Schwidefsky wrote: > > The system call that caused > > this has been sys_ipc with IPC_RMID and from there the call chain is > > as follows: sys_shmctl, shm_destroy, fput, dput, iput, truncate_inode_pages, > > truncate_list_pages, schedule. The scheduler picked a process that called > > sys_shmat. It tries to get the lock and hangs. > > There's no way the kernel can successfully hold a spinlock > across that call chain. >
Is adding a check for this type of situation (under CONFIG_DEBUG_SPINLOCK of course) worth the effort? One would simply add a 'locks_held' count for each task and check for zero at certain places such as return to user mode, and during context switching.
It appears that this was done for 'sparc64', but no other architectures. I would consider doing this for i386, if anyone would actually use it.
One would think these types of things are easily found, but this example suggests otherwise. Has anyone run the kernel through an extensive (stress) test suite with any of the kernel debug options enabled?
-- Mike - 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/
| |