From: Johan Hovold <johan@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
Johan Hovold <johan@kernel.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Kees Cook <keescook@chromium.org>
Subject: [v2] USB: serial: io_edgeport: mark expected switch fall-throughs
Date: Thu, 2 May 2019 16:48:12 +0200 [thread overview]
Message-ID: <20190502144812.GW26546@localhost> (raw)
On Thu, May 02, 2019 at 04:40:41PM +0200, Greg Kroah-Hartman wrote:
> On Thu, May 02, 2019 at 09:28:37AM -0500, Gustavo A. R. Silva wrote:
> > >>>> @@ -1813,6 +1813,7 @@ static void process_rcvd_data(struct edgeport_serial *edge_serial,
> > >>>> }
> > >>>> /* Else, drop through */
> > >>>> }
> > >>>> + /* Fall through */
> > >>>> case EXPECT_DATA: /* Expect data */
> > >>>
> > >>> Looks like you forgot to take the original review feedback you got into
> > >>> account:
> > >>>
> > >>> https://lkml.kernel.org/r/87k1zf4k24.fsf@miraculix.mork.no
> > >>>
> > >>
> > >> Oh, the thing is that the fall-through comments have to be placed at
> > >> the very bottom of the case. Also, based on that feedback, this time
> > >> I left the "Else, drop through" comment in place, so people can be
> > >> informed that such fall-through is conditional.
> > >>
> > >> What do you think about this:
> > >>
> > >> diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
> > >> index 4ca31c0e4174..52f27fc82563 100644
> > >> --- a/drivers/usb/serial/io_edgeport.c
> > >> +++ b/drivers/usb/serial/io_edgeport.c
> > >> @@ -1751,7 +1751,7 @@ static void process_rcvd_data(struct edgeport_serial *edge_serial,
> > >> edge_serial->rxState = EXPECT_HDR2;
> > >> break;
> > >> }
> > >> - /* otherwise, drop on through */
> > >> + /* Fall through - otherwise, drop on through */
> > >> case EXPECT_HDR2:
> > >> edge_serial->rxHeader2 = *buffer;
> > >> ++buffer;
> > >> @@ -1813,6 +1813,11 @@ static void process_rcvd_data(struct edgeport_serial *edge_serial,
> > >> }
> > >> /* Else, drop through */
> > >> }
> > >> + /* Beware that, currently, there are at least three
> > >> + * break statements in this case block, so the
> > >> + * fall-through marked below is NOT unconditional.
> > >> + */
> > >> + /* Fall through */
> > >> case EXPECT_DATA: /* Expect data */
> > >> if (bufferLength < edge_serial->rxBytesRemaining) {
> > >> rxLen = bufferLength;
> > >
> > > It's better than v2, but I thought you said you were gonna look into
> > > restructuring the code to maintain (or even improve) readability?
> > >
> >
> > At first, I thought about that, but now I don't think that's realistic.
> > I'd turn the if-else into a switch, and based on the history of feedback
> > on this patch, we will end up having the same complains about the break
> > statements in that new switch and the possibility of a fall-through to
> > case EXPECT_DATA. At the end I would still have to add a comment explaining
> > that the last fall-through mark in unconditional.
>
> I love it how no one is blaming the original author of this code (i.e.
> me...)
>
> Let me see if I can fix it up to be more "sane", this is my fault.
Thanks, that'd be great. I haven't looked at it myself in a long time,
but judging from the old thread it did not seem impossible at least.
Getting rid of some of that deep nesting would be good either way. :)
Johan
WARNING: multiple messages have this Message-ID (diff)
From: Johan Hovold <johan@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
Johan Hovold <johan@kernel.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v2] USB: serial: io_edgeport: mark expected switch fall-throughs
Date: Thu, 2 May 2019 16:48:12 +0200 [thread overview]
Message-ID: <20190502144812.GW26546@localhost> (raw)
Message-ID: <20190502144812.AbfOPbO1kuWbT2Sqs4cOZVldbS123ZQh1fNlgbx0rdo@z> (raw)
In-Reply-To: <20190502144041.GA17960@kroah.com>
On Thu, May 02, 2019 at 04:40:41PM +0200, Greg Kroah-Hartman wrote:
> On Thu, May 02, 2019 at 09:28:37AM -0500, Gustavo A. R. Silva wrote:
> > >>>> @@ -1813,6 +1813,7 @@ static void process_rcvd_data(struct edgeport_serial *edge_serial,
> > >>>> }
> > >>>> /* Else, drop through */
> > >>>> }
> > >>>> + /* Fall through */
> > >>>> case EXPECT_DATA: /* Expect data */
> > >>>
> > >>> Looks like you forgot to take the original review feedback you got into
> > >>> account:
> > >>>
> > >>> https://lkml.kernel.org/r/87k1zf4k24.fsf@miraculix.mork.no
> > >>>
> > >>
> > >> Oh, the thing is that the fall-through comments have to be placed at
> > >> the very bottom of the case. Also, based on that feedback, this time
> > >> I left the "Else, drop through" comment in place, so people can be
> > >> informed that such fall-through is conditional.
> > >>
> > >> What do you think about this:
> > >>
> > >> diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
> > >> index 4ca31c0e4174..52f27fc82563 100644
> > >> --- a/drivers/usb/serial/io_edgeport.c
> > >> +++ b/drivers/usb/serial/io_edgeport.c
> > >> @@ -1751,7 +1751,7 @@ static void process_rcvd_data(struct edgeport_serial *edge_serial,
> > >> edge_serial->rxState = EXPECT_HDR2;
> > >> break;
> > >> }
> > >> - /* otherwise, drop on through */
> > >> + /* Fall through - otherwise, drop on through */
> > >> case EXPECT_HDR2:
> > >> edge_serial->rxHeader2 = *buffer;
> > >> ++buffer;
> > >> @@ -1813,6 +1813,11 @@ static void process_rcvd_data(struct edgeport_serial *edge_serial,
> > >> }
> > >> /* Else, drop through */
> > >> }
> > >> + /* Beware that, currently, there are at least three
> > >> + * break statements in this case block, so the
> > >> + * fall-through marked below is NOT unconditional.
> > >> + */
> > >> + /* Fall through */
> > >> case EXPECT_DATA: /* Expect data */
> > >> if (bufferLength < edge_serial->rxBytesRemaining) {
> > >> rxLen = bufferLength;
> > >
> > > It's better than v2, but I thought you said you were gonna look into
> > > restructuring the code to maintain (or even improve) readability?
> > >
> >
> > At first, I thought about that, but now I don't think that's realistic.
> > I'd turn the if-else into a switch, and based on the history of feedback
> > on this patch, we will end up having the same complains about the break
> > statements in that new switch and the possibility of a fall-through to
> > case EXPECT_DATA. At the end I would still have to add a comment explaining
> > that the last fall-through mark in unconditional.
>
> I love it how no one is blaming the original author of this code (i.e.
> me...)
>
> Let me see if I can fix it up to be more "sane", this is my fault.
Thanks, that'd be great. I haven't looked at it myself in a long time,
but judging from the old thread it did not seem impossible at least.
Getting rid of some of that deep nesting would be good either way. :)
Johan
next prev reply other threads:[~2019-05-02 14:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-01 21:33 [v2] USB: serial: io_edgeport: mark expected switch fall-throughs Gustavo A. R. Silva
2019-05-01 21:33 ` [PATCH v2] " Gustavo A. R. Silva
2019-05-02 10:26 ` [v2] " Johan Hovold
2019-05-02 10:26 ` [PATCH v2] " Johan Hovold
2019-05-02 13:22 ` [v2] " Gustavo A. R. Silva
2019-05-02 13:22 ` [PATCH v2] " Gustavo A. R. Silva
2019-05-02 13:56 ` [v2] " Johan Hovold
2019-05-02 13:56 ` [PATCH v2] " Johan Hovold
2019-05-02 14:28 ` [v2] " Gustavo A. R. Silva
2019-05-02 14:28 ` [PATCH v2] " Gustavo A. R. Silva
2019-05-02 14:40 ` [v2] " Greg Kroah-Hartman
2019-05-02 14:40 ` [PATCH v2] " Greg Kroah-Hartman
2019-05-02 14:47 ` [v2] " Greg Kroah-Hartman
2019-05-02 14:47 ` [PATCH v2] " Greg Kroah-Hartman
2019-05-02 14:57 ` [v2] " Gustavo A. R. Silva
2019-05-02 14:57 ` [PATCH v2] " Gustavo A. R. Silva
2019-05-02 15:04 ` [v2] " Greg Kroah-Hartman
2019-05-02 15:04 ` [PATCH v2] " Greg Kroah-Hartman
2019-05-02 15:14 ` [v2] " Johan Hovold
2019-05-02 15:14 ` [PATCH v2] " Johan Hovold
2019-05-02 14:48 ` Johan Hovold [this message]
2019-05-02 14:48 ` Johan Hovold
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=20190502144812.GW26546@localhost \
--to=johan@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo@embeddedor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/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).