1. 08 Jun, 2018 1 commit
    • Mike Kravetz's avatar
      mm: restructure memfd code · 5d752600
      Mike Kravetz authored
      With the addition of memfd hugetlbfs support, we now have the situation
      where memfd depends on TMPFS -or- HUGETLBFS.  Previously, memfd was only
      supported on tmpfs, so it made sense that the code resided in shmem.c.
      In the current code, memfd is only functional if TMPFS is defined.  If
      HUGETLFS is defined and TMPFS is not defined, then memfd functionality
      will not be available for hugetlbfs.  This does not cause BUGs, just a
      lack of potentially desired functionality.
      
      Code is restructured in the following way:
      - include/linux/memfd.h is a new file containing memfd specific
        definitions previously contained in shmem_fs.h.
      - mm/memfd.c is a new file containing memfd specific code previously
        contained in shmem.c.
      - memfd specific code is removed from shmem_fs.h and shmem.c.
      - A new config option MEMFD_CREATE is added that is defined if TMPFS
        or HUGETLBFS is defined.
      
      No functional changes are made to the code: restructuring only.
      
      Link: http://lkml.kernel.org/r/20180415182119.4517-4-mike.kravetz@oracle.comSigned-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reviewed-by: default avatarKhalid Aziz <khalid.aziz@oracle.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Marc-Andr Lureau <marcandre.lureau@gmail.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5d752600
  2. 01 May, 2018 1 commit
    • Kirill Tkhai's avatar
      fasync: Fix deadlock between task-context and interrupt-context kill_fasync() · 7a107c0f
      Kirill Tkhai authored
      I observed the following deadlock between them:
      
      [task 1]                          [task 2]                         [task 3]
      kill_fasync()                     mm_update_next_owner()           copy_process()
       spin_lock_irqsave(&fa->fa_lock)   read_lock(&tasklist_lock)        write_lock_irq(&tasklist_lock)
        send_sigio()                    <IRQ>                             ...
         read_lock(&fown->lock)         kill_fasync()                     ...
          read_lock(&tasklist_lock)      spin_lock_irqsave(&fa->fa_lock)  ...
      
      Task 1 can't acquire read locked tasklist_lock, since there is
      already task 3 expressed its wish to take the lock exclusive.
      Task 2 holds the read locked lock, but it can't take the spin lock.
      
      Also, there is possible another deadlock (which I haven't observed):
      
      [task 1]                            [task 2]
      f_getown()                          kill_fasync()
       read_lock(&f_own->lock)             spin_lock_irqsave(&fa->fa_lock,)
       <IRQ>                               send_sigio()                     write_lock_irq(&f_own->lock)
        kill_fasync()                       read_lock(&fown->lock)
         spin_lock_irqsave(&fa->fa_lock,)
      
      Actually, we do not need exclusive fa->fa_lock in kill_fasync_rcu(),
      as it guarantees fa->fa_file->f_owner integrity only. It may seem,
      that it used to give a task a small possibility to receive two sequential
      signals, if there are two parallel kill_fasync() callers, and task
      handles the first signal fastly, but the behaviour won't become
      different, since there is exclusive sighand lock in do_send_sig_info().
      
      The patch converts fa_lock into rwlock_t, and this fixes two above
      deadlocks, as rwlock is allowed to be taken from interrupt handler
      by qrwlock design.
      Signed-off-by: default avatarKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      7a107c0f
  3. 02 Apr, 2018 1 commit
  4. 11 Feb, 2018 1 commit
    • Linus Torvalds's avatar
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds authored
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  5. 01 Feb, 2018 2 commits
  6. 12 Jan, 2018 1 commit
    • Eric W. Biederman's avatar
      signal: Ensure generic siginfos the kernel sends have all bits initialized · faf1f22b
      Eric W. Biederman authored
      Call clear_siginfo to ensure stack allocated siginfos are fully
      initialized before being passed to the signal sending functions.
      
      This ensures that if there is the kind of confusion documented by
      TRAP_FIXME, FPE_FIXME, or BUS_FIXME the kernel won't send unitialized
      data to userspace when the kernel generates a signal with SI_USER but
      the copy to userspace assumes it is a different kind of signal, and
      different fields are initialized.
      
      This also prepares the way for turning copy_siginfo_to_user
      into a copy_to_user, by removing the need in many cases to perform
      a field by field copy simply to skip the uninitialized fields.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      faf1f22b
  7. 30 Nov, 2017 1 commit
  8. 28 Nov, 2017 1 commit
  9. 15 Nov, 2017 2 commits
  10. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      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 <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  11. 25 Oct, 2017 1 commit
    • Mark Rutland's avatar
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland authored
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6aa7de05
  12. 19 Sep, 2017 1 commit
  13. 24 Jul, 2017 1 commit
    • Eric W. Biederman's avatar
      fcntl: Don't use ambiguous SIG_POLL si_codes · d08477aa
      Eric W. Biederman authored
      We have a weird and problematic intersection of features that when
      they all come together result in ambiguous siginfo values, that
      we can not support properly.
      
      - Supporting fcntl(F_SETSIG,...) with arbitrary valid signals.
      
      - Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc
        that imply they are signal specific si_codes and using the
        aforementioned arbitrary signal to deliver them.
      
      - Supporting injection of arbitrary siginfo values for debugging and
        checkpoint/restore.
      
      The result is that just looking at siginfo si_codes of 1 to 6 are
      ambigious.  It could either be a signal specific si_code or it could
      be a generic si_code.
      
      For most of the kernel this is a non-issue but for sending signals
      with siginfo it is impossible to play back the kernel signals and
      get the same result.
      
      Strictly speaking when the si_code was changed from SI_SIGIO to
      POLL_IN and friends between 2.2 and 2.4 this functionality was not
      ambiguous, as only real time signals were supported.  Before 2.4 was
      released the kernel began supporting siginfo with non realtime signals
      so they could give details of why the signal was sent.
      
      The result is that if F_SETSIG is set to one of the signals with signal
      specific si_codes then user space can not know why the signal was sent.
      
      I grepped through a bunch of userspace programs using debian code
      search to get a feel for how often people choose a signal that results
      in an ambiguous si_code.  I only found one program doing so and it was
      using SIGCHLD to test the F_SETSIG functionality, and did not appear
      to be a real world usage.
      
      Therefore the ambiguity does not appears to be a real world problem in
      practice.  Remove the ambiguity while introducing the smallest chance
      of breakage by changing the si_code to SI_SIGIO when signals with
      signal specific si_codes are targeted.
      
      Fixes: v2.3.40 -- Added support for queueing non-rt signals
      Fixes: v2.3.21 -- Changed the si_code from SI_SIGIO
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      d08477aa
  14. 07 Jul, 2017 1 commit
    • Linus Torvalds's avatar
      vfs: fix flock compat thinko · b59eea55
      Linus Torvalds authored
      Michael Ellerman reported that commit 8c6657cb ("Switch flock
      copyin/copyout primitives to copy_{from,to}_user()") broke his
      networking on a bunch of PPC machines (64-bit kernel, 32-bit userspace).
      
      The reason is a brown-paper bug by that commit, which had the arguments
      to "copy_flock_fields()" in the wrong order, breaking the compat
      handling for file locking.  Apparently very few people run 32-bit user
      space on x86 any more, so the PPC people got the honor of noticing this
      "feature".
      
      Michael also sent a minimal diff that just changed the order of the
      arguments in that macro.
      
      This is not that minimal diff.
      
      This not only changes the order of the arguments in the macro, it also
      changes them to be pointers (to be consistent with all the other uses of
      those pointers), and makes the functions that do all of this also have
      the proper "const" attribution on the source pointers in order to make
      issues like that (using the source as a destination) be really obvious.
      Reported-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b59eea55
  15. 28 Jun, 2017 1 commit
  16. 27 Jun, 2017 2 commits
    • Jens Axboe's avatar
      fs: add fcntl() interface for setting/getting write life time hints · c75b1d94
      Jens Axboe authored
      Define a set of write life time hints:
      
      RWH_WRITE_LIFE_NOT_SET	No hint information set
      RWH_WRITE_LIFE_NONE	No hints about write life time
      RWH_WRITE_LIFE_SHORT	Data written has a short life time
      RWH_WRITE_LIFE_MEDIUM	Data written has a medium life time
      RWH_WRITE_LIFE_LONG	Data written has a long life time
      RWH_WRITE_LIFE_EXTREME	Data written has an extremely long life time
      
      The intent is for these values to be relative to each other, no
      absolute meaning should be attached to these flag names.
      
      Add an fcntl interface for querying these flags, and also for
      setting them as well:
      
      F_GET_RW_HINT		Returns the read/write hint set on the
      			underlying inode.
      
      F_SET_RW_HINT		Set one of the above write hints on the
      			underlying inode.
      
      F_GET_FILE_RW_HINT	Returns the read/write hint set on the
      			file descriptor.
      
      F_SET_FILE_RW_HINT	Set one of the above write hints on the
      			file descriptor.
      
      The user passes in a 64-bit pointer to get/set these values, and
      the interface returns 0/-1 on success/error.
      
      Sample program testing/implementing basic setting/getting of write
      hints is below.
      
      Add support for storing the write life time hint in the inode flags
      and in struct file as well, and pass them to the kiocb flags. If
      both a file and its corresponding inode has a write hint, then we
      use the one in the file, if available. The file hint can be used
      for sync/direct IO, for buffered writeback only the inode hint
      is available.
      
      This is in preparation for utilizing these hints in the block layer,
      to guide on-media data placement.
      
      /*
       * writehint.c: get or set an inode write hint
       */
       #include <stdio.h>
       #include <fcntl.h>
       #include <stdlib.h>
       #include <unistd.h>
       #include <stdbool.h>
       #include <inttypes.h>
      
       #ifndef F_GET_RW_HINT
       #define F_LINUX_SPECIFIC_BASE	1024
       #define F_GET_RW_HINT		(F_LINUX_SPECIFIC_BASE + 11)
       #define F_SET_RW_HINT		(F_LINUX_SPECIFIC_BASE + 12)
       #endif
      
      static char *str[] = { "RWF_WRITE_LIFE_NOT_SET", "RWH_WRITE_LIFE_NONE",
      			"RWH_WRITE_LIFE_SHORT", "RWH_WRITE_LIFE_MEDIUM",
      			"RWH_WRITE_LIFE_LONG", "RWH_WRITE_LIFE_EXTREME" };
      
      int main(int argc, char *argv[])
      {
      	uint64_t hint;
      	int fd, ret;
      
      	if (argc < 2) {
      		fprintf(stderr, "%s: file <hint>\n", argv[0]);
      		return 1;
      	}
      
      	fd = open(argv[1], O_RDONLY);
      	if (fd < 0) {
      		perror("open");
      		return 2;
      	}
      
      	if (argc > 2) {
      		hint = atoi(argv[2]);
      		ret = fcntl(fd, F_SET_RW_HINT, &hint);
      		if (ret < 0) {
      			perror("fcntl: F_SET_RW_HINT");
      			return 4;
      		}
      	}
      
      	ret = fcntl(fd, F_GET_RW_HINT, &hint);
      	if (ret < 0) {
      		perror("fcntl: F_GET_RW_HINT");
      		return 3;
      	}
      
      	printf("%s: hint %s\n", argv[1], str[hint]);
      	close(fd);
      	return 0;
      }
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      c75b1d94
    • Al Viro's avatar
      Switch flock copyin/copyout primitives to copy_{from,to}_user() · 8c6657cb
      Al Viro authored
      ... and lose HAVE_ARCH_...; if copy_{to,from}_user() on an
      architecture sucks badly enough to make it a problem, we have
      a worse problem.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      8c6657cb
  17. 14 Jun, 2017 3 commits
    • Jeff Layton's avatar
      fs/fcntl: return -ESRCH in f_setown when pid/pgid can't be found · f7312735
      Jeff Layton authored
      The current implementation of F_SETOWN doesn't properly vet the argument
      passed in and only returns an error if INT_MIN is passed in. If the
      argument doesn't specify a valid pid/pgid, then we just end up cleaning
      out the file->f_owner structure.
      
      What we really want is to only clean that out only in the case where
      userland passed in an argument of 0. For anything else, we want to
      return ESRCH if it doesn't refer to a valid pid.
      
      The relevant POSIX spec page is here:
      
          http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
      
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: zhong jiang <zhongjiang@huawei.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      f7312735
    • Jiri Slaby's avatar
      fs/fcntl: f_setown, avoid undefined behaviour · fc3dc674
      Jiri Slaby authored
      fcntl(0, F_SETOWN, 0x80000000) triggers:
      UBSAN: Undefined behaviour in fs/fcntl.c:118:7
      negation of -2147483648 cannot be represented in type 'int':
      CPU: 1 PID: 18261 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1
      ...
      Call Trace:
      ...
       [<ffffffffad8f0868>] ? f_setown+0x1d8/0x200
       [<ffffffffad8f19a9>] ? SyS_fcntl+0x999/0xf30
       [<ffffffffaed1fb00>] ? entry_SYSCALL_64_fastpath+0x23/0xc1
      
      Fix that by checking the arg parameter properly (against INT_MAX) before
      "who = -who". And return immediatelly with -EINVAL in case it is wrong.
      Note that according to POSIX we can return EINVAL:
          http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
      
          [EINVAL]
              The cmd argument is F_SETOWN and the value of the argument
              is not valid as a process or process group identifier.
      
      [v2] returns an error, v1 used to fail silently
      [v3] implement proper check for the bad value INT_MIN
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Jeff Layton <jlayton@poochiereds.net>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      fc3dc674
    • Jiri Slaby's avatar
      fs/fcntl: f_setown, allow returning error · 393cc3f5
      Jiri Slaby authored
      Allow f_setown to return an error value. We will fail in the next patch
      with EINVAL for bad input to f_setown, so tile the path for the later
      patch.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Cc: Jeff Layton <jlayton@poochiereds.net>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      393cc3f5
  18. 01 Jun, 2017 1 commit
  19. 27 May, 2017 1 commit
  20. 27 Apr, 2017 1 commit
  21. 17 Apr, 2017 1 commit
  22. 02 Mar, 2017 1 commit
  23. 24 Dec, 2016 1 commit
  24. 04 Dec, 2016 1 commit
  25. 09 Jan, 2016 1 commit
  26. 08 Jan, 2015 1 commit
    • David Drysdale's avatar
      vfs: renumber FMODE_NONOTIFY and add to uniqueness check · 75069f2b
      David Drysdale authored
      Fix clashing values for O_PATH and FMODE_NONOTIFY on sparc.  The
      clashing O_PATH value was added in commit 5229645b ("vfs: add
      nonconflicting values for O_PATH") but this can't be changed as it is
      user-visible.
      
      FMODE_NONOTIFY is only used internally in the kernel, but it is in the
      same numbering space as the other O_* flags, as indicated by the comment
      at the top of include/uapi/asm-generic/fcntl.h (and its use in
      fs/notify/fanotify/fanotify_user.c).  So renumber it to avoid the clash.
      
      All of this has happened before (commit 12ed2e36: "fanotify:
      FMODE_NONOTIFY and __O_SYNC in sparc conflict"), and all of this will
      happen again -- so update the uniqueness check in fcntl_init() to
      include __FMODE_NONOTIFY.
      Signed-off-by: default avatarDavid Drysdale <drysdale@google.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Eric Paris <eparis@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      75069f2b
  27. 09 Sep, 2014 1 commit
  28. 08 Aug, 2014 1 commit
    • David Herrmann's avatar
      shm: add sealing API · 40e041a2
      David Herrmann authored
      If two processes share a common memory region, they usually want some
      guarantees to allow safe access. This often includes:
        - one side cannot overwrite data while the other reads it
        - one side cannot shrink the buffer while the other accesses it
        - one side cannot grow the buffer beyond previously set boundaries
      
      If there is a trust-relationship between both parties, there is no need
      for policy enforcement.  However, if there's no trust relationship (eg.,
      for general-purpose IPC) sharing memory-regions is highly fragile and
      often not possible without local copies.  Look at the following two
      use-cases:
      
        1) A graphics client wants to share its rendering-buffer with a
           graphics-server. The memory-region is allocated by the client for
           read/write access and a second FD is passed to the server. While
           scanning out from the memory region, the server has no guarantee that
           the client doesn't shrink the buffer at any time, requiring rather
           cumbersome SIGBUS handling.
        2) A process wants to perform an RPC on another process. To avoid huge
           bandwidth consumption, zero-copy is preferred. After a message is
           assembled in-memory and a FD is passed to the remote side, both sides
           want to be sure that neither modifies this shared copy, anymore. The
           source may have put sensible data into the message without a separate
           copy and the target may want to parse the message inline, to avoid a
           local copy.
      
      While SIGBUS handling, POSIX mandatory locking and MAP_DENYWRITE provide
      ways to achieve most of this, the first one is unproportionally ugly to
      use in libraries and the latter two are broken/racy or even disabled due
      to denial of service attacks.
      
      This patch introduces the concept of SEALING.  If you seal a file, a
      specific set of operations is blocked on that file forever.  Unlike locks,
      seals can only be set, never removed.  Hence, once you verified a specific
      set of seals is set, you're guaranteed that no-one can perform the blocked
      operations on this file, anymore.
      
      An initial set of SEALS is introduced by this patch:
        - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced
                  in size. This affects ftruncate() and open(O_TRUNC).
        - GROW: If SEAL_GROW is set, the file in question cannot be increased
                in size. This affects ftruncate(), fallocate() and write().
        - WRITE: If SEAL_WRITE is set, no write operations (besides resizing)
                 are possible. This affects fallocate(PUNCH_HOLE), mmap() and
                 write().
        - SEAL: If SEAL_SEAL is set, no further seals can be added to a file.
                This basically prevents the F_ADD_SEAL operation on a file and
                can be set to prevent others from adding further seals that you
                don't want.
      
      The described use-cases can easily use these seals to provide safe use
      without any trust-relationship:
      
        1) The graphics server can verify that a passed file-descriptor has
           SEAL_SHRINK set. This allows safe scanout, while the client is
           allowed to increase buffer size for window-resizing on-the-fly.
           Concurrent writes are explicitly allowed.
        2) For general-purpose IPC, both processes can verify that SEAL_SHRINK,
           SEAL_GROW and SEAL_WRITE are set. This guarantees that neither
           process can modify the data while the other side parses it.
           Furthermore, it guarantees that even with writable FDs passed to the
           peer, it cannot increase the size to hit memory-limits of the source
           process (in case the file-storage is accounted to the source).
      
      The new API is an extension to fcntl(), adding two new commands:
        F_GET_SEALS: Return a bitset describing the seals on the file. This
                     can be called on any FD if the underlying file supports
                     sealing.
        F_ADD_SEALS: Change the seals of a given file. This requires WRITE
                     access to the file and F_SEAL_SEAL may not already be set.
                     Furthermore, the underlying file must support sealing and
                     there may not be any existing shared mapping of that file.
                     Otherwise, EBADF/EPERM is returned.
                     The given seals are _added_ to the existing set of seals
                     on the file. You cannot remove seals again.
      
      The fcntl() handler is currently specific to shmem and disabled on all
      files. A file needs to explicitly support sealing for this interface to
      work. A separate syscall is added in a follow-up, which creates files that
      support sealing. There is no intention to support this on other
      file-systems. Semantics are unclear for non-volatile files and we lack any
      use-case right now. Therefore, the implementation is specific to shmem.
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Ryan Lortie <desrt@desrt.ca>
      Cc: Lennart Poettering <lennart@poettering.net>
      Cc: Daniel Mack <zonque@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      40e041a2
  29. 22 Apr, 2014 1 commit
    • Jeff Layton's avatar
      locks: rename file-private locks to "open file description locks" · 0d3f7a2d
      Jeff Layton authored
      File-private locks have been merged into Linux for v3.15, and *now*
      people are commenting that the name and macro definitions for the new
      file-private locks suck.
      
      ...and I can't even disagree. The names and command macros do suck.
      
      We're going to have to live with these for a long time, so it's
      important that we be happy with the names before we're stuck with them.
      The consensus on the lists so far is that they should be rechristened as
      "open file description locks".
      
      The name isn't a big deal for the kernel, but the command macros are not
      visually distinct enough from the traditional POSIX lock macros. The
      glibc and documentation folks are recommending that we change them to
      look like F_OFD_{GETLK|SETLK|SETLKW}. That lessens the chance that a
      programmer will typo one of the commands wrong, and also makes it easier
      to spot this difference when reading code.
      
      This patch makes the following changes that I think are necessary before
      v3.15 ships:
      
      1) rename the command macros to their new names. These end up in the uapi
         headers and so are part of the external-facing API. It turns out that
         glibc doesn't actually use the fcntl.h uapi header, but it's hard to
         be sure that something else won't. Changing it now is safest.
      
      2) make the the /proc/locks output display these as type "OFDLCK"
      
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Carlos O'Donell <carlos@redhat.com>
      Cc: Stefan Metzmacher <metze@samba.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Frank Filz <ffilzlnx@mindspring.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      0d3f7a2d
  30. 31 Mar, 2014 2 commits
    • Jeff Layton's avatar
      locks: add new fcntl cmd values for handling file private locks · 5d50ffd7
      Jeff Layton authored
      Due to some unfortunate history, POSIX locks have very strange and
      unhelpful semantics. The thing that usually catches people by surprise
      is that they are dropped whenever the process closes any file descriptor
      associated with the inode.
      
      This is extremely problematic for people developing file servers that
      need to implement byte-range locks. Developers often need a "lock
      management" facility to ensure that file descriptors are not closed
      until all of the locks associated with the inode are finished.
      
      Additionally, "classic" POSIX locks are owned by the process. Locks
      taken between threads within the same process won't conflict with one
      another, which renders them useless for synchronization between threads.
      
      This patchset adds a new type of lock that attempts to address these
      issues. These locks conflict with classic POSIX read/write locks, but
      have semantics that are more like BSD locks with respect to inheritance
      and behavior on close.
      
      This is implemented primarily by changing how fl_owner field is set for
      these locks. Instead of having them owned by the files_struct of the
      process, they are instead owned by the filp on which they were acquired.
      Thus, they are inherited across fork() and are only released when the
      last reference to a filp is put.
      
      These new semantics prevent them from being merged with classic POSIX
      locks, even if they are acquired by the same process. These locks will
      also conflict with classic POSIX locks even if they are acquired by
      the same process or on the same file descriptor.
      
      The new locks are managed using a new set of cmd values to the fcntl()
      syscall. The initial implementation of this converts these values to
      "classic" cmd values at a fairly high level, and the details are not
      exposed to the underlying filesystem. We may eventually want to push
      this handing out to the lower filesystem code but for now I don't
      see any need for it.
      
      Also, note that with this implementation the new cmd values are only
      available via fcntl64() on 32-bit arches. There's little need to
      add support for legacy apps on a new interface like this.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      5d50ffd7
    • Jeff Layton's avatar
      locks: pass the cmd value to fcntl_getlk/getlk64 · c1e62b8f
      Jeff Layton authored
      Once we introduce file private locks, we'll need to know what cmd value
      was used, as that affects the ownership and whether a conflict would
      arise.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      c1e62b8f
  31. 25 Oct, 2013 1 commit
  32. 05 Aug, 2013 1 commit
  33. 23 Feb, 2013 1 commit
  34. 09 Oct, 2012 1 commit