1. 12 4月, 2015 1 次提交
  2. 13 3月, 2015 2 次提交
    • M
      9p/trans_virtio: fix hot-unplug · 8051a2a5
      Michael S. Tsirkin 提交于
      On device hot-unplug, 9p/virtio currently will kfree channel while
      it might still be in use.
      
      Of course, it might stay used forever, so it's an extremely ugly hack,
      but it seems better than use-after-free that we have now.
      
      [ Unused variable removed, whitespace cleanup, msg single-lined --RR ]
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      8051a2a5
    • E
      net: Introduce possible_net_t · 0c5c9fb5
      Eric W. Biederman 提交于
      Having to say
      > #ifdef CONFIG_NET_NS
      > 	struct net *net;
      > #endif
      
      in structures is a little bit wordy and a little bit error prone.
      
      Instead it is possible to say:
      > typedef struct {
      > #ifdef CONFIG_NET_NS
      >       struct net *net;
      > #endif
      > } possible_net_t;
      
      And then in a header say:
      
      > 	possible_net_t net;
      
      Which is cleaner and easier to use and easier to test, as the
      possible_net_t is always there no matter what the compile options.
      
      Further this allows read_pnet and write_pnet to be functions in all
      cases which is better at catching typos.
      
      This change adds possible_net_t, updates the definitions of read_pnet
      and write_pnet, updates optional struct net * variables that
      write_pnet uses on to have the type possible_net_t, and finally fixes
      up the b0rked users of read_pnet and write_pnet.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c5c9fb5
  3. 21 1月, 2015 1 次提交
  4. 15 10月, 2014 1 次提交
  5. 16 7月, 2014 1 次提交
  6. 26 3月, 2014 8 次提交
  7. 11 2月, 2014 1 次提交
    • R
      9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers · b6f52ae2
      Richard Yao 提交于
      The 9p-virtio transport does zero copy on things larger than 1024 bytes
      in size. It accomplishes this by returning the physical addresses of
      pages to the virtio-pci device. At present, the translation is usually a
      bit shift.
      
      That approach produces an invalid page address when we read/write to
      vmalloc buffers, such as those used for Linux kernel modules. Any
      attempt to load a Linux kernel module from 9p-virtio produces the
      following stack.
      
      [<ffffffff814878ce>] p9_virtio_zc_request+0x45e/0x510
      [<ffffffff814814ed>] p9_client_zc_rpc.constprop.16+0xfd/0x4f0
      [<ffffffff814839dd>] p9_client_read+0x15d/0x240
      [<ffffffff811c8440>] v9fs_fid_readn+0x50/0xa0
      [<ffffffff811c84a0>] v9fs_file_readn+0x10/0x20
      [<ffffffff811c84e7>] v9fs_file_read+0x37/0x70
      [<ffffffff8114e3fb>] vfs_read+0x9b/0x160
      [<ffffffff81153571>] kernel_read+0x41/0x60
      [<ffffffff810c83ab>] copy_module_from_fd.isra.34+0xfb/0x180
      
      Subsequently, QEMU will die printing:
      
      qemu-system-x86_64: virtio: trying to map MMIO memory
      
      This patch enables 9p-virtio to correctly handle this case. This not
      only enables us to load Linux kernel modules off virtfs, but also
      enables ZFS file-based vdevs on virtfs to be used without killing QEMU.
      
      Special thanks to both Avi Kivity and Alexander Graf for their
      interpretation of QEMU backtraces. Without their guidence, tracking down
      this bug would have taken much longer. Also, special thanks to Linus
      Torvalds for his insightful explanation of why this should use
      is_vmalloc_addr() instead of is_vmalloc_or_module_addr():
      
      https://lkml.org/lkml/2014/2/8/272Signed-off-by: NRichard Yao <ryao@gentoo.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6f52ae2
  8. 10 2月, 2014 1 次提交
  9. 24 11月, 2013 1 次提交
  10. 25 10月, 2013 1 次提交
  11. 17 10月, 2013 1 次提交
  12. 26 8月, 2013 2 次提交
    • W
      fs/9p: avoid accessing utsname after namespace has been torn down · 50192abe
      Will Deacon 提交于
      During trinity fuzzing in a kvmtool guest, I stumbled across the
      following:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000004
      PC is at v9fs_file_do_lock+0xc8/0x1a0
      LR is at v9fs_file_do_lock+0x48/0x1a0
      [<c01e2ed0>] (v9fs_file_do_lock+0xc8/0x1a0) from [<c0119154>] (locks_remove_flock+0x8c/0x124)
      [<c0119154>] (locks_remove_flock+0x8c/0x124) from [<c00d9bf0>] (__fput+0x58/0x1e4)
      [<c00d9bf0>] (__fput+0x58/0x1e4) from [<c0044340>] (task_work_run+0xac/0xe8)
      [<c0044340>] (task_work_run+0xac/0xe8) from [<c002e36c>] (do_exit+0x6bc/0x8d8)
      [<c002e36c>] (do_exit+0x6bc/0x8d8) from [<c002e674>] (do_group_exit+0x3c/0xb0)
      [<c002e674>] (do_group_exit+0x3c/0xb0) from [<c002e6f8>] (__wake_up_parent+0x0/0x18)
      
      I believe this is due to an attempt to access utsname()->nodename, after
      exit_task_namespaces() has been called, leaving current->nsproxy->uts_ns
      as NULL and causing the above dereference.
      
      A similar issue was fixed for lockd in 9a1b6bf8 ("LOCKD: Don't call
      utsname()->nodename from nlmclnt_setlockargs"), so this patch attempts
      something similar for 9pfs.
      
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Ron Minnich <rminnich@sandia.gov>
      Cc: Latchesar Ionkov <lucho@ionkov.net>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      50192abe
    • M
      9p: send uevent after adding/removing mount_tag attribute · e0d6cb9c
      Michael Marineau 提交于
      This driver adds an attribute to the existing virtio device so a CHANGE
      event is required in order udev rules to make use of it. The ADD event
      happens before this driver is probed and unlike a more typical driver
      like a block device there isn't a higher level device to watch for.
      Signed-off-by: NMichael Marineau <michael.marineau@coreos.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      e0d6cb9c
  13. 31 7月, 2013 1 次提交
  14. 25 7月, 2013 1 次提交
  15. 12 7月, 2013 1 次提交
    • S
      9p: fix off by one causing access violations and memory corruption · 110ecd69
      Sasha Levin 提交于
      p9_release_pages() would attempt to dereference one value past the end of
      pages[]. This would cause the following crashes:
      
      [ 6293.171817] BUG: unable to handle kernel paging request at ffff8807c96f3000
      [ 6293.174146] IP: [<ffffffff8412793b>] p9_release_pages+0x3b/0x60
      [ 6293.176447] PGD 79c5067 PUD 82c1e3067 PMD 82c197067 PTE 80000007c96f3060
      [ 6293.180060] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [ 6293.180060] Modules linked in:
      [ 6293.180060] CPU: 62 PID: 174043 Comm: modprobe Tainted: G        W    3.10.0-next-20130710-sasha #3954
      [ 6293.180060] task: ffff8807b803b000 ti: ffff880787dde000 task.ti: ffff880787dde000
      [ 6293.180060] RIP: 0010:[<ffffffff8412793b>]  [<ffffffff8412793b>] p9_release_pages+0x3b/0x60
      [ 6293.214316] RSP: 0000:ffff880787ddfc28  EFLAGS: 00010202
      [ 6293.214316] RAX: 0000000000000001 RBX: ffff8807c96f2ff8 RCX: 0000000000000000
      [ 6293.222017] RDX: ffff8807b803b000 RSI: 0000000000000001 RDI: ffffea001c7e3d40
      [ 6293.222017] RBP: ffff880787ddfc48 R08: 0000000000000000 R09: 0000000000000000
      [ 6293.222017] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
      [ 6293.222017] R13: 0000000000000001 R14: ffff8807cc50c070 R15: ffff8807cc50c070
      [ 6293.222017] FS:  00007f572641d700(0000) GS:ffff8807f3600000(0000) knlGS:0000000000000000
      [ 6293.256784] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 6293.256784] CR2: ffff8807c96f3000 CR3: 00000007c8e81000 CR4: 00000000000006e0
      [ 6293.256784] Stack:
      [ 6293.256784]  ffff880787ddfcc8 ffff880787ddfcc8 0000000000000000 ffff880787ddfcc8
      [ 6293.256784]  ffff880787ddfd48 ffffffff84128be8 ffff880700000002 0000000000000001
      [ 6293.256784]  ffff8807b803b000 ffff880787ddfce0 0000100000000000 0000000000000000
      [ 6293.256784] Call Trace:
      [ 6293.256784]  [<ffffffff84128be8>] p9_virtio_zc_request+0x598/0x630
      [ 6293.256784]  [<ffffffff8115c610>] ? wake_up_bit+0x40/0x40
      [ 6293.256784]  [<ffffffff841209b1>] p9_client_zc_rpc+0x111/0x3a0
      [ 6293.256784]  [<ffffffff81174b78>] ? sched_clock_cpu+0x108/0x120
      [ 6293.256784]  [<ffffffff84122a21>] p9_client_read+0xe1/0x2c0
      [ 6293.256784]  [<ffffffff81708a90>] v9fs_file_read+0x90/0xc0
      [ 6293.256784]  [<ffffffff812bd073>] vfs_read+0xc3/0x130
      [ 6293.256784]  [<ffffffff811a78bd>] ? trace_hardirqs_on+0xd/0x10
      [ 6293.256784]  [<ffffffff812bd5a2>] SyS_read+0x62/0xa0
      [ 6293.256784]  [<ffffffff841a1a00>] tracesys+0xdd/0xe2
      [ 6293.256784] Code: 66 90 48 89 fb 41 89 f5 48 8b 3f 48 85 ff 74 29 85 f6 74 25 45 31 e4 66 0f 1f 84 00 00 00 00 00 e8 eb 14 12 fd 41 ff c4 49 63 c4 <48> 8b 3c c3 48 85 ff 74 05 45 39 e5 75 e7 48 83 c4 08 5b 41 5c
      [ 6293.256784] RIP  [<ffffffff8412793b>] p9_release_pages+0x3b/0x60
      [ 6293.256784]  RSP <ffff880787ddfc28>
      [ 6293.256784] CR2: ffff8807c96f3000
      [ 6293.256784] ---[ end trace 50822ee72cd360fc ]---
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      110ecd69
  16. 08 7月, 2013 11 次提交
  17. 29 5月, 2013 1 次提交
  18. 28 5月, 2013 3 次提交
  19. 20 3月, 2013 1 次提交