1. 02 11月, 2016 4 次提交
    • J
      nfsd: clean up supported attribute handling · 916d2d84
      J. Bruce Fields 提交于
      Minor cleanup, no change in behavior.
      
      Provide helpers for some common attribute bitmap operations.  Drop some
      comments that just echo the code.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      916d2d84
    • J
      nfsd: fix error handling for clients that fail to return the layout · 851238a2
      Jeff Layton 提交于
      Currently, when the client continually returns NFS4ERR_DELAY on a
      CB_LAYOUTRECALL, we'll give up trying to retransmit after two lease
      periods, but leave the layout in place.
      
      What we really need to do here is fence the client in this case. Have it
      fall through to that code in that case instead of into the
      NFS4ERR_NOMATCHING_LAYOUT case.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      851238a2
    • J
      nfsd: more robust allocation failure handling in nfsd_reply_cache_init · 8f97514b
      Jeff Layton 提交于
      Currently, we try to allocate the cache as a single, large chunk, which
      can fail if no big chunks of memory are available. We _do_ try to size
      it according to the amount of memory in the box, but if the server is
      started well after boot time, then the allocation can fail due to memory
      fragmentation.
      
      Fall back to doing a vzalloc if the kcalloc fails, and switch the
      shutdown code to do a kvfree to handle freeing correctly.
      Reported-by: NOlaf Hering <olaf@aepfle.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      8f97514b
    • C
      nfsd: Fix general protection fault in release_lock_stateid() · f46c445b
      Chuck Lever 提交于
      When I push NFSv4.1 / RDMA hard, (xfstests generic/089, for example),
      I get this crash on the server:
      
      Oct 28 22:04:30 klimt kernel: general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
      Oct 28 22:04:30 klimt kernel: Modules linked in: cts rpcsec_gss_krb5 iTCO_wdt iTCO_vendor_support sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm btrfs irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd xor pcspkr raid6_pq i2c_i801 i2c_smbus lpc_ich mfd_core sg mei_me mei ioatdma shpchp wmi ipmi_si ipmi_msghandler rpcrdma ib_ipoib rdma_ucm acpi_power_meter acpi_pad ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c mlx4_ib mlx4_en ib_core sr_mod cdrom sd_mod ast drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crc32c_intel igb ahci libahci ptp mlx4_core pps_core dca libata i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod
      Oct 28 22:04:30 klimt kernel: CPU: 7 PID: 1558 Comm: nfsd Not tainted 4.9.0-rc2-00005-g82cd754 #8
      Oct 28 22:04:30 klimt kernel: Hardware name: Supermicro Super Server/X10SRL-F, BIOS 1.0c 09/09/2015
      Oct 28 22:04:30 klimt kernel: task: ffff880835c3a100 task.stack: ffff8808420d8000
      Oct 28 22:04:30 klimt kernel: RIP: 0010:[<ffffffffa05a759f>]  [<ffffffffa05a759f>] release_lock_stateid+0x1f/0x60 [nfsd]
      Oct 28 22:04:30 klimt kernel: RSP: 0018:ffff8808420dbce0  EFLAGS: 00010246
      Oct 28 22:04:30 klimt kernel: RAX: ffff88084e6660f0 RBX: ffff88084e667020 RCX: 0000000000000000
      Oct 28 22:04:30 klimt kernel: RDX: 0000000000000007 RSI: 0000000000000000 RDI: ffff88084e667020
      Oct 28 22:04:30 klimt kernel: RBP: ffff8808420dbcf8 R08: 0000000000000001 R09: 0000000000000000
      Oct 28 22:04:30 klimt kernel: R10: ffff880835c3a100 R11: ffff880835c3aca8 R12: 6b6b6b6b6b6b6b6b
      Oct 28 22:04:30 klimt kernel: R13: ffff88084e6670d8 R14: ffff880835f546f0 R15: ffff880835f1c548
      Oct 28 22:04:30 klimt kernel: FS:  0000000000000000(0000) GS:ffff88087bdc0000(0000) knlGS:0000000000000000
      Oct 28 22:04:30 klimt kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      Oct 28 22:04:30 klimt kernel: CR2: 00007ff020389000 CR3: 0000000001c06000 CR4: 00000000001406e0
      Oct 28 22:04:30 klimt kernel: Stack:
      Oct 28 22:04:30 klimt kernel: ffff88084e667020 0000000000000000 ffff88084e6670d8 ffff8808420dbd20
      Oct 28 22:04:30 klimt kernel: ffffffffa05ac80d ffff880835f54548 ffff88084e640008 ffff880835f545b0
      Oct 28 22:04:30 klimt kernel: ffff8808420dbd70 ffffffffa059803d ffff880835f1c768 0000000000000870
      Oct 28 22:04:30 klimt kernel: Call Trace:
      Oct 28 22:04:30 klimt kernel: [<ffffffffa05ac80d>] nfsd4_free_stateid+0xfd/0x1b0 [nfsd]
      Oct 28 22:04:30 klimt kernel: [<ffffffffa059803d>] nfsd4_proc_compound+0x40d/0x690 [nfsd]
      Oct 28 22:04:30 klimt kernel: [<ffffffffa0583114>] nfsd_dispatch+0xd4/0x1d0 [nfsd]
      Oct 28 22:04:30 klimt kernel: [<ffffffffa047bbf9>] svc_process_common+0x3d9/0x700 [sunrpc]
      Oct 28 22:04:30 klimt kernel: [<ffffffffa047ca64>] svc_process+0xf4/0x330 [sunrpc]
      Oct 28 22:04:30 klimt kernel: [<ffffffffa05827ca>] nfsd+0xfa/0x160 [nfsd]
      Oct 28 22:04:30 klimt kernel: [<ffffffffa05826d0>] ? nfsd_destroy+0x170/0x170 [nfsd]
      Oct 28 22:04:30 klimt kernel: [<ffffffff810b367b>] kthread+0x10b/0x120
      Oct 28 22:04:30 klimt kernel: [<ffffffff810b3570>] ? kthread_stop+0x280/0x280
      Oct 28 22:04:30 klimt kernel: [<ffffffff8174e8ba>] ret_from_fork+0x2a/0x40
      Oct 28 22:04:30 klimt kernel: Code: c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 87 b0 00 00 00 48 89 fb 4c 8b a0 98 00 00 00 <49> 8b 44 24 20 48 8d b8 80 03 00 00 e8 10 66 1a e1 48 89 df e8
      Oct 28 22:04:30 klimt kernel: RIP  [<ffffffffa05a759f>] release_lock_stateid+0x1f/0x60 [nfsd]
      Oct 28 22:04:30 klimt kernel: RSP <ffff8808420dbce0>
      Oct 28 22:04:30 klimt kernel: ---[ end trace cf5d0b371973e167 ]---
      
      Jeff Layton says:
      > Hm...now that I look though, this is a little suspicious:
      >
      >    struct nfs4_openowner *oo = openowner(stp->st_openstp->st_stateowner);
      >
      > I wonder if it's possible for the openstateid to have already been
      > destroyed at this point.
      >
      > We might be better off doing something like this to get the client pointer:
      >
      >    stp->st_stid.sc_client;
      >
      > ...which should be more direct and less dependent on other stateids
      > staying valid.
      
      With the suggested change, I am no longer able to reproduce the above oops.
      
      v2: Fix unhash_lock_stateid() as well
      Fix-suggested-by: NJeff Layton <jlayton@redhat.com>
      Fixes: 42691398 ('nfsd: Fix race between FREE_STATEID and LOCK')
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f46c445b
  2. 25 10月, 2016 1 次提交
  3. 20 10月, 2016 6 次提交
    • A
      fs/proc: Stop trying to report thread stacks · b18cb64e
      Andy Lutomirski 提交于
      This reverts more of:
      
        b7643757 ("procfs: mark thread stack correctly in proc/<pid>/maps")
      
      ... which was partially reverted by:
      
        65376df5 ("proc: revert /proc/<pid>/maps [stack:TID] annotation")
      
      Originally, /proc/PID/task/TID/maps was the same as /proc/TID/maps.
      
      In current kernels, /proc/PID/maps (or /proc/TID/maps even for
      threads) shows "[stack]" for VMAs in the mm's stack address range.
      
      In contrast, /proc/PID/task/TID/maps uses KSTK_ESP to guess the
      target thread's stack's VMA.  This is racy, probably returns garbage
      and, on arches with CONFIG_TASK_INFO_IN_THREAD=y, is also crash-prone:
      KSTK_ESP is not safe to use on tasks that aren't known to be running
      ordinary process-context kernel code.
      
      This patch removes the difference and just shows "[stack]" for VMAs
      in the mm's stack range.  This is IMO much more sensible -- the
      actual "stack" address really is treated specially by the VM code,
      and the current thread stack isn't even well-defined for programs
      that frequently switch stacks on their own.
      Reported-by: NJann Horn <jann@thejh.net>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Linux API <linux-api@vger.kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tycho Andersen <tycho.andersen@canonical.com>
      Link: http://lkml.kernel.org/r/3e678474ec14e0a0ec34c611016753eea2e1b8ba.1475257877.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b18cb64e
    • A
      fs/proc: Stop reporting eip and esp in /proc/PID/stat · 0a1eb2d4
      Andy Lutomirski 提交于
      Reporting these fields on a non-current task is dangerous.  If the
      task is in any state other than normal kernel code, they may contain
      garbage or even kernel addresses on some architectures.  (x86_64
      used to do this.  I bet lots of architectures still do.)  With
      CONFIG_THREAD_INFO_IN_TASK=y, it can OOPS, too.
      
      As far as I know, there are no use programs that make any material
      use of these fields, so just get rid of them.
      Reported-by: NJann Horn <jann@thejh.net>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Linux API <linux-api@vger.kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Cc: Tycho Andersen <tycho.andersen@canonical.com>
      Link: http://lkml.kernel.org/r/a5fed4c3f4e33ed25d4bb03567e329bc5a712bcc.1475257877.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      0a1eb2d4
    • R
      ubifs: Abort readdir upon error · c83ed4c9
      Richard Weinberger 提交于
      If UBIFS is facing an error while walking a directory, it reports this
      error and ubifs_readdir() returns the error code. But the VFS readdir
      logic does not make the getdents system call fail in all cases. When the
      readdir cursor indicates that more entries are present, the system call
      will just return and the libc wrapper will try again since it also
      knows that more entries are present.
      This causes the libc wrapper to busy loop for ever when a directory is
      corrupted on UBIFS.
      A common approach do deal with corrupted directory entries is
      skipping them by setting the cursor to the next entry. On UBIFS this
      approach is not possible since we cannot compute the next directory
      entry cursor position without reading the current entry. So all we can
      do is setting the cursor to the "no more entries" position and make
      getdents exit.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      c83ed4c9
    • R
      ubifs: Fix xattr_names length in exit paths · 843741c5
      Richard Weinberger 提交于
      When the operation fails we also have to undo the changes
      we made to ->xattr_names. Otherwise listxattr() will report
      wrong lengths.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      843741c5
    • R
      ubifs: Rename ubifs_rename2 · 390975ac
      Richard Weinberger 提交于
      Since ->rename2 is gone, rename ubifs_rename2() to ubifs_rename().
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      390975ac
    • A
      nfs4: fix missing-braces warning · 83aa3e0f
      Arnd Bergmann 提交于
      A bugfix introduced a harmless warning for update_open_stateid:
      
      fs/nfs/nfs4proc.c:1548:2: error: missing braces around initializer [-Werror=missing-braces]
      
      Removing the zero in the initializer will do the right thing here
      and initialize the entire structure to zero.
      
      Fixes: 1393d961 ("NFSv4: Fix a race when updating an open_stateid")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      83aa3e0f
  4. 19 10月, 2016 2 次提交
  5. 18 10月, 2016 7 次提交
  6. 16 10月, 2016 1 次提交
  7. 15 10月, 2016 9 次提交
  8. 14 10月, 2016 10 次提交