BMC/Intel-BMC/linux.git/fs/jffs2/gc.c, branch dev

jffs2: Fix lock acquisition order bug in gc path

2012-05-07T19:30:14+00:00

The locking policy is such that the erase_complete_block spinlock is nested within the alloc_sem mutex. This fixes a case in which the acquisition order was erroneously reversed. This issue was caught by the following lockdep splat: ======================================================= [ INFO: possible circular locking dependency detected ] 3.0.5 #1 ------------------------------------------------------- jffs2_gcd_mtd6/299 is trying to acquire lock: (&c->alloc_sem){+.+.+.}, at: [] jffs2_garbage_collect_pass+0x314/0x890 but task is already holding lock: (&(&c->erase_completion_lock)->rlock){+.+...}, at: [] jffs2_garbage_collect_pass+0x308/0x890 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&(&c->erase_completion_lock)->rlock){+.+...}: [] validate_chain+0xe6c/0x10bc [] __lock_acquire+0x54c/0xba4 [] lock_acquire+0xa4/0x114 [] _raw_spin_lock+0x3c/0x4c [] jffs2_garbage_collect_pass+0x4c/0x890 [] jffs2_garbage_collect_thread+0x1b4/0x1cc [] kthread+0x98/0xa0 [] kernel_thread_exit+0x0/0x8 -> #0 (&c->alloc_sem){+.+.+.}: [] print_circular_bug+0x70/0x2c4 [] validate_chain+0x1034/0x10bc [] __lock_acquire+0x54c/0xba4 [] lock_acquire+0xa4/0x114 [] mutex_lock_nested+0x74/0x33c [] jffs2_garbage_collect_pass+0x314/0x890 [] jffs2_garbage_collect_thread+0x1b4/0x1cc [] kthread+0x98/0xa0 [] kernel_thread_exit+0x0/0x8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&c->erase_completion_lock)->rlock); lock(&c->alloc_sem); lock(&(&c->erase_completion_lock)->rlock); lock(&c->alloc_sem); *** DEADLOCK *** 1 lock held by jffs2_gcd_mtd6/299: #0: (&(&c->erase_completion_lock)->rlock){+.+...}, at: [] jffs2_garbage_collect_pass+0x308/0x890 stack backtrace: [] (unwind_backtrace+0x0/0x100) from [] (dump_stack+0x20/0x24) [] (dump_stack+0x20/0x24) from [] (print_circular_bug+0x1c8/0x2c4) [] (print_circular_bug+0x1c8/0x2c4) from [] (validate_chain+0x1034/0x10bc) [] (validate_chain+0x1034/0x10bc) from [] (__lock_acquire+0x54c/0xba4) [] (__lock_acquire+0x54c/0xba4) from [] (lock_acquire+0xa4/0x114) [] (lock_acquire+0xa4/0x114) from [] (mutex_lock_nested+0x74/0x33c) [] (mutex_lock_nested+0x74/0x33c) from [] (jffs2_garbage_collect_pass+0x314/0x890) [] (jffs2_garbage_collect_pass+0x314/0x890) from [] (jffs2_garbage_collect_thread+0x1b4/0x1cc) [] (jffs2_garbage_collect_thread+0x1b4/0x1cc) from [] (kthread+0x98/0xa0) [] (kthread+0x98/0xa0) from [] (kernel_thread_exit+0x0/0x8) This was introduce in '81cfc9f jffs2: Fix serious write stall due to erase'. Cc: stable@kernel.org [2.6.37+] Signed-off-by: Josh Cartwright Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse

jffs2: Use pr_fmt and remove jffs: from formats

2012-03-26T23:40:19+00:00

Use pr_fmt to prefix KBUILD_MODNAME to appropriate logging messages. Remove now unnecessary internal prefixes from formats. Signed-off-by: Joe Perches Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse

jffs2: Convert printks to pr_

2012-03-26T23:39:40+00:00

Use the more current logging style. Coalesce formats, align arguments. Convert uses of embedded function names to %s, __func__. A couple of long line checkpatch errors I don't care about exist. Signed-off-by: Joe Perches Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse

jffs2: Convert most D1/D2 macros to jffs2_dbg

2012-03-26T23:39:24+00:00

D1 and D2 macros are mostly uses to emit debugging messages. Convert the logging uses of D1 & D2 to jffs2_dbg(level, fmt, ...) to be a bit more consistent style with the rest of the kernel. All jffs2_dbg output is now at KERN_DEBUG where some of the previous uses were emitted at various KERN_s. Signed-off-by: Joe Perches Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse

jffs2: Fix serious write stall due to erase

2010-10-25T00:06:22+00:00

Drop the alloc_sem before erasing flash in jffs2_garbage_collect_pass(). Otherwise writes are put on hold until the erase has finised. Signed-off-by: Joakim Tjernlund Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse

jffs2: Update copyright notices

2010-08-08T13:15:22+00:00

Signed-off-by: David Woodhouse

jffs2: Use jffs2_garbage_collect_trigger() to trigger pending erases

2010-05-19T16:10:44+00:00

This is now done in a GC pass; we don't need to trigger kupdated to do it. Signed-off-by: David Woodhouse

jffs2: Erase pending blocks in GC pass, avoid invalid -EIO return

2010-05-19T15:49:37+00:00

jffs2_garbage_collect_pass() would previously return -EAGAIN if it couldn't find anything to garbage collect from, and there were blocks on the erase_pending_list. If the blocks were actually in the process of being erased, though, then they wouldn't be on that list. Check for nr_erasing_blocks being non-zero instead. Fix jffs2_reserve_space() to wait for the in-progress erases to complete, when jffs2_garbage_collect_pass() returns -EAGAIN. And fix jffs2_erase_succeeded() to actually wake up the erase_wait wq that jffs2_reserve_space() is now using. Signed-off-by: David Woodhouse

jffs2: Fix long-standing bug with symlink garbage collection.

2009-12-16T03:27:20+00:00

Ever since jffs2_garbage_collect_metadata() was first half-written in February 2001, it's been broken on architectures where 'char' is signed. When garbage collecting a symlink with target length above 127, the payload length would end up negative, causing interesting and bad things to happen. Cc: stable@kernel.org Signed-off-by: David Woodhouse

[JFFS2] Track parent inode for directories (for NFS export)

2008-05-01T17:47:17+00:00

To support NFS export, we need to know the parent inode of directories. Rather than growing the jffs2_inode_cache structure, share space with the nlink field -- which was always set to 1 for directories anyway. Signed-off-by: David Woodhouse