All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Cc: devel@driverdev.osuosl.org, Ivan Safonov <insafonov@gmail.com>,
	Takashi Iwai <tiwai@suse.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kernel-janitors@vger.kernel.org,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: [PATCH] staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan()
Date: Fri, 5 Mar 2021 21:32:59 +0300	[thread overview]
Message-ID: <20210305183259.GE2087@kadam> (raw)
In-Reply-To: <CAOc6etYqu_SJPjZtZdp4xDX=MVB0XY67tJ-EYoDYWuLfEyjnrw@mail.gmail.com>

On Fri, Mar 05, 2021 at 10:58:17AM -0600, Edmundo Carmona Antoranz wrote:
> On Fri, Mar 5, 2021 at 2:59 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > -                                       if (sec_len > 0 && sec_len <= len) {
> > +                                       if (sec_len > 0 &&
> > +                                           sec_len <= len &&
> > +                                           sec_len <= 32) {
> 
> I wonder if this could be reduced to (sec_len > 0 && sec_len <=
> min(len, 32)) from a stylistic POV?

I kind of prefer it the way I wrote it.  I prefer conditions split
apart and done ploddingly, one at a time...  You'll notice how I could
have written it like:

					if (sec_len > 0 && sec_len <= len &&
					    sec_len <= 32) {

But I really like my conditions to be spelled out so the "sec_len" is
perfectly aligned in each part of the condition.  Your way would be to
combine two conditions into one part of a line and seems sneaky.

> 
> First attempt at something kernel related so I know there's plenty of
> things to learn (including patterns for problems like this and
> etiquette).

It's good that you're reviewing code...  We try to be predictable though
and no one would have predicted your response.  Ideally patch review
should be like, "Ugh!  Why didn't I think of that?  Of course, we should
propagate the error code."  Or "Oh, I didn't know checkpatch warns about
that."

The truth is that I don't always agree with all of Greg's reviews.  He
is more strict than I am about breaking up patches into multiple things.
(It's a tricky line to define for me).  But I can always predict what
Greg will say in a review so that saves time when I know which patches
he will accept and which he won't.

regards,
dan carpenter

  reply	other threads:[~2021-03-05 21:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05  8:58 [PATCH] staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan() Dan Carpenter
2021-03-05 16:58 ` Edmundo Carmona Antoranz
2021-03-05 18:32   ` Dan Carpenter [this message]
2021-03-05 18:55     ` Edmundo Carmona Antoranz
2022-05-18  7:00 ` [PATCH] staging: r8188eu: prevent ->Ssid " Denis Efremov
2022-05-18  7:49   ` Denis Efremov
2022-05-19 15:40     ` Greg KH
2022-05-20  3:57       ` [PATCH v5.10] staging: rtl8723bs: " Denis Efremov (Oracle)
2022-05-23 15:26         ` Greg KH
2022-05-23 17:41           ` Denis Efremov
2022-05-26 12:05             ` Greg KH
2022-05-26 12:05         ` Patch "staging: rtl8723bs: prevent ->Ssid overflow in rtw_wx_set_scan()" has been added to the 5.10-stable tree gregkh
2022-05-23 17:39       ` [PATCH v5.4-v4.14] staging: rtl8723bs: prevent ->Ssid overflow in rtw_wx_set_scan() Denis Efremov (Oracle)
2022-05-26 12:05         ` Patch "staging: rtl8723bs: prevent ->Ssid overflow in rtw_wx_set_scan()" has been added to the 4.14-stable tree gregkh
2022-05-26 12:05         ` Patch "staging: rtl8723bs: prevent ->Ssid overflow in rtw_wx_set_scan()" has been added to the 4.19-stable tree gregkh
2022-05-26 12:05         ` Patch "staging: rtl8723bs: prevent ->Ssid overflow in rtw_wx_set_scan()" has been added to the 5.4-stable tree gregkh
2022-05-19 15:45   ` [PATCH] staging: r8188eu: prevent ->Ssid overflow in rtw_wx_set_scan() Greg KH
2022-05-19 17:16     ` Dan Carpenter
2022-05-19 17:36       ` Greg KH

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=20210305183259.GE2087@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=eantoranz@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=insafonov@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=memxor@gmail.com \
    --cc=tiwai@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.