linux-kernel - Re: [PATCH] block: add abort on failure

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 PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 8 Aug 2014 18:22:09 +0200 (CEST)
From:	Julia Lawall <julia.lawall@...6.fr>
To:	Josh Morris <josh.h.morris@...ibm.com>
cc:	Jeff Moyer <jmoyer@...hat.com>, kernel-janitors@...r.kernel.org,
	Philip Kelleher <pjk1939@...ux.vnet.ibm.com>,
	dan.carpenter@...cle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: add abort on failure



On Fri, 8 Aug 2014, Josh Morris wrote:

> Howdy Julia,
>
> It is by design that we complete the probe despite failures in
> rsxx_load_config() and rsxx_get_num_targets(). The reason is that we will be
> unable to debug and fix the issue without a driver loaded.
>
> In the case that the on-card config has been corrupted we will need the
> driver loaded to reset or repair the configuration.
>
> I couldn't find a place where we were derefrencing card->ctrl outside of a
> loop that checked the index against n_targets. That should prevent the
> driver from dereferencing an 0 size array.  So I believe we still want the
> probe to complete in this case so we can debug the hardware.

OK.  I also looked for such a reference and didn't see one.

Thanks for the feedback.

julia

>
> Cheers!
>
> Josh
>
>
>
> From:        Julia Lawall <julia.lawall@...6.fr>
> To:        Josh Morris/Houston/IBM@...US,
> Cc:        Jeff Moyer <jmoyer@...hat.com>, kernel-janitors@...r.kernel.org,
> Philip Kelleher <pjk1939@...ux.vnet.ibm.com>, dan.carpenter@...cle.com,
> linux-kernel@...r.kernel.org
> Date:        08/08/2014 04:31 AM
> Subject:        Re: [PATCH] block: add abort on failure
>
> ____________________________________________________________________________
>
>
>
> On Fri, 8 Aug 2014, Julia Lawall wrote:
>
> > From: Julia Lawall <Julia.Lawall@...6.fr>
> >
> > Initializing card seems to be critical to the rest of the probe process,
> so
> > abort the probe function if the calls to rsxx_load_config and
> > rsxx_get_num_targets do not succeed.
>
> Note that this is not tested.  Nevertheless, at least the first failure
> will leave card in an unknown partially initialized state, which seems
> undesirable.
>
> julia
>
>
> > Suggested by Jeff Moyer.
> >
> > Signed-off-by: Julia Lawall <Julia.Lawall@...6.fr>
> >
> > ---
> >  drivers/block/rsxx/core.c |    8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
> > index a8de2ee..ae2805b 100644
> > --- a/drivers/block/rsxx/core.c
> > +++ b/drivers/block/rsxx/core.c
> > @@ -915,15 +915,19 @@ static int rsxx_pci_probe(struct pci_dev *dev,
> >
> >                   /************* Load Card Config *************/
> >                   st = rsxx_load_config(card);
> > -                 if (st)
> > +                 if (st) {
> >                                    dev_err(CARD_TO_DEV(card),
> >                                                     "Failed loading card
> config\n");
> > +                                  goto failed_dma_setup;
> > +                 }
> >
> >                   /************* Setup DMA Engine *************/
> >                   st = rsxx_get_num_targets(card, &card->n_targets);
> > -                 if (st)
> > +                 if (st) {
> >                                    dev_info(CARD_TO_DEV(card),
> >                                                     "Failed reading the
> number of DMA targets\n");
> > +                                  goto failed_dma_setup;
> > +                 }
> >
> >                   card->ctrl = kzalloc(card->n_targets *
> sizeof(*card->ctrl), GFP_KERNEL);
> >                   if (!card->ctrl) {
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kernel-janitors"
> in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
>
>
>
>