Messages in this thread | | | From | "Yang, Fei" <> | Subject | RE: [PATCH V2] usb: gadget: f_fs: don't free buffer prematurely | Date | Wed, 20 Mar 2019 17:30:40 +0000 |
| |
> On Tue, Mar 19, 2019 at 10:56 PM Josh Gao <jmgao@google.com> wrote: > > > > On Tue, Mar 19, 2019 at 10:32 PM <fei.yang@intel.com> wrote: > > > > > > From: Fei Yang <fei.yang@intel.com> > > > > > > The following kernel panic happens due to the io_data buffer gets > > > deallocated before the async io is completed. Add a check for the > > > case where io_data buffer should be deallocated by ffs_user_copy_worker. > > > > It looks like this happened because data got renamed to io_data, which > > made the `data = NULL` marked with "Do not kfree the buffer in this > > function" not do what it was hoping. This should probably either > > delete the assignment above or fix the assignment to refer to io_data? > > (EIOCBQUEUED presumably can't come from > > elsewhere?) > > (except ffs_free_buffer doesn't check for null, so probably the former)
I don’t see EIOCBQUEUED coming from anywhere else in the context of epfile_io, but you are right it's hard to be 100% sure about that. Maybe I should simply check for (data == NULL) so that the original logic remains intact, If (data) ffs_free_buffer(io_data);
| |