- 27 Sep, 2006 40 commits
-
-
Vasily Averin authored
SWsoft Virtuozzo/OpenVZ Linux kernel team has discovered that ext3 error behavior was broken in linux kernels since 2.5.x versions by the following patch: 2002/10/31 02:15:26-05:00 tytso@snap.thunk.org Default mount options from superblock for ext2/3 filesystems http://linux.bkbits.net:8080/linux-2.6/gnupatch@3dc0d88eKbV9ivV4ptRNM8fBuA3JBQ In case ext3 file system is mounted with errors=continue (EXT3_ERRORS_CONTINUE) errors should be ignored when possible. However at present in case of any error kernel aborts journal and remounts filesystem to read-only. Such behavior was hit number of times and noted to differ from that of 2.4.x kernels. This patch fixes this: - do nothing in case of EXT3_ERRORS_CONTINUE, - set EXT3_MOUNT_ABORT and call journal_abort() in all other cases - panic() should be called after ext3_commit_super() to save sb marked as EXT3_ERROR_FS Signed-off-by:
Vasily Averin <vvs@sw.ru> Acked-by:
Kirill Korotaev <dev@sw.ru> Cc: Theodore Ts'o <tytso@mit.edu> Cc: "Stephen C. Tweedie" <sct@redhat.com> Cc: Mingming Cao <cmm@us.ibm.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Mingming Cao authored
Signed-off-by:
Mingming Cao <cmm@us.ibm.com> Acked-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Mingming Cao authored
In the past there were a few kernel panics related to block reservation tree operations failure (insert/remove etc). It would be very useful to get the block allocation reservation map info when such error happens. Signed-off-by:
-
Eric Sandeen authored
These are a few places I've found in jbd that look like they may not be 16T-safe, or consistent with the use of unsigned longs for block containers. Problems here would be somewhat hard to hit, would require journal blocks past the 8T boundary, which would not be terribly common. Still, should fix. (some of these have come from the ext4 work on jbd as well). I think there's one more possibility that the wrap() function may not be safe IF your last block in the journal butts right up against the 232 block boundary, but that seems like a VERY remote possibility, and I'm not worrying about it at this point. Signed-off-by:
Eric Sandeen <esandeen@redhat.com> Signed-off-by:
-
Eric Sandeen authored
This is primarily format string fixes, with changes to ialloc.c where large inode counts could overflow, and also pass around journal_inum as an unsigned long, just to be pedantic about it.... Signed-off-by:
-
Eric Sandeen authored
Signed-off-by:
-
Eric Sandeen authored
I need to do some actual IO testing now, but this gets things mounting for a 16T ext3 filesystem. (patched up e2fsprogs is needed too, I'll send that off the kernel list) This patch fixes these issues in the kernel: o sbi->s_groups_count overflows in ext3_fill_super() sbi->s_groups_count = (le32_to_cpu(es->s_blocks_count) - le32_to_cpu(es->s_first_data_block) + EXT3_BLOCKS_PER_GROUP(sb) - 1) / EXT3_BLOCKS_PER_GROUP(sb); at 16T, s_blocks_count is already maxed out; adding EXT3_BLOCKS_PER_GROUP(sb) overflows it and groups_count comes out to 0. Not really what we want, and causes a failed mount. Feel free to check my math (actually, please do!), but changing it this way should work & avoid the overflow: (A + B - 1)/B changed to: ((A - 1)/B) + 1 o ext3_check_descriptors() overflows range checks ext3_check_descriptors() iterates over all block groups making sure that various bits are within the right block ranges... on the last pass through, it is checking the error case [item] >= block + EXT3_BLOCKS_PER_GROUP(sb) where "block" is the first block in the last block group. The last block in this group (and the last one that will fit in 32 bits) is block + EXT3_BLOCKS_PER_GROUP(sb)- 1. block + EXT3_BLOCKS_PER_GROUP(sb) wraps back around to 0. so, make things clearer with "first_block" and "last_block" where those are first and last, inclusive, and use <, > rather than <, >=. Finally, the last block group may be smaller than the rest, so account for this on the last pass through: last_block = sb->s_blocks_count - 1; (a similar patch could be done for ext2; does anyone in their right mind use ext2 at 16T? I'll send an ext2 patch doing the same thing if that's warranted) Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Acked-by:
Stephen Tweedie <sct@redhat.com> Signed-off-by:
-
Mingming Cao authored
Remove whitespace from ext3 and jbd, before we clone ext4. Signed-off-by: Mingming Cao<cmm@us.ibm.com> Signed-off-by:
-
Josh Triplett authored
jbd_sync_bh releases journal->j_list_lock. Add a lock annotation to this function so that sparse can check callers for lock pairing, and so that sparse will not complain about this function since it intentionally uses the lock in this manner. Signed-off-by:
Josh Triplett <josh@freedesktop.org> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
Fix build error introduced by 3212fe15 Non-NUMA case should be handled. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: <stable@kernel.org> Signed-off-by:
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/i2c-2.6: (30 commits) i2c: Drop unimplemented slave functions i2c: Constify i2c_algorithm declarations, part 2 i2c: Constify i2c_algorithm declarations, part 1 i2c: Let drivers constify i2c_algorithm data i2c-isa: Restore driver owner i2c-viapro: Add support for the VT8237A and VT8251 i2c: Warn on i2c client creation failure i2c-core: Drop useless bitmaskings i2c-algo-pcf: Discard the mdelay data struct member i2c-algo-bit: Cleanups i2c-isa: Fail adding driver on attach_adapter error i2c: __must_check fixes (chip drivers) i2c-dev: attach/detach_adapter cleanups i2c-stub: Chip address as a module parameter i2c: Plan i2c-isa for removal i2c: New bus driver for TI OMAP boards i2c-algo-bit: Discard the mdelay data struct member i2c-matroxfb: Struct init conversion i2c: Fix copy-n-paste in subsystem Kconfig i2c-au1550: Add I2C support for Au1200 ...
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6: (28 commits) pciehp - fix wrong return value IA64: PCI: dont disable irq which is not enabled acpiphp: add support for ioapic hot-remove PCI: assign ioapic resource at hotplug acpiphp: disable bridges acpiphp: stop bus device before acpi_bus_trim PCI: add pci_stop_bus_device acpiphp: do not initialize existing ioapics acpiphp: initialize ioapics before starting devices acpiphp: set hpp values before starting devices PCI Hotplug: cleanup pcihp skeleton code. PCI: Restore PCI Express capability registers after PM event PCI: drivers/pci/hotplug/acpiphp_glue.c: make a function static PCI: Multiprobe sanitizer PCI: fix __must_check warnings PCI Hotplug: fix __must_check warnings SHPCHP: fix __must_check warnings PCI-Express AER implemetation: pcie_portdrv error handler PCI-Express AER implemetation: AER core and aerdriver PCI-Express AER implemetation: export pcie_port_bus_type ...
-
Franck Bui-Huu authored
There's no point to rewrite some logic to parse command line to pass initrd parameters or to declare a user memory area. We could use instead parse_early_param() that does the same thing. Signed-off-by:
Franck Bui-Huu <vagabon.xyz@gmail.com> Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Franck Bui-Huu authored
It doesn't improve readability. Signed-off-by:
-
Franck Bui-Huu authored
There's no point to inline any functions in setup.c. Let's GCC doing its job, it's good enough for that now. Signed-off-by:
-
Franck Bui-Huu authored
Signed-off-by:
-
Franck Bui-Huu authored
NUMA specific code could rely on them too. Signed-off-by:
-
Franck Bui-Huu authored
This function although doing simple thing is hard to follow. It's mainly due to: - a lot of #ifdef - bad local names - redundant tests So this patch try to address these issues. It also do not use max_pfn global which is marked as an unused exported symbol. As a bonus side, it's now really easy to see what part of the code is for no-numa system. There's also no point to make this function inline. Signed-off-by: -
Franck Bui-Huu authored
This array was used to 'cache' some frame info about scheduler functions to speed up get_wchan(). This array was 1Ko size and was only used when CONFIG_KALLSYMS was set but declared for all configs. Rather than make the array statement conditional, this patches removes this array and its uses. Indeed the common case doesn't seem to use this array and get_wchan() is not a critical path anyways. It results in a smaller bss and a smaller/cleaner code: text data bss dec hex filename 2543808 254148 139296 2937252 2cd1a4 vmlinux-new-get-wchan 2544080 254148 143392 2941620 2ce2b4 vmlinux~old Signed-off-by:
-
Franck Bui-Huu authored
This patch adds 2 sanity checks. The first one test that the start address of the function to analyze has been set by the caller. If not return an error since nothing usefull can be done without. The second one checks that the function's size has been set. A null size can happen if CONFIG_KALLSYMS is not set and it means that we don't know the size of the function to analyze. In this case, we make it equal to 128 instructions by default. Signed-off-by:
-
Franck Bui-Huu authored
Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Richard Sandiford authored
MIPS is the only port to call its fstatat()-related syscalls "__NR_fstatat". Now I can see why that might be seen as every other port being wrong, but I think for o32, it is at best confusing. __NR_fstat provides a plain (32-bit) stat while __NR_fstatat provides a 64-bit stat. Changing the name to __NR_fstatat64 would make things more explicit, match x86, and make the glibc port slightly easier. The current name is more appropriate for n32 and n64, but it would be appropriate for other 64-bit targets too, and those targets have chosen to call it __NR_newfstatat instead. Using the same name for MIPS would again be more consistent and make the glibc port slightly easier. I'm not wedded to this idea if the current names are preferred, but FWIW... Signed-off-by:
Richard Sandiford <richard@codesourcery.com> Signed-off-by:
-
Richard Sandiford authored
While working on a glibc patch to support the fstatat() functions[1], I noticed that the o32 implementation behaves differently on 32-bit and 64-bit kernels; the former provides a stat64 while the latter provides a plain (o32) stat. I think the former is what's intended, as there is no separate fstatat64. It's also what x86 does. I think this is just a case of a compat too far. [1] I've seen Khem's patch, but I don't think it's right. Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Ralf Baechle authored
This is the unchanged part 2 of Chris' hazard cleanup. Signed-off-by: -
Ralf Baechle authored
Mostly based on patch by Chris Dearman and cleanups from Yoichi. Signed-off-by: -
Ralf Baechle authored
Signed-off-by: -
Peter Watkins authored
The code in pgtable-64.h assumes TASK_SIZE is always bigger than a first level PGDIR_SIZE. This is not the case for 64K pages, where task size is 40 bits (1TB) and a pgd entry can map 42 bits. This leads to USER_PTRS_PER_PGD being zero for 64K pages. Signed-off-by:
Peter Watkins <treestem@gmail.com> Signed-off-by:
-
thomas@koeller.dyndns.org authored
This patch introduces a number of configuration variables. These allow to specify presence/absence of integrated peripherals found on the MIPS RM9xxx processor family, based on the particular processor model used. Signed-off-by:
Thomas Koeller <thomas.koeller@baslerweb.com> Signed-off-by:
-
thomas@koeller.dyndns.org authored
excite_fpga.h, like all platform headers, really belongs in the platform header directory. Signed-off-by:
-
thomas@koeller.dyndns.org authored
The excite platform exports hardware resources for device drivers to use. Any driver wanting to use these resources will look up them by their names. Since these resources are declared to have static linkage, but are not used in the source file defining them, the compiler used to emit an 'unused' warning, which this patch suppresses. Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Atsushi Nemoto authored
Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
-
Yoichi Yuasa authored
Signed-off-by:
Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by:
-
Ralf Baechle authored
Signed-off-by: -
Yoichi Yuasa authored
Signed-off-by:
-
