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
     

05 Jun, 2017

1 commit


01 Feb, 2017

1 commit

  • Currently turning on NFSv4.2 results in 4.2 clients suddenly seeing the
    individual file labels as they're set on the server. This is not what
    they've previously seen, and not appropriate in may cases. (In
    particular, if clients have heterogenous security policies then one
    client's labels may not even make sense to another.) Labeled NFS should
    be opted in only in those cases when the administrator knows it makes
    sense.

    It's helpful to be able to turn 4.2 on by default, and otherwise the
    protocol upgrade seems free of regressions. So, default labeled NFS to
    off and provide an export flag to reenable it.

    Users wanting labeled NFS support on an export will henceforth need to:

    - make sure 4.2 support is enabled on client and server (as
    before), and
    - upgrade the server nfs-utils to a version supporting the new
    "security_label" export flag.
    - set that "security_label" flag on the export.

    This is commit may be seen as a regression to anyone currently depending
    on security labels. We believe those cases are currently rare.

    Reported-by: tibbs@math.uh.edu
    Signed-off-by: J. Bruce Fields

    J. Bruce Fields
     

16 Jul, 2016

1 commit

  • If the underlying filesystem supports multiple layout types, then there
    is little reason not to advertise that fact to clients and let them
    choose what type to use.

    Turn the ex_layout_type field into a bitfield. For each supported
    layout type, we set a bit in that field. When the client requests a
    layout, ensure that the bit for that layout type is set. When the
    client requests attributes, send back a list of supported types.

    Signed-off-by: Jeff Layton
    Reviewed-by: Weston Andros Adamson
    Signed-off-by: J. Bruce Fields

    Jeff Layton
     

14 Jul, 2016

1 commit

  • This addresses the conundrum referenced in RFC5661 18.35.3,
    and will allow clients to return state to the server using the
    machine credentials.

    The biggest part of the problem is that we need to allow the client
    to send a compound op with integrity/privacy on mounts that don't
    have it enabled.

    Add server support for properly decoding and using spo_must_enforce
    and spo_must_allow bits. Add support for machine credentials to be
    used for CLOSE, OPEN_DOWNGRADE, LOCKU, DELEGRETURN,
    and TEST/FREE STATEID.
    Implement a check so as to not throw WRONGSEC errors when these
    operations are used if integrity/privacy isn't turned on.

    Without this, Linux clients with credentials that expired while holding
    delegations were getting stuck in an endless loop.

    Signed-off-by: Andrew Elble
    Reviewed-by: Jeff Layton
    Signed-off-by: J. Bruce Fields

    Andrew Elble
     

13 Aug, 2015

1 commit


27 Apr, 2015

1 commit

  • Pull fourth vfs update from Al Viro:
    "d_inode() annotations from David Howells (sat in for-next since before
    the beginning of merge window) + four assorted fixes"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    RCU pathwalk breakage when running into a symlink overmounting something
    fix I_DIO_WAKEUP definition
    direct-io: only inc/dec inode->i_dio_count for file systems
    fs/9p: fix readdir()
    VFS: assorted d_backing_inode() annotations
    VFS: fs/inode.c helpers: d_inode() annotations
    VFS: fs/cachefiles: d_backing_inode() annotations
    VFS: fs library helpers: d_inode() annotations
    VFS: assorted weird filesystems: d_inode() annotations
    VFS: normal filesystems (and lustre): d_inode() annotations
    VFS: security/: d_inode() annotations
    VFS: security/: d_backing_inode() annotations
    VFS: net/: d_inode() annotations
    VFS: net/unix: d_backing_inode() annotations
    VFS: kernel/: d_inode() annotations
    VFS: audit: d_backing_inode() annotations
    VFS: Fix up some ->d_inode accesses in the chelsio driver
    VFS: Cachefiles should perform fs modifications on the top layer only
    VFS: AF_UNIX sockets should call mknod on the top layer only

    Linus Torvalds
     

16 Apr, 2015

1 commit


03 Apr, 2015

1 commit


01 Apr, 2015

1 commit


03 Feb, 2015

1 commit

  • Add support for the GETDEVICEINFO, LAYOUTGET, LAYOUTCOMMIT and
    LAYOUTRETURN NFSv4.1 operations, as well as backing code to manage
    outstanding layouts and devices.

    Layout management is very straight forward, with a nfs4_layout_stateid
    structure that extends nfs4_stid to manage layout stateids as the
    top-level structure. It is linked into the nfs4_file and nfs4_client
    structures like the other stateids, and contains a linked list of
    layouts that hang of the stateid. The actual layout operations are
    implemented in layout drivers that are not part of this commit, but
    will be added later.

    The worst part of this commit is the management of the pNFS device IDs,
    which suffers from a specification that is not sanely implementable due
    to the fact that the device-IDs are global and not bound to an export,
    and have a small enough size so that we can't store the fsid portion of
    a file handle, and must never be reused. As we still do need perform all
    export authentication and validation checks on a device ID passed to
    GETDEVICEINFO we are caught between a rock and a hard place. To work
    around this issue we add a new hash that maps from a 64-bit integer to a
    fsid so that we can look up the export to authenticate against it,
    a 32-bit integer as a generation that we can bump when changing the device,
    and a currently unused 32-bit integer that could be used in the future
    to handle more than a single device per export. Entries in this hash
    table are never deleted as we can't reuse the ids anyway, and would have
    a severe lifetime problem anyway as Linux export structures are temporary
    structures that can go away under load.

    Parts of the XDR data, structures and marshaling/unmarshaling code, as
    well as many concepts are derived from the old pNFS server implementation
    from Andy Adamson, Benny Halevy, Dean Hildebrand, Marc Eshel, Fred Isaman,
    Mike Sager, Ricardo Labiaga and many others.

    Signed-off-by: Christoph Hellwig

    Christoph Hellwig
     

19 Aug, 2014

1 commit

  • One of our customer's application only needs file names, not file
    attributes. With directories having 10K+ inodes (assuming buffer cache
    has directory blocks cached having file names, but inode cache is
    limited and hence need eviction of older cached inodes), older inodes
    are evicted periodically. So if they keep on doing readdir(2) from NSF
    client on multiple directories, some directory's files are periodically
    removed from inode cache and hence new readdir(2) on same directory
    requires disk access to bring back inodes again to inode cache.

    As READDIRPLUS request fetches attributes also, doing getattr on each
    file on server, it causes unnecessary disk accesses. If READDIRPLUS on
    NFS client is returned with -ENOTSUPP, NFS client uses READDIR request
    which just gets the names of the files in a directory, not attributes,
    hence avoiding disk accesses on server.

    There's already a corresponding client-side mount option, but an export
    option reduces the need for configuration across multiple clients.

    This flag affects NFSv3 only. If it turns out it's needed for NFSv4 as
    well then we may have to figure out how to extend the behavior to NFSv4,
    but it's not currently obvious how to do that.

    Signed-off-by: Rajesh Ghanekar
    Signed-off-by: J. Bruce Fields

    Rajesh Ghanekar
     

23 Jun, 2014

2 commits


31 May, 2014

8 commits


30 Oct, 2013

2 commits

  • If we're going to refuse to accept these it would be polite of us to at
    least say so....

    This introduces a slight complication since we need to grandfather in
    exportfs's ill-advised use of -1 uid and gid on its test_export.

    If it turns out there are other users passing down -1 we may need to
    do something else.

    Best might be to drop the checks entirely, but I'm not sure if other
    parts of the kernel might assume that a task can't run as uid or gid -1.

    Cc: "Eric W. Biederman"
    Signed-off-by: J. Bruce Fields

    J. Bruce Fields
     
  • Someone noticed exportfs happily accepted exports that would later be
    rejected when mountd tried to give them to the kernel. Fix this.

    This is a regression from 4c1e1b34d5c800ad3ac9a7e2805b0bea70ad2278
    "nfsd: Store ex_anon_uid and ex_anon_gid as kuids and kgids".

    Cc: "Eric W. Biederman"
    Cc: stable@vger.kernel.org
    Reported-by: Yin.JianHong
    Signed-off-by: J. Bruce Fields

    J. Bruce Fields
     

01 Mar, 2013

1 commit

  • Pull nfsd changes from J Bruce Fields:
    "Miscellaneous bugfixes, plus:

    - An overhaul of the DRC cache by Jeff Layton. The main effect is
    just to make it larger. This decreases the chances of intermittent
    errors especially in the UDP case. But we'll need to watch for any
    reports of performance regressions.

    - Containerized nfsd: with some limitations, we now support
    per-container nfs-service, thanks to extensive work from Stanislav
    Kinsbursky over the last year."

    Some notes about conflicts, since there were *two* non-data semantic
    conflicts here:

    - idr_remove_all() had been added by a memory leak fix, but has since
    become deprecated since idr_destroy() does it for us now.

    - xs_local_connect() had been added by this branch to make AF_LOCAL
    connections be synchronous, but in the meantime Trond had changed the
    calling convention in order to avoid a RCU dereference.

    There were a couple of more obvious actual source-level conflicts due to
    the hlist traversal changes and one just due to code changes next to
    each other, but those were trivial.

    * 'for-3.9' of git://linux-nfs.org/~bfields/linux: (49 commits)
    SUNRPC: make AF_LOCAL connect synchronous
    nfsd: fix compiler warning about ambiguous types in nfsd_cache_csum
    svcrpc: fix rpc server shutdown races
    svcrpc: make svc_age_temp_xprts enqueue under sv_lock
    lockd: nlmclnt_reclaim(): avoid stack overflow
    nfsd: enable NFSv4 state in containers
    nfsd: disable usermode helper client tracker in container
    nfsd: use proper net while reading "exports" file
    nfsd: containerize NFSd filesystem
    nfsd: fix comments on nfsd_cache_lookup
    SUNRPC: move cache_detail->cache_request callback call to cache_read()
    SUNRPC: remove "cache_request" argument in sunrpc_cache_pipe_upcall() function
    SUNRPC: rework cache upcall logic
    SUNRPC: introduce cache_detail->cache_request callback
    NFS: simplify and clean cache library
    NFS: use SUNRPC cache creation and destruction helper for DNS cache
    nfsd4: free_stid can be static
    nfsd: keep a checksum of the first 256 bytes of request
    sunrpc: trim off trailing checksum before returning decrypted or integrity authenticated buffer
    sunrpc: fix comment in struct xdr_buf definition
    ...

    Linus Torvalds
     

15 Feb, 2013

2 commits

  • For most of SUNRPC caches (except NFS DNS cache) cache_detail->cache_upcall is
    redundant since all that it's implementations are doing is calling
    sunrpc_cache_pipe_upcall() with proper function address argument.
    Cache request function address is now stored on cache_detail structure and
    thus all the code can be simplified.
    Now, for those cache details, which doesn't have cache_upcall callback (the
    only one, which still has is nfs_dns_resolve_template)
    sunrpc_cache_pipe_upcall will be called instead.

    Signed-off-by: Stanislav Kinsbursky
    Signed-off-by: J. Bruce Fields

    Stanislav Kinsbursky
     
  • This callback will allow to simplify upcalls in further patches in this
    series.

    Signed-off-by: Stanislav Kinsbursky
    Signed-off-by: J. Bruce Fields

    Stanislav Kinsbursky
     

13 Feb, 2013

1 commit


04 Feb, 2013

1 commit

  • commit 885c91f7466 in Bruce's tree was causing oopses for me:

    general protection fault: 0000 [#1] SMP
    Modules linked in: nfsd(OF) nfs_acl(OF) auth_rpcgss(OF) lockd(OF) sunrpc(OF) kvm_amd kvm microcode i2c_piix4 virtio_net virtio_balloon cirrus drm_kms_helper ttm drm virtio_blk i2c_core
    CPU 0
    Pid: 564, comm: exportfs Tainted: GF O 3.8.0-0.rc5.git2.1.fc19.x86_64 #1 Bochs Bochs
    RIP: 0010:[] [] kfree+0x49/0x280
    RSP: 0018:ffff88007a3d7c50 EFLAGS: 00010203
    RAX: 01adaf8dadadad80 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000001
    RDX: ffffffff7fffffff RSI: 0000000000000000 RDI: 6b6b6b6b6b6b6b6b
    RBP: ffff88007a3d7c80 R08: 6b6b6b6b6b6b6b6b R09: 0000000000000000
    R10: 0000000000000018 R11: 0000000000000000 R12: ffff88006a117b50
    R13: ffffffffa01a589c R14: ffff8800631b0f50 R15: 01ad998dadadad80
    FS: 00007fcaa3616740(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 00007f5d84b6fdd8 CR3: 0000000064db4000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process exportfs (pid: 564, threadinfo ffff88007a3d6000, task ffff88006af28000)
    Stack:
    ffff88007a3d7c80 ffff88006a117b68 ffff88006a117b50 0000000000000000
    ffff8800631b0f50 ffff88006a117b50 ffff88007a3d7ca0 ffffffffa01a589c
    ffff880036be1148 ffff88007a3d7cf8 ffff88007a3d7e28 ffffffffa01a6a98
    Call Trace:
    [] svc_export_put+0x5c/0x70 [nfsd]
    [] svc_export_parse+0x328/0x7e0 [nfsd]
    [] cache_do_downcall+0x57/0x70 [sunrpc]
    [] cache_downcall+0x7e/0x100 [sunrpc]
    [] cache_write_procfs+0x58/0x90 [sunrpc]
    [] ? cache_downcall+0x100/0x100 [sunrpc]
    [] proc_reg_write+0x75/0xb0
    [] vfs_write+0x9f/0x170
    [] sys_write+0x49/0xa0
    [] system_call_fastpath+0x16/0x1b
    Code: 66 66 66 90 48 83 fb 10 0f 86 c3 00 00 00 48 89 df 49 bf 00 00 00 00 00 ea ff ff e8 f2 12 ea ff 48 c1 e8 0c 48 c1 e0 06 49 01 c7 8b 07 f6 c4 80 0f 85 1d 02 00 00 49 8b 07 a8 80 0f 84 ee 01
    RIP [] kfree+0x49/0x280
    RSP

    I think Majianpeng's patch is correct, but incomplete. In order for it
    to be safe to free the ex_uuid unconditionally in svc_export_put, we
    need to make sure it's initialized to NULL in the init routine.

    Cc: majianpeng
    Signed-off-by: Jeff Layton
    Signed-off-by: J. Bruce Fields

    Jeff Layton
     

30 Jan, 2013

1 commit

  • In func svc_export_parse, the uuid which used kmemdup to alloc will be
    changed in func export_update.So the later kfree don't free this memory.
    And it can't be free in func svc_export_parse because other place still
    used.So put this operation in func svc_export_put.

    Signed-off-by: Jianpeng Ma
    Signed-off-by: J. Bruce Fields

    majianpeng
     

28 Jul, 2012

1 commit


25 Jul, 2012

1 commit


01 Jun, 2012

2 commits


12 Apr, 2012

6 commits