All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Gao <jmgao@google.com>
To: fei.yang@intel.com
Cc: balbi@kernel.org, gregkh@linuxfoundation.org,
	Jerry Zhang <zhangjerry@google.com>,
	andrzej.p@collabora.com, plr.vincent@gmail.com,
	jingx.shen@intel.com, John Stultz <john.stultz@linaro.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] usb: gadget: f_fs: don't free buffer prematurely
Date: Tue, 19 Mar 2019 22:59:05 -0700	[thread overview]
Message-ID: <CAAHfpN_uVBR5X7e4Bb=OsMVqudB9rVD7rqLhTfix6Pa+-iVwWw@mail.gmail.com> (raw)
In-Reply-To: <CAAHfpN_2rUu+kCCgOV+RdqCU5+XRe_c3KkJk6FNv50FG+5_qwg@mail.gmail.com>

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)

WARNING: multiple messages have this Message-ID (diff)
From: Josh Gao <jmgao@google.com>
To: fei.yang@intel.com
Cc: balbi@kernel.org, gregkh@linuxfoundation.org,
	Jerry Zhang <zhangjerry@google.com>,
	andrzej.p@collabora.com, plr.vincent@gmail.com,
	jingx.shen@intel.com, John Stultz <john.stultz@linaro.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [V2] usb: gadget: f_fs: don't free buffer prematurely
Date: Tue, 19 Mar 2019 22:59:05 -0700	[thread overview]
Message-ID: <CAAHfpN_uVBR5X7e4Bb=OsMVqudB9rVD7rqLhTfix6Pa+-iVwWw@mail.gmail.com> (raw)

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)

  reply	other threads:[~2019-03-20  5:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20  5:32 [PATCH V2] usb: gadget: f_fs: don't free buffer prematurely fei.yang
2019-03-20  5:32 ` [V2] " fei.yang
2019-03-20  5:56 ` [PATCH V2] " Josh Gao
2019-03-20  5:56   ` [V2] " Josh Gao
2019-03-20  5:59   ` Josh Gao [this message]
2019-03-20  5:59     ` Josh Gao
2019-03-20 17:30     ` [PATCH V2] " Yang, Fei
2019-03-20 17:30       ` [V2] " fei.yang
2019-03-20 16:40 ` [PATCH V2] " John Stultz
2019-03-20 16:40   ` [V2] " John Stultz
2019-03-20 16:52   ` [PATCH V2] " Alan Stern
2019-03-20 16:52     ` [V2] " Alan Stern
2019-03-20 16:55     ` [PATCH V2] " John Stultz
2019-03-20 16:55       ` [V2] " John Stultz
2019-03-20 18:21   ` [PATCH V2] " John Stultz
2019-03-20 18:21     ` [V2] " John Stultz
2019-04-02  3:26     ` [PATCH V2] " John Stultz
2019-04-02  3:26       ` [V2] " John Stultz
2019-04-24 16:50       ` [PATCH V2] " Greg KH
2019-04-24 16:50         ` [V2] " Greg Kroah-Hartman
2019-04-25  3:53         ` [PATCH V2] " John Stultz
2019-04-25  3:53           ` [V2] " John Stultz
2019-04-25 16:01           ` [PATCH V2] " Yang, Fei
2019-04-25 16:01             ` [V2] " fei.yang
2019-04-25 16:19             ` [PATCH V2] " John Stultz
2019-04-25 16:19               ` [V2] " John Stultz
2019-03-20 23:28   ` [PATCH V2] " Yang, Fei
2019-03-20 23:28     ` [V2] " fei.yang
2019-03-20 23:42     ` [PATCH V2] " John Stultz
2019-03-20 23:42       ` [V2] " John Stultz
2019-04-02  3:25 ` [PATCH V2] " John Stultz
2019-04-02  3:25   ` [V2] " John Stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAHfpN_uVBR5X7e4Bb=OsMVqudB9rVD7rqLhTfix6Pa+-iVwWw@mail.gmail.com' \
    --to=jmgao@google.com \
    --cc=andrzej.p@collabora.com \
    --cc=balbi@kernel.org \
    --cc=fei.yang@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jingx.shen@intel.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=plr.vincent@gmail.com \
    --cc=zhangjerry@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.