Re: WARNING in ion_ioctl

2018-01-05 Thread Dan Carpenter 
Oh..  Duh to me...  I didn't even know pr_warn_once() existed.  Cool.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] media: staging: tegra-vde: select DMA_SHARED_BUFFER

2018-01-05 Thread Arnd Bergmann 
Without CONFIG_DMA_SHARED_BUFFER we run into a link error for the
dma_buf_* APIs:

ERROR: "dma_buf_map_attachment" [drivers/staging/media/tegra-vde/tegra-vde.ko] 
undefined!
ERROR: "dma_buf_attach" [drivers/staging/media/tegra-vde/tegra-vde.ko] 
undefined!
ERROR: "dma_buf_get" [drivers/staging/media/tegra-vde/tegra-vde.ko] undefined!
ERROR: "dma_buf_put" [drivers/staging/media/tegra-vde/tegra-vde.ko] undefined!
ERROR: "dma_buf_detach" [drivers/staging/media/tegra-vde/tegra-vde.ko] 
undefined!
ERROR: "dma_buf_unmap_attachment" 
[drivers/staging/media/tegra-vde/tegra-vde.ko] undefined!

Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/tegra-vde/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/tegra-vde/Kconfig 
b/drivers/staging/media/tegra-vde/Kconfig
index ec3ebdaa..5c4914674468 100644
--- a/drivers/staging/media/tegra-vde/Kconfig
+++ b/drivers/staging/media/tegra-vde/Kconfig
@@ -1,6 +1,7 @@
 config TEGRA_VDE
tristate "NVIDIA Tegra Video Decoder Engine driver"
depends on ARCH_TEGRA || COMPILE_TEST
+   select DMA_SHARED_BUFFER
select SRAM
help
Say Y here to enable support for the NVIDIA Tegra video decoder
-- 
2.9.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] ANDROID: binder: remove waitqueue when thread exits.

2018-01-05 Thread Martijn Coenen 
binder_poll() passes the thread->wait waitqueue that
can be slept on for work. When a thread that uses
epoll explicitly exits using BINDER_THREAD_EXIT,
the waitqueue is freed, but it is never removed
from the corresponding epoll data structure. When
the process subsequently exits, the epoll cleanup
code tries to access the waitlist, which results in
a use-after-free.

Prevent this by using POLLFREE when the thread exits.

Signed-off-by: Martijn Coenen 
Reported-by: syzbot 
---
 drivers/android/binder.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 778caed570c6..26a66da72f02 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4365,6 +4365,18 @@ static int binder_thread_release(struct binder_proc 
*proc,
if (t)
spin_lock(&t->lock);
}
+
+   /*
+* If this thread used poll, make sure we remove the waitqueue
+* from any epoll data structures holding it with POLLFREE.
+* waitqueue_active() is safe to use here because we're holding
+* the inner lock.
+*/
+   if ((thread->looper & BINDER_LOOPER_STATE_POLL) &&
+   waitqueue_active(&thread->wait)) {
+   wake_up_poll(&thread->wait, POLLHUP | POLLFREE);
+   }
+
binder_inner_proc_unlock(thread->proc);
 
if (send_reply)
-- 
2.16.0.rc0.223.g4a4ac83678-goog

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: irda: Prefer 'unsigned int' to bare use of 'unsigned'

2018-01-05 Thread Sumit Pundir 
This patch fixes the following checkpatch.pl issue at multiple lines:

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'

Signed-off-by: Sumit Pundir 
---
 drivers/staging/irda/drivers/act200l-sir.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/irda/drivers/act200l-sir.c 
b/drivers/staging/irda/drivers/act200l-sir.c
index e891751..62a02e5 100644
--- a/drivers/staging/irda/drivers/act200l-sir.c
+++ b/drivers/staging/irda/drivers/act200l-sir.c
@@ -29,7 +29,7 @@
 static int act200l_reset(struct sir_dev *dev);
 static int act200l_open(struct sir_dev *dev);
 static int act200l_close(struct sir_dev *dev);
-static int act200l_change_speed(struct sir_dev *dev, unsigned speed);
+static int act200l_change_speed(struct sir_dev *dev, unsigned int speed);
 
 /* Regsiter 0: Control register #1 */
 #define ACT200L_REG00x00
@@ -134,7 +134,7 @@ static int act200l_close(struct sir_dev *dev)
  *Set the speed for the ACTiSYS ACT-IR200L type dongle.
  *
  */
-static int act200l_change_speed(struct sir_dev *dev, unsigned speed)
+static int act200l_change_speed(struct sir_dev *dev, unsigned int speed)
 {
u8 control[3];
int ret = 0;
@@ -191,8 +191,8 @@ static int act200l_change_speed(struct sir_dev *dev, 
unsigned speed)
 
 static int act200l_reset(struct sir_dev *dev)
 {
-   unsigned state = dev->fsm.substate;
-   unsigned delay = 0;
+   unsigned int state = dev->fsm.substate;
+   unsigned int delay = 0;
static const u8 control[9] = {
ACT200L_REG15,
ACT200L_REG13 | ACT200L_SHDW,
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: irda: Prefer 'unsigned int' to bare use of 'unsigned'

2018-01-05 Thread Shyam Saini 
Hi,

Did you read this?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/irda/TODO


Thanks,
Shyam


> This patch fixes the following checkpatch.pl issue at multiple lines:
>
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
>
> Signed-off-by: Sumit Pundir 
> ---
>  drivers/staging/irda/drivers/act200l-sir.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/irda/drivers/act200l-sir.c 
> b/drivers/staging/irda/drivers/act200l-sir.c
> index e891751..62a02e5 100644
> --- a/drivers/staging/irda/drivers/act200l-sir.c
> +++ b/drivers/staging/irda/drivers/act200l-sir.c
> @@ -29,7 +29,7 @@
>  static int act200l_reset(struct sir_dev *dev);
>  static int act200l_open(struct sir_dev *dev);
>  static int act200l_close(struct sir_dev *dev);
> -static int act200l_change_speed(struct sir_dev *dev, unsigned speed);
> +static int act200l_change_speed(struct sir_dev *dev, unsigned int speed);
>
>  /* Regsiter 0: Control register #1 */
>  #define ACT200L_REG00x00
> @@ -134,7 +134,7 @@ static int act200l_close(struct sir_dev *dev)
>   *Set the speed for the ACTiSYS ACT-IR200L type dongle.
>   *
>   */
> -static int act200l_change_speed(struct sir_dev *dev, unsigned speed)
> +static int act200l_change_speed(struct sir_dev *dev, unsigned int speed)
>  {
> u8 control[3];
> int ret = 0;
> @@ -191,8 +191,8 @@ static int act200l_change_speed(struct sir_dev *dev, 
> unsigned speed)
>
>  static int act200l_reset(struct sir_dev *dev)
>  {
> -   unsigned state = dev->fsm.substate;
> -   unsigned delay = 0;
> +   unsigned int state = dev->fsm.substate;
> +   unsigned int delay = 0;
> static const u8 control[9] = {
> ACT200L_REG15,
> ACT200L_REG13 | ACT200L_SHDW,
> --
> 2.7.4
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: fsl-mc/dpio: Add dpaa2_io_service_select() API

2018-01-05 Thread Ioana Radulescu 
All DPIO service API functions receive a dpaa2_io service pointer
as parameter (NULL meaning any service will do) which indicates
the hardware resource to be used to execute the specified command.

There isn't however any available API for obtaining such a service
reference that could be used further, effectively forcing the users
to always request a random service for DPIO operations.
(The DPIO driver holds internally an array mapping services to cpus,
and affine services can be indirectly requested by a couple of API
functions: dpaa2_io_service_register and dpaa2_io_service_rearm
use the cpu id provided by the user to select the corresponding
service)

This patch adds a function for selecting a DPIO service based on
the specified cpu id. If the user provides a "don't care" value
for the cpu, we revert to the default behavior and return the next
DPIO, taken in a round-robin fashion from a list of available
services.

Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-mc/bus/dpio/dpio-service.c | 17 +
 drivers/staging/fsl-mc/include/dpaa2-io.h  |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c 
b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
index a8a8e15..6e8994c 100644
--- a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
+++ b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
@@ -104,6 +104,23 @@ static inline struct dpaa2_io *service_select(struct 
dpaa2_io *d)
 }
 
 /**
+ * dpaa2_io_service_select() - return a dpaa2_io service affined to this cpu
+ * @cpu: the cpu id
+ *
+ * Return the affine dpaa2_io service, or NULL if there is no service affined
+ * to the specified cpu. If DPAA2_IO_ANY_CPU is used, return the next available
+ * service.
+ */
+struct dpaa2_io *dpaa2_io_service_select(int cpu)
+{
+   if (cpu == DPAA2_IO_ANY_CPU)
+   return service_select(NULL);
+
+   return service_select_by_cpu(NULL, cpu);
+}
+EXPORT_SYMBOL_GPL(dpaa2_io_service_select);
+
+/**
  * dpaa2_io_create() - create a dpaa2_io object.
  * @desc: the dpaa2_io descriptor
  *
diff --git a/drivers/staging/fsl-mc/include/dpaa2-io.h 
b/drivers/staging/fsl-mc/include/dpaa2-io.h
index 07ad15a..9d70251 100644
--- a/drivers/staging/fsl-mc/include/dpaa2-io.h
+++ b/drivers/staging/fsl-mc/include/dpaa2-io.h
@@ -88,6 +88,8 @@ void dpaa2_io_down(struct dpaa2_io *d);
 
 irqreturn_t dpaa2_io_irq(struct dpaa2_io *obj);
 
+struct dpaa2_io *dpaa2_io_service_select(int cpu);
+
 /**
  * struct dpaa2_io_notification_ctx - The DPIO notification context structure
  * @cb:   The callback to be invoked when the notification arrives
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: fsl-dpaa2/eth: Use affine DPIO services

2018-01-05 Thread Ioana Radulescu 
Use the newly added DPIO service API to map cpu-affine DPIO services
to channels.

The DPAA2 Ethernet driver already had mappings of frame queues and
channels to cpus, but had no control over the DPIOs used. We can
now ensure full affinity of hotpath hardware resources to cores,
which improves performance and almost eliminates some resource
contentions (e.g. enqueue/dequeue busy counters should be close to
zero from now on).

Making the pull channel operation core affine brings the most
significant benefits. This ensures the same DPIO service will be
used for all dequeue commands issued for a certain frame queue,
which is in line with the way hardware is optimized.

Additionally, we also use affine DPIOs for the frame enqueue and
buffer release operations in order to avoid resource contention.
dpaa2_io_service_register() and dpaa2_io_service_rearm()
functions receive an affine DPIO as argument mostly for uniformity,
but this doesn't change the previous functionality.

Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 24 ++--
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h |  1 +
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index 824c4ad..2817e67 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -597,7 +597,8 @@ static netdev_tx_t dpaa2_eth_tx(struct sk_buff *skb, struct 
net_device *net_dev)
queue_mapping = skb_get_queue_mapping(skb);
fq = &priv->fq[queue_mapping];
for (i = 0; i < DPAA2_ETH_ENQUEUE_RETRIES; i++) {
-   err = dpaa2_io_service_enqueue_qd(NULL, priv->tx_qdid, 0,
+   err = dpaa2_io_service_enqueue_qd(fq->channel->dpio,
+ priv->tx_qdid, 0,
  fq->tx_qdbin, &fd);
if (err != -EBUSY)
break;
@@ -719,7 +720,8 @@ static void free_bufs(struct dpaa2_eth_priv *priv, u64 
*buf_array, int count)
 /* Perform a single release command to add buffers
  * to the specified buffer pool
  */
-static int add_bufs(struct dpaa2_eth_priv *priv, u16 bpid)
+static int add_bufs(struct dpaa2_eth_priv *priv,
+   struct dpaa2_eth_channel *ch, u16 bpid)
 {
struct device *dev = priv->net_dev->dev.parent;
u64 buf_array[DPAA2_ETH_BUFS_PER_CMD];
@@ -753,7 +755,7 @@ static int add_bufs(struct dpaa2_eth_priv *priv, u16 bpid)
 
 release_bufs:
/* In case the portal is busy, retry until successful */
-   while ((err = dpaa2_io_service_release(NULL, bpid,
+   while ((err = dpaa2_io_service_release(ch->dpio, bpid,
   buf_array, i)) == -EBUSY)
cpu_relax();
 
@@ -794,7 +796,7 @@ static int seed_pool(struct dpaa2_eth_priv *priv, u16 bpid)
for (j = 0; j < priv->num_channels; j++) {
for (i = 0; i < DPAA2_ETH_NUM_BUFS;
 i += DPAA2_ETH_BUFS_PER_CMD) {
-   new_count = add_bufs(priv, bpid);
+   new_count = add_bufs(priv, priv->channel[j], bpid);
priv->channel[j]->buf_count += new_count;
 
if (new_count < DPAA2_ETH_BUFS_PER_CMD) {
@@ -852,7 +854,7 @@ static int refill_pool(struct dpaa2_eth_priv *priv,
return 0;
 
do {
-   new_count = add_bufs(priv, bpid);
+   new_count = add_bufs(priv, ch, bpid);
if (unlikely(!new_count)) {
/* Out of memory; abort for now, we'll try later on */
break;
@@ -873,7 +875,8 @@ static int pull_channel(struct dpaa2_eth_channel *ch)
 
/* Retry while portal is busy */
do {
-   err = dpaa2_io_service_pull_channel(NULL, ch->ch_id, ch->store);
+   err = dpaa2_io_service_pull_channel(ch->dpio, ch->ch_id,
+   ch->store);
dequeues++;
cpu_relax();
} while (err == -EBUSY);
@@ -923,7 +926,7 @@ static int dpaa2_eth_poll(struct napi_struct *napi, int 
budget)
if (cleaned < budget && napi_complete_done(napi, cleaned)) {
/* Re-enable data available notifications */
do {
-   err = dpaa2_io_service_rearm(NULL, &ch->nctx);
+   err = dpaa2_io_service_rearm(ch->dpio, &ch->nctx);
cpu_relax();
} while (err == -EBUSY);
WARN_ONCE(err, "CDAN notifications rearm failed on core %d",
@@ -1531,7 +1534,8 @@ static int setup_dpio(struct dpaa2_eth_priv *priv)
nctx->desired_cpu = i;
 
/* Register the new context */
-   err = dpaa2_io_service_register(NULL, nctx);
+   channel->dp

Re: [PATCH] Staging: irda: Prefer 'unsigned int' to bare use of 'unsigned'

2018-01-05 Thread Sumit Pundir 
On Fri, Jan 5, 2018 at 4:14 PM, Shyam Saini  wrote:
> Hi,
>
> Did you read this?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/irda/TODO
>
>
> Thanks,
> Shyam

Hi Shyam,

Thanks for the update. Totally forgot to read it.

Thanks,
Sumit

On Fri, Jan 5, 2018 at 4:14 PM, Shyam Saini  wrote:
> Hi,
>
> Did you read this?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/irda/TODO
>
>
> Thanks,
> Shyam
>
>
>> This patch fixes the following checkpatch.pl issue at multiple lines:
>>
>> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
>>
>> Signed-off-by: Sumit Pundir 
>> ---
>>  drivers/staging/irda/drivers/act200l-sir.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/irda/drivers/act200l-sir.c 
>> b/drivers/staging/irda/drivers/act200l-sir.c
>> index e891751..62a02e5 100644
>> --- a/drivers/staging/irda/drivers/act200l-sir.c
>> +++ b/drivers/staging/irda/drivers/act200l-sir.c
>> @@ -29,7 +29,7 @@
>>  static int act200l_reset(struct sir_dev *dev);
>>  static int act200l_open(struct sir_dev *dev);
>>  static int act200l_close(struct sir_dev *dev);
>> -static int act200l_change_speed(struct sir_dev *dev, unsigned speed);
>> +static int act200l_change_speed(struct sir_dev *dev, unsigned int speed);
>>
>>  /* Regsiter 0: Control register #1 */
>>  #define ACT200L_REG00x00
>> @@ -134,7 +134,7 @@ static int act200l_close(struct sir_dev *dev)
>>   *Set the speed for the ACTiSYS ACT-IR200L type dongle.
>>   *
>>   */
>> -static int act200l_change_speed(struct sir_dev *dev, unsigned speed)
>> +static int act200l_change_speed(struct sir_dev *dev, unsigned int speed)
>>  {
>> u8 control[3];
>> int ret = 0;
>> @@ -191,8 +191,8 @@ static int act200l_change_speed(struct sir_dev *dev, 
>> unsigned speed)
>>
>>  static int act200l_reset(struct sir_dev *dev)
>>  {
>> -   unsigned state = dev->fsm.substate;
>> -   unsigned delay = 0;
>> +   unsigned int state = dev->fsm.substate;
>> +   unsigned int delay = 0;
>> static const u8 control[9] = {
>> ACT200L_REG15,
>> ACT200L_REG13 | ACT200L_SHDW,
>> --
>> 2.7.4
>>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/2] staging: fsl-mc/dpio, fsl-dpaa2/eth: Use affine DPIO services

2018-01-05 Thread Ioana Radulescu 
The first patch introduces a new DPIO API function allowing
the selection of a cpu-affine service. In the second patch,
the Ethernet driver uses this new API to map cpu-affine DPIO
services to channels.

This adds a significant performance boost on the frame dequeue
side (see numbers below), but, more importantly, helps us avoid
a scenario leading to the kernel running out of memory:

In an unidirectional IP forwarding test running on 8cores, with
ingress traffic @10Gbps, the rate with which Tx frames are
enqueued by the cpu on Tx queues is higher than the rate with
which cores manage to dequeue Tx confirmation frames. So these
confirmation frames increasingly accumulate on hardware queues,
eventually gobbling up all system memory.

Enforcing DPIO service affinity takes advantage of the way
our hardware was designed to be used, eliminating the bottleneck
that caused the imbalance between Rx and Tx processing paths.

Performance numbers measured on a LS2088A board with 8cores @2GHz:

Bidirectional IP forwarding, 512 flows with 64B frames:
1.68Mpps (before) vs 3.77Mpps (after)
Unidirectional IP forwarding, 512 flows with 64B frames:
1.33Mpps (and OOM after ~5-8min) vs 3.72Mpps
TCP netperf (client), 256 flows:
17.27Gbps with 100% cpu load vs 18.78Gbps with 77.6% cpu load

Ioana Radulescu (2):
  staging: fsl-mc/dpio: Add dpaa2_io_service_select() API
  staging: fsl-dpaa2/eth: Use affine DPIO services

 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 24 ++--
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h |  1 +
 drivers/staging/fsl-mc/bus/dpio/dpio-service.c | 17 +
 drivers/staging/fsl-mc/include/dpaa2-io.h  |  2 ++
 4 files changed, 34 insertions(+), 10 deletions(-)

-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: staging: tegra-vde: select DMA_SHARED_BUFFER

2018-01-05 Thread Dmitry Osipenko 
On 05.01.2018 12:43, Arnd Bergmann wrote:
> Without CONFIG_DMA_SHARED_BUFFER we run into a link error for the
> dma_buf_* APIs:
> 
> ERROR: "dma_buf_map_attachment" 
> [drivers/staging/media/tegra-vde/tegra-vde.ko] undefined!
> ERROR: "dma_buf_attach" [drivers/staging/media/tegra-vde/tegra-vde.ko] 
> undefined!
> ERROR: "dma_buf_get" [drivers/staging/media/tegra-vde/tegra-vde.ko] undefined!
> ERROR: "dma_buf_put" [drivers/staging/media/tegra-vde/tegra-vde.ko] undefined!
> ERROR: "dma_buf_detach" [drivers/staging/media/tegra-vde/tegra-vde.ko] 
> undefined!
> ERROR: "dma_buf_unmap_attachment" 
> [drivers/staging/media/tegra-vde/tegra-vde.ko] undefined!
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/staging/media/tegra-vde/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/media/tegra-vde/Kconfig 
> b/drivers/staging/media/tegra-vde/Kconfig
> index ec3ebdaa..5c4914674468 100644
> --- a/drivers/staging/media/tegra-vde/Kconfig
> +++ b/drivers/staging/media/tegra-vde/Kconfig
> @@ -1,6 +1,7 @@
>  config TEGRA_VDE
>   tristate "NVIDIA Tegra Video Decoder Engine driver"
>   depends on ARCH_TEGRA || COMPILE_TEST
> + select DMA_SHARED_BUFFER
>   select SRAM
>   help
>   Say Y here to enable support for the NVIDIA Tegra video decoder
> 

Thanks!

Acked-by: Dmitry Osipenko 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] ANDROID: binder: remove waitqueue when thread exits.

2018-01-05 Thread Greg KH 
On Fri, Jan 05, 2018 at 11:27:07AM +0100, Martijn Coenen wrote:
> binder_poll() passes the thread->wait waitqueue that
> can be slept on for work. When a thread that uses
> epoll explicitly exits using BINDER_THREAD_EXIT,
> the waitqueue is freed, but it is never removed
> from the corresponding epoll data structure. When
> the process subsequently exits, the epoll cleanup
> code tries to access the waitlist, which results in
> a use-after-free.
> 
> Prevent this by using POLLFREE when the thread exits.
> 
> Signed-off-by: Martijn Coenen 
> Reported-by: syzbot 
> ---
>  drivers/android/binder.c | 12 
>  1 file changed, 12 insertions(+)

Should this be a 4.15-final thing, as well as backported to any range of
older kernels?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] ANDROID: binder: remove waitqueue when thread exits.

2018-01-05 Thread Martijn Coenen 
On Fri, Jan 5, 2018 at 1:20 PM, Greg KH  wrote:
> Should this be a 4.15-final thing, as well as backported to any range of
> older kernels?

This was found by syzkaller and wouldn't be hit in normal code paths,
so I think it's not critical for 4.15. This code was introduced in
4.14, so it should be backported there (let me know if it doesn't
apply cleanly - I think it should).

Thanks,
Martijn
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: lustre: Fix prefer seq_puts to seq_printf

2018-01-05 Thread Sumit Pundir 
Use seq_puts() for strings without format specifiers instead of
seq_printf(). Issue reported by checkpatch.pl

Signed-off-by: Sumit Pundir 
---
 drivers/staging/lustre/lustre/obdclass/cl_object.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/cl_object.c 
b/drivers/staging/lustre/lustre/obdclass/cl_object.c
index fdd27ce..b900747 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_object.c
@@ -510,13 +510,13 @@ locks: .. .. .. .. .. [.. .. 
.. .. ..]
  */
lu_site_stats_print(&site->cs_lu, m);
cache_stats_print(&site->cs_pages, m, 1);
-   seq_printf(m, " [");
+   seq_puts(m, " [");
for (i = 0; i < ARRAY_SIZE(site->cs_pages_state); ++i)
seq_printf(m, "%s: %u ", pstate[i],
   atomic_read(&site->cs_pages_state[i]));
-   seq_printf(m, "]\n");
+   seq_puts(m, "]\n");
cache_stats_print(&cl_env_stats, m, 0);
-   seq_printf(m, "\n");
+   seq_puts(m, "\n");
return 0;
 }
 EXPORT_SYMBOL(cl_site_stats_print);
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: lustre: Fix prefer kcalloc over kzalloc with multiply

2018-01-05 Thread Sumit Pundir 
Use kcalloc for allocating an array instead of kzalloc with
multiply. kcalloc is the preferred API. Issue reported by
checkpatch.pl

Signed-off-by: Sumit Pundir 
---
 drivers/staging/lustre/lustre/obdclass/cl_object.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/cl_object.c 
b/drivers/staging/lustre/lustre/obdclass/cl_object.c
index fdd27ce..4b10e2f 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_object.c
@@ -1017,7 +1017,7 @@ int cl_global_init(void)
 {
int result;
 
-   cl_envs = kzalloc(sizeof(*cl_envs) * num_possible_cpus(), GFP_KERNEL);
+   cl_envs = kcalloc(num_possible_cpus(), sizeof(*cl_envs), GFP_KERNEL);
if (!cl_envs) {
result = -ENOMEM;
goto out;
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: fsl-mc/dpio: Add dpaa2_io_service_select() API

2018-01-05 Thread Roy Pledge 
On 1/5/2018 6:04 AM, Ioana Radulescu wrote:
> All DPIO service API functions receive a dpaa2_io service pointer
> as parameter (NULL meaning any service will do) which indicates
> the hardware resource to be used to execute the specified command.
> 
> There isn't however any available API for obtaining such a service
> reference that could be used further, effectively forcing the users
> to always request a random service for DPIO operations.
> (The DPIO driver holds internally an array mapping services to cpus,
> and affine services can be indirectly requested by a couple of API
> functions: dpaa2_io_service_register and dpaa2_io_service_rearm
> use the cpu id provided by the user to select the corresponding
> service)
> 
> This patch adds a function for selecting a DPIO service based on
> the specified cpu id. If the user provides a "don't care" value
> for the cpu, we revert to the default behavior and return the next
> DPIO, taken in a round-robin fashion from a list of available
> services.
> 
> Signed-off-by: Ioana Radulescu 
> ---
>   drivers/staging/fsl-mc/bus/dpio/dpio-service.c | 17 +
>   drivers/staging/fsl-mc/include/dpaa2-io.h  |  2 ++
>   2 files changed, 19 insertions(+)
> 
> diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c 
> b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
> index a8a8e15..6e8994c 100644
> --- a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
> +++ b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
> @@ -104,6 +104,23 @@ static inline struct dpaa2_io *service_select(struct 
> dpaa2_io *d)
>   }
>   
>   /**
> + * dpaa2_io_service_select() - return a dpaa2_io service affined to this cpu
> + * @cpu: the cpu id
> + *
> + * Return the affine dpaa2_io service, or NULL if there is no service affined
> + * to the specified cpu. If DPAA2_IO_ANY_CPU is used, return the next 
> available
> + * service.
> + */
> +struct dpaa2_io *dpaa2_io_service_select(int cpu)
> +{
> + if (cpu == DPAA2_IO_ANY_CPU)
> + return service_select(NULL);
> +
> + return service_select_by_cpu(NULL, cpu);
> +}
> +EXPORT_SYMBOL_GPL(dpaa2_io_service_select);
> +
> +/**
>* dpaa2_io_create() - create a dpaa2_io object.
>* @desc: the dpaa2_io descriptor
>*
> diff --git a/drivers/staging/fsl-mc/include/dpaa2-io.h 
> b/drivers/staging/fsl-mc/include/dpaa2-io.h
> index 07ad15a..9d70251 100644
> --- a/drivers/staging/fsl-mc/include/dpaa2-io.h
> +++ b/drivers/staging/fsl-mc/include/dpaa2-io.h
> @@ -88,6 +88,8 @@ void dpaa2_io_down(struct dpaa2_io *d);
>   
>   irqreturn_t dpaa2_io_irq(struct dpaa2_io *obj);
>   
> +struct dpaa2_io *dpaa2_io_service_select(int cpu);
> +
>   /**
>* struct dpaa2_io_notification_ctx - The DPIO notification context 
> structure
>* @cb:   The callback to be invoked when the notification arrives
> 

Acked-by: Roy Pledge 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: android: ion: Switch from WARN to pr_warn

2018-01-05 Thread Laura Abbott 
Syzbot reported a warning with Ion:

WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73 
ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
Kernel panic - not syncing: panic_on_warn set ...

This is a warning that validation of the ioctl fields failed. This was
deliberately added as a warning to make it very obvious to developers that
something needed to be fixed. In reality, this is overkill and disturbs
fuzzing. Switch to pr_warn for a message instead.

Reported-by: syzbot+fa2d5f63ee5904a01...@syzkaller.appspotmail.com
Reported-by: syzbot 
Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion-ioctl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 6ed2cc15c8c0..a8d3cc412fb9 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -60,8 +60,10 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
return -EFAULT;
 
ret = validate_ioctl_arg(cmd, &data);
-   if (WARN_ON_ONCE(ret))
+   if (ret) {
+   pr_warn_once("%s: ioctl validate failed\n", __func__);
return ret;
+   }
 
if (!(dir & _IOC_WRITE))
memset(&data, 0, sizeof(data));
-- 
2.14.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: android: ion: Add __GFP_NOWARN for system contig heap

2018-01-05 Thread Laura Abbott 
syzbot reported a warning from Ion:

  WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926

  ...
   __alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
  alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
  alloc_pages include/linux/gfp.h:492 [inline]
  ion_system_contig_heap_allocate+0x40/0x2c0
  drivers/staging/android/ion/ion_system_heap.c:374
  ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline]
  ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420
  ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84
  vfs_ioctl fs/ioctl.c:46 [inline]
  do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
  SYSC_ioctl fs/ioctl.c:701 [inline]
  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692

This is a warning about attempting to allocate order > MAX_ORDER. This
is coming from a userspace Ion allocation request. Since userspace is
free to request however much memory it wants (and the kernel is free to
deny its allocation), silence the allocation attempt with __GFP_NOWARN
in case it fails.

Reported-by: syzbot+76e7efc4748495855...@syzkaller.appspotmail.com
Reported-by: syzbot 
Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion_system_heap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_system_heap.c 
b/drivers/staging/android/ion/ion_system_heap.c
index 71c4228f8238..bc19cdd30637 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -362,7 +362,7 @@ static int ion_system_contig_heap_allocate(struct ion_heap 
*heap,
unsigned long i;
int ret;
 
-   page = alloc_pages(low_order_gfp_flags, order);
+   page = alloc_pages(low_order_gfp_flags | __GFP_NOWARN, order);
if (!page)
return -ENOMEM;
 
-- 
2.14.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: android: ion: Add __GFP_NOWARN for system contig heap

2018-01-05 Thread Chris Wilson 
Quoting Laura Abbott (2018-01-05 19:14:08)
> syzbot reported a warning from Ion:
> 
>   WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926
> 
>   ...
>__alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
>   alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
>   alloc_pages include/linux/gfp.h:492 [inline]
>   ion_system_contig_heap_allocate+0x40/0x2c0
>   drivers/staging/android/ion/ion_system_heap.c:374
>   ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline]
>   ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420
>   ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84
>   vfs_ioctl fs/ioctl.c:46 [inline]
>   do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
>   SYSC_ioctl fs/ioctl.c:701 [inline]
>   SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> 
> This is a warning about attempting to allocate order > MAX_ORDER. This
> is coming from a userspace Ion allocation request. Since userspace is
> free to request however much memory it wants (and the kernel is free to
> deny its allocation), silence the allocation attempt with __GFP_NOWARN
> in case it fails.
> 
> Reported-by: syzbot+76e7efc4748495855...@syzkaller.appspotmail.com
> Reported-by: syzbot 
> Signed-off-by: Laura Abbott 
> ---
>  drivers/staging/android/ion/ion_system_heap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ion/ion_system_heap.c 
> b/drivers/staging/android/ion/ion_system_heap.c
> index 71c4228f8238..bc19cdd30637 100644
> --- a/drivers/staging/android/ion/ion_system_heap.c
> +++ b/drivers/staging/android/ion/ion_system_heap.c
> @@ -362,7 +362,7 @@ static int ion_system_contig_heap_allocate(struct 
> ion_heap *heap,
> unsigned long i;
> int ret;
>  
> -   page = alloc_pages(low_order_gfp_flags, order);
> +   page = alloc_pages(low_order_gfp_flags | __GFP_NOWARN, order);

There's both high_order_gfp and low_order_gfp. The former includes
NOWARN and NORETRY.

Interesting, ion_system_heap_create_pools() tries to mix low_order and
high_order, but it only ever uses high_order flags. (orders[0] == 8
forcing a permanent switch from low_order_gfp to high_order_gfp).

There's no good reason for low_order_gfp, high_order_gfp to be static
rewritable variables.

For this instance, I would go farther and suggest you may want
__GFP_RETRY_MAYFAIL | __GFP_NOWARN to prevent userspace from triggering
the lowmemkiller/oomkiller here.
 
(I would kill low_order_gfp_flags / high_order_gfp_flags and avoid the
obfuscation.)
-Chris
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: android: ion: Add __GFP_NOWARN for system contig heap

2018-01-05 Thread Laura Abbott 

On 01/05/2018 11:36 AM, Chris Wilson wrote:

Quoting Laura Abbott (2018-01-05 19:14:08)

syzbot reported a warning from Ion:

   WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926

   ...
__alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
   alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
   alloc_pages include/linux/gfp.h:492 [inline]
   ion_system_contig_heap_allocate+0x40/0x2c0
   drivers/staging/android/ion/ion_system_heap.c:374
   ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline]
   ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420
   ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84
   vfs_ioctl fs/ioctl.c:46 [inline]
   do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
   SYSC_ioctl fs/ioctl.c:701 [inline]
   SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692

This is a warning about attempting to allocate order > MAX_ORDER. This
is coming from a userspace Ion allocation request. Since userspace is
free to request however much memory it wants (and the kernel is free to
deny its allocation), silence the allocation attempt with __GFP_NOWARN
in case it fails.

Reported-by: syzbot+76e7efc4748495855...@syzkaller.appspotmail.com
Reported-by: syzbot 
Signed-off-by: Laura Abbott 
---
  drivers/staging/android/ion/ion_system_heap.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_system_heap.c 
b/drivers/staging/android/ion/ion_system_heap.c
index 71c4228f8238..bc19cdd30637 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -362,7 +362,7 @@ static int ion_system_contig_heap_allocate(struct ion_heap 
*heap,
 unsigned long i;
 int ret;
  
-   page = alloc_pages(low_order_gfp_flags, order);

+   page = alloc_pages(low_order_gfp_flags | __GFP_NOWARN, order);


There's both high_order_gfp and low_order_gfp. The former includes
NOWARN and NORETRY.

Interesting, ion_system_heap_create_pools() tries to mix low_order and
high_order, but it only ever uses high_order flags. (orders[0] == 8
forcing a permanent switch from low_order_gfp to high_order_gfp).



Good find, that got lost in a refactor back in 4.9.


There's no good reason for low_order_gfp, high_order_gfp to be static
rewritable variables.

For this instance, I would go farther and suggest you may want
__GFP_RETRY_MAYFAIL | __GFP_NOWARN to prevent userspace from triggering
the lowmemkiller/oomkiller here.
  
(I would kill low_order_gfp_flags / high_order_gfp_flags and avoid the

obfuscation.)
-Chris



Yeah, I think this all needs some refactoring. The high_order/low_order
flags were originally for the system heap to allocate pages for the
page pool and I don't think they should be reused for the contig heap.
I'll see about doing a refactor.

Thanks for the review!

Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Compliment of the Season

2018-01-05 Thread Samuel Mabota 


Good day

This is to inform you after much deliberation on your countless efforts to get 
your payment without success and with regard to your dealings with impostors. I 
wish to inform you that a resolution has been reached by members of the payment 
committee to get your funds cleared and delivered to your home address within a 
period of 72 hours solemnly agreed by Board of Trustee of the United Nations 
World Re-compensation Commission (U.N.W.R.C). A VISA MASTER CARD containing the 
sum of Four Million Eight Hundred Thousand United States Dollars ($4,800,000.00 
USD) will be issued in your Favor.

Secondly, as a result of widespread fraud over the internet and to avoid abuse 
of the program, we will provide you details of the VISA GOLD CARD upon your 
response. Please we will like you to confirm the following information.Now we 
have arranged your payment through ATM Card department which you will use to 
withdraw your money in any ATM machine in your country or any part of the 
world, but the maximum you can withdraw is (US$5000) per day stated by the Bank 
rules.So if you like to receive your fund in this way, please let us know by 
responding for the release of your ATM Card to you.

Your Full Name:
Current Residential Address:
Direct Contact Telephone Number:

You are further advised to STOP further contact with any offices or agency 
related to your transactions.

Yours Sincerely,
Dr. Samuel Mabota.
Payment Coordinator
U.N.C.C Service Regional office
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel