linux-kernel - Re: [patch 1/2] fastboot: Add a module parameter to skip probing of specific ports

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Aug 2008 08:39:03 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>,
	linux-ide@...r.kernel.org
Subject: Re: [patch 1/2] fastboot: Add a module parameter to skip probing of
 specific ports

On Mon, 11 Aug 2008 15:36:41 -0700
Arjan van de Ven <arjan@...radead.org> wrote:

> 
> From: Kristen Accardi <kristen.c.accardi@...el.com>
> Subject: [PATCH] libata: Add a module parameter to skip probing of specific ports
> 
> Port probing by libata can easily take 10% or more of the kernel boot
> time (2%+ of total). For cases where one knows there is nothing
> connected to certain ports (for example on netbooks) this is a waste
> of boot time.
> 
> This patch adds a module parameter that allows the admin to specify
> to skip ports (specified by a bitmask) and recoup this boot time.
> This capability is potentially also useful to get systems to boot
> for cases where port-probing on a certain ports causes crashes.
> 
> A follow-on patch will add the capability to use DMI identification
> to automate this for certain known systems.

What happens if I plug in an additional libata using device ? What
defines the probe order here particularly as people are pushing for
parallel probing of multiple devices.

This doesn't appear to make any rational sense as the mask isn't tied to
the actual bus device identifier to keep it on the same port. It might
kidn of work for an EEEPC (until you see what people retrofit into the
corners of them) but it isn't a valid general solution.

Also the EEE problem seems to be a controller specific screwup - they
didn't apparently manage the enablebits on the ATA controller correctly,
so it belongs in that driver. That also lets you tie it to the right
system, pci id, bus id so it'll always hit the right device.

(Plus double check the enables code in case you are papering over the
real bug)

Second problem is you've changed the API. Several drivers do things on
the port 0 register they know they will receive and will simply crash and
burn if you change this.

NAK this patch for now: right theory, wrong implementation. Please post a
version which uses DMI in the relevant driver and checks the PCI DEVFN
matches.

--
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/