From: Greg KH <gregkh@linuxfoundation.org>
To: Matthias Brugger <mbrugger@suse.com>
Cc: matthias.bgg@kernel.org, rafael@kernel.org,
linux-kernel@vger.kernel.org, gene.chen.richtek@gmail.com,
lee.jones@linaro.org, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH 1/2] drivers: base: Warn if driver name is not present
Date: Mon, 8 Jun 2020 14:15:19 +0200 [thread overview]
Message-ID: <20200608121519.GA306451@kroah.com> (raw)
In-Reply-To: <b8affc8c-3f38-3488-76dd-1b02fcdda329@suse.com>
On Mon, Jun 08, 2020 at 01:48:28PM +0200, Matthias Brugger wrote:
>
>
> On 08/06/2020 12:57, Greg KH wrote:
> > On Mon, Jun 08, 2020 at 11:52:16AM +0200, matthias.bgg@kernel.org wrote:
> >> From: Matthias Brugger <mbrugger@suse.com>
> >>
> >> If we pass a driver without a name, we end up in a NULL pointer
> >> derefernce.
> >
> > That's a very good reason not to have a driver without a name :)
> >
> > What in-kernel driver does this?
> >
> >> Check for the name before trying to register the driver.
> >> As we don't have a driver name to point to in the error message, we dump
> >> the call stack to make it easier to detect the buggy driver.
> >>
> >> Reported-by: kernel test robot <lkp@intel.com>
> >> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
> >> ---
> >> drivers/base/driver.c | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/base/driver.c b/drivers/base/driver.c
> >> index 57c68769e157..40fba959c140 100644
> >> --- a/drivers/base/driver.c
> >> +++ b/drivers/base/driver.c
> >> @@ -149,6 +149,12 @@ int driver_register(struct device_driver *drv)
> >> int ret;
> >> struct device_driver *other;
> >>
> >> + if (!drv->name) {
> >> + pr_err("Driver has no name.\n");
> >> + dump_stack();
> >> + return -EINVAL;
> >
> > Ick, no, an oops-traceback for doing something dumb like this should be
> > all that we need, right?
> >
> > How "hardened" do we need to make internal apis anyway? What's the odds
> > that if this does trigger, the driver author would even notice it?
> >
>
> We just had the case that a driver got accepted in a maintainer repository
> without a name. Which got later found by the kernel test robot.
That driver had obviously never actually been run before :(
> I agree with you that it probably doesn't make much sense to check for this kind
> of bugs, as it should be discoverable if you test your code, before you submit.
>
> I propose to ignore this patch.
Thanks, now dropped!
greg k-h
prev parent reply other threads:[~2020-06-08 12:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-08 9:52 [PATCH 1/2] drivers: base: Warn if driver name is not present matthias.bgg
2020-06-08 9:52 ` [PATCH 2/2] drivers: base: Convert to printk alias functions matthias.bgg
2020-06-08 10:57 ` [PATCH 1/2] drivers: base: Warn if driver name is not present Greg KH
2020-06-08 11:48 ` Matthias Brugger
2020-06-08 12:15 ` Greg KH [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=20200608121519.GA306451@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=gene.chen.richtek@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=matthias.bgg@kernel.org \
--cc=mbrugger@suse.com \
--cc=rafael@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 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.