Commit graph

4 commits

Author SHA1 Message Date
Andreas Schwab
9d923a0603 [PATCH] ufs: fix char vs. __s8 clash in ufs
Fix this warning:

fs/ufs/super.c: In function ‘ufs_fill_super’:
fs/ufs/super.c:858: warning: case label value exceeds maximum value for type

which happens because __s8 != char.  These macros are used for struct
ufs_super_block.fs_clean which is declared as __s8.

Signed-off-by: Andreas Schwab <schwab@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-03 08:32:05 -08:00
Evgeniy Dushistov
09114eb8c5 [PATCH] ufs: fix hang during `rm'
This fixes the code like this:

	bh = sb_find_get_block (sb, tmp + j);
	if ((bh && DATA_BUFFER_USED(bh)) || tmp != fs32_to_cpu(sb, *p)) {
		retry = 1;
		brelse (bh);
		goto next1;
	}
	bforget (bh);

sb_find_get_block() ordinarily returns a buffer_head with b_count>=2, and
this code assume that in case if "b_count>1" buffer is used, so this caused
infinite loop.

(akpm: that is-the-buffer-busy code is incomprehensible.  Good riddance.  Use
of block_truncate_page() seems sane).

Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-03 08:32:04 -08:00
Evgeniy Dushistov
e295cfcb29 [PATCH] ufs: fix oops with `ufs1' type
"rm" command, on file system with "ufs1" type cause system hang up.  This
is, in fact, not so bad as it seems to be, because of after that in "kernel
control path" there are 3-4 places which may cause "oops".

So the first patch fix oopses, and the second patch fix "kernel hang up".

"oops" appears because of reading of group's summary info partly wrong, and
access to not first group's summary info cause "oops".

Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-03 08:32:04 -08:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00