03 Mar, 2019

1 commit


22 Feb, 2019

1 commit

  • A 'false retry' in NFSv4.1 occurs when the client attempts to transmit a
    new RPC call using a slot+sequence number combination that references an
    already cached one. Currently, the Linux NFS client will do this if a
    user process interrupts an RPC call that is in progress.
    The problem with doing so is that we defeat the main mechanism used by
    the server to differentiate between a new call and a replayed one. Even
    if the server is able to perfectly cache the arguments of the old call,
    it cannot know if the client intended to replay or send a new call.

    The obvious fix is to bump the sequence number pre-emptively if an
    RPC call is interrupted, but in order to deal with the corner cases
    where the interrupted call is not actually received and processed by
    the server, we need to interpret the error NFS4ERR_SEQ_MISORDERED
    as a sign that we need to either wait or locate a correct sequence
    number that lies between the value we sent, and the last value that
    was acked by a SEQUENCE call on that slot.

    Signed-off-by: Trond Myklebust
    Tested-by: Jason Tibbitts

    Trond Myklebust
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

31 Jan, 2017

3 commits


28 Sep, 2016

1 commit

  • As described in RFC5661, section 18.46, some of the status flags exist
    in order to tell the client when it needs to acknowledge the existence of
    revoked state on the server and/or to recover state.
    Those flags will then remain set until the recovery procedure is done.

    In order to avoid looping, the client therefore needs to ignore
    those particular flags while recovering.

    Signed-off-by: Trond Myklebust
    Tested-by: Oleg Drokin
    Signed-off-by: Anna Schumaker

    Trond Myklebust
     

20 Sep, 2016

1 commit


29 Aug, 2016

3 commits


25 Jan, 2016

1 commit


04 Mar, 2015

1 commit


19 Feb, 2015

1 commit


02 Feb, 2014

1 commit


05 Sep, 2013

1 commit

  • linux/fs/nfs/nfs4session.c:337:6: warning:
    symbol 'nfs41_set_target_slotid' was not declared. Should it be static?

    Move nfs41_set_target_slotid() and nfs41_update_target_slotid() back
    behind CONFIG_NFS_V4_1, since, in the final revision of this work,
    they are used only in NFSv4.1 and later.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

04 Sep, 2013

3 commits


22 Aug, 2013

1 commit


08 Aug, 2013

1 commit

  • Increase NFS4_DEF_SLOT_TABLE_SIZE which is used as the client ca_maxreequests
    value in CREATE_SESSION. Current non-dynamic session slot server
    implementations use the client ca_maxrequests as a maximum slot number: 64
    session slots can handle most workloads.

    Signed-off-by: Andy Adamson
    Signed-off-by: Trond Myklebust

    Andy Adamson
     

29 Jun, 2013

1 commit

  • nfs4_init_session was originally written to be called prior to
    nfs4_init_channel_attrs, setting the session target_max response and request
    sizes that nfs4_init_channel_attrs would pay attention to.

    In the current code flow, nfs4_init_session, just like nfs4_init_ds_session
    for the data server case, is called after the session is all negotiated, and
    is actually used in a RECLAIM COMPLETE call to the server.

    Remove the un-needed fc_target_max response and request fields from
    nfs4_session and just set the max_resp_sz and max_rqst_sz in
    nfs4_init_channel_attrs.

    Signed-off-by: Andy Adamson
    Signed-off-by: Trond Myklebust

    Andy Adamson
     

21 May, 2013

1 commit

  • On a CB_RECALL the callback service thread flushes the inode using
    filemap_flush prior to scheduling the state manager thread to return the
    delegation. When pNFS is used and I/O has not yet gone to the data server
    servicing the inode, a LAYOUTGET can preceed the I/O. Unlike the async
    filemap_flush call, the LAYOUTGET must proceed to completion.

    If the state manager starts to recover data while the inode flush is sending
    the LAYOUTGET, a deadlock occurs as the callback service thread holds the
    single callback session slot until the flushing is done which blocks the state
    manager thread, and the state manager thread has set the session draining bit
    which puts the inode flush LAYOUTGET RPC to sleep on the forechannel slot
    table waitq.

    Separate the draining of the back channel from the draining of the fore channel
    by moving the NFS4_SESSION_DRAINING bit from session scope into the fore
    and back slot tables. Drain the back channel first allowing the LAYOUTGET
    call to proceed (and fail) so the callback service thread frees the callback
    slot. Then proceed with draining the forechannel.

    Signed-off-by: Andy Adamson
    Signed-off-by: Trond Myklebust

    Andy Adamson
     

16 Dec, 2012

2 commits


06 Dec, 2012

5 commits