1. 30 May, 2012 13 commits
    • Liu Bo's avatar
      Btrfs: fix wrong error returned by adding a device · f8c5d0b4
      Liu Bo authored
      Reproduce:
      $ mkfs.btrfs /dev/sdb7
      $ mount /dev/sdb7 /mnt/btrfs -o ro
      $ btrfs dev add /dev/sdb8 /mnt/btrfs
      ERROR: error adding the device '/dev/sdb8' - Invalid argument
      
      Since we mount with readonly options, and /dev/sdb7 is not a seeding one,
      a readonly notification is preferred.
      Signed-off-by: default avatarLiu Bo <liubo2009@cn.fujitsu.com>
      Reviewed-by: default avatarJosef Bacik <josef@redhat.com>
      f8c5d0b4
    • Josef Bacik's avatar
      Btrfs: finish ordered extents in their own thread · 5fd02043
      Josef Bacik authored
      We noticed that the ordered extent completion doesn't really rely on having
      a page and that it could be done independantly of ending the writeback on a
      page.  This patch makes us not do the threaded endio stuff for normal
      buffered writes and direct writes so we can end page writeback as soon as
      possible (in irq context) and only start threads to do the ordered work when
      it is actually done.  Compression needs to be reworked some to take
      advantage of this as well, but atm it has to do a find_get_page in its endio
      handler so it must be done in its own thread.  This makes direct writes
      quite a bit faster.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      5fd02043
    • Josef Bacik's avatar
      Btrfs: do not check delalloc when updating disk_i_size · 4e899152
      Josef Bacik authored
      We are checking delalloc to see if it is ok to update the i_size.  There are
      2 cases it stops us from updating
      
      1) If there is delalloc between our current disk_i_size and this ordered
      extent
      
      2) If there is delalloc between our current ordered extent and the next
      ordered extent
      
      These tests are racy however since we can set delalloc for these ranges at
      any time.  Also for the first case if we notice there is delalloc between
      disk_i_size and our ordered extent we will not update disk_i_size and assume
      that when that delalloc bit gets written out it will update everything
      properly.  However if we crash before that we will have file extents outside
      of our i_size, which is not good, so this test is dangerous as well as racy.
      Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      4e899152
    • Jim Meyering's avatar
      Btrfs: avoid buffer overrun in mount option handling · f60d16a8
      Jim Meyering authored
      There is an off-by-one error: allocating room for a maximal result
      string but without room for a trailing NUL.  That, can lead to
      returning a transformed string that is not NUL-terminated, and
      then to a caller reading beyond end of the malloc'd buffer.
      
      Rewrite to s/kzalloc/kmalloc/, remove unwarranted use of strncpy
      (the result is guaranteed to fit), remove dead strlen at end, and
      change a few variable names and comments.
      Reviewed-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarJim Meyering <meyering@redhat.com>
      f60d16a8
    • Jim Meyering's avatar
      Btrfs: NUL-terminate path buffer in DEV_INFO ioctl result · a27202fb
      Jim Meyering authored
      A device with name of length BTRFS_DEVICE_PATH_NAME_MAX or longer
      would not be NUL-terminated in the DEV_INFO ioctl result buffer.
      Signed-off-by: default avatarJim Meyering <meyering@redhat.com>
      a27202fb
    • Jim Meyering's avatar
      Btrfs: avoid buffer overrun in btrfs_printk · f07c9a79
      Jim Meyering authored
      The buffer read-overrun would be triggered by a printk format
      starting with <N>, where N is a single digit.  NUL-terminate
      after strncpy.  Use memcpy, not strncpy, since we know the
      string we're copying fits in the destination buffer and
      contains no NUL byte.
      Signed-off-by: default avatarJim Meyering <meyering@redhat.com>
      f07c9a79
    • Daniel J Blueman's avatar
      Fix minor type issues · 2eec6c81
      Daniel J Blueman authored
      Address some minor type issues identified by sparse checker.
      Signed-off-by: default avatarDaniel J Blueman <daniel@quora.org>
      2eec6c81
    • Sergei Trofimovich's avatar
      btrfs: allow changing 'thread_pool' size at remount time · 0d2450ab
      Sergei Trofimovich authored
      Changing 'mount -oremount,thread_pool=2 /' didn't make any effect:
      
      maximum amount of worker threads is specified in 2 places:
      - in 'strict btrfs_fs_info::thread_pool_size'
      - in each worker struct: 'struct btrfs_workers::max_workers'
      
      'mount -oremount' updated only 'btrfs_fs_info::thread_pool_size'.
      
      Fix it by pushing new maximum value to all created worker structures
      as well.
      
      Cc: Josef Bacik <josef@redhat.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Reviewed-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      0d2450ab
    • Josef Bacik's avatar
      Btrfs: do not do filemap_write_and_wait_range in fsync · 0885ef5b
      Josef Bacik authored
      We already do the btrfs_wait_ordered_range which will do this for us, so
      just remove this call so we don't call it twice.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      0885ef5b
    • Josef Bacik's avatar
      Btrfs: remove useless waiting and extra filemap work · 551ebb2d
      Josef Bacik authored
      In btrfs_wait_ordered_range we have been calling filemap_fdata_write() twice
      because compression does strange things and then waiting.  Then we look up
      ordered extents and if we find any we will always schedule_timeout(); once
      and then loop back around and do it all again.  We will even check to see if
      there is delalloc pages on this range and loop again.  So this patch gets
      rid of the multipe fdata_write() calls and just does
      filemap_write_and_wait().  In the case of compression we will still find the
      ordered extents and start those individually if we need to so that is ok,
      but in the normal buffered case we avoid all this weird overhead.
      
      Then in the case of the schedule_timeout(1), we don't need it.  All callers
      either 1) don't care, they just want to make sure what they just wrote maeks
      it to disk or 2) are doing the lock()->lookup ordered->unlock->flush thing
      in which case it will lock and check for ordered extents _anyway_ so get
      back to them as quickly as possible.  The delaloc check is simply not
      needed, this only catches the case where we write to the file again since
      doing the filemap_write_and_wait() and if the caller truly cares about that
      it will take care of everything itself.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      551ebb2d
    • Josef Bacik's avatar
      Btrfs: fix compile warnings in extent_io.c · d7dbe9e7
      Josef Bacik authored
      These warnings are bogus since we will always have at least one page in an
      eb, but to make the compiler happy just set ret = 0 in these two cases.
      Thanks,
      Btrfs: fix compile warnings in extent_io.c
      
      These warnings are bogus since we will always have at least one page in an
      eb, but to make the compiler happy just set ret = 0 in these two cases.
      Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      d7dbe9e7
    • Josef Bacik's avatar
      Btrfs: cache no acl on new inodes · 30f8fe3e
      Josef Bacik authored
      When running compilebench I noticed we were spending some time looking up
      acls on new inodes, which shouldn't be happening since there were no acls.
      This is because when we init acls on the inode after creating them we don't
      cache the fact there are no acls if there aren't any.  Doing this adds a
      little bit of a bump to my compilebench runs.  Thanks,
      Btrfs: cache no acl on new inodes
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      30f8fe3e
    • Josef Bacik's avatar
      Btrfs: use i_version instead of our own sequence · 0c4d2d95
      Josef Bacik authored
      We've been keeping around the inode sequence number in hopes that somebody
      would use it, but nobody uses it and people actually use i_version which
      serves the same purpose, so use i_version where we used the incore inode's
      sequence number and that way the sequence is updated properly across the
      board, and not just in file write.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      0c4d2d95
  2. 11 May, 2012 7 commits
  3. 06 May, 2012 5 commits
  4. 05 May, 2012 10 commits
  5. 04 May, 2012 5 commits
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f756beba
      Linus Torvalds authored
      Pull timer fix from Thomas Gleixner.
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        rtc: Fix possible null pointer dereference in rtc-mpc5121.c
      f756beba
    • Linus Torvalds's avatar
      Merge git://git.samba.org/sfrench/cifs-2.6 · c6de1687
      Linus Torvalds authored
      Pull CIFS fixes from Steve French.
      
      * git://git.samba.org/sfrench/cifs-2.6:
        fs/cifs: fix parsing of dfs referrals
        cifs: make sure we ignore the credentials= and cred= options
        [CIFS] Update cifs version to 1.78
        cifs - check S_AUTOMOUNT in revalidate
        cifs: add missing initialization of server->req_lock
        cifs: don't cap ra_pages at the same level as default_backing_dev_info
        CIFS: Fix indentation in cifs_show_options
      c6de1687
    • Dave Jones's avatar
      CPU frequency drivers MAINTAINERS update · a03a09b2
      Dave Jones authored
      Remove myself as cpufreq maintainer.
      x86 driver changes can go through the regular x86/ACPI trees.
      ARM driver changes through the ARM trees.
      cpufreq core changes are rare these days, and can just go to lkml/direct.
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a03a09b2
    • Linus Torvalds's avatar
      seqlock: add 'raw_seqcount_begin()' function · 4f988f15
      Linus Torvalds authored
      The normal read_seqcount_begin() function will wait for any current
      writers to exit their critical region by looping until the sequence
      count is even.
      
      That "wait for sequence count to stabilize" is the right thing to do if
      the read-locker will just retry the whole operation on contention: no
      point in doing a potentially expensive reader sequence if we know at the
      beginning that we'll just end up re-doing it all.
      
      HOWEVER.  Some users don't actually retry the operation, but instead
      will abort and do the operation with proper locking.  So the sequence
      count case may be the optimistic quick case, but in the presense of
      writers you may want to do full locking in order to guarantee forward
      progress.  The prime example of this would be the RCU name lookup.
      
      And in that case, you may well be better off without the "retry early",
      and are in a rush to instead get to the failure handling.  Thus this
      "raw" interface that just returns the sequence number without testing it
      - it just forces the low bit to zero so that read_seqcount_retry() will
      always fail such a "active concurrent writer" scenario.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4f988f15
    • Linus Torvalds's avatar
      Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value read · 2f624278
      Linus Torvalds authored
      We really need to use a ACCESS_ONCE() on the sequence value read in
      __read_seqcount_begin(), because otherwise the compiler might end up
      reloading the value in between the test and the return of it.  As a
      result, it might end up returning an odd value (which means that a write
      is in progress).
      
      If the reader is then fast enough that that odd value is still the
      current one when the read_seqcount_retry() is done, we might end up with
      a "successful" read sequence, even despite the concurrent write being
      active.
      
      In practice this probably never really happens - there just isn't
      anything else going on around the read of the sequence count, and the
      common case is that we end up having a read barrier immediately
      afterwards.
      
      So the code sequence in which gcc might decide to reaload from memory is
      small, and there's no reason to believe it would ever actually do the
      reload.  But if the compiler ever were to decide to do so, it would be
      incredibly annoying to debug.  Let's just make sure.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f624278