[PATCH] vmbus: hvsock: add proper sync for vmbus_hvsock_device_unregister()

Without the patch, vmbus_hvsock_device_unregister() can destroy the device prematurely when close() is called, and can cause NULl dereferencing or potential data loss (the last portion of the data stream may be dropped prematurely). Signed-off-by: Dexuan Cui Cc: K. Y.

Re: [PATCH] timer: Remove meaningless .data/.function assignments

From: Kees Cook Date: Mon, 9 Oct 2017 17:10:32 -0700 > Several timer users needlessly reset their .function/.data fields during > their timer callback, but nothing else changes them. Some users do not > use their .data field at all. Each instance is removed here. > > Cc:

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

On 10/09/2017 03:08 PM, Mark Brown wrote: > On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote: > >> Anyway, to move this forward I think we need to see a proof of concept >> of using selinux to protect access to specific heaps. > > Aren't Unix permissions enough with separate files or

[PATCH] timer: Remove meaningless .data/.function assignments

Several timer users needlessly reset their .function/.data fields during their timer callback, but nothing else changes them. Some users do not use their .data field at all. Each instance is removed here. Cc: Krzysztof Halasa Cc: Aditya Shankar Cc:

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

On Tue, Oct 10, 2017 at 02:48:58AM +0530, Shreeya Patel wrote: > Remove NULL pointer dereference as it results in undefined > behaviour, and will usually lead to a runtime error. The diff does not show any pointer dereference so it is hard to understand what you are trying to do with this patch.

Re: [PATCH 1/2] staging: typec: tcpm: Validate source and sink caps

Sorry about delay. Just sent the rebased patchset along with the comments addressed. Thanks & Regards, Badhri. On Mon, Sep 18, 2017 at 3:20 AM, Greg Kroah-Hartman wrote: > On Thu, Sep 07, 2017 at 06:22:13PM -0700, Badhri Jagan Sridharan wrote: >> The source and sink

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote: > Anyway, to move this forward I think we need to see a proof of concept > of using selinux to protect access to specific heaps. Aren't Unix permissions enough with separate files or am I misunderstanding what you're looking to see a

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

On 10/05/2017 06:06 AM, Benjamin Gaignard wrote: > 2017-10-04 12:17 GMT+02:00 Mark Brown : >> On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote: >> >>> It is entirely possible and easy in android/ueventd to create those nodes >>> under "/dev/ion/". (assuming the

[PATCH] Staging: rtlwifi: Remove NULL pointer dereference

Remove NULL pointer dereference as it results in undefined behaviour, and will usually lead to a runtime error. Signed-off-by: Shreeya Patel --- drivers/staging/rtlwifi/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

On Mon, Oct 9, 2017 at 7:18 PM, Bjorn Helgaas wrote: > On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote: >> [+cc Rafael, linux-pm] >> >> Hi Jia-Ju, >> >> On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: >> > The drivers vt6655 and gma500 call

Re: [PATCH 03/15] staging: comedi: ni_routing: Add NI signal routing info

On Mon, 2017-10-09 at 10:56 +0100, Ian Abbott wrote: > On 08/10/17 07:44, Spencer E Olson wrote: > > On Thu, 2016-11-10 at 18:16 +, Ian Abbott wrote: > >> On 10/11/16 17:54, Greg Kroah-Hartman wrote: > >>> On Thu, Nov 10, 2016 at 05:08:36PM +, Ian Abbott wrote: > On 12/10/16 12:05,

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote: > [+cc Rafael, linux-pm] > > Hi Jia-Ju, > > On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: > > The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, > > which may sleep. > > The function call paths

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

[+cc Rafael, linux-pm] Hi Jia-Ju, On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: > The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, > which may sleep. > The function call paths are: > gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c) >

[PATCH v2] staging: rtl8723bs: remove implicit int->bool conversions

Implicit type conversions are bad; they hinder readability of code and have potential to cause bugs. Here the variable wait_ack is always supplied a bool value while in function declarations it is defined as an int type. Fix it by defining wait_ack a bool type in all usages. Signed-off-by:

Re: [PATCH v5 1/2] staging: ion: simplify ioctl args checking function

On 10/09/2017 02:21 AM, Benjamin Gaignard wrote: > 2017-09-27 15:20 GMT+02:00 Benjamin Gaignard : >> Make arguments checking more easy to read. >> > > Hi Laura, > > Even if we don't have found a solution for the second patch I believe > this one could be useful. >

Re: [Outreachy kernel] [PATCH] staging: rtl8723bs: remove implicit int->bool conversions

On Mon, 9 Oct 2017, Aishwarya Pant wrote: > Implicit type conversions are bad; they hinder readability of code and have > potential to cause bugs. Here the variable wait_ack is always supplied a bool > value while in function declarations it is defined as an int type. Fix it by > defining

[PATCH] staging: rtl8723bs: remove implicit int->bool conversions

Implicit type conversions are bad; they hinder readability of code and have potential to cause bugs. Here the variable wait_ack is always supplied a bool value while in function declarations it is defined as an int type. Fix it by defining wait_ack a bool type in all usages. Signed-off-by:

Re: [PATCH] ANDROID: binder: call poll_wait() unconditionally.

On Mon, Oct 9, 2017 at 2:37 PM, Greg KH wrote: > Does this need to get into 4.14-final, or is 4.15-rc1 ok? I'm a bit > lost as to which patches I applied to what tree... This fixes a race that is somewhat hard to hit, I've only ever seen it with test code that

Re: [PATCH] ANDROID: binder: call poll_wait() unconditionally.

On Mon, Oct 09, 2017 at 02:26:56PM +0200, Martijn Coenen wrote: > Because we're not guaranteed that subsequent calls > to poll() will have a poll_table_struct parameter > with _qproc set. When _qproc is not set, poll_wait() > is a noop, and we won't be woken up correctly. > > Signed-off-by:

[PATCH] ANDROID: binder: call poll_wait() unconditionally.

Because we're not guaranteed that subsequent calls to poll() will have a poll_table_struct parameter with _qproc set. When _qproc is not set, poll_wait() is a noop, and we won't be woken up correctly. Signed-off-by: Martijn Coenen --- drivers/android/binder.c | 11 +--

Re: [PATCH v2 03/13] ANDROID: binder: add support for RT prio inheritance.

On Mon, Oct 09, 2017 at 01:21:23PM +0200, Martijn Coenen wrote: > On Fri, Sep 1, 2017 at 9:24 AM, Greg KH wrote: > > > > I've now applied patches 1, 2, 7, 9, 11, and 12 from this series to my > > tree, so feel free to rebase on it for the next round of these patches. >

Re: [PATCH v2 03/13] ANDROID: binder: add support for RT prio inheritance.

On Fri, Sep 1, 2017 at 9:24 AM, Greg KH wrote: > > I've now applied patches 1, 2, 7, 9, 11, and 12 from this series to my > tree, so feel free to rebase on it for the next round of these patches. Thanks Greg. You should also be able to apply patch 10 from this series

Re: [PATCH 04/15] staging: comedi: ni_routing: add ni routing tables

On 08/10/17 07:50, Spencer E Olson wrote: On Thu, 2016-11-10 at 11:27 -0700, Spencer E Olson wrote: On Thu, 2016-11-10 at 18:18 +, Ian Abbott wrote: On 10/11/16 17:54, Greg Kroah-Hartman wrote: On Thu, Nov 10, 2016 at 05:17:22PM +, Ian Abbott wrote: On 12/10/16 12:05, Spencer E.

Re: [PATCH 03/15] staging: comedi: ni_routing: Add NI signal routing info

On 08/10/17 07:44, Spencer E Olson wrote: On Thu, 2016-11-10 at 18:16 +, Ian Abbott wrote: On 10/11/16 17:54, Greg Kroah-Hartman wrote: On Thu, Nov 10, 2016 at 05:08:36PM +, Ian Abbott wrote: On 12/10/16 12:05, Spencer E. Olson wrote: See README for a thorough discussion of this

Re: [PATCH v2] staging: comedi: dt282x: fix IRQ assignment for dev->irq.

On 06/10/17 19:25, Arvind Yadav wrote: Here, dev->irq is not assigned with irq. comedi_legacy_detach() is using dev->irq for release irq and dt282x_attach() is using dev->irq for initialize comedi_subdevice. Signed-off-by: Arvind Yadav --- changes in v2:

[PATCH] vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend

The driver may sleep under a spinlock, and the function call path is: vt6655_suspend (acquire the spinlock) pci_set_power_state __pci_start_power_transition (drivers/pci/pci.c) msleep --> may sleep To fix it, pci_set_power_state is called without having a spinlock. This bug is found

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

Oh, sorry, I will send the patches for each driver. Thanks, Jia-Ju Bai On 2017/10/9 16:17, Greg KH wrote: On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, which may sleep. The function call paths are:

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: > The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, > which may sleep. > The function call paths are: > gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c) > gma_resume_pci >

Re: [BUG] vt6655: A possible sleep-in-atomic bug in vt6655_suspend

Okay, I will send a patch :) Thanks, Jia-Ju Bai On 2017/10/9 13:43, Greg KH wrote: On Mon, Oct 09, 2017 at 09:10:28AM +0800, Jia-Ju Bai wrote: According to device_main.c, the driver may sleep under a spinlock, and the function call path is: vt6655_suspend (acquire the spinlock)