1. 05 Jan, 2012 4 commits
    • Chuck Lever's avatar
      NFSD: Change name of extended attribute containing junction · 9b4146e8
      Chuck Lever authored
      As of fedfs-utils-0.8.0, user space stores all NFS junction
      information in a single extended attribute: "trusted.junction.nfs".
      
      Both FedFS and NFS basic junctions are stored in this one attribute,
      and the intention is that all future forms of NFS junction metadata
      will be stored in this attribute.  Other protocols may use a different
      extended attribute.
      
      Thus NFSD needs to look only for that one extended attribute.  The
      "trusted.junction.type" xattr is deprecated.  fedfs-utils-0.8.0 will
      continue to attach a "trusted.junction.type" xattr to junctions, but
      future fedfs-utils releases may no longer do that.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      9b4146e8
    • J. Bruce Fields's avatar
      svcrpc: don't revert to SVC_POOL_DEFAULT on nfsd shutdown · 9689dcce
      J. Bruce Fields authored
      This was unexpected behavior (at least for me)--why would you want
      configuration settings automatically lost on nfsd restart?
      
      In practice this won't affect distributions, which likely set everything
      on every startup.  But I'd expect the behavior to be less confusing to
      someone manually restarting nfsd for testing.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      9689dcce
    • J. Bruce Fields's avatar
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode · 61c8504c
      J. Bruce Fields authored
      The pool_to and to_pool fields of the global svc_pool_map are freed on
      shutdown, but are initialized in nfsd startup only in the
      SVC_POOL_PERCPU and SVC_POOL_PERNODE cases.
      
      They *are* initialized to zero on kernel startup.  So as long as you use
      only SVC_POOL_GLOBAL (the default), this will never be a problem.
      
      You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE.
      
      However, the following sequence events leads to a double-free:
      
      	1. set SVC_POOL_PERCPU or SVC_POOL_PERNODE
      	2. start nfsd: both fields are initialized.
      	3. shutdown nfsd: both fields are freed.
      	4. set SVC_POOL_GLOBAL
      	5. start nfsd: the fields are left untouched.
      	6. shutdown nfsd: now we try to free them again.
      
      Step 4 is actually unnecessary, since (for some bizarre reason), nfsd
      automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      61c8504c
    • J. Bruce Fields's avatar
      nfsd4: be forgiving in the absence of the recovery directory · b8548894
      J. Bruce Fields authored
      If the recovery directory doesn't exist, then behavior after a reboot
      will be suboptimal.  But it's unnecessarily harsh to then prevent the
      nfsv4 server from working at all.  Instead just print a warning
      (already done in nfsd4_init_recdir()) and soldier on.
      Tested-by: default avatarLior <lior@tonian.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      b8548894
  2. 02 Jan, 2012 1 commit
  3. 14 Dec, 2011 1 commit
  4. 13 Dec, 2011 1 commit
  5. 12 Dec, 2011 1 commit
  6. 07 Dec, 2011 1 commit
  7. 06 Dec, 2011 7 commits
    • Stanislav Kinsbursky's avatar
      SUNRPC: create svc_xprt in proper network namespace · bd4620dd
      Stanislav Kinsbursky authored
      This patch makes svc_xprt inherit network namespace link from its socket.
      Signed-off-by: default avatarStanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      bd4620dd
    • J. Bruce Fields's avatar
      svcrpc: update outdated BKL comment · 94cf3179
      J. Bruce Fields authored
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      94cf3179
    • Mi Jinlong's avatar
      nfsd41: allow non-reclaim open-by-fh's in 4.1 · 0cf99b91
      Mi Jinlong authored
      With NFSv4.0 it was safe to assume that open-by-filehandles were always
      reclaims.
      
      With NFSv4.1 there are non-reclaim open-by-filehandle operations, so we
      should ensure we're only insisting on reclaims in the
      OPEN_CLAIM_PREVIOUS case.
      Signed-off-by: default avatarMi Jinlong <mijinlong@cn.fujitsu.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      0cf99b91
    • J. Bruce Fields's avatar
      svcrpc: avoid memory-corruption on pool shutdown · b4f36f88
      J. Bruce Fields authored
      Socket callbacks use svc_xprt_enqueue() to add an xprt to a
      pool->sp_sockets list.  In normal operation a server thread will later
      come along and take the xprt off that list.  On shutdown, after all the
      threads have exited, we instead manually walk the sv_tempsocks and
      sv_permsocks lists to find all the xprt's and delete them.
      
      So the sp_sockets lists don't really matter any more.  As a result,
      we've mostly just ignored them and hoped they would go away.
      
      Which has gotten us into trouble; witness for example ebc63e53
      "svcrpc: fix list-corrupting race on nfsd shutdown", the result of Ben
      Greear noticing that a still-running svc_xprt_enqueue() could re-add an
      xprt to an sp_sockets list just before it was deleted.  The fix was to
      remove it from the list at the end of svc_delete_xprt().  But that only
      made corruption less likely--I can see nothing that prevents a
      svc_xprt_enqueue() from adding another xprt to the list at the same
      moment that we're removing this xprt from the list.  In fact, despite
      the earlier xpo_detach(), I don't even see what guarantees that
      svc_xprt_enqueue() couldn't still be running on this xprt.
      
      So, instead, note that svc_xprt_enqueue() essentially does:
      	lock sp_lock
      		if XPT_BUSY unset
      			add to sp_sockets
      	unlock sp_lock
      
      So, if we do:
      
      	set XPT_BUSY on every xprt.
      	Empty every sp_sockets list, under the sp_socks locks.
      
      Then we're left knowing that the sp_sockets lists are all empty and will
      stay that way, since any svc_xprt_enqueue() will check XPT_BUSY under
      the sp_lock and see it set.
      
      And *then* we can continue deleting the xprt's.
      
      (Thanks to Jeff Layton for being correctly suspicious of this code....)
      
      Cc: Ben Greear <greearb@candelatech.com>
      Cc: Jeff Layton <jlayton@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      b4f36f88
    • J. Bruce Fields's avatar
      svcrpc: destroy server sockets all at once · 2fefb8a0
      J. Bruce Fields authored
      There's no reason I can see that we need to call sv_shutdown between
      closing the two lists of sockets.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      2fefb8a0
    • J. Bruce Fields's avatar
      svcrpc: make svc_delete_xprt static · 7710ec36
      J. Bruce Fields authored
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      7710ec36
    • Sasha Levin's avatar
      nfsd: Fix oops when parsing a 0 length export · b2ea70af
      Sasha Levin authored
      expkey_parse() oopses when handling a 0 length export. This is easily
      triggerable from usermode by writing 0 bytes into
      '/proc/[proc id]/net/rpc/nfsd.fh/channel'.
      
      Below is the log:
      
      [ 1402.286893] BUG: unable to handle kernel paging request at ffff880077c49fff
      [ 1402.287632] IP: [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
      [ 1402.287632] PGD 2206063 PUD 1fdfd067 PMD 1ffbc067 PTE 8000000077c49160
      [ 1402.287632] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [ 1402.287632] CPU 1
      [ 1402.287632] Pid: 20198, comm: trinity Not tainted 3.2.0-rc2-sasha-00058-gc65cd37 #6
      [ 1402.287632] RIP: 0010:[<ffffffff812b4b99>]  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
      [ 1402.287632] RSP: 0018:ffff880077f0fd68  EFLAGS: 00010292
      [ 1402.287632] RAX: ffff880077c49fff RBX: 00000000ffffffea RCX: 0000000001043400
      [ 1402.287632] RDX: 0000000000000000 RSI: ffff880077c4a000 RDI: ffffffff82283de0
      [ 1402.287632] RBP: ffff880077f0fe18 R08: 0000000000000001 R09: ffff880000000000
      [ 1402.287632] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880077c4a000
      [ 1402.287632] R13: ffffffff82283de0 R14: 0000000001043400 R15: ffffffff82283de0
      [ 1402.287632] FS:  00007f25fec3f700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000
      [ 1402.287632] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 1402.287632] CR2: ffff880077c49fff CR3: 0000000077e1d000 CR4: 00000000000406e0
      [ 1402.287632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1402.287632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [ 1402.287632] Process trinity (pid: 20198, threadinfo ffff880077f0e000, task ffff880077db17b0)
      [ 1402.287632] Stack:
      [ 1402.287632]  ffff880077db17b0 ffff880077c4a000 ffff880077f0fdb8 ffffffff810b411e
      [ 1402.287632]  ffff880000000000 ffff880077db17b0 ffff880077c4a000 ffffffff82283de0
      [ 1402.287632]  0000000001043400 ffffffff82283de0 ffff880077f0fde8 ffffffff81111f63
      [ 1402.287632] Call Trace:
      [ 1402.287632]  [<ffffffff810b411e>] ? lock_release+0x1af/0x1bc
      [ 1402.287632]  [<ffffffff81111f63>] ? might_fault+0x97/0x9e
      [ 1402.287632]  [<ffffffff81111f1a>] ? might_fault+0x4e/0x9e
      [ 1402.287632]  [<ffffffff81a8bcf2>] cache_do_downcall+0x3e/0x4f
      [ 1402.287632]  [<ffffffff81a8c950>] cache_write.clone.16+0xbb/0x130
      [ 1402.287632]  [<ffffffff81a8c9df>] ? cache_write_pipefs+0x1a/0x1a
      [ 1402.287632]  [<ffffffff81a8c9f8>] cache_write_procfs+0x19/0x1b
      [ 1402.287632]  [<ffffffff8118dc54>] proc_reg_write+0x8e/0xad
      [ 1402.287632]  [<ffffffff8113fe81>] vfs_write+0xaa/0xfd
      [ 1402.287632]  [<ffffffff8114142d>] ? fget_light+0x35/0x9e
      [ 1402.287632]  [<ffffffff8113ff8b>] sys_write+0x48/0x6f
      [ 1402.287632]  [<ffffffff81bbdb92>] system_call_fastpath+0x16/0x1b
      [ 1402.287632] Code: c0 c9 c3 55 48 63 d2 48 89 e5 48 8d 44 32 ff 41 57 41 56 41 55 41 54 53 bb ea ff ff ff 48 81 ec 88 00 00 00 48 89 b5 58 ff ff ff
      [ 1402.287632]  38 0a 0f 85 89 02 00 00 c6 00 00 48 8b 3d 44 4a e5 01 48 85
      [ 1402.287632] RIP  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
      [ 1402.287632]  RSP <ffff880077f0fd68>
      [ 1402.287632] CR2: ffff880077c49fff
      [ 1402.287632] ---[ end trace 368ef53ff773a5e3 ]---
      
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: linux-nfs@vger.kernel.org
      Cc: stable@kernel.org
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      b2ea70af
  8. 25 Nov, 2011 1 commit
  9. 16 Nov, 2011 2 commits
  10. 08 Nov, 2011 13 commits
  11. 07 Nov, 2011 8 commits
    • Al Viro's avatar
      VFS: we need to set LOOKUP_JUMPED on mountpoint crossing · a3fbbde7
      Al Viro authored
      Mountpoint crossing is similar to following procfs symlinks - we do
      not get ->d_revalidate() called for dentry we have arrived at, with
      unpleasant consequences for NFS4.
      
      Simple way to reproduce the problem in mainline:
      
          cat >/tmp/a.c <<'EOF'
          #include <unistd.h>
          #include <fcntl.h>
          #include <stdio.h>
          main()
          {
                  struct flock fl = {.l_type = F_RDLCK, .l_whence = SEEK_SET, .l_len = 1};
                  if (fcntl(0, F_SETLK, &fl))
                          perror("setlk");
          }
          EOF
          cc /tmp/a.c -o /tmp/test
      
      then on nfs4:
      
          mount --bind file1 file2
          /tmp/test < file1		# ok
          /tmp/test < file2		# spews "setlk: No locks available"...
      
      What happens is the missing call of ->d_revalidate() after mountpoint
      crossing and that's where NFS4 would issue OPEN request to server.
      
      The fix is simple - treat mountpoint crossing the same way we deal with
      following procfs-style symlinks.  I.e.  set LOOKUP_JUMPED...
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a3fbbde7
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 54a0f913
      Linus Torvalds authored
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf top: Fix live annotation in the --stdio interface
        perf top tui: Don't recalc column widths considering just the first page
        perf report: Add progress bar when processing time ordered events
        perf hists browser: Warn about lost events
        perf tools: Fix a typo of command name as trace-cmd
        perf hists: Fix recalculation of total_period when sorting entries
        perf header: Fix build on old systems
        perf ui browser: Handle K_RESIZE in dialog windows
        perf ui browser: No need to switch char sets that often
        perf hists browser: Use K_TIMER
        perf ui: Rename ui__warning_paranoid to ui__error_paranoid
        perf ui: Reimplement the popup windows using libslang
        perf ui: Reimplement ui__popup_menu using ui__browser
        perf ui: Reimplement ui_helpline using libslang
        perf ui: Improve handling sigwinch a bit
        perf ui progress: Reimplement using slang
        perf evlist: Fix grouping of multiple events
      54a0f913
    • Tony Lindgren's avatar
      d30cc16c
    • Tony Lindgren's avatar
      ARM: OMAP: Fix export.h or module.h includes · a1bcc1dc
      Tony Lindgren authored
      Commit 32aaeffb (Merge branch
      'modsplit-Oct31_2011'...) caused some build errors. Fix these
      and make sure we always have export.h or module.h included
      for MODULE_ and EXPORT_SYMBOL users:
      
      $ grep -rl ^MODULE_ arch/arm/*omap*/*.c | xargs \
        grep -L linux/module.h
        arch/arm/mach-omap2/dsp.c
        arch/arm/mach-omap2/mailbox.c
        arch/arm/mach-omap2/omap-iommu.c
        arch/arm/mach-omap2/smartreflex.c
      
      Also check we either have export.h or module.h included
      for the files exporting symbols:
      
      $ grep -rl EXPORT_SYMBOL arch/arm/*omap*/*.c | xargs \
        grep -L linux/export.h | xargs grep -L linux/module.h
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      a1bcc1dc
    • Axel Lin's avatar
      ARM: OMAP: omap_device: Include linux/export.h · 55581415
      Axel Lin authored
      Include linux/export.h to fix below build warning:
      
        CC      arch/arm/plat-omap/omap_device.o
      arch/arm/plat-omap/omap_device.c:1055: warning: data definition has no type or storage class
      arch/arm/plat-omap/omap_device.c:1055: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
      arch/arm/plat-omap/omap_device.c:1055: warning: parameter names (without types) in function declaration
      Signed-off-by: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      55581415
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 94956eed
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (47 commits)
        forcedeth: fix a few sparse warnings (variable shadowing)
        forcedeth: Improve stats counters
        forcedeth: remove unneeded stats updates
        forcedeth: Acknowledge only interrupts that are being processed
        forcedeth: fix race when unloading module
        MAINTAINERS/rds: update maintainer
        wanrouter: Remove kernel_lock annotations
        usbnet: fix oops in usbnet_start_xmit
        ixgbe: Fix compile for kernel without CONFIG_PCI_IOV defined
        etherh: Add MAINTAINERS entry for etherh
        bonding: comparing a u8 with -1 is always false
        sky2: fix regression on Yukon Optima
        netlink: clarify attribute length check documentation
        netlink: validate NLA_MSECS length
        i825xx:xscale:8390:freescale: Fix Kconfig dependancies
        macvlan: receive multicast with local address
        tg3: Update version to 3.121
        tg3: Eliminate timer race with reset_task
        tg3: Schedule at most one tg3_reset_task run
        tg3: Obtain PCI function number from device
        ...
      94956eed
    • Al Viro's avatar
    • david decotigny's avatar
      forcedeth: fix a few sparse warnings (variable shadowing) · e45a6187
      david decotigny authored
      This fixes the following sparse warnings:
      drivers/net/ethernet/nvidia/forcedeth.c:2113:7: warning: symbol 'size' shadows an earlier one
      drivers/net/ethernet/nvidia/forcedeth.c:2102:6: originally declared here
      drivers/net/ethernet/nvidia/forcedeth.c:2155:7: warning: symbol 'size' shadows an earlier one
      drivers/net/ethernet/nvidia/forcedeth.c:2102:6: originally declared here
      drivers/net/ethernet/nvidia/forcedeth.c:2227:7: warning: symbol 'size' shadows an earlier one
      drivers/net/ethernet/nvidia/forcedeth.c:2215:6: originally declared here
      drivers/net/ethernet/nvidia/forcedeth.c:2271:7: warning: symbol 'size' shadows an earlier one
      drivers/net/ethernet/nvidia/forcedeth.c:2215:6: originally declared here
      drivers/net/ethernet/nvidia/forcedeth.c:2986:20: warning: symbol 'addr' shadows an earlier one
      drivers/net/ethernet/nvidia/forcedeth.c:2963:6: originally declared here
      Signed-off-by: default avatarDavid Decotigny <david.decotigny@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e45a6187