Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 04 11月, 2017 1 次提交
  3. 31 10月, 2017 2 次提交
  5. 20 10月, 2017 2 次提交
  7. 04 10月, 2017 2 次提交
  9. 22 9月, 2017 2 次提交
    • O
      Drivers: hv: fcopy: restore correct transfer length · 549e658a
      由 Olaf Hering 提交于 
      Till recently the expected length of bytes read by the
daemon did depend on the context. It was either hv_start_fcopy or
hv_do_fcopy. The daemon had a buffer size of two pages, which was much
larger than needed.

Now the expected length of bytes read by the
daemon changed slightly. For START_FILE_COPY it is still the size of
hv_start_fcopy.  But for WRITE_TO_FILE and the other operations it is as
large as the buffer that arrived via vmbus. In case of WRITE_TO_FILE
that is slightly larger than a struct hv_do_fcopy. Since the buffer in
the daemon was still larger everything was fine.

Currently, the daemon reads only what is actually needed.
The new buffer layout is as large as a struct hv_do_fcopy, for the
WRITE_TO_FILE operation. Since the kernel expects a slightly larger
size, hvt_op_read will return -EINVAL because the daemon will read
slightly less than expected. Address this by restoring the expected
buffer size in case of WRITE_TO_FILE.

Fixes: 'c7e490fc ("Drivers: hv: fcopy: convert to hv_utils_transport")'
Fixes: '3f2baa8a ("Tools: hv: update buffer handling in hv_fcopy_daemon")'
Signed-off-by: NOlaf Hering <olaf@aepfle.de>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      549e658a
    • D
      vmbus: don't acquire the mutex in vmbus_hvsock_device_unregister() · 33c150c2
      由 Dexuan Cui 提交于 
      Due to commit 54a66265 ("Drivers: hv: vmbus: Fix rescind handling"),
we need this patch to resolve the below deadlock:

after we get the mutex in vmbus_hvsock_device_unregister() and call
vmbus_device_unregister() -> device_unregister() -> ... -> device_release()
-> vmbus_device_release(), we'll get a deadlock, because
vmbus_device_release() tries to get the same mutex.
Signed-off-by: NDexuan Cui <decui@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Cc: stable@vger.kernel.org (4.13 and above)
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33c150c2
  11. 17 8月, 2017 8 次提交
  13. 11 8月, 2017 1 次提交
    • V
      x86/hyper-v: Use hypercall for remote TLB flush · 2ffd9e33
      由 Vitaly Kuznetsov 提交于 
      Hyper-V host can suggest us to use hypercall for doing remote TLB flush,
this is supposed to work faster than IPIs.

Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls
we need to put the input somewhere in memory and we don't really want to
have memory allocation on each call so we pre-allocate per cpu memory areas
on boot.

pv_ops patching is happening very early so we need to separate
hyperv_setup_mmu_ops() and hyper_alloc_mmu().

It is possible and easy to implement local TLB flushing too and there is
even a hint for that. However, I don't see a room for optimization on the
host side as both hypercall and native tlb flush will result in vmexit. The
hint is also not set on modern Hyper-V versions.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NStephen Hemminger <sthemmin@microsoft.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Jork Loeser <Jork.Loeser@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Simon Xiao <sixiao@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: devel@linuxdriverproject.org
Link: http://lkml.kernel.org/r/20170802160921.21791-8-vkuznets@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2ffd9e33
  15. 10 8月, 2017 3 次提交
  17. 17 7月, 2017 6 次提交
  19. 13 6月, 2017 1 次提交
  21. 25 5月, 2017 6 次提交
  23. 18 5月, 2017 4 次提交
  25. 17 3月, 2017 2 次提交