1. 04 May, 2019 1 commit
  2. 02 May, 2019 1 commit
  3. 03 Apr, 2019 2 commits
    • Olga Kornievskaia's avatar
      NFSv4.1 don't free interrupted slot on open · 01105243
      Olga Kornievskaia authored
      commit 0cb98abb upstream.
      Allow the async rpc task for finish and update the open state if needed,
      then free the slot. Otherwise, the async rpc unable to decode the reply.
      Signed-off-by: 's avatarOlga Kornievskaia <kolga@netapp.com>
      Fixes: ae55e59d ("pnfs: Don't release the sequence slot...")
      Cc: stable@vger.kernel.org # v4.18+
      Signed-off-by: 's avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Catalin Marinas's avatar
      NFS: Fix nfs4_lock_state refcounting in nfs4_alloc_{lock,unlock}data() · 7a4cdaf9
      Catalin Marinas authored
      commit 3028efe0 upstream.
      Commit 7b587e1a ("NFS: use locks_copy_lock() to copy locks.")
      changed the lock copying from memcpy() to the dedicated
      locks_copy_lock() function. The latter correctly increments the
      nfs4_lock_state.ls_count via nfs4_fl_copy_lock(), however, this refcount
      has already been incremented in the nfs4_alloc_{lock,unlock}data().
      Kmemleak subsequently reports an unreferenced nfs4_lock_state object as
      below (arm64 platform):
      unreferenced object 0xffff8000fce0b000 (size 256):
        comm "systemd-sysuser", pid 1608, jiffies 4294892825 (age 32.348s)
        hex dump (first 32 bytes):
          20 57 4c fb 00 80 ff ff 20 57 4c fb 00 80 ff ff   WL..... WL.....
          00 57 4c fb 00 80 ff ff 01 00 00 00 00 00 00 00  .WL.............
          [<000000000d15010d>] kmem_cache_alloc+0x178/0x208
          [<00000000d7c1d264>] nfs4_set_lock_state+0x124/0x1f0
          [<000000009c867628>] nfs4_proc_lock+0x90/0x478
          [<000000001686bd74>] do_setlk+0x64/0xe8
          [<00000000e01500d4>] nfs_lock+0xe8/0x1f0
          [<000000004f387d8d>] vfs_lock_file+0x18/0x40
          [<00000000656ab79b>] do_lock_file_wait+0x68/0xf8
          [<00000000f17c4a4b>] fcntl_setlk+0x224/0x280
          [<0000000052a242c6>] do_fcntl+0x418/0x730
          [<000000004f47291a>] __arm64_sys_fcntl+0x84/0xd0
          [<00000000d6856e01>] el0_svc_common+0x80/0xf0
          [<000000009c4bd1df>] el0_svc_handler+0x2c/0x80
          [<00000000b1a0d479>] el0_svc+0x8/0xc
          [<0000000056c62a0f>] 0xffffffffffffffff
      This patch removes the original refcount_inc(&lsp->ls_count) that was
      paired with the memcpy() lock copying.
      Fixes: 7b587e1a ("NFS: use locks_copy_lock() to copy locks.")
      Cc: <stable@vger.kernel.org> # 5.0.x-
      Cc: NeilBrown <neilb@suse.com>
      Signed-off-by: 's avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: 's avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 23 Mar, 2019 4 commits
  5. 15 Feb, 2019 1 commit
    • David Howells's avatar
      keys: Fix dependency loop between construction record and auth key · 822ad64d
      David Howells authored
      In the request_key() upcall mechanism there's a dependency loop by which if
      a key type driver overrides the ->request_key hook and the userspace side
      manages to lose the authorisation key, the auth key and the internal
      construction record (struct key_construction) can keep each other pinned.
      Fix this by the following changes:
       (1) Killing off the construction record and using the auth key instead.
       (2) Including the operation name in the auth key payload and making the
           payload available outside of security/keys/.
       (3) The ->request_key hook is given the authkey instead of the cons
           record and operation name.
      Changes (2) and (3) allow the auth key to naturally be cleaned up if the
      keyring it is in is destroyed or cleared or the auth key is unlinked.
      Fixes: 7ee02a316600 ("keys: Fix dependency loop between construction record and auth key")
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarJames Morris <james.morris@microsoft.com>
  6. 12 Feb, 2019 1 commit
  7. 29 Jan, 2019 1 commit
  8. 28 Jan, 2019 1 commit
    • Yao Liu's avatar
      nfs: Fix NULL pointer dereference of dev_name · 80ff0017
      Yao Liu authored
      There is a NULL pointer dereference of dev_name in nfs_parse_devname()
      The oops looks something like:
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
        RIP: 0010:nfs_fs_mount+0x3b6/0xc20 [nfs]
        Call Trace:
         ? ida_alloc_range+0x34b/0x3d0
         ? nfs_clone_super+0x80/0x80 [nfs]
         ? nfs_free_parsed_mount_data+0x60/0x60 [nfs]
         ? __init_waitqueue_head+0x3b/0x50
      Fix this by adding a NULL check on dev_name
      Signed-off-by: 's avatarYao Liu <yotta.liu@ucloud.cn>
      Signed-off-by: 's avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
  9. 15 Jan, 2019 1 commit
  10. 02 Jan, 2019 5 commits
  11. 31 Dec, 2018 1 commit
  12. 28 Dec, 2018 3 commits
  13. 21 Dec, 2018 5 commits
    • Chris Perl's avatar
      NFS: nfs_compare_mount_options always compare auth flavors. · 594d1644
      Chris Perl authored
      This patch removes the check from nfs_compare_mount_options to see if a
      `sec' option was passed for the current mount before comparing auth
      flavors and instead just always compares auth flavors.
      Consider the following scenario:
      You have a server with the address and two exports /export/a
      and /export/b.  The first export supports `sys' and `krb5' security, the
      second just `sys'.
      Assume you start with no mounts from the server.
      The following results in EIOs being returned as the kernel nfs client
      incorrectly thinks it can share the underlying `struct nfs_server's:
      $ mkdir /tmp/{a,b}
      $ sudo mount -t nfs -o vers=3,sec=krb5 /tmp/a
      $ sudo mount -t nfs -o vers=3 /tmp/b
      $ df >/dev/null
      df: ‘/tmp/b’: Input/output error
      Signed-off-by: 's avatarChris Perl <cperl@janestreet.com>
      Signed-off-by: 's avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
    • Al Viro's avatar
      LSM: new method: ->sb_add_mnt_opt() · 757cbe59
      Al Viro authored
      Adding options to growing mnt_opts.  NFS kludge with passing
      context= down into non-text-options mount switched to it, and
      with that the last use of ->sb_parse_opts_str() is gone.
      Reviewed-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      LSM: hide struct security_mnt_opts from any generic code · 204cc0cc
      Al Viro authored
      Keep void * instead, allocate on demand (in parse_str_opts, at the
      moment).  Eventually both selinux and smack will be better off
      with private structures with several strings in those, rather than
      this "counter and two pointers to dynamically allocated arrays"
      ugliness.  This commit allows to do that at leisure, without
      disrupting anything outside of given module.
      	* instead of struct security_mnt_opt use an opaque pointer
      initialized to NULL.
      	* security_sb_eat_lsm_opts(), security_sb_parse_opts_str() and
      security_free_mnt_opts() take it as var argument (i.e. as void **);
      call sites are unchanged.
      	* security_sb_set_mnt_opts() and security_sb_remount() take
      it by value (i.e. as void *).
      	* new method: ->sb_free_mnt_opts().  Takes void *, does
      whatever freeing that needs to be done.
      	* ->sb_set_mnt_opts() and ->sb_remount() might get NULL as
      mnt_opts argument, meaning "empty".
      Reviewed-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      nfs_remount(): don't leak, don't ignore LSM options quietly · 6a0440e5
      Al Viro authored
      * if mount(2) passes something like "context=foo" with MS_REMOUNT
      in flags (/sbin/mount.nfs will _not_ do that - you need to issue
      the syscall manually), you'll get leaked copies for LSM options.
      The reason is that instead of nfs_{alloc,free}_parsed_mount_data()
      nfs_remount() uses kzalloc/kfree, which lacks the needed cleanup.
      * selinux options are not changed on remount (as for any other
      fs), but in case of NFS the failure is quiet - they are not compared
      to what we used to have, with complaint in case of attempted changes.
      Trivially fixed by converting to use of security_sb_remount().
      Reviewed-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      new helper: security_sb_eat_lsm_opts() · f5c0c26d
      Al Viro authored
      combination of alloc_secdata(), security_sb_copy_data(),
      security_sb_parse_opt_str() and free_secdata().
      Reviewed-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
  14. 19 Dec, 2018 12 commits
  15. 02 Dec, 2018 1 commit
    • Dave Kleikamp's avatar
      nfs: don't dirty kernel pages read by direct-io · ad3cba22
      Dave Kleikamp authored
      When we use direct_IO with an NFS backing store, we can trigger a
      WARNING in __set_page_dirty(), as below, since we're dirtying the page
      unnecessarily in nfs_direct_read_completion().
      To fix, replicate the logic in commit 53cbf3b1 ("fs: direct-io:
      don't dirtying pages for ITER_BVEC/ITER_KVEC direct read").
      Other filesystems that implement direct_IO handle this; most use
      blockdev_direct_IO(). ceph and cifs have similar logic.
      mount /nfs
      dd if=/dev/zero of=/nfs/image bs=1M count=200
      losetup --direct-io=on -f /nfs/image
      mkfs.btrfs /dev/loop0
      mount -t btrfs /dev/loop0 /mnt/
      kernel: WARNING: CPU: 0 PID: 8067 at fs/buffer.c:580 __set_page_dirty+0xaf/0xd0
      kernel: Modules linked in: loop(E) nfsv3(E) rpcsec_gss_krb5(E) nfsv4(E) dns_resolver(E) nfs(E) fscache(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) fuse(E) tun(E) ip6t_rpfilter(E) ipt_REJECT(E) nf_
      kernel:  snd_seq(E) snd_seq_device(E) snd_pcm(E) video(E) snd_timer(E) snd(E) soundcore(E) ip_tables(E) xfs(E) libcrc32c(E) sd_mod(E) sr_mod(E) cdrom(E) ata_generic(E) pata_acpi(E) crc32c_intel(E) ahci(E) li
      kernel: CPU: 0 PID: 8067 Comm: kworker/0:2 Tainted: G            E     4.20.0-rc1.master.20181111.ol7.x86_64 #1
      kernel: Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      kernel: Workqueue: nfsiod rpc_async_release [sunrpc]
      kernel: RIP: 0010:__set_page_dirty+0xaf/0xd0
      kernel: Code: c3 48 8b 02 f6 c4 04 74 d4 48 89 df e8 ba 05 f7 ff 48 89 c6 eb cb 48 8b 43 08 a8 01 75 1f 48 89 d8 48 8b 00 a8 04 74 02 eb 87 <0f> 0b eb 83 48 83 e8 01 eb 9f 48 83 ea 01 0f 1f 00 eb 8b 48 83 e8
      kernel: RSP: 0000:ffffc1c8825b7d78 EFLAGS: 00013046
      kernel: RAX: 000fffffc0020089 RBX: fffff2b603308b80 RCX: 0000000000000001
      kernel: RDX: 0000000000000001 RSI: ffff9d11478115c8 RDI: ffff9d11478115d0
      kernel: RBP: ffffc1c8825b7da0 R08: 0000646f6973666e R09: 8080808080808080
      kernel: R10: 0000000000000001 R11: 0000000000000000 R12: ffff9d11478115d0
      kernel: R13: ffff9d11478115c8 R14: 0000000000003246 R15: 0000000000000001
      kernel: FS:  0000000000000000(0000) GS:ffff9d115ba00000(0000) knlGS:0000000000000000
      kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      kernel: CR2: 00007f408686f640 CR3: 0000000104d8e004 CR4: 00000000000606f0
      kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      kernel: Call Trace:
      kernel:  __set_page_dirty_buffers+0xb6/0x110
      kernel:  set_page_dirty+0x52/0xb0
      kernel:  nfs_direct_read_completion+0xc4/0x120 [nfs]
      kernel:  nfs_pgio_release+0x10/0x20 [nfs]
      kernel:  rpc_free_task+0x30/0x70 [sunrpc]
      kernel:  rpc_async_release+0x12/0x20 [sunrpc]
      kernel:  process_one_work+0x174/0x390
      kernel:  worker_thread+0x4f/0x3e0
      kernel:  kthread+0x102/0x140
      kernel:  ? drain_workqueue+0x130/0x130
      kernel:  ? kthread_stop+0x110/0x110
      kernel:  ret_from_fork+0x35/0x40
      kernel: ---[ end trace 01341980905412c9 ]---
      Signed-off-by: 's avatarDave Kleikamp <dave.kleikamp@oracle.com>
      Signed-off-by: 's avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      [forward-ported to v4.20]
      Signed-off-by: 's avatarCalum Mackay <calum.mackay@oracle.com>
      Reviewed-by: 's avatarDave Kleikamp <dave.kleikamp@oracle.com>
      Reviewed-by: 's avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: 's avatarTrond Myklebust <trond.myklebust@hammerspace.com>