[PATCH 1/2] usb: f_fs: refactor and document __ffs_ep0_read_events better

[PATCH 1/2] usb: f_fs: refactor and document __ffs_ep0_read_events better

[Michal Nazarewicz]

Instead of using variable length array, use a static length equal to
the size of the ffs->ev.types array.  This gets rid of a sparse warning:

	drivers/usb/gadget/function/f_fs.c:401:44: warning:
	Variable length array is used.

and makes it more explicit that the array has a very tight upper size
limit.  Also add some more documentation about the ev.types array and
how its size is limited and affects the rest of the code.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
---
 This has been compile tested only.

 drivers/usb/gadget/function/f_fs.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index dc30adf1..ec50e0d 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -385,14 +385,16 @@ done_spin:
 	return ret;
 }
 
+/* Called with ffs->ev.waitq.lock and ffs->mutex held, both released on exit. */
 static ssize_t __ffs_ep0_read_events(struct ffs_data *ffs, char __user *buf,
 				     size_t n)
 {
 	/*
-	 * We are holding ffs->ev.waitq.lock and ffs->mutex and we need
-	 * to release them.
+	 * n cannot be bigger than ffs->ev.count, which cannot be bigger than
+	 * size of ffs->ev.types array (which is four) so that's how much space
+	 * we reserve.
 	 */
-	struct usb_functionfs_event events[n];
+	struct usb_functionfs_event events[ARRAY_SIZE(ffs->ev.types)];
 	unsigned i = 0;
 
 	memset(events, 0, sizeof events);
@@ -405,12 +407,10 @@ static ssize_t __ffs_ep0_read_events(struct ffs_data *ffs, char __user *buf,
 		}
 	} while (++i < n);
 
-	if (n < ffs->ev.count) {
-		ffs->ev.count -= n;
+	ffs->ev.count -= n;
+	if (ffs->ev.count) {
 		memmove(ffs->ev.types, ffs->ev.types + n,
 			ffs->ev.count * sizeof *ffs->ev.types);
-	} else {
-		ffs->ev.count = 0;
 	}
 
 	spin_unlock_irq(&ffs->ev.waitq.lock);
@@ -2293,6 +2293,13 @@ static void __ffs_event_add(struct ffs_data *ffs,
 	if (ffs->setup_state == FFS_SETUP_PENDING)
 		ffs->setup_state = FFS_SETUP_CANCELLED;
 
+	/*
+	 * Logic of this function guarantees that there will be at most four
+	 * pending evens on the ffs->ev.types queue.  This is important since
+	 * that array has only place for four elements and __ffs_event_add
+	 * function also depends on that limit.  If more event types are added,
+	 * those limits have to be revisited or guaranteed to still hold.
+	 */
 	switch (type) {
 	case FUNCTIONFS_RESUME:
 		rem_type2 = FUNCTIONFS_SUSPEND;
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 2/2] usb: f_fs: replace BUG in dead-code with less serious WARN_ON

[Michal Nazarewicz]

Even though the BUG() in __ffs_event_add is a dead-code, it is still
better to warn rather then crash the system if that code ever gets
executed.

Suggested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
---
 This has been compile tested only.

 drivers/usb/gadget/function/f_fs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index ec50e0d..74d48b3 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2321,7 +2321,9 @@ static void __ffs_event_add(struct ffs_data *ffs,
 		break;
 
 	default:
-		BUG();
+		pr_vdebug("%d: unknown event, this should not happen\n", type);
+		WARN_ON(1);
+		return;
 	}
 
 	{
-- 
2.1.0.rc2.206.gedb03e5

Re: [PATCH 2/2] usb: f_fs: replace BUG in dead-code with less serious WARN_ON

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Wed, Sep 10, 2014 at 05:50:25PM +0200, Michal Nazarewicz wrote:
> Even though the BUG() in __ffs_event_add is a dead-code, it is still
> better to warn rather then crash the system if that code ever gets
> executed.
> 
> Suggested-by: Felipe Balbi <balbi@ti.com>
> Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
> ---
>  This has been compile tested only.
> 
>  drivers/usb/gadget/function/f_fs.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
> index ec50e0d..74d48b3 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -2321,7 +2321,9 @@ static void __ffs_event_add(struct ffs_data *ffs,
>  		break;
>  
>  	default:
> -		BUG();
> +		pr_vdebug("%d: unknown event, this should not happen\n", type);
> +		WARN_ON(1);

WARN(1, "unknown event type %d\n", type);
Then you can drop pr_vdebug();

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCHv2] usb: f_fs: replace BUG in dead-code with less serious WARN_ON

[Michal Nazarewicz]

Even though the BUG() in __ffs_event_add is a dead-code, it is still
better to warn rather then crash the system if that code ever gets
executed.

Reported-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
---
 drivers/usb/gadget/function/f_fs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

On Wed, Sep 10 2014, Felipe Balbi <balbi@ti.com> wrote:
> WARN(1, "unknown event type %d\n", type);
> Then you can drop pr_vdebug();

True, but the printk call will stay in the binary whereas pr_vdebug is not
included in non-debug builds.  Furthermore, WARN() does not use pr_fmt.

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index ec50e0d..ea21565 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2321,7 +2321,8 @@ static void __ffs_event_add(struct ffs_data *ffs,
 		break;
 
 	default:
-		BUG();
+		WARN(1, "%d: unknown event, this should not happen\n", type);
+		return;
 	}
 
 	{
-- 
2.1.0.rc2.206.gedb03e5

Re: [PATCHv2] usb: f_fs: replace BUG in dead-code with less serious WARN_ON

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Thu, Sep 11, 2014 at 06:52:49PM +0200, Michal Nazarewicz wrote:
> Even though the BUG() in __ffs_event_add is a dead-code, it is still
> better to warn rather then crash the system if that code ever gets
> executed.
> 
> Reported-by: Felipe Balbi <balbi@ti.com>
> Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
> ---
>  drivers/usb/gadget/function/f_fs.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> On Wed, Sep 10 2014, Felipe Balbi <balbi@ti.com> wrote:
> > WARN(1, "unknown event type %d\n", type);
> > Then you can drop pr_vdebug();
> 
> True, but the printk call will stay in the binary whereas pr_vdebug is not

not a big deal. I'd rather get a message all the time this triggers.

> included in non-debug builds.  Furthermore, WARN() does not use pr_fmt.

not a big deal either, we will get a stack dump and can easily figure
out where that comes from.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]