From: Greg KH <greg@kroah.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
Milton Miller <miltonm@bga.com>,
Michael Ellerman <michael@ellerman.id.au>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH/RFC] pci: dynids.use_driver_data considered harmful
Date: Sun, 17 Aug 2008 20:50:37 -0700 [thread overview]
Message-ID: <20080818035037.GC30843@kroah.com> (raw)
In-Reply-To: <20080817210659.06601a3b@hyperion.delvare>
On Sun, Aug 17, 2008 at 09:06:59PM +0200, Jean Delvare wrote:
> Hi all,
>
> On Fri, 15 Aug 2008 23:22:59 -0700, Greg KH wrote:
> > On Fri, Aug 15, 2008 at 12:15:01PM -0700, Jesse Barnes wrote:
> > > On Friday, August 15, 2008 11:55 am Jean Delvare wrote:
> > > > In fact we can do even better than that. We could accept from
> > > > user-space only driver_data values which at least one device ID entry in
> > > > the driver already uses. That should be fairly easy to implement, and
> > > > would offer a level of safety an order of magnitude above what we have
> > > > at the moment... And it works both ways: if 0 is not a valid data for
> > > > some driver, that would force the user to provide a non-zero (and
> > > > valid) data value. And it guarantees that the user can't ask for
> > > > something the driver doesn't expect, so drivers don't even need extra
> > > > checks. And no need for a use_driver_data flag either.
> > >
> > > Meaning a driver audit of the usage? Yeah that would be great.
> > >
> > > > The only drawback is that it prevents the user from passing a "new"
> > > > data value even if it would be valid. But honestly, I don't expect that
> > > > case to happen frequently... if ever at all. So I'd say the benefits
> > > > totally outweight the drawback.
> > > >
> > > > If the interested people agree with the idea, I'll look into
> > > > implementing it.
> > >
> > > Well the audit would show if user supplied "new" values are needed; otherwise
> > > the approach sounds good to me.
> >
> > That sounds reasonable, and should work properly.
> >
> > No objection from me.
>
> Ok, here's what it could look like:
>
> * * * * *
>
> From: Jean Delvare <khali@linux-fr.org>
> Subject: PCI: Check dynids driver_data value for validity
>
> Only accept dynids those driver_data value matches one of the driver's
> pci_driver_id entry. This prevents the user from accidentally passing
> values the drivers do not expect.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
> Cc: Milton Miller <miltonm@bga.com>
> Cc: Greg KH <greg@kroah.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Looks good, thanks for sticking with it and creating this.
greg k-h
next prev parent reply other threads:[~2008-08-18 3:52 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 21:12 [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't Milton Miller
2008-07-10 21:12 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Milton Miller
2008-07-10 21:14 ` mtd: remove __PPC__ hardcoded address from nand/diskonchip and devices/docprobe Milton Miller
2008-07-10 21:14 ` [1/3] powerpc: add _HEAD_GLOBAL to place functions in .text.head Milton Miller
2008-07-10 21:16 ` [2/3] powerpc: head_64.S: put irq vectors " Milton Miller
2008-07-10 21:19 ` powerpc: numa.c: always trim to lmb_end_of_DRAM Milton Miller
2008-07-10 21:20 ` powerpc: pseries, cell: use cpu_thread_in_core in smp_init for of_spin_map Milton Miller
2008-07-10 21:22 ` powerpc: find and destroy possible stale kernel added properties Milton Miller
2008-07-10 21:23 ` powerpc: add static and ifdef prom_strtoul and prom_memparse Milton Miller
2008-07-10 21:29 ` [PATCH] spufs: correct kcalloc usage Milton Miller
2008-07-10 23:04 ` Jeremy Kerr
2008-07-10 21:33 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Hans de Goede
2008-07-10 21:33 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Hans de Goede
2008-07-10 21:33 ` Hans de Goede
2008-07-10 21:51 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Milton Miller
2008-07-10 21:51 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Milton Miller
2008-07-10 21:51 ` Milton Miller
2008-07-11 6:52 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Jean Delvare
2008-07-11 6:52 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Jean Delvare
2008-07-11 6:52 ` Jean Delvare
2008-07-11 7:27 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Hans de Goede
2008-07-11 7:27 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Hans de Goede
2008-07-11 7:27 ` Hans de Goede
2008-07-11 7:36 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Jean Delvare
2008-07-11 7:36 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Jean Delvare
2008-07-11 7:36 ` Jean Delvare
2008-07-13 6:31 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Hans de Goede
2008-07-13 6:31 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Hans de Goede
2008-07-13 6:31 ` Hans de Goede
2008-07-13 21:11 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please David Hubbard
2008-07-13 21:11 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region David Hubbard
2008-07-13 21:11 ` David Hubbard
2008-07-13 21:22 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Hans de Goede
2008-07-13 21:22 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Hans de Goede
2008-07-13 21:22 ` Hans de Goede
2008-07-13 21:26 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please David Hubbard
2008-07-13 21:26 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region David Hubbard
2008-07-13 21:26 ` David Hubbard
2008-07-14 7:59 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Jean Delvare
2008-07-14 7:59 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Jean Delvare
2008-07-14 7:59 ` Jean Delvare
2008-07-14 17:09 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Milton Miller
2008-07-14 17:09 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Milton Miller
2008-07-14 17:09 ` Milton Miller
2008-07-14 17:30 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- Hans de Goede
2008-07-14 17:30 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Hans de Goede
2008-07-14 17:30 ` Hans de Goede
2008-07-14 17:55 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please David Hubbard
2008-07-14 17:55 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region David Hubbard
2008-07-14 17:55 ` David Hubbard
2008-07-15 8:36 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Jean Delvare
2008-07-15 8:36 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Jean Delvare
2008-07-15 8:36 ` Jean Delvare
2008-07-15 15:31 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please David Hubbard
2008-07-15 15:31 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region David Hubbard
2008-07-15 15:31 ` David Hubbard
2008-07-16 7:46 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Jean Delvare
2008-07-16 7:46 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Jean Delvare
2008-07-16 7:46 ` Jean Delvare
2008-07-16 8:09 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Rene Herman
2008-07-16 8:09 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Rene Herman
2008-07-16 8:09 ` Rene Herman
2008-07-15 8:28 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please Jean Delvare
2008-07-15 8:28 ` [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Jean Delvare
2008-07-15 8:28 ` Jean Delvare
[not found] ` <for-27-patch9@bga.com>
2008-07-12 20:02 ` [PATCH/RESEND] pci: dynids.use_driver_data considered harmful Milton Miller
2008-07-12 20:17 ` Greg KH
2008-07-12 20:58 ` Jean Delvare
2008-07-12 21:17 ` Milton Miller
2008-07-12 21:29 ` Milton Miller
[not found] ` <20080712041137.GA5933@kroah.com>
2008-07-12 21:08 ` [PATCH/RFC] " Milton Miller
2008-07-12 22:48 ` Milton Miller
2008-07-16 10:18 ` Milton Miller
2008-07-17 7:07 ` Greg KH
2008-07-17 14:36 ` Milton Miller
2008-08-06 7:31 ` Jean Delvare
2008-08-14 22:12 ` Greg KH
2008-08-15 14:50 ` Milton Miller
2008-08-15 15:50 ` Jean Delvare
2008-08-15 17:46 ` Jesse Barnes
2008-08-15 18:55 ` Jean Delvare
2008-08-15 19:15 ` Jesse Barnes
2008-08-16 6:22 ` Greg KH
2008-08-17 19:06 ` Jean Delvare
2008-08-18 3:50 ` Greg KH [this message]
2008-08-18 17:13 ` Jesse Barnes
2008-08-18 20:41 ` Jesse Barnes
2008-08-19 18:01 ` Milton Miller
2008-08-06 7:22 ` Jean Delvare
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=20080818035037.GC30843@kroah.com \
--to=greg@kroah.com \
--cc=akpm@linux-foundation.org \
--cc=jbarnes@virtuousgeek.org \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=michael@ellerman.id.au \
--cc=miltonm@bga.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.