lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: arca-vm-8 [Re: [patch] arca-vm-6, killed kswapd [Re: [patch] new-vm , improvement , [Re: 2.2.0 Bug summary]]]
   Date: 	Thu, 7 Jan 1999 09:56:03 -0800 (PST)
From: Linus Torvalds <torvalds@transmeta.com>

The positive news is that if I'm right in my suspicions it can only
happen with shared writable mappings or shared memory segments. The
bad news is that the bug appears rather old, and no immediate
solution presents itself.

We could drop the superblock lock right before the actual bread()
call, grab it again right afterwards, then idicate back down to the
original caller that he should restart his search from the beginning
of the toplevel logic in ext2_free_blocks/ext2_new_block.

The second time around a bread() won't happen.

From a performance standpoint, since we are doing a disk I/O anyways,
the extra software overhead here will be mute.

However, I am concerned about deadlocks in this scheme where the
bread() kicks some other bitmap block back out to disk, and we loop
forever pingponging block bitmap blocks back and forth with no forward
progress being made. Also the logic in these functions is non-trivial
and making an "obviously correct" patch, ignoring the possible
deadlock mentioned here, might not be easy.

We've had a couple strange issues like this, with recursive superblock
lock problems, recall the quota writeback deadlock Bill Hawes fixed a
few months ago, very similar.

Later,
David S. Miller
davem@dm.cobaltmicro.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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