Skip to content

L
linux
Switch branch/tag
  1. 30 Sep, 2014 2 commits
  3. 29 Sep, 2014 3 commits
  5. 26 Sep, 2014 6 commits
  7. 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
  9. 11 Sep, 2014 1 commit
  11. 07 Sep, 2014 11 commits
  13. 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7