From: Dan Carpenter <dan.carpenter@oracle.com>
To: Daeseok Youn <daeseok.youn@gmail.com>
Cc: lidza.louina@gmail.com, gregkh@linuxfoundation.org,
markh@compro.net, driverdev-devel@linuxdriverproject.org,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] staging: dgap: implement proper error handling in dgap_firmware_load()
Date: Tue, 27 May 2014 13:20:02 +0300 [thread overview]
Message-ID: <20140527102002.GI17724@mwanda> (raw)
In-Reply-To: <20140527070937.GA21621@devel.8.8.4.4>
The "brd->nasync = 0;" was wrong, yes, but my main complaint was that
you are writing complicated error handling. This v2 patch makes the
error handling even more complicated. If dgap_tty_init() fails it
should free the things it allocates itself, instead of the caller
handling errors for it.
It's not actually that hard. The only error handling we need to do in
dgap_tty_init() is if the kzalloc() fails:
1374 /*
1375 * Allocate channel memory that might not have been allocated
1376 * when the driver was first loaded.
1377 */
1378 for (i = 0; i < brd->nasync; i++) {
1379 if (!brd->channels[i]) {
1380 brd->channels[i] =
1381 kzalloc(sizeof(struct channel_t), GFP_KERNEL);
1382 if (!brd->channels[i])
1383 return -ENOMEM;
Instead of returning directly here we should free the previous
allocations.
1384 }
1385 }
The code is confusing because which ones did we allocate and which ones
were already non-NULL at the start of the function? In other words
the "if (!brd->channels[i]) {" test?
The answer is that the comment and the test seem to be wrong they were
all NULL at the start of the function. Just add a:
free_chan:
while (--i >= 0) {
kfree(brd->channels[i]);
brd->channels[i] = NULL;
}
return ret;
Actually, for these I would introduce an "int chan" variable just for
that loop instead of "i" which we re-use.
So then we remove the call to dgap_tty_uninit() from
dgap_firmware_load().
regards,
dan carpenter
next prev parent reply other threads:[~2014-05-27 10:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 7:09 [PATCH V2] staging: dgap: implement proper error handling in dgap_firmware_load() Daeseok Youn
2014-05-27 10:20 ` Dan Carpenter [this message]
2014-05-27 23:36 ` DaeSeok Youn
2014-05-28 7:02 ` Dan Carpenter
2014-05-28 9:29 ` DaeSeok Youn
2014-05-28 10:11 ` Dan Carpenter
2014-05-29 0:17 ` DaeSeok Youn
2014-05-29 6:40 ` Dan Carpenter
2014-05-29 20:59 ` Greg KH
[not found] ` <1203682594.1176349.1401271946432.JavaMail.root@mx2.compro.net>
2014-05-28 14:14 ` Mark Hounschell
2014-05-28 14:26 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140527102002.GI17724@mwanda \
--to=dan.carpenter@oracle.com \
--cc=daeseok.youn@gmail.com \
--cc=devel@driverdev.osuosl.org \
--cc=driverdev-devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=lidza.louina@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markh@compro.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).