lkml.org 
[lkml]   [2002]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:26    [W:0.489 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site