On Mon, Sep 17, 2018 at 04:14:55AM +, k...@linuxonhyperv.com wrote:
> From: Vitaly Kuznetsov
>
> 'error' variable is left uninitialized in case we see an unknown operation.
> As we don't immediately return and proceed to pwrite() we need to set it
> to something, HV_E_FAIL sounds good
From: Dexuan Cui
With CONFIG_DEBUG_PREEMPT=y, I always see this warning:
BUG: using smp_processor_id() in preemptible []
Fix the false warning by using get/put_cpu().
Here vmbus_connect() sends a message to the host and waits for the
host's response. The host will deliver the response
From: Vitaly Kuznetsov
'error' variable is left uninitialized in case we see an unknown operation.
As we don't immediately return and proceed to pwrite() we need to set it
to something, HV_E_FAIL sounds good enough.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
From: "K. Y. Srinivasan"
Some miscellaneous fixes.
Dexuan Cui (1):
Drivers: hv: vmbus: Use get/put_cpu() in vmbus_connect()
Vitaly Kuznetsov (1):
tools: hv: fcopy: set 'error' in case an unknown operation was
requested
drivers/hv/connection.c| 8 +---
From: Alistair Strachan
[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]
The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
From: Alistair Strachan
[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]
The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
From: Alistair Strachan
[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]
The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
From: Alistair Strachan
[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]
The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
From: Alistair Strachan
[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]
The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
/commits/Stephen-Hemminger/fix-Hyper-V-uio-restart/20180916-181024
config: x86_64-randconfig-x015-201837 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed
/commits/Stephen-Hemminger/fix-Hyper-V-uio-restart/20180916-181024
config: x86_64-randconfig-g0-09161659 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed
On Wed, Sep 12, 2018 at 05:01:03PM +0200, Arnd Bergmann wrote:
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c
> b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 87a0ce47f201..a170f5ca7416 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -678,20 +678,10
On Fri, 14 Sep 2018, Andy Lutomirski wrote:
> > On Sep 14, 2018, at 7:27 AM, Thomas Gleixner wrote:
> > On Fri, 14 Sep 2018, Andy Lutomirski wrote:
> >> That’s... horrible. In an amazing way. Can you add BUILD_BUG_ON somewhere
> >> to assert that this actually works?
> >
> > Sure, but changing
13 matches
Mail list logo
