lkml.org 
[lkml]   [2003]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.5.64-mm1
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 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:33    [W:0.110 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site