From: Keith Owens <kaos@ocs.com.au>
To: linux-kernel@vger.kernel.org
Subject: Re: [RFC] 2.5.8 sort kernel tables
Date: Fri, 19 Apr 2002 01:38:59 +1000 [thread overview]
Message-ID: <3112.1019144339@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "Thu, 18 Apr 2002 23:02:11 +1000." <15550.50131.489249.256007@nanango.paulus.ozlabs.org>
On Thu, 18 Apr 2002 23:02:11 +1000 (EST),
Paul Mackerras <paulus@samba.org> wrote:
>We already sort the kernel exception table on PPC using an insertion
>sort. We have chrp, pmac, prep sections as well as init, which is why
>we had to do that.
Good, I will pinch that code and use it on all architectures.
>BTW, do you have any valid examples of use of copy_to/from_user or
>get/put_user in an init section?
No, I was using those functions as an example. The problem is
__ex_table, there is other code that uses __ex_table besides
copy_to_user. It is quite legal for an arch setup routine to use a
.fixup/__ex_table wrapper around code that might fail on some platforms
and to have that setup routine marked __init.
For example, arm #defines get8_unaligned_check which uses __ex_table.
__get_qspan_pci_config in ppc also uses __ex_table. Use of any of
these macros (and others) in an __init section will generate unsorted
tables. One table has already broken because of out of order text
sections. Other tables may be broken, depending on what __init code an
architecture uses.
The real nasty is that we do not know if the table is broken until an
exception table entry is used and we fail to find an entry because the
table is not sorted. Some exception table entries will work, others
will not, but there is no mechanism to test if the table is valid, we
blindly assume that it is. It is far safer to sort the tables at boot
time than to hope that they are always sorted.
next prev parent reply other threads:[~2002-04-18 15:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-18 9:46 Keith Owens
2002-04-18 10:21 ` Matthias Andree
2002-04-18 10:32 ` Keith Owens
2002-04-18 10:52 ` Alan Cox
2002-04-18 13:02 ` Paul Mackerras
2002-04-18 15:38 ` Keith Owens [this message]
2002-04-18 15:52 ` Russell King
2002-04-18 16:09 ` Keith Owens
2002-04-18 13:59 ` William Lee Irwin III
2002-04-18 18:16 ` Kai Henningsen
2002-04-18 18:24 ` William Lee Irwin III
2002-04-19 11:46 ` David Weinehall
2002-04-18 20:20 ` Oliver Xymoron
2002-04-19 4:59 ` Matt
2002-04-19 13:45 ` Jamie Lokier
2002-04-19 13:46 ` Jamie Lokier
2002-04-19 14:25 ` Oliver Xymoron
2002-04-19 15:16 ` Tobias Wollgam
[not found] <1589.1019123186@ocs3.intra.ocs.com.au.suse.lists.linux.kernel>
[not found] ` <15550.50131.489249.256007@nanango.paulus.ozlabs.org.suse.lists.linux.kernel>
2002-04-18 17:51 ` Andi Kleen
2002-04-18 23:17 ` Keith Owens
2002-04-19 11:38 Randal, Phil
2002-04-20 5:19 ` Keith Owens
2002-04-20 8:50 ` Alan Cox
2002-04-20 9:40 ` Keith Owens
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=3112.1019144339@ocs3.intra.ocs.com.au \
--to=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®