Messages in this thread | | | Date | Fri, 18 Jul 2008 12:39:18 +0200 | From | "Vegard Nossum" <> | Subject | Re: latest -git: A peculiar case of a stuck process (ext3/sched-related?) |
| |
On Fri, Jul 18, 2008 at 12:32 PM, Andrew Morton <akpm@linux-foundation.org> wrote: > On Fri, 18 Jul 2008 12:17:17 +0200 "Vegard Nossum" <vegard.nossum@gmail.com> wrote: > >> 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? > > yup. ext2 did that a couple of times. See the explicit check for > de->rec_len == 0 in ext2_find_entry(). > > We fixed one filesystem and forgot the others. Again.
Wow, that change is OLD, though:
commit aa4f3f285643956bb614cf7b8f88e15f3a375886 Author: Andrew Morton <akpm@zip.com.au> Date: Mon Apr 29 23:51:34 2002 -0700
[PATCH] ext2 directory handling
Will you also send the patch for ext3? :-)
Vegard
-- "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
| |