summaryrefslogtreecommitdiff
path: root/fs/hfsplus/bfind.c
AgeCommit message (Collapse)Author
2010-12-16hfsplus: over 80 character lines clean-upAnton Salikhmetov
Match coding style line length limitation where checkpatch.pl reported over-80-character-line warnings. Signed-off-by: Anton Salikhmetov <alexo@tuxera.com> Signed-off-by: Christoph Hellwig <hch@tuxera.com>
2010-10-14hfsplus: handle more on-disk corruptions without oopsingEric Sandeen
hfs seems prone to bad things when it encounters on disk corruption. Many values are read from disk, and used as lengths to memcpy, as an example. This patch fixes up several of these problematic cases. o sanity check the on-disk maximum key lengths on mount (these are set to a defined value at mkfs time and shouldn't differ) o check on-disk node keylens against the maximum key length for each tree o fix hfs_btree_open so that going out via free_tree: doesn't wind up in hfs_releasepage, which wants to follow the very pointer we were trying to set up: HFS_SB(sb)->cat_tree = hfs_btree_open() . failure gets to hfs_releasepage and tries to follow HFS_SB(sb)->cat_tree Tested with the fsfuzzer; it survives more than it used to. [hch: ported of commit cf0594625083111ae522496dc1c256f7476939c2 from hfs] [hch: added the fixes from 5581d018ed3493d226e7a4d645d9c8a5af6c36b] Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Christoph Hellwig <hch@tuxera.com>
2010-10-01hfsplus: convert tree_lock to mutexThomas Gleixner
tree_lock is used as mutex so make it a mutex. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Christoph Hellwig <hch@tuxera.com>
2006-01-19[PATCH] hfs: cleanup HFS+ printsRoman Zippel
Add the log level and a "hfs: " prefix to all kernel prints. (HFS and HFS+ will use the same prefix, as they share some code and could be merged at some point.) Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!