1. 28 2月, 2013 1 次提交
    • J
      nfs: don't allow nfs_find_actor to match inodes of the wrong type · f6488c9b
      Jeff Layton 提交于
      Benny Halevy reported the following oops when testing RHEL6:
      
      <7>nfs_update_inode: inode 892950 mode changed, 0040755 to 0100644
      <1>BUG: unable to handle kernel NULL pointer dereference at (null)
      <1>IP: [<ffffffffa02a52c5>] nfs_closedir+0x15/0x30 [nfs]
      <4>PGD 81448a067 PUD 831632067 PMD 0
      <4>Oops: 0000 [#1] SMP
      <4>last sysfs file: /sys/kernel/mm/redhat_transparent_hugepage/enabled
      <4>CPU 6
      <4>Modules linked in: fuse bonding 8021q garp ebtable_nat ebtables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi softdog bridge stp llc xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_round_robin dm_multipath objlayoutdriver2(U) nfs(U) lockd fscache auth_rpcgss nfs_acl sunrpc vhost_net macvtap macvlan tun kvm_intel kvm be2net igb dca ptp pps_core microcode serio_raw sg iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 mbcache jbd2 sd_mod crc_t10dif ahci dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
      <4>
      <4>Pid: 6332, comm: dd Not tainted 2.6.32-358.el6.x86_64 #1 HP ProLiant DL170e G6  /ProLiant DL170e G6
      <4>RIP: 0010:[<ffffffffa02a52c5>]  [<ffffffffa02a52c5>] nfs_closedir+0x15/0x30 [nfs]
      <4>RSP: 0018:ffff88081458bb98  EFLAGS: 00010292
      <4>RAX: ffffffffa02a52b0 RBX: 0000000000000000 RCX: 0000000000000003
      <4>RDX: ffffffffa02e45a0 RSI: ffff88081440b300 RDI: ffff88082d5f5760
      <4>RBP: ffff88081458bba8 R08: 0000000000000000 R09: 0000000000000000
      <4>R10: 0000000000000772 R11: 0000000000400004 R12: 0000000040000008
      <4>R13: ffff88082d5f5760 R14: ffff88082d6e8800 R15: ffff88082f12d780
      <4>FS:  00007f728f37e700(0000) GS:ffff8800456c0000(0000) knlGS:0000000000000000
      <4>CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      <4>CR2: 0000000000000000 CR3: 0000000831279000 CR4: 00000000000007e0
      <4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      <4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      <4>Process dd (pid: 6332, threadinfo ffff88081458a000, task ffff88082fa0e040)
      <4>Stack:
      <4> 0000000040000008 ffff88081440b300 ffff88081458bbf8 ffffffff81182745
      <4><d> ffff88082d5f5760 ffff88082d6e8800 ffff88081458bbf8 ffffffffffffffea
      <4><d> ffff88082f12d780 ffff88082d6e8800 ffffffffa02a50a0 ffff88082d5f5760
      <4>Call Trace:
      <4> [<ffffffff81182745>] __fput+0xf5/0x210
      <4> [<ffffffffa02a50a0>] ? do_open+0x0/0x20 [nfs]
      <4> [<ffffffff81182885>] fput+0x25/0x30
      <4> [<ffffffff8117e23e>] __dentry_open+0x27e/0x360
      <4> [<ffffffff811c397a>] ? inotify_d_instantiate+0x2a/0x60
      <4> [<ffffffff8117e4b9>] lookup_instantiate_filp+0x69/0x90
      <4> [<ffffffffa02a6679>] nfs_intent_set_file+0x59/0x90 [nfs]
      <4> [<ffffffffa02a686b>] nfs_atomic_lookup+0x1bb/0x310 [nfs]
      <4> [<ffffffff8118e0c2>] __lookup_hash+0x102/0x160
      <4> [<ffffffff81225052>] ? selinux_inode_permission+0x72/0xb0
      <4> [<ffffffff8118e76a>] lookup_hash+0x3a/0x50
      <4> [<ffffffff81192a4b>] do_filp_open+0x2eb/0xdd0
      <4> [<ffffffff8104757c>] ? __do_page_fault+0x1ec/0x480
      <4> [<ffffffff8119f562>] ? alloc_fd+0x92/0x160
      <4> [<ffffffff8117de79>] do_sys_open+0x69/0x140
      <4> [<ffffffff811811f6>] ? sys_lseek+0x66/0x80
      <4> [<ffffffff8117df90>] sys_open+0x20/0x30
      <4> [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
      <4>Code: 65 48 8b 04 25 c8 cb 00 00 83 a8 44 e0 ff ff 01 5b 41 5c c9 c3 90 55 48 89 e5 53 48 83 ec 08 0f 1f 44 00 00 48 8b 9e a0 00 00 00 <48> 8b 3b e8 13 0c f7 ff 48 89 df e8 ab 3d ec e0 48 83 c4 08 31
      <1>RIP  [<ffffffffa02a52c5>] nfs_closedir+0x15/0x30 [nfs]
      <4> RSP <ffff88081458bb98>
      <4>CR2: 0000000000000000
      
      I think this is ultimately due to a bug on the server. The client had
      previously found a directory dentry. It then later tried to do an atomic
      open on a new (regular file) dentry. The attributes it got back had the
      same filehandle as the previously found directory inode. It then tried
      to put the filp because it failed the aops tests for O_DIRECT opens, and
      oopsed here because the ctx was still NULL.
      
      Obviously the root cause here is a server issue, but we can take steps
      to mitigate this on the client. When nfs_fhget is called, we always know
      what type of inode it is. In the event that there's a broken or
      malicious server on the other end of the wire, the client can end up
      crashing because the wrong ops are set on it.
      
      Have nfs_find_actor check that the inode type is correct after checking
      the fileid. The fileid check should rarely ever match, so it should only
      rarely ever get to this check. In the case where we have a broken
      server, we may see two different inodes with the same i_ino, but the
      client should be able to cope with them without crashing.
      
      This should fix the oops reported here:
      
          https://bugzilla.redhat.com/show_bug.cgi?id=913660Reported-by: NBenny Halevy <bhalevy@tonian.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f6488c9b
  2. 26 2月, 2013 1 次提交
    • W
      NFSv4.1: Hold reference to layout hdr in layoutget · a47970ff
      Weston Andros Adamson 提交于
      This fixes an oops where a LAYOUTGET is in still in the rpciod queue,
      but the requesting processes has been killed.  Without this, killing
      the process does the final pnfs_put_layout_hdr() and sets NFS_I(inode)->layout
      to NULL while the LAYOUTGET rpc task still references it.
      
      Example oops:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
      IP: [<ffffffffa01bd586>] pnfs_choose_layoutget_stateid+0x37/0xef [nfsv4]
      PGD 7365b067 PUD 7365d067 PMD 0
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      Modules linked in: nfs_layout_nfsv41_files nfsv4 auth_rpcgss nfs lockd sunrpc ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ip6table_filter ip6_tables ppdev e1000 i2c_piix4 i2c_core shpchp parport_pc parport crc32c_intel aesni_intel xts aes_x86_64 lrw gf128mul ablk_helper cryptd mptspi scsi_transport_spi mptscsih mptbase floppy autofs4
      CPU 0
      Pid: 27, comm: kworker/0:1 Not tainted 3.8.0-dros_cthon2013+ #4 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
      RIP: 0010:[<ffffffffa01bd586>]  [<ffffffffa01bd586>] pnfs_choose_layoutget_stateid+0x37/0xef [nfsv4]
      RSP: 0018:ffff88007b0c1c88  EFLAGS: 00010246
      RAX: ffff88006ed36678 RBX: 0000000000000000 RCX: 0000000ea877e3bc
      RDX: ffff88007a729da8 RSI: 0000000000000000 RDI: ffff88007a72b958
      RBP: ffff88007b0c1ca8 R08: 0000000000000002 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff88007a72b958
      R13: ffff88007a729da8 R14: 0000000000000000 R15: ffffffffa011077e
      FS:  0000000000000000(0000) GS:ffff88007f600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000080 CR3: 00000000735f8000 CR4: 00000000001407f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process kworker/0:1 (pid: 27, threadinfo ffff88007b0c0000, task ffff88007c2fa0c0)
      Stack:
       ffff88006fc05388 ffff88007a72b908 ffff88007b240900 ffff88006fc05388
       ffff88007b0c1cd8 ffffffffa01a2170 ffff88007b240900 ffff88007b240900
       ffff88007b240970 ffffffffa011077e ffff88007b0c1ce8 ffffffffa0110791
      Call Trace:
       [<ffffffffa01a2170>] nfs4_layoutget_prepare+0x7b/0x92 [nfsv4]
       [<ffffffffa011077e>] ? __rpc_atrun+0x15/0x15 [sunrpc]
       [<ffffffffa0110791>] rpc_prepare_task+0x13/0x15 [sunrpc]
      Reported-by: NTigran Mkrtchyan <tigran.mkrtchyan@desy.de>
      Signed-off-by: NWeston Andros Adamson <dros@netapp.com>
      Cc: stable@kernel.org
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      a47970ff
  3. 24 2月, 2013 1 次提交
    • B
      pnfs: fix resend_to_mds for directio · 78f33277
      Benny Halevy 提交于
      Pass the directio request on pageio_init to clean up the API.
      
      Percolate pg_dreq from original nfs_pageio_descriptor to the
      pnfs_{read,write}_done_resend_to_mds and use it on respective
      call to nfs_pageio_init_{read,write} on the newly created
      nfs_pageio_descriptor.
      
      Reproduced by command:
       mount -o vers=4.1 server:/ /mnt
       dd bs=128k count=8 if=/dev/zero of=/mnt/dd.out oflag=direct
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      IP: [<ffffffffa021a3a8>] atomic_inc+0x4/0x9 [nfs]
      PGD 34786067 PUD 34794067 PMD 0
      Oops: 0002 [#1] SMP
      Modules linked in: nfs_layout_nfsv41_files nfsv4 nfs nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc btrfs zlib_deflate libcrc32c ipv6 autofs4
      CPU 1
      Pid: 259, comm: kworker/1:2 Not tainted 3.8.0-rc6 #2 Bochs Bochs
      RIP: 0010:[<ffffffffa021a3a8>]  [<ffffffffa021a3a8>] atomic_inc+0x4/0x9 [nfs]
      RSP: 0018:ffff880038f8fa68  EFLAGS: 00010206
      RAX: ffffffffa021a6a9 RBX: ffff880038f8fb48 RCX: 00000000000a0000
      RDX: ffffffffa021e616 RSI: ffff8800385e9a40 RDI: 0000000000000028
      RBP: ffff880038f8fa68 R08: ffffffff81ad6720 R09: ffff8800385e9510
      R10: ffffffffa0228450 R11: ffff880038e87418 R12: ffff8800385e9a40
      R13: ffff8800385e9a70 R14: ffff880038f8fb38 R15: ffffffffa0148878
      FS:  0000000000000000(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000028 CR3: 0000000034789000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process kworker/1:2 (pid: 259, threadinfo ffff880038f8e000, task ffff880038302480)
      Stack:
       ffff880038f8fa78 ffffffffa021a6bf ffff880038f8fa88 ffffffffa021bb82
       ffff880038f8fae8 ffffffffa021f454 ffff880038f8fae8 ffffffff8109689d
       ffff880038f8fab8 ffffffff00000006 0000000000000000 ffff880038f8fb48
      Call Trace:
       [<ffffffffa021a6bf>] nfs_direct_pgio_init+0x16/0x18 [nfs]
       [<ffffffffa021bb82>] nfs_pgheader_init+0x6a/0x6c [nfs]
       [<ffffffffa021f454>] nfs_generic_pg_writepages+0x51/0xf8 [nfs]
       [<ffffffff8109689d>] ? mark_held_locks+0x71/0x99
       [<ffffffffa0148878>] ? rpc_release_resources_task+0x37/0x37 [sunrpc]
       [<ffffffffa021bc25>] nfs_pageio_doio+0x1a/0x43 [nfs]
       [<ffffffffa021be7c>] nfs_pageio_complete+0x16/0x2c [nfs]
       [<ffffffffa02608be>] pnfs_write_done_resend_to_mds+0x95/0xc5 [nfsv4]
       [<ffffffffa0148878>] ? rpc_release_resources_task+0x37/0x37 [sunrpc]
       [<ffffffffa028e27f>] filelayout_reset_write+0x8c/0x99 [nfs_layout_nfsv41_files]
       [<ffffffffa028e5f9>] filelayout_write_done_cb+0x4d/0xc1 [nfs_layout_nfsv41_files]
       [<ffffffffa024587a>] nfs4_write_done+0x36/0x49 [nfsv4]
       [<ffffffffa021f996>] nfs_writeback_done+0x53/0x1cc [nfs]
       [<ffffffffa021fb1d>] nfs_writeback_done_common+0xe/0x10 [nfs]
       [<ffffffffa028e03d>] filelayout_write_call_done+0x28/0x2a [nfs_layout_nfsv41_files]
       [<ffffffffa01488a1>] rpc_exit_task+0x29/0x87 [sunrpc]
       [<ffffffffa014a0c9>] __rpc_execute+0x11d/0x3cc [sunrpc]
       [<ffffffff810969dc>] ? trace_hardirqs_on_caller+0x117/0x173
       [<ffffffffa014a39f>] rpc_async_schedule+0x27/0x32 [sunrpc]
       [<ffffffffa014a378>] ? __rpc_execute+0x3cc/0x3cc [sunrpc]
       [<ffffffff8105f8c1>] process_one_work+0x226/0x422
       [<ffffffff8105f7f4>] ? process_one_work+0x159/0x422
       [<ffffffff81094757>] ? lock_acquired+0x210/0x249
       [<ffffffffa014a378>] ? __rpc_execute+0x3cc/0x3cc [sunrpc]
       [<ffffffff810600d8>] worker_thread+0x126/0x1c4
       [<ffffffff8105ffb2>] ? manage_workers+0x240/0x240
       [<ffffffff81064ef8>] kthread+0xb1/0xb9
       [<ffffffff81064e47>] ? __kthread_parkme+0x65/0x65
       [<ffffffff815206ec>] ret_from_fork+0x7c/0xb0
       [<ffffffff81064e47>] ? __kthread_parkme+0x65/0x65
      Code: 00 83 38 02 74 12 48 81 4b 50 00 00 01 00 c7 83 60 07 00 00 01 00 00 00 48 89 df e8 55 fe ff ff 5b 41 5c 5d c3 66 90 55 48 89 e5 <f0> ff 07 5d c3 55 48 89 e5 f0 ff 0f 0f 94 c0 84 c0 0f 95 c0 0f
      RIP  [<ffffffffa021a3a8>] atomic_inc+0x4/0x9 [nfs]
       RSP <ffff880038f8fa68>
      CR2: 0000000000000028
      Signed-off-by: NBenny Halevy <bhalevy@tonian.com>
      Cc: stable@kernel.org [>= 3.6]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      78f33277
  4. 23 2月, 2013 2 次提交
    • T
      SUNRPC: Don't start the retransmission timer when out of socket space · a9a6b52e
      Trond Myklebust 提交于
      If the socket is full, we're better off just waiting until it empties,
      or until the connection is broken. The reason why we generally don't
      want to time out is that the call to xprt->ops->release_xprt() will
      trigger a connection reset, which isn't helpful...
      
      Let's make an exception for soft RPC calls, since they have to provide
      timeout guarantees.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org
      a9a6b52e
    • T
      NFS: Don't allow NFS silly-renamed files to be deleted, no signal · 5a7a613a
      Trond Myklebust 提交于
      Commit 73ca1001 broke the code that prevents the client from deleting
      a silly renamed dentry.  This affected "delete on last close"
      semantics as after that commit, nothing prevented removal of
      silly-renamed files.  As a result, a process holding a file open
      could easily get an ESTALE on the file in a directory where some
      other process issued 'rm -rf some_dir_containing_the_file' twice.
      Before the commit, any attempt at unlinking silly renamed files would
      fail inside may_delete() with -EBUSY because of the
      DCACHE_NFSFS_RENAMED flag.  The following testcase demonstrates
      the problem:
        tail -f /nfsmnt/dir/file &
        rm -rf /nfsmnt/dir
        rm -rf /nfsmnt/dir
        # second removal does not fail, 'tail' process receives ESTALE
      
      The problem with the above commit is that it unhashes the old and
      new dentries from the lookup path, even in the normal case when
      a signal is not encountered and it would have been safe to call
      d_move.  Unfortunately the old dentry has the special
      DCACHE_NFSFS_RENAMED flag set on it.  Unhashing has the
      side-effect that future lookups call d_alloc(), allocating a new
      dentry without the special flag for any silly-renamed files.  As a
      result, subsequent calls to unlink silly renamed files do not fail
      but allow the removal to go through.  This will result in ESTALE
      errors for any other process doing operations on the file.
      
      To fix this, go back to using d_move on success.
      For the signal case, it's unclear what we may safely do beyond d_drop.
      Reported-by: NDave Wysochanski <dwysocha@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Cc: stable@vger.kernel.org
      5a7a613a
  5. 20 2月, 2013 1 次提交
  6. 18 2月, 2013 4 次提交
    • F
      umount oops when remove blocklayoutdriver first · 5a12cca6
      fanchaoting 提交于
      now pnfs client uses block layout, maybe we can remove
      blocklayoutdriver first. if we umount later,
      it can cause oops in unset_pnfs_layoutdriver.
      because nfss->pnfs_curr_ld->clear_layoutdriver is invalid.
      
      reproduce it:
       modprobe  blocklayoutdriver
       mount -t nfs4 -o minorversion=1 pnfsip:/ /mnt/
       rmmod blocklayoutdriver
       umount /mnt
      
      then you can see following
      
      CPU 0
      Pid: 17023, comm: umount.nfs4 Tainted: GF          O 3.7.0-rc6-pnfs #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
      RIP: 0010:[<ffffffffa04cfe6d>]  [<ffffffffa04cfe6d>] unset_pnfs_layoutdriver+0x1d/0x70 [nfsv4]
      RSP: 0018:ffff8800022d9e48  EFLAGS: 00010286
      RAX: ffffffffa04a1b00 RBX: ffff88000b013800 RCX: 0000000000000001
      RDX: ffffffff81ae8ee0 RSI: ffff880001ee94b8 RDI: ffff88000b013800
      RBP: ffff8800022d9e58 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff880001ee9400
      R13: ffff8800105978c0 R14: 00007fff25846c08 R15: 0000000001bba550
      FS:  00007f45ae7f0700(0000) GS:ffff880012c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: ffffffffa04a1b38 CR3: 0000000002c0c000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process umount.nfs4 (pid: 17023, threadinfo ffff8800022d8000, task ffff880006e48aa0)
      Stack:
      ffff8800105978c0 ffff88000b013800 ffff8800022d9e78 ffffffffa04cd0ce
      ffff8800022d9e78 ffff88000b013800 ffff8800022d9ea8 ffffffffa04755a7
      ffff8800022d9ea8 ffff880002f96400 ffff88000b013800 ffff880002f96400
      Call Trace:
      [<ffffffffa04cd0ce>] nfs4_destroy_server+0x1e/0x30 [nfsv4]
      [<ffffffffa04755a7>] nfs_free_server+0xb7/0x150 [nfs]
      [<ffffffffa047d4d5>] nfs_kill_super+0x35/0x40 [nfs]
      [<ffffffff81178d35>] deactivate_locked_super+0x45/0x70
      [<ffffffff8117986a>] deactivate_super+0x4a/0x70
      [<ffffffff81193ee2>] mntput_no_expire+0xd2/0x130
      [<ffffffff81194d62>] sys_umount+0x72/0xe0
      [<ffffffff8154af59>] system_call_fastpath+0x16/0x1b
      Code: 06 e1 b8 ea ff ff ff eb 9e 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 8b 87 80 03 00 00 48 89 fb 48 85 c0 74 29 <48> 8b 40 38 48 85 c0 74 02 ff d0 48 8b 03 3e ff 48 04 0f 94 c2
      RIP  [<ffffffffa04cfe6d>] unset_pnfs_layoutdriver+0x1d/0x70 [nfsv4]
      RSP <ffff8800022d9e48>
      CR2: ffffffffa04a1b38
      ---[ end trace 29f75aaedda058bf ]---
      
      Signed-off-by: fanchaoting<fanchaoting@cn.fujitsu.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org
      5a12cca6
    • J
      sunrpc: silence build warning in gss_fill_context · 173db309
      Jeff Layton 提交于
      Since commit 620038f6, gcc is throwing the following warning:
      
        CC [M]  net/sunrpc/auth_gss/auth_gss.o
      In file included from include/linux/sunrpc/types.h:14:0,
                       from include/linux/sunrpc/sched.h:14,
                       from include/linux/sunrpc/clnt.h:18,
                       from net/sunrpc/auth_gss/auth_gss.c:45:
      net/sunrpc/auth_gss/auth_gss.c: In function ‘gss_pipe_downcall’:
      include/linux/sunrpc/debug.h:45:10: warning: ‘timeout’ may be used
      uninitialized in this function [-Wmaybe-uninitialized]
          printk(KERN_DEFAULT args); \
                ^
      net/sunrpc/auth_gss/auth_gss.c:194:15: note: ‘timeout’ was declared here
        unsigned int timeout;
                     ^
      If simple_get_bytes returns an error, then we'll end up calling printk
      with an uninitialized timeout value. Reasonably harmless, but fairly
      simple to fix by removing the printout of the uninitialised parameters.
      
      Cc: Andy Adamson <andros@netapp.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      [Trond: just remove the parameters rather than initialising timeout]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      173db309
    • T
      nfs: remove kfree() redundant null checks · 96aa1549
      Tim Gardner 提交于
      smatch analysis:
      
      fs/nfs/getroot.c:130 nfs_get_root() info: redundant null
       check on name calling kfree()
      
      fs/nfs/unlink.c:272 nfs_async_unlink() info: redundant null
       check on devname_garbage calling kfree()
      
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: linux-nfs@vger.kernel.org
      Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      96aa1549
    • W
      NFSv4.1: Don't decode skipped layoutgets · 085b7a45
      Weston Andros Adamson 提交于
      layoutget's prepare hook can call rpc_exit with status = NFS4_OK (0).
      Because of this, nfs4_proc_layoutget can't depend on a 0 status to mean
      that the RPC was successfully sent, received and parsed.
      
      To fix this, use the result's len member to see if parsing took place.
      
      This fixes the following OOPS -- calling xdr_init_decode() with a buffer length
      0 doesn't set the stream's 'p' member and ends up using uninitialized memory
      in filelayout_decode_layout.
      
      BUG: unable to handle kernel paging request at 0000000000008050
      IP: [<ffffffff81282e78>] memcpy+0x18/0x120
      PGD 0
      Oops: 0000 [#1] SMP
      last sysfs file: /sys/devices/pci0000:00/0000:00:11.0/0000:02:01.0/irq
      CPU 1
      Modules linked in: nfs_layout_nfsv41_files nfs lockd fscache auth_rpcgss nfs_acl autofs4 sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log dm_mod ppdev parport_pc parport snd_ens1371 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc e1000 microcode vmware_balloon i2c_piix4 i2c_core sg shpchp ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptspi mptscsih mptbase scsi_transport_spi [last unloaded: speedstep_lib]
      
      Pid: 1665, comm: flush-0:22 Not tainted 2.6.32-356-test-2 #2 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
      RIP: 0010:[<ffffffff81282e78>]  [<ffffffff81282e78>] memcpy+0x18/0x120
      RSP: 0018:ffff88003dfab588  EFLAGS: 00010206
      RAX: ffff88003dc42000 RBX: ffff88003dfab610 RCX: 0000000000000009
      RDX: 000000003f807ff0 RSI: 0000000000008050 RDI: ffff88003dc42000
      RBP: ffff88003dfab5b0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000080 R12: 0000000000000024
      R13: ffff88003dc42000 R14: ffff88003f808030 R15: ffff88003dfab6a0
      FS:  0000000000000000(0000) GS:ffff880003420000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 0000000000008050 CR3: 000000003bc92000 CR4: 00000000001407e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process flush-0:22 (pid: 1665, threadinfo ffff88003dfaa000, task ffff880037f77540)
      Stack:
      ffffffffa0398ac1 ffff8800397c5940 ffff88003dfab610 ffff88003dfab6a0
      <d> ffff88003dfab5d0 ffff88003dfab680 ffffffffa01c150b ffffea0000d82e70
      <d> 000000508116713b 0000000000000000 0000000000000000 0000000000000000
      Call Trace:
      [<ffffffffa0398ac1>] ? xdr_inline_decode+0xb1/0x120 [sunrpc]
      [<ffffffffa01c150b>] filelayout_decode_layout+0xeb/0x350 [nfs_layout_nfsv41_files]
      [<ffffffffa01c17fc>] filelayout_alloc_lseg+0x8c/0x3c0 [nfs_layout_nfsv41_files]
      [<ffffffff8150e6ce>] ? __wait_on_bit+0x7e/0x90
      Signed-off-by: NWeston Andros Adamson <dros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org
      085b7a45
  7. 15 2月, 2013 1 次提交
    • T
      NFSv4.1: Fix bulk recall and destroy of layouts · fd9a8d71
      Trond Myklebust 提交于
      The current code in pnfs_destroy_all_layouts() assumes that removing
      the layout from the server->layouts list is sufficient to make it
      invisible to other processes. This ignores the fact that most
      users access the layout through the nfs_inode->layout...
      There is further breakage due to lack of reference counting of the
      layouts, meaning that the whole thing Oopses at the drop of a hat.
      
      The code in initiate_bulk_draining() is almost correct, and can be
      used as a model for pnfs_destroy_all_layouts(), so move that
      code to pnfs.c, and refactor the code to allow us to choose between
      a single filesystem bulk recall, and a recall of all layouts.
      Also note that initiate_bulk_draining() currently calls iput() while
      holding locks. Fix that too.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org
      fd9a8d71
  8. 12 2月, 2013 7 次提交
  9. 01 2月, 2013 15 次提交
  10. 31 1月, 2013 7 次提交
    • A
      MIPS: Function tracer: Fix broken function tracing · 58b69401
      Al Cooper 提交于
      Function tracing is currently broken for all 32 bit MIPS platforms.
      When tracing is enabled, the kernel immediately hangs on boot.
      This is a result of commit b732d439
      that changes the kernel/trace/Kconfig file so that is no longer
      forces FRAME_POINTER when FUNCTION_TRACING is enabled.
      
      MIPS frame pointers are generally considered to be useless because
      they cannot be used to unwind the stack. Unfortunately the MIPS
      function tracing code has bugs that are masked by the use of frame
      pointers. This commit fixes the bugs so that MIPS frame pointers
      don't need to be enabled.
      
      The bugs are a result of the odd calling sequence used to call the trace
      routine. This calling sequence is inserted into every traceable function
      when the tracing CONFIG option is enabled. This sequence is generated
      for 32bit MIPS platforms by the compiler via the "-pg" flag.
      
      Part of the sequence is "addiu sp,sp,-8" in the delay slot after every
      call to the trace routine "_mcount" (some legacy thing where 2 arguments
      used to be pushed on the stack). The _mcount routine is expected to
      adjust the sp by +8 before returning.  So when not disabled, the original
      jalr and addiu will be there, so _mcount has to adjust sp.
      
      The problem is that when tracing is disabled for a function, the
      "jalr _mcount" instruction is replaced with a nop, but the
      "addiu sp,sp,-8" is still executed and the stack pointer is left
      trashed. When frame pointers are enabled the problem is masked
      because any access to the stack is done through the frame
      pointer and the stack pointer is restored from the frame pointer when
      the function returns.
      
      This patch writes two nops starting at the address of the "jalr _mcount"
      instruction whenever tracing is disabled. This means that the
      "addiu sp,sp.-8" will be converted to a nop along with the "jalr".  When
      disabled, there will be two nops.
      
      This is SMP safe because the first time this happens is during
      ftrace_init() which is before any other processor has been started.
      Subsequent calls to enable/disable tracing when other CPUs ARE running
      will still be safe because the enable will only change the first nop
      to a "jalr" and the disable, while writing 2 nops, will only be changing
      the "jalr". This patch also stops using stop_machine() to call the
      tracer enable/disable routines and calls them directly because the
      routines are SMP safe.
      
      When the kernel first boots we have to be able to handle the gcc
      generated jalr, addui sequence until ftrace_init gets a chance to run
      and change the sequence. At this point mcount just adjusts the stack
      and returns. When ftrace_init runs, we convert the jalr/addui to nops.
      Then whenever tracing is enabled we convert the first nop to a "jalr
      mcount+8". The mcount+8 entry point skips the stack adjust.
      
      [ralf@linux-mips.org: Folded in  Steven Rostedt's build fix.]
      Signed-off-by: NAl Cooper <alcooperx@gmail.com>
      Cc: rostedt@goodmis.org
      Cc: ddaney.cavm@gmail.com
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/4806/
      Patchwork: https://patchwork.linux-mips.org/patch/4841/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      58b69401
    • A
      dm: fix write same requests counting · fe7af2d3
      Alasdair G Kergon 提交于
      When processing write same requests, fix dm to send the configured
      number of WRITE SAME requests to the target rather than the number of
      discards, which is not always the same.
      
      Device-mapper WRITE SAME support was introduced by commit
      23508a96 ("dm: add WRITE SAME support").
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      Acked-by: NMike Snitzer <snitzer@redhat.com>
      fe7af2d3
    • S
      mips: Move __virt_addr_valid() to a place for MIPS 64 · 196897a2
      Steven Rostedt 提交于
      Commit d3ce8843 "MIPS: Fix modpost error in modules attepting to use
      virt_addr_valid()" moved __virt_addr_valid() from a macro in a header
      file to a function in ioremap.c. But ioremap.c is only compiled for MIPS
      32, and not for MIPS 64.
      
      When compiling for my yeeloong2, which supposedly supports hibernation,
      which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I
      got this error:
      
        LD      init/built-in.o
      kernel/built-in.o: In function `memory_bm_free':
      snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid'
      snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid'
      kernel/built-in.o: In function `snapshot_write_next':
      (.text+0x4e44c): undefined reference to `__virt_addr_valid'
      kernel/built-in.o: In function `snapshot_write_next':
      (.text+0x4e890): undefined reference to `__virt_addr_valid'
      make[1]: *** [vmlinux] Error 1
      make: *** [sub-make] Error 2
      
      I suspect that __virt_addr_valid() is fine for mips 64. I moved it to
      mmap.c such that it gets compiled for mips 64 and 32.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/4842/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      196897a2
    • M
      dm thin: fix queue limits stacking · 0f640dca
      Mike Snitzer 提交于
      thin_io_hints() is blindly copying the queue limits from the thin-pool
      which can lead to incorrect limits being set.  The fix here simply
      deletes the thin_io_hints() hook which leaves the existing stacking
      infrastructure to set the limits correctly.
      
      When a thin-pool uses an MD device for the data device a thin device
      from the thin-pool must respect MD's constraints about disallowing a bio
      from spanning multiple chunks.  Otherwise we can see problems.  If the raid0
      chunksize is 1152K and thin-pool chunksize is 256K I see the following
      md/raid0 error (with extra debug tracing added to thin_endio) when
      mkfs.xfs is executed against the thin device:
      
      md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127
      device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0
      
      This extra DM debugging shows that the failing bio is spanning across
      the first and second logical 1152K chunk (sector 2080 + 255 takes the
      bio beyond the first chunk's boundary of sector 2304).  So the bio
      splitting that DM is doing clearly isn't respecting the MD limits.
      
      max_hw_sectors_kb is 127 for both the thin-pool and thin device
      (queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of
      precision).  So this explains why bi_size is 130560.
      
      But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given
      that it doesn't have a .merge function (for bio_add_page to consult
      indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD
      device that has a compulsory merge_bvec_fn.  This scenario is exactly
      why DM must resort to sending single PAGE_SIZE bios to the underlying
      layer. Some additional context for this is available in the header for
      commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries").
      
      Long story short, the reason a thin device doesn't properly get
      configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that
      thin_io_hints() is blindly copying the queue limits from the thin-pool
      device directly to the thin device's queue limits.
      
      Fix this by eliminating thin_io_hints.  Doing so is safe because the
      block layer's queue limits stacking already enables the upper level thin
      device to inherit the thin-pool device's discard and minimum_io_size and
      optimal_io_size limits that get set in pool_io_hints.  But avoiding the
      queue limits copy allows the thin and thin-pool limits to be different
      where it is important, namely max_hw_sectors_kb.
      Reported-by: NDaniel Browning <db@kavod.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      0f640dca
    • L
      Merge branch 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 04c2eee5
      Linus Torvalds 提交于
      Pull x86 EFI fixes from Peter Anvin:
       "This is a collection of fixes for the EFI support.  The controversial
        bit here is a set of patches which bumps the boot protocol version as
        part of fixing some serious problems with the EFI handover protocol,
        used when booting under EFI using a bootloader as opposed to directly
        from EFI.  These changes should also make it a lot saner to support
        cross-mode 32/64-bit EFI booting in the future.  Getting these changes
        into 3.8 means we avoid presenting an inconsistent ABI to bootloaders.
      
        Other changes are display detection and fixing efivarfs."
      
      * 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, efi: remove attribute check from setup_efi_pci
        x86, build: Dynamically find entry points in compressed startup code
        x86, efi: Fix PCI ROM handing in EFI boot stub, in 32-bit mode
        x86, efi: Fix 32-bit EFI handover protocol entry point
        x86, efi: Fix display detection in EFI boot stub
        x86, boot: Define the 2.12 bzImage boot protocol
        x86/boot: Fix minor fd leakage in tools/relocs.c
        x86, efi: Set runtime_version to the EFI spec revision
        x86, efi: fix 32-bit warnings in setup_efi_pci()
        efivarfs: Delete dentry from dcache in efivarfs_file_write()
        efivarfs: Never return ENOENT from firmware
        efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
        efivarfs: Drop link count of the right inode
      04c2eee5
    • L
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · bdb0ae6a
      Linus Torvalds 提交于
      Pull x86 fixes from Peter Anvin:
       "This is a collection of miscellaneous fixes, the most important one is
        the fix for the Samsung laptop bricking issue (auto-blacklisting the
        samsung-laptop driver); the efi_enabled() changes you see below are
        prerequisites for that fix.
      
        The other issues fixed are booting on OLPC XO-1.5, an UV fix, NMI
        debugging, and requiring CAP_SYS_RAWIO for MSR references, just as
        with I/O port references."
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        samsung-laptop: Disable on EFI hardware
        efi: Make 'efi_enabled' a function to query EFI facilities
        smp: Fix SMP function call empty cpu mask race
        x86/msr: Add capabilities check
        x86/dma-debug: Bump PREALLOC_DMA_DEBUG_ENTRIES
        x86/olpc: Fix olpc-xo1-sci.c build errors
        arch/x86/platform/uv: Fix incorrect tlb flush all issue
        x86-64: Fix unwind annotations in recent NMI changes
        x86-32: Start out cr0 clean, disable paging before modifying cr3/4
      bdb0ae6a
    • L
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 0fe94b9e
      Linus Torvalds 提交于
      Pull console lockdep checking revert from Dave Airlie.
      
      The lockdep splat this showed was interesting, but it's very very old,
      and we won't be fixing it until 3.9.  In the meantime, undo the lockdep
      annotation so that we don't generate the (known) console lockdep issue,
      and then possibly hide any potential other (unknown) lockdep problems
      that got disabled by the first one that triggered.
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        Revert "console: implement lockdep support for console_lock"
      0fe94b9e