2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-21 19:53:59 +08:00
Commit Graph

6 Commits

Author SHA1 Message Date
Christoph Hellwig
dd73a01a30 hfsplus: fix HFSPLUS_SB calling convention
HFSPLUS_SB doesn't return a pointer to the hfsplus-specific superblock
information like all other FOO_SB macros, but dereference the pointer in a way
that made it look like a direct struct derefence.  This only works as long
as the HFSPLUS_SB macro is used directly and prevents us from keepig a local
hfsplus_sb_info pointer.  Fix the calling convention and introduce a local
sbi variable in all functions that use it constantly.

Signed-off-by: Christoph Hellwig <hch@tuxera.com>
2010-10-01 05:42:59 +02:00
Christoph Hellwig
40bf48afe9 hfsplus: introduce alloc_mutex
Use a new per-sb alloc_mutex instead of abusing i_mutex of the alloc_file
to protect block allocations.  This gets rid of lockdep nesting warnings
and prepares for extending the scope of alloc_mutex.

Signed-off-by: Christoph Hellwig <hch@tuxera.com>
2010-10-01 05:41:39 +02:00
Eric Sesterhenn
649f1ee6c7 hfsplus: check read_mapping_page() return value
While testing more corrupted images with hfsplus, i came across
one which triggered the following bug:

[15840.675016] BUG: unable to handle kernel paging request at fffffffb
[15840.675016] IP: [<c0116a4f>] kmap+0x15/0x56
[15840.675016] *pde = 00008067 *pte = 00000000
[15840.675016] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
[15840.675016] Modules linked in:
[15840.675016]
[15840.675016] Pid: 11575, comm: ln Not tainted (2.6.27-rc4-00123-gd3ee1b4-dirty #29)
[15840.675016] EIP: 0060:[<c0116a4f>] EFLAGS: 00010202 CPU: 0
[15840.675016] EIP is at kmap+0x15/0x56
[15840.675016] EAX: 00000246 EBX: fffffffb ECX: 00000000 EDX: cab919c0
[15840.675016] ESI: 000007dd EDI: cab0bcf4 EBP: cab0bc98 ESP: cab0bc94
[15840.675016]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[15840.675016] Process ln (pid: 11575, ti=cab0b000 task=cab919c0 task.ti=cab0b000)
[15840.675016] Stack: 00000000 cab0bcdc c0231cfb 00000000 cab0bce0 00000800 ca9290c0 fffffffb
[15840.675016]        cab145d0 cab919c0 cab15998 22222222 22222222 22222222 00000001 cab15960
[15840.675016]        000007dd cab0bcf4 cab0bd04 c022cb3a cab0bcf4 cab15a6c ca9290c0 00000000
[15840.675016] Call Trace:
[15840.675016]  [<c0231cfb>] ? hfsplus_block_allocate+0x6f/0x2d3
[15840.675016]  [<c022cb3a>] ? hfsplus_file_extend+0xc4/0x1db
[15840.675016]  [<c022ce41>] ? hfsplus_get_block+0x8c/0x19d
[15840.675016]  [<c06adde4>] ? sub_preempt_count+0x9d/0xab
[15840.675016]  [<c019ece6>] ? __block_prepare_write+0x147/0x311
[15840.675016]  [<c0161934>] ? __grab_cache_page+0x52/0x73
[15840.675016]  [<c019ef4f>] ? block_write_begin+0x79/0xd5
[15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [<c019f22a>] ? cont_write_begin+0x27f/0x2af
[15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [<c0139ebe>] ? tick_program_event+0x28/0x4c
[15840.675016]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[15840.675016]  [<c022b723>] ? hfsplus_write_begin+0x2d/0x32
[15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [<c0161988>] ? pagecache_write_begin+0x33/0x107
[15840.675016]  [<c01879e5>] ? __page_symlink+0x3c/0xae
[15840.675016]  [<c019ad34>] ? __mark_inode_dirty+0x12f/0x137
[15840.675016]  [<c0187a70>] ? page_symlink+0x19/0x1e
[15840.675016]  [<c022e6eb>] ? hfsplus_symlink+0x41/0xa6
[15840.675016]  [<c01886a9>] ? vfs_symlink+0x99/0x101
[15840.675016]  [<c018a2f6>] ? sys_symlinkat+0x6b/0xad
[15840.675016]  [<c018a348>] ? sys_symlink+0x10/0x12
[15840.675016]  [<c01038bd>] ? sysenter_do_call+0x12/0x31
[15840.675016]  =======================
[15840.675016] Code: 00 00 75 10 83 3d 88 2f ec c0 02 75 07 89 d0 e8 12 56 05 00 5d c3 55 ba 06 00 00 00 89 e5 53 89 c3 b8 3d eb 7e c0 e8 16 74 00 00 <8b> 03 c1 e8 1e 69 c0 d8 02 00 00 05 b8 69 8e c0 2b 80 c4 02 00
[15840.675016] EIP: [<c0116a4f>] kmap+0x15/0x56 SS:ESP 0068:cab0bc94
[15840.675016] ---[ end trace 4fea40dad6b70e5f ]---

This happens because the return value of read_mapping_page() is passed on
to kmap unchecked.  The bug is triggered after the first
read_mapping_page() in hfsplus_block_allocate(), this patch fixes all
three usages in this functions but leaves the ones further down in the
file unchanged.

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-16 11:21:46 -07:00
Pekka Enberg
090d2b185d [PATCH] read_mapping_page for address space
Add read_mapping_page() which is used for callers that pass
mapping->a_ops->readpage as the filler for read_cache_page.  This removes
some duplication from filesystem code.

Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-23 07:43:02 -07:00
Jes Sorensen
1b1dcc1b57 [PATCH] mutex subsystem, semaphore to mutex: VFS, ->i_sem
This patch converts the inode semaphore to a mutex. I have tested it on
XFS and compiled as much as one can consider on an ia64. Anyway your
luck with it might be different.

Modified-by: Ingo Molnar <mingo@elte.hu>

(finished the conversion)

Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2006-01-09 15:59:24 -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