linux-kernel - Re: BUG: unable to handle kernel paging request in usb_match

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 19 Aug 2012 07:35:32 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	Ming Lei <tom.leiming@...il.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Oliver Neukum <oneukum@...e.de>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	linux-kernel@...r.kernel.org,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"Lan, Tianyu" <tianyu.lan@...el.com>
Subject: Re: BUG: unable to handle kernel paging request in usb_match_id()

On Sun, Aug 19, 2012 at 12:23:38PM +0200, Bjørn Mork wrote:
> Ming Lei <tom.leiming@...il.com> writes:
> > On Fri, Aug 17, 2012 at 10:42 PM, Greg Kroah-Hartman
> > <gregkh@...uxfoundation.org> wrote:
> >> On Fri, Aug 17, 2012 at 10:38:16AM -0400, Alan Stern wrote:
> >>> On Fri, 17 Aug 2012, Ming Lei wrote:
> >>>
> >>> > But,  if HOTPLUG is not enabled, should device_add() trigger driver probe
> >>> > further after kernel init is completed?  Or even devices should be allowed
> >>> > to add into system?
> >>>
> >>> Indeed, does it make any sense to have USB support at all if HOTPLUG
> >>> isn't enabled?  Should USB select HOTPLUG?
> >>
> >> Well, a long time ago people wanted to use USB but not have HOTPLUG
> >> enabled in their systems for various (odd) embedded systems.  As it's
> >> pretty hard to even turn off HOTPLUG these days, I'd be more likely to
> >> just remove CONFIG_HOTPLUG entirely given the dynamic nature of almost
> >> all systems.
> >
> > It should make sense, otherwise all device id table should not use
> > __devinit* markings. There are lots of pci driver usage on it.
> 
> You might want to start here then:
> 
> /**
>  * DEFINE_PCI_DEVICE_TABLE - macro used to describe a pci device table
>  * @_table: device table name
>  *
>  * This macro is used to create a struct pci_device_id array (a device table)
>  * in a generic manner.
>  */
> #define DEFINE_PCI_DEVICE_TABLE(_table) \
>         const struct pci_device_id _table[] __devinitconst
> 

That's not as big of a problem, as pci drivers are usually left as a
module, and very few people dynamically add and remove pci devices on
systems that do not have CONFIG_HOTPLUG enabled.

Not to say that it couldn't happen, just that it is rare.

And it shows again that __devinitconst just needs to be removed, I'll
work on that soon and see what happens...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/