| 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
| ||
|
Date: Sat, 26 Apr 2014 11:39:38 +0900
From: DaeSeok Youn <daeseok.youn@...il.com>
To: Mark Hounschell <markh@...pro.net>
Cc: Dan Carpenter <dan.carpenter@...cle.com>,
Lidza Louina <lidza.louina@...il.com>,
Greg KH <gregkh@...uxfoundation.org>,
devel <devel@...verdev.osuosl.org>,
driverdev-devel@...uxdriverproject.org,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] staging: dgap: implement error handling in dgap_tty_register()
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".
dgap_Major_XXX_Registered only is used in cleaup function, right?
So code like below
rc = tty_register_driver(brd->PrintDriver);
if (rc < 0)
goto unregister_serial_drv;
brd->dgap_Major_TransparentPrint_Registered = TRUE;
...
unregister_serial_drv;
brd->dgap_Major_Serial_Registered = false;
tty_unregister_driver(brd->SerialDriver);
Thanks.
Regards,
Daeseok Youn.
>
> I need to look at the (dgap_NumBoards < MAXBOARDS) thing too.
>
> Mark
>
>
--
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