1. 22 10月, 2015 1 次提交
  2. 13 8月, 2015 1 次提交
  3. 28 5月, 2015 1 次提交
    • L
      kernel/params: constify struct kernel_param_ops uses · 9c27847d
      Luis R. Rodriguez 提交于
      Most code already uses consts for the struct kernel_param_ops,
      sweep the kernel for the last offending stragglers. Other than
      include/linux/moduleparam.h and kernel/params.c all other changes
      were generated with the following Coccinelle SmPL patch. Merge
      conflicts between trees can be handled with Coccinelle.
      
      In the future git could get Coccinelle merge support to deal with
      patch --> fail --> grammar --> Coccinelle --> new patch conflicts
      automatically for us on patches where the grammar is available and
      the patch is of high confidence. Consider this a feature request.
      
      Test compiled on x86_64 against:
      
      	* allnoconfig
      	* allmodconfig
      	* allyesconfig
      
      @ const_found @
      identifier ops;
      @@
      
      const struct kernel_param_ops ops = {
      };
      
      @ const_not_found depends on !const_found @
      identifier ops;
      @@
      
      -struct kernel_param_ops ops = {
      +const struct kernel_param_ops ops = {
      };
      
      Generated-by: Coccinelle SmPL
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Junio C Hamano <gitster@pobox.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: cocci@systeme.lip6.fr
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      9c27847d
  4. 24 4月, 2015 1 次提交
  5. 16 4月, 2015 1 次提交
  6. 12 3月, 2015 1 次提交
  7. 06 2月, 2015 1 次提交
  8. 21 1月, 2015 1 次提交
  9. 13 9月, 2014 1 次提交
  10. 05 8月, 2014 1 次提交
  11. 13 7月, 2014 1 次提交
  12. 10 6月, 2014 1 次提交
  13. 30 5月, 2014 1 次提交
  14. 13 3月, 2014 1 次提交
    • T
      fs: push sync_filesystem() down to the file system's remount_fs() · 02b9984d
      Theodore Ts'o 提交于
      Previously, the no-op "mount -o mount /dev/xxx" operation when the
      file system is already mounted read-write causes an implied,
      unconditional syncfs().  This seems pretty stupid, and it's certainly
      documented or guaraunteed to do this, nor is it particularly useful,
      except in the case where the file system was mounted rw and is getting
      remounted read-only.
      
      However, it's possible that there might be some file systems that are
      actually depending on this behavior.  In most file systems, it's
      probably fine to only call sync_filesystem() when transitioning from
      read-write to read-only, and there are some file systems where this is
      not needed at all (for example, for a pseudo-filesystem or something
      like romfs).
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Cc: Jan Kara <jack@suse.cz>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Anders Larsen <al@alarsen.net>
      Cc: Phillip Lougher <phillip@squashfs.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: xfs@oss.sgi.com
      Cc: linux-btrfs@vger.kernel.org
      Cc: linux-cifs@vger.kernel.org
      Cc: samba-technical@lists.samba.org
      Cc: codalist@coda.cs.cmu.edu
      Cc: linux-ext4@vger.kernel.org
      Cc: linux-f2fs-devel@lists.sourceforge.net
      Cc: fuse-devel@lists.sourceforge.net
      Cc: cluster-devel@redhat.com
      Cc: linux-mtd@lists.infradead.org
      Cc: jfs-discussion@lists.sourceforge.net
      Cc: linux-nfs@vger.kernel.org
      Cc: linux-nilfs@vger.kernel.org
      Cc: linux-ntfs-dev@lists.sourceforge.net
      Cc: ocfs2-devel@oss.oracle.com
      Cc: reiserfs-devel@vger.kernel.org
      02b9984d
  15. 16 11月, 2013 1 次提交
  16. 29 10月, 2013 7 次提交
  17. 11 9月, 2013 1 次提交
    • D
      fs: convert fs shrinkers to new scan/count API · 1ab6c499
      Dave Chinner 提交于
      Convert the filesystem shrinkers to use the new API, and standardise some
      of the behaviours of the shrinkers at the same time.  For example,
      nr_to_scan means the number of objects to scan, not the number of objects
      to free.
      
      I refactored the CIFS idmap shrinker a little - it really needs to be
      broken up into a shrinker per tree and keep an item count with the tree
      root so that we don't need to walk the tree every time the shrinker needs
      to count the number of objects in the tree (i.e.  all the time under
      memory pressure).
      
      [glommer@openvz.org: fixes for ext4, ubifs, nfs, cifs and glock. Fixes are needed mainly due to new code merged in the tree]
      [assorted fixes folded in]
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NGlauber Costa <glommer@openvz.org>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Acked-by: NJan Kara <jack@suse.cz>
      Acked-by: NSteven Whitehouse <swhiteho@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: Arve Hjønnevåg <arve@android.com>
      Cc: Carlos Maiolino <cmaiolino@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Chuck Lever <chuck.lever@oracle.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: J. Bruce Fields <bfields@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Kent Overstreet <koverstreet@google.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1ab6c499
  18. 08 9月, 2013 3 次提交
  19. 05 9月, 2013 1 次提交
  20. 08 8月, 2013 2 次提交
  21. 29 6月, 2013 4 次提交
  22. 09 6月, 2013 4 次提交
  23. 31 5月, 2013 1 次提交
    • C
      NFS: Fix security flavor negotiation with legacy binary mounts · eb54d437
      Chuck Lever 提交于
      Darrick J. Wong <darrick.wong@oracle.com> reports:
      > I have a kvm-based testing setup that netboots VMs over NFS, the
      > client end of which seems to have broken somehow in 3.10-rc1.  The
      > server's exports file looks like this:
      >
      > /storage/mtr/x64	192.168.122.0/24(ro,sync,no_root_squash,no_subtree_check)
      >
      > On the client end (inside the VM), the initrd runs the following
      > command to try to mount the rootfs over NFS:
      >
      > # mount -o nolock -o ro -o retrans=10 192.168.122.1:/storage/mtr/x64/ /root
      >
      > (Note: This is the busybox mount command.)
      >
      > The mount fails with -EINVAL.
      
      Commit 4580a92d "NFS: Use server-recommended security flavor by
      default (NFSv3)" introduced a behavior regression for NFS mounts
      done via a legacy binary mount(2) call.
      
      Ensure that a default security flavor is specified for legacy binary
      mount requests, since they do not invoke nfs_select_flavor() in the
      kernel.
      
      Busybox uses klibc's nfsmount command, which performs NFS mounts
      using the legacy binary mount data format.  /sbin/mount.nfs is not
      affected by this regression.
      Reported-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Tested-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Acked-by: NWeston Andros Adamson <dros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      eb54d437
  24. 07 5月, 2013 1 次提交
    • W
      NFSv3: match sec= flavor against server list · d497ab97
      Weston Andros Adamson 提交于
      Older linux clients match the 'sec=' mount option flavor against the server's
      flavor list (if available) and return EPERM if the specified flavor or AUTH_NULL
      (which "matches" any flavor) is not found.
      
      Recent changes skip this step and allow the vfs mount even though no operations
      will succeed, creating a 'dud' mount.
      
      This patch reverts back to the old behavior of matching specified flavors
      against the server list and also returns EPERM when no sec= is specified and
      none of the flavors returned by the server are supported by the client.
      
      Example of behavior change:
      
      the server's /etc/exports:
      
      /export/krb5      *(sec=krb5,rw,no_root_squash)
      
      old client behavior:
      
      $ uname -a
      Linux one.apikia.fake 3.8.8-202.fc18.x86_64 #1 SMP Wed Apr 17 23:25:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
      $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
      mount.nfs: timeout set for Sun May  5 17:32:04 2013
      mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
      mount.nfs: prog 100003, trying vers=3, prot=6
      mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
      mount.nfs: prog 100005, trying vers=3, prot=17
      mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
      mount.nfs: mount(2): Permission denied
      mount.nfs: access denied by server while mounting zero:/export/krb5
      
      recently changed behavior:
      
      $ uname -a
      Linux one.apikia.fake 3.9.0-testing+ #2 SMP Fri May 3 20:29:32 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
      $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
      mount.nfs: timeout set for Sun May  5 17:37:17 2013
      mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
      mount.nfs: prog 100003, trying vers=3, prot=6
      mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
      mount.nfs: prog 100005, trying vers=3, prot=17
      mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
      $ ls /mnt
      ls: cannot open directory /mnt: Permission denied
      $ sudo ls /mnt
      ls: cannot open directory /mnt: Permission denied
      $ sudo df /mnt
      df: ‘/mnt’: Permission denied
      df: no file systems processed
      $ sudo umount /mnt
      $
      Signed-off-by: NWeston Andros Adamson <dros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      d497ab97
  25. 05 4月, 2013 1 次提交
    • C
      NFS: Use server-recommended security flavor by default (NFSv3) · 4580a92d
      Chuck Lever 提交于
      Since commit ec88f28d in 2009, checking if the user-specified flavor
      is in the server's flavor list has been the source of a few
      noticeable regressions (now fixed), but there is one that is still
      vexing.
      
      An NFS server can list AUTH_NULL in its flavor list, which suggests
      a client should try to mount the server with the flavor of the
      client's choice, but the server will squash all accesses.  In some
      cases, our client fails to mount a server because of this check,
      when the mount could have proceeded successfully.
      
      Skip this check if the user has specified "sec=" on the mount
      command line.  But do consult the server-provided flavor list to
      choose a security flavor if no sec= option is specified on the mount
      command.
      
      If a server lists Kerberos pseudoflavors before "sys" in its export
      options, our client now chooses Kerberos over AUTH_UNIX for mount
      points, when no security flavor is specified by the mount command.
      This could be surprising to some administrators or users, who would
      then need to have Kerberos credentials to access the export.
      
      Or, a client administrator may not have enabled rpc.gssd.  In this
      case, auth_rpcgss.ko might still be loadable, which is enough for
      the new logic to choose Kerberos over AUTH_UNIX.  But the mount
      would fail since no GSS context can be created without rpc.gssd
      running.
      
      To retain the use of AUTH_UNIX by default:
      
        o  The server administrator can ensure that "sys" is listed before
           Kerberos flavors in its export security options (see
           exports(5)),
      
        o  The client administrator can explicitly specify "sec=sys" on
           its mount command line (see nfs(5)),
      
        o  The client administrator can use "Sec=sys" in an appropriate
           section of /etc/nfsmount.conf (see nfsmount.conf(5)), or
      
        o  The client administrator can blacklist auth_rpcgss.ko.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      4580a92d