1. 30 Sep, 2014 1 commit
  2. 29 Sep, 2014 3 commits
  3. 26 Sep, 2014 6 commits
  4. 17 Sep, 2014 11 commits
    • J. Bruce Fields's avatar
      nfsd4: clarify how grace period ends · 70b28235
      J. Bruce Fields authored
      The grace period is ended in two steps--first userland is notified that
      the grace period is now long enough that any clients who have not yet
      reclaimed can be safely forgotten, then we flip the switch that forbids
      reclaims and allows new opens.  I had to think a bit to convince myself
      that the ordering was right here.  Document it.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      70b28235
    • J. Bruce Fields's avatar
      nfsd4: stop grace_time update at end of grace period · bea57fe4
      J. Bruce Fields authored
      The attempt to automatically set a new grace period time at the end of
      the grace period isn't really helpful.  We'll probably shut down and
      reboot before we actually make use of the new grace period time anyway.
      So may as well leave it up to the init system to get this right.
      
      This just confuses people when they see /proc/fs/nfsd/nfsv4gracetime
      change from what they set it to.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      bea57fe4
    • Jeff Layton's avatar
      nfsd: skip subsequent UMH "create" operations after the first one for v4.0 clients · 65decb65
      Jeff Layton authored
      In the case of v4.0 clients, we may call into the "create" client
      tracking operation multiple times (once for each openowner). Upcalling
      for each one of those is wasteful and slow however. We can skip doing
      further "create" operations after the first one if we know that one has
      already been done.
      
      v4.1+ clients generally only call into this function once (on
      RECLAIM_COMPLETE), and we can't skip upcalling on the create even if the
      STABLE bit is set. Doing so would make it impossible for nfsdcltrack to
      lift the grace period early since the timestamp has a different meaning
      in the case where the client is expected to issue a RECLAIM_COMPLETE.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      65decb65
    • Jeff Layton's avatar
      nfsd: set and test NFSD4_CLIENT_STABLE bit to reduce nfsdcltrack upcalls · 788a7914
      Jeff Layton authored
      The nfsdcltrack upcall doesn't utilize the NFSD4_CLIENT_STABLE flag,
      which basically results in an upcall every time we call into the client
      tracking ops.
      
      Change it to set this bit on a successful "check" or "create" request,
      and clear it on a "remove" request.  Also, check to see if that bit is
      set before upcalling on a "check" or "remove" request, and skip
      upcalling appropriately, depending on its state.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      788a7914
    • Jeff Layton's avatar
      nfsd: serialize nfsdcltrack upcalls for a particular client · d682e750
      Jeff Layton authored
      In a later patch, we want to add a flag that will allow us to reduce the
      need for upcalls. In order to handle that correctly, we'll need to
      ensure that racing upcalls for the same client can't occur. In practice
      it should be rare for this to occur with a well-behaved client, but it
      is possible.
      
      Convert one of the bits in the cl_flags field to be an upcall bitlock,
      and use it to ensure that upcalls for the same client are serialized.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      d682e750
    • Jeff Layton's avatar
      nfsd: pass extra info in env vars to upcalls to allow for early grace period end · d4318acd
      Jeff Layton authored
      In order to support lifting the grace period early, we must tell
      nfsdcltrack what sort of client the "create" upcall is for. We can't
      reliably tell if a v4.0 client has completed reclaiming, so we can only
      lift the grace period once all the v4.1+ clients have issued a
      RECLAIM_COMPLETE and if there are no v4.0 clients.
      
      Also, in order to lift the grace period, we have to tell userland when
      the grace period started so that it can tell whether a RECLAIM_COMPLETE
      has been issued for each client since then.
      
      Since this is all optional info, we pass it along in environment
      variables to the "init" and "create" upcalls. By doing this, we don't
      need to revise the upcall format. The UMH upcall can simply make use of
      this info if it happens to be present. If it's not then it can just
      avoid lifting the grace period early.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      d4318acd
    • Jeff Layton's avatar
      nfsd: add a v4_end_grace file to /proc/fs/nfsd · 7f5ef2e9
      Jeff Layton authored
      Allow a privileged userland process to end the v4 grace period early.
      Writing "Y", "y", or "1" to the file will cause the v4 grace period to
      be lifted.  The basic idea with this will be to allow the userland
      client tracking program to lift the grace period once it knows that no
      more clients will be reclaiming state.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      7f5ef2e9
    • Jeff Layton's avatar
      lockd: add a /proc/fs/lockd/nlm_end_grace file · d68e3c4a
      Jeff Layton authored
      Add a new procfile that will allow a (privileged) userland process to
      end the NLM grace period early. The basic idea here will be to have
      sm-notify write to this file, if it sent out no NOTIFY requests when
      it runs. In that situation, we can generally expect that there will be
      no reclaim requests so the grace period can be lifted early.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      d68e3c4a
    • Jeff Layton's avatar
      nfsd: reject reclaim request when client has already sent RECLAIM_COMPLETE · 3b3e7b72
      Jeff Layton authored
      As stated in RFC 5661, section 18.51.3:
      
          Once a RECLAIM_COMPLETE is done, there can be no further reclaim
          operations for locks whose scope is defined as having completed
          recovery.  Once the client sends RECLAIM_COMPLETE, the server will
          not allow the client to do subsequent reclaims of locking state for
          that scope and, if these are attempted, will return
          NFS4ERR_NO_GRACE.
      
      Ensure that we enforce that requirement.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      3b3e7b72
    • Jeff Layton's avatar
      nfsd: remove redundant boot_time parm from grace_done client tracking op · 919b8049
      Jeff Layton authored
      Since it's stored in nfsd_net, we don't need to pass it in separately.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      919b8049
    • Jeff Layton's avatar
      lockd: move lockd's grace period handling into its own module · f7790029
      Jeff Layton authored
      Currently, all of the grace period handling is part of lockd. Eventually
      though we'd like to be able to build v4-only servers, at which point
      we'll need to put all of this elsewhere.
      
      Move the code itself into fs/nfs_common and have it build a grace.ko
      module. Then, rejigger the Kconfig options so that both nfsd and lockd
      enable it automatically.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      f7790029
  5. 11 Sep, 2014 1 commit
  6. 07 Sep, 2014 11 commits
  7. 06 Sep, 2014 6 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 2b12164b
      Linus Torvalds authored
      Pull kvm fixes from Paolo Bonzini:
       "A smattering of bug fixes across most architectures"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        powerpc/kvm/cma: Fix panic introduces by signed shift operation
        KVM: s390/mm: Fix guest storage key corruption in ptep_set_access_flags
        KVM: s390/mm: Fix storage key corruption during swapping
        arm/arm64: KVM: Complete WFI/WFE instructions
        ARM/ARM64: KVM: Nuke Hyp-mode tlbs before enabling MMU
        KVM: s390/mm: try a cow on read only pages for key ops
        KVM: s390: Fix user triggerable bug in dead code
      2b12164b
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 56c22854
      Linus Torvalds authored
      Pull ARM SoC fixes from Kevin Hilman:
       "Another round of fixes from arm-soc land, which are mostly DT fixes
        for:
      
         - OMAP: handful of DT fixes devices on newly supported hardware
         - davinci: fix 2nd EDMA channel
         - ux500: extend previous pinctrl fix to another board
         - at91: clock registration fixes, compatibility string precision
      
        And one more fix for event cleanup in drivers/bus/arm-ccn"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        bus: arm-ccn: Move event cleanup routine
        ARM: at91/dt: rm9200: fix usb clock definition
        ARM: at91: rm9200: fix clock registration
        ARM: at91/dt: sam9g20: set at91sam9g20 pllb driver
        ARM: dts: dra7-evm: Add vtt regulator support
        ARM: dts: dra7-evm: Fix spi1 mux documentation
        ARM: dts: am43x-epos-evm: Disable QSPI to prevent conflict with GPMC-NAND
        ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring
        ARM: dts: am43xx-epos-evm: Don't use read/write wait monitoring
        ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
        ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8
        ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8
        ARM: dts: am4372: fix USB regs size
        ARM: dts: am437x-gp: switch i2c0 to 100KHz
        ARM: dts: dra7-evm: Fix 8th NAND partition's name
        ARM: dts: dra7-evm: Fix i2c3 pinmux and frequency
        ARM: ux500: disable msp2 node on Snowball
        ARM: edma: Fix configuration parsing for SoCs with multiple eDMA3 CC
        ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock
      56c22854
    • Linus Torvalds's avatar
      Merge tag 'xfs-for-linus-3.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs · 11e97398
      Linus Torvalds authored
      Pull xfs fixes from Dave Chinner:
       "The fixes all address recently discovered data corruption issues.
      
        The original Direct IO issue was discovered by Chris Mason @ Facebook
        on a production workload which mixed buffered reads with direct reads
        and writes IO to the same file.  The fix for that exposed other issues
        with page invalidation (exposed by millions of fsx operations) failing
        due to dirty buffers beyond EOF.
      
        Finally, the collapse_range code could also cause problems due to
        racing writeback changing the extent map while it was being shifted
        around.  The commits for that problem are simple mitigation fixes that
        prevent the problem from occuring.  A more robust fix for 3.18 that
        addresses the underlying problem is currently being worked on by
        Brian.
      
        Summary of fixes:
         - a direct IO read/buffered read data corruption
         - the associated fallout from the DIO data corruption fix
         - collapse range bugs that are potential data corruption issues"
      
      * tag 'xfs-for-linus-3.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs:
        xfs: trim eofblocks before collapse range
        xfs: xfs_file_collapse_range is delalloc challenged
        xfs: don't log inode unless extent shift makes extent modifications
        xfs: use ranged writeback and invalidation for direct IO
        xfs: don't zero partial page cache pages during O_DIRECT writes
        xfs: don't zero partial page cache pages during O_DIRECT writes
        xfs: don't dirty buffers beyond EOF
      11e97398
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20140905' of git://git.infradead.org/linux-mtd · 925e0ea4
      Linus Torvalds authored
      Pull mtd fixes from Brian Norris:
       "Two trivial MTD updates for 3.17-rc4:
      
         - a tiny comment tweak, to kill a bunch of DocBook warnings added
           during the merge window
      
         - a small fixup to the OTP routines' error handling"
      
      * tag 'for-linus-20140905' of git://git.infradead.org/linux-mtd:
        mtd: nand: fix DocBook warnings on nand_sdr_timings doc
        mtd: cfi_cmdset_0002: check return code for get_chip()
      925e0ea4
    • Thomas Gleixner's avatar
      timekeeping: Update timekeeper before updating vsyscall and pvclock · 9bf2419f
      Thomas Gleixner authored
      The update_walltime() code works on the shadow timekeeper to make the
      seqcount protected region as short as possible. But that update to the
      shadow timekeeper does not update all timekeeper fields because it's
      sufficient to do that once before it becomes life. One of these fields
      is tkr.base_mono. That stays stale in the shadow timekeeper unless an
      operation happens which copies the real timekeeper to the shadow.
      
      The update function is called after the update calls to vsyscall and
      pvclock. While not correct, it did not cause any problems because none
      of the invoked update functions used base_mono.
      
      commit cbcf2dd3 (x86: kvm: Make kvm_get_time_and_clockread()
      nanoseconds based) changed that in the kvm pvclock update function, so
      the stale mono_base value got used and caused kvm-clock to malfunction.
      
      Put the update where it belongs and fix the issue.
      Reported-by: default avatarChris J Arges <chris.j.arges@canonical.com>
      Reported-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409050000570.3333@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      9bf2419f
    • Thomas Gleixner's avatar
      compat: nanosleep: Clarify error handling · 849151dd
      Thomas Gleixner authored
      The error handling in compat_sys_nanosleep() is correct, but
      completely non obvious. Document it and restrict it to the
      -ERESTART_RESTARTBLOCK return value for clarity.
      Reported-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      849151dd
  8. 05 Sep, 2014 1 commit