ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/
- Various fixes against 2.6.23-rc7-mm1.
- I repulled the subsystem git trees, but not the subsystem quilt trees.
Large amounts of stuff broke as a result - not a bad effort for 24 hours :(
- git-sched.patch broke and was dropped
- The cpuidle code wasn't readded to the acpi tree today, so it still isn't in
2.6.23-rc8-mm1.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1
git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail [email protected]
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.
- When reporting bugs in this kernel via email, please also rewrite the
email Subject: in some manner to reflect the nature of the bug. Some
developers filter by Subject: when looking for messages to read.
- Occasional snapshots of the -mm lineup are uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
the mm-commits list.
Changes since 2.6.23-rc7-mm1:
git-acpi.patch
git-alsa.patch
git-arm.patch
git-audit-master.patch
git-avr32.patch
git-cifs.patch
git-cpufreq.patch
git-powerpc.patch
git-powerpc-galak.patch
git-drm.patch
git-dvb.patch
git-hwmon.patch
git-gfs2-nmw.patch
git-hid.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-jfs.patch
git-jg-misc.patch
git-kbuild.patch
git-kvm.patch
git-leds.patch
git-libata-all.patch
git-md-accel.patch
git-mips.patch
git-mmc.patch
git-mtd.patch
git-ubi.patch
git-net.patch
git-backlight.patch
git-nfs.patch
git-nfsd.patch
git-ocfs2.patch
git-r8169.patch
git-selinux.patch
git-s390.patch
git-sh.patch
git-scsi-misc.patch
git-block.patch
git-unionfs.patch
git-watchdog.patch
git-wireless.patch
git-ipwireless_cs.patch
git-newsetup.patch
git-xfs.patch
git-cryptodev.patch
git-kgdb.patch
git trees
-alsa-procfs-fix.patch
-ehca_irq-misc-cpuinit-section-annotations-and-ifdef-cleanups.patch
-git-backlight-build-fix.patch
Merged into mainline or a subsystem tree
-fix-potential-oops-in-generic_setlease-v2.patch
Folded into fix-potential-oops-in-generic_setlease.patch
+fix-potential-oops-in-generic_setlease-fix.patch
Fix fix-potential-oops-in-generic_setlease.patch
+fix-modules-oopsing-in-lguest-guests.patch
lguest fix
+git-cifs-build-fix.patch
Fix git-cifs.patch
+git-hwmon-fixup.patch
Fix rejects in git-hwmon.patch
+git-jg-warning-fixes.patch
Fix git-jg-misc.patch
-git-mips-fixup.patch
Unneeded
-mips-add-gpio-support-to-the-bcm947xx-platform-update.patch
Folded into mips-add-gpio-support-to-the-bcm947xx-platform.patch
-mips-gpio-led-driver-for-the-wgt634u-machine.patch
-mips-move-platform-independent-cfe-code-into-arch-mips-cfe.patch
-mips-add-cfe-support-to-bcm947xx-code.patch
Merged, or broken by git-mips changes.
+git-net-sctp-build-fix.patch
+mv643xx_eth-remove-redundant-multiple-initialization.patch
+iseries_veth-kill-unused-variable.patch
+git-net-fix-pasemi_mac.patch
Keep fixing git-net.patch
+net-bluetooth-hidp-corec-make-hidp_setup_input.patch
bluetooth fix
+git-nfsd-fix-generic_setlease-mismerge.patch
+git-nfsd-fix-memory-shortage-can-result-in-inconsistent-flocks-state.patch
Fix stuff in git-nfsd.patch
+ipsc-update-version-information.patch
scsi driver fix
+git-block-dasd_eckd-fix.patch
+git-block-ps3disk-fix.patch
Fix git-block
+usb-skeleton-leaking-locks-on-open.patch
USB fix
-iwl3945-is-bust.patch
-git-wireless-b44-is-bust.patch
Unneeded - wireless got better.
+x86-64-calgary-fix-calgary=disable=busnum-for-calioc2.patch
+x86-64-calgary-get-rid-of-translate_phb.patch
Calgary updates
+mm-use-pagevec-to-rotate-reclaimable-page-fix-2.patch
Fix mm-use-pagevec-to-rotate-reclaimable-page.patch some more
+memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code-fix-2-3.patch
Fix memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code.patch
some more
+maps-pssproportional-set-size-accounting-in-smaps.patch
/proc/pid/smaps feature
+oom-move-prototypes-to-appropriate-header-file-fix.patch
Fix oom-move-prototypes-to-appropriate-header-file.patch
+track-accurate-idle-time-with-tick_schedidle_sleeptime-fix.patch
Fix track-accurate-idle-time-with-tick_schedidle_sleeptime.patch
-aio-dont-confuse-debug-define-location.patch
Generated warnings - dropped
+ecryptfs-update-metadata-read-write-functions-cleanup.patch
Fix ecryptfs-update-metadata-read-write-functions.patch
+ecryptfs-fix-data-types.patch
Fix ecryptfs patches in -mm
+intel-fb-whitespace-bracket-and-other-clean-ups.patch
+intel-fb-obvious-changes-and-corrections.patch
+intel-fb-force-even-line-count-in-interlaced-mode.patch
+intel-fb-more-interlaced-mode-support.patch
fbdev updates
+r-o-bind-mounts-elevate-write-count-for-do_utimes-touch-command-causes-oops.patch
Fix r-o-bind-mounts-elevate-write-count-for-do_utimes.patch
-r-o-bind-mounts-track-number-of-mount-writers-hack-hack-hack.patch
+r-o-bind-mounts-track-number-of-mount-writers-make-lockdep-happy-with-r-o-bind-mounts.patch
Fix this properly
+ext2-reservations-fix-for-r-o-bind-mounts-take-writer-count-v2.patch
Fix ext3-reservations.patch for the r-o bind mounts code
+use-extended-crashkernel-command-line-on-i386-fix-config_nohighmem-for-extended-crashkernel-command-line.patch
+use-extended-crashkernel-command-line-on-i386-fix-config_nohighmem-for-extended-crashkernel-command-line-fix.patch
Fix use-extended-crashkernel-command-line-on-i386.patch
+use-extended-crashkernel-command-line-on-ia64-fix.patch
Fix use-extended-crashkernel-command-line-on-ia64.patch
+add-documentation-for-extended-crashkernel-syntax-add-extended-crashkernel-syntax-to-kernel-parameterstxt.patch
Update add-documentation-for-extended-crashkernel-syntax.patch
5381 commits in 2052 patch files
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/patch-list
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/
Hi Andrew,
The build error reported at http://lkml.org/lkml/2007/9/20/210 for the
drivers/ata/pata_scc.c is seen in both 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1.
The patch proposed for this build error at http://lkml.org/lkml/2007/9/21/557
is not seen in the latest 2.6.23-rc8-mm1 patch's.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
This patch kills a may-be-used-uninitialized warning.
Signed-off-by: WANG Cong <[email protected]>
---
fs/udf/balloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-rc8-mm1/fs/udf/balloc.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/fs/udf/balloc.c
+++ linux-2.6.23-rc8-mm1/fs/udf/balloc.c
@@ -689,7 +689,7 @@ static int udf_table_new_block(struct su
uint32_t spread = 0xFFFFFFFF, nspread = 0xFFFFFFFF;
uint32_t newblock = 0, adsize;
uint32_t elen, goal_elen = 0;
- kernel_lb_addr eloc, goal_eloc;
+ kernel_lb_addr eloc, uninitialized_var(goal_eloc);
struct extent_position epos, goal_epos;
int8_t etype;
Hi Andrew,
The drivers/net/ibm_newemac/mal seems to be broken, which stop with
build error
CC drivers/net/ibm_newemac/mal.o
drivers/net/ibm_newemac/mal.c: In function ?mal_schedule_poll?:
drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ?netif_rx_schedule_prep?
drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ?netif_rx_schedule_prep?
drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ?netif_rx_schedule_prep?
drivers/net/ibm_newemac/mal.c:241: error: too few arguments to function ?__netif_rx_schedule?
drivers/net/ibm_newemac/mal.c: In function ?mal_poll_disable?:
drivers/net/ibm_newemac/mal.c:321: error: ?__LINK_STATE_RX_SCHED? undeclared (first use in this function)
drivers/net/ibm_newemac/mal.c:321: error: (Each undeclared identifier is reported only once
drivers/net/ibm_newemac/mal.c:321: error: for each function it appears in.)
drivers/net/ibm_newemac/mal.c: In function ?mal_poll?:
drivers/net/ibm_newemac/mal.c:337: error: ?struct net_device? has no member named ?quota?
drivers/net/ibm_newemac/mal.c:337: warning: type defaults to ?int? in declaration of ?_x?
drivers/net/ibm_newemac/mal.c:337: error: ?struct net_device? has no member named ?quota?
drivers/net/ibm_newemac/mal.c:375: error: too few arguments to function ?__netif_rx_complete?
drivers/net/ibm_newemac/mal.c:390: warning: passing argument 2 of ?netif_rx_reschedule? makes pointer from integer without a cast
drivers/net/ibm_newemac/mal.c:404: error: ?struct net_device? has no member named ?quota?
drivers/net/ibm_newemac/mal.c: In function ?mal_probe?:
drivers/net/ibm_newemac/mal.c:542: error: ?struct net_device? has no member named ?weight?
drivers/net/ibm_newemac/mal.c:543: error: ?struct net_device? has no member named ?poll?
drivers/net/ibm_newemac/mal.c: In function ?mal_remove?:
drivers/net/ibm_newemac/mal.c:660: error: implicit declaration of function ?netif_poll_disable?
make[3]: *** [drivers/net/ibm_newemac/mal.o] Error 1
make[2]: *** [drivers/net/ibm_newemac] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
Kill two unused variables in drivers/usb/misc/sisusbvga/sisusb.c.
Signed-off-by: WANG Cong <[email protected]>
---
drivers/usb/misc/sisusbvga/sisusb.c | 2 --
1 file changed, 2 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/usb/misc/sisusbvga/sisusb.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/usb/misc/sisusbvga/sisusb.c
+++ linux-2.6.23-rc8-mm1/drivers/usb/misc/sisusbvga/sisusb.c
@@ -3316,8 +3316,6 @@ static struct usb_driver sisusb_driver =
static int __init usb_sisusb_init(void)
{
- int retval;
- struct sisusb_usb_data *sisusb;
#ifdef INCL_SISUSB_CON
sisusb_init_concode();
2.6.23-rc6-mm1, 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1 all fail to link
correctly on a powerpc machine (elm3b19) in our test grid. It fails as
below:
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
Compiler versions and linker versions as below:
root@elm3b19:~/apw/linux-2.6.22# gcc -v
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared
--with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-softfloat
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--disable-werror --enable-checking=release powerpc-linux-gnu
Thread model: posix
gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
root@elm3b19:~/apw/linux-2.6.22# ld -v
GNU ld version 2.16.1 Debian GNU/Linux
As suggested elsewhere I have had a go at tracking this down. Previous
problems of this kind were introduced as a result of using 'weak'
declarations to provide default implementations. This investigation led
me to the following commit:
commit c60473b5d32ea6cf4561232bc852bacd3a513528
Author: Jiri Kosina <[email protected]>
Date: Sat Sep 15 01:49:49 2007 +0000
i386-and-x86_64-randomize-brk
Backing this change out seems to get us past this problem. If we are to
support compilers of this age, and I believe we currently do, then we
probabally need to avoid the weak declarations and use the Kconfig
system to provide the alternatives here.
Jiri?
-apw
Dereferencing unintialized "usb3" pointer in ufs_fill_super() is not
going to work. gcc even warns about this.
BUG: unable to handle kernel NULL pointer dereference at virtual address 0000014e
printing eip: f9a3b1a2 *pde = 00000000
Oops: 0000 [#1] PREEMPT
last sysfs file: /block/loop7/removable
Modules linked in: ufs loop usbhid ehci_hcd snd_intel8x0 snd_ac97_codec uhci_hcd rtc ac97_bus usbcore thermal button processor sr_mod evdev cdrom
Pid: 1066, comm: mount Not tainted (2.6.23-rc8-mm1 #1)
EIP: 0060:[<f9a3b1a2>] EFLAGS: 00010286 CPU: 0
EIP is at ufs_fill_super+0x52f/0x12e5 [ufs]
EAX: 00000002 EBX: c39c4960 ECX: c0176465 EDX: 00000000
ESI: c38c5000 EDI: c387f800 EBP: 00000600 ESP: c3816d3c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process mount (pid: 1066, ti=c3816000 task=c38f34d0 task.ti=c3816000)
last branch before last exception/interrupt
from c0130fc0 (lockdep_on+0xb/0xc)
to c0118d82 (vprintk+0x29f/0x2fb)
Stack: 00000010 00000000 00000600 00000000 c3816db4 0038c0d8 00000000 c3816dd4
ffffffff 00000002 00000200 00000600 00002130 00002000 c39c4960 c01b1355
c3816d94 c3816d94 c0187966 c3816db4 00000020 c0347b9b c280680c 00000400
Call Trace:
[<c01b1355>] snprintf+0x1f/0x22
[<c0187966>] disk_name+0x79/0x83
[<c015c49b>] get_sb_bdev+0xdc/0x11a
[<c016ca6d>] alloc_vfsmnt+0x8d/0xb3
[<f9a39e3c>] ufs_get_sb+0x20/0x25 [ufs]
[<f9a3ac73>] ufs_fill_super+0x0/0x12e5 [ufs]
[<c015c09c>] vfs_kern_mount+0x40/0x79
[<c016d601>] do_mount+0x6c0/0x7e3
[<c02c82a3>] _spin_unlock+0x25/0x3b
[<c01318dc>] mark_held_locks+0x39/0x53
[<c013fd1d>] find_lock_page+0xf/0x84
[<c014456f>] get_page_from_freelist+0x21e/0x3f0
[<c0131ab0>] trace_hardirqs_on+0x118/0x13b
[<c0144599>] get_page_from_freelist+0x248/0x3f0
[<c01582f1>] kmem_cache_alloc+0x68/0x9b
[<c016be18>] copy_mount_options+0x26/0x109
[<c016d79b>] sys_mount+0x77/0xb3
[<c0103db2>] sysenter_past_esp+0x5f/0x99
=======================
INFO: lockdep is turned off.
Code: d2 f7 74 24 28 03 87 50 01 00 00 89 04 24 c7 44 24 04 00 00 00 00 89 f2 89 f8 e8 e6 2b 00 00 85 c0 0f 84 1e 0d 00 00 8b 44 24 24 <8b> 90 4c 01 00 00 8b 86 58 02 00 00 83 78 08 00 74 02 0f ca 89
EIP: [<f9a3b1a2>] ufs_fill_super+0x52f/0x12e5 [ufs] SS:ESP 0068:c3816d3c
Signed-off-by: Alexey Dobriyan <[email protected]>
---
fs/ufs/super.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/fs/ufs/super.c
+++ b/fs/ufs/super.c
@@ -837,6 +837,10 @@ again:
if (!ubh)
goto failed;
+ usb1 = ubh_get_usb_first(uspi);
+ usb2 = ubh_get_usb_second(uspi);
+ usb3 = ubh_get_usb_third(uspi);
+
/* Sort out mod used on SunOS 4.1.3 for fs_state */
uspi->s_postblformat = fs32_to_cpu(sb, usb3->fs_postblformat);
if (((flags & UFS_ST_MASK) == UFS_ST_SUNOS) &&
@@ -845,11 +849,6 @@ again:
flags |= UFS_ST_SUN;
}
-
- usb1 = ubh_get_usb_first(uspi);
- usb2 = ubh_get_usb_second(uspi);
- usb3 = ubh_get_usb_third(uspi);
-
/*
* Check ufs magic number
*/
On Tue, 25 Sep 2007, Andy Whitcroft wrote:
> As suggested elsewhere I have had a go at tracking this down. Previous
> problems of this kind were introduced as a result of using 'weak'
> declarations to provide default implementations. This investigation led
> me to the following commit:
> commit c60473b5d32ea6cf4561232bc852bacd3a513528
> Author: Jiri Kosina <[email protected]>
> Date: Sat Sep 15 01:49:49 2007 +0000
> i386-and-x86_64-randomize-brk
> Backing this change out seems to get us past this problem. If we are to
> support compilers of this age, and I believe we currently do, then we
> probabally need to avoid the weak declarations and use the Kconfig
> system to provide the alternatives here.
> Jiri?
Hi,
actually, my first patch wasn't using weak symbols, but I have been
convinced that it's the way to go(tm). Please see
http://lkml.org/lkml/2007/9/1/131 and the ongoing thread.
I am fine with replacing the brk randomization patch with the one that
wasn't using weak symbols (posted in the mentioned thread too), I have no
strong opinion either way.
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 25 Sep 2007 16:09:31 +0530 Kamalesh Babulal <[email protected]> wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/
>
> Hi Andrew,
>
> The build error reported at http://lkml.org/lkml/2007/9/20/210 for the
> drivers/ata/pata_scc.c is seen in both 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1.
The followup to that report wasn't clear to me and I was hoping that Alan
could help find the final fix.
> The patch proposed for this build error at http://lkml.org/lkml/2007/9/21/557
> is not seen in the latest 2.6.23-rc8-mm1 patch's.
Alan didn't comment on that one. afacit it is needed in Jeff's
git-libata-all tree. I'll merge it and see what happens.
On Tue, 25 Sep 2007 18:23:58 +0530 Kamalesh Babulal <[email protected]> wrote:
> Hi Andrew,
>
> The drivers/net/ibm_newemac/mal seems to be broken, which stop with
> build error
(please cc [email protected] on networking things)
> CC drivers/net/ibm_newemac/mal.o
> drivers/net/ibm_newemac/mal.c: In function ‘mal_schedule_poll’:
> drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ‘netif_rx_schedule_prep’
> drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ‘netif_rx_schedule_prep’
> drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ‘netif_rx_schedule_prep’
> drivers/net/ibm_newemac/mal.c:241: error: too few arguments to function ‘__netif_rx_schedule’
> drivers/net/ibm_newemac/mal.c: In function ‘mal_poll_disable’:
> drivers/net/ibm_newemac/mal.c:321: error: ‘__LINK_STATE_RX_SCHED’ undeclared (first use in this function)
> drivers/net/ibm_newemac/mal.c:321: error: (Each undeclared identifier is reported only once
> drivers/net/ibm_newemac/mal.c:321: error: for each function it appears in.)
> drivers/net/ibm_newemac/mal.c: In function ‘mal_poll’:
> drivers/net/ibm_newemac/mal.c:337: error: ‘struct net_device’ has no member named ‘quota’
> drivers/net/ibm_newemac/mal.c:337: warning: type defaults to ‘int’ in declaration of ‘_x’
> drivers/net/ibm_newemac/mal.c:337: error: ‘struct net_device’ has no member named ‘quota’
> drivers/net/ibm_newemac/mal.c:375: error: too few arguments to function ‘__netif_rx_complete’
> drivers/net/ibm_newemac/mal.c:390: warning: passing argument 2 of ‘netif_rx_reschedule’ makes pointer from integer without a cast
> drivers/net/ibm_newemac/mal.c:404: error: ‘struct net_device’ has no member named ‘quota’
> drivers/net/ibm_newemac/mal.c: In function ‘mal_probe’:
> drivers/net/ibm_newemac/mal.c:542: error: ‘struct net_device’ has no member named ‘weight’
> drivers/net/ibm_newemac/mal.c:543: error: ‘struct net_device’ has no member named ‘poll’
> drivers/net/ibm_newemac/mal.c: In function ‘mal_remove’:
> drivers/net/ibm_newemac/mal.c:660: error: implicit declaration of function ‘netif_poll_disable’
> make[3]: *** [drivers/net/ibm_newemac/mal.o] Error 1
> make[2]: *** [drivers/net/ibm_newemac] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
Yes, there's been a lot of breakage in netdev land:
git-net-fix-macec.patch
git-net-sky2-fixups.patch
git-net-fix-wireless-kconfig.patch
git-net-fix-spidernet-build.patch
git-net-sctp-build-fix.patch
spider_net_ethtool-keep-up-with-recent-netdev-stats-changes.patch
pasemi_mac-build-fix-after-recent-netdev-stats.patch
git-net-fix-pasemi_mac.patch
make-mv643xx_ethc-build-again.patch
but we're getting there. It looks like ibmn_newemac is more busted than
most...
On Tue, 25 Sep 2007 01:46:25 -0700 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/
>
> - Various fixes against 2.6.23-rc7-mm1.
>
>
> git-unionfs.patch
in unionfs debug.c:
#if BITS_PER_LONG == 32
#define POISONED_PTR ((void*) 0x5a5a5a5a)
#elif BITS_PER_LONG == 64
#define POISONED_PTR ((void*) 0x5a5a5a5a5a5a5a5a)
#else
#error Unknown BITS_PER_LONG value
#endif /* BITS_PER_LONG != known */
We try to keep all poison values in include/linux/poison.h so that
when digging around for them, it's easier to locate the one in
question.
Also, on x86_64, the 64-bit version wants a L or UL suffix:
fs/unionfs/debug.c:96:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it is long
fs/unionfs/debug.c:264:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it is long
---
~Randy
Phaedrus says that Quality is about caring.
On Tue, Sep 25, 2007 at 10:26:37AM -0700, Randy Dunlap wrote:
> On Tue, 25 Sep 2007 01:46:25 -0700 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/
> >
> > - Various fixes against 2.6.23-rc7-mm1.
> >
> >
> > git-unionfs.patch
>
> in unionfs debug.c:
>
> #if BITS_PER_LONG == 32
> #define POISONED_PTR ((void*) 0x5a5a5a5a)
> #elif BITS_PER_LONG == 64
> #define POISONED_PTR ((void*) 0x5a5a5a5a5a5a5a5a)
> #else
> #error Unknown BITS_PER_LONG value
> #endif /* BITS_PER_LONG != known */
>
>
> We try to keep all poison values in include/linux/poison.h so that
> when digging around for them, it's easier to locate the one in
> question.
Right. I didn't want to introduce this kind of ifdef, the 0x5a pattern is
also the same as POISON_INUSE. I guess, using the 32-bit poison value should
be good enough anyway.
> Also, on x86_64, the 64-bit version wants a L or UL suffix:
>
> fs/unionfs/debug.c:96:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it is long
> fs/unionfs/debug.c:264:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it is long
Strange...I didn't get the warning when I compile tested; but it's valid.
Josef 'Jeff' Sipek.
--
Research, n.:
Consider Columbus:
He didn't know where he was going.
When he got there he didn't know where he was.
When he got back he didn't know where he had been.
And he did it all on someone else's money.
This also fixes a compile warning on 64-bit systems.
Cc: [email protected]
Signed-off-by: Josef 'Jeff' Sipek <[email protected]>
---
fs/unionfs/debug.c | 12 ++----------
fs/unionfs/union.h | 1 +
include/linux/poison.h | 3 +++
3 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/fs/unionfs/debug.c b/fs/unionfs/debug.c
index f678534..aa6a76a 100644
--- a/fs/unionfs/debug.c
+++ b/fs/unionfs/debug.c
@@ -25,14 +25,6 @@
} \
} while (0)
-#if BITS_PER_LONG == 32
-#define POISONED_PTR ((void*) 0x5a5a5a5a)
-#elif BITS_PER_LONG == 64
-#define POISONED_PTR ((void*) 0x5a5a5a5a5a5a5a5a)
-#else
-#error Unknown BITS_PER_LONG value
-#endif /* BITS_PER_LONG != known */
-
/*
* __unionfs_check_{inode,dentry,file} perform exhaustive sanity checking on
* the fan-out of various Unionfs objects. We check that no lower objects
@@ -93,7 +85,7 @@ void __unionfs_check_inode(const struct inode *inode,
printk(" Ci5: inode/linode=%p:%p bindex=%d "
"istart/end=%d:%d\n", inode,
lower_inode, bindex, istart, iend);
- } else if (lower_inode == POISONED_PTR) {
+ } else if (lower_inode == UNIONFS_POISONED_PTR) {
/* freed inode! */
PRINT_CALLER(fname, fxn, line);
printk(" Ci6: inode/linode=%p:%p bindex=%d "
@@ -261,7 +253,7 @@ void __unionfs_check_dentry(const struct dentry *dentry,
printk(" CI5: dentry/linode=%p:%p bindex=%d "
"istart/end=%d:%d\n", dentry,
lower_inode, bindex, istart, iend);
- } else if (lower_inode == POISONED_PTR) {
+ } else if (lower_inode == UNIONFS_POISONED_PTR) {
/* freed inode! */
PRINT_CALLER(fname, fxn, line);
printk(" CI6: dentry/linode=%p:%p bindex=%d "
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index 9ec5f82..3b6881a 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -43,6 +43,7 @@
#include <linux/fs_stack.h>
#include <linux/magic.h>
#include <linux/log2.h>
+#include <linux/poison.h>
#include <asm/mman.h>
#include <asm/system.h>
diff --git a/include/linux/poison.h b/include/linux/poison.h
index d93c300..c81118b 100644
--- a/include/linux/poison.h
+++ b/include/linux/poison.h
@@ -38,6 +38,9 @@
/********** fs/jbd/journal.c **********/
#define JBD_POISON_FREE 0x5b
+/********** fs/unionfs/debug.c **********/
+#define UNIONFS_POISONED_PTR ((void *) 0x75757575)
+
/********** drivers/base/dmapool.c **********/
#define POOL_POISON_FREED 0xa7 /* !inuse */
#define POOL_POISON_ALLOCATED 0xa9 /* !initted */
--
1.5.2.2.238.g7cbf2f2
Hi Andrew,
The 2.6.23-rc8-mm1 kernel linking fails on the powerpc (P5+) box
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `memory_block_action':
/root/scrap/linux-2.6.23-rc8/drivers/base/memory.c:188: undefined reference to `.remove_memory'
make: *** [.tmp_vmlinux1] Error 1
# gcc -v
Using built-in specs.
Target: powerpc64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --program-suffix=-4.1
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=default32 --enable-secureplt --with-long-double-128 --host=powerpc64-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
# ld -v
GNU ld version 2.17.50.0.5 20060927 (SUSE Linux)
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
Hello,
Similar (the same?) as in 2.6.23-rc6-mm1?
http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg208812.html
CC [M] drivers/kvm/ioapic.o
drivers/kvm/ioapic.c: In function 'ioapic_deliver':
drivers/kvm/ioapic.c:208: error: 'dest_LowestPrio' undeclared (first use in this function)
drivers/kvm/ioapic.c:208: error: (Each undeclared identifier is reported only once
drivers/kvm/ioapic.c:208: error: for each function it appears in.)
drivers/kvm/ioapic.c:219: error: 'dest_Fixed' undeclared (first use in this function)
make[2]: *** [drivers/kvm/ioapic.o] Error 1
make[1]: *** [drivers/kvm] Error 2
make: *** [drivers] Error 2
Regards,
Mariusz
On Wed, 2007-09-26 at 01:30 +0530, Kamalesh Babulal wrote:
> Hi Andrew,
>
> The 2.6.23-rc8-mm1 kernel linking fails on the powerpc (P5+) box
>
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `memory_block_action':
> /root/scrap/linux-2.6.23-rc8/drivers/base/memory.c:188: undefined reference to `.remove_memory'
> make: *** [.tmp_vmlinux1] Error 1
>
I ran into the same thing earlier. Here is the fix I made.
Thanks,
Badari
Memory hotplug remove is currently supported only on IA64
Signed-off-by: Badari Pulavarty <[email protected]>
Index: linux-2.6.23-rc8/mm/Kconfig
===================================================================
--- linux-2.6.23-rc8.orig/mm/Kconfig 2007-09-25 14:44:03.000000000 -0700
+++ linux-2.6.23-rc8/mm/Kconfig 2007-09-25 14:44:48.000000000 -0700
@@ -143,6 +143,7 @@ config MEMORY_HOTREMOVE
bool "Allow for memory hot remove"
depends on MEMORY_HOTPLUG
depends on MIGRATION
+ depends on (IA64)
# Heavily threaded applications may benefit from splitting the mm-wide
# page_table_lock, so that faults on different parts of the user address
Hi Andy,
One the patch you created in -mm is causing compile warning.
Here is the fix. Please verify.
Thanks,
Badari
arch/powerpc/mm/init_64.c: In function `vmemmap_populated':
arch/powerpc/mm/init_64.c:211: warning: passing arg 1 of `vmemmap_section_start' makes pointer from integer without a cast
vmemmap_section_start() gets called with an argument which is unsigned long.
Signed-off-by: Badari Pulavarty <[email protected]>
Index: linux-2.6.23-rc8/arch/powerpc/mm/init_64.c
===================================================================
--- linux-2.6.23-rc8.orig/arch/powerpc/mm/init_64.c 2007-09-25 09:18:13.000000000 -0700
+++ linux-2.6.23-rc8/arch/powerpc/mm/init_64.c 2007-09-25 14:50:44.000000000 -0700
@@ -189,10 +189,9 @@ void pgtable_cache_init(void)
* do this by hand as the proffered address may not be correctly aligned.
* Subtraction of non-aligned pointers produces undefined results.
*/
-unsigned long __meminit vmemmap_section_start(struct page *page)
+unsigned long __meminit vmemmap_section_start(unsigned long page)
{
- unsigned long offset = ((unsigned long)page) -
- ((unsigned long)(vmemmap));
+ unsigned long offset = page - ((unsigned long)(vmemmap));
/* Return the pfn of the start of the section. */
return (offset / sizeof(struct page)) & PAGE_SECTION_MASK;
Hi
I've applied the 2.6.23-rc8-mm1 patch, and I've got a new directory
"mips" at root of my linux source. This directory only contain :
"bcm947xx/wgt634u.c"
I think that this directory "bcm947xx" should be added in "arch/mips"
subdirectory.
regards,
trem
On Tue, Sep 25, 2007 at 01:45:19PM -0400, Josef 'Jeff' Sipek wrote:
> This also fixes a compile warning on 64-bit systems.
Ok, I had a brain-fart...ignore this patch.
Jeff.
--
We have joy, we have fun, we have Linux on a Sun...
On Wed, 26 Sep 2007 01:30:02 +0530
Kamalesh Babulal <[email protected]> wrote:
> Hi Andrew,
>
> The 2.6.23-rc8-mm1 kernel linking fails on the powerpc (P5+) box
>
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `memory_block_action':
> /root/scrap/linux-2.6.23-rc8/drivers/base/memory.c:188: undefined reference to `.remove_memory'
> make: *** [.tmp_vmlinux1] Error 1
>
Maybe my patch is the problem. could you give me your .config ?
Thanks,
-Kame
On Wed, 26 Sep 2007 10:32:05 +0900
KAMEZAWA Hiroyuki <[email protected]> wrote:
> Maybe my patch is the problem. could you give me your .config ?
>
Ah, memory hot remove is selectable even if the arch doesn't support it....sorry.
ok, this is fix.
Thanks,
-Kame
==
MEMORY_HOTREMOVE config option is selectable even it arch doesn't support it.
This fix it.
Signed-off-by: KAMEZAWA Hiroyuki <[email protected]>
Index: linux-2.6.23-rc8-mm1/arch/ia64/Kconfig
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/ia64/Kconfig
+++ linux-2.6.23-rc8-mm1/arch/ia64/Kconfig
@@ -305,6 +305,9 @@ config HOTPLUG_CPU
config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
+config ARCH_ENABLE_MEMORY_HOTREMOVE
+ def_bool y
+
config SCHED_SMT
bool "SMT scheduler support"
depends on SMP
Index: linux-2.6.23-rc8-mm1/mm/Kconfig
===================================================================
--- linux-2.6.23-rc8-mm1.orig/mm/Kconfig
+++ linux-2.6.23-rc8-mm1/mm/Kconfig
@@ -141,7 +141,7 @@ config MEMORY_HOTPLUG_SPARSE
config MEMORY_HOTREMOVE
bool "Allow for memory hot remove"
- depends on MEMORY_HOTPLUG
+ depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
depends on MIGRATION
# Heavily threaded applications may benefit from splitting the mm-wide
On 09/25/2007 10:46 AM, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/
I don't know if this is a regression, I hadn't suspend working before rc7-mm1
(rc7-mm1 is the same), but
X -> kill X -> console (OK)
X -> suspend (2ram) -> resume -> kill X -> black screen (no signal), reboot
stucks at some point after some services are shutted down
X driver: intel (compiled from git)
agp dmesg part:
Linux agpgart interface v0.102
agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org
on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c)
Is this what should I try?
agpgart: Detected an Intel G33 Chipset.
agpgart: Detected 8192K stolen memory.
agpgart: AGP aperture is 256M @ 0xd0000000
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
[drm] Initialized i915 1.6.0 20060119 on minor 0
thanks,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University
Badari Pulavarty wrote:
> On Wed, 2007-09-26 at 01:30 +0530, Kamalesh Babulal wrote:
>> Hi Andrew,
>>
>> The 2.6.23-rc8-mm1 kernel linking fails on the powerpc (P5+) box
>>
>> CC init/version.o
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>> drivers/built-in.o: In function `memory_block_action':
>> /root/scrap/linux-2.6.23-rc8/drivers/base/memory.c:188: undefined reference to `.remove_memory'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>
> I ran into the same thing earlier. Here is the fix I made.
>
> Thanks,
> Badari
>
> Memory hotplug remove is currently supported only on IA64
>
> Signed-off-by: Badari Pulavarty <[email protected]>
>
> Index: linux-2.6.23-rc8/mm/Kconfig
> ===================================================================
> --- linux-2.6.23-rc8.orig/mm/Kconfig 2007-09-25 14:44:03.000000000 -0700
> +++ linux-2.6.23-rc8/mm/Kconfig 2007-09-25 14:44:48.000000000 -0700
> @@ -143,6 +143,7 @@ config MEMORY_HOTREMOVE
> bool "Allow for memory hot remove"
> depends on MEMORY_HOTPLUG
> depends on MIGRATION
> + depends on (IA64)
>
> # Heavily threaded applications may benefit from splitting the mm-wide
> # page_table_lock, so that faults on different parts of the user address
>
>
> -
> 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/
Hi Badari,
Thanks, your patch fixed the problem.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
KAMEZAWA Hiroyuki wrote:
> On Wed, 26 Sep 2007 10:32:05 +0900
> KAMEZAWA Hiroyuki <[email protected]> wrote:
>> Maybe my patch is the problem. could you give me your .config ?
>>
> Ah, memory hot remove is selectable even if the arch doesn't support it....sorry.
>
> ok, this is fix.
>
> Thanks,
> -Kame
> ==
> MEMORY_HOTREMOVE config option is selectable even it arch doesn't support it.
> This fix it.
>
> Signed-off-by: KAMEZAWA Hiroyuki <[email protected]>
>
>
> Index: linux-2.6.23-rc8-mm1/arch/ia64/Kconfig
> ===================================================================
> --- linux-2.6.23-rc8-mm1.orig/arch/ia64/Kconfig
> +++ linux-2.6.23-rc8-mm1/arch/ia64/Kconfig
> @@ -305,6 +305,9 @@ config HOTPLUG_CPU
> config ARCH_ENABLE_MEMORY_HOTPLUG
> def_bool y
>
> +config ARCH_ENABLE_MEMORY_HOTREMOVE
> + def_bool y
> +
> config SCHED_SMT
> bool "SMT scheduler support"
> depends on SMP
> Index: linux-2.6.23-rc8-mm1/mm/Kconfig
> ===================================================================
> --- linux-2.6.23-rc8-mm1.orig/mm/Kconfig
> +++ linux-2.6.23-rc8-mm1/mm/Kconfig
> @@ -141,7 +141,7 @@ config MEMORY_HOTPLUG_SPARSE
>
> config MEMORY_HOTREMOVE
> bool "Allow for memory hot remove"
> - depends on MEMORY_HOTPLUG
> + depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
> depends on MIGRATION
>
> # Heavily threaded applications may benefit from splitting the mm-wide
>
> -
Hi Kame,
Thanks, your patch fixes the problem.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
Mariusz Kozlowski wrote:
> Hello,
>
> Similar (the same?) as in 2.6.23-rc6-mm1?
>
> http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg208812.html
>
> CC [M] drivers/kvm/ioapic.o
> drivers/kvm/ioapic.c: In function 'ioapic_deliver':
> drivers/kvm/ioapic.c:208: error: 'dest_LowestPrio' undeclared (first use in this function)
> drivers/kvm/ioapic.c:208: error: (Each undeclared identifier is reported only once
> drivers/kvm/ioapic.c:208: error: for each function it appears in.)
> drivers/kvm/ioapic.c:219: error: 'dest_Fixed' undeclared (first use in this function)
> make[2]: *** [drivers/kvm/ioapic.o] Error 1
> make[1]: *** [drivers/kvm] Error 2
> make: *** [drivers] Error 2
>
>
We now include asm/io_apic.h like we should. Has that file changed in -mm?
--
error compiling committee.c: too many arguments to function
On Wed, 26 Sep 2007 11:00:09 +0200 Avi Kivity <[email protected]> wrote:
> Mariusz Kozlowski wrote:
> > Hello,
> >
> > Similar (the same?) as in 2.6.23-rc6-mm1?
> >
> > http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg208812.html
> >
> > CC [M] drivers/kvm/ioapic.o
> > drivers/kvm/ioapic.c: In function 'ioapic_deliver':
> > drivers/kvm/ioapic.c:208: error: 'dest_LowestPrio' undeclared (first use in this function)
> > drivers/kvm/ioapic.c:208: error: (Each undeclared identifier is reported only once
> > drivers/kvm/ioapic.c:208: error: for each function it appears in.)
> > drivers/kvm/ioapic.c:219: error: 'dest_Fixed' undeclared (first use in this function)
> > make[2]: *** [drivers/kvm/ioapic.o] Error 1
> > make[1]: *** [drivers/kvm] Error 2
> > make: *** [drivers] Error 2
> >
> >
>
> We now include asm/io_apic.h like we should. Has that file changed in -mm?
>
CONFIG_X86_IO_APIC isn't set.
Andrew Morton wrote:
> On Wed, 26 Sep 2007 11:00:09 +0200 Avi Kivity <[email protected]> wrote:
>
>
>> Mariusz Kozlowski wrote:
>>
>>> Hello,
>>>
>>> Similar (the same?) as in 2.6.23-rc6-mm1?
>>>
>>> http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg208812.html
>>>
>>> CC [M] drivers/kvm/ioapic.o
>>> drivers/kvm/ioapic.c: In function 'ioapic_deliver':
>>> drivers/kvm/ioapic.c:208: error: 'dest_LowestPrio' undeclared (first use in this function)
>>> drivers/kvm/ioapic.c:208: error: (Each undeclared identifier is reported only once
>>> drivers/kvm/ioapic.c:208: error: for each function it appears in.)
>>> drivers/kvm/ioapic.c:219: error: 'dest_Fixed' undeclared (first use in this function)
>>> make[2]: *** [drivers/kvm/ioapic.o] Error 1
>>> make[1]: *** [drivers/kvm] Error 2
>>> make: *** [drivers] Error 2
>>>
>>>
>>>
>> We now include asm/io_apic.h like we should. Has that file changed in -mm?
>>
>>
>
> CONFIG_X86_IO_APIC isn't set.
>
Why should that matter? we're just pulling that file for the definitions.
I'll try to compile without it here and see how it breaks.
--
error compiling committee.c: too many arguments to function
On Tue, Sep 25, 2007 at 03:05:53PM -0700, Badari Pulavarty wrote:
> Hi Andy,
>
> One the patch you created in -mm is causing compile warning.
> Here is the fix. Please verify.
>
> Thanks,
> Badari
>
> arch/powerpc/mm/init_64.c: In function `vmemmap_populated':
> arch/powerpc/mm/init_64.c:211: warning: passing arg 1 of `vmemmap_section_start' makes pointer from integer without a cast
>
> vmemmap_section_start() gets called with an argument which is unsigned long.
>
> Signed-off-by: Badari Pulavarty <[email protected]>
Clearly correct.
Acked-by: Andy Whitcroft <[email protected]>
> Index: linux-2.6.23-rc8/arch/powerpc/mm/init_64.c
> ===================================================================
> --- linux-2.6.23-rc8.orig/arch/powerpc/mm/init_64.c 2007-09-25 09:18:13.000000000 -0700
> +++ linux-2.6.23-rc8/arch/powerpc/mm/init_64.c 2007-09-25 14:50:44.000000000 -0700
> @@ -189,10 +189,9 @@ void pgtable_cache_init(void)
> * do this by hand as the proffered address may not be correctly aligned.
> * Subtraction of non-aligned pointers produces undefined results.
> */
> -unsigned long __meminit vmemmap_section_start(struct page *page)
> +unsigned long __meminit vmemmap_section_start(unsigned long page)
> {
> - unsigned long offset = ((unsigned long)page) -
> - ((unsigned long)(vmemmap));
> + unsigned long offset = page - ((unsigned long)(vmemmap));
>
> /* Return the pfn of the start of the section. */
> return (offset / sizeof(struct page)) & PAGE_SECTION_MASK;
-apw
> actually, my first patch wasn't using weak symbols, but I have been
> convinced that it's the way to go(tm). Please see
> http://lkml.org/lkml/2007/9/1/131 and the ongoing thread.
>
> I am fine with replacing the brk randomization patch with the one that
> wasn't using weak symbols (posted in the mentioned thread too), I have no
> strong opinion either way.
Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems
we have three options from here:
1) update the compiler support list to exclude these compilers, or
2) back this change out, or
3) switch to the version not using __weak.
The latter seems to be the least intrusive change. As no-one closer
to the problem is stepping up to make the decision I will propose
we go with the third option here.
-apw
On Thu, 27 Sep 2007, Andy Whitcroft wrote:
> Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we
> have three options from here:
> 1) update the compiler support list to exclude these compilers, or
> 2) back this change out, or
> 3) switch to the version not using __weak.
> The latter seems to be the least intrusive change. As no-one closer to
> the problem is stepping up to make the decision I will propose we go
> with the third option here.
Andrew,
if you agree with Andy that we should support compilers that don't work
with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace
it with the one below instead (this has been already posted at
http://lkml.org/lkml/2007/8/31/113). Thanks.
From: Jiri Kosina <[email protected]>
i386 and x86_64: randomize brk()
This patch randomizes the location of the heap (brk) for i386 and x86_64.
The range is randomized in the range starting at current brk location up
to 0x02000000 offset for both architectures. This, together with
pie-executable-randomization.patch and
pie-executable-randomization-fix.patch, should make the address space
randomization on i386 and x86_64 complete.
The empty stubs are not added for architectures that don't support ELF
binaries, namely blackfin, h8300, m68knommu and v850.
Arjan says:
This is known to break older versions of some emacs variants, whose dumper
code assumed that the last variable declared in the program is equal to
the start of the dynamically allocated memory region.
(The dumper is the code where emacs effectively dumps core at the end of
it's compilation stage; this coredump is then loaded as the main program
during normal use)
iirc this was 5 years or so; we found this way back when I was at RH and
we first did the security stuff there (including this brk randomization).
It wasn't all variants of emacs, and it got fixed as a result (I vaguely
remember that emacs already had code to deal with it for other archs/oses,
just ifdeffed wrongly).
It's a rare and wrong assumption as a general thing, just on x86 it mostly
happened to be true (but to be honest, it'll break too if gcc does
something fancy or if the linker does a non-standard order). Still its
something we should at least document.
Note 2: afaik it only broke the emacs *build*. I'm not 100% sure about
that (it IS 5 years ago) though.
Signed-off-by: Jiri Kosina <[email protected]>
diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
index 8466471..ba8ad15 100644
--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -949,3 +949,17 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
}
+
+void arch_randomize_brk(void)
+{
+ unsigned long new_brk;
+ unsigned long range_start;
+ unsigned long range_end;
+
+ range_start = current->mm->brk;
+ range_end = range_start + 0x02000000;
+ new_brk = randomize_range(range_start, range_end, 0);
+ if (new_brk)
+ current->mm->brk = current->mm->start_brk = new_brk;
+}
+
diff --git a/arch/x86_64/ia32/ia32_binfmt.c b/arch/x86_64/ia32/ia32_binfmt.c
index dffd2ac..ccc4350 100644
--- a/arch/x86_64/ia32/ia32_binfmt.c
+++ b/arch/x86_64/ia32/ia32_binfmt.c
@@ -262,6 +262,7 @@ static void elf32_init(struct pt_regs *);
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
#define arch_setup_additional_pages syscall32_setup_pages
extern int syscall32_setup_pages(struct linux_binprm *, int exstack);
+extern void arch_randomize_brk(void);
#include "../../../fs/binfmt_elf.c"
diff --git a/arch/x86_64/kernel/process.c b/arch/x86_64/kernel/process.c
index 2842f50..fe7203b 100644
--- a/arch/x86_64/kernel/process.c
+++ b/arch/x86_64/kernel/process.c
@@ -902,3 +902,17 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
}
+
+void arch_randomize_brk(void)
+{
+ unsigned long new_brk;
+ unsigned long range_start;
+ unsigned long range_end;
+
+ range_start = current->mm->brk;
+ range_end = range_start + 0x02000000;
+ new_brk = randomize_range(range_start, range_end, 0);
+ if (new_brk)
+ current->mm->brk = current->mm->start_brk = new_brk;
+}
+
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d65f1d9..4c92461 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1073,6 +1073,9 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs)
current->mm->end_data = end_data;
current->mm->start_stack = bprm->p;
+ if (current->flags & PF_RANDOMIZE)
+ arch_randomize_brk();
+
if (current->personality & MMAP_PAGE_ZERO) {
/* Why this, you ask??? Well SVr4 maps page 0 as read-only,
and some applications "depend" upon this behavior.
diff --git a/include/asm-alpha/elf.h b/include/asm-alpha/elf.h
index 6c2d78f..18210cc 100644
--- a/include/asm-alpha/elf.h
+++ b/include/asm-alpha/elf.h
@@ -163,5 +163,9 @@ extern int alpha_l3_cacheshape;
NEW_AUX_ENT(AT_L3_CACHESHAPE, alpha_l3_cacheshape); \
} while (0)
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* __KERNEL__ */
#endif /* __ASM_ALPHA_ELF_H */
diff --git a/include/asm-arm/elf.h b/include/asm-arm/elf.h
index ec1c685..eeeee3f 100644
--- a/include/asm-arm/elf.h
+++ b/include/asm-arm/elf.h
@@ -116,4 +116,8 @@ extern char elf_platform[];
#endif
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif
diff --git a/include/asm-avr32/elf.h b/include/asm-avr32/elf.h
index d334b49..61b7d81 100644
--- a/include/asm-avr32/elf.h
+++ b/include/asm-avr32/elf.h
@@ -107,4 +107,8 @@ typedef struct user_fpu_struct elf_fpregset_t;
#define SET_PERSONALITY(ex, ibcs2) set_personality(PER_LINUX_32BIT)
#endif
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* __ASM_AVR32_ELF_H */
diff --git a/include/asm-cris/elf.h b/include/asm-cris/elf.h
index 96a40c1..10607c7 100644
--- a/include/asm-cris/elf.h
+++ b/include/asm-cris/elf.h
@@ -93,4 +93,8 @@ typedef unsigned long elf_fpregset_t;
#endif /* __KERNEL__ */
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif
diff --git a/include/asm-frv/elf.h b/include/asm-frv/elf.h
index 7df58a3..07df9dd 100644
--- a/include/asm-frv/elf.h
+++ b/include/asm-frv/elf.h
@@ -141,4 +141,8 @@ do { \
#define SET_PERSONALITY(ex, ibcs2) set_personality((ibcs2)?PER_SVR4:PER_LINUX)
#endif
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif
diff --git a/include/asm-i386/elf.h b/include/asm-i386/elf.h
index b32df3a..5935d4c 100644
--- a/include/asm-i386/elf.h
+++ b/include/asm-i386/elf.h
@@ -160,4 +160,6 @@ do if (vdso_enabled) { \
#endif
+extern void arch_randomize_brk(void);
+
#endif
diff --git a/include/asm-ia64/elf.h b/include/asm-ia64/elf.h
index 25f9835..3b84b0d 100644
--- a/include/asm-ia64/elf.h
+++ b/include/asm-ia64/elf.h
@@ -249,4 +249,8 @@ do { \
#endif /* __KERNEL__ */
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* _ASM_IA64_ELF_H */
diff --git a/include/asm-m32r/elf.h b/include/asm-m32r/elf.h
index bbee8b2..33a5244 100644
--- a/include/asm-m32r/elf.h
+++ b/include/asm-m32r/elf.h
@@ -133,4 +133,8 @@ typedef elf_fpreg_t elf_fpregset_t;
#define SET_PERSONALITY(ex, ibcs2) set_personality(PER_LINUX)
#endif
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* _ASM_M32R__ELF_H */
diff --git a/include/asm-m68k/elf.h b/include/asm-m68k/elf.h
index eb63b85..f6ff4fe 100644
--- a/include/asm-m68k/elf.h
+++ b/include/asm-m68k/elf.h
@@ -118,4 +118,8 @@ typedef struct user_m68kfp_struct elf_fpregset_t;
#define SET_PERSONALITY(ex, ibcs2) set_personality((ibcs2)?PER_SVR4:PER_LINUX)
#endif
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif
diff --git a/include/asm-mips/elf.h b/include/asm-mips/elf.h
index e7d95d4..571cd80 100644
--- a/include/asm-mips/elf.h
+++ b/include/asm-mips/elf.h
@@ -372,4 +372,8 @@ extern int dump_task_fpu(struct task_struct *, elf_fpregset_t *);
#define ELF_ET_DYN_BASE (TASK_SIZE / 3 * 2)
#endif
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* _ASM_ELF_H */
diff --git a/include/asm-parisc/elf.h b/include/asm-parisc/elf.h
index f628ac7..9807cae 100644
--- a/include/asm-parisc/elf.h
+++ b/include/asm-parisc/elf.h
@@ -344,4 +344,8 @@ struct pt_regs; /* forward declaration... */
#define ELF_HWCAP 0
/* (boot_cpu_data.x86_capability) */
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif
diff --git a/include/asm-powerpc/elf.h b/include/asm-powerpc/elf.h
index de50799..af45d0e 100644
--- a/include/asm-powerpc/elf.h
+++ b/include/asm-powerpc/elf.h
@@ -422,4 +422,8 @@ extern void arch_write_notes(struct file *file);
#define ARCH_HAVE_EXTRA_ELF_NOTES
#endif /* CONFIG_PPC_CELL */
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* _ASM_POWERPC_ELF_H */
diff --git a/include/asm-s390/elf.h b/include/asm-s390/elf.h
index 91d0632..0a32ac3 100644
--- a/include/asm-s390/elf.h
+++ b/include/asm-s390/elf.h
@@ -216,4 +216,8 @@ do { \
#endif /* __s390x__ */
#endif
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif
diff --git a/include/asm-sh/elf.h b/include/asm-sh/elf.h
index 43ca244..f055a68 100644
--- a/include/asm-sh/elf.h
+++ b/include/asm-sh/elf.h
@@ -140,4 +140,8 @@ do { \
} while (0)
#endif /* CONFIG_VSYSCALL */
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* __ASM_SH_ELF_H */
diff --git a/include/asm-sh64/elf.h b/include/asm-sh64/elf.h
index f994286..5d6dd4b 100644
--- a/include/asm-sh64/elf.h
+++ b/include/asm-sh64/elf.h
@@ -104,4 +104,8 @@ typedef struct user_fpu_struct elf_fpregset_t;
#define SET_PERSONALITY(ex, ibcs2) set_personality(PER_LINUX_32BIT)
#endif
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* __ASM_SH64_ELF_H */
diff --git a/include/asm-sparc/elf.h b/include/asm-sparc/elf.h
index aaf6ef4..94b273d 100644
--- a/include/asm-sparc/elf.h
+++ b/include/asm-sparc/elf.h
@@ -168,4 +168,8 @@ do { unsigned long *dest = &(__elf_regs[0]); \
#endif /* __KERNEL__ */
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* !(__ASMSPARC_ELF_H) */
diff --git a/include/asm-sparc64/elf.h b/include/asm-sparc64/elf.h
index 303d85e..8afe25f 100644
--- a/include/asm-sparc64/elf.h
+++ b/include/asm-sparc64/elf.h
@@ -190,4 +190,8 @@ do { unsigned long new_flags = current_thread_info()->flags; \
} while (0)
#endif
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* !(__ASM_SPARC64_ELF_H) */
diff --git a/include/asm-um/elf-x86_64.h b/include/asm-um/elf-x86_64.h
index 8a8246d..e1d664e 100644
--- a/include/asm-um/elf-x86_64.h
+++ b/include/asm-um/elf-x86_64.h
@@ -81,6 +81,10 @@ extern long elf_aux_hwcap;
#define SET_PERSONALITY(ex, ibcs2) do ; while(0)
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif
/*
diff --git a/include/asm-x86_64/elf.h b/include/asm-x86_64/elf.h
index b4fbe47..5a1adf9 100644
--- a/include/asm-x86_64/elf.h
+++ b/include/asm-x86_64/elf.h
@@ -177,4 +177,6 @@ do if (vdso_enabled) { \
#endif
+extern void arch_randomize_brk(void);
+
#endif
diff --git a/include/asm-xtensa/elf.h b/include/asm-xtensa/elf.h
index 1569b53..10e60bf 100644
--- a/include/asm-xtensa/elf.h
+++ b/include/asm-xtensa/elf.h
@@ -222,5 +222,9 @@ extern void do_save_fpregs (elf_fpregset_t*, struct pt_regs*,
extern int do_restore_fpregs (elf_fpregset_t*, struct pt_regs*,
struct task_struct*);
+static inline void arch_randomize_brk(void)
+{
+}
+
#endif /* __KERNEL__ */
#endif /* _XTENSA_ELF_H */
On Thu, 27 Sep 2007 14:13:21 +0200 (CEST) Jiri Kosina <[email protected]> wrote:
> On Thu, 27 Sep 2007, Andy Whitcroft wrote:
>
> > Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we
> > have three options from here:
> > 1) update the compiler support list to exclude these compilers, or
> > 2) back this change out, or
> > 3) switch to the version not using __weak.
> > The latter seems to be the least intrusive change. As no-one closer to
> > the problem is stepping up to make the decision I will propose we go
> > with the third option here.
>
> Andrew,
>
> if you agree with Andy that we should support compilers that don't work
> with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace
> it with the one below instead (this has been already posted at
> http://lkml.org/lkml/2007/8/31/113). Thanks.
>
We have quite a few instances of __weak in there. What is special about
this one?
>
> From: Jiri Kosina <[email protected]>
>
> i386 and x86_64: randomize brk()
That's a better patch anyway. We often use __weak because people
can't be bothered doing all that editing.
On Thu, Sep 27, 2007 at 10:13:42AM -0700, Andrew Morton wrote:
> On Thu, 27 Sep 2007 14:13:21 +0200 (CEST) Jiri Kosina <[email protected]> wrote:
>
> > On Thu, 27 Sep 2007, Andy Whitcroft wrote:
> >
> > > Ok, this problem seems to still persist in 2.6.23-rc8-mm2. It seems we
> > > have three options from here:
> > > 1) update the compiler support list to exclude these compilers, or
> > > 2) back this change out, or
> > > 3) switch to the version not using __weak.
> > > The latter seems to be the least intrusive change. As no-one closer to
> > > the problem is stepping up to make the decision I will propose we go
> > > with the third option here.
> >
> > Andrew,
> >
> > if you agree with Andy that we should support compilers that don't work
> > with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace
> > it with the one below instead (this has been already posted at
> > http://lkml.org/lkml/2007/8/31/113). Thanks.
> >
>
> We have quite a few instances of __weak in there. What is special about
> this one?
The bug we trigger is an ld bug - not a compiler bug.
What happens is that we have the same function defined weak twice.
In fs/ we include binfmt_elf.o in the build because
CONFIG_BINFMT_ELF is set.
And in arch/powerpc/kernel/binfmt_elf32.c:
we do an: #include "../../../fs/binfmt_elf.c"
Without actually trying it out I assume we trigger the ld bug
because we define the same weak function twice.
And this is a non-typical situation.
Sam
On Thu, 27 Sep 2007 14:13:21 +0200 (CEST)
Jiri Kosina <[email protected]> wrote:
> i386 and x86_64: randomize brk()
>
> ...
>
> --- a/arch/x86_64/ia32/ia32_binfmt.c
> +++ b/arch/x86_64/ia32/ia32_binfmt.c
> @@ -262,6 +262,7 @@ static void elf32_init(struct pt_regs *);
> #define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
> #define arch_setup_additional_pages syscall32_setup_pages
> extern int syscall32_setup_pages(struct linux_binprm *, int exstack);
> +extern void arch_randomize_brk(void);
>
> #include "../../../fs/binfmt_elf.c"
Is this sinful extern-decl-in-C acually needed?
> index b4fbe47..5a1adf9 100644
> --- a/include/asm-x86_64/elf.h
> +++ b/include/asm-x86_64/elf.h
> @@ -177,4 +177,6 @@ do if (vdso_enabled) { \
>
> #endif
>
> +extern void arch_randomize_brk(void);
> +
> #endif
Because we already have a declaration in the correct place?
On Thu, 27 Sep 2007, Andrew Morton wrote:
> > +extern void arch_randomize_brk(void);
> > #include "../../../fs/binfmt_elf.c"
> Is this sinful extern-decl-in-C acually needed?
Some time passed since I have written the patch, but I remember that this
was needed, otherwise under some circumstances the build failed, but I
don't remember details ... I will try to look at it more in a while.
But it definitely was needed to work with that horrible
include-huge-c-file-from-another-one.
Thanks,
--
Jiri Kosina
SUSE Labs