linux-kernel - Re: [PATCH] staging: dgap: implement error handling in dgap_tty

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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHb8M2DC==5Z40iNdq=or+9E15KH3UR-w_yeTzt1PT_-dCnZ0A@mail.gmail.com>
Date:	Mon, 28 Apr 2014 08:21:34 +0900
From:	DaeSeok Youn <daeseok.youn@...il.com>
To:	Dan Carpenter <dan.carpenter@...cle.com>
Cc:	Mark Hounschell <markh@...pro.net>,
	devel <devel@...verdev.osuosl.org>,
	Lidza Louina <lidza.louina@...il.com>,
	driverdev-devel@...uxdriverproject.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] staging: dgap: implement error handling in dgap_tty_register()

OK. I'll make my patch based on Mark's patch.
Thanks.

Daeseok Youn.

2014-04-27 3:48 GMT+09:00 Dan Carpenter <dan.carpenter@...cle.com>:
> On Sat, Apr 26, 2014 at 11:39:38AM +0900, DaeSeok Youn wrote:
>> Hi,
>>
>> please check below my comments.
>>
>> 2014-04-25 23:41 GMT+09:00 Mark Hounschell <markh@...pro.net>:
>> > On 04/25/2014 08:59 AM, Dan Carpenter wrote:
>> >> On Fri, Apr 25, 2014 at 08:29:41AM -0400, Mark Hounschell wrote:
>> >>> On 04/25/2014 07:02 AM, DaeSeok Youn wrote:
>> >>>> Hi, Dan.
>> >>>>
>> >>>> 2014-04-25 18:26 GMT+09:00 Dan Carpenter <dan.carpenter@...cle.com>:
>> >>>>> Mark, maybe you should add yourself to the MAINTAINERS entry for this
>> >>>>> driver?
>> >>>>>
>> >>>
>> >>> I'll look into this. I am clueless on what that would actually mean.
>> >>>
>> >>
>> >> Just add your name with Lidza in the MAINTAINERS file so that people
>> >> will CC you on all the patches.
>> >>
>> >> DIGI EPCA PCI PRODUCTS
>> >> M:      Lidza Louina <lidza.louina@...il.com>
>> >> L:      driverdev-devel@...uxdriverproject.org
>> >> S:      Maintained
>> >> F:      drivers/staging/dgap/
>> >>
>> >> You don't have to do it if you don't want to, but you seem to be working
>> >> on this driver and I'm going to refer questions to you either way.  :P
>> >>
>> >>>>> On Fri, Apr 25, 2014 at 04:04:59PM +0900, Daeseok Youn wrote:
>> >>>>>> @@ -1263,7 +1277,8 @@ static int dgap_tty_register(struct board_t *brd)
>> >>>>>>               /* Register tty devices */
>> >>>>>>               rc = tty_register_driver(brd->SerialDriver);
>> >>>>>>               if (rc < 0)
>> >>>>>> -                     return rc;
>> >>>>>> +                     goto free_print_ttys;
>> >>>>>> +
>> >>>>>>               brd->dgap_Major_Serial_Registered = TRUE;
>> >>>>>>               dgap_BoardsByMajor[brd->SerialDriver->major] = brd;
>> >>>>>>               brd->dgap_Serial_Major = brd->SerialDriver->major;
>> >>>>>> @@ -1273,13 +1288,29 @@ static int dgap_tty_register(struct board_t *brd)
>> >>>>>>               /* Register Transparent Print devices */
>> >>>>>>               rc = tty_register_driver(brd->PrintDriver);
>> >>>>>>               if (rc < 0)
>> >>>>>> -                     return rc;
>> >>>>>> +                     goto unregister_serial_drv;
>> >>>>>> +
>> >>>>>>               brd->dgap_Major_TransparentPrint_Registered = TRUE;
>> >>>>>>               dgap_BoardsByMajor[brd->PrintDriver->major] = brd;
>> >>>>>>               brd->dgap_TransparentPrint_Major = brd->PrintDriver->major;
>> >>>>>>       }
>> >>>>>>
>> >>>>>>       return rc;
>> >>>>>> +
>> >>>>>> +unregister_serial_drv:
>> >>>>>> +     tty_unregister_driver(brd->SerialDriver);
>> >>>>>
>> >>>>> We only register the ->SerialDriver if someone else hasn't registered it
>> >>>>> first?  So this should be:
>> >>>>>
>> >>>>>         if (we_were_the_ones_who_registered_the_serial_driver)
>> >>>>>                 tty_unregister_driver(brd->SerialDriver);
>> >>>>>
>> >>>>> I haven't followed looked at this.  Who else is registering the serial
>> >>>>> driver?  You have looked at this, what do you think?  Or Mark.
>> >>>>
>> >>>
>> >>> registering the brd->XxxxxDriver is only done when a board is detected
>> >>> and only during the firmware_load process. If we fail to
>> >>> tty_register_driver do we _need_ to tty_unregister_driver? Isn't that
>> >>> like freeing after an alloc failure?
>> >>
>> >> The allocation is conditional so the free should be conditional.  If we
>> >> didn't allocate it, then we shouldn't free it.
>> >>
>> >> It wouldn't have even been a question except I'm not sure the allocation
>> >> is *really* conditional because brd->dgap_Major_Serial_Registered might
>> >> always be "false" like you guys seem to be saying.
>> >>
>> >>>
>> >>>> I think brd struct is from dgap_Board array as global static variable
>> >>>> when this function is
>> >>>> called. So brd->dgap_Major_Serial_Registered is always "false".
>> >>>> If dgap_NumBoards is less than MAXBOARDS, brd->SerialDriver should be
>> >>>> registered.
>> >>>>
>> >>>> I'm not sure..
>> >>>>
>> >>>
>> >>> I don't see any check for (dgap_NumBoards <  MAXBOARDS), which I think I
>> >>> probably should, but I do see we are calling dgap_tty_register, which
>> >>> can fail, without actually checking the return value. Also, yes,
>> >>> dgap_Major_Xxxx_Registered seems to be always "false" until registered,
>> >>> and it looks like dgap_Major_Xxxxx_Registered flags could be removed
>> >>> because the only places we can unregister is at module_cleanup or
>> >>> "after" it is already registered.
>> >>>
>> >>> What is the driver _supposed_ to do if we fail something on the second
>> >>> or later board? Is the driver supposed to cleanup and exit or are we
>> >>> supposed to stay loaded for the board/boards that are usable?
>> >>
>> >> Stay loaded.
>> >>
>> >
>> > Then these tests on brd->dgap_Major_Serial_Registered need to stay in
>> > there. If I have 3 boards and the second fails in some way, if I rmmod
>> > the driver they will protect from unregistering a never registered one.
>> > At least in the unregister code path. There is probably no need for them
>> > in the register code path. I'll work up a patch for this.
>>
>> Should I update my patch?
>>
>> I think "if (!brd->dgap_Major_XXX_Registered)" line can be removed in this
>> function, because if tty_register_driver() is failed just set "false"
>> to "dgap_Major_XXX_Registered".
>
> Mark sent a patch to remove the check.  Could you redo your patch based
> on his?
>
> regards,
> dan carpenter
>
--
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/