[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120814144310.GD5277@herton-Z68MA-D2H-B3>
Date: Tue, 14 Aug 2012 11:43:11 -0300
From: Herton Ronaldo Krzesinski <herton.krzesinski@...onical.com>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: Jiri Kosina <jkosina@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>,
linux-kernel@...r.kernel.org, Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH v3 4/6] floppy: properly handle failure on add_disk loop
On Tue, Aug 14, 2012 at 04:31:23AM +0100, Ben Hutchings wrote:
> On Mon, 2012-08-13 at 15:16 -0300, Herton Ronaldo Krzesinski wrote:
> > On do_floppy_init, if something failed inside the loop we call add_disk,
> > there was no cleanup of previous iterations in the error handling.
> >
> > Cc: stable@...r.kernel.org
> > Acked-by: Vivek Goyal <vgoyal@...hat.com>
> > Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@...onical.com>
>
> This depends on 3/6. If that's replaced by my proposed fix, then:
>
> > ---
> > drivers/block/floppy.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> > index 9272203..3eafe93 100644
> > --- a/drivers/block/floppy.c
> > +++ b/drivers/block/floppy.c
> > @@ -4294,7 +4294,7 @@ static int __init do_floppy_init(void)
> >
> > err = platform_device_register(&floppy_device[drive]);
> > if (err)
> > - goto out_release_dma;
> > + goto out_remove_drives;
> >
> > err = device_create_file(&floppy_device[drive].dev,
> > &dev_attr_cmos);
> > @@ -4313,6 +4313,14 @@ static int __init do_floppy_init(void)
> >
> > out_unreg_platform_dev:
> > platform_device_unregister(&floppy_device[drive]);
> > +out_remove_drives:
> > + while (drive--) {
> > + if (disk_registered[drive]) {
>
> I think the test of allowed_drive_mask and FDC version before
> registering each driver should be factored out into a function that you
> can use here. There would then no need for the disk_registered array.
Seems a better approach. I'll redo the patches, but I'm not sure how to
proceed now, since it depends on your change. Patches 4-6 that I did
needs to be dropped/redone. At first my patches 0001/0002 could be
applied with yours, then I would submit another series for the rest. Or
I could take your change and submit your patch along with my series.
>
> Ben.
>
--
[]'s
Herton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists