linux-toradex.git/fs/jffs2, branch v3.4.73

jffs2: hold erase_completion_lock on exit

2013-01-17T16:50:46+00:00

commit 2cbba75a56ea78e6876b4e2547a882f10b3fe72b upstream.

Users of jffs2_do_reserve_space() expect they still held
erase_completion_lock after call to it. But there is a path
where jffs2_do_reserve_space() leaves erase_completion_lock unlocked.
The patch fixes it.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman

jffs2: Fix lock acquisition order bug in jffs2_write_begin

2012-12-03T19:47:06+00:00

commit 5ffd3412ae5536a4c57469cb8ea31887121dcb2e upstream.

jffs2_write_begin() first acquires the page lock, then f->sem. This
causes an AB-BA deadlock with jffs2_garbage_collect_live(), which first
acquires f->sem, then the page lock:

jffs2_garbage_collect_live
    mutex_lock(&f->sem)                         (A)
    jffs2_garbage_collect_dnode
        jffs2_gc_fetch_page
            read_cache_page_async
                do_read_cache_page
                    lock_page(page)             (B)

jffs2_write_begin
    grab_cache_page_write_begin
        find_lock_page
            lock_page(page)                     (B)
    mutex_lock(&f->sem)                         (A)

We fix this by restructuring jffs2_write_begin() to take f->sem before
the page lock. However, we make sure that f->sem is not held when
calling jffs2_reserve_space(), as this is not permitted by the locking
rules.

The deadlock above was observed multiple times on an SoC with a dual
ARMv7 (Cortex-A9), running the long-term 3.4.11 kernel; it occurred
when using scp to copy files from a host system to the ARM target
system. The fix was heavily tested on the same target system.

Signed-off-by: Thomas Betker 
Acked-by: Joakim Tjernlund 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman

JFFS2: don't fail on bitflips in OOB

2012-10-12T20:39:00+00:00

commit 74d83beaa229aac7d126ac1ed9414658ff1a89d2 upstream.

JFFS2 was designed without thought for OOB bitflips, it seems, but they
can occur and will be reported to JFFS2 via mtd_read_oob()[1]. We don't
want to fail on these transactions, since the data was corrected.

[1] Few drivers report bitflips for OOB-only transactions. With such
    drivers, this patch should have no effect.

Signed-off-by: Brian Norris 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

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

Merge tag 'for-linus-3.4' of git://git.infradead.org/mtd-2.6

2012-03-31T00:31:56+00:00

Pull MTD changes from David Woodhouse:
 - Artem's cleanup of the MTD API continues apace.
 - Fixes and improvements for ST FSMC and SuperH FLCTL NAND, amongst
   others.
 - More work on DiskOnChip G3, new driver for DiskOnChip G4.
 - Clean up debug/warning printks in JFFS2 to use pr_.

Fix up various trivial conflicts, largely due to changes in calling
conventions for things like dmaengine_prep_slave_sg() (new inline
wrapper to hide new parameter, clashing with rewrite of previously last
parameter that used to be an 'append' flag, and is now a bitmap of
'unsigned long flags').

(Also some header file fallout - like so many merges this merge window -
and silly conflicts with sparse fixes)

* tag 'for-linus-3.4' of git://git.infradead.org/mtd-2.6: (120 commits)
  mtd: docg3 add protection against concurrency
  mtd: docg3 refactor cascade floors structure
  mtd: docg3 increase write/erase timeout
  mtd: docg3 fix inbound calculations
  mtd: nand: gpmi: fix function annotations
  mtd: phram: fix section mismatch for phram_setup
  mtd: unify initialization of erase_info->fail_addr
  mtd: support ONFI multi lun NAND
  mtd: sm_ftl: fix typo in major number.
  mtd: add device-tree support to spear_smi
  mtd: spear_smi: Remove default partition information from driver
  mtd: Add device-tree support to fsmc_nand
  mtd: fix section mismatch for doc_probe_device
  mtd: nand/fsmc: Remove sparse warnings and errors
  mtd: nand/fsmc: Add DMA support
  mtd: nand/fsmc: Access the NAND device word by word whenever possible
  mtd: nand/fsmc: Use dev_err to report error scenario
  mtd: nand/fsmc: Use devm routines
  mtd: nand/fsmc: Modify fsmc driver to accept nand timing parameters via platform
  mtd: fsmc_nand: add pm callbacks to support hibernation
  ...

mtd: unify initialization of erase_info->fail_addr

2012-03-27T00:02:24+00:00

Initialization of 'erase_info->fail_addr' to MTD_FAIL_ADDR_UNKNOWN prior
erase operation is duplicated accross several MTD drivers, and also taken
care of by some MTD users as well.

Harmonize it: initialize 'fail_addr' within 'mtd_erase()' interface.

Signed-off-by: Shmulik Ladkani 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse

jffs2: Standardize JFFS_ uses

2012-03-26T23:42:14+00:00

Use pr_ to prefix KBUILD_MODNAME via pr_fmt.

Remove obfuscating defines and use constants in pr_
No need for a do {} while (0) for single statements.

Form of JFFS_ output changes from
"JFFS2 notice: " to "jffs2: notice: "

Added pr_fmt to xattr.c

Signed-off-by: Joe Perches 
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