Re: 2.5.64-mm1

[Andrew Morton <akpm@digeo.com>]

Alex Tomas <bzzz@tmi.comex.ru> wrote:
>
> 
> As far as I understand this isn't error path. 
> 
> 	lock_kernel();
> 
> 	sb = inode->i_sb;
> 
> 	if (is_dx(inode)) {
> 		err = ext3_dx_readdir(filp, dirent, filldir);
> 		if (err != ERR_BAD_DX_DIR)
> 			return err;
> 		/*
> 		 * We don't set the inode dirty flag since it's not
> 		 * critical that it get flushed back to the disk.
> 		 */
> 		EXT3_I(filp->f_dentry->d_inode)->i_flags &= ~EXT3_INDEX_FL;
> 	}
> 
> So, if ext3_dx_readdir() returns 0 (OK path), then ext3_readdir() finish
> w/o unlock_kernel(). The remain part of ext3_readdir() gets used if
> ext3_dx_readdir() can't use HTree and returns ERR_BAD_DX_DIR.
> 

hm, yes, it does look that way.

It could be that any task which travels that path ends up running under
lock_kernel() for the rest of its existence, and nobody noticed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>