public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Vincent Stehlé" <vincent.stehle@intel.com>
To: Darren Hart <dvhart@infradead.org>
Cc: platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Sujith Thomas <sujith.thomas@intel.com>,
	Zhang Rui <rui.zhang@intel.com>, Len Brown <len.brown@intel.com>,
	Rafael Wysocki <rjw@rjwysocki.net>
Subject: Re: [PATCH] intel_menlow: prevent NULL pointer dereference
Date: Thu, 9 Jun 2016 19:24:52 +0200	[thread overview]
Message-ID: <20160609172452.GA32327@jazz.nc.intel.com> (raw)
In-Reply-To: <20160608203846.GG28348@f23x64.localdomain>

On Wed, Jun 08, 2016 at 01:38:46PM -0700, Darren Hart wrote:
> Under what circumstances can the .remove op be called with a NULL struct
> acpi_device * as a parameter? From what I can see, most acpi_* calls accpeting
> an acpi_device rely on it not being null, and they are regularly called from
> driver remove functions.
> Did you observe an explicit failure or can you describe a call path where this
> can occur?

Hi Darren,

Thank you for reviewing.

I am not sure about when the .remove() functions are called with a NULL
pointer, or if that can ever happen. I just noticed that dereferencing the
pointer and checking for NULL after did not seem to be the right thing to
do. So I wanted to replicate instead the same construct as e.g.
xen_acpi_processor_remove().

Your remark encouraged me to do some more digging into the sources and it
appears that 13 .remove() functions do indeed check their input device
pointer for NULL, while 26 do not (the remaining do not use their input
pointer at all). Now I am puzzled about the necessity to check the pointer
for NULL or not, and there does not seem to be a definitive answer in the
docs either...

Best regards,

Vincent.

  reply	other threads:[~2016-06-09 17:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-25 14:20 [PATCH] intel_menlow: prevent NULL pointer dereference Vincent Stehlé
2016-06-08 20:38 ` Darren Hart
2016-06-09 17:24   ` Vincent Stehlé [this message]
2016-06-09 19:53     ` Darren Hart

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=20160609172452.GA32327@jazz.nc.intel.com \
    --to=vincent.stehle@intel.com \
    --cc=dvhart@infradead.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rui.zhang@intel.com \
    --cc=sujith.thomas@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox