Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1553059940-127038-1-git-send-email-fei.yang@intel.com>
In-Reply-To: <1553059940-127038-1-git-send-email-fei.yang@intel.com>
From:   Josh Gao <jmgao@google.com>
Date:   Tue, 19 Mar 2019 22:56:54 -0700
Message-ID: <CAAHfpN_2rUu+kCCgOV+RdqCU5+XRe_c3KkJk6FNv50FG+5_qwg@mail.gmail.com>
Subject: Re: [PATCH V2] usb: gadget: f_fs: don't free buffer prematurely
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
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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?)