Re: 2.5.64-mm1

From: Alex Tomas (bzzz@tmi.comex.ru)
Date: Thu Mar 06 2003 - 05:00:30 EST


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.

Am I miss something?

>>>>> Andrew Morton (AM) writes:

 AM> +htree-lock_kernel-fix.patch

 AM> Missing unlock_kernel() on htree error path

-
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/



This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:31 EST