From: Dan Carpenter <dan.carpenter@oracle.com>
To: Rupesh Gujare <rupesh.gujare@atmel.com>
Cc: devel@linuxdriverproject.org, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] staging: ozwpan: Increment port number for new device.
Date: Mon, 5 Aug 2013 23:23:38 +0300 [thread overview]
Message-ID: <20130805202338.GO5051@mwanda> (raw)
In-Reply-To: <51FFF244.9000604@atmel.com>
On Mon, Aug 05, 2013 at 07:43:16PM +0100, Rupesh Gujare wrote:
> On 05/08/13 18:53, Dan Carpenter wrote:
> >On Mon, Aug 05, 2013 at 06:40:13PM +0100, Rupesh Gujare wrote:
> >>This patch fixes crash issue when there is quick cycle of
> >>de-enumeration & enumeration due to loss of wireless link.
> >>
> >>It is found that sometimes new device (or coming back device)
> >>returns very fast, even before USB core read out hub status,
> >>resulting in allocation of same port, which results in unstable
> >>system & crash.
> >>
> >>Above issue is resolved by making sure that we always assign
> >>new port to new device, making sure that USB core reads correct
> >>hub status.
> >>
> >This feels like papering over the problem. Surely the real fix
> >would be to improve the reference counting.
> >
> >This patch is probably effective but it makes the code more subtle
> >and it shows that we don't really understand what we are doing with
> >regards to reference counting.
> >
> >
>
> Probably this is easier way to fix issue, since we don't have
> reference count for ports & we rely on flags to check port status.
> Any suggestions are appreciated.
To be honest, I wish someone would just go through and make this
look more like kernel style. It's very ugly to look at. Even a
very cursory patch series would make a big difference:
[patch 1/6] Add a blank line between declaractions and code.
[patch 2/6] Add a blank line between functions
[patch 3/6] Make oz_hcd_pd_arrived() return a struct pointer (instead of a void pointer)
[patch 4/6] Make oz_hcd_pd_departed() take a struct pointer
[patch 5/6] Swap arguments of oz_ep_alloc() to match kmalloc()
[patch 6/6] Remove unneeded initializers
Also it's better to separate the success path from the failure path
because it means fewer intend levels. The way oz_hcd_pd_arrived()
looks now it's easy to think we free "ep" but actually we do this
spaghetti thing of setting it to NULL on success. This function
should just be:
frob();
frob();
ret = frob();
if (ret)
goto err_put;
frob();
frob();
ret = frob();
if (ret)
goto err_free_ep;
frob();
frob();
put();
return hport;
err_free_ep:
free_ep();
err_put:
put();
return NULL;
But instead it is:
frob();
ret = frob();
if (ret) {
unlock();
goto out;
}
frob();
ret = frob();
if (ret success) {
frob();
frob();
ep = NULL;
frob();
unlock();
frob();
} else {
unlock();
}
out:
if (ep)
free_ep();
put();
return something;
In the second example most of the code is indented. It's so hard
to read because there are unlocks scattered throughout. Meanwhile,
if you separate success and failure then there are only two unlocks,
one for success and one for failure.
In the current code you have to set "ep" to NULL on the success path
and then test it and or free it. If you separate them out then it's
obvious that "ep" is not freed on success.
If you separate them out then it's clear that we return NULL on
failure. In the current code you have to scroll back to the start
of the function.
Obviously it's not an emergency to fix any of these style issues but
it will need to be addressed eventually before it moves out of
staging. I think as well that just cleaning things up helps to
fix bugs.
regards,
dan carpenter
next prev parent reply other threads:[~2013-08-05 20:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 17:40 [PATCH 0/4] staging: ozwpan: Fix crash issues Rupesh Gujare
2013-08-05 17:40 ` [PATCH 1/4] staging: ozwpan: Fixes crash due to invalid port aceess Rupesh Gujare
2013-08-05 18:20 ` Dan Carpenter
2013-08-05 17:40 ` [PATCH 2/4] staging: ozwpan: Increment port number for new device Rupesh Gujare
2013-08-05 17:53 ` Dan Carpenter
2013-08-05 18:43 ` Rupesh Gujare
2013-08-05 20:23 ` Dan Carpenter [this message]
2013-08-05 20:33 ` Dan Carpenter
2013-08-06 10:26 ` Rupesh Gujare
2013-08-06 10:41 ` Dan Carpenter
2013-08-12 21:57 ` Greg KH
2013-08-05 17:40 ` [PATCH 3/4] staging: ozwpan: Reset port configuration number Rupesh Gujare
2013-08-05 18:21 ` Dan Carpenter
2013-08-05 18:58 ` Rupesh Gujare
2013-08-05 17:40 ` [PATCH 4/4] staging: ozwpan: Return correct hub status Rupesh Gujare
2013-08-05 18:56 ` Dan Carpenter
2013-08-05 19:00 ` Rupesh Gujare
2013-08-05 19:28 ` 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=20130805202338.GO5051@mwanda \
--to=dan.carpenter@oracle.com \
--cc=devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rupesh.gujare@atmel.com \
/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