1. 06 Mar, 2015 1 commit
    • Chen Jie's avatar
      jffs2: fix handling of corrupted summary length · 6192e21a
      Chen Jie authored
      commit 164c24063a3eadee11b46575c5482b2f1417be49 upstream.
      
      sm->offset maybe wrong but magic maybe right, the offset do not have CRC.
      
      Badness at c00c7580 [verbose debug info unavailable]
      NIP: c00c7580 LR: c00c718c CTR: 00000014
      REGS: df07bb40 TRAP: 0700   Not tainted  (2.6.34.13-WR4.3.0.0_standard)
      MSR: 00029000 <EE,ME,CE>  CR: 22084f84  XER: 00000000
      TASK = df84d6e0[908] 'mount' THREAD: df07a000
      GPR00: 00000001 df07bbf0 df84d6e0 00000000 00000001 00000000 df07bb58 00000041
      GPR08: 00000041 c0638860 00000000 00000010 22084f88 100636c8 df814ff8 00000000
      GPR16: df84d6e0 dfa558cc c05adb90 00000048 c0452d30 00000000 000240d0 000040d0
      GPR24: 00000014 c05ae734 c05be2e0 00000000 00000001 00000000 00000000 c05ae730
      NIP [c00c7580] __alloc_pages_nodemask+0x4d0/0x638
      LR [c00c718c] __alloc_pages_nodemask+0xdc/0x638
      Call Trace:
      [df07bbf0] [c00c718c] __alloc_pages_nodemask+0xdc/0x638 (unreliable)
      [df07bc90] [c00c7708] __get_free_pages+0x20/0x48
      [df07bca0] [c00f4a40] __kmalloc+0x15c/0x1ec
      [df07bcd0] [c01fc880] jffs2_scan_medium+0xa58/0x14d0
      [df07bd70] [c01ff38c] jffs2_do_mount_fs+0x1f4/0x6b4
      [df07bdb0] [c020144c] jffs2_do_fill_super+0xa8/0x260
      [df07bdd0] [c020230c] jffs2_fill_super+0x104/0x184
      [df07be00] [c0335814] get_sb_mtd_aux+0x9c/0xec
      [df07be20] [c033596c] get_sb_mtd+0x84/0x1e8
      [df07be60] [c0201ed0] jffs2_get_sb+0x1c/0x2c
      [df07be70] [c0103898] vfs_kern_mount+0x78/0x1e8
      [df07bea0] [c0103a58] do_kern_mount+0x40/0x100
      [df07bec0] [c011fe90] do_mount+0x240/0x890
      [df07bf10] [c0120570] sys_mount+0x90/0xd8
      [df07bf40] [c00110d8] ret_from_syscall+0x0/0x4
      
      === Exception: c01 at 0xff61a34
          LR = 0x100135f0
      Instruction dump:
      38800005 38600000 48010f41 4bfffe1c 4bfc2d15 4bfffe8c 72e90200 4082fc28
      3d20c064 39298860 8809000d 68000001 <0f000000> 2f800000 419efc0c 38000001
      mount: mounting /dev/mtdblock3 on /common failed: Input/output error
      Signed-off-by: default avatarChen Jie <chenjie6@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6192e21a
  2. 14 Nov, 2014 1 commit
  3. 27 Apr, 2014 4 commits
    • Li Zefan's avatar
      jffs2: remove from wait queue after schedule() · cc8ece83
      Li Zefan authored
      commit 3ead9578443b66ddb3d50ed4f53af8a0c0298ec5 upstream.
      
      @wait is a local variable, so if we don't remove it from the wait queue
      list, later wake_up() may end up accessing invalid memory.
      
      This was spotted by eyes.
      Signed-off-by: default avatarLi Zefan <lizefan@huawei.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc8ece83
    • Li Zefan's avatar
      jffs2: avoid soft-lockup in jffs2_reserve_space_gc() · 3a196f46
      Li Zefan authored
      commit 13b546d96207c131eeae15dc7b26c6e7d0f1cad7 upstream.
      
      We triggered soft-lockup under stress test on 2.6.34 kernel.
      
      BUG: soft lockup - CPU#1 stuck for 60009ms! [lockf2.test:14488]
      ...
      [<bf09a4d4>] (jffs2_do_reserve_space+0x420/0x440 [jffs2])
      [<bf09a528>] (jffs2_reserve_space_gc+0x34/0x78 [jffs2])
      [<bf0a1350>] (jffs2_garbage_collect_dnode.isra.3+0x264/0x478 [jffs2])
      [<bf0a2078>] (jffs2_garbage_collect_pass+0x9c0/0xe4c [jffs2])
      [<bf09a670>] (jffs2_reserve_space+0x104/0x2a8 [jffs2])
      [<bf09dc48>] (jffs2_write_inode_range+0x5c/0x4d4 [jffs2])
      [<bf097d8c>] (jffs2_write_end+0x198/0x2c0 [jffs2])
      [<c00e00a4>] (generic_file_buffered_write+0x158/0x200)
      [<c00e14f4>] (__generic_file_aio_write+0x3a4/0x414)
      [<c00e15c0>] (generic_file_aio_write+0x5c/0xbc)
      [<c012334c>] (do_sync_write+0x98/0xd4)
      [<c0123a84>] (vfs_write+0xa8/0x150)
      [<c0123d74>] (sys_write+0x3c/0xc0)]
      
      Fix this by adding a cond_resched() in the while loop.
      
      [akpm@linux-foundation.org: don't initialize `ret']
      Signed-off-by: default avatarLi Zefan <lizefan@huawei.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a196f46
    • Ajesh Kunhipurayil Vijayan's avatar
      jffs2: Fix crash due to truncation of csize · 16668c2b
      Ajesh Kunhipurayil Vijayan authored
      commit 41bf1a24c1001f4d0d41a78e1ac575d2f14789d7 upstream.
      
      mounting JFFS2 partition sometimes crashes with this call trace:
      
      [ 1322.240000] Kernel bug detected[#1]:
      [ 1322.244000] Cpu 2
      [ 1322.244000] $ 0   : 0000000000000000 0000000000000018 000000003ff00070 0000000000000001
      [ 1322.252000] $ 4   : 0000000000000000 c0000000f3980150 0000000000000000 0000000000010000
      [ 1322.260000] $ 8   : ffffffffc09cd5f8 0000000000000001 0000000000000088 c0000000ed300de8
      [ 1322.268000] $12   : e5e19d9c5f613a45 ffffffffc046d464 0000000000000000 66227ba5ea67b74e
      [ 1322.276000] $16   : c0000000f1769c00 c0000000ed1e0200 c0000000f3980150 0000000000000000
      [ 1322.284000] $20   : c0000000f3a80000 00000000fffffffc c0000000ed2cfbd8 c0000000f39818f0
      [ 1322.292000] $24   : 0000000000000004 0000000000000000
      [ 1322.300000] $28   : c0000000ed2c0000 c0000000ed2cfab8 0000000000010000 ffffffffc039c0b0
      [ 1322.308000] Hi    : 000000000000023c
      [ 1322.312000] Lo    : 000000000003f802
      [ 1322.316000] epc   : ffffffffc039a9f8 check_tn_node+0x88/0x3b0
      [ 1322.320000]     Not tainted
      [ 1322.324000] ra    : ffffffffc039c0b0 jffs2_do_read_inode_internal+0x1250/0x1e48
      [ 1322.332000] Status: 5400f8e3    KX SX UX KERNEL EXL IE
      [ 1322.336000] Cause : 00800034
      [ 1322.340000] PrId  : 000c1004 (Netlogic XLP)
      [ 1322.344000] Modules linked in:
      [ 1322.348000] Process jffs2_gcd_mtd7 (pid: 264, threadinfo=c0000000ed2c0000, task=c0000000f0e68dd8, tls=0000000000000000)
      [ 1322.356000] Stack : c0000000f1769e30 c0000000ed010780 c0000000ed010780 c0000000ed300000
              c0000000f1769c00 c0000000f3980150 c0000000f3a80000 00000000fffffffc
              c0000000ed2cfbd8 ffffffffc039c0b0 ffffffffc09c6340 0000000000001000
              0000000000000dec ffffffffc016c9d8 c0000000f39805a0 c0000000f3980180
              0000008600000000 0000000000000000 0000000000000000 0000000000000000
              0001000000000dec c0000000f1769d98 c0000000ed2cfb18 0000000000010000
              0000000000010000 0000000000000044 c0000000f3a80000 c0000000f1769c00
              c0000000f3d207a8 c0000000f1769d98 c0000000f1769de0 ffffffffc076f9c0
              0000000000000009 0000000000000000 0000000000000000 ffffffffc039cf90
              0000000000000017 ffffffffc013fbdc 0000000000000001 000000010003e61c
              ...
      [ 1322.424000] Call Trace:
      [ 1322.428000] [<ffffffffc039a9f8>] check_tn_node+0x88/0x3b0
      [ 1322.432000] [<ffffffffc039c0b0>] jffs2_do_read_inode_internal+0x1250/0x1e48
      [ 1322.440000] [<ffffffffc039cf90>] jffs2_do_crccheck_inode+0x70/0xd0
      [ 1322.448000] [<ffffffffc03a1b80>] jffs2_garbage_collect_pass+0x160/0x870
      [ 1322.452000] [<ffffffffc03a392c>] jffs2_garbage_collect_thread+0xdc/0x1f0
      [ 1322.460000] [<ffffffffc01541c8>] kthread+0xb8/0xc0
      [ 1322.464000] [<ffffffffc0106d18>] kernel_thread_helper+0x10/0x18
      [ 1322.472000]
      [ 1322.472000]
      Code: 67bd0050  94a4002c  2c830001 <00038036> de050218  2403fffc  0080a82d  00431824  24630044
      [ 1322.480000] ---[ end trace b052bb90e97dfbf5 ]---
      
      The variable csize in structure jffs2_tmp_dnode_info is of type uint16_t, but it
      is used to hold the compressed data length(csize) which is declared as uint32_t.
      So, when the value of csize exceeds 16bits, it gets truncated when assigned to
      tn->csize. This is causing a kernel BUG.
      Changing the definition of csize in jffs2_tmp_dnode_info to uint32_t fixes the issue.
      Signed-off-by: default avatarAjesh Kunhipurayil Vijayan <ajesh@broadcom.com>
      Signed-off-by: default avatarKamlakant Patel <kamlakant.patel@broadcom.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16668c2b
    • Kamlakant Patel's avatar
      jffs2: Fix segmentation fault found in stress test · 5734144c
      Kamlakant Patel authored
      commit 3367da5610c50e6b83f86d366d72b41b350b06a2 upstream.
      
      Creating a large file on a JFFS2 partition sometimes crashes with this call
      trace:
      
      [  306.476000] CPU 13 Unable to handle kernel paging request at virtual address c0000000dfff8002, epc == ffffffffc03a80a8, ra == ffffffffc03a8044
      [  306.488000] Oops[#1]:
      [  306.488000] Cpu 13
      [  306.492000] $ 0   : 0000000000000000 0000000000000000 0000000000008008 0000000000008007
      [  306.500000] $ 4   : c0000000dfff8002 000000000000009f c0000000e0007cde c0000000ee95fa58
      [  306.508000] $ 8   : 0000000000000001 0000000000008008 0000000000010000 ffffffffffff8002
      [  306.516000] $12   : 0000000000007fa9 000000000000ff0e 000000000000ff0f 80e55930aebb92bb
      [  306.524000] $16   : c0000000e0000000 c0000000ee95fa5c c0000000efc80000 ffffffffc09edd70
      [  306.532000] $20   : ffffffffc2b60000 c0000000ee95fa58 0000000000000000 c0000000efc80000
      [  306.540000] $24   : 0000000000000000 0000000000000004
      [  306.548000] $28   : c0000000ee950000 c0000000ee95f738 0000000000000000 ffffffffc03a8044
      [  306.556000] Hi    : 00000000000574a5
      [  306.560000] Lo    : 6193b7a7e903d8c9
      [  306.564000] epc   : ffffffffc03a80a8 jffs2_rtime_compress+0x98/0x198
      [  306.568000]     Tainted: G        W
      [  306.572000] ra    : ffffffffc03a8044 jffs2_rtime_compress+0x34/0x198
      [  306.580000] Status: 5000f8e3    KX SX UX KERNEL EXL IE
      [  306.584000] Cause : 00800008
      [  306.588000] BadVA : c0000000dfff8002
      [  306.592000] PrId  : 000c1100 (Netlogic XLP)
      [  306.596000] Modules linked in:
      [  306.596000] Process dd (pid: 170, threadinfo=c0000000ee950000, task=c0000000ee6e0858, tls=0000000000c47490)
      [  306.608000] Stack : 7c547f377ddc7ee4 7ffc7f967f5d7fae 7f617f507fc37ff4 7e7d7f817f487f5f
              7d8e7fec7ee87eb3 7e977ff27eec7f9e 7d677ec67f917f67 7f3d7e457f017ed7
              7fd37f517f867eb2 7fed7fd17ca57e1d 7e5f7fe87f257f77 7fd77f0d7ede7fdb
              7fba7fef7e197f99 7fde7fe07ee37eb5 7f5c7f8c7fc67f65 7f457fb87f847e93
              7f737f3e7d137cd9 7f8e7e9c7fc47d25 7dbb7fac7fb67e52 7ff17f627da97f64
              7f6b7df77ffa7ec5 80057ef17f357fb3 7f767fa27dfc7fd5 7fe37e8e7fd07e53
              7e227fcf7efb7fa1 7f547e787fa87fcc 7fcb7fc57f5a7ffb 7fc07f6c7ea97e80
              7e2d7ed17e587ee0 7fb17f9d7feb7f31 7f607e797e887faa 7f757fdd7c607ff3
              7e877e657ef37fbd 7ec17fd67fe67ff7 7ff67f797ff87dc4 7eef7f3a7c337fa6
              7fe57fc97ed87f4b 7ebe7f097f0b8003 7fe97e2a7d997cba 7f587f987f3c7fa9
              ...
      [  306.676000] Call Trace:
      [  306.680000] [<ffffffffc03a80a8>] jffs2_rtime_compress+0x98/0x198
      [  306.684000] [<ffffffffc0394f10>] jffs2_selected_compress+0x110/0x230
      [  306.692000] [<ffffffffc039508c>] jffs2_compress+0x5c/0x388
      [  306.696000] [<ffffffffc039dc58>] jffs2_write_inode_range+0xd8/0x388
      [  306.704000] [<ffffffffc03971bc>] jffs2_write_end+0x16c/0x2d0
      [  306.708000] [<ffffffffc01d3d90>] generic_file_buffered_write+0xf8/0x2b8
      [  306.716000] [<ffffffffc01d4e7c>] __generic_file_aio_write+0x1ac/0x350
      [  306.720000] [<ffffffffc01d50a0>] generic_file_aio_write+0x80/0x168
      [  306.728000] [<ffffffffc021f7dc>] do_sync_write+0x94/0xf8
      [  306.732000] [<ffffffffc021ff6c>] vfs_write+0xa4/0x1a0
      [  306.736000] [<ffffffffc02202e8>] SyS_write+0x50/0x90
      [  306.744000] [<ffffffffc0116cc0>] handle_sys+0x180/0x1a0
      [  306.748000]
      [  306.748000]
      Code: 020b202d  0205282d  90a50000 <90840000> 14a40038  00000000  0060602d  0000282d  016c5823
      [  306.760000] ---[ end trace 79dd088435be02d0 ]---
      Segmentation fault
      
      This crash is caused because the 'positions' is declared as an array of signed
      short. The value of position is in the range 0..65535, and will be converted
      to a negative number when the position is greater than 32767 and causes a
      corruption and crash. Changing the definition to 'unsigned short' fixes this
      issue
      Signed-off-by: default avatarJayachandran C <jchandra@broadcom.com>
      Signed-off-by: default avatarKamlakant Patel <kamlakant.patel@broadcom.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5734144c
  4. 04 Mar, 2013 1 commit
    • Eric W. Biederman's avatar
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman authored
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      autofs4.
      
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarKees Cook <keescook@google.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  5. 23 Feb, 2013 1 commit
  6. 21 Jan, 2013 1 commit
  7. 18 Nov, 2012 1 commit
  8. 09 Nov, 2012 1 commit
    • Thomas Betker's avatar
      jffs2: Fix lock acquisition order bug in jffs2_write_begin · 5ffd3412
      Thomas Betker authored
      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.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Betker <thomas.betker@rohde-schwarz.com>
      Acked-by: default avatarJoakim Tjernlund <Joakim.Tjernlund@transmode.se>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      5ffd3412
  9. 09 Oct, 2012 1 commit
  10. 03 Oct, 2012 1 commit
  11. 29 Sep, 2012 2 commits
  12. 21 Sep, 2012 1 commit
  13. 18 Sep, 2012 1 commit
    • Eric W. Biederman's avatar
      userns: Pass a userns parameter into posix_acl_to_xattr and posix_acl_from_xattr · 5f3a4a28
      Eric W. Biederman authored
       - Pass the user namespace the uid and gid values in the xattr are stored
         in into posix_acl_from_xattr.
      
       - Pass the user namespace kuid and kgid values should be converted into
         when storing uid and gid values in an xattr in posix_acl_to_xattr.
      
      - Modify all callers of posix_acl_from_xattr and posix_acl_to_xattr to
        pass in &init_user_ns.
      
      In the short term this change is not strictly needed but it makes the
      code clearer.  In the longer term this change is necessary to be able to
      mount filesystems outside of the initial user namespace that natively
      store posix acls in the linux xattr format.
      
      Cc: Theodore Tso <tytso@mit.edu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      5f3a4a28
  14. 22 Jul, 2012 1 commit
  15. 14 Jul, 2012 2 commits
  16. 31 May, 2012 4 commits
  17. 14 May, 2012 9 commits
  18. 07 May, 2012 1 commit
    • Josh Cartwright's avatar
      jffs2: Fix lock acquisition order bug in gc path · 226bb7df
      Josh Cartwright authored
      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: [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
      
         but task is already holding lock:
          (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] 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){+.+...}:
                [<c008bec4>] validate_chain+0xe6c/0x10bc
                [<c008c660>] __lock_acquire+0x54c/0xba4
                [<c008d240>] lock_acquire+0xa4/0x114
                [<c046780c>] _raw_spin_lock+0x3c/0x4c
                [<c01f744c>] jffs2_garbage_collect_pass+0x4c/0x890
                [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
                [<c0071a68>] kthread+0x98/0xa0
                [<c000f264>] kernel_thread_exit+0x0/0x8
      
         -> #0 (&c->alloc_sem){+.+.+.}:
                [<c008ad2c>] print_circular_bug+0x70/0x2c4
                [<c008c08c>] validate_chain+0x1034/0x10bc
                [<c008c660>] __lock_acquire+0x54c/0xba4
                [<c008d240>] lock_acquire+0xa4/0x114
                [<c0466628>] mutex_lock_nested+0x74/0x33c
                [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
                [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
                [<c0071a68>] kthread+0x98/0xa0
                [<c000f264>] 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: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890
      
         stack backtrace:
         [<c00155dc>] (unwind_backtrace+0x0/0x100) from [<c0463dc0>] (dump_stack+0x20/0x24)
         [<c0463dc0>] (dump_stack+0x20/0x24) from [<c008ae84>] (print_circular_bug+0x1c8/0x2c4)
         [<c008ae84>] (print_circular_bug+0x1c8/0x2c4) from [<c008c08c>] (validate_chain+0x1034/0x10bc)
         [<c008c08c>] (validate_chain+0x1034/0x10bc) from [<c008c660>] (__lock_acquire+0x54c/0xba4)
         [<c008c660>] (__lock_acquire+0x54c/0xba4) from [<c008d240>] (lock_acquire+0xa4/0x114)
         [<c008d240>] (lock_acquire+0xa4/0x114) from [<c0466628>] (mutex_lock_nested+0x74/0x33c)
         [<c0466628>] (mutex_lock_nested+0x74/0x33c) from [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890)
         [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) from [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc)
         [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) from [<c0071a68>] (kthread+0x98/0xa0)
         [<c0071a68>] (kthread+0x98/0xa0) from [<c000f264>] (kernel_thread_exit+0x0/0x8)
      
      This was introduce in '81cfc9f1 jffs2: Fix serious write stall due to erase'.
      
      Cc: stable@kernel.org [2.6.37+]
      Signed-off-by: default avatarJosh Cartwright <joshc@linux.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      226bb7df
  19. 06 May, 2012 1 commit
  20. 27 Mar, 2012 1 commit
  21. 26 Mar, 2012 4 commits