04 Oct, 2011

1 commit


01 Oct, 2011

1 commit

  • A user reported a problem where ceph was getting into 100% cpu usage while doing
    some writing. It turns out it's because we were doing a short write on a not
    uptodate page, which means we'd fall back at one page at a time and fault the
    page in. The problem is our position is on the page boundary, so our fault in
    logic wasn't actually reading the page, so we'd just spin forever or until the
    page got read in by somebody else. This will force a readpage if we end up
    doing a short copy. Alexandre could reproduce this easily with ceph and reports
    it fixes his problem. I also wrote a reproducer that no longer hangs my box
    with this patch. Thanks,

    Reported-and-tested-by: Alexandre Oliva
    Signed-off-by: Josef Bacik
    Signed-off-by: Chris Mason

    Josef Bacik
     

27 Sep, 2011

3 commits

  • That flag no longer makes sense, since we don't look up automount points
    as eagerly any more. Additionally, it turns out that the NO_AUTOMOUNT
    handling was buggy to begin with: it would avoid automounting even for
    cases where we really *needed* to do the automount handling, and could
    return ENOENT for autofs entries that hadn't been instantiated yet.

    With our new non-eager automount semantics, one discussion has been
    about adding a AT_AUTOMOUNT flag to vfs_fstatat (and thus the
    newfstatat() and fstatat64() system calls), but it's probably not worth
    it: you can always force at least directory automounting by simply
    adding the final '/' to the filename, which works for *all* of the stat
    family system calls, old and new.

    So AT_NO_AUTOMOUNT (and thus LOOKUP_NO_AUTOMOUNT) really were just a
    result of our bad default behavior.

    Acked-by: Ian Kent
    Acked-by: Trond Myklebust
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • The concensus seems to be that system calls such as stat() etc should
    not trigger an automount. Neither should the l* versions.

    This patch therefore adds a LOOKUP_AUTOMOUNT flag to tag those lookups
    that _should_ trigger an automount on the last path element.

    Signed-off-by: Trond Myklebust
    [ Edited to leave out the cases that are already covered by LOOKUP_OPEN,
    LOOKUP_DIRECTORY and LOOKUP_CREATE - all of which also fundamentally
    force automounting for their own reasons - Linus ]
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     
  • Since we've now turned around and made LOOKUP_FOLLOW *not* force an
    automount, we want to add the ability to force an automount event on
    lookup even if we don't happen to have one of the other flags that force
    it implicitly (LOOKUP_OPEN, LOOKUP_DIRECTORY, LOOKUP_PARENT..)

    Most cases will never want to use this, since you'd normally want to
    delay automounting as long as possible, which usually implies
    LOOKUP_OPEN (when we open a file or directory, we really cannot avoid
    the automount any more).

    But Trond argued sufficiently forcefully that at a minimum bind mounting
    a file and quotactl will want to force the automount lookup. Some other
    cases (like nfs_follow_remote_path()) could use it too, although
    LOOKUP_DIRECTORY would work there as well.

    This commit just adds the flag and logic, no users yet, though. It also
    doesn't actually touch the LOOKUP_NO_AUTOMOUNT flag that is related, and
    was made irrelevant by the same change that made us not follow on
    LOOKUP_FOLLOW.

    Cc: Trond Myklebust
    Cc: Ian Kent
    Cc: Jeff Layton
    Cc: Miklos Szeredi
    Cc: David Howells
    Cc: Al Viro
    Cc: Greg KH
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

22 Sep, 2011

4 commits

  • * 'for-linus' of git://git.kernel.dk/linux-block:
    floppy: use del_timer_sync() in init cleanup
    blk-cgroup: be able to remove the record of unplugged device
    block: Don't check QUEUE_FLAG_SAME_COMP in __blk_complete_request
    mm: Add comment explaining task state setting in bdi_forker_thread()
    mm: Cleanup clearing of BDI_pending bit in bdi_forker_thread()
    block: simplify force plug flush code a little bit
    block: change force plug flush call order
    block: Fix queue_flag update when rq_affinity goes from 2 to 1
    block: separate priority boosting from REQ_META
    block: remove READ_META and WRITE_META
    xen-blkback: fixed indentation and comments
    xen-blkback: Don't disconnect backend until state switched to XenbusStateClosed.

    Linus Torvalds
     
  • This is modeled after the smaps code.

    It detects transparent hugepages and then does a single gather_stats()
    for the page as a whole. This has two benifits:
    1. It is more efficient since it does many pages in a single shot.
    2. It does not have to break down the huge page.

    Signed-off-by: Dave Hansen
    Acked-by: Hugh Dickins
    Acked-by: David Rientjes
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • gather_pte_stats() does a number of checks on a target page
    to see whether it should even be considered for statistics.
    This breaks that code out in to a separate function so that
    we can use it in the transparent hugepage case in the next
    patch.

    Signed-off-by: Dave Hansen
    Acked-by: Hugh Dickins
    Reviewed-by: Christoph Lameter
    Acked-by: David Rientjes
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • We need to teach the numa_maps code about transparent huge pages. The
    first step is to teach gather_stats() that the pte it is dealing with
    might represent more than one page.

    Note that will we use this in a moment for transparent huge pages since
    they have use a single pmd_t which _acts_ as a "surrogate" for a bunch
    of smaller pte_t's.

    I'm a _bit_ unhappy that this interface counts in hugetlbfs page sizes
    for hugetlbfs pages and PAGE_SIZE for normal pages. That means that to
    figure out how many _bytes_ "dirty=1" means, you must first know the
    hugetlbfs page size. That's easier said than done especially if you
    don't have visibility in to the mount.

    But, that's probably a discussion for another day especially since it
    would change behavior to fix it. But, just in case anyone wonders why
    this patch only passes a '1' in the hugetlb case...

    Signed-off-by: Dave Hansen
    Acked-by: Hugh Dickins
    Acked-by: David Rientjes
    Signed-off-by: Linus Torvalds

    Dave Hansen
     

21 Sep, 2011

3 commits


20 Sep, 2011

5 commits

  • Fix sec=ntlmv2/i authentication option during mount of Samba shares.

    cifs client was coding ntlmv2 response incorrectly.
    All that is needed in temp as specified in MS-NLMP seciton 3.3.2

    "Define ComputeResponse(NegFlg, ResponseKeyNT, ResponseKeyLM,
    CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge, Time, ServerName)

    as
    Set temp to ConcatenationOf(Responserversion, HiResponserversion,
    Z(6), Time, ClientChallenge, Z(4), ServerName, Z(4)"

    is MsvAvNbDomainName.

    For sec=ntlmsspi, build_av_pair is not used, a blob is plucked from
    type 2 response sent by the server to use in authentication.

    I tested sec=ntlmv2/i and sec=ntlmssp/i mount options against
    Samba (3.6) and Windows - XP, 2003 Server and 7.
    They all worked.

    Signed-off-by: Shirish Pargaonkar
    Signed-off-by: Steve French

    Shirish Pargaonkar
     
  • Both these options are started with "rw" - that's why the first one
    isn't switched on even if it is specified. Fix this by adding a length
    check for "rw" option check.

    Cc:
    Signed-off-by: Pavel Shilovsky
    Signed-off-by: Steve French

    Steve French
     
  • move it to the beginning of the loop.

    Signed-off-by: Pavel Shilovsky
    Reviewed-by: Jeff Layton
    Signed-off-by: Steve French

    Pavel Shilovsky
     
  • The name_len variable in CIFSFindNext is a signed int that gets set to
    the resume_name_len in the cifs_search_info. The resume_name_len however
    is unsigned and for some infolevels is populated directly from a 32 bit
    value sent by the server.

    If the server sends a very large value for this, then that value could
    look negative when converted to a signed int. That would make that
    value pass the PATH_MAX check later in CIFSFindNext. The name_len would
    then be used as a length value for a memcpy. It would then be treated
    as unsigned again, and the memcpy scribbles over a ton of memory.

    Fix this by making the name_len an unsigned value in CIFSFindNext.

    Cc:
    Reported-by: Darren Lavender
    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     
  • * 'for-linus' of git://github.com/chrismason/linux:
    Btrfs: only clear the need lookup flag after the dentry is setup
    BTRFS: Fix lseek return value for error
    Btrfs: don't change inode flag of the dest clone file
    Btrfs: don't make a file partly checksummed through file clone
    Btrfs: fix pages truncation in btrfs_ioctl_clone()
    btrfs: fix d_off in the first dirent

    Linus Torvalds
     

18 Sep, 2011

7 commits

  • We can race with readdir and the RCU path walking stuff. This is because we
    clear the need lookup flag before actually instantiating the inode. This will
    lead the RCU path walk stuff to find a dentry it thinks is valid without a
    d_inode attached. So instead unhash the dentry when we first start the lookup,
    and then clear the flag after we've instantiated the dentry so we're garunteed
    to either try the slow lookup, or have the d_inode set properly.

    Signed-off-by: Josef Bacik
    Signed-off-by: Chris Mason

    Josef Bacik
     
  • The recent reworking of btrfs' lseek lead to incorrect
    values being returned. This adds checks for seeking
    beyond EOF in SEEK_HOLE and makes sure the error
    values come back correct.

    Andi Kleen also sent in similar patches.

    Signed-off-by: Jie Liu
    Reported-by: Andi Kleen
    Signed-off-by: Chris Mason

    Jeff Liu
     
  • Chris Mason
     
  • The dst file will have the same inode flags with dst file after
    file clone, and I think it's unexpected.

    For example, the dst file will suddenly become immutable after
    getting some share of data with src file, if the src is immutable.

    Signed-off-by: Li Zefan
    Signed-off-by: Chris Mason

    Li Zefan
     
  • To reproduce the bug:

    # mount /dev/sda7 /mnt
    # dd if=/dev/zero of=/mnt/src bs=4K count=1
    # umount /mnt

    # mount -o nodatasum /dev/sda7 /mnt
    # dd if=/dev/zero of=/mnt/dst bs=4K count=1
    # clone_range -s 4K -l 4K /mnt/src /mnt/dst

    # echo 3 > /proc/sys/vm/drop_caches
    # cat /mnt/dst
    # dmesg
    ...
    btrfs no csum found for inode 258 start 0
    btrfs csum failed ino 258 off 0 csum 2566472073 private 0

    It's because part of the file is checksummed and the other part is not,
    and then btrfs will complain checksum is not found when we read the file.

    Disallow file clone if src and dst file have different checksum flag,
    so we ensure a file is completely checksummed or unchecksummed.

    Signed-off-by: Li Zefan
    Signed-off-by: Chris Mason

    Li Zefan
     
  • It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
    (Btrfs: truncate pages from clone ioctl target range)

    We should pass the dest range to the truncate function, but not the
    src range.

    Also move the function before locking extent state.

    Signed-off-by: Li Zefan
    Signed-off-by: Chris Mason

    Li Zefan
     
  • Since the d_off in the first dirent for "." (that originates from
    the 4th argument "offset" of filldir() for the 2nd dirent for "..")
    is wrongly assigned in btrfs_real_readdir(), telldir returns same
    offset for different locations.

    | # mkfs.btrfs /dev/sdb1
    | # mount /dev/sdb1 fs0
    | # cd fs0
    | # touch file0 file1
    | # ../test
    | telldir: 0
    | readdir: d_off = 2, d_name = "."
    | telldir: 2
    | readdir: d_off = 2, d_name = ".."
    | telldir: 2
    | readdir: d_off = 3, d_name = "file0"
    | telldir: 3
    | readdir: d_off = 2147483647, d_name = "file1"
    | telldir: 2147483647

    To fix this problem, pass filp->f_pos (which is loff_t) instead.

    | # ../test
    | telldir: 0
    | readdir: d_off = 1, d_name = "."
    | telldir: 1
    | readdir: d_off = 2, d_name = ".."
    | telldir: 2
    | readdir: d_off = 3, d_name = "file0"
    :

    At the moment the "offset" for "." is unused because there is no
    preceding dirent, however it is better to pass filp->f_pos to follow
    grammatical usage.

    Signed-off-by: Hidetoshi Seto
    Signed-off-by: Chris Mason

    Hidetoshi Seto
     

16 Sep, 2011

3 commits

  • * 'bugfixes' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
    nfs: Do not allow multiple mounts on same mountpoint when using -o noac
    NFS: Fix a typo in nfs_flush_multi
    NFSv4: renewd needs to be able to handle the NFS4ERR_CB_PATH_DOWN error
    NFSv4: The NFSv4.0 client must send RENEW calls if it holds a delegation
    NFSv4: nfs4_proc_renew should be declared static
    NFSv4: nfs4_proc_async_renew should use a GFP_NOFS allocation

    Linus Torvalds
     
  • generic_check_addressable can't deal with hfsplus's larger than page
    size allocation blocks, so simply opencode the checks that we actually
    need in hfsplus_fill_super.

    Signed-off-by: Christoph Hellwig
    Reported-by: Pavel Ivanov
    Tested-by: Pavel Ivanov
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Commit 6596528e391a ("hfsplus: ensure bio requests are not smaller than
    the hardware sectors") changed the pointers used for volume header
    allocations but failed to free the correct pointers in the error path
    path of hfsplus_fill_super() and hfsplus_read_wrapper.

    The second hunk came from a separate patch by Pavel Ivanov.

    Reported-by: Pavel Ivanov
    Signed-off-by: Seth Forshee
    Signed-off-by: Christoph Hellwig
    Cc:
    Signed-off-by: Linus Torvalds

    Seth Forshee
     

15 Sep, 2011

2 commits

  • * 'for-linus' of git://oss.sgi.com/xfs/xfs:
    xfs: fix a use after free in xfs_end_io_direct_write

    Linus Torvalds
     
  • We used to get the victim pinned by dentry_unhash() prior to commit
    64252c75a219 ("vfs: remove dget() from dentry_unhash()") and ->rmdir()
    and ->rename() instances relied on that; most of them don't care, but
    ones that used d_delete() themselves do. As the result, we are getting
    rmdir() oopses on NFS now.

    Just grab the reference before locking the victim and drop it explicitly
    after unlocking, same as vfs_rename_other() does.

    Signed-off-by: Al Viro
    Tested-by: Simon Kirby
    Cc: stable@kernel.org (3.0.x)
    Signed-off-by: Linus Torvalds

    Al Viro
     

14 Sep, 2011

3 commits

  • There is a window in which the ioend that we call inode_dio_wake on
    in xfs_end_io_direct_write is already free. Fix this by storing
    the inode pointer in a local variable.

    This is a fix for the regression introduced in 3.1-rc by
    "fs: move inode_dio_done to the end_io handler".

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Alex Elder

    Christoph Hellwig
     
  • Do not allow multiple mounts on same mountpoint when using -o noac

    When you normally attempt to mount a share twice on the same mountpoint,
    a check in do_add_mount causes it to return an error

    # mount localhost:/nfsv3 /mnt
    # mount localhost:/nfsv3 /mnt
    mount.nfs: /mnt is already mounted or busy

    However when using the option 'noac', the user is able to mount the same
    share on the same mountpoint multiple times. This happens because a
    share mounted with the noac option is automatically assigned the 'sync'
    flag MS_SYNCHRONOUS in nfs_initialise_sb(). This flag is set after the
    check for already existing superblocks is done in sget(). The check for
    the mount flags in nfs_compare_mount_options() does not take into
    account the 'sync' flag applied later on in the code path. This means
    that when using 'noac', a new superblock structure is assigned for every
    new mount of the same share and multiple shares on the same mountpoint
    are allowed.

    ie.
    # mount -onoac localhost:/nfsv3 /mnt
    can be run multiple times.

    The patch checks for noac and assigns the sync flag before sget() is
    called to obtain an already existing superblock structure.

    Signed-off-by: Sachin Prabhu
    Reviewed-by: Jeff Layton
    Signed-off-by: Trond Myklebust

    Sachin Prabhu
     
  • Fix a typo which causes an Oops in the RPC layer, when using wsize < 4k.

    Signed-off-by: Trond Myklebust
    Tested-by: Sricharan R

    Trond Myklebust
     

13 Sep, 2011

3 commits

  • * 'for-linus' of git://github.com/chrismason/linux:
    Btrfs: add dummy extent if dst offset excceeds file end in
    Btrfs: calc file extent num_bytes correctly in file clone
    btrfs: xattr: fix attribute removal
    Btrfs: fix wrong nbytes information of the inode
    Btrfs: fix the file extent gap when doing direct IO
    Btrfs: fix unclosed transaction handle in btrfs_cont_expand
    Btrfs: fix misuse of trans block rsv
    Btrfs: reset to appropriate block rsv after orphan operations
    Btrfs: skip locking if searching the commit root in csum lookup
    btrfs: fix warning in iput for bad-inode
    Btrfs: fix an oops when deleting snapshots

    Linus Torvalds
     
  • kmemleak is reporting that 32 bytes are being leaked by FUSE:

    unreferenced object 0xe373b270 (size 32):
    comm "fusermount", pid 1207, jiffies 4294707026 (age 2675.187s)
    hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    backtrace:
    [] kmemleak_alloc+0x27/0x50
    [] kmem_cache_alloc+0xc5/0x180
    [] fuse_alloc_forget+0x1e/0x20
    [] fuse_alloc_inode+0xb0/0xd0
    [] alloc_inode+0x1c/0x80
    [] iget5_locked+0x8f/0x1a0
    [] fuse_iget+0x72/0x1a0
    [] fuse_get_root_inode+0x8a/0x90
    [] fuse_fill_super+0x3ef/0x590
    [] mount_nodev+0x3f/0x90
    [] fuse_mount+0x15/0x20
    [] mount_fs+0x1c/0xc0
    [] vfs_kern_mount+0x41/0x90
    [] do_kern_mount+0x39/0xd0
    [] do_mount+0x2e5/0x660
    [] sys_mount+0x66/0xa0

    This leak report is consistent and happens once per boot on
    3.1.0-rc5-dirty.

    This happens if a FORGET request is queued after the fuse device was
    released.

    Reported-by: Sitsofe Wheeler
    Signed-off-by: Miklos Szeredi
    Tested-by: Sitsofe Wheeler
    Signed-off-by: Linus Torvalds

    Miklos Szeredi
     
  • Commit 37fb3a30b4 ("fuse: fix flock") added in 3.1-rc4 caused flock() to
    fail with ENOSYS with the kernel ABI version 7.16 or earlier.

    Fix by falling back to testing FUSE_POSIX_LOCKS for ABI versions 7.16
    and earlier.

    Reported-by: Martin Ziegler
    Signed-off-by: Miklos Szeredi
    Tested-by: Martin Ziegler
    Signed-off-by: Linus Torvalds

    Miklos Szeredi
     

11 Sep, 2011

5 commits

  • You can see there's no file extent with range [0, 4096]. Check this by
    btrfsck:

    # btrfsck /dev/sda7
    root 5 inode 258 errors 100
    ...

    Signed-off-by: Li Zefan
    Signed-off-by: Chris Mason

    Li Zefan
     
  • num_bytes should be 4096 not 12288.

    Signed-off-by: Li Zefan
    Signed-off-by: Chris Mason

    Li Zefan
     
  • An attribute is not removed by 'setfattr -x attr file' and remains
    visible in attr list. This makes xfstests/062 pass again.

    Signed-off-by: David Sterba
    Signed-off-by: Chris Mason

    David Sterba
     
  • If we write some data into the data hole of the file(no preallocation for this
    hole), Btrfs will allocate some disk space, and update nbytes of the inode, but
    the other element--disk_i_size needn't be updated. At this condition, we must
    update inode metadata though disk_i_size is not changed(btrfs_ordered_update_i_size()
    return 1).

    # mkfs.btrfs /dev/sdb1
    # mount /dev/sdb1 /mnt
    # touch /mnt/a
    # truncate -s 856002 /mnt/a
    # dd if=/dev/zero of=/mnt/a bs=4K count=1 conv=nocreat,notrunc
    # umount /mnt
    # btrfsck /dev/sdb1
    root 5 inode 257 errors 400
    found 32768 bytes used err is 1

    Signed-off-by: Miao Xie
    Signed-off-by: Chris Mason

    Miao Xie
     
  • When we write some data to the place that is beyond the end of the file
    in direct I/O mode, a data hole will be created. And Btrfs should insert
    a file extent item that point to this hole into the fs tree. But unfortunately
    Btrfs forgets doing it.

    The following is a simple way to reproduce it:
    # mkfs.btrfs /dev/sdc2
    # mount /dev/sdc2 /test4
    # touch /test4/a
    # dd if=/dev/zero of=/test4/a seek=8 count=1 bs=4K oflag=direct conv=nocreat,notrunc
    # umount /test4
    # btrfsck /dev/sdc2
    root 5 inode 257 errors 100

    Reported-by: Tsutomu Itoh
    Signed-off-by: Miao Xie
    Tested-by: Tsutomu Itoh
    Signed-off-by: Chris Mason

    Miao Xie