From: nguyenb@codeaurora.org
To: Greg KH <gregkh@linuxfoundation.org>
Cc: ulf.hansson@linaro.org, robh+dt@kernel.org,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
asutoshd@codeaurora.org, cang@codeaurora.org,
"Bao D. Nguyen" <nguyenb@quicinc.com>
Subject: Re: [<PATCH v1> 9/9] mmc: sd: Fix trivial SD card issues
Date: Wed, 18 Dec 2019 12:16:28 -0800 [thread overview]
Message-ID: <e8fe4566bbd9490f6244c80fb4c6e0ea@codeaurora.org> (raw)
In-Reply-To: <20191218082943.GB1554871@kroah.com>
On 2019-12-18 00:29, Greg KH wrote:
> On Mon, Dec 16, 2019 at 06:50:42PM -0800, Bao D. Nguyen wrote:
>> From: "Bao D. Nguyen" <nguyenb@quicinc.com>
>>
>> Fix various trivial SD card issues.
>
> There are a number of real bugfixes in here, please split these out and
> put them at the beginning of the series so that they can be backported
> to the stable kernel tree. Specifics below:
>
>>
>> Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org>
>> ---
>> drivers/mmc/core/block.c | 4 ++--
>> drivers/mmc/core/bus.c | 13 +++++++++++++
>> drivers/mmc/core/core.c | 13 ++++++++-----
>> drivers/mmc/core/sd.c | 9 ++++++---
>> 4 files changed, 29 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
>> index 95b41c0..200882d 100644
>> --- a/drivers/mmc/core/block.c
>> +++ b/drivers/mmc/core/block.c
>> @@ -653,13 +653,13 @@ static int mmc_blk_ioctl_cmd(struct mmc_blk_data
>> *md,
>> struct request *req;
>>
>> idata = mmc_blk_ioctl_copy_from_user(ic_ptr);
>> - if (IS_ERR(idata))
>> + if (IS_ERR_OR_NULL(idata))
>
> How can this function ever return NULL?
>
>> return PTR_ERR(idata);
>
> If NULL was returned, are you sure you can return 0 here? That implies
> that all went well, when obviously it did not.
>
> But again, I do not see how mmc_blk_ioctl_copy_from_user() can return
> NULL, do you?
>
>> /* This will be NULL on non-RPMB ioctl():s */
>> idata->rpmb = rpmb;
>>
>> card = md->queue.card;
>> - if (IS_ERR(card)) {
>> + if (IS_ERR_OR_NULL(card)) {
>
> How can card be NULL?
>
>> err = PTR_ERR(card);
>
> Again, returning "success" is ok? Are you sure?
>
>> goto cmd_done;
>> }
>> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
>> index 74de3f2..fb17d21 100644
>> --- a/drivers/mmc/core/bus.c
>> +++ b/drivers/mmc/core/bus.c
>> @@ -131,6 +131,16 @@ static void mmc_bus_shutdown(struct device *dev)
>> struct mmc_host *host = card->host;
>> int ret;
>>
>> + if (!drv) {
>> + pr_debug("%s: %s: drv is NULL\n", dev_name(dev), __func__);
>
> How can this ever happen?
>
> And never use pr_* calls in a driver, you have a valid device, use
> dev_dbg() and friends.
>
>> + return;
>> + }
>> +
>> + if (!card) {
>> + pr_debug("%s: %s: card is NULL\n", dev_name(dev), __func__);
>
> Same here, how can this ever happen?
>
>> + return;
>> + }
>> +
>> if (dev->driver && drv->shutdown)
>> drv->shutdown(card);
>>
>> @@ -247,12 +257,15 @@ void mmc_unregister_driver(struct mmc_driver
>> *drv)
>> static void mmc_release_card(struct device *dev)
>> {
>> struct mmc_card *card = mmc_dev_to_card(dev);
>> + struct mmc_host *host = card->host;
>>
>> sdio_free_common_cis(card);
>>
>> kfree(card->info);
>>
>> kfree(card);
>> + if (host)
>> + host->card = NULL;
>
> Why are you setting this to null? Does this solve some race condition
> that you are then catching in the shutdown callback? If so, this
> should
> be broken out as a separate bugfix and put earlier in the series as
> that
> should go to all stable kernels, right?
>
>> }
>>
>> /*
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 38b0cec..13d496e 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -399,7 +399,7 @@ void mmc_wait_for_req_done(struct mmc_host *host,
>> struct mmc_request *mrq)
>> struct mmc_command *cmd;
>>
>> while (1) {
>> - wait_for_completion(&mrq->completion);
>> + wait_for_completion_io(&mrq->completion);
>
> Why this change? That seems like a big one. Why is this not a
> separate
> patch?
>
>>
>> cmd = mrq->cmd;
>>
>> @@ -666,6 +666,10 @@ void mmc_set_data_timeout(struct mmc_data *data,
>> const struct mmc_card *card)
>> {
>> unsigned int mult;
>>
>> + if (!card) {
>> + WARN_ON(1);
>
> And you just crashed systems that run with panic-on-warn :(
>
> How can this ever happen? If it is a real issue, catch it, log it, and
> then move on, don't splat the kernel log with a full traceback and
> reboot machines :(
>
>> + return;
>> + }
>> /*
>> * SDIO cards only define an upper 1 s limit on access.
>> */
>> @@ -2341,17 +2345,16 @@ void mmc_rescan(struct work_struct *work)
>>
>> void mmc_start_host(struct mmc_host *host)
>> {
>> + mmc_claim_host(host);
>
> What? This is a totally separate change, plaese break this out and
> describe what you are fixing here. Again, should be a bugfix for
> earlier in the series.
>
>> host->f_init = max(freqs[0], host->f_min);
>> host->rescan_disable = 0;
>> host->ios.power_mode = MMC_POWER_UNDEFINED;
>>
>> - if (!(host->caps2 & MMC_CAP2_NO_PRESCAN_POWERUP)) {
>> - mmc_claim_host(host);
>> + if (!(host->caps2 & MMC_CAP2_NO_PRESCAN_POWERUP))
>> mmc_power_up(host, host->ocr_avail);
>> - mmc_release_host(host);
>> - }
>>
>> mmc_gpiod_request_cd_irq(host);
>> + mmc_release_host(host);
>
> And are you sure the reference counting is correct here? Before this
> patch, you dropped the reference above, now you are matching it.
> Either
> this is wrong, or the original code is wrong. Either way, you need to
> describe it much better please.
>
>> _mmc_detect_change(host, 0, false);
>> }
>>
>> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
>> index 5938caf..e163f0e 100644
>> --- a/drivers/mmc/core/sd.c
>> +++ b/drivers/mmc/core/sd.c
>> @@ -989,6 +989,7 @@ static int mmc_sd_init_card(struct mmc_host *host,
>> u32 ocr,
>> err = mmc_send_relative_addr(host, &card->rca);
>> if (err)
>> goto free_card;
>> + host->card = card;
>
> Why?
>
>> }
>>
>> if (!oldcard) {
>> @@ -1090,13 +1091,13 @@ static int mmc_sd_init_card(struct mmc_host
>> *host, u32 ocr,
>> goto free_card;
>> }
>> done:
>> - host->card = card;
>> return 0;
>>
>> free_card:
>> - if (!oldcard)
>> + if (!oldcard) {
>> + host->card = NULL;
>
> Again, why?
>
>> mmc_remove_card(card);
>> -
>> + }
>> return err;
>> }
>>
>> @@ -1106,7 +1107,9 @@ static int mmc_sd_init_card(struct mmc_host
>> *host, u32 ocr,
>> static void mmc_sd_remove(struct mmc_host *host)
>> {
>> mmc_remove_card(host->card);
>> + mmc_claim_host(host);
>> host->card = NULL;
>> + mmc_release_host(host);
>
> Huh? What is this "fixing"?
>
> Again, please break all of these out into logical bugfixes and describe
> what you are doing.
>
> thanks,
>
> greg k-h
Thank you for providing the feedback. There are a lot of good feedback
and it will take me a bit of time to review them and make changes
properly.
Regards,
Bao
next prev parent reply other threads:[~2019-12-18 20:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 2:50 [<PATCH v1> 0/9] SD card bug fixes Bao D. Nguyen
2019-12-17 2:50 ` [<PATCH v1> 1/9] mmc: core: Add a cap to use long discard size Bao D. Nguyen
2019-12-17 7:09 ` Ulf Hansson
2019-12-17 2:50 ` [<PATCH v1> 2/9] mmc: core: allow hosts to specify a large " Bao D. Nguyen
2019-12-17 2:50 ` [<PATCH v1> 3/9] mmc: host: Add device_prepare pm for mmc_host Bao D. Nguyen
2019-12-17 2:50 ` [<PATCH v1> 4/9] mmc: core: fix SD card request queue refcount underflow during shutdown Bao D. Nguyen
2019-12-18 8:33 ` Greg KH
2019-12-17 2:50 ` [<PATCH v1> 5/9] mmc: core: fix one NULL pointer dereference after SD card is removed Bao D. Nguyen
2019-12-17 2:50 ` [<PATCH v1> 6/9] mmc: sdhci-msm: Ignore data timeout error for R1B commands Bao D. Nguyen
2019-12-18 8:34 ` Greg KH
2019-12-17 2:50 ` [<PATCH v1> 7/9] mmc: core: Skip frequency retries for SDCC slots Bao D. Nguyen
2019-12-18 8:34 ` Greg KH
2019-12-18 11:48 ` Ulf Hansson
2019-12-18 12:04 ` Greg Kroah-Hartman
2019-12-18 13:12 ` Ulf Hansson
2019-12-17 2:50 ` [<PATCH v1> 8/9] mmc: core: remove shutdown handler Bao D. Nguyen
2019-12-17 2:50 ` [<PATCH v1> 9/9] mmc: sd: Fix trivial SD card issues Bao D. Nguyen
2019-12-18 8:29 ` Greg KH
2019-12-18 20:16 ` nguyenb [this message]
2019-12-18 8:21 ` [<PATCH v1> 0/9] SD card bug fixes Greg KH
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=e8fe4566bbd9490f6244c80fb4c6e0ea@codeaurora.org \
--to=nguyenb@codeaurora.org \
--cc=asutoshd@codeaurora.org \
--cc=cang@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=nguyenb@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=ulf.hansson@linaro.org \
/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.