From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Cc: andreas.noever@gmail.com, michael.jamet@intel.com,
YehezkelShB@gmail.com, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Re: [PATCH] thunderbolt: Check for null pointer after calling kmemdup
Date: Wed, 5 Jan 2022 12:11:11 +0200 [thread overview]
Message-ID: <YdVuv9ZvYmmW1nQX@lahna> (raw)
In-Reply-To: <20220105085307.2410653-1-jiasheng@iscas.ac.cn>
On Wed, Jan 05, 2022 at 04:53:07PM +0800, Jiasheng Jiang wrote:
> On Wed, Jan 05, 2022 at 03:30:47PM +0800, Mika Westerberg wrote:
> > This is doing two things so I suggest sending two patches instead.
>
> Fine, I have already sent the patch for icm_handle_event() independently.
Thanks!
> > However, for the UUID part, I think it works fine if we get NULL (and I
> > think kmemdup() issues warning too).
> >
> > There are probably not needed either since the "fix" here is for pretty
> > rare case of running out of memory. I think there is not even a NULL
> > pointer dereference because UUID is optional.
>
> As for icm_icl_set_uuid(), I think the check for kmemdup() is needed.
> Because users need to know that icm_start() fails, or they will be puzzled
> why the uuid is unsetted.
> So at least it is a cleanup.
> if so, I would like to send patch for icm_icl_set_uuid() without fixes tag.
I don't think icm_start() actually fails because if this. If the UUID is
not set tb_switch_add() will look it up from the host router vendor area
then.
We can log a warning or something like that (but I think that's already
done in kmemdup()).
prev parent reply other threads:[~2022-01-05 10:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-05 8:53 Re: [PATCH] thunderbolt: Check for null pointer after calling kmemdup Jiasheng Jiang
2022-01-05 10:11 ` Mika Westerberg [this message]
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=YdVuv9ZvYmmW1nQX@lahna \
--to=mika.westerberg@linux.intel.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=jiasheng@iscas.ac.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=michael.jamet@intel.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 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.