Messages in this thread | | | Date | Thu, 6 Mar 2003 02:21:40 -0800 | From | Andrew Morton <> | Subject | Re: 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/
| |