1. 12 Oct, 2019 22 commits
  2. 11 Oct, 2019 15 commits
  3. 10 Oct, 2019 3 commits
    • Benjamin Coddington's avatar
      SUNRPC: fix race to sk_err after xs_error_report · af84537d
      Benjamin Coddington authored
      Since commit 4f8943f8 ("SUNRPC: Replace direct task wakeups from
      softirq context") there has been a race to the value of the sk_err if both
      XPRT_SOCK_WAKE_ERROR and XPRT_SOCK_WAKE_DISCONNECT are set.  In that case,
      we may end up losing the sk_err value that existed when xs_error_report was
      called.
      
      Fix this by reverting to the previous behavior: instead of using SO_ERROR
      to retrieve the value at a later time (which might also return sk_err_soft),
      copy the sk_err value onto struct sock_xprt, and use that value to wake
      pending tasks.
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Fixes: 4f8943f8 ("SUNRPC: Replace direct task wakeups from softirq context")
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      af84537d
    • Chuck Lever's avatar
      NFSv4: Fix leak of clp->cl_acceptor string · 1047ec86
      Chuck Lever authored
      Our client can issue multiple SETCLIENTID operations to the same
      server in some circumstances. Ensure that calls to
      nfs4_proc_setclientid() after the first one do not overwrite the
      previously allocated cl_acceptor string.
      
      unreferenced object 0xffff888461031800 (size 32):
        comm "mount.nfs", pid 2227, jiffies 4294822467 (age 1407.749s)
        hex dump (first 32 bytes):
          6e 66 73 40 6b 6c 69 6d 74 2e 69 62 2e 31 30 31  nfs@klimt.ib.101
          35 67 72 61 6e 67 65 72 2e 6e 65 74 00 00 00 00  5granger.net....
        backtrace:
          [<00000000ab820188>] __kmalloc+0x128/0x176
          [<00000000eeaf4ec8>] gss_stringify_acceptor+0xbd/0x1a7 [auth_rpcgss]
          [<00000000e85e3382>] nfs4_proc_setclientid+0x34e/0x46c [nfsv4]
          [<000000003d9cf1fa>] nfs40_discover_server_trunking+0x7a/0xed [nfsv4]
          [<00000000b81c3787>] nfs4_discover_server_trunking+0x81/0x244 [nfsv4]
          [<000000000801b55f>] nfs4_init_client+0x1b0/0x238 [nfsv4]
          [<00000000977daf7f>] nfs4_set_client+0xfe/0x14d [nfsv4]
          [<0000000053a68a2a>] nfs4_create_server+0x107/0x1db [nfsv4]
          [<0000000088262019>] nfs4_remote_mount+0x2c/0x59 [nfsv4]
          [<00000000e84a2fd0>] legacy_get_tree+0x2d/0x4c
          [<00000000797e947c>] vfs_get_tree+0x20/0xc7
          [<00000000ecabaaa8>] fc_mount+0xe/0x36
          [<00000000f15fafc2>] vfs_kern_mount+0x74/0x8d
          [<00000000a3ff4e26>] nfs_do_root_mount+0x8a/0xa3 [nfsv4]
          [<00000000d1c2b337>] nfs4_try_mount+0x58/0xad [nfsv4]
          [<000000004c9bddee>] nfs_fs_mount+0x820/0x869 [nfs]
      
      Fixes: f11b2a1c ("nfs4: copy acceptor name from context ... ")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      1047ec86
    • Paul Burton's avatar
      MIPS: Disable Loongson MMI instructions for kernel build · 2f2b4fd6
      Paul Burton authored
      GCC 9.x automatically enables support for Loongson MMI instructions when
      using some -march= flags, and then errors out when -msoft-float is
      specified with:
      
        cc1: error: ‘-mloongson-mmi’ must be used with ‘-mhard-float’
      
      The kernel shouldn't be using these MMI instructions anyway, just as it
      doesn't use floating point instructions. Explicitly disable them in
      order to fix the build with GCC 9.x.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: 3702bba5 ("MIPS: Loongson: Add GCC 4.4 support for Loongson2E")
      Fixes: 6f7a251a ("MIPS: Loongson: Add basic Loongson 2F support")
      Fixes: 5188129b ("MIPS: Loongson-3: Improve -march option and move it to Platform")
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
      Cc: stable@vger.kernel.org # v2.6.32+
      Cc: linux-mips@vger.kernel.org
      2f2b4fd6