1. 04 2月, 2015 3 次提交
  2. 13 1月, 2015 1 次提交
  3. 10 1月, 2015 1 次提交
  4. 09 1月, 2015 5 次提交
  5. 08 1月, 2015 1 次提交
  6. 06 1月, 2015 8 次提交
  7. 03 1月, 2015 7 次提交
  8. 27 12月, 2014 1 次提交
  9. 23 12月, 2014 1 次提交
  10. 22 12月, 2014 2 次提交
  11. 19 12月, 2014 10 次提交
    • J
      udf: Check path length when reading symlink · 0e5cc9a4
      Jan Kara 提交于
      Symlink reading code does not check whether the resulting path fits into
      the page provided by the generic code. This isn't as easy as just
      checking the symlink size because of various encoding conversions we
      perform on path. So we have to check whether there is still enough space
      in the buffer on the fly.
      
      CC: stable@vger.kernel.org
      Reported-by: NCarl Henrik Lunde <chlunde@ping.uio.no>
      Signed-off-by: NJan Kara <jack@suse.cz>
      0e5cc9a4
    • J
      udf: Verify symlink size before loading it · a1d47b26
      Jan Kara 提交于
      UDF specification allows arbitrarily large symlinks. However we support
      only symlinks at most one block large. Check the length of the symlink
      so that we don't access memory beyond end of the symlink block.
      
      CC: stable@vger.kernel.org
      Reported-by: NCarl Henrik Lunde <chlunde@gmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      a1d47b26
    • J
      udf: Verify i_size when loading inode · e159332b
      Jan Kara 提交于
      Verify that inode size is sane when loading inode with data stored in
      ICB. Otherwise we may get confused later when working with the inode and
      inode size is too big.
      
      CC: stable@vger.kernel.org
      Reported-by: NCarl Henrik Lunde <chlunde@ping.uio.no>
      Signed-off-by: NJan Kara <jack@suse.cz>
      e159332b
    • J
      isofs: Fix unchecked printing of ER records · 4e202462
      Jan Kara 提交于
      We didn't check length of rock ridge ER records before printing them.
      Thus corrupted isofs image can cause us to access and print some memory
      behind the buffer with obvious consequences.
      Reported-and-tested-by: NCarl Henrik Lunde <chlunde@ping.uio.no>
      CC: stable@vger.kernel.org
      Signed-off-by: NJan Kara <jack@suse.cz>
      4e202462
    • J
      ocfs2: fix journal commit deadlock · 136f49b9
      Junxiao Bi 提交于
      For buffer write, page lock will be got in write_begin and released in
      write_end, in ocfs2_write_end_nolock(), before it unlock the page in
      ocfs2_free_write_ctxt(), it calls ocfs2_run_deallocs(), this will ask
      for the read lock of journal->j_trans_barrier.  Holding page lock and
      ask for journal->j_trans_barrier breaks the locking order.
      
      This will cause a deadlock with journal commit threads, ocfs2cmt will
      get write lock of journal->j_trans_barrier first, then it wakes up
      kjournald2 to do the commit work, at last it waits until done.  To
      commit journal, kjournald2 needs flushing data first, it needs get the
      cache page lock.
      
      Since some ocfs2 cluster locks are holding by write process, this
      deadlock may hung the whole cluster.
      
      unlock pages before ocfs2_run_deallocs() can fix the locking order, also
      put unlock before ocfs2_commit_trans() to make page lock is unlocked
      before j_trans_barrier to preserve unlocking order.
      Signed-off-by: NJunxiao Bi <junxiao.bi@oracle.com>
      Reviewed-by: NWengang Wang <wen.gang.wang@oracle.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: NMark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      136f49b9
    • J
      ocfs2/dlm: fix race between dispatched_work and dlm_lockres_grab_inflight_worker · 1e589581
      Joseph Qi 提交于
      Commit ac4fef4d ("ocfs2/dlm: do not purge lockres that is queued for
      assert master") may have the following possible race case:
      
        dlm_dispatch_assert_master       dlm_wq
        ========================================================================
        queue_work(dlm->quedlm_worker,
            &dlm->dispatched_work);
                                       dispatch work,
                                       dlm_lockres_drop_inflight_worker
                                       *BUG_ON(res->inflight_assert_workers == 0)*
        dlm_lockres_grab_inflight_worker
        inflight_assert_workers++
      
      So ensure inflight_assert_workers to be increased first.
      Signed-off-by: NJoseph Qi <joseph.qi@huawei.com>
      Signed-off-by: NXue jiufei <xuejiufei@huawei.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Reviewed-by: NMark Fasheh <mfasheh@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1e589581
    • J
      ocfs2: reflink: fix slow unlink for refcounted file · f62f12b3
      Junxiao Bi 提交于
      When running ocfs2 test suite multiple nodes reflink stress test, for a
      4 nodes cluster, every unlink() for refcounted file needs about 700s.
      
      The slow unlink is caused by the contention of refcount tree lock since
      all nodes are unlink files using the same refcount tree.  When the
      unlinking file have many extents(over 1600 in our test), most of the
      extents has refcounted flag set.  In ocfs2_commit_truncate(), it will
      execute the following call trace for every extents.  This means it needs
      get and released refcount tree lock about 1600 times.  And when several
      nodes are do this at the same time, the performance will be very low.
      
        ocfs2_remove_btree_range()
        --  ocfs2_lock_refcount_tree()
        ----  ocfs2_refcount_lock()
        ------  __ocfs2_cluster_lock()
      
      ocfs2_refcount_lock() is costly, move it to ocfs2_commit_truncate() to
      do lock/unlock once can improve a lot performance.
      Signed-off-by: NJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Wengang <wen.gang.wang@oracle.com>
      Reviewed-by: NMark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f62f12b3
    • P
      fs/proc/meminfo.c: include cma info in proc/meminfo · 47f8f929
      Pintu Kumar 提交于
      This patch include CMA info (CMATotal, CMAFree) in /proc/meminfo.
      Currently, in a CMA enabled system, if somebody wants to know the total
      CMA size declared, there is no way to tell, other than the dmesg or
      /var/log/messages logs.
      
      With this patch we are showing the CMA info as part of meminfo, so that it
      can be determined at any point of time.  This will be populated only when
      CMA is enabled.
      
      Below is the sample output from a ARM based device with RAM:512MB and CMA:16MB.
      
        MemTotal:         471172 kB
        MemFree:          111712 kB
        MemAvailable:     271172 kB
        .
        .
        .
        CmaTotal:          16384 kB
        CmaFree:            6144 kB
      
      This patch also fix below checkpatch errors that were found during these changes.
      
        ERROR: space required after that ',' (ctx:ExV)
        199: FILE: fs/proc/meminfo.c:199:
        +       ,atomic_long_read(&num_poisoned_pages) << (PAGE_SHIFT - 10)
                ^
      
        ERROR: space required after that ',' (ctx:ExV)
        202: FILE: fs/proc/meminfo.c:202:
        +       ,K(global_page_state(NR_ANON_TRANSPARENT_HUGEPAGES) *
                ^
      
        ERROR: space required after that ',' (ctx:ExV)
        206: FILE: fs/proc/meminfo.c:206:
        +       ,K(totalcma_pages)
                ^
      
        total: 3 errors, 0 warnings, 2 checks, 236 lines checked
      Signed-off-by: NPintu Kumar <pintu.k@samsung.com>
      Signed-off-by: NVishnu Pratap Singh <vishnu.ps@samsung.com>
      Acked-by: NMichal Nazarewicz <mina86@mina86.com>
      Cc: Rafael Aquini <aquini@redhat.com>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      47f8f929
    • S
      hfsplus: fix longname handling · 89ac9b4d
      Sougata Santra 提交于
      Longname is not correctly handled by hfsplus driver.  If an attempt to
      create a longname(>255) file/directory is made, it succeeds by creating a
      file/directory with HFSPLUS_MAX_STRLEN and incorrect catalog key.  Thus
      leaving the volume in an inconsistent state.  This patch fixes this issue.
      
      Although lookup is always called first to create a negative entry, so just
      doing a check in lookup would probably fix this issue.  I choose to
      propagate error to other iops as well.
      
      Please NOTE: I have factored out hfsplus_cat_build_key_with_cnid from
      hfsplus_cat_build_key, to avoid unncessary branching.
      
      Thanks a lot.
      
        TEST:
        ------
        dir="TEST_DIR"
        cdir=`pwd`
        name255="_123456789_123456789_123456789_123456789_123456789_123456789\
        _123456789_123456789_123456789_123456789_123456789_123456789_123456789\
        _123456789_123456789_123456789_123456789_123456789_123456789_123456789\
        _123456789_123456789_123456789_123456789_123456789_1234"
        name256="${name255}5"
      
        mkdir $dir
        cd $dir
        touch $name255
        rm -f $name255
        touch $name256
        ls -la
        cd $cdir
        rm -rf $dir
      
        RESULT:
        -------
        [sougata@ultrabook tmp]$ cdir=`pwd`
        [sougata@ultrabook tmp]$
        name255="_123456789_123456789_123456789_123456789_123456789_123456789\
         > _123456789_123456789_123456789_123456789_123456789_123456789_123456789\
         > _123456789_123456789_123456789_123456789_123456789_123456789_123456789\
         > _123456789_123456789_123456789_123456789_123456789_1234"
        [sougata@ultrabook tmp]$ name256="${name255}5"
        [sougata@ultrabook tmp]$
        [sougata@ultrabook tmp]$ mkdir $dir
        [sougata@ultrabook tmp]$ cd $dir
        [sougata@ultrabook TEST_DIR]$ touch $name255
        [sougata@ultrabook TEST_DIR]$ rm -f $name255
        [sougata@ultrabook TEST_DIR]$ touch $name256
        [sougata@ultrabook TEST_DIR]$ ls -la
        ls: cannot access
        _123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_1234:
        No such file or directory
        total 0
        drwxrwxr-x 1 sougata sougata 3 Feb 20 19:56 .
        drwxrwxrwx 1 root    root    6 Feb 20 19:56 ..
        -????????? ? ?       ?       ?            ?
        _123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_1234
        [sougata@ultrabook TEST_DIR]$ cd $cdir
        [sougata@ultrabook tmp]$ rm -rf $dir
        rm: cannot remove `TEST_DIR': Directory not empty
      
      -ENAMETOOLONG returned from hfsplus_asc2uni was not propaged to iops.
      This allowed hfsplus to create files/directories with HFSPLUS_MAX_STRLEN
      and incorrect keys, leaving the FS in an inconsistent state.  This patch
      fixes this issue.
      Signed-off-by: NSougata Santra <sougata@tuxera.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      89ac9b4d
    • E
      mnt: Fix a memory stomp in umount · c297abfd
      Eric W. Biederman 提交于
      While reviewing the code of umount_tree I realized that when we append
      to a preexisting unmounted list we do not change pprev of the former
      first item in the list.
      
      Which means later in namespace_unlock hlist_del_init(&mnt->mnt_hash) on
      the former first item of the list will stomp unmounted.first leaving
      it set to some random mount point which we are likely to free soon.
      
      This isn't likely to hit, but if it does I don't know how anyone could
      track it down.
      
      [ This happened because we don't have all the same operations for
        hlist's as we do for normal doubly-linked lists. In particular,
        list_splice() is easy on our standard doubly-linked lists, while
        hlist_splice() doesn't exist and needs both start/end entries of the
        hlist.  And commit 38129a13 incorrectly open-coded that missing
        hlist_splice().
      
        We should think about making these kinds of "mindless" conversions
        easier to get right by adding the missing hlist helpers   - Linus ]
      
      Fixes: 38129a13 switch mnt_hash to hlist
      Cc: stable@vger.kernel.org
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c297abfd