08 Aug, 2010

8 commits

  • The open and release block_device_operations are currently
    called with the BKL held. In order to change that, we must
    first make sure that all drivers that currently rely
    on this have no regressions.

    This blindly pushes the BKL into all .open and .release
    operations for all block drivers to prepare for the
    next step. The drivers can subsequently replace the BKL
    with their own locks or remove it completely when it can
    be shown that it is not needed.

    The functions blkdev_get and blkdev_put are the only
    remaining users of the big kernel lock in the block
    layer, besides a few uses in the ioctl code, none
    of which need to serialize with blkdev_{get,put}.

    Most of these two functions is also under the protection
    of bdev->bd_mutex, including the actual calls to
    ->open and ->release, and the common code does not
    access any global data structures that need the BKL.

    Signed-off-by: Arnd Bergmann
    Acked-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Arnd Bergmann
     
  • Tracing high level background writeback events is good, but it doesn't
    give the entire picture. Add visibility into write throttling to catch IO
    dispatched by foreground throttling of processing dirtying lots of pages.

    Signed-off-by: Dave Chinner
    Signed-off-by: Jens Axboe

    Dave Chinner
     
  • Trace queue/sched/exec parts of the writeback loop. This provides
    insight into when and why flusher threads are scheduled to run. e.g
    a sync invocation leaves traces like:

    sync-[...]: writeback_queue: bdi 8:0: sb_dev 8:1 nr_pages=7712 sync_mode=0 kupdate=0 range_cyclic=0 background=0
    flush-8:0-[...]: writeback_exec: bdi 8:0: sb_dev 8:1 nr_pages=7712 sync_mode=0 kupdate=0 range_cyclic=0 background=0

    This also lays the foundation for adding more writeback tracing to
    provide deeper insight into the whole writeback path.

    The original tracing code is from Jens Axboe, though this version is
    a rewrite as a result of the code being traced changing
    significantly.

    Signed-off-by: Dave Chinner
    Signed-off-by: Jens Axboe

    Dave Chinner
     
  • No real bugs I believe, just some dead code, and some
    shut up code.

    Signed-off-by: Andi Kleen
    Cc: Eric Paris
    Signed-off-by: Andrew Morton
    Signed-off-by: Jens Axboe

    Andi Kleen
     
  • Move all code for the writeback thread into fs/fs-writeback.c instead of
    splitting it over two functions in two files.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Christoph Hellwig
     
  • The wb_list member of struct backing_device_info always has exactly one
    element. Just use the direct bdi->wb pointer instead and simplify some
    code.

    Also remove bdi_task_init which is now trivial to prepare for the next
    patch.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Christoph Hellwig
     
  • Remove the current bio flags and reuse the request flags for the bio, too.
    This allows to more easily trace the type of I/O from the filesystem
    down to the block driver. There were two flags in the bio that were
    missing in the requests: BIO_RW_UNPLUG and BIO_RW_AHEAD. Also I've
    renamed two request flags that had a superflous RW in them.

    Note that the flags are in bio.h despite having the REQ_ name - as
    blkdev.h includes bio.h that is the only way to go for now.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Christoph Hellwig
     
  • A barrier request should by defintion have priority in get_request
    and let the queue be unplugged immediately as it's blocking all forward
    progress due to the queue draining.

    Most filesystems already get this implicitly by the way how submit_bh
    treats the buffer_ordered flag, and gfs2 sets it explicitly. But btrfs
    and XFS are still forgetting to set the flag, as is blkdev_issue_flush
    and some places in DM/MD.

    For XFS on metadata heavy workloads this gives a consistent speedup
    in the 2-3% range.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Christoph Hellwig
     

02 Aug, 2010

1 commit

  • nfs_commit_inode() needs to be defined irrespectively of whether or not
    we are supporting NFSv3 and NFSv4.

    Allow the compiler to optimise away code in the NFSv2-only case by
    converting it into an inlined stub function.

    Reported-and-tested-by: Ingo Molnar
    Signed-off-by: Trond Myklebust
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     

31 Jul, 2010

5 commits


30 Jul, 2010

1 commit

  • It's possible for get_task_cred() as it currently stands to 'corrupt' a set of
    credentials by incrementing their usage count after their replacement by the
    task being accessed.

    What happens is that get_task_cred() can race with commit_creds():

    TASK_1 TASK_2 RCU_CLEANER
    -->get_task_cred(TASK_2)
    rcu_read_lock()
    __cred = __task_cred(TASK_2)
    -->commit_creds()
    old_cred = TASK_2->real_cred
    TASK_2->real_cred = ...
    put_cred(old_cred)
    call_rcu(old_cred)
    [__cred->usage == 0]
    get_cred(__cred)
    [__cred->usage == 1]
    rcu_read_unlock()
    -->put_cred_rcu()
    [__cred->usage == 1]
    panic()

    However, since a tasks credentials are generally not changed very often, we can
    reasonably make use of a loop involving reading the creds pointer and using
    atomic_inc_not_zero() to attempt to increment it if it hasn't already hit zero.

    If successful, we can safely return the credentials in the knowledge that, even
    if the task we're accessing has released them, they haven't gone to the RCU
    cleanup code.

    We then change task_state() in procfs to use get_task_cred() rather than
    calling get_cred() on the result of __task_cred(), as that suffers from the
    same problem.

    Without this change, a BUG_ON in __put_cred() or in put_cred_rcu() can be
    tripped when it is noticed that the usage count is not zero as it ought to be,
    for example:

    kernel BUG at kernel/cred.c:168!
    invalid opcode: 0000 [#1] SMP
    last sysfs file: /sys/kernel/mm/ksm/run
    CPU 0
    Pid: 2436, comm: master Not tainted 2.6.33.3-85.fc13.x86_64 #1 0HR330/OptiPlex
    745
    RIP: 0010:[] [] __put_cred+0xc/0x45
    RSP: 0018:ffff88019e7e9eb8 EFLAGS: 00010202
    RAX: 0000000000000001 RBX: ffff880161514480 RCX: 00000000ffffffff
    RDX: 00000000ffffffff RSI: ffff880140c690c0 RDI: ffff880140c690c0
    RBP: ffff88019e7e9eb8 R08: 00000000000000d0 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000040 R12: ffff880140c690c0
    R13: ffff88019e77aea0 R14: 00007fff336b0a5c R15: 0000000000000001
    FS: 00007f12f50d97c0(0000) GS:ffff880007400000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f8f461bc000 CR3: 00000001b26ce000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process master (pid: 2436, threadinfo ffff88019e7e8000, task ffff88019e77aea0)
    Stack:
    ffff88019e7e9ec8 ffffffff810698cd ffff88019e7e9ef8 ffffffff81069b45
    ffff880161514180 ffff880161514480 ffff880161514180 0000000000000000
    ffff88019e7e9f28 ffffffff8106aace 0000000000000001 0000000000000246
    Call Trace:
    [] put_cred+0x13/0x15
    [] commit_creds+0x16b/0x175
    [] set_current_groups+0x47/0x4e
    [] sys_setgroups+0xf6/0x105
    [] system_call_fastpath+0x16/0x1b
    Code: 48 8d 71 ff e8 7e 4e 15 00 85 c0 78 0b 8b 75 ec 48 89 df e8 ef 4a 15 00
    48 83 c4 18 5b c9 c3 55 8b 07 8b 07 48 89 e5 85 c0 74 04 0b eb fe 65 48 8b
    04 25 00 cc 00 00 48 3b b8 58 04 00 00 75
    RIP [] __put_cred+0xc/0x45
    RSP
    ---[ end trace df391256a100ebdd ]---

    Signed-off-by: David Howells
    Acked-by: Jiri Olsa
    Signed-off-by: Linus Torvalds

    David Howells
     

29 Jul, 2010

3 commits

  • The function ecryptfs_uid_hash wrongly assumes that the
    second parameter to hash_long() is the number of hash
    buckets instead of the number of hash bits.
    This patch fixes that and renames the variable
    ecryptfs_hash_buckets to ecryptfs_hash_bits to make it
    clearer.

    Fixes: CVE-2010-2492

    Signed-off-by: Andre Osterhues
    Signed-off-by: Tyler Hicks
    Signed-off-by: Linus Torvalds

    Andre Osterhues
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
    ceph: use complete_all and wake_up_all
    ceph: Correct obvious typo of Kconfig variable "CRYPTO_AES"
    ceph: fix dentry lease release
    ceph: fix leak of dentry in ceph_init_dentry() error path
    ceph: fix pg_mapping leak on pg_temp updates
    ceph: fix d_release dop for snapdir, snapped dentries
    ceph: avoid dcache readdir for snapdir

    Linus Torvalds
     
  • If we don't need a huge amount of memory in ->readdir() then
    we can use kmalloc rather than vmalloc to allocate it. This
    should cut down on the greater overheads associated with
    vmalloc for smaller directories.

    We may be able to eliminate vmalloc entirely at some stage,
    but this is easy to do right away.

    Also using GFP_NOFS to avoid any issues wrt to deleting inodes
    while under a glock, and suggestion from Linus to factor out
    the alloc/dealloc.

    I've given this a test with a variety of different sized
    directories and it seems to work ok.

    Cc: Andrew Morton
    Cc: Nick Piggin
    Cc: Prarit Bhargava
    Signed-off-by: Steven Whitehouse
    Signed-off-by: Linus Torvalds

    Steven Whitehouse
     

28 Jul, 2010

2 commits


27 Jul, 2010

3 commits

  • Supporting symlinks from untagged to tagged directories is reasonable,
    and needed to support CONFIG_SYSFS_DEPRECATED. So don't fail a prior
    allowing that case to work.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • This happens for network devices when SYSFS_DEPRECATED is enabled.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • Recently my tagged sysfs support revealed a flaw in the device core
    that a few rare drivers are running into such that we don't always put
    network devices in a class subdirectory named net/.

    Since we are not creating the class directory the network devices wind
    up in a non-tagged directory, but the symlinks to the network devices
    from /sys/class/net are in a tagged directory. All of which works
    until we go to remove or rename the symlink. When we remove or rename
    a symlink we look in the namespace of the target of the symlink.
    Since the target of the symlink is in a non-tagged sysfs directory we
    don't have a namespace to look in, and we fail to remove the symlink.

    Detect this problem up front and simply don't create symlinks we won't
    be able to remove later. This prevents symlink leakage and fails in
    a much clearer and more understandable way.

    Signed-off-by: Eric W. Biederman
    Cc: Andrew Morton
    Cc: Rafael J. Wysocki
    Cc: Maciej W. Rozycki
    Cc: Kay Sievers
    Cc: Johannes Berg
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     

25 Jul, 2010

1 commit


24 Jul, 2010

4 commits


23 Jul, 2010

2 commits

  • We should always go to the MDS for readdir on the hidden snapdir. The
    set of snapshots can change at any time; the client can't trust its cache
    for that.

    Signed-off-by: Sage Weil

    Sage Weil
     
  • Fix the security problem in the CIFS filesystem DNS lookup code in which a
    malicious redirect could be installed by a random user by simply adding a
    result record into one of their keyrings with add_key() and then invoking a
    CIFS CFS lookup [CVE-2010-2524].

    This is done by creating an internal keyring specifically for the caching of
    DNS lookups. To enforce the use of this keyring, the module init routine
    creates a set of override credentials with the keyring installed as the thread
    keyring and instructs request_key() to only install lookup result keys in that
    keyring.

    The override is then applied around the call to request_key().

    This has some additional benefits when a kernel service uses this module to
    request a key:

    (1) The result keys are owned by root, not the user that caused the lookup.

    (2) The result keys don't pop up in the user's keyrings.

    (3) The result keys don't come out of the quota of the user that caused the
    lookup.

    The keyring can be viewed as root by doing cat /proc/keys:

    2a0ca6c3 I----- 1 perm 1f030000 0 0 keyring .dns_resolver: 1/4

    It can then be listed with 'keyctl list' by root.

    # keyctl list 0x2a0ca6c3
    1 key in keyring:
    726766307: --alswrv 0 0 dns_resolver: foo.bar.com

    Signed-off-by: David Howells
    Reviewed-and-Tested-by: Jeff Layton
    Acked-by: Steve French
    Signed-off-by: Linus Torvalds

    David Howells
     

22 Jul, 2010

1 commit


21 Jul, 2010

1 commit


20 Jul, 2010

7 commits

  • * 'shrinker' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsdev:
    xfs: track AGs with reclaimable inodes in per-ag radix tree
    xfs: convert inode shrinker to per-filesystem contexts
    mm: add context argument to shrinker callback

    Linus Torvalds
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable:
    Btrfs: fix checks in BTRFS_IOC_CLONE_RANGE
    Btrfs: fix CLONE ioctl destination file size expansion to block boundary
    Btrfs: fix split_leaf double split corner case

    Linus Torvalds
     
  • https://bugzilla.kernel.org/show_bug.cgi?id=16348

    When the filesystem grows to a large number of allocation groups,
    the summing of recalimable inodes gets expensive. In many cases,
    most AGs won't have any reclaimable inodes and so we are wasting CPU
    time aggregating over these AGs. This is particularly important for
    the inode shrinker that gets called frequently under memory
    pressure.

    To avoid the overhead, track AGs with reclaimable inodes in the
    per-ag radix tree so that we can find all the AGs with reclaimable
    inodes via a simple gang tag lookup. This involves setting the tag
    when the first reclaimable inode is tracked in the AG, and removing
    the tag when the last reclaimable inode is removed from the tree.
    Then the summation process becomes a loop walking the radix tree
    summing AGs with the reclaim tag set.

    This significantly reduces the overhead of scanning - a 6400 AG
    filesystea now only uses about 25% of a cpu in kswapd while slab
    reclaim progresses instead of being permanently stuck at 100% CPU
    and making little progress. Clean filesystems filesystems will see
    no overhead and the overhead only increases linearly with the number
    of dirty AGs.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     
  • Now the shrinker passes us a context, wire up a shrinker context per
    filesystem. This allows us to remove the global mount list and the
    locking problems that introduced. It also means that a shrinker call
    does not need to traverse clean filesystems before finding a
    filesystem with reclaimable inodes. This significantly reduces
    scanning overhead when lots of filesystems are present.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     
  • 1. The BTRFS_IOC_CLONE and BTRFS_IOC_CLONE_RANGE ioctls should check
    whether the donor file is append-only before writing to it.

    2. The BTRFS_IOC_CLONE_RANGE ioctl appears to have an integer
    overflow that allows a user to specify an out-of-bounds range to copy
    from the source file (if off + len wraps around). I haven't been able
    to successfully exploit this, but I'd imagine that a clever attacker
    could use this to read things he shouldn't. Even if it's not
    exploitable, it couldn't hurt to be safe.

    Signed-off-by: Dan Rosenberg
    cc: stable@kernel.org
    Signed-off-by: Chris Mason

    Dan Rosenberg
     
  • The CLONE and CLONE_RANGE ioctls round up the range of extents being
    cloned to the block size when the range to clone extends to the end of file
    (this is always the case with CLONE). It was then using that offset when
    extending the destination file's i_size. Fix this by not setting i_size
    beyond the originally requested ending offset.

    This bug was introduced by a22285a6 (2.6.35-rc1).

    Signed-off-by: Sage Weil
    Signed-off-by: Chris Mason

    Sage Weil
     
  • split_leaf was not properly balancing leaves when it was forced to
    split a leaf twice. This commit adds an extra push left and right
    before forcing the double split in hopes of getting the slot where
    we want to insert at either the start or end of the leaf.

    If the extra pushes do work, then we are able to avoid splitting twice
    and we keep the tree properly balanced.

    Signed-off-by: Chris Mason

    Chris Mason
     

19 Jul, 2010

1 commit

  • Partition boundary calculation fails for DASD FBA disks under the
    following conditions:
    - disk is formatted with CMS FORMAT with a blocksize of more than
    512 bytes
    - all of the disk is reserved to a single CMS file using CMS RESERVE
    - the disk is accessed using the DIAG mode of the DASD driver

    Under these circumstances, the partition detection code tries to
    read the CMS label block containing partition-relevant information
    from logical block offset 1, while it is in fact located at physical
    block offset 1.

    Fix this problem by using the correct CMS label block location
    depending on the device type as determined by the DASD SENSE ID
    information.

    Signed-off-by: Peter Oberparleiter
    Signed-off-by: Martin Schwidefsky

    Peter Oberparleiter