linux-kernel - Re: [GIT]: Networking for 2.6.28

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]

Message-Id: <20081011.150456.193701531.davem@davemloft.net>
Date:	Sat, 11 Oct 2008 15:04:56 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	torvalds@...ux-foundation.org
Cc:	akpm@...ux-foundation.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, philipl@...rt.org, hmh@....eng.br,
	linville@...driver.com
Subject: Re: [GIT]: Networking for 2.6.28

From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Sat, 11 Oct 2008 13:10:52 -0700 (PDT)

> On Sat, 11 Oct 2008, David Miller wrote:
> > This patch should fix that case, let me know if it works:
> 
> How about you test it? 

Yep, indeed I did give it a try.

> It wasn't my bug-report, I just reported another 
> report from somebody who _does_ run randconfig.

Where did you see this?  I wouldn't have asked all of these idiotic
questions if I had a link to the report.  Then I could go grab the
config used to produce the problem and then ping the reporter with
a test patch. :-)

> Here's another one:
> 
> 	drivers/built-in.o: In function `bt_poll_rfkill':
> 	toshiba_acpi.c:(.text+0x37346): undefined reference to `input_event'
> 
> where the cause seems to be a totally broken Kconfig entry ACPI_TOSHIBA.

Where are these reports coming from?  Some automated randconfig thing
that gets posted somewhere?  I'd really like to look at this stuff, it
seems very useful.

> You can't just do
> 
> 	select INPUT_POLLDEV
> 
> since that in turn needs all the _other_ input stuff. Yes, yes, things 
> like various keyboard drivers do exactly that, but they are already inside 
> "if INPUT_KEYBOARD/INPUT_MISC" or similar.
> 
> So at the very least, you'd now have to have it do a "depends on INPUT" or 
> something like that.
> 
> Or perhaps just make that particular _feature_ depend on it, rather than 
> make the whole driver depend on or select it. 

Do you want me to fix this ACPI build failure in the networking tree?
I'm more than happy to :-)

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