public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Greg KH <greg@kroah.com>, 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: Fri, 15 Aug 2008 20:55:00 +0200	[thread overview]
Message-ID: <20080815205500.1945916f@hyperion.delvare> (raw)
In-Reply-To: <200808151046.59590.jbarnes@virtuousgeek.org>

Hi Jesse,

On Fri, 15 Aug 2008 10:46:59 -0700, Jesse Barnes wrote:
> So I think your point about dynamic IDs in general is a good one; this flag 
> really does look like an "audit was done" bit, but doesn't go as far is it 
> should.
> 
> The patch you posted to forbid dynamic binding unless use_driver_data is iset 
> is probably the safest thing to do, given that drivers that *don't* set 
> use_driver_data look like they might misbehave even with a driver_data value 
> of 0...

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.

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.

-- 
Jean Delvare

  reply	other threads:[~2008-08-15 18:55 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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:33 ` [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region Hans de Goede
2008-07-10 21:51   ` Milton Miller
2008-07-11  6:52     ` Jean Delvare
2008-07-11  7:27       ` Hans de Goede
2008-07-11  7:36         ` Jean Delvare
2008-07-13  6:31           ` Hans de Goede
2008-07-13 21:11             ` [lm-sensors] " David Hubbard
2008-07-13 21:22               ` Hans de Goede
2008-07-13 21:26                 ` David Hubbard
2008-07-14  7:59                   ` Jean Delvare
2008-07-14 17:09                     ` Milton Miller
2008-07-14 17:30                       ` [lm-sensors] " Hans de Goede
2008-07-14 17:55                         ` David Hubbard
2008-07-15  8:36                           ` Jean Delvare
2008-07-15 15:31                             ` David Hubbard
2008-07-16  7:46                               ` Jean Delvare
2008-07-16  8:09                                 ` Rene Herman
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 [this message]
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
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=20080815205500.1945916f@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=jbarnes@virtuousgeek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox