Re: 2.6.23-rc3-mm1 -- drivers/ net/wireless/zd1211rw-mac80211/zd_mac.c:822: erro r: ‘IEEE80211_ERP_CHANGE_PREAMBLE ’ undeclared (first use in this function)
Miles Lane wrote:
> CC [M] drivers/net/wireless/zd1211rw-mac80211/zd_mac.o
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c: In function
> 'zd_op_erp_ie_changed':
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error:
> 'IEEE80211_ERP_CHANGE_PREAMBLE' undeclared (first use in this
> function)
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: (Each
> undeclared identifier is reported only once
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: for each
> function it appears in.)
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c: At top level:
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:844: error: unknown
> field 'erp_ie_changed' specified in initializer
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:844: warning:
> initialization from incompatible pointer type
> make[4]: *** [drivers/net/wireless/zd1211rw-mac80211/zd_mac.o] Error 1
Probably following patch is missing from -mm. Notify also that
zd1211rw-mac80211 is currently not working on wireless-dev.git
branch everything, so even with the ERP patch, zd1211rw-mac80211
will probably not work on -mm.
I had to write my own git-patch-mangling script to be able to create a
tree that allowed me to bisect the problem. (The script is able to
replay "git log -p" output.) The result of the bisect has been the
patch titled "mac80211: split RX handlers into own file" and it is
quite large. I had no chance so far to have a further look.
commit 741f99b32747492ca0d8bb4cc0602e15ffc513b9
Author: Daniel Drake <[EMAIL PROTECTED]>
Date: Fri Jul 27 15:43:24 2007 +0200
[PATCH] mac80211: implement ERP info change notifications
zd1211rw and bcm43xx are interested in being notified when ERP IE conditions
change, so that they can reprogram a register which affects how control
frames
are transmitted.
This patch adds an interface similar to the one that can be found in
softmac.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 3282038..e503cd3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -697,6 +697,14 @@ struct ieee80211_ops {
void (*sta_table_notification)(struct ieee80211_hw *hw,
int num_sta);
+ /* Handle ERP IE change notifications. Must be atomic. */
+ void (*erp_ie_changed)(struct ieee80211_hw *hw, u8 changes,
+ int cts_protection, int preamble);
+
+ /* Flags for the erp_ie_changed changes parameter */
+#define IEEE80211_ERP_CHANGE_PROTECTION (1<<0) /* protection flag changed */
+#define IEEE80211_ERP_CHANGE_PREAMBLE (1<<1) /* barker preamble mode changed */
+
/* Configure TX queue parameters (EDCF (aifs, cw_min, cw_max),
* bursting) for a hardware TX queue.
* queue = IEEE80211_TX_QUEUE_*.
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index befc97b..f6e650a 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -464,8 +464,10 @@ static int ieee80211_open(struct net_device *dev)
if (sdata->type == IEEE80211_IF_TYPE_MNTR) {
local->monitors++;
local->hw.conf.flags |= IEEE80211_CONF_RADIOTAP;
- } else
+ } else {
ieee80211_if_config(dev);
+ ieee80211_reset_erp_info(dev);
+ }
if (sdata->type == IEEE80211_IF_TYPE_STA &&
!local->user_space_mlme)
@@ -748,6 +750,27 @@ int ieee80211_hw_config(struct ieee80211_local *local)
return ret;
}
+void ieee80211_erp_info_change_notify(struct net_device *dev, u8 changes)
+{
+ struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ if (local->ops->erp_ie_changed)
+ local->ops->erp_ie_changed(local_to_hw(local), changes,
+ sdata->use_protection,
+ !sdata->short_preamble);
+}
+
+void ieee80211_reset_erp_info(struct net_device *dev)
+{
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+
+ sdata->short_preamble = 0;
+ sdata->use_protection = 0;
+ ieee80211_erp_info_change_notify(dev,
+IEEE80211_ERP_CHANGE_PROTECTION |
+IEEE80211_ERP_CHANGE_PREAMBLE);
+}
+
struct dev_mc_list *ieee80211_get_mc_list_item(struct ieee80211_hw *hw,
struct dev_mc_list *prev,
void **ptr)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index b0af6e9..ccc 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -788,6 +788,8 @@ struct sta_info * ieee80211_ibss_add_sta(struct
Re: 2.6.23-rc3-mm1 -- drivers/ net/wireless/zd1211rw-mac80211/zd_mac.c:822: erro r: ‘IEEE80211_ERP_CHANGE_PREAMBLE ’ undeclared (first use in this function)
Miles Lane wrote:
CC [M] drivers/net/wireless/zd1211rw-mac80211/zd_mac.o
drivers/net/wireless/zd1211rw-mac80211/zd_mac.c: In function
'zd_op_erp_ie_changed':
drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error:
'IEEE80211_ERP_CHANGE_PREAMBLE' undeclared (first use in this
function)
drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: (Each
undeclared identifier is reported only once
drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: for each
function it appears in.)
drivers/net/wireless/zd1211rw-mac80211/zd_mac.c: At top level:
drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:844: error: unknown
field 'erp_ie_changed' specified in initializer
drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:844: warning:
initialization from incompatible pointer type
make[4]: *** [drivers/net/wireless/zd1211rw-mac80211/zd_mac.o] Error 1
Probably following patch is missing from -mm. Notify also that
zd1211rw-mac80211 is currently not working on wireless-dev.git
branch everything, so even with the ERP patch, zd1211rw-mac80211
will probably not work on -mm.
I had to write my own git-patch-mangling script to be able to create a
tree that allowed me to bisect the problem. (The script is able to
replay git log -p output.) The result of the bisect has been the
patch titled mac80211: split RX handlers into own file and it is
quite large. I had no chance so far to have a further look.
commit 741f99b32747492ca0d8bb4cc0602e15ffc513b9
Author: Daniel Drake [EMAIL PROTECTED]
Date: Fri Jul 27 15:43:24 2007 +0200
[PATCH] mac80211: implement ERP info change notifications
zd1211rw and bcm43xx are interested in being notified when ERP IE conditions
change, so that they can reprogram a register which affects how control
frames
are transmitted.
This patch adds an interface similar to the one that can be found in
softmac.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
Signed-off-by: John W. Linville [EMAIL PROTECTED]
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 3282038..e503cd3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -697,6 +697,14 @@ struct ieee80211_ops {
void (*sta_table_notification)(struct ieee80211_hw *hw,
int num_sta);
+ /* Handle ERP IE change notifications. Must be atomic. */
+ void (*erp_ie_changed)(struct ieee80211_hw *hw, u8 changes,
+ int cts_protection, int preamble);
+
+ /* Flags for the erp_ie_changed changes parameter */
+#define IEEE80211_ERP_CHANGE_PROTECTION (10) /* protection flag changed */
+#define IEEE80211_ERP_CHANGE_PREAMBLE (11) /* barker preamble mode changed */
+
/* Configure TX queue parameters (EDCF (aifs, cw_min, cw_max),
* bursting) for a hardware TX queue.
* queue = IEEE80211_TX_QUEUE_*.
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index befc97b..f6e650a 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -464,8 +464,10 @@ static int ieee80211_open(struct net_device *dev)
if (sdata-type == IEEE80211_IF_TYPE_MNTR) {
local-monitors++;
local-hw.conf.flags |= IEEE80211_CONF_RADIOTAP;
- } else
+ } else {
ieee80211_if_config(dev);
+ ieee80211_reset_erp_info(dev);
+ }
if (sdata-type == IEEE80211_IF_TYPE_STA
!local-user_space_mlme)
@@ -748,6 +750,27 @@ int ieee80211_hw_config(struct ieee80211_local *local)
return ret;
}
+void ieee80211_erp_info_change_notify(struct net_device *dev, u8 changes)
+{
+ struct ieee80211_local *local = wdev_priv(dev-ieee80211_ptr);
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ if (local-ops-erp_ie_changed)
+ local-ops-erp_ie_changed(local_to_hw(local), changes,
+ sdata-use_protection,
+ !sdata-short_preamble);
+}
+
+void ieee80211_reset_erp_info(struct net_device *dev)
+{
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+
+ sdata-short_preamble = 0;
+ sdata-use_protection = 0;
+ ieee80211_erp_info_change_notify(dev,
+IEEE80211_ERP_CHANGE_PROTECTION |
+IEEE80211_ERP_CHANGE_PREAMBLE);
+}
+
struct dev_mc_list *ieee80211_get_mc_list_item(struct ieee80211_hw *hw,
struct dev_mc_list *prev,
void **ptr)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index b0af6e9..ccc 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -788,6 +788,8 @@ struct sta_info * ieee80211_ibss_add_sta(struct net_device
*dev,
Re: Is PIE randomization breaking klibc binaries?
H. Peter Anvin wrote: > Yup... it should probably be pointed out the reason the old kernel > worked was nothing but pure dumb luck. This was a GNU ld change which > needed to be undone for klibc. It's unfortunate that stock x86-64 > binaries leave as little of a null pointer range as they do, but that's > life, unfortunately. The other alternative is to map klibc just below > the 2 GB point, which would also work, but the old way broke when the ld > change went in. As previously stated, klibc-1.4.35 or higher fixes this. > > -hpa Just for the record: The kernel with the PIE patch boots perfectly using the klibc 1.5 shared binaries on my machine. -- Uli Kunitz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is PIE randomization breaking klibc binaries?
Sergey Vlasov wrote: > On Wed, 25 Jul 2007 08:32:43 +0200 Ulrich Kunitz wrote: > > [...] > > Here is some output from objdump: > > > > $ objdump -x bin/sleep > > > > bin/sleep: file format elf64-x86-64 > > bin/sleep > > architecture: i386:x86-64, flags 0x0102: > > EXEC_P, D_PAGED > > start address 0x0040014c > > > > Program Header: > > PHDR off0x0040 vaddr 0x00400040 paddr > > 0x00400040 align 2**3 > > filesz 0x00e0 memsz 0x00e0 flags r-x > > INTERP off0x0120 vaddr 0x00400120 paddr > > 0x00400120 align 2**0 > > filesz 0x002a memsz 0x002a flags r-- > > LOAD off0x vaddr 0x0040 paddr > > 0x0040 align 2**21 > > filesz 0x01c3 memsz 0x01c3 flags r-x > >STACK off0x vaddr 0x paddr > > 0x align 2**3 > > filesz 0x memsz 0x flags rwx > > > > Sections: > > Idx Name Size VMA LMA File off > > Algn > > 0 .interp 002a 00400120 00400120 0120 > > 2**0 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > 1 .text 0059 0040014c 0040014c 014c > > 2**2 > > CONTENTS, ALLOC, LOAD, READONLY, CODE > > 2 .rodata 001e 004001a5 004001a5 01a5 > > 2**0 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > 3 .gnu_debuglink 000c 01c3 > > 2**0 > > CONTENTS, READONLY > > SYMBOL TABLE: > > no symbols > > > > > > $ objdump -x lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so > >. What version of klibc is this? I think you found it: 1.4.30-3ubuntu2. > > > > > lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so: file format elf64-x86-64 > > lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so > > architecture: i386:x86-64, flags 0x0102: > > EXEC_P, D_PAGED > > start address 0x00200200 > > > > Program Header: > > LOAD off0x vaddr 0x0020 paddr > > 0x0020 align 2**21 > > filesz 0x0001197e memsz 0x0001197e flags r-x > > LOAD off0x00011980 vaddr 0x00411980 paddr > > 0x00411980 align 2**21 > > Note that the vaddr here can overlap the binary which is linked starting > at 0x40. > > This is the bug which I have found and fixed some time ago: > > http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=10df6dfb13ffefe716f12136bbc667f18ff64744 > > The fix was included in klibc-1.4.35, but does not seem to be applied in > your case (the alignment is still 2**21 - it should be 2**20) - so > either you are using an old klibc, or the "-z max-page-size=0x10" > option does not take effect for some reason. > > In my case the buggy klibc worked fine with a stock 2.6.18 kernel, but > broke when the execshield patch was applied - and the commit 60bfba7e > code comes from execshield, so it looks like the same problem. > > > filesz 0x0100 memsz 0x4288 flags rw- > >STACK off0x vaddr 0x paddr > > 0x align 2**3 > > filesz 0x memsz 0x flags rwx > > > > Sections: > > Idx Name Size VMA LMA File off > > Algn > > 0 .text da94 00200200 00200200 0200 > > 2**2 > > CONTENTS, ALLOC, LOAD, READONLY, CODE > > 1 .rodata 3cde 0020dca0 0020dca0 dca0 > > 2**5 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > 2 .data 0100 00411980 00411980 00011980 > > 2**5 > > CONTENTS, ALLOC, LOAD, DATA > > 3 .bss 4188 00411a80 00411a80 00011a80 > > 2**5 > > ALLOC > > 4 .gnu_debuglink 002c 00011a80 > > 2**0 > > CONTENTS, READONLY > > SYMBOL TABLE: > > no symbols > > -- Uli Kunitz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is PIE randomization breaking klibc binaries?
Sergey Vlasov wrote: On Wed, 25 Jul 2007 08:32:43 +0200 Ulrich Kunitz wrote: [...] Here is some output from objdump: $ objdump -x bin/sleep bin/sleep: file format elf64-x86-64 bin/sleep architecture: i386:x86-64, flags 0x0102: EXEC_P, D_PAGED start address 0x0040014c Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x00e0 memsz 0x00e0 flags r-x INTERP off0x0120 vaddr 0x00400120 paddr 0x00400120 align 2**0 filesz 0x002a memsz 0x002a flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x01c3 memsz 0x01c3 flags r-x STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .interp 002a 00400120 00400120 0120 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0059 0040014c 0040014c 014c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 001e 004001a5 004001a5 01a5 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu_debuglink 000c 01c3 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols $ objdump -x lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so . What version of klibc is this? I think you found it: 1.4.30-3ubuntu2. lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so: file format elf64-x86-64 lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so architecture: i386:x86-64, flags 0x0102: EXEC_P, D_PAGED start address 0x00200200 Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 Note that the vaddr here can overlap the binary which is linked starting at 0x40. This is the bug which I have found and fixed some time ago: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=10df6dfb13ffefe716f12136bbc667f18ff64744 The fix was included in klibc-1.4.35, but does not seem to be applied in your case (the alignment is still 2**21 - it should be 2**20) - so either you are using an old klibc, or the -z max-page-size=0x10 option does not take effect for some reason. In my case the buggy klibc worked fine with a stock 2.6.18 kernel, but broke when the execshield patch was applied - and the commit 60bfba7e code comes from execshield, so it looks like the same problem. filesz 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 00011a80 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is PIE randomization breaking klibc binaries?
H. Peter Anvin wrote: Yup... it should probably be pointed out the reason the old kernel worked was nothing but pure dumb luck. This was a GNU ld change which needed to be undone for klibc. It's unfortunate that stock x86-64 binaries leave as little of a null pointer range as they do, but that's life, unfortunately. The other alternative is to map klibc just below the 2 GB point, which would also work, but the old way broke when the ld change went in. As previously stated, klibc-1.4.35 or higher fixes this. -hpa Just for the record: The kernel with the PIE patch boots perfectly using the klibc 1.5 shared binaries on my machine. -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is PIE randomization breaking klibc binaries?
Jiri Kosina wrote: > On Tue, 31 Jul 2007, H. Peter Anvin wrote: > > > > So it seems to me that either it is something x86_64 specific or > > > initramfs-specific. Will try to reproduce it. > > My guess would be the former, rather than the latter. I haven't had a > > chance to reproduce it myself yet (I'm on the road), but I will try to > > get the time tomorrow. > > I still wasn't successful reproducing it with 2.6.23-rc1 + > pie-randomization.patch with klibc-1.5 on x86_64 system -- all programs > from 'shared' and 'static' seem to be running well. > > Ulrich, could you please send me your .config? Thanks, Here is the .config file. I used it directly with 60bfba7e8 and could reproduce the bug. (All other builds after the patch could also reproduce the bug.) I use klibc-utils 1.4.30-3ubuntu2 which depends on libklibc with the same version number. The processor is an Intel Core 2 Duo T5500 @ 1.66 GHz, if that helps. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22 # Wed Jul 25 07:48:18 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-pie" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_VIRT_TO_BUS=y CONFIG_NR_CPUS=2 CONFIG_PHYSICAL_ALIGN=0x20 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set
Re: Is PIE randomization breaking klibc binaries?
Jiri Kosina wrote: On Tue, 31 Jul 2007, H. Peter Anvin wrote: So it seems to me that either it is something x86_64 specific or initramfs-specific. Will try to reproduce it. My guess would be the former, rather than the latter. I haven't had a chance to reproduce it myself yet (I'm on the road), but I will try to get the time tomorrow. I still wasn't successful reproducing it with 2.6.23-rc1 + pie-randomization.patch with klibc-1.5 on x86_64 system -- all programs from 'shared' and 'static' seem to be running well. Ulrich, could you please send me your .config? Thanks, Here is the .config file. I used it directly with 60bfba7e8 and could reproduce the bug. (All other builds after the patch could also reproduce the bug.) I use klibc-utils 1.4.30-3ubuntu2 which depends on libklibc with the same version number. The processor is an Intel Core 2 Duo T5500 @ 1.66 GHz, if that helps. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22 # Wed Jul 25 07:48:18 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-pie # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_VIRT_TO_BUS=y CONFIG_NR_CPUS=2 CONFIG_PHYSICAL_ALIGN=0x20 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_K8_NB=y
Re: Is PIE randomization breaking klibc binaries?
On 07-07-24 15:45 H. Peter Anvin wrote: > Chuck Ebbert wrote: > > > >Okay, I tested with Fedora on x86_64 and it worked there too. > >(Not that that proves much.) > > > >Did you capture any of the error messages, like the address > >of the segfault? > > > > FWIW, on x86-64, this should show up in dmesg. > > -hpa Ok, I have tested it again. The message looks like: sleep[7888]: segfault at 0004001C rip 0004001C rsp 7fff14776468 error 14 Repeated calls get the same message with the stack pointer changing. Other binaries (mount) have a segmentation fault at another addressi (0x400184). It appears that the instruction pointer fails at the start address of the klibc binary. Notify that this lies in the binary itself and not in the /lib/klibc*.so object, so it appears that the klibc binary sections are loaded at randomized addresses. Here is some output from objdump: $ objdump -x bin/sleep bin/sleep: file format elf64-x86-64 bin/sleep architecture: i386:x86-64, flags 0x0102: EXEC_P, D_PAGED start address 0x0040014c Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x00e0 memsz 0x00e0 flags r-x INTERP off0x0120 vaddr 0x00400120 paddr 0x00400120 align 2**0 filesz 0x002a memsz 0x002a flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x01c3 memsz 0x01c3 flags r-x STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .interp 002a 00400120 00400120 0120 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0059 0040014c 0040014c 014c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 001e 004001a5 004001a5 01a5 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu_debuglink 000c 01c3 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols $ objdump -x lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so: file format elf64-x86-64 lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so architecture: i386:x86-64, flags 0x0102: EXEC_P, D_PAGED start address 0x00200200 Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 filesz 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 00011a80 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols -- Uli Kunitz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is PIE randomization breaking klibc binaries?
On 07-07-24 15:45 H. Peter Anvin wrote: Chuck Ebbert wrote: Okay, I tested with Fedora on x86_64 and it worked there too. (Not that that proves much.) Did you capture any of the error messages, like the address of the segfault? FWIW, on x86-64, this should show up in dmesg. -hpa Ok, I have tested it again. The message looks like: sleep[7888]: segfault at 0004001C rip 0004001C rsp 7fff14776468 error 14 Repeated calls get the same message with the stack pointer changing. Other binaries (mount) have a segmentation fault at another addressi (0x400184). It appears that the instruction pointer fails at the start address of the klibc binary. Notify that this lies in the binary itself and not in the /lib/klibc*.so object, so it appears that the klibc binary sections are loaded at randomized addresses. Here is some output from objdump: $ objdump -x bin/sleep bin/sleep: file format elf64-x86-64 bin/sleep architecture: i386:x86-64, flags 0x0102: EXEC_P, D_PAGED start address 0x0040014c Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x00e0 memsz 0x00e0 flags r-x INTERP off0x0120 vaddr 0x00400120 paddr 0x00400120 align 2**0 filesz 0x002a memsz 0x002a flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x01c3 memsz 0x01c3 flags r-x STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .interp 002a 00400120 00400120 0120 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0059 0040014c 0040014c 014c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 001e 004001a5 004001a5 01a5 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu_debuglink 000c 01c3 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols $ objdump -x lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so: file format elf64-x86-64 lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so architecture: i386:x86-64, flags 0x0102: EXEC_P, D_PAGED start address 0x00200200 Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 filesz 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 00011a80 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is PIE randomization breaking klibc binaries?
On 07-07-24 15:45 H. Peter Anvin wrote: > Chuck Ebbert wrote: > > > >Okay, I tested with Fedora on x86_64 and it worked there too. > >(Not that that proves much.) > > > >Did you capture any of the error messages, like the address > >of the segfault? > > > > FWIW, on x86-64, this should show up in dmesg. > > -hpa Guys, this is at boot time and most of the binaries don't work. However at the end busybox is called and then there is a shell, where I can call the binaries and force the segmentation violation. Pencil and paper work usually. But right now I don't have the broken kernel anymore and it's 1 am here. Wait for tomorrow. -- Uli Kunitz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is PIE randomization breaking klibc binaries?
On 07-07-24 16:57 Chuck Ebbert wrote:
> > $ strace ./cat
> > execve("./cat", ["./cat"], [/* 55 vars */]) = -1 ENOENT (No such file or
> > directory)
> > ...
Chuck, my binaries run always into a segmentation violation. So
ENOENT is not the issue. (Notify it was on an x86-64.)
> > $ file cat
> > cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically
> > linked (uses shared libs), stripped
> >
> > Funny nobody noticed that before...
> >
>
> After installing klibc.so and klibc-.so into /lib everything works:
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> PHDR 0x34 0x08048034 0x08048034 0xa0 0xa0 R E 0x4
> INTERP 0xd4 0x080480d4 0x080480d4 0x2a 0x2a R 0x1
> [Requesting program interpreter:
> /lib/klibc-58kBUyV_qhVvkMnaxy8A7N8rLak.so]
>
Yes, these files were present in the initrd.img file. I checked it
by unpacking the initrd.img file. Notify also that I used
git-bisect to identify the PIE patch. This requires successful
builds. Reverting the patch clearly resolved the issue at the end.
> Ulrich, did your initrd contain the correct .so?
Sure! I have only one klibc-*.so on my box in /lib. I diffed the
file in the unpacked initrd.img with the file in /lib and there
has been no difference.
I always recreate the initial ramdisk after the kernel rebuild
with make install and my own installkernel script, which uses
mkinitramfs. The mkinitramfs script ensures that the klibc so
object from /lib and the klibc binaries from /usr/lib/klibc/bin
are copied into the initrd image. Usually that works without any
issue on x86, x86-64. PPC can't use make install, but I use
mkinitramfs there too, which handles klibc the same way.
> Did you try rebuilding klibc after building the new kernel?
Rebuilding klibc doesn't make sense from my point of view. What
should be the point of it?
--
Uli Kunitz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is PIE randomization breaking klibc binaries?
On 07-07-24 16:57 Chuck Ebbert wrote: $ strace ./cat execve(./cat, [./cat], [/* 55 vars */]) = -1 ENOENT (No such file or directory) ... Chuck, my binaries run always into a segmentation violation. So ENOENT is not the issue. (Notify it was on an x86-64.) $ file cat cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked (uses shared libs), stripped Funny nobody noticed that before... After installing klibc.so and klibc-ID.so into /lib everything works: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x34 0x08048034 0x08048034 0xa0 0xa0 R E 0x4 INTERP 0xd4 0x080480d4 0x080480d4 0x2a 0x2a R 0x1 [Requesting program interpreter: /lib/klibc-58kBUyV_qhVvkMnaxy8A7N8rLak.so] Yes, these files were present in the initrd.img file. I checked it by unpacking the initrd.img file. Notify also that I used git-bisect to identify the PIE patch. This requires successful builds. Reverting the patch clearly resolved the issue at the end. Ulrich, did your initrd contain the correct .so? Sure! I have only one klibc-*.so on my box in /lib. I diffed the file in the unpacked initrd.img with the file in /lib and there has been no difference. I always recreate the initial ramdisk after the kernel rebuild with make install and my own installkernel script, which uses mkinitramfs. The mkinitramfs script ensures that the klibc so object from /lib and the klibc binaries from /usr/lib/klibc/bin are copied into the initrd image. Usually that works without any issue on x86, x86-64. PPC can't use make install, but I use mkinitramfs there too, which handles klibc the same way. Did you try rebuilding klibc after building the new kernel? Rebuilding klibc doesn't make sense from my point of view. What should be the point of it? -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is PIE randomization breaking klibc binaries?
On 07-07-24 15:45 H. Peter Anvin wrote: Chuck Ebbert wrote: Okay, I tested with Fedora on x86_64 and it worked there too. (Not that that proves much.) Did you capture any of the error messages, like the address of the segfault? FWIW, on x86-64, this should show up in dmesg. -hpa Guys, this is at boot time and most of the binaries don't work. However at the end busybox is called and then there is a shell, where I can call the binaries and force the segmentation violation. Pencil and paper work usually. But right now I don't have the broken kernel anymore and it's 1 am here. Wait for tomorrow. -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is PIE randomization breaking klibc binaries?
Since this week new linux-2.6/master kernels don't work with my initial ram disks. The sleep binary runs repeatingly into segmentation faults until the Busybox shell starts. My system is a x86-64 with Kubuntu Feisty Fawn. By bisecting I found out that the PIE randomization patch (commit 60bfba7e) appears to cause the segmentation faults. Digging further into the issue I found out, that the sleep binary on the initial ramdisk is a klibc binary. /usr/bin/file says it is statically linked and uses shared libraries. I have no clue about klibc, but the binaries seem to be statically linked, but load a shared library; probably at a fixed address. Other klibc binaries are also running into segmentation faults. Busybox is working, but it is statically linked and doesn't use a shared library. It looks like that the PIE randomization patch breaks klibc binaries on x86-64. -- Uli Kunitz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is PIE randomization breaking klibc binaries?
Since this week new linux-2.6/master kernels don't work with my initial ram disks. The sleep binary runs repeatingly into segmentation faults until the Busybox shell starts. My system is a x86-64 with Kubuntu Feisty Fawn. By bisecting I found out that the PIE randomization patch (commit 60bfba7e) appears to cause the segmentation faults. Digging further into the issue I found out, that the sleep binary on the initial ramdisk is a klibc binary. /usr/bin/file says it is statically linked and uses shared libraries. I have no clue about klibc, but the binaries seem to be statically linked, but load a shared library; probably at a fixed address. Other klibc binaries are also running into segmentation faults. Busybox is working, but it is statically linked and doesn't use a shared library. It looks like that the PIE randomization patch breaks klibc binaries on x86-64. -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] softmac: Fixed handling of deassociation from AP
In 2.6.19 a deauthentication from the AP doesn't start a
reassociation by the softmac code. It appears that
mac->associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled. This patch
fixes that.
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
---
net/ieee80211/softmac/ieee80211softmac_assoc.c | 14 --
net/ieee80211/softmac/ieee80211softmac_auth.c |2 ++
net/ieee80211/softmac/ieee80211softmac_priv.h |2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index cf51c87..614aa8d 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -427,6 +427,17 @@ ieee80211softmac_handle_assoc_response(s
return 0;
}
+void
+ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ mac->associnfo.associating = 1;
+ schedule_work(>associnfo.work);
+ spin_unlock_irqrestore(>lock, flags);
+}
+
int
ieee80211softmac_handle_disassoc(struct net_device * dev,
struct ieee80211_disassoc *disassoc)
@@ -445,8 +456,7 @@ ieee80211softmac_handle_disassoc(struct
dprintk(KERN_INFO PFX "got disassoc frame\n");
ieee80211softmac_disassoc(mac);
- /* try to reassociate */
- schedule_work(>associnfo.work);
+ ieee80211softmac_try_reassoc(mac);
return 0;
}
diff --git a/net/ieee80211/softmac/ieee80211softmac_auth.c
b/net/ieee80211/softmac/ieee80211softmac_auth.c
index 4cef39e..88897e4 100644
--- a/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ b/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -328,6 +328,8 @@ ieee80211softmac_deauth_from_net(struct
/* can't transmit data right now... */
netif_carrier_off(mac->dev);
spin_unlock_irqrestore(>lock, flags);
+
+ ieee80211softmac_try_reassoc(mac);
}
/*
diff --git a/net/ieee80211/softmac/ieee80211softmac_priv.h
b/net/ieee80211/softmac/ieee80211softmac_priv.h
index 0642e09..3ae894f 100644
--- a/net/ieee80211/softmac/ieee80211softmac_priv.h
+++ b/net/ieee80211/softmac/ieee80211softmac_priv.h
@@ -238,4 +238,6 @@ void ieee80211softmac_call_events_locked
int ieee80211softmac_notify_internal(struct ieee80211softmac_device *mac,
int event, void *event_context, notify_function_ptr fun, void *context,
gfp_t gfp_mask);
+void ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac);
+
#endif /* IEEE80211SOFTMAC_PRIV_H_ */
--
1.4.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] softmac: Fixed handling of deassociation from AP
In 2.6.19 a deauthentication from the AP doesn't start a
reassociation by the softmac code. It appears that
mac-associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled. This patch
fixes that.
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
---
net/ieee80211/softmac/ieee80211softmac_assoc.c | 14 --
net/ieee80211/softmac/ieee80211softmac_auth.c |2 ++
net/ieee80211/softmac/ieee80211softmac_priv.h |2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index cf51c87..614aa8d 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -427,6 +427,17 @@ ieee80211softmac_handle_assoc_response(s
return 0;
}
+void
+ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(mac-lock, flags);
+ mac-associnfo.associating = 1;
+ schedule_work(mac-associnfo.work);
+ spin_unlock_irqrestore(mac-lock, flags);
+}
+
int
ieee80211softmac_handle_disassoc(struct net_device * dev,
struct ieee80211_disassoc *disassoc)
@@ -445,8 +456,7 @@ ieee80211softmac_handle_disassoc(struct
dprintk(KERN_INFO PFX got disassoc frame\n);
ieee80211softmac_disassoc(mac);
- /* try to reassociate */
- schedule_work(mac-associnfo.work);
+ ieee80211softmac_try_reassoc(mac);
return 0;
}
diff --git a/net/ieee80211/softmac/ieee80211softmac_auth.c
b/net/ieee80211/softmac/ieee80211softmac_auth.c
index 4cef39e..88897e4 100644
--- a/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ b/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -328,6 +328,8 @@ ieee80211softmac_deauth_from_net(struct
/* can't transmit data right now... */
netif_carrier_off(mac-dev);
spin_unlock_irqrestore(mac-lock, flags);
+
+ ieee80211softmac_try_reassoc(mac);
}
/*
diff --git a/net/ieee80211/softmac/ieee80211softmac_priv.h
b/net/ieee80211/softmac/ieee80211softmac_priv.h
index 0642e09..3ae894f 100644
--- a/net/ieee80211/softmac/ieee80211softmac_priv.h
+++ b/net/ieee80211/softmac/ieee80211softmac_priv.h
@@ -238,4 +238,6 @@ void ieee80211softmac_call_events_locked
int ieee80211softmac_notify_internal(struct ieee80211softmac_device *mac,
int event, void *event_context, notify_function_ptr fun, void *context,
gfp_t gfp_mask);
+void ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac);
+
#endif /* IEEE80211SOFTMAC_PRIV_H_ */
--
1.4.1
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tiny MM performance and typo patches for 2.4.2
Hi folks,
this is a list of patches I collected while looking at the memory
management sources. Two patches might improve the performance of your
box. The others are more or less cosmetic.
This mail is sent with a kernel using these patches.
Here is a list sorted with decreasing importance:
patch-uk2 makes use of the pgd, pmd and pte quicklists for x86 too;
risky: there might be a reason that 2.4.x doesn't use the
quicklists.
patch-uk6 In 2.4.x _page_hashfn divides struct address_space pointer
with a parameter derived from the size of struct
inode. Deriving this parameter from the size of struct
address_space makes more sense -- at least for me.
patch-uk5 cleans the bd_flush_param union.
patch-uk1 fixes a comment typo in asm-i386/highmem.h.
patch-uk3 fixes a comment typo in asm-i386/pgtable-3level.h.
Ciao,
Uli Kunitz
--
Ulrich Kunitz ([EMAIL PROTECTED])
--- linux-2.4.2/include/asm-i386/pgalloc.h Thu Feb 22 01:09:57 2001
+++ linux/include/asm-i386/pgalloc.hSun Mar 4 20:14:50 2001
@@ -92,9 +92,9 @@
free_page((unsigned long)pte);
}
-#define pte_free_kernel(pte)free_pte_slow(pte)
-#define pte_free(pte) free_pte_slow(pte)
-#define pgd_free(pgd) free_pgd_slow(pgd)
+#define pte_free_kernel(pte)free_pte_fast(pte)
+#define pte_free(pte) free_pte_fast(pte)
+#define pgd_free(pgd) free_pgd_fast(pgd)
#define pgd_alloc() get_pgd_fast()
extern inline pte_t * pte_alloc_kernel(pmd_t * pmd, unsigned long address)
@@ -145,7 +145,7 @@
* inside the pgd, so has no extra memory associated with it.
* (In the PAE case we free the page.)
*/
-#define pmd_free(pmd) free_pmd_slow(pmd)
+#define pmd_free(pmd) free_pmd_fast(pmd)
#define pmd_free_kernelpmd_free
#define pmd_alloc_kernel pmd_alloc
--- linux-2.4.2/include/linux/pagemap.h Thu Feb 22 01:10:01 2001
+++ linux/include/linux/pagemap.h Sun Mar 4 20:14:50 2001
@@ -58,7 +58,8 @@
*/
extern inline unsigned long _page_hashfn(struct address_space * mapping, unsigned
long index)
{
-#define i (((unsigned long) mapping)/(sizeof(struct inode) & ~ (sizeof(struct inode)
- 1)))
+#define i (((unsigned long) mapping) / \
+ (sizeof(struct address_space) & ~ (sizeof(struct address_space) - 1)))
#define s(x) ((x)+((x)>>PAGE_HASH_BITS))
return s(i+index) & (PAGE_HASH_SIZE-1);
#undef i
--- linux-2.4.2/fs/buffer.c Fri Feb 9 20:29:44 2001
+++ linux/fs/buffer.c Sun Mar 4 19:27:31 2001
@@ -112,19 +112,18 @@
*/
union bdflush_param {
struct {
- int nfract; /* Percentage of buffer cache dirty to
- activate bdflush */
- int ndirty; /* Maximum number of dirty blocks to write out per
+ int nfract; /* Percentage of buffer cache dirty to
+activate bdflush */
+ int ndirty; /* Maximum number of dirty blocks to write out per
wake-cycle */
- int nrefill; /* Number of clean buffers to try to obtain
- each time we call refill */
int dummy1; /* unused */
+ int dummy2; /* unused */
int interval; /* jiffies delay between kupdate flushes */
int age_buffer; /* Time for normal buffer to age before we flush it */
int nfract_sync; /* Percentage of buffer cache dirty to
activate bdflush synchronously */
- int dummy2;/* unused */
- int dummy3;/* unused */
+ int dummy3; /* unused */
+ int dummy4; /* unused */
} b_un;
unsigned int data[N_PARAM];
} bdf_prm = {{30, 64, 64, 256, 5*HZ, 30*HZ, 60, 0, 0}};
--- linux-2.4.2/include/asm-i386/highmem.h Thu Feb 22 01:09:58 2001
+++ linux/include/asm-i386/highmem.hSun Mar 4 20:14:50 2001
@@ -9,7 +9,7 @@
*
*
* Redesigned the x86 32-bit VM architecture to deal with
- * up to 16 Terrabyte physical memory. With current x86 CPUs
+ * up to 16 Terabyte physical memory. With current x86 CPUs
* we now support up to 64 Gigabytes physical RAM.
*
* Copyright (C) 1999 Ingo Molnar <[EMAIL PROTECTED]>
--- linux-2.4.2/include/asm-i386/pgtable-3level.h Wed Oct 18 23:25:46 2000
+++ linux/include/asm-i386/pgtable-3level.h Sun Mar 4 19:25:00 2001
@@ -48,7 +48,7 @@
/* Rules for using set_pte: the pte being assigned *must* be
* either not present or in a state where the hardware will
* not attempt to update the pte. In places where this is
- * not possible, use pte_get_and_clear to obtain the old pte
+ * not possible, use ptep_get_and_clear to obtain the old pte
* value and then use set_pte to update it. -ben
*/
static inline void set_pte(pte_t *ptep, pte_t pte)
[PATCH] tiny MM performance and typo patches for 2.4.2
Hi folks,
this is a list of patches I collected while looking at the memory
management sources. Two patches might improve the performance of your
box. The others are more or less cosmetic.
This mail is sent with a kernel using these patches.
Here is a list sorted with decreasing importance:
patch-uk2 makes use of the pgd, pmd and pte quicklists for x86 too;
risky: there might be a reason that 2.4.x doesn't use the
quicklists.
patch-uk6 In 2.4.x _page_hashfn divides struct address_space pointer
with a parameter derived from the size of struct
inode. Deriving this parameter from the size of struct
address_space makes more sense -- at least for me.
patch-uk5 cleans the bd_flush_param union.
patch-uk1 fixes a comment typo in asm-i386/highmem.h.
patch-uk3 fixes a comment typo in asm-i386/pgtable-3level.h.
Ciao,
Uli Kunitz
--
Ulrich Kunitz ([EMAIL PROTECTED])
--- linux-2.4.2/include/asm-i386/pgalloc.h Thu Feb 22 01:09:57 2001
+++ linux/include/asm-i386/pgalloc.hSun Mar 4 20:14:50 2001
@@ -92,9 +92,9 @@
free_page((unsigned long)pte);
}
-#define pte_free_kernel(pte)free_pte_slow(pte)
-#define pte_free(pte) free_pte_slow(pte)
-#define pgd_free(pgd) free_pgd_slow(pgd)
+#define pte_free_kernel(pte)free_pte_fast(pte)
+#define pte_free(pte) free_pte_fast(pte)
+#define pgd_free(pgd) free_pgd_fast(pgd)
#define pgd_alloc() get_pgd_fast()
extern inline pte_t * pte_alloc_kernel(pmd_t * pmd, unsigned long address)
@@ -145,7 +145,7 @@
* inside the pgd, so has no extra memory associated with it.
* (In the PAE case we free the page.)
*/
-#define pmd_free(pmd) free_pmd_slow(pmd)
+#define pmd_free(pmd) free_pmd_fast(pmd)
#define pmd_free_kernelpmd_free
#define pmd_alloc_kernel pmd_alloc
--- linux-2.4.2/include/linux/pagemap.h Thu Feb 22 01:10:01 2001
+++ linux/include/linux/pagemap.h Sun Mar 4 20:14:50 2001
@@ -58,7 +58,8 @@
*/
extern inline unsigned long _page_hashfn(struct address_space * mapping, unsigned
long index)
{
-#define i (((unsigned long) mapping)/(sizeof(struct inode) ~ (sizeof(struct inode)
- 1)))
+#define i (((unsigned long) mapping) / \
+ (sizeof(struct address_space) ~ (sizeof(struct address_space) - 1)))
#define s(x) ((x)+((x)PAGE_HASH_BITS))
return s(i+index) (PAGE_HASH_SIZE-1);
#undef i
--- linux-2.4.2/fs/buffer.c Fri Feb 9 20:29:44 2001
+++ linux/fs/buffer.c Sun Mar 4 19:27:31 2001
@@ -112,19 +112,18 @@
*/
union bdflush_param {
struct {
- int nfract; /* Percentage of buffer cache dirty to
- activate bdflush */
- int ndirty; /* Maximum number of dirty blocks to write out per
+ int nfract; /* Percentage of buffer cache dirty to
+activate bdflush */
+ int ndirty; /* Maximum number of dirty blocks to write out per
wake-cycle */
- int nrefill; /* Number of clean buffers to try to obtain
- each time we call refill */
int dummy1; /* unused */
+ int dummy2; /* unused */
int interval; /* jiffies delay between kupdate flushes */
int age_buffer; /* Time for normal buffer to age before we flush it */
int nfract_sync; /* Percentage of buffer cache dirty to
activate bdflush synchronously */
- int dummy2;/* unused */
- int dummy3;/* unused */
+ int dummy3; /* unused */
+ int dummy4; /* unused */
} b_un;
unsigned int data[N_PARAM];
} bdf_prm = {{30, 64, 64, 256, 5*HZ, 30*HZ, 60, 0, 0}};
--- linux-2.4.2/include/asm-i386/highmem.h Thu Feb 22 01:09:58 2001
+++ linux/include/asm-i386/highmem.hSun Mar 4 20:14:50 2001
@@ -9,7 +9,7 @@
*
*
* Redesigned the x86 32-bit VM architecture to deal with
- * up to 16 Terrabyte physical memory. With current x86 CPUs
+ * up to 16 Terabyte physical memory. With current x86 CPUs
* we now support up to 64 Gigabytes physical RAM.
*
* Copyright (C) 1999 Ingo Molnar [EMAIL PROTECTED]
--- linux-2.4.2/include/asm-i386/pgtable-3level.h Wed Oct 18 23:25:46 2000
+++ linux/include/asm-i386/pgtable-3level.h Sun Mar 4 19:25:00 2001
@@ -48,7 +48,7 @@
/* Rules for using set_pte: the pte being assigned *must* be
* either not present or in a state where the hardware will
* not attempt to update the pte. In places where this is
- * not possible, use pte_get_and_clear to obtain the old pte
+ * not possible, use ptep_get_and_clear to obtain the old pte
* value and then use set_pte to update it. -ben
*/
static inline void set_pte(pte_t *ptep, pte_t pte)
2.4.0 i386: Why free_xxx_slow() instead free_xxx_fast()?
Hello,
in include/asm-i386/pgalloc.h the {pgd,pmd,pte}_free* functions are
defined as the functions free_{pgd,pmd,pte}_slow (see the patch below).
IMO this leaves the quick lists pretty useless for i386.
Have I overlooked something?
There is a linux-kernel mail from Martin Schwidefsky
([EMAIL PROTECTED]) about 2.4.0-test10 hinting on bad_pmd_table()
and bad_pgd_table() landing in the quick lists. Using the _slow
functions would fix any problem with the quick lists for now.
Changing the defines as in the patch seems to work here on a
two uniprocessor machines (Pentium III, Athlon). I've checked with
2.4.1-pre9 too. But what are the risks?
Ciao,
Uli Kunitz
--- linux-2.4.0/include/asm-i386/pgalloc.h Tue Jan 9 15:00:08 2001
+++ linux/include/asm-i386/pgalloc.hThu Jan 11 17:30:55 2001
@@ -92,9 +92,9 @@
free_page((unsigned long)pte);
}
-#define pte_free_kernel(pte)free_pte_slow(pte)
-#define pte_free(pte) free_pte_slow(pte)
-#define pgd_free(pgd) free_pgd_slow(pgd)
+#define pte_free_kernel(pte)free_pte_fast(pte)
+#define pte_free(pte) free_pte_fast(pte)
+#define pgd_free(pgd) free_pgd_fast(pgd)
#define pgd_alloc() get_pgd_fast()
extern inline pte_t * pte_alloc_kernel(pmd_t * pmd, unsigned long address)
@@ -145,7 +145,7 @@
* inside the pgd, so has no extra memory associated with it.
* (In the PAE case we free the page.)
*/
-#define pmd_free(pmd) free_pmd_slow(pmd)
+#define pmd_free(pmd) free_pmd_fast(pmd)
#define pmd_free_kernelpmd_free
#define pmd_alloc_kernel pmd_alloc
--
Ulrich Kunitz ([EMAIL PROTECTED])
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] two comment typos, kernel 2.4.0
These patches work for 2.4.0-pre9 too. --- linux-2.4.0/include/asm-i386/highmem.h Tue Jan 9 15:00:08 2001 +++ linux/include/asm-i386/highmem.hThu Jan 11 17:30:55 2001 @@ -9,7 +9,7 @@ * * * Redesigned the x86 32-bit VM architecture to deal with - * up to 16 Terrabyte physical memory. With current x86 CPUs + * up to 16 Terabyte physical memory. With current x86 CPUs * we now support up to 64 Gigabytes physical RAM. * * Copyright (C) 1999 Ingo Molnar <[EMAIL PROTECTED]> --- linux-2.4.0/include/asm-i386/pgtable-3level.h Wed Oct 18 23:25:46 2000 +++ linux/include/asm-i386/pgtable-3level.h Fri Jan 12 13:17:28 2001 @@ -48,7 +48,7 @@ /* Rules for using set_pte: the pte being assigned *must* be * either not present or in a state where the hardware will * not attempt to update the pte. In places where this is - * not possible, use pte_get_and_clear to obtain the old pte + * not possible, use ptep_get_and_clear to obtain the old pte * value and then use set_pte to update it. -ben */ static inline void set_pte(pte_t *ptep, pte_t pte) -- Ulrich Kunitz ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] two comment typos, kernel 2.4.0
These patches work for 2.4.0-pre9 too. --- linux-2.4.0/include/asm-i386/highmem.h Tue Jan 9 15:00:08 2001 +++ linux/include/asm-i386/highmem.hThu Jan 11 17:30:55 2001 @@ -9,7 +9,7 @@ * * * Redesigned the x86 32-bit VM architecture to deal with - * up to 16 Terrabyte physical memory. With current x86 CPUs + * up to 16 Terabyte physical memory. With current x86 CPUs * we now support up to 64 Gigabytes physical RAM. * * Copyright (C) 1999 Ingo Molnar [EMAIL PROTECTED] --- linux-2.4.0/include/asm-i386/pgtable-3level.h Wed Oct 18 23:25:46 2000 +++ linux/include/asm-i386/pgtable-3level.h Fri Jan 12 13:17:28 2001 @@ -48,7 +48,7 @@ /* Rules for using set_pte: the pte being assigned *must* be * either not present or in a state where the hardware will * not attempt to update the pte. In places where this is - * not possible, use pte_get_and_clear to obtain the old pte + * not possible, use ptep_get_and_clear to obtain the old pte * value and then use set_pte to update it. -ben */ static inline void set_pte(pte_t *ptep, pte_t pte) -- Ulrich Kunitz ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0 i386: Why free_xxx_slow() instead free_xxx_fast()?
Hello,
in include/asm-i386/pgalloc.h the {pgd,pmd,pte}_free* functions are
defined as the functions free_{pgd,pmd,pte}_slow (see the patch below).
IMO this leaves the quick lists pretty useless for i386.
Have I overlooked something?
There is a linux-kernel mail from Martin Schwidefsky
([EMAIL PROTECTED]) about 2.4.0-test10 hinting on bad_pmd_table()
and bad_pgd_table() landing in the quick lists. Using the _slow
functions would fix any problem with the quick lists for now.
Changing the defines as in the patch seems to work here on a
two uniprocessor machines (Pentium III, Athlon). I've checked with
2.4.1-pre9 too. But what are the risks?
Ciao,
Uli Kunitz
--- linux-2.4.0/include/asm-i386/pgalloc.h Tue Jan 9 15:00:08 2001
+++ linux/include/asm-i386/pgalloc.hThu Jan 11 17:30:55 2001
@@ -92,9 +92,9 @@
free_page((unsigned long)pte);
}
-#define pte_free_kernel(pte)free_pte_slow(pte)
-#define pte_free(pte) free_pte_slow(pte)
-#define pgd_free(pgd) free_pgd_slow(pgd)
+#define pte_free_kernel(pte)free_pte_fast(pte)
+#define pte_free(pte) free_pte_fast(pte)
+#define pgd_free(pgd) free_pgd_fast(pgd)
#define pgd_alloc() get_pgd_fast()
extern inline pte_t * pte_alloc_kernel(pmd_t * pmd, unsigned long address)
@@ -145,7 +145,7 @@
* inside the pgd, so has no extra memory associated with it.
* (In the PAE case we free the page.)
*/
-#define pmd_free(pmd) free_pmd_slow(pmd)
+#define pmd_free(pmd) free_pmd_fast(pmd)
#define pmd_free_kernelpmd_free
#define pmd_alloc_kernel pmd_alloc
--
Ulrich Kunitz ([EMAIL PROTECTED])
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
