Skip to content

L
linux
Switch branch/tag
  1. 18 May, 2016 2 commits
    • Dave Chinner's avatar
      xfs: concurrent readdir hangs on data buffer locks · 9f541801
      Dave Chinner authored 
      There's a three-process deadlock involving shared/exclusive barriers
and inverted lock orders in the directory readdir implementation.
It's a pre-existing problem with lock ordering, exposed by the
VFS parallelisation code.

process 1               process 2               process 3
---------               ---------               ---------
readdir
iolock(shared)
  get_leaf_dents
    iterate entries
       ilock(shared)
       map, lock and read buffer
       iunlock(shared)
       process entries in buffer
       .....
                                                readdir
                                                iolock(shared)
                                                  get_leaf_dents
                                                    iterate entries
                                                      ilock(shared)
                                                      map, lock buffer
                                                      <blocks>
                        finish ->iterate_shared
                        file_accessed()
                          ->update_time
                            start transaction
                            ilock(excl)
                            <blocks>
        .....
        finishes processing buffer
        get next buffer
          ilock(shared)
          <blocks>

And that's the deadlock.

Fix this by dropping the current buffer lock in process 1 before
trying to map the next buffer. This means we keep the lock order of
ilock -> buffer lock intact and hence will allow process 3 to make
progress and drop it's ilock(shared) once it is done.
Reported-by: default avatarXiong Zhou <xzhou@redhat.com>
Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      9f541801
    • Al Viro's avatar
      Revert "btrfs: switch to ->iterate_shared()" · fe742fd4
      Al Viro authored 
      This reverts commit 972b241f.
Quoth Chris:
	didn't take the delayed inode stuff into account
	it got an rbtree of items and it pulls things out
	so in shared mode, its hugely racey
	sorry, lets revert and fix it for real inside of btrfs
Signed-off-by: default avatarChris Mason <clm@fb.com>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      fe742fd4
  3. 13 May, 2016 3 commits
  5. 12 May, 2016 4 commits
  7. 10 May, 2016 4 commits
  9. 09 May, 2016 14 commits
  11. 08 May, 2016 1 commit
    • Al Viro's avatar
      get_rock_ridge_filename(): handle malformed NM entries · 99d82582
      Al Viro authored 
      Payloads of NM entries are not supposed to contain NUL.  When we run
into such, only the part prior to the first NUL goes into the
concatenation (i.e. the directory entry name being encoded by a bunch
of NM entries).  We do stop when the amount collected so far + the
claimed amount in the current NM entry exceed 254.  So far, so good,
but what we return as the total length is the sum of *claimed*
sizes, not the actual amount collected.  And that can grow pretty
large - not unlimited, since you'd need to put CE entries in
between to be able to get more than the maximum that could be
contained in one isofs directory entry / continuation chunk and
we are stop once we'd encountered 32 CEs, but you can get about 8Kb
easily.  And that's what will be passed to readdir callback as the
name length.  8Kb __copy_to_user() from a buffer allocated by
__get_free_page()

Cc: stable@vger.kernel.org # 0.98pl6+ (yes, really)
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      99d82582
  13. 04 May, 2016 1 commit
    • Al Viro's avatar
      ecryptfs: fix handling of directory opening · 6a480a78
      Al Viro authored 
      First of all, trying to open them r/w is idiocy; it's guaranteed to fail.
Moreover, assigning ->f_pos and assuming that everything will work is
blatantly broken - try that with e.g. tmpfs as underlying layer and watch
the fireworks.  There may be a non-trivial amount of state associated with
current IO position, well beyond the numeric offset.  Using the single
struct file associated with underlying inode is really not a good idea;
we ought to open one for each ecryptfs directory struct file.

Additionally, file_operations both for directories and non-directories are
full of pointless methods; non-directories should *not* have ->iterate(),
directories should not have ->flush(), ->fasync() and ->splice_read().
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      6a480a78
  15. 02 May, 2016 11 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7