linux-kernel - Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

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]

Message-ID: <20070430182945.240530@gmx.net>
Date:	Mon, 30 Apr 2007 20:29:45 +0200
From:	"Uwe Bugla" <uwe.bugla@....de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-dvb@...uxtv.org, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, helge.hafting@...el.hist.no,
	mchehab@...radead.org
Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and
 pseudo-authorities

-------- Original-Nachricht --------
Datum: Mon, 30 Apr 2007 11:14:14 -0700
Von: Andrew Morton <akpm@...ux-foundation.org>
An: "Uwe Bugla" <uwe.bugla@....de>
CC: Mauro Carvalho Chehab <mchehab@...radead.org>, helge.hafting@...el.hist.no, torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org, linux-dvb@...uxtv.org
Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

> On Mon, 30 Apr 2007 19:25:47 +0200
> "Uwe Bugla" <uwe.bugla@....de> wrote:
> 
> > I did not manage to at least find one single unresolved module during
> compilation, and I have been working with this almost fantastic solution with
> several kernels for months now!
> 
> That isn't what Mauro is saying.  What he is saying is that the missing
> symbols will not be reported at build time.  The kernel will all link
> correctly and will appear to load modules correctly.
> 
> See, there's a third mechanism for symbol resolution which is used at
> runtime, not at build time: symbol_request().
> 
> What Mauro is saying is that these changes will cause symbol_request() to
> return different results on some people's setups with different hardware,
> causing those setups to fail.

Hi Andrew,
But, even if this is the case, it should be transparent WHAT DIFFERENT HARDWARE
IS MEANT EXACTLY! DST AND DST_CA CANNOT BE MEANT - this I have made quite shure!

I swear I did not notice any errors - so as long as I cannot see through where the problem is, and as long as I have been working with my patches without the slightest noise for months now - where should I apply some additions then?

See, there's a third mechanism for symbol resolution which is used at
runtime, not at build time: symbol_request().

If this symbol_request() appears at runtime, then there should be some feedback in dmesg or any other kind of syslog.

But I swear I haven't seen any kind of bad or counterproductive messages like this!
My system runs excelent with my patches - so why should I care?

I meanwhile have sent my patches to someone, he will have a look at them - and we all will see what happens then.

Above that I will at least try to enhance those two patches by a dvb-pll.c deselection feature which I said very politely to Trent that I am missing it.

And I want to get out now of that horrible discussion - I am exhausted.

Cheers
Uwe

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
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/