23 May, 2018

1 commit


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
     

09 Nov, 2013

1 commit


14 Jul, 2012

1 commit

  • Just the flags; only NFS cares even about that, but there are
    legitimate uses for such argument. And getting rid of that
    completely would require splitting ->lookup() into a couple
    of methods (at least), so let's leave that alone for now...

    Signed-off-by: Al Viro

    Al Viro
     

21 Mar, 2012

2 commits


22 Oct, 2010

1 commit

  • All uses of the BKL in qnx4 were the result of a pushdown into
    code that doesn't really need it. As Christoph points out, this
    is a read-only file system, which eliminates most of the races in
    readdir/lookup.

    Signed-off-by: Arnd Bergmann
    Acked-by: Anders Larsen
    Cc: Christoph Hellwig

    Arnd Bergmann
     

09 Nov, 2009

1 commit


23 Sep, 2009

1 commit

  • qnx4 wrte support has never been fully implement, is broken since the dawn
    of time and hasn't been actively developed since before git history
    started.

    Instead of letting it further bitrot and complicate API transition (like
    the new truncate code) remove it.

    Signed-off-by: Christoph Hellwig
    Cc: Anders Larsen
    Cc: Nick Piggin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

12 Jun, 2009

2 commits

  • fs-internal parts of qnx4_fs.h taken to fs/qnx4/qnx4.h, includes adjusted,
    qnx4_fs.h doesn't need unifdef anymore.

    Signed-off-by: Al Viro

    Al Viro
     
  • * have directory operations use mark_buffer_dirty_inode(),
    so that sync_mapping_buffers() would get those.
    * make qnx4_write_inode() honour its last argument.
    * get rid of insane copies of very ancient "walk the indirect blocks"
    in qnx4/fsync - they never matched the actual fs layout and, fortunately,
    never'd been called. Again, all this junk is not needed; ->fsync()
    should just do sync_mapping_buffers + sync_inode (and if we implement
    block allocation for qnx4, we'll need to use mark_buffer_dirty_inode()
    for extent blocks)

    Signed-off-by: Al Viro

    Al Viro
     

08 Feb, 2008

1 commit

  • Stop the QNX4 filesystem from using iget() and read_inode(). Replace
    qnx4_read_inode() with qnx4_iget(), and call that instead of iget().
    qnx4_iget() then uses iget_locked() directly and returns a proper error code
    instead of an inode in the event of an error.

    qnx4_fill_super() returns any error incurred when getting the root inode
    instead of EINVAL.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: David Howells
    Cc: Anders Larsen
    Acked-by: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

01 Oct, 2006

2 commits

  • Some filesystems, instead of simply decrementing i_nlink, simply zero it
    during an unlink operation. We need to catch these in addition to the
    decrement operations.

    Signed-off-by: Dave Hansen
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • When a filesystem decrements i_nlink to zero, it means that a write must be
    performed in order to drop the inode from the filesystem.

    We're shortly going to have keep filesystems from being remounted r/o between
    the time that this i_nlink decrement and that write occurs.

    So, add a little helper function to do the decrements. We'll tie into it in a
    bit to note when i_nlink hits zero.

    Signed-off-by: Dave Hansen
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     

01 Jul, 2006

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds