Messages in this thread Patch in this message | | | From | Michal Nazarewicz <> | Subject | Re: BUG: scheduling while atomic in f_fs when gadget remove driver | Date | Wed, 28 Sep 2016 18:31:55 +0200 |
| |
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»
| |