<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/fs/logfs/logfs.h, branch v3.4.26</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Merge tag 'for-linus' of git://github.com/prasad-joshi/logfs_upstream</title>
<updated>2012-01-31T17:23:59+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-01-31T17:23:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d3712b9dfcf44ca145cf87e7f4096fa2d923471a'/>
<id>d3712b9dfcf44ca145cf87e7f4096fa2d923471a</id>
<content type='text'>
There are few important bug fixes for LogFS

* tag 'for-linus' of git://github.com/prasad-joshi/logfs_upstream:
  Logfs: Allow NULL block_isbad() methods
  logfs: Grow inode in delete path
  logfs: Free areas before calling generic_shutdown_super()
  logfs: remove useless BUG_ON
  MAINTAINERS: Add Prasad Joshi in LogFS maintiners
  logfs: Propagate page parameter to __logfs_write_inode
  logfs: set superblock shutdown flag after generic sb shutdown
  logfs: take write mutex lock during fsync and sync
  logfs: Prevent memory corruption
  logfs: update page reference count for pined pages

Fix up conflict in fs/logfs/dev_mtd.c due to semantic change in what
"mtd-&gt;block_isbad" means in commit f2933e86ad93: "Logfs: Allow NULL
block_isbad() methods" clashing with the abstraction changes in the
commits 7086c19d0742: "mtd: introduce mtd_block_isbad interface" and
d58b27ed58a3: "logfs: do not use 'mtd-&gt;block_isbad' directly".

This resolution takes the semantics from commit f2933e86ad93, and just
makes mtd_block_isbad() return zero (false) if the 'block_isbad'
function is NULL.  But that also means that now "mtd_can_have_bb()"
always returns 0.

Now, "mtd_block_markbad()" will obviously return an error if the
low-level driver doesn't support bad blocks, so this is somewhat
non-symmetric, but it actually makes sense if a NULL "block_isbad"
function is considered to mean "I assume that all my blocks are always
good".
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are few important bug fixes for LogFS

* tag 'for-linus' of git://github.com/prasad-joshi/logfs_upstream:
  Logfs: Allow NULL block_isbad() methods
  logfs: Grow inode in delete path
  logfs: Free areas before calling generic_shutdown_super()
  logfs: remove useless BUG_ON
  MAINTAINERS: Add Prasad Joshi in LogFS maintiners
  logfs: Propagate page parameter to __logfs_write_inode
  logfs: set superblock shutdown flag after generic sb shutdown
  logfs: take write mutex lock during fsync and sync
  logfs: Prevent memory corruption
  logfs: update page reference count for pined pages

Fix up conflict in fs/logfs/dev_mtd.c due to semantic change in what
"mtd-&gt;block_isbad" means in commit f2933e86ad93: "Logfs: Allow NULL
block_isbad() methods" clashing with the abstraction changes in the
commits 7086c19d0742: "mtd: introduce mtd_block_isbad interface" and
d58b27ed58a3: "logfs: do not use 'mtd-&gt;block_isbad' directly".

This resolution takes the semantics from commit f2933e86ad93, and just
makes mtd_block_isbad() return zero (false) if the 'block_isbad'
function is NULL.  But that also means that now "mtd_can_have_bb()"
always returns 0.

Now, "mtd_block_markbad()" will obviously return an error if the
low-level driver doesn't support bad blocks, so this is somewhat
non-symmetric, but it actually makes sense if a NULL "block_isbad"
function is considered to mean "I assume that all my blocks are always
good".
</pre>
</div>
</content>
</entry>
<entry>
<title>logfs: Free areas before calling generic_shutdown_super()</title>
<updated>2012-01-28T06:12:39+00:00</updated>
<author>
<name>Joern Engel</name>
<email>joern@logfs.org</email>
</author>
<published>2011-08-05T09:18:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1bcceaff8cbe5e5698ccf1015c9a938aa72718c4'/>
<id>1bcceaff8cbe5e5698ccf1015c9a938aa72718c4</id>
<content type='text'>
Or hit an assertion in map_invalidatepage() instead.

Signed-off-by: Joern Engel &lt;joern@logfs.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Or hit an assertion in map_invalidatepage() instead.

Signed-off-by: Joern Engel &lt;joern@logfs.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>logfs: Propagate page parameter to __logfs_write_inode</title>
<updated>2012-01-28T06:08:25+00:00</updated>
<author>
<name>Prasad Joshi</name>
<email>prasadjoshi.linux@gmail.com</email>
</author>
<published>2011-10-02T18:16:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0bd90387ed5a8abbcf43391b480efdc211721cfe'/>
<id>0bd90387ed5a8abbcf43391b480efdc211721cfe</id>
<content type='text'>
During GC LogFS has to rewrite each valid block to a separate segment.
Rewrite operation reads data from an old segment and writes it to a
newly allocated segment. Since every write operation changes data
block pointers maintained in inode, inode should also be rewritten.

In GC path to avoid AB-BA deadlock LogFS marks a page with
PG_pre_locked in addition to locking the page (PG_locked). The page
lock is ignored iff the page is pre-locked.

LogFS uses a special file called segment file. The segment file
maintains an 8 bytes entry for every segment. It keeps track of erase
count, level etc. for every segment.

Bad things happen with a segment belonging to the segment file is GCed

 ------------[ cut here ]------------
kernel BUG at /home/prasad/logfs/readwrite.c:297!
invalid opcode: 0000 [#1] SMP
Modules linked in: logfs joydev usbhid hid psmouse e1000 i2c_piix4
		serio_raw [last unloaded: logfs]
Pid: 20161, comm: mount Not tainted 3.1.0-rc3+ #3 innotek GmbH
		VirtualBox
EIP: 0060:[&lt;f809132a&gt;] EFLAGS: 00010292 CPU: 0
EIP is at logfs_lock_write_page+0x6a/0x70 [logfs]
EAX: 00000027 EBX: f73f5b20 ECX: c16007c8 EDX: 00000094
ESI: 00000000 EDI: e59be6e4 EBP: c7337b28 ESP: c7337b18
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process mount (pid: 20161, ti=c7336000 task=eb323f70 task.ti=c7336000)
Stack:
f8099a3d c7337b24 f73f5b20 00001002 c7337b50 f8091f6d f8099a4d f80994e4
00000003 00000000 c7337b68 00000000 c67e4400 00001000 c7337b80 f80935e5
00000000 00000000 00000000 00000000 e1fcf000 0000000f e59be618 c70bf900
Call Trace:
[&lt;f8091f6d&gt;] logfs_get_write_page.clone.16+0xdd/0x100 [logfs]
[&lt;f80935e5&gt;] logfs_mod_segment_entry+0x55/0x110 [logfs]
[&lt;f809460d&gt;] logfs_get_segment_entry+0x1d/0x20 [logfs]
[&lt;f8091060&gt;] ? logfs_cleanup_journal+0x50/0x50 [logfs]
[&lt;f809521b&gt;] ostore_get_erase_count+0x1b/0x40 [logfs]
[&lt;f80965b8&gt;] logfs_open_area+0xc8/0x150 [logfs]
[&lt;c141a7ec&gt;] ? kmemleak_alloc+0x2c/0x60
[&lt;f809668e&gt;] __logfs_segment_write.clone.16+0x4e/0x1b0 [logfs]
[&lt;c10dd563&gt;] ? mempool_kmalloc+0x13/0x20
[&lt;c10dd563&gt;] ? mempool_kmalloc+0x13/0x20
[&lt;f809696f&gt;] logfs_segment_write+0x17f/0x1d0 [logfs]
[&lt;f8092e8c&gt;] logfs_write_i0+0x11c/0x180 [logfs]
[&lt;f8092f35&gt;] logfs_write_direct+0x45/0x90 [logfs]
[&lt;f80934cd&gt;] __logfs_write_buf+0xbd/0xf0 [logfs]
[&lt;c102900e&gt;] ? kmap_atomic_prot+0x4e/0xe0
[&lt;f809424b&gt;] logfs_write_buf+0x3b/0x60 [logfs]
[&lt;f80947a9&gt;] __logfs_write_inode+0xa9/0x110 [logfs]
[&lt;f8094cb0&gt;] logfs_rewrite_block+0xc0/0x110 [logfs]
[&lt;f8095300&gt;] ? get_mapping_page+0x10/0x60 [logfs]
[&lt;f8095aa0&gt;] ? logfs_load_object_aliases+0x2e0/0x2f0 [logfs]
[&lt;f808e57d&gt;] logfs_gc_segment+0x2ad/0x310 [logfs]
[&lt;f808e62a&gt;] __logfs_gc_once+0x4a/0x80 [logfs]
[&lt;f808ed43&gt;] logfs_gc_pass+0x683/0x6a0 [logfs]
[&lt;f8097a89&gt;] logfs_mount+0x5a9/0x680 [logfs]
[&lt;c1126b21&gt;] mount_fs+0x21/0xd0
[&lt;c10f6f6f&gt;] ? __alloc_percpu+0xf/0x20
[&lt;c113da41&gt;] ? alloc_vfsmnt+0xb1/0x130
[&lt;c113db4b&gt;] vfs_kern_mount+0x4b/0xa0
[&lt;c113e06e&gt;] do_kern_mount+0x3e/0xe0
[&lt;c113f60d&gt;] do_mount+0x34d/0x670
[&lt;c10f2749&gt;] ? strndup_user+0x49/0x70
[&lt;c113fcab&gt;] sys_mount+0x6b/0xa0
[&lt;c142d87c&gt;] syscall_call+0x7/0xb
Code: f8 e8 8b 93 39 c9 8b 45 f8 3e 0f ba 28 00 19 d2 85 d2 74 ca eb d0 0f 0b 8d 45 fc 89 44 24 04 c7 04 24 3d 9a 09 f8 e8 09 92 39 c9 &lt;0f&gt; 0b 8d 74 26 00 55 89 e5 3e 8d 74 26 00 8b 10 80 e6 01 74 09
EIP: [&lt;f809132a&gt;] logfs_lock_write_page+0x6a/0x70 [logfs] SS:ESP 0068:c7337b18
---[ end trace 96e67d5b3aa3d6ca ]---

The patch passes locked page to __logfs_write_inode. It calls function
logfs_get_wblocks() to pre-lock the page. This ensures any further
attempts to lock the page are ignored (esp from get_erase_count).

Acked-by: Joern Engel &lt;joern@logfs.org&gt;
Signed-off-by: Prasad Joshi &lt;prasadjoshi.linux@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During GC LogFS has to rewrite each valid block to a separate segment.
Rewrite operation reads data from an old segment and writes it to a
newly allocated segment. Since every write operation changes data
block pointers maintained in inode, inode should also be rewritten.

In GC path to avoid AB-BA deadlock LogFS marks a page with
PG_pre_locked in addition to locking the page (PG_locked). The page
lock is ignored iff the page is pre-locked.

LogFS uses a special file called segment file. The segment file
maintains an 8 bytes entry for every segment. It keeps track of erase
count, level etc. for every segment.

Bad things happen with a segment belonging to the segment file is GCed

 ------------[ cut here ]------------
kernel BUG at /home/prasad/logfs/readwrite.c:297!
invalid opcode: 0000 [#1] SMP
Modules linked in: logfs joydev usbhid hid psmouse e1000 i2c_piix4
		serio_raw [last unloaded: logfs]
Pid: 20161, comm: mount Not tainted 3.1.0-rc3+ #3 innotek GmbH
		VirtualBox
EIP: 0060:[&lt;f809132a&gt;] EFLAGS: 00010292 CPU: 0
EIP is at logfs_lock_write_page+0x6a/0x70 [logfs]
EAX: 00000027 EBX: f73f5b20 ECX: c16007c8 EDX: 00000094
ESI: 00000000 EDI: e59be6e4 EBP: c7337b28 ESP: c7337b18
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process mount (pid: 20161, ti=c7336000 task=eb323f70 task.ti=c7336000)
Stack:
f8099a3d c7337b24 f73f5b20 00001002 c7337b50 f8091f6d f8099a4d f80994e4
00000003 00000000 c7337b68 00000000 c67e4400 00001000 c7337b80 f80935e5
00000000 00000000 00000000 00000000 e1fcf000 0000000f e59be618 c70bf900
Call Trace:
[&lt;f8091f6d&gt;] logfs_get_write_page.clone.16+0xdd/0x100 [logfs]
[&lt;f80935e5&gt;] logfs_mod_segment_entry+0x55/0x110 [logfs]
[&lt;f809460d&gt;] logfs_get_segment_entry+0x1d/0x20 [logfs]
[&lt;f8091060&gt;] ? logfs_cleanup_journal+0x50/0x50 [logfs]
[&lt;f809521b&gt;] ostore_get_erase_count+0x1b/0x40 [logfs]
[&lt;f80965b8&gt;] logfs_open_area+0xc8/0x150 [logfs]
[&lt;c141a7ec&gt;] ? kmemleak_alloc+0x2c/0x60
[&lt;f809668e&gt;] __logfs_segment_write.clone.16+0x4e/0x1b0 [logfs]
[&lt;c10dd563&gt;] ? mempool_kmalloc+0x13/0x20
[&lt;c10dd563&gt;] ? mempool_kmalloc+0x13/0x20
[&lt;f809696f&gt;] logfs_segment_write+0x17f/0x1d0 [logfs]
[&lt;f8092e8c&gt;] logfs_write_i0+0x11c/0x180 [logfs]
[&lt;f8092f35&gt;] logfs_write_direct+0x45/0x90 [logfs]
[&lt;f80934cd&gt;] __logfs_write_buf+0xbd/0xf0 [logfs]
[&lt;c102900e&gt;] ? kmap_atomic_prot+0x4e/0xe0
[&lt;f809424b&gt;] logfs_write_buf+0x3b/0x60 [logfs]
[&lt;f80947a9&gt;] __logfs_write_inode+0xa9/0x110 [logfs]
[&lt;f8094cb0&gt;] logfs_rewrite_block+0xc0/0x110 [logfs]
[&lt;f8095300&gt;] ? get_mapping_page+0x10/0x60 [logfs]
[&lt;f8095aa0&gt;] ? logfs_load_object_aliases+0x2e0/0x2f0 [logfs]
[&lt;f808e57d&gt;] logfs_gc_segment+0x2ad/0x310 [logfs]
[&lt;f808e62a&gt;] __logfs_gc_once+0x4a/0x80 [logfs]
[&lt;f808ed43&gt;] logfs_gc_pass+0x683/0x6a0 [logfs]
[&lt;f8097a89&gt;] logfs_mount+0x5a9/0x680 [logfs]
[&lt;c1126b21&gt;] mount_fs+0x21/0xd0
[&lt;c10f6f6f&gt;] ? __alloc_percpu+0xf/0x20
[&lt;c113da41&gt;] ? alloc_vfsmnt+0xb1/0x130
[&lt;c113db4b&gt;] vfs_kern_mount+0x4b/0xa0
[&lt;c113e06e&gt;] do_kern_mount+0x3e/0xe0
[&lt;c113f60d&gt;] do_mount+0x34d/0x670
[&lt;c10f2749&gt;] ? strndup_user+0x49/0x70
[&lt;c113fcab&gt;] sys_mount+0x6b/0xa0
[&lt;c142d87c&gt;] syscall_call+0x7/0xb
Code: f8 e8 8b 93 39 c9 8b 45 f8 3e 0f ba 28 00 19 d2 85 d2 74 ca eb d0 0f 0b 8d 45 fc 89 44 24 04 c7 04 24 3d 9a 09 f8 e8 09 92 39 c9 &lt;0f&gt; 0b 8d 74 26 00 55 89 e5 3e 8d 74 26 00 8b 10 80 e6 01 74 09
EIP: [&lt;f809132a&gt;] logfs_lock_write_page+0x6a/0x70 [logfs] SS:ESP 0068:c7337b18
---[ end trace 96e67d5b3aa3d6ca ]---

The patch passes locked page to __logfs_write_inode. It calls function
logfs_get_wblocks() to pre-lock the page. This ensures any further
attempts to lock the page are ignored (esp from get_erase_count).

Acked-by: Joern Engel &lt;joern@logfs.org&gt;
Signed-off-by: Prasad Joshi &lt;prasadjoshi.linux@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>logfs: take write mutex lock during fsync and sync</title>
<updated>2012-01-28T06:06:06+00:00</updated>
<author>
<name>Prasad Joshi</name>
<email>prasadjoshi.linux@gmail.com</email>
</author>
<published>2012-01-28T06:06:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=13ced29cb28996a9bc4f68e43ff0c57eafdb1e21'/>
<id>13ced29cb28996a9bc4f68e43ff0c57eafdb1e21</id>
<content type='text'>
LogFS uses super-&gt;s_write_mutex while writing data to disk. Taking the
same mutex lock in sync and fsync code path solves the following BUG:

------------[ cut here ]------------
kernel BUG at /home/prasad/logfs/dev_bdev.c:134!

Pid: 2387, comm: flush-253:16 Not tainted 3.0.0+ #4 Bochs Bochs
RIP: 0010:[&lt;ffffffffa007deed&gt;]  [&lt;ffffffffa007deed&gt;]
                bdev_writeseg+0x25d/0x270 [logfs]
Call Trace:
[&lt;ffffffffa007c381&gt;] logfs_open_area+0x91/0x150 [logfs]
[&lt;ffffffff8128dcb2&gt;] ? find_level.clone.9+0x62/0x100
[&lt;ffffffffa007c49c&gt;] __logfs_segment_write.clone.20+0x5c/0x190 [logfs]
[&lt;ffffffff810ef005&gt;] ? mempool_kmalloc+0x15/0x20
[&lt;ffffffff810ef383&gt;] ? mempool_alloc+0x53/0x130
[&lt;ffffffffa007c7a4&gt;] logfs_segment_write+0x1d4/0x230 [logfs]
[&lt;ffffffffa0078f8e&gt;] logfs_write_i0+0x12e/0x190 [logfs]
[&lt;ffffffffa0079300&gt;] __logfs_write_rec+0x140/0x220 [logfs]
[&lt;ffffffffa0079444&gt;] logfs_write_rec+0x64/0xd0 [logfs]
[&lt;ffffffffa00795b6&gt;] __logfs_write_buf+0x106/0x110 [logfs]
[&lt;ffffffffa007a13e&gt;] logfs_write_buf+0x4e/0x80 [logfs]
[&lt;ffffffffa0073e33&gt;] __logfs_writepage+0x23/0x80 [logfs]
[&lt;ffffffffa007410c&gt;] logfs_writepage+0xdc/0x110 [logfs]
[&lt;ffffffff810f5ba7&gt;] __writepage+0x17/0x40
[&lt;ffffffff810f6208&gt;] write_cache_pages+0x208/0x4f0
[&lt;ffffffff810f5b90&gt;] ? set_page_dirty+0x70/0x70
[&lt;ffffffff810f653a&gt;] generic_writepages+0x4a/0x70
[&lt;ffffffff810f75d1&gt;] do_writepages+0x21/0x40
[&lt;ffffffff8116b9d1&gt;] writeback_single_inode+0x101/0x250
[&lt;ffffffff8116bdbd&gt;] writeback_sb_inodes+0xed/0x1c0
[&lt;ffffffff8116c5fb&gt;] writeback_inodes_wb+0x7b/0x1e0
[&lt;ffffffff8116cc23&gt;] wb_writeback+0x4c3/0x530
[&lt;ffffffff814d984d&gt;] ? sub_preempt_count+0x9d/0xd0
[&lt;ffffffff8116cd6b&gt;] wb_do_writeback+0xdb/0x290
[&lt;ffffffff814d984d&gt;] ? sub_preempt_count+0x9d/0xd0
[&lt;ffffffff814d6208&gt;] ? _raw_spin_unlock_irqrestore+0x18/0x40
[&lt;ffffffff8105aa5a&gt;] ? del_timer+0x8a/0x120
[&lt;ffffffff8116cfac&gt;] bdi_writeback_thread+0x8c/0x2e0
[&lt;ffffffff8116cf20&gt;] ? wb_do_writeback+0x290/0x290
[&lt;ffffffff8106d2e6&gt;] kthread+0x96/0xa0
[&lt;ffffffff814de514&gt;] kernel_thread_helper+0x4/0x10
[&lt;ffffffff8106d250&gt;] ? kthread_worker_fn+0x190/0x190
[&lt;ffffffff814de510&gt;] ? gs_change+0xb/0xb
RIP  [&lt;ffffffffa007deed&gt;] bdev_writeseg+0x25d/0x270 [logfs]
---[ end trace 0211ad60a57657c4 ]---

Reviewed-by: Joern Engel &lt;joern@logfs.org&gt;
Signed-off-by: Prasad Joshi &lt;prasadjoshi.linux@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
LogFS uses super-&gt;s_write_mutex while writing data to disk. Taking the
same mutex lock in sync and fsync code path solves the following BUG:

------------[ cut here ]------------
kernel BUG at /home/prasad/logfs/dev_bdev.c:134!

Pid: 2387, comm: flush-253:16 Not tainted 3.0.0+ #4 Bochs Bochs
RIP: 0010:[&lt;ffffffffa007deed&gt;]  [&lt;ffffffffa007deed&gt;]
                bdev_writeseg+0x25d/0x270 [logfs]
Call Trace:
[&lt;ffffffffa007c381&gt;] logfs_open_area+0x91/0x150 [logfs]
[&lt;ffffffff8128dcb2&gt;] ? find_level.clone.9+0x62/0x100
[&lt;ffffffffa007c49c&gt;] __logfs_segment_write.clone.20+0x5c/0x190 [logfs]
[&lt;ffffffff810ef005&gt;] ? mempool_kmalloc+0x15/0x20
[&lt;ffffffff810ef383&gt;] ? mempool_alloc+0x53/0x130
[&lt;ffffffffa007c7a4&gt;] logfs_segment_write+0x1d4/0x230 [logfs]
[&lt;ffffffffa0078f8e&gt;] logfs_write_i0+0x12e/0x190 [logfs]
[&lt;ffffffffa0079300&gt;] __logfs_write_rec+0x140/0x220 [logfs]
[&lt;ffffffffa0079444&gt;] logfs_write_rec+0x64/0xd0 [logfs]
[&lt;ffffffffa00795b6&gt;] __logfs_write_buf+0x106/0x110 [logfs]
[&lt;ffffffffa007a13e&gt;] logfs_write_buf+0x4e/0x80 [logfs]
[&lt;ffffffffa0073e33&gt;] __logfs_writepage+0x23/0x80 [logfs]
[&lt;ffffffffa007410c&gt;] logfs_writepage+0xdc/0x110 [logfs]
[&lt;ffffffff810f5ba7&gt;] __writepage+0x17/0x40
[&lt;ffffffff810f6208&gt;] write_cache_pages+0x208/0x4f0
[&lt;ffffffff810f5b90&gt;] ? set_page_dirty+0x70/0x70
[&lt;ffffffff810f653a&gt;] generic_writepages+0x4a/0x70
[&lt;ffffffff810f75d1&gt;] do_writepages+0x21/0x40
[&lt;ffffffff8116b9d1&gt;] writeback_single_inode+0x101/0x250
[&lt;ffffffff8116bdbd&gt;] writeback_sb_inodes+0xed/0x1c0
[&lt;ffffffff8116c5fb&gt;] writeback_inodes_wb+0x7b/0x1e0
[&lt;ffffffff8116cc23&gt;] wb_writeback+0x4c3/0x530
[&lt;ffffffff814d984d&gt;] ? sub_preempt_count+0x9d/0xd0
[&lt;ffffffff8116cd6b&gt;] wb_do_writeback+0xdb/0x290
[&lt;ffffffff814d984d&gt;] ? sub_preempt_count+0x9d/0xd0
[&lt;ffffffff814d6208&gt;] ? _raw_spin_unlock_irqrestore+0x18/0x40
[&lt;ffffffff8105aa5a&gt;] ? del_timer+0x8a/0x120
[&lt;ffffffff8116cfac&gt;] bdi_writeback_thread+0x8c/0x2e0
[&lt;ffffffff8116cf20&gt;] ? wb_do_writeback+0x290/0x290
[&lt;ffffffff8106d2e6&gt;] kthread+0x96/0xa0
[&lt;ffffffff814de514&gt;] kernel_thread_helper+0x4/0x10
[&lt;ffffffff8106d250&gt;] ? kthread_worker_fn+0x190/0x190
[&lt;ffffffff814de510&gt;] ? gs_change+0xb/0xb
RIP  [&lt;ffffffffa007deed&gt;] bdev_writeseg+0x25d/0x270 [logfs]
---[ end trace 0211ad60a57657c4 ]---

Reviewed-by: Joern Engel &lt;joern@logfs.org&gt;
Signed-off-by: Prasad Joshi &lt;prasadjoshi.linux@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>logfs: propagate umode_t</title>
<updated>2012-01-04T03:55:06+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2011-07-26T07:13:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=881764461165d69814194b6fe97d4352bbd0ae82'/>
<id>881764461165d69814194b6fe97d4352bbd0ae82</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>lib/string.c: introduce memchr_inv()</title>
<updated>2011-11-01T00:30:47+00:00</updated>
<author>
<name>Akinobu Mita</name>
<email>akinobu.mita@gmail.com</email>
</author>
<published>2011-11-01T00:08:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=798248206b59acc6e1238c778281419c041891a7'/>
<id>798248206b59acc6e1238c778281419c041891a7</id>
<content type='text'>
memchr_inv() is mainly used to check whether the whole buffer is filled
with just a specified byte.

The function name and prototype are stolen from logfs and the
implementation is from SLUB.

Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.com&gt;
Acked-by: Christoph Lameter &lt;cl@linux-foundation.org&gt;
Acked-by: Pekka Enberg &lt;penberg@kernel.org&gt;
Cc: Matt Mackall &lt;mpm@selenic.com&gt;
Acked-by: Joern Engel &lt;joern@logfs.org&gt;
Cc: Marcin Slusarz &lt;marcin.slusarz@gmail.com&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
memchr_inv() is mainly used to check whether the whole buffer is filled
with just a specified byte.

The function name and prototype are stolen from logfs and the
implementation is from SLUB.

Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.com&gt;
Acked-by: Christoph Lameter &lt;cl@linux-foundation.org&gt;
Acked-by: Pekka Enberg &lt;penberg@kernel.org&gt;
Cc: Matt Mackall &lt;mpm@selenic.com&gt;
Acked-by: Joern Engel &lt;joern@logfs.org&gt;
Cc: Marcin Slusarz &lt;marcin.slusarz@gmail.com&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: push i_mutex and filemap_write_and_wait down into -&gt;fsync() handlers</title>
<updated>2011-07-21T00:47:59+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>josef@redhat.com</email>
</author>
<published>2011-07-17T00:44:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=02c24a82187d5a628c68edfe71ae60dc135cd178'/>
<id>02c24a82187d5a628c68edfe71ae60dc135cd178</id>
<content type='text'>
Btrfs needs to be able to control how filemap_write_and_wait_range() is called
in fsync to make it less of a painful operation, so push down taking i_mutex and
the calling of filemap_write_and_wait() down into the -&gt;fsync() handlers.  Some
file systems can drop taking the i_mutex altogether it seems, like ext3 and
ocfs2.  For correctness sake I just pushed everything down in all cases to make
sure that we keep the current behavior the same for everybody, and then each
individual fs maintainer can make up their mind about what to do from there.
Thanks,

Acked-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Josef Bacik &lt;josef@redhat.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Btrfs needs to be able to control how filemap_write_and_wait_range() is called
in fsync to make it less of a painful operation, so push down taking i_mutex and
the calling of filemap_write_and_wait() down into the -&gt;fsync() handlers.  Some
file systems can drop taking the i_mutex altogether it seems, like ext3 and
ocfs2.  For correctness sake I just pushed everything down in all cases to make
sure that we keep the current behavior the same for everybody, and then each
individual fs maintainer can make up their mind about what to do from there.
Thanks,

Acked-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Josef Bacik &lt;josef@redhat.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: logfs: Fix up MTD=y build.</title>
<updated>2010-11-01T20:34:56+00:00</updated>
<author>
<name>Paul Mundt</name>
<email>lethal@linux-sh.org</email>
</author>
<published>2010-11-01T20:29:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e99d11d19977c74b18411cdb59cdebb788237a6e'/>
<id>e99d11d19977c74b18411cdb59cdebb788237a6e</id>
<content type='text'>
Commit 7d945a3aa760 ("logfs get_sb, part 3") broke the logfs build when
CONFIG_MTD is set due to a mangled logfs_get_sb_mtd() definition.

Signed-off-by: Paul Mundt &lt;lethal@linux-sh.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 7d945a3aa760 ("logfs get_sb, part 3") broke the logfs build when
CONFIG_MTD is set due to a mangled logfs_get_sb_mtd() definition.

Signed-off-by: Paul Mundt &lt;lethal@linux-sh.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>switch logfs to -&gt;mount()</title>
<updated>2010-10-29T08:16:51+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2010-07-26T08:14:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a1da9e8ab687e6496482b7b2aa17d0da31e55b20'/>
<id>a1da9e8ab687e6496482b7b2aa17d0da31e55b20</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>logfs: fix a leak in get_sb</title>
<updated>2010-10-29T08:16:48+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2010-07-26T08:06:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e5a0726a953daf224ae42bcf5edaa64f71b4e8a7'/>
<id>e5a0726a953daf224ae42bcf5edaa64f71b4e8a7</id>
<content type='text'>
a) switch -&gt;put_device() to logfs_super *
b) actually call it on early failures in logfs_get_sb_device()

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
a) switch -&gt;put_device() to logfs_super *
b) actually call it on early failures in logfs_get_sb_device()

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
