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
     

15 Sep, 2017

3 commits

  • MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 8bit

    The script “checkpatch.pl” pointed information out like the following.

    Comparison to NULL could be written !…

    Thus fix affected source code places.

    Signed-off-by: Markus Elfring
    Signed-off-by: Mike Marshall

    Markus Elfring
     
  • The xattr_handler structure is only stored in an array of const
    structures. Thus the xattr_handler structure itself can be
    const.

    Signed-off-by: Julia Lawall
    Signed-off-by: Mike Marshall

    Julia Lawall
     
  • A previous patch which claimed to remove off by ones actually introduced
    them.

    strlen() returns the length of the string not including the NUL
    character. We are using strcpy() to copy "name" into a buffer which is
    ORANGEFS_MAX_XATTR_NAMELEN characters long. We should make sure to
    leave space for the NUL, otherwise we're writing one character beyond
    the end of the buffer.

    Fixes: e675c5ec51fe ("orangefs: clean up oversize xattr validation")
    Signed-off-by: Dan Carpenter
    Signed-off-by: Mike Marshall

    Dan Carpenter
     

27 Apr, 2017

2 commits


08 Oct, 2016

1 commit

  • All filesystems that support xattrs by now do so via xattr handlers.
    They all define sb->s_xattr, and their getxattr, setxattr, and
    removexattr inode operations use the generic inode operations. On
    filesystems that don't support xattrs, the xattr inode operations are
    all NULL, and sb->s_xattr is also NULL.

    This means that we can remove the getxattr, setxattr, and removexattr
    inode operations and directly call the generic handlers, or better,
    inline expand those handlers into fs/xattr.c.

    Filesystems that do not support xattrs on some inodes should clear the
    IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
    have checks to disable xattrs on some inodes in the ->list, ->get, and
    ->set xattr handler operations instead.) The IOP_XATTR flag is
    automatically cleared in inodes of filesystems that don't have xattr
    support.

    In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
    check for symlinks to orangefs_inode_getxattr to preserve the current,
    weird behavior; that check may not be necessary though.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     

06 Jul, 2016

4 commits

  • In orangefs_inode_getxattr(), an fsuid is written to dmesg. The kuid is
    converted to a userspace uid via from_kuid(current_user_ns(), [...]), but
    since dmesg is global, init_user_ns should be used here instead.

    In copy_attributes_from_inode(), op_alloc() and fill_default_sys_attrs(),
    upcall structures are populated with uids/gids that have been mapped into
    the caller's namespace. However, those upcall structures are read by
    another process (the userspace filesystem driver), and that process might
    be running in another namespace. This effectively lets any user spoof its
    uid and gid as seen by the userspace filesystem driver.

    To fix the second issue, I just construct the opcall structures with
    init_user_ns uids/gids and require the filesystem server to run in the
    init namespace. Since orangefs is full of global state anyway (as the error
    message in DUMP_DEVICE_ERROR explains, there can only be one userspace
    orangefs filesystem driver at once), that shouldn't be a problem.

    [
    Why does orangefs even exist in the kernel if everything does upcalls into
    userspace? What does orangefs do that couldn't be done with the FUSE
    interface? If there is no good answer to those questions, I'd prefer to see
    orangefs kicked out of the kernel. Can that be done for something that
    shipped in a release?

    According to commit f7ab093f74bf ("Orangefs: kernel client part 1"), they
    even already have a FUSE daemon, and the only rational reason (apart from
    "but most of our users report preferring to use our kernel module instead")
    given for not wanting to use FUSE is one "in-the-works" feature that could
    probably be integated into FUSE instead.
    ]

    This patch has been compile-tested.

    Signed-off-by: Jann Horn
    Signed-off-by: Mike Marshall

    Jann Horn
     
  • Mike,

    On Fri, Jun 3, 2016 at 9:44 PM, Mike Marshall wrote:
    > We use the return value in this one line you changed, our userspace code gets
    > ill when we send it (-ENOMEM +1) as a key length...

    ah, my mistake. Here's a fixed version.

    Thanks,
    Andreas

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Mike Marshall

    Andreas Gruenbacher
     
  • Orangefs has a catch-all xattr handler that effectively does what the
    trusted handler does already.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Mike Marshall

    Andreas Gruenbacher
     
  • The ORANGEFS_XATTR_INDEX_ defines are unused; the ORANGEFS_XATTR_NAME_
    defines only obfuscate the code.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Mike Marshall

    Andreas Gruenbacher
     

28 May, 2016

1 commit


03 May, 2016

1 commit


11 Apr, 2016

1 commit


09 Apr, 2016

2 commits

  • Suggested by David Binderman
    The former can potentially be a performance win over the latter.

    memcpy(d, s, len);
    memset(d+len, c, size-len);

    memset(d, c, size);
    memcpy(d, s, len);

    Signed-off-by: Mike Marshall

    Mike Marshall
     
  • 1. It is nonsense to test for negative size_t, suggested by
    David Binderman

    2. By the time Orangefs gets called, the vfs has ensured that
    name != NULL, and that buffer and size are sane.

    Signed-off-by: Mike Marshall

    Mike Marshall
     

18 Mar, 2016

2 commits


18 Dec, 2015

1 commit


05 Dec, 2015

1 commit


04 Dec, 2015

1 commit

  • OrangeFS was formerly known as PVFS2 and retains the name in many places.

    I leave the device /dev/pvfs2-req since this affects userspace.

    I leave the filesystem type pvfs2 since this affects userspace. Further
    the OrangeFS sysint library reads fstab for an entry of type pvfs2
    independently of kernel mounts.

    I leave extended attribute keys user.pvfs2 and system.pvfs2 as the
    sysint library understands these.

    I leave references to userspace binaries still named pvfs2.

    I leave the filenames.

    Signed-off-by: Yi Liu
    [martin@omnibond.com: clairify above constraints and merge]
    Signed-off-by: Martin Brandenburg
    Signed-off-by: Mike Marshall

    Yi Liu
     

17 Nov, 2015

1 commit

  • On Wed, Nov 11, 2015 at 10:19:48AM +0000, Al Viro wrote:

    > I'll cook the minimal fixup for API change after I get some sleep and
    > send it your way, unless somebody gets there first...

    This should do it - switches ->ioctl() to pvfs2_inode_[gs]etxattr() and
    converts xattr_handler ->[gs]et() to new API.

    Signed-off-by: Al Viro
    Signed-off-by: Mike Marshall

    Al Viro
     

03 Oct, 2015

2 commits