<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs/hfsplus/bitmap.c, branch v3.2.18</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/fs/hfsplus/bitmap.c?h=v3.2.18</id>
<link rel='self' href='https://git.amat.us/linux/atom/fs/hfsplus/bitmap.c?h=v3.2.18'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2010-12-16T17:08:45Z</updated>
<entry>
<title>hfsplus: over 80 character lines clean-up</title>
<updated>2010-12-16T17:08:45Z</updated>
<author>
<name>Anton Salikhmetov</name>
<email>alexo@tuxera.com</email>
</author>
<published>2010-12-16T16:08:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2753cc281c9a0e8a0a45ee2b8110866a9fe63bdd'/>
<id>urn:sha1:2753cc281c9a0e8a0a45ee2b8110866a9fe63bdd</id>
<content type='text'>
Match coding style line length limitation where checkpatch.pl
reported over-80-character-line warnings.

Signed-off-by: Anton Salikhmetov &lt;alexo@tuxera.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@tuxera.com&gt;
</content>
</entry>
<entry>
<title>hfsplus: fix HFSPLUS_SB calling convention</title>
<updated>2010-10-01T03:42:59Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@tuxera.com</email>
</author>
<published>2010-10-01T03:42:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=dd73a01a30d729e8fa6f829c4582650e258e36f9'/>
<id>urn:sha1:dd73a01a30d729e8fa6f829c4582650e258e36f9</id>
<content type='text'>
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 &lt;hch@tuxera.com&gt;
</content>
</entry>
<entry>
<title>hfsplus: introduce alloc_mutex</title>
<updated>2010-10-01T03:41:39Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2010-10-01T03:41:39Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=40bf48afe92fcea61e7e164f0b2599fba8b88124'/>
<id>urn:sha1:40bf48afe92fcea61e7e164f0b2599fba8b88124</id>
<content type='text'>
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 &lt;hch@tuxera.com&gt;
</content>
</entry>
<entry>
<title>hfsplus: check read_mapping_page() return value</title>
<updated>2008-10-16T18:21:46Z</updated>
<author>
<name>Eric Sesterhenn</name>
<email>snakebyte@gmx.de</email>
</author>
<published>2008-10-16T05:04:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=649f1ee6c705aab644035a7998d7b574193a598a'/>
<id>urn:sha1:649f1ee6c705aab644035a7998d7b574193a598a</id>
<content type='text'>
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: [&lt;c0116a4f&gt;] 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:[&lt;c0116a4f&gt;] 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]  [&lt;c0231cfb&gt;] ? hfsplus_block_allocate+0x6f/0x2d3
[15840.675016]  [&lt;c022cb3a&gt;] ? hfsplus_file_extend+0xc4/0x1db
[15840.675016]  [&lt;c022ce41&gt;] ? hfsplus_get_block+0x8c/0x19d
[15840.675016]  [&lt;c06adde4&gt;] ? sub_preempt_count+0x9d/0xab
[15840.675016]  [&lt;c019ece6&gt;] ? __block_prepare_write+0x147/0x311
[15840.675016]  [&lt;c0161934&gt;] ? __grab_cache_page+0x52/0x73
[15840.675016]  [&lt;c019ef4f&gt;] ? block_write_begin+0x79/0xd5
[15840.675016]  [&lt;c022cdb5&gt;] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [&lt;c019f22a&gt;] ? cont_write_begin+0x27f/0x2af
[15840.675016]  [&lt;c022cdb5&gt;] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [&lt;c0139ebe&gt;] ? tick_program_event+0x28/0x4c
[15840.675016]  [&lt;c013bd35&gt;] ? trace_hardirqs_off+0xb/0xd
[15840.675016]  [&lt;c022b723&gt;] ? hfsplus_write_begin+0x2d/0x32
[15840.675016]  [&lt;c022cdb5&gt;] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [&lt;c0161988&gt;] ? pagecache_write_begin+0x33/0x107
[15840.675016]  [&lt;c01879e5&gt;] ? __page_symlink+0x3c/0xae
[15840.675016]  [&lt;c019ad34&gt;] ? __mark_inode_dirty+0x12f/0x137
[15840.675016]  [&lt;c0187a70&gt;] ? page_symlink+0x19/0x1e
[15840.675016]  [&lt;c022e6eb&gt;] ? hfsplus_symlink+0x41/0xa6
[15840.675016]  [&lt;c01886a9&gt;] ? vfs_symlink+0x99/0x101
[15840.675016]  [&lt;c018a2f6&gt;] ? sys_symlinkat+0x6b/0xad
[15840.675016]  [&lt;c018a348&gt;] ? sys_symlink+0x10/0x12
[15840.675016]  [&lt;c01038bd&gt;] ? 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 &lt;8b&gt; 03 c1 e8 1e 69 c0 d8 02 00 00 05 b8 69 8e c0 2b 80 c4 02 00
[15840.675016] EIP: [&lt;c0116a4f&gt;] 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 &lt;snakebyte@gmx.de&gt;
Cc: Roman Zippel &lt;zippel@linux-m68k.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] read_mapping_page for address space</title>
<updated>2006-06-23T14:43:02Z</updated>
<author>
<name>Pekka Enberg</name>
<email>penberg@cs.helsinki.fi</email>
</author>
<published>2006-06-23T09:05:08Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=090d2b185d8680fc26a2eaf4245d4171dcf4baf1'/>
<id>urn:sha1:090d2b185d8680fc26a2eaf4245d4171dcf4baf1</id>
<content type='text'>
Add read_mapping_page() which is used for callers that pass
mapping-&gt;a_ops-&gt;readpage as the filler for read_cache_page.  This removes
some duplication from filesystem code.

Signed-off-by: Pekka Enberg &lt;penberg@cs.helsinki.fi&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] mutex subsystem, semaphore to mutex: VFS, -&gt;i_sem</title>
<updated>2006-01-09T23:59:24Z</updated>
<author>
<name>Jes Sorensen</name>
<email>jes@sgi.com</email>
</author>
<published>2006-01-09T23:59:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1b1dcc1b57a49136f118a0f16367256ff9994a69'/>
<id>urn:sha1:1b1dcc1b57a49136f118a0f16367256ff9994a69</id>
<content type='text'>
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 &lt;mingo@elte.hu&gt;

(finished the conversion)

Signed-off-by: Jes Sorensen &lt;jes@sgi.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>urn:sha1:1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
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!
</content>
</entry>
</feed>
