lkml.org 
[lkml]   [2016]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: BUG: scheduling while atomic in f_fs when gadget remove driver
Date
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»

\
 
 \ /
  Last update: 2016-09-28 18:35    [W:0.479 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site