lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 10 May 2021 16:01:10 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Bean Huo <huobean@...il.com>
Cc:     rric@...nel.org, Linus Walleij <linus.walleij@...aro.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Bean Huo (beanhuo)" <beanhuo@...ron.com>,
        "# 4.0+" <stable@...r.kernel.org>
Subject: Re: [PATCH v1 2/2] mmc: cavium: Remove redundant if-statement checkup

On Thu, 29 Apr 2021 at 22:30, Bean Huo <huobean@...il.com> wrote:
>
> On Fri, 2021-03-19 at 16:42 +0100, Bean Huo wrote:
> > On Fri, 2021-03-19 at 15:09 +0100, Ulf Hansson wrote:
> >
> > > On Fri, 19 Mar 2021 at 13:14, Bean Huo <huobean@...il.com> wrote:
> > > > From: Bean Huo <beanhuo@...ron.com>
> > > > Currently, we have two ways to issue multiple-block read/write
> > > > the
> > > > command to the eMMC. One is by normal IO request path fs->block-
> > > > > mmc.
> > > > Another one is that we can issue multiple-block read/write
> > > > through
> > > > MMC ioctl interface. For the first path, mrq->stop, and mrq-
> > > > >stop-
> > > > > opcode
> > > > will be initialized in mmc_blk_data_prep(). However, for the
> > > > second
> > > > IO
> > > > path, mrq->stop is not initialized since it is a pre-defined
> > > > multiple
> > > > blocks read/write.
> > > As a matter of fact this way is also supported for the regular
> > > block
> > > I/O path. To make the mmc block driver to use it, mmc host drivers
> > > need to announce that it's supported by setting MMC_CAP_CMD23.
> > > It looks like that is what your patch should be targeted towards,
> > > can
> > > you have a look at this instead?
> >
> >
> > Hi Ulf,
> >
> > Thanks for your comments. I will look at that as your suggestion.
> >
> > The patch [1/2] is accepted, so I will just update this patch to
> >
> > the next version.
> >
> >
> >
> > Kind regards,
> >
> > Bean
>
>
> Hi Uffe,
> Could you please firstly accept this patch? let the customer update
> their kernel. As I tried to develop the next version of the patch
> according to your suggestion, more changes will be involved. Also, no
> matter how to make the change general, below mrq->stop checkup should
> be deleted since it is obsolete. In the data transmission completion
> interrupt, mrq->stop will be checked again.
>
> -       if (!mrq->data || !mrq->data->sg || !mrq->data->sg_len ||
> -           !mrq->stop || mrq->stop->opcode != MMC_STOP_TRANSMISSION) {
> +       if (!mrq->data || !mrq->data->sg || !mrq->data->sg_len) {
>

Well, I don't think the above checks are incorrect. Instead I think it
points out that the cavium mmc driver lacks support for CMD23, while
only open ended data transfers are supported.

The proper way forward is instead to implement CMD23 support to the
cavium mmc driver. In the same patch adding that support, you should
be able to remove the above checks.

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ