Re: BUG: scheduling while atomic in f_fs when gadget remove driver

[Michal Nazarewicz <mina86@mina86.com>]

On Wed, Sep 28 2016, Chen Yu wrote:
> I will try to fix it, but I'm engaged in other tasks and can not spend
> much time on it.
>
> Do you have any suggestions about how to fix it?

epfile->ep is protected by ffs->eps_lock which brings us to realisation
that there is another bug in the code and we need to do this:

------- >8 -------------------------------------------------------------
>From 0ce6cc5e2440800243eff06c6952cba0f976da2f Mon Sep 17 00:00:00 2001
From: Michal Nazarewicz <mina86@mina86.com>
Date: Wed, 28 Sep 2016 18:10:42 +0200
Subject: [PATCH] usb: gadget: f_fs: edit epfile->ep under lock

epfile->ep is protected by ffs->eps_lock (not epfile->mutex) so clear it
while holding the spin lock.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT requests")
---
 drivers/usb/gadget/function/f_fs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 0aeed85..759f5d4 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1725,17 +1725,17 @@ static void ffs_func_eps_disable(struct ffs_function *func)
 	unsigned long flags;
 
 	do {
-		if (epfile)
-			mutex_lock(&epfile->mutex);
 		spin_lock_irqsave(&func->ffs->eps_lock, flags);
 		/* pending requests get nuked */
 		if (likely(ep->ep))
 			usb_ep_disable(ep->ep);
 		++ep;
+		if (epfile)
+			epfile->ep = NULL;
 		spin_unlock_irqrestore(&func->ffs->eps_lock, flags);
 
 		if (epfile) {
-			epfile->ep = NULL;
+			mutex_lock(&epfile->mutex);
 			kfree(epfile->read_buffer);
 			epfile->read_buffer = NULL;
 			mutex_unlock(&epfile->mutex);
------- >8 -------------------------------------------------------------

With that done, the only thing which needs a mutex is
epfile->read_buffer.

The read_buffer pointer shouldn’t be that big of an issue (it could be
protected by the same eps_lock).  The real problem is freeing the
memory.

We cannot do it while __ffs_epfile_read_buffered is reading data from
it.  We cannot blindly schedule it to happen later either since in the
meanwhile __ffs_epfile_read_buffered could have freed it.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»