1. 08 Mar, 2014 1 commit
    • Ditang Chen's avatar
      SUNRPC: Fix oops when trace sunrpc_task events in nfs client · 2ca310fc
      Ditang Chen authored
      When tracking sunrpc_task events in nfs client, the clnt pointer may be NULL.
      
      [  139.269266] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
      [  139.269915] IP: [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915] PGD 1d293067 PUD 1d294067 PMD 0
      [  139.269915] Oops: 0000 [#1] SMP
      [  139.269915] Modules linked in: nfsv4 dns_resolver nfs lockd sunrpc fscache sg ppdev e1000
      serio_raw pcspkr parport_pc parport i2c_piix4 i2c_core microcode xfs libcrc32c sd_mod sr_mod
      cdrom ata_generic crc_t10dif crct10dif_common pata_acpi ahci libahci ata_piix libata dm_mirror
      dm_region_hash dm_log dm_mod
      [  139.269915] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 3.10.0-84.el7.x86_64 #1
      [  139.269915] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  139.269915] Workqueue: rpciod rpc_async_schedule [sunrpc]
      [  139.269915] task: ffff88001b598000 ti: ffff88001b632000 task.ti: ffff88001b632000
      [  139.269915] RIP: 0010:[<ffffffffa026f216>]  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915] RSP: 0018:ffff88001b633d70  EFLAGS: 00010206
      [  139.269915] RAX: ffff88001dfc5338 RBX: ffff88001cc37a00 RCX: ffff88001dfc5334
      [  139.269915] RDX: ffff88001dfc5338 RSI: 0000000000000000 RDI: ffff88001dfc533c
      [  139.269915] RBP: ffff88001b633db0 R08: 000000000000002c R09: 000000000000000a
      [  139.269915] R10: 0000000000062180 R11: 00000020759fb9dc R12: ffffffffa0292c20
      [  139.269915] R13: ffff88001dfc5334 R14: 0000000000000000 R15: 0000000000000000
      [  139.269915] FS:  0000000000000000(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
      [  139.269915] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  139.269915] CR2: 0000000000000004 CR3: 000000001d290000 CR4: 00000000000006f0
      [  139.269915] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  139.269915] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  139.269915] Stack:
      [  139.269915]  000000001b633d98 0000000000000246 ffff88001df1dc00 ffff88001cc37a00
      [  139.269915]  ffff88001bc35e60 0000000000000000 ffff88001ffa0a48 ffff88001bc35ee0
      [  139.269915]  ffff88001b633e08 ffffffffa02704b5 0000000000010000 ffff88001cc37a70
      [  139.269915] Call Trace:
      [  139.269915]  [<ffffffffa02704b5>] __rpc_execute+0x1d5/0x400 [sunrpc]
      [  139.269915]  [<ffffffffa0270706>] rpc_async_schedule+0x26/0x30 [sunrpc]
      [  139.269915]  [<ffffffff8107867b>] process_one_work+0x17b/0x460
      [  139.269915]  [<ffffffff8107942b>] worker_thread+0x11b/0x400
      [  139.269915]  [<ffffffff81079310>] ? rescuer_thread+0x3e0/0x3e0
      [  139.269915]  [<ffffffff8107fc80>] kthread+0xc0/0xd0
      [  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
      [  139.269915]  [<ffffffff815d122c>] ret_from_fork+0x7c/0xb0
      [  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
      [  139.269915] Code: 4c 8b 45 c8 48 8d 7d d0 89 4d c4 41 89 c9 b9 28 00 00 00 e8 9d b4 e9
      e0 48 85 c0 49 89 c5 74 a2 48 89 c7 e8 9d 3f e9 e0 48 89 c2 <41> 8b 46 04 48 8b 7d d0 4c
      89 e9 4c 89 e6 89 42 0c 0f b7 83 d4
      [  139.269915] RIP  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915]  RSP <ffff88001b633d70>
      [  139.269915] CR2: 0000000000000004
      [  140.946406] ---[ end trace ba486328b98d7622 ]---
      Signed-off-by: default avatarDitang Chen <chendt.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      2ca310fc
  2. 05 Mar, 2014 4 commits
  3. 03 Mar, 2014 1 commit
  4. 01 Mar, 2014 1 commit
  5. 19 Feb, 2014 1 commit
  6. 17 Feb, 2014 1 commit
  7. 16 Feb, 2014 2 commits
  8. 11 Feb, 2014 2 commits
  9. 10 Feb, 2014 6 commits
  10. 09 Feb, 2014 9 commits
    • Al Viro's avatar
      fix a kmap leak in virtio_console · c9efe511
      Al Viro authored
      While we are at it, don't do kmap() under kmap_atomic(), *especially*
      for a page we'd allocated with GFP_KERNEL.  It's spelled "page_address",
      and had that been more than that, we'd have a real trouble - kmap_high()
      can block, and doing that while holding kmap_atomic() is a Bad Idea(tm).
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      c9efe511
    • Al Viro's avatar
      fix O_SYNC|O_APPEND syncing the wrong range on write() · d311d79d
      Al Viro authored
      It actually goes back to 2004 ([PATCH] Concurrent O_SYNC write support)
      when sync_page_range() had been introduced; generic_file_write{,v}() correctly
      synced
      	pos_after_write - written .. pos_after_write - 1
      but generic_file_aio_write() synced
      	pos_before_write .. pos_before_write + written - 1
      instead.  Which is not the same thing with O_APPEND, obviously.
      A couple of years later correct variant had been killed off when
      everything switched to use of generic_file_aio_write().
      
      All users of generic_file_aio_write() are affected, and the same bug
      has been copied into other instances of ->aio_write().
      
      The fix is trivial; the only subtle point is that generic_write_sync()
      ought to be inlined to avoid calculations useless for the majority of
      calls.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      d311d79d
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · 9c1db779
      Linus Torvalds authored
      Pull btrfs fixes from Chris Mason:
       "This is a small collection of fixes"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
        Btrfs: fix data corruption when reading/updating compressed extents
        Btrfs: don't loop forever if we can't run because of the tree mod log
        btrfs: reserve no transaction units in btrfs_ioctl_set_features
        btrfs: commit transaction after setting label and features
        Btrfs: fix assert screwup for the pending move stuff
      9c1db779
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 6f2a1c1e
      Linus Torvalds authored
      Pull perf fixes from Ingo Molnar:
       "Tooling fixes, mostly related to the KASLR fallout, but also other
        fixes"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf buildid-cache: Check relocation when checking for existing kcore
        perf tools: Adjust kallsyms for relocated kernel
        perf tests: No need to set up ref_reloc_sym
        perf symbols: Prevent the use of kcore if the kernel has moved
        perf record: Get ref_reloc_sym from kernel map
        perf machine: Set up ref_reloc_sym in machine__create_kernel_maps()
        perf machine: Add machine__get_kallsyms_filename()
        perf tools: Add kallsyms__get_function_start()
        perf symbols: Fix symbol annotation for relocated kernel
        perf tools: Fix include for non x86 architectures
        perf tools: Fix AAAAARGH64 memory barriers
        perf tools: Demangle kernel and kernel module symbols too
        perf/doc: Remove mention of non-existent set_perf_event_pending() from design.txt
      6f2a1c1e
    • Filipe David Borba Manana's avatar
      Btrfs: fix data corruption when reading/updating compressed extents · a2aa75e1
      Filipe David Borba Manana authored
      When using a mix of compressed file extents and prealloc extents, it
      is possible to fill a page of a file with random, garbage data from
      some unrelated previous use of the page, instead of a sequence of zeroes.
      
      A simple sequence of steps to get into such case, taken from the test
      case I made for xfstests, is:
      
         _scratch_mkfs
         _scratch_mount "-o compress-force=lzo"
         $XFS_IO_PROG -f -c "pwrite -S 0x06 -b 18670 266978 18670" $SCRATCH_MNT/foobar
         $XFS_IO_PROG -c "falloc 26450 665194" $SCRATCH_MNT/foobar
         $XFS_IO_PROG -c "truncate 542872" $SCRATCH_MNT/foobar
         $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar
      
      This results in the following file items in the fs tree:
      
         item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160
             inode generation 6 transid 6 size 542872 block group 0 mode 100600
         item 5 key (257 INODE_REF 256) itemoff 15863 itemsize 16
             inode ref index 2 namelen 6 name: foobar
         item 6 key (257 EXTENT_DATA 0) itemoff 15810 itemsize 53
             extent data disk byte 0 nr 0 gen 6
             extent data offset 0 nr 24576 ram 266240
             extent compression 0
         item 7 key (257 EXTENT_DATA 24576) itemoff 15757 itemsize 53
             prealloc data disk byte 12849152 nr 241664 gen 6
             prealloc data offset 0 nr 241664
         item 8 key (257 EXTENT_DATA 266240) itemoff 15704 itemsize 53
             extent data disk byte 12845056 nr 4096 gen 6
             extent data offset 0 nr 20480 ram 20480
             extent compression 2
         item 9 key (257 EXTENT_DATA 286720) itemoff 15651 itemsize 53
             prealloc data disk byte 13090816 nr 405504 gen 6
             prealloc data offset 0 nr 258048
      
      The on disk extent at offset 266240 (which corresponds to 1 single disk block),
      contains 5 compressed chunks of file data. Each of the first 4 compress 4096
      bytes of file data, while the last one only compresses 3024 bytes of file data.
      Therefore a read into the file region [285648 ; 286720[ (length = 4096 - 3024 =
      1072 bytes) should always return zeroes (our next extent is a prealloc one).
      
      The solution here is the compression code path to zero the remaining (untouched)
      bytes of the last page it uncompressed data into, as the information about how
      much space the file data consumes in the last page is not known in the upper layer
      fs/btrfs/extent_io.c:__do_readpage(). In __do_readpage we were correctly zeroing
      the remainder of the page but only if it corresponds to the last page of the inode
      and if the inode's size is not a multiple of the page size.
      
      This would cause not only returning random data on reads, but also permanently
      storing random data when updating parts of the region that should be zeroed.
      For the example above, it means updating a single byte in the region [285648 ; 286720[
      would store that byte correctly but also store random data on disk.
      
      A test case for xfstests follows soon.
      Signed-off-by: default avatarFilipe David Borba Manana <fdmanana@gmail.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      a2aa75e1
    • Josef Bacik's avatar
      Btrfs: don't loop forever if we can't run because of the tree mod log · 27a377db
      Josef Bacik authored
      A user reported a 100% cpu hang with my new delayed ref code.  Turns out I
      forgot to increase the count check when we can't run a delayed ref because of
      the tree mod log.  If we can't run any delayed refs during this there is no
      point in continuing to look, and we need to break out.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      27a377db
    • David Sterba's avatar
      btrfs: reserve no transaction units in btrfs_ioctl_set_features · 8051aa1a
      David Sterba authored
      Added in patch "btrfs: add ioctls to query/change feature bits online"
      modifications to superblock don't need to reserve metadata blocks when
      starting a transaction.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      8051aa1a
    • Jeff Mahoney's avatar
      btrfs: commit transaction after setting label and features · d0270aca
      Jeff Mahoney authored
      The set_fslabel ioctl uses btrfs_end_transaction, which means it's
      possible that the change will be lost if the system crashes, same for
      the newly set features. Let's use btrfs_commit_transaction instead.
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      d0270aca
    • Josef Bacik's avatar
      Btrfs: fix assert screwup for the pending move stuff · 6cc98d90
      Josef Bacik authored
      Wang noticed that he was failing btrfs/030 even though me and Filipe couldn't
      reproduce.  Turns out this is because Wang didn't have CONFIG_BTRFS_ASSERT set,
      which meant that a key part of Filipe's original patch was not being built in.
      This appears to be a mess up with merging Filipe's patch as it does not exist in
      his original patch.  Fix this by changing how we make sure del_waiting_dir_move
      asserts that it did not error and take the function out of the ifdef check.
      This makes btrfs/030 pass with the assert on or off.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Reviewed-by: default avatarFilipe Manana <fdmanana@gmail.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      6cc98d90
  11. 08 Feb, 2014 6 commits
  12. 07 Feb, 2014 6 commits