[lkml]   [2008]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: latest -git: A peculiar case of a stuck process (ext3/sched-related?)
On Fri, Jul 18, 2008 at 3:00 PM, Duane Griffin <> wrote:
> 2008/7/18 Vegard Nossum <>:
>> And the ext3_find_entry() corresponds to this line:
>> for (; de < top; de = ext3_next_entry(de)) /* <--- HERE! */
>> if (ext3_match (namelen, name, de)) {
>> if (!ext3_check_dir_entry("ext3_find_entry",
>> dir, de, bh,
>> (block<<EXT3_BLOCK_SIZE_BITS(sb))
>> +((char *)de - bh->b_data))) {
>> brelse (bh);
>> *err = ERR_BAD_DX_DIR;
>> goto errout;
>> }
>> *res_dir = de;
>> dx_release (frames);
>> return bh;
>> }
>> Is it possible that this loop can get stuck with a corrupt filesystem image?
> It certainly is. This is the same problem as the first case reported
> at There is a patch
> in -mm for it already (2fde9f7a0faabe821b31ccd982d482c21f7c503f),
> posted here:
> Hopefully that should fix the problem for you.

Oh, right. Thanks!

(This patch looks much shorter than the one I found for ext2, though,
i.e. commit aa4f3f285643956bb614cf7b8f88e15f3a375886 from the
historical git repository. Does it fix all the right cases? I don't
mean to troll -- I just wanted to be sure you knew about it.)

I'll try it and report back if there's any trouble. Thanks,


"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036

 \ /
  Last update: 2008-07-18 19:07    [W:0.084 / U:1.160 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site