2.4.23pre6aa1

2.4.23pre6aa1

[Andrea Arcangeli]

URL:

	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23pre6aa1.gz
	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23pre6aa1/

Probably the most notable new feature is that you can now pass 'desktop'
as parameter to the kernel in lilo to ask the kernel to behave optimally
for a desktop machine. No need of compile time options anymore. For more
experienced users HZ=500/HZ=50/HZ=200 should work fine too, then you can
tune the timeslices by hand but you must know what you're doing.

You can verify everything went well after boot with:

	cat /proc/sys/kernel/{*timeslice,HZ}

This kernel seems to boot fine again on x86-64 too. The merges in pre6
were helpful.

Due the amount of changes you may not want to run this on any production
box (note: not because of the dynamic-hz feature, but because of
everything else, the dynamic-hz is the only one that has no way to break
anything, modulo stuff that would break anyways on ia64 and alpha
already and that you can workaround trivially with HZ=100 if needed).

Only in 2.4.22aa1: 00_config-smp-1
Only in 2.4.22aa1: 00_copy-namespace-1
Only in 2.4.22aa1: 00_panic-console-switch-1
Only in 2.4.22aa1: 00_pgt-cache-leak-2
Only in 2.4.22aa1: 00_read_full_page-get_block-err-2
Only in 2.4.22aa1: 00_sk98lin_2.4.22-20030902-1.gz
Only in 2.4.22aa1: 05_vm_03_vm_tunables-4
Only in 2.4.22aa1: 05_vm_05_zone_accounting-2
Only in 2.4.22aa1: 05_vm_06_swap_out-3
Only in 2.4.22aa1: 05_vm_07_local_pages-4
Only in 2.4.22aa1: 05_vm_09_misc_junk-3
Only in 2.4.22aa1: 05_vm_16_active_free_zone_bhs-1
Only in 2.4.22aa1: 05_vm_20_cleanups-3
Only in 2.4.22aa1: 9999900_request-firmware-1

	Merged in mainline.

Only in 2.4.22aa1: 00_cpu-affinity-syscall-rml-4
Only in 2.4.23pre6aa1: 00_cpu-affinity-syscall-rml-5
Only in 2.4.22aa1: 00_extraversion-29
Only in 2.4.23pre6aa1: 00_extraversion-30
Only in 2.4.22aa1: 00_global-irq-race-1
Only in 2.4.23pre6aa1: 00_global-irq-race-2
Only in 2.4.22aa1: 00_rwsem-fair-38
Only in 2.4.22aa1: 00_rwsem-fair-38-recursive-8
Only in 2.4.23pre6aa1: 00_rwsem-fair-39
Only in 2.4.23pre6aa1: 00_rwsem-fair-39-recursive-8
Only in 2.4.22aa1: 00_silent-stack-overflow-18
Only in 2.4.23pre6aa1: 00_silent-stack-overflow-19
Only in 2.4.22aa1: 00_x86-optimize-apic-irq-and-cacheline-2
Only in 2.4.23pre6aa1: 00_x86-optimize-apic-irq-and-cacheline-3
Only in 2.4.22aa1: 05_vm_22_vm-anon-lru-1
Only in 2.4.23pre6aa1: 05_vm_22_vm-anon-lru-2
Only in 2.4.22aa1: 05_vm_17_rest-10
Only in 2.4.23pre6aa1: 05_vm_26-rest-1
Only in 2.4.22aa1: 05_vm_23_per-cpu-pages-3
Only in 2.4.23pre6aa1: 05_vm_23_per-cpu-pages-4
Only in 2.4.22aa1: 05_vm_24_accessed-ipi-only-smp-1
Only in 2.4.22aa1: 10_lvm-snapshot-check-3
Only in 2.4.23pre6aa1: 10_lvm-snapshot-check-4
Only in 2.4.23pre6aa1: 20_rcu-poll-10
Only in 2.4.22aa1: 20_rcu-poll-9
Only in 2.4.22aa1: 30_irq-balance-15
Only in 2.4.23pre6aa1: 30_irq-balance-16
Only in 2.4.22aa1: 60_net-exports-3
Only in 2.4.23pre6aa1: 60_net-exports-4
Only in 2.4.22aa1: 60_tux-syscall-5
Only in 2.4.23pre6aa1: 60_tux-syscall-6
Only in 2.4.22aa1: 60_tux-sysctl-3
Only in 2.4.23pre6aa1: 60_tux-sysctl-4
Only in 2.4.22aa1: 90_proc-mapped-base-5
Only in 2.4.23pre6aa1: 90_proc-mapped-base-6
Only in 2.4.22aa1: 93_NUMAQ-13
Only in 2.4.23pre6aa1: 93_NUMAQ-14
Only in 2.4.22aa1: 96_inode_read_write-atomic-8
Only in 2.4.23pre6aa1: 96_inode_read_write-atomic-9
Only in 2.4.22aa1: 9900_aio-23.gz
Only in 2.4.23pre6aa1: 9900_aio-24.gz
Only in 2.4.22aa1: 9903_aio-22-ppc-1
Only in 2.4.23pre6aa1: 9903_aio-22-ppc-2
Only in 2.4.22aa1: 9910_shm-largepage-16.gz
Only in 2.4.23pre6aa1: 9910_shm-largepage-17.gz
Only in 2.4.22aa1: 9920_kgdb-11.gz
Only in 2.4.23pre6aa1: 9920_kgdb-12.gz
Only in 2.4.22aa1: 9925_kmsgdump-0.4.4-3.gz
Only in 2.4.23pre6aa1: 9925_kmsgdump-0.4.4-4.gz
Only in 2.4.22aa1: 9950_futex-5.gz
Only in 2.4.23pre6aa1: 9950_futex-6.gz
Only in 2.4.22aa1: 9999_sched_yield_scale-6
Only in 2.4.23pre6aa1: 9999_sched_yield_scale-8
Only in 2.4.22aa1: 9999901_scsi-softirq-2
Only in 2.4.23pre6aa1: 9999901_scsi-softirq-3
Only in 2.4.22aa1: 9999900_ecc-20030225-1.gz
Only in 2.4.23pre6aa1: 9999900_ecc-20030225-2.gz
Only in 2.4.22aa1: 9999900_ikd-2.gz
Only in 2.4.23pre6aa1: 9999900_ikd-4.gz
Only in 2.4.22aa1: 9999900_ipc-rcu-1
Only in 2.4.23pre6aa1: 9999900_ipc-rcu-2
Only in 2.4.22aa1: 9999900_monitor-mwait-1
Only in 2.4.23pre6aa1: 9999900_monitor-mwait-2

	Rediffed.

Only in 2.4.23pre6aa1: 00_do_brk-1

	glitch fixup from Andrew.

Only in 2.4.23pre6aa1: 00_e-nodev-1

	s/NODEV/ENODEV/ fixes from Vojtech.

Only in 2.4.23pre6aa1: 00_get_request_wait-race-1

	Add missing smb_mb().

Only in 2.4.22aa1: 00_log-buf-len-1
Only in 2.4.23pre6aa1: 00_log-buf-len-dynamic-1

	Ported to 2.4.23pre6 to allow the configuration of the
	buffer size at compile time too.

Only in 2.4.23pre6aa1: 00_proc-readlink-1

	Remeber to free tmp buffer (from spender)

Only in 2.4.22aa1: 00_sched-O1-aa-2.4.19rc3-17.gz
Only in 2.4.23pre6aa1: 00_sched-O1-aa-2.4.19rc3-18.gz

	Let the idle load_balance pass to pick any task it find,
	if we go idle it means we've no task left. This fix speeds up number
	crunching up to 100% in some arch. The very same fix incidentally is
	also present in current 2.6.

Only in 2.4.23pre6aa1: 00_sk98lin-char-fix-1

	Count the right number of bytes (not ints).

Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1

	Don't take the bkl (the same paths runs w/o the bkl elsewhere), from
	Chris Mason.

Only in 2.4.23pre6aa1: 01_softirq-nowait-1

	We must really keep executing softirqs or it may take
	a too long time before ksoftirqd gets some cpu time.
	For an embedded device you may want to remove this,
	on a server we need this still.

Only in 2.4.23pre6aa1: 05_vm_27-pte-dirty-bit-in-hardware-1

	This fixes a longstanding bug for a number of archs that haven't the
	dirty bit updated in hardware. For those archs we can't mark the pte
	writeable when it's still in swap cache, unless we don't mark it dirty
	too at the same time. Otherwise the cpu will go ahead writing to the
	page, no fault will happen and the swapcache will be still clean, and
	the data will be lost at the next zeroIO swapout leading to userspace
	data corruption and segfaults during swap. Affected archs are
	alpha/s390/s390x for example.

	This bug was specific to the -aa VM, it couldn't happen
	in mainline. In my tree I optimized the code to exploited
	properties of archs that updates the bit in hardware for the
	first time. Hence the first need of a #define to differentiate the
	two code paths. The logic in the software-dirty-bit case will
	be less efficient of course (that's why there's a difference
	in the first place).

	This is an obvious noop for x86 and x86-64 for example.

	NOTE: the software-dirty-bit code is safe for all archs, the other way
	around not.

Only in 2.4.23pre6aa1: 30_18-busy-inodes-1

	Try to avoid to leave busy inodes in autofs unmount. From Olaf Kirch.
	(original from Trond).

Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1

	Ignore errors on exiting lock cleanups. From Trond.

Only in 2.4.22aa1: 70_xfs-1.3-2.gz
Only in 2.4.23pre6aa1: 70_xfs-1.3-3.gz
Only in 2.4.22aa1: 70_xfs-sysctl-3
Only in 2.4.23pre6aa1: 70_xfs13pre-final-1.gz
Only in 2.4.23pre6aa1: 71_qsort-1
Only in 2.4.22aa1: 71_xfs-VM_IO-1
Only in 2.4.22aa1: 71_xfs-aa-4
Only in 2.4.23pre6aa1: 71_xfs-aa-5
Only in 2.4.23pre6aa1: 71_xfs-mmap-1
Only in 2.4.22aa1: 71_xfs-tuning-1

	XFS 13pre-final merged.

Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1

	To really be able to help and not just waste some
	seek and cpu, wait_on_buffer should honour the
	BH_Sync, but this is late in 2.4, and so I prefer
	to get rid of it instead of giving it the full power
	it should have.

Only in 2.4.23pre6aa1: 9999900_soft-float-1

	Trap any usage of the FPU in kernel (needed
	to trap things like schedule_timeout(HZ*0.1)).

Only in 2.4.22aa1: 9999901_aio-network-poll-pipe-1
Only in 2.4.23pre6aa1: 9999901_aio-poll-2

	Leave only the aio-poll functionality because
	the network aio is still unfinished and nobody
	needs the pipe one (AFIK).

Only in 2.4.23pre6aa1: 9999_00_x86_64-suse-1
Only in 2.4.23pre6aa1: 9999_00_x86_64-sys-1
Only in 2.4.23pre6aa1: 9999_00_x86_64-tsc-c0-bandaid-1
Only in 2.4.23pre6aa1: 9999_00_x86_64-warning-1
Only in 2.4.23pre6aa1: 9999_00_x86_64-zone-startpfn-1
Only in 2.4.23pre6aa1: 9999_01_x86_64-aio-bigpages-1
Only in 2.4.23pre6aa1: 9999_01_x86_64-aio-export-1
Only in 2.4.23pre6aa1: 9999_01_x86_64-bitops-1
Only in 2.4.23pre6aa1: 9999_01_x86_64-discontig-pmd-1
Only in 2.4.23pre6aa1: 9999_01_x86_64-epoll-1
Only in 2.4.23pre6aa1: 9999_01_x86_64-fault32-wrap-1
Only in 2.4.23pre6aa1: 9999_01_x86_64-kgdb-1
Only in 2.4.23pre6aa1: 9999_01_x86_64-lvm32-no-checks-1

	Merge x86-64 updates from Andi Kleen.

Only in 2.4.23pre6aa1: 9999_athlon-errata-prefetch-1

	Fix athlon prefetch invalid faults from userspace.
	From Andi Kleen.

Only in 2.4.23pre6aa1: 9999_z-execve-race-1

	Fix race in exit_mmap.

Only in 2.4.23pre6aa1: 9999_z-laptopmode-1

	Allow the first read hitting the disk to flush all the dirty buffers.
	From Jens Axboe.

Only in 2.4.22aa1: 9999900_desktop-4
Only in 2.4.23pre6aa1: 9999_zz-dynamic-timeslice-1
Only in 2.4.23pre6aa1: 9999_zzz-dynamic-hz-1

	HZ is now dynamic, you can boot with HZ=50 HZ=100 HZ=500
	or HZ=1000. However only HZ=100 and HZ=1000 are supported.
	Anything different from HZ=100 can trigger device driver
	bugs (those would already trigger on ia64 and alpha but
	on x86 the amount of drivers in use is larger).

	But wait, you shouldn't use HZ=, you should only pass 'desktop' if you
	want to use the machine to behave as a better desktop and the kernel
	will just do the right thing.

	max-timeslice/min-timeslice tunables are also provided
	as sysctl. Again no need to tune those, just pass
	'desktop' if your machine is a desktop.

	The scheduler has internal heuristics (the avg_sleep for
	example in the o1 scheduler) to try to identify the interactive
	tasks. Since those are heuristics there's also the chance
	of failing. By rescheduling taks at around 100hz even if
	the heuristic fails there's quite a good margin before your
	eye can see it. This should help with video players and games.

Only in 2.4.23pre6aa1: 9999_zzzz-stackoverflow-1

	Prevent overflows from happening on top of softirq. From
	Hugh Dickins.

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/

Re: 2.4.23pre6aa1

[Mathias Kretschmer]

I'm getting the below errors compiling the bttv module.

Also, the commercial OSS sound driver fails to compile against it.
It compiled under -pre6.

Otherwise, it seems to work fine for me.

Let me know, if you need any further info.

Cheers,

Mathias


make[4]: Entering directory `/usr/src/linux-2.4/drivers/media/video'
gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall -Wstrict-prototypes 
-Wno-trigraphs           -O4 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer -pipe -msoft-float -mprefer 
red-stack-boundary=2 -march=pentium3   -nostdinc -iwithprefix include 
-DKBUILD_BASENAM          E=bttv_cards  -c -o bttv-cards.o bttv-cards.c
bttv-cards.c: In function `pvr_boot':
bttv-cards.c:2552: structure has no member named `dev'
bttv-cards.c:2555: warning: implicit declaration of function 
`request_firmware'
bttv-cards.c:2559: `rc' undeclared (first use in this function)
bttv-cards.c:2559: (Each undeclared identifier is reported only once
bttv-cards.c:2559: for each function it appears in.)
bttv-cards.c:2561: dereferencing pointer to incomplete type
bttv-cards.c:2561: dereferencing pointer to incomplete type
bttv-cards.c:2562: warning: implicit declaration of function 
`release_firmware'

Andrea Arcangeli wrote:
> URL:
> 
> 	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23pre6aa1.gz
> 	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.23pre6aa1/
> 
> Probably the most notable new feature is that you can now pass 'desktop'
> as parameter to the kernel in lilo to ask the kernel to behave optimally
> for a desktop machine. No need of compile time options anymore. For more
> experienced users HZ=500/HZ=50/HZ=200 should work fine too, then you can
> tune the timeslices by hand but you must know what you're doing.
> 
> You can verify everything went well after boot with:
> 
> 	cat /proc/sys/kernel/{*timeslice,HZ}
> 
> This kernel seems to boot fine again on x86-64 too. The merges in pre6
> were helpful.
> 
> Due the amount of changes you may not want to run this on any production
> box (note: not because of the dynamic-hz feature, but because of
> everything else, the dynamic-hz is the only one that has no way to break
> anything, modulo stuff that would break anyways on ia64 and alpha
> already and that you can workaround trivially with HZ=100 if needed).
> 
> Only in 2.4.22aa1: 00_config-smp-1
> Only in 2.4.22aa1: 00_copy-namespace-1
> Only in 2.4.22aa1: 00_panic-console-switch-1
> Only in 2.4.22aa1: 00_pgt-cache-leak-2
> Only in 2.4.22aa1: 00_read_full_page-get_block-err-2
> Only in 2.4.22aa1: 00_sk98lin_2.4.22-20030902-1.gz
> Only in 2.4.22aa1: 05_vm_03_vm_tunables-4
> Only in 2.4.22aa1: 05_vm_05_zone_accounting-2
> Only in 2.4.22aa1: 05_vm_06_swap_out-3
> Only in 2.4.22aa1: 05_vm_07_local_pages-4
> Only in 2.4.22aa1: 05_vm_09_misc_junk-3
> Only in 2.4.22aa1: 05_vm_16_active_free_zone_bhs-1
> Only in 2.4.22aa1: 05_vm_20_cleanups-3
> Only in 2.4.22aa1: 9999900_request-firmware-1
> 
> 	Merged in mainline.
> 
> Only in 2.4.22aa1: 00_cpu-affinity-syscall-rml-4
> Only in 2.4.23pre6aa1: 00_cpu-affinity-syscall-rml-5
> Only in 2.4.22aa1: 00_extraversion-29
> Only in 2.4.23pre6aa1: 00_extraversion-30
> Only in 2.4.22aa1: 00_global-irq-race-1
> Only in 2.4.23pre6aa1: 00_global-irq-race-2
> Only in 2.4.22aa1: 00_rwsem-fair-38
> Only in 2.4.22aa1: 00_rwsem-fair-38-recursive-8
> Only in 2.4.23pre6aa1: 00_rwsem-fair-39
> Only in 2.4.23pre6aa1: 00_rwsem-fair-39-recursive-8
> Only in 2.4.22aa1: 00_silent-stack-overflow-18
> Only in 2.4.23pre6aa1: 00_silent-stack-overflow-19
> Only in 2.4.22aa1: 00_x86-optimize-apic-irq-and-cacheline-2
> Only in 2.4.23pre6aa1: 00_x86-optimize-apic-irq-and-cacheline-3
> Only in 2.4.22aa1: 05_vm_22_vm-anon-lru-1
> Only in 2.4.23pre6aa1: 05_vm_22_vm-anon-lru-2
> Only in 2.4.22aa1: 05_vm_17_rest-10
> Only in 2.4.23pre6aa1: 05_vm_26-rest-1
> Only in 2.4.22aa1: 05_vm_23_per-cpu-pages-3
> Only in 2.4.23pre6aa1: 05_vm_23_per-cpu-pages-4
> Only in 2.4.22aa1: 05_vm_24_accessed-ipi-only-smp-1
> Only in 2.4.22aa1: 10_lvm-snapshot-check-3
> Only in 2.4.23pre6aa1: 10_lvm-snapshot-check-4
> Only in 2.4.23pre6aa1: 20_rcu-poll-10
> Only in 2.4.22aa1: 20_rcu-poll-9
> Only in 2.4.22aa1: 30_irq-balance-15
> Only in 2.4.23pre6aa1: 30_irq-balance-16
> Only in 2.4.22aa1: 60_net-exports-3
> Only in 2.4.23pre6aa1: 60_net-exports-4
> Only in 2.4.22aa1: 60_tux-syscall-5
> Only in 2.4.23pre6aa1: 60_tux-syscall-6
> Only in 2.4.22aa1: 60_tux-sysctl-3
> Only in 2.4.23pre6aa1: 60_tux-sysctl-4
> Only in 2.4.22aa1: 90_proc-mapped-base-5
> Only in 2.4.23pre6aa1: 90_proc-mapped-base-6
> Only in 2.4.22aa1: 93_NUMAQ-13
> Only in 2.4.23pre6aa1: 93_NUMAQ-14
> Only in 2.4.22aa1: 96_inode_read_write-atomic-8
> Only in 2.4.23pre6aa1: 96_inode_read_write-atomic-9
> Only in 2.4.22aa1: 9900_aio-23.gz
> Only in 2.4.23pre6aa1: 9900_aio-24.gz
> Only in 2.4.22aa1: 9903_aio-22-ppc-1
> Only in 2.4.23pre6aa1: 9903_aio-22-ppc-2
> Only in 2.4.22aa1: 9910_shm-largepage-16.gz
> Only in 2.4.23pre6aa1: 9910_shm-largepage-17.gz
> Only in 2.4.22aa1: 9920_kgdb-11.gz
> Only in 2.4.23pre6aa1: 9920_kgdb-12.gz
> Only in 2.4.22aa1: 9925_kmsgdump-0.4.4-3.gz
> Only in 2.4.23pre6aa1: 9925_kmsgdump-0.4.4-4.gz
> Only in 2.4.22aa1: 9950_futex-5.gz
> Only in 2.4.23pre6aa1: 9950_futex-6.gz
> Only in 2.4.22aa1: 9999_sched_yield_scale-6
> Only in 2.4.23pre6aa1: 9999_sched_yield_scale-8
> Only in 2.4.22aa1: 9999901_scsi-softirq-2
> Only in 2.4.23pre6aa1: 9999901_scsi-softirq-3
> Only in 2.4.22aa1: 9999900_ecc-20030225-1.gz
> Only in 2.4.23pre6aa1: 9999900_ecc-20030225-2.gz
> Only in 2.4.22aa1: 9999900_ikd-2.gz
> Only in 2.4.23pre6aa1: 9999900_ikd-4.gz
> Only in 2.4.22aa1: 9999900_ipc-rcu-1
> Only in 2.4.23pre6aa1: 9999900_ipc-rcu-2
> Only in 2.4.22aa1: 9999900_monitor-mwait-1
> Only in 2.4.23pre6aa1: 9999900_monitor-mwait-2
> 
> 	Rediffed.
> 
> Only in 2.4.23pre6aa1: 00_do_brk-1
> 
> 	glitch fixup from Andrew.
> 
> Only in 2.4.23pre6aa1: 00_e-nodev-1
> 
> 	s/NODEV/ENODEV/ fixes from Vojtech.
> 
> Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
> 
> 	Add missing smb_mb().
> 
> Only in 2.4.22aa1: 00_log-buf-len-1
> Only in 2.4.23pre6aa1: 00_log-buf-len-dynamic-1
> 
> 	Ported to 2.4.23pre6 to allow the configuration of the
> 	buffer size at compile time too.
> 
> Only in 2.4.23pre6aa1: 00_proc-readlink-1
> 
> 	Remeber to free tmp buffer (from spender)
> 
> Only in 2.4.22aa1: 00_sched-O1-aa-2.4.19rc3-17.gz
> Only in 2.4.23pre6aa1: 00_sched-O1-aa-2.4.19rc3-18.gz
> 
> 	Let the idle load_balance pass to pick any task it find,
> 	if we go idle it means we've no task left. This fix speeds up number
> 	crunching up to 100% in some arch. The very same fix incidentally is
> 	also present in current 2.6.
> 
> Only in 2.4.23pre6aa1: 00_sk98lin-char-fix-1
> 
> 	Count the right number of bytes (not ints).
> 
> Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
> 
> 	Don't take the bkl (the same paths runs w/o the bkl elsewhere), from
> 	Chris Mason.
> 
> Only in 2.4.23pre6aa1: 01_softirq-nowait-1
> 
> 	We must really keep executing softirqs or it may take
> 	a too long time before ksoftirqd gets some cpu time.
> 	For an embedded device you may want to remove this,
> 	on a server we need this still.
> 
> Only in 2.4.23pre6aa1: 05_vm_27-pte-dirty-bit-in-hardware-1
> 
> 	This fixes a longstanding bug for a number of archs that haven't the
> 	dirty bit updated in hardware. For those archs we can't mark the pte
> 	writeable when it's still in swap cache, unless we don't mark it dirty
> 	too at the same time. Otherwise the cpu will go ahead writing to the
> 	page, no fault will happen and the swapcache will be still clean, and
> 	the data will be lost at the next zeroIO swapout leading to userspace
> 	data corruption and segfaults during swap. Affected archs are
> 	alpha/s390/s390x for example.
> 
> 	This bug was specific to the -aa VM, it couldn't happen
> 	in mainline. In my tree I optimized the code to exploited
> 	properties of archs that updates the bit in hardware for the
> 	first time. Hence the first need of a #define to differentiate the
> 	two code paths. The logic in the software-dirty-bit case will
> 	be less efficient of course (that's why there's a difference
> 	in the first place).
> 
> 	This is an obvious noop for x86 and x86-64 for example.
> 
> 	NOTE: the software-dirty-bit code is safe for all archs, the other way
> 	around not.
> 
> Only in 2.4.23pre6aa1: 30_18-busy-inodes-1
> 
> 	Try to avoid to leave busy inodes in autofs unmount. From Olaf Kirch.
> 	(original from Trond).
> 
> Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
> 
> 	Ignore errors on exiting lock cleanups. From Trond.
> 
> Only in 2.4.22aa1: 70_xfs-1.3-2.gz
> Only in 2.4.23pre6aa1: 70_xfs-1.3-3.gz
> Only in 2.4.22aa1: 70_xfs-sysctl-3
> Only in 2.4.23pre6aa1: 70_xfs13pre-final-1.gz
> Only in 2.4.23pre6aa1: 71_qsort-1
> Only in 2.4.22aa1: 71_xfs-VM_IO-1
> Only in 2.4.22aa1: 71_xfs-aa-4
> Only in 2.4.23pre6aa1: 71_xfs-aa-5
> Only in 2.4.23pre6aa1: 71_xfs-mmap-1
> Only in 2.4.22aa1: 71_xfs-tuning-1
> 
> 	XFS 13pre-final merged.
> 
> Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
> 
> 	To really be able to help and not just waste some
> 	seek and cpu, wait_on_buffer should honour the
> 	BH_Sync, but this is late in 2.4, and so I prefer
> 	to get rid of it instead of giving it the full power
> 	it should have.
> 
> Only in 2.4.23pre6aa1: 9999900_soft-float-1
> 
> 	Trap any usage of the FPU in kernel (needed
> 	to trap things like schedule_timeout(HZ*0.1)).
> 
> Only in 2.4.22aa1: 9999901_aio-network-poll-pipe-1
> Only in 2.4.23pre6aa1: 9999901_aio-poll-2
> 
> 	Leave only the aio-poll functionality because
> 	the network aio is still unfinished and nobody
> 	needs the pipe one (AFIK).
> 
> Only in 2.4.23pre6aa1: 9999_00_x86_64-suse-1
> Only in 2.4.23pre6aa1: 9999_00_x86_64-sys-1
> Only in 2.4.23pre6aa1: 9999_00_x86_64-tsc-c0-bandaid-1
> Only in 2.4.23pre6aa1: 9999_00_x86_64-warning-1
> Only in 2.4.23pre6aa1: 9999_00_x86_64-zone-startpfn-1
> Only in 2.4.23pre6aa1: 9999_01_x86_64-aio-bigpages-1
> Only in 2.4.23pre6aa1: 9999_01_x86_64-aio-export-1
> Only in 2.4.23pre6aa1: 9999_01_x86_64-bitops-1
> Only in 2.4.23pre6aa1: 9999_01_x86_64-discontig-pmd-1
> Only in 2.4.23pre6aa1: 9999_01_x86_64-epoll-1
> Only in 2.4.23pre6aa1: 9999_01_x86_64-fault32-wrap-1
> Only in 2.4.23pre6aa1: 9999_01_x86_64-kgdb-1
> Only in 2.4.23pre6aa1: 9999_01_x86_64-lvm32-no-checks-1
> 
> 	Merge x86-64 updates from Andi Kleen.
> 
> Only in 2.4.23pre6aa1: 9999_athlon-errata-prefetch-1
> 
> 	Fix athlon prefetch invalid faults from userspace.
> 	From Andi Kleen.
> 
> Only in 2.4.23pre6aa1: 9999_z-execve-race-1
> 
> 	Fix race in exit_mmap.
> 
> Only in 2.4.23pre6aa1: 9999_z-laptopmode-1
> 
> 	Allow the first read hitting the disk to flush all the dirty buffers.
> 	From Jens Axboe.
> 
> Only in 2.4.22aa1: 9999900_desktop-4
> Only in 2.4.23pre6aa1: 9999_zz-dynamic-timeslice-1
> Only in 2.4.23pre6aa1: 9999_zzz-dynamic-hz-1
> 
> 	HZ is now dynamic, you can boot with HZ=50 HZ=100 HZ=500
> 	or HZ=1000. However only HZ=100 and HZ=1000 are supported.
> 	Anything different from HZ=100 can trigger device driver
> 	bugs (those would already trigger on ia64 and alpha but
> 	on x86 the amount of drivers in use is larger).
> 
> 	But wait, you shouldn't use HZ=, you should only pass 'desktop' if you
> 	want to use the machine to behave as a better desktop and the kernel
> 	will just do the right thing.
> 
> 	max-timeslice/min-timeslice tunables are also provided
> 	as sysctl. Again no need to tune those, just pass
> 	'desktop' if your machine is a desktop.
> 
> 	The scheduler has internal heuristics (the avg_sleep for
> 	example in the o1 scheduler) to try to identify the interactive
> 	tasks. Since those are heuristics there's also the chance
> 	of failing. By rescheduling taks at around 100hz even if
> 	the heuristic fails there's quite a good margin before your
> 	eye can see it. This should help with video players and games.
> 
> Only in 2.4.23pre6aa1: 9999_zzzz-stackoverflow-1
> 
> 	Prevent overflows from happening on top of softirq. From
> 	Hugh Dickins.
> 
> Andrea - If you prefer relying on open source software, check these links:
> 	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
> 	    http://www.cobite.com/cvsps/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.23pre6aa1

[Mike Fedyk]

On Thu, Oct 02, 2003 at 05:26:48PM +0200, Andrea Arcangeli wrote:
> Only in 2.4.23pre6aa1: 05_vm_27-pte-dirty-bit-in-hardware-1
> 
> 	This fixes a longstanding bug for a number of archs that haven't the
> 	dirty bit updated in hardware. For those archs we can't mark the pte
> 	writeable when it's still in swap cache, unless we don't mark it dirty
> 	too at the same time. Otherwise the cpu will go ahead writing to the
> 	page, no fault will happen and the swapcache will be still clean, and
> 	the data will be lost at the next zeroIO swapout leading to userspace
> 	data corruption and segfaults during swap. Affected archs are
> 	alpha/s390/s390x for example.
> 
> 	This bug was specific to the -aa VM, it couldn't happen
> 	in mainline. In my tree I optimized the code to exploited
> 	properties of archs that updates the bit in hardware for the
> 	first time. Hence the first need of a #define to differentiate the
> 	two code paths. The logic in the software-dirty-bit case will
> 	be less efficient of course (that's why there's a difference
> 	in the first place).

What does rmap do in this case then?

Re: 2.4.23pre6aa1

[Andrea Arcangeli]

On Thu, Oct 02, 2003 at 05:51:16PM -0700, Mike Fedyk wrote:
> On Thu, Oct 02, 2003 at 05:26:48PM +0200, Andrea Arcangeli wrote:
> > Only in 2.4.23pre6aa1: 05_vm_27-pte-dirty-bit-in-hardware-1
> > 
> > 	This fixes a longstanding bug for a number of archs that haven't the
> > 	dirty bit updated in hardware. For those archs we can't mark the pte
> > 	writeable when it's still in swap cache, unless we don't mark it dirty
> > 	too at the same time. Otherwise the cpu will go ahead writing to the
> > 	page, no fault will happen and the swapcache will be still clean, and
> > 	the data will be lost at the next zeroIO swapout leading to userspace
> > 	data corruption and segfaults during swap. Affected archs are
> > 	alpha/s390/s390x for example.
> > 
> > 	This bug was specific to the -aa VM, it couldn't happen
> > 	in mainline. In my tree I optimized the code to exploited
> > 	properties of archs that updates the bit in hardware for the
> > 	first time. Hence the first need of a #define to differentiate the
> > 	two code paths. The logic in the software-dirty-bit case will
> > 	be less efficient of course (that's why there's a difference
> > 	in the first place).
> 
> What does rmap do in this case then?

no idea, but likely it wasn't affected. This was an ultra optimization I
did, it was very aggressive and it broke the archs with the pte-dirty
bit handled in software.

this is also the proof that the pte_* abstraction is not trasparent at
all, and we definitely need a compile time #define to differentiate the
two cases (I added it in the above patch for x86 and x86-64 and as said
above this patch is infact an obvious noop for those two archs).

This is the code that broke it. the 'page' pointed by the pte is an
exclusive page at that point, it means it's not shared by any other
"mm" and it's of course an anonymous page. It can be in the swapcache or
not, it doesn't make any difference (if it's not in the swapcache it's
guaranteed to be marked PG_dirty at the phyiscal level).

		if (write_access)
			pte = pte_mkdirty(pte);
		if (vma->vm_flags & VM_WRITE)
			pte = pte_mkwrite(pte);

This code is perfectly correct and it's more efficient than the
software-dirty-bitflag because it avoids a copy-on-write page fault if
this was a read access. If it was a read access we want to mark the pte
writeable but not dirty, so if the page is still in the swapcache and
nobody writes to it, we can swap out it zerocost. And at the same time
we avoid any copy-on-write pagefault if somebody writes later to the
page after we instantiated the mapping.

This is instead the version needed by archs with the dirty bit in
software like ppc/s390/s390x/ppc64/alpha (there maybe more).

		if (write_access)
			pte = pte_mkdirty(pte_mkwrite(pte));

On these archs we simply can't mark the pte writeable if we don't mark
it dirty too, or somebody can write to the swappage and we would never
notice, and the kernel would think it can swapout zerocost (swapcache
still clean), while it really should do the I/O in that case.

The bug wasn't too bad, just a segfault or data corruption in userspace
during heavy swapping. The kernel was stable, there's no way to crash
the kernel forgetting a dirty bit. So it was also hardly noticeable. And
if you had zero swap it simply couldn't trigger because no swapcache
could be allocated. So the workaround swapoff -a is 100% reliable.

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/

Re: 2.4.23pre6aa1

[Andrea Arcangeli]

On Thu, Oct 02, 2003 at 08:09:28PM -0400, Mathias Kretschmer wrote:
> I'm getting the below errors compiling the bttv module.
> 
> Also, the commercial OSS sound driver fails to compile against it.
> It compiled under -pre6.
> 
> Otherwise, it seems to work fine for me.
> 
> Let me know, if you need any further info.

did you configure pre6 mainline with CONFIG_FW_LOADER = y ?

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/

Re: 2.4.23pre6aa1: HZ not constant?

[Eyal Lebedinsky]

I am getting failures like this:

tr.c:81: initializer element is not constant
make[3]: *** [tr.o] Error 1
make[3]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre-aa/net/802'


ecc.c:43: initializer element is not constant
ecc.c:1495: warning: function declaration isn't a prototype
make[2]: *** [ecc.o] Error 1
make[2]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre-aa/drivers/char'

where the problem is a file level definition like
	static var = HZ;

and it seems that HZ is not anymore valid here (see include/linux/hz.h).

I have:
# CONFIG_DEBUG_KERNEL is not set

My gcc is 2.95 (Debian stable/woody).

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>

Re: 2.4.23pre6aa1: HZ not constant?

[Andrea Arcangeli]

On Fri, Oct 03, 2003 at 08:15:41PM +1000, Eyal Lebedinsky wrote:
> I am getting failures like this:
> 
> tr.c:81: initializer element is not constant
> make[3]: *** [tr.o] Error 1
> make[3]: Leaving directory
> `/data2/usr/local/src/linux-2.4-pre-aa/net/802'
> 
> 
> ecc.c:43: initializer element is not constant
> ecc.c:1495: warning: function declaration isn't a prototype
> make[2]: *** [ecc.o] Error 1
> make[2]: Leaving directory
> `/data2/usr/local/src/linux-2.4-pre-aa/drivers/char'
> 
> where the problem is a file level definition like
> 	static var = HZ;
> 
> and it seems that HZ is not anymore valid here (see include/linux/hz.h).

HZ isn't known at compile time anymore, you pass it to the kernel as
parameter dynamically.

the way to fix it is:

1) if the 'static var' variable is somehow visible to userspace then
   use USER_HZ and the user_to_kenrel_hz/user_to_kernel_hz_overflow
   (the latter is more efficient, it introduces zero branches , but it gives
   wrong results for very big inputs, it's ideal for sysctl set to
   things like 5*USER_HZ or anyways smaller than 2G/HZ ~= 1million).
2) if the static var is not visible to userspace (either via sysctl
   or module parameter) then we can just initialize it dynamically

This is the relevant fix for the above two problems. Please try again
and let me know if something else doesn't compile. Thanks!

--- x/drivers/char/ecc.c.~1~	2003-10-02 15:08:07.000000000 +0200
+++ x/drivers/char/ecc.c	2003-10-03 13:52:16.000000000 +0200
@@ -40,7 +40,7 @@
 #define max(a,b)	((a)>(b)?(a):(b))
 
 static int ecc_scrub = -1;
-static int ecc_ticks = HZ;
+static int ecc_ticks = USER_HZ;
 
 static spinlock_t ecc_lock = SPIN_LOCK_UNLOCKED;
 static int proc_ram_valid = 0;
@@ -1410,7 +1410,7 @@ static void check_ecc(unsigned long dumm
 	if (cs.clear_err)
 		cs.clear_err();
 
-	ecc_timer.expires = jiffies + ecc_ticks;
+	ecc_timer.expires = jiffies + user_to_kernel_hz_overflow(ecc_ticks);
 	add_timer(&ecc_timer);
 
 	spin_unlock (&ecc_lock);
@@ -1616,8 +1616,8 @@ static int __init ecc_init(void) 
 	spin_lock_bh (&ecc_lock);
 
 	printk(KERN_INFO "ECC: monitor version %s\n", ECC_VER);
-	if (ecc_ticks != HZ)
-		printk(KERN_INFO "ECC: interval=%d ticks\n", ecc_ticks);
+	if (user_to_kernel_hz_overflow(ecc_ticks) != HZ)
+		printk(KERN_INFO "ECC: interval=%d ticks\n", user_to_kernel_hz_overflow(ecc_ticks));
 
 	for (loop=0;loop<MAX_BANKS;loop++) {
 		bank[loop].endaddr = 0;
@@ -1650,7 +1650,7 @@ static int __init ecc_init(void) 
 
 	init_timer(&ecc_timer);
 	ecc_timer.function = check_ecc;
-	ecc_timer.expires = jiffies + ecc_ticks;
+	ecc_timer.expires = jiffies + user_to_kernel_hz_overflow(ecc_ticks);
 	add_timer(&ecc_timer);
 	ecc_timer_valid = 1;
 
@@ -1688,7 +1688,7 @@ MODULE_LICENSE("GPL");
 MODULE_PARM(ecc_scrub, "i");
 MODULE_PARM_DESC(ecc_scrub, "Force ECC scrubbing: 0=off 1=on");
 MODULE_PARM(ecc_ticks, "i");
-MODULE_PARM_DESC(ecc_ticks, "Timer interval (default HZ)");
+MODULE_PARM_DESC(ecc_ticks, "Timer interval (default USER_HZ)");
 
 module_init(ecc_init);
 module_exit(ecc_exit);
--- x/net/802/tr.c.~1~	2003-06-13 22:07:42.000000000 +0200
+++ x/net/802/tr.c	2003-10-03 13:59:02.000000000 +0200
@@ -69,7 +69,7 @@ struct rif_cache_s {	
 static rif_cache rif_table[RIF_TABLE_SIZE];
 static spinlock_t rif_lock = SPIN_LOCK_UNLOCKED;
 
-#define RIF_TIMEOUT 60*10*HZ
+#define RIF_TIMEOUT 60*10*USER_HZ
 #define RIF_CHECK_INTERVAL 60*HZ
 
 /*
@@ -78,7 +78,8 @@ static spinlock_t rif_lock = SPIN_LOCK_U
  
 static struct timer_list rif_timer;
 
-int sysctl_tr_rif_timeout = RIF_TIMEOUT;
+int __sysctl_tr_rif_timeout = RIF_TIMEOUT;
+#define sysctl_tr_rif_timeout user_to_kernel_hz_overflow(__sysctl_tr_rif_timeout)
 
 /*
  *	Put the headers on a token ring packet. Token ring source routing
@@ -545,7 +546,7 @@ static int rif_get_info(char *buffer,cha
 
 static int __init rif_init(void)
 {
-	rif_timer.expires  = RIF_TIMEOUT;
+	rif_timer.expires  = user_to_kernel_hz_overflow(RIF_TIMEOUT);
 	rif_timer.data     = 0L;
 	rif_timer.function = rif_check_expire;
 	init_timer(&rif_timer);
--- x/net/802/sysctl_net_802.c.~1~	2003-03-15 03:25:18.000000000 +0100
+++ x/net/802/sysctl_net_802.c	2003-10-03 13:59:19.000000000 +0200
@@ -19,9 +19,9 @@ ctl_table e802_table[] = {
 };
 
 #ifdef CONFIG_TR
-extern int sysctl_tr_rif_timeout;
+extern int __sysctl_tr_rif_timeout;
 ctl_table tr_table[] = {
-	{NET_TR_RIF_TIMEOUT, "rif_timeout", &sysctl_tr_rif_timeout, sizeof(int),
+	{NET_TR_RIF_TIMEOUT, "rif_timeout", &__sysctl_tr_rif_timeout, sizeof(int),
 	 0644, NULL, &proc_dointvec},
 	{0}
 };

Side note: there is no way that dynamic-hz could destabilize the kernel
(assuming you don't pass HZ != 100 at boot time which can trigger bugs
that would trigger anyways already on alpha or ia64). Every failure will
always happen at compile time (the worst one was HZ*0.1, but that's now
trapped by the -msoft-float, idea from Andi). I designed it strictly
that way, if you enable the CONFIG_DEBUG_HZ = y then even a reader of HZ
before the kernel parsing at boot initializes it will be safe defaulted
to USER_HZ and will only generate an harmless printk (this is useful to
port it to other archs).  However it's recommended to leave
CONFIG_DEBUG_HZ = n since enabling it would decrease performance due the
additional sanity checking. While dyanmic-hz with debugging disabled is
definitely not measurable in any benchmark and it allows to run true
desktop multimedia with a guarantee of timeslices that provides a
rescheduling rate higher than 50hz, that is the only way to reliably
fool our eyes. The scheduler heuristics still play an important role but
any heuristic isn't infallible and we can't depend on it. A desktop
isn't computing anyways, boosting the reschedule rate is perfectly
acceptable and the right thing to do IMHO.

Once somebody will start shipping cpus with address space numbers in the
tlb (no brainer and needed _huge_ hardware optimization), the slowdown
will be even less.

BTW, there's a -aa NUMA specific bug that is crashing my x86-64 in half
an hour (it's related to the paddr stuff needed for 32bit numa with PAE,
this mean 32bit NUMA is also unused), so don't compile a numa kernel,
select smp only. Next release should work fine with numa too.

> I have:
> # CONFIG_DEBUG_KERNEL is not set

that's ok, it's not related to this.

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/

Re: 2.4.23pre6aa1: scsi/pcmcia qlogic does not build

[Eyal Lebedinsky]

gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre-aa/include -Wall
-Wstrict-
prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-poi
nter -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686
-malign-functio
ns=4 -DMODULE -DMODVERSIONS -include
/data2/usr/local/src/linux-2.4-pre-aa/inclu
de/linux/modversions.h  -nostdinc -iwithprefix include
-DKBUILD_BASENAME=qlogicf
as -DPCMCIA -D__NO_VERSION__ -c -o qlogicfas.o ../qlogicfas.c
../qlogicfas.c: In function `qlogicfas_detect':
../qlogicfas.c:650: warning: passing arg 1 of
`scsi_unregister_R2c5e5a25' from incompatible pointer type
ld -m elf_i386 -r -o qlogic_cs.o qlogic_stub.o qlogicfas.o
qlogicfas.o: In function `init_module':
qlogicfas.o(.text+0xe40): multiple definition of `init_module'
qlogic_stub.o(.text+0x770): first defined here
ld: Warning: size of symbol `init_module' changed from 77 to 58 in
qlogicfas.o
qlogicfas.o: In function `cleanup_module':
qlogicfas.o(.text+0xe80): multiple definition of `cleanup_module'
qlogic_stub.o(.text+0x7c0): first defined here
ld: Warning: size of symbol `cleanup_module' changed from 40 to 16 in
qlogicfas.o
make[3]: *** [qlogic_cs.o] Error 1
make[3]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre-aa/drivers/scsi/pcmcia'

A broken build?

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>

Re: 2.4.23pre6aa1: scsi/pcmcia qlogic does not build

[Andrea Arcangeli]

On Sat, Oct 04, 2003 at 12:26:43AM +1000, Eyal Lebedinsky wrote:
> gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre-aa/include -Wall
> -Wstrict-
> prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
> -fomit-frame-poi
> nter -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686
> -malign-functio
> ns=4 -DMODULE -DMODVERSIONS -include
> /data2/usr/local/src/linux-2.4-pre-aa/inclu
> de/linux/modversions.h  -nostdinc -iwithprefix include
> -DKBUILD_BASENAME=qlogicf
> as -DPCMCIA -D__NO_VERSION__ -c -o qlogicfas.o ../qlogicfas.c
> ../qlogicfas.c: In function `qlogicfas_detect':
> ../qlogicfas.c:650: warning: passing arg 1 of
> `scsi_unregister_R2c5e5a25' from incompatible pointer type
> ld -m elf_i386 -r -o qlogic_cs.o qlogic_stub.o qlogicfas.o
> qlogicfas.o: In function `init_module':
> qlogicfas.o(.text+0xe40): multiple definition of `init_module'
> qlogic_stub.o(.text+0x770): first defined here
> ld: Warning: size of symbol `init_module' changed from 77 to 58 in
> qlogicfas.o
> qlogicfas.o: In function `cleanup_module':
> qlogicfas.o(.text+0xe80): multiple definition of `cleanup_module'
> qlogic_stub.o(.text+0x7c0): first defined here
> ld: Warning: size of symbol `cleanup_module' changed from 40 to 16 in
> qlogicfas.o
> make[3]: *** [qlogic_cs.o] Error 1
> make[3]: Leaving directory
> `/data2/usr/local/src/linux-2.4-pre-aa/drivers/scsi/pcmcia'
> 
> A broken build?

it's a real compilation bug (not a mistake of your toolchain). The
init_module function is defined both in qlogic_stub.c and in qlogicfas.c
that imports scsi_module.c. One of the two has to go away or it can't
link due a name clash across two objects.

after a first look I'm unsure what's the right fix. I guess the init
module of the _cs has to get priority over the scsi_module.c. so
basically you could hack something to disable the include of
scsi_module.c from the other file. This assumes the _cs init_module will
eventually register the scsi device too from the pcmcia callback.

However this should be a generic problem not introduced by my changes.
Is there any scsi or pcmcia person interested in fixing it?

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/

Re: 2.4.23pre6aa1

[Norberto Bensa]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 399 bytes --]

Hi Andrea,

Andrea Arcangeli wrote:
> URL:
>
> 	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.2
>3pre6aa1.gz

find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.23; fi
depmod: *** Unresolved symbols in /lib/modules/2.4.23/kernel/fs/xfs/xfs.o
depmod:         qsort

Regards,
Norberto

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.4.23pre6aa1

[Marcelo Tosatti]

On Thu, 2 Oct 2003, Andrea Arcangeli wrote:

> URL:
> Only in 2.4.23pre6aa1: 00_e-nodev-1
> 
> 	s/NODEV/ENODEV/ fixes from Vojtech.
> 
> Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
> 
> 	Add missing smb_mb().

> Only in 2.4.23pre6aa1: 00_proc-readlink-1
> 
> 	Remeber to free tmp buffer (from spender)
> 
> Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
> 
> 	Don't take the bkl (the same paths runs w/o the bkl elsewhere), from
> 	Chris Mason.
> 
> Only in 2.4.23pre6aa1: 01_softirq-nowait-1
> 
> 	We must really keep executing softirqs or it may take
> 	a too long time before ksoftirqd gets some cpu time.
> 	For an embedded device you may want to remove this,
> 	on a server we need this still.
> 
> Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
> 
> 	Ignore errors on exiting lock cleanups. From Trond.
> 
> Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
> 
> 	To really be able to help and not just waste some
> 	seek and cpu, wait_on_buffer should honour the
> 	BH_Sync, but this is late in 2.4, and so I prefer
> 	to get rid of it instead of giving it the full power
> 	it should have.
> 
> Only in 2.4.23pre6aa1: 9999_z-execve-race-1
> 
> 	Fix race in exit_mmap.

Andrea,

What about trying to merge this in mainline ? 

Will I have to look at them and merge them manually like I did with the VM 
changes ? 

:/

Re: 2.4.23pre6aa1

[Andrea Arcangeli]

On Sat, Oct 04, 2003 at 11:50:07PM -0300, Marcelo Tosatti wrote:
> 
> 
> On Thu, 2 Oct 2003, Andrea Arcangeli wrote:
> 
> > URL:
> > Only in 2.4.23pre6aa1: 00_e-nodev-1
> > 
> > 	s/NODEV/ENODEV/ fixes from Vojtech.
> > 
> > Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
> > 
> > 	Add missing smb_mb().
> 
> > Only in 2.4.23pre6aa1: 00_proc-readlink-1
> > 
> > 	Remeber to free tmp buffer (from spender)
> > 
> > Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
> > 
> > 	Don't take the bkl (the same paths runs w/o the bkl elsewhere), from
> > 	Chris Mason.
> > 
> > Only in 2.4.23pre6aa1: 01_softirq-nowait-1
> > 
> > 	We must really keep executing softirqs or it may take
> > 	a too long time before ksoftirqd gets some cpu time.
> > 	For an embedded device you may want to remove this,
> > 	on a server we need this still.
> > 
> > Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
> > 
> > 	Ignore errors on exiting lock cleanups. From Trond.
> > 
> > Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
> > 
> > 	To really be able to help and not just waste some
> > 	seek and cpu, wait_on_buffer should honour the
> > 	BH_Sync, but this is late in 2.4, and so I prefer
> > 	to get rid of it instead of giving it the full power
> > 	it should have.
> > 
> > Only in 2.4.23pre6aa1: 9999_z-execve-race-1
> > 
> > 	Fix race in exit_mmap.
> 
> Andrea,
> 
> What about trying to merge this in mainline ? 
> 
> Will I have to look at them and merge them manually like I did with the VM 
> changes ? 

I recall I sent one of these to you privately already (though not all of
them). the ones to merge are these:

	00_e-nodev-1
	00_get_request_wait-race-1
	00_proc-readlink-1
	00_sync-buffer-scale-1
	30_19-nfs-kill-unlock-1
	9999900_BH_Sync-remove-1
	9999_z-execve-race-1

I benchmarked BH_Sync as a worthless logic, it increases cpu usage and
slowdown I/O a little due suprious unplugs, basically it makes no sense
until we change wait_on_buffer not to call run_task_queue if the BH is
BH_Sync, but personally I prefer to nuke it than to go mangle
wait_on_buffer, it wouldn't be a huge optimization anyways (and it's a
noop without more than one spindle running).

as you know I tried to fix the execve race w/o removing the fast path,
but the lazy tlb code didn't work correctly, I'm unsure exactly what
went wrong with it. The above fix is obviously safe instead and it
indeed works fine. I'll be busy today and early next week. If something
doesn't apply cleanly let me know and I can fix it for you.

the checksum fix as well doesn't need to be merged since the bug was
fixed on a 2.4.19 based kernel, but 2.4.20 already has an alternate fix,
but I believe the fix Andi did is much better since it's zerocost for
the common aligned case, we only must avoid generating an invalid page
fault, reading garbage from the next page has always been safe, since
the garbage will be discared by the asm. So I'm evaluating if to drop
the fix in 2.4.20 and to retain only Andi's one for performance reason.
It's obvious Andi's fix won't alter performance for the 99% of common
cases so personally I prefer it.

thanks!

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/

Re: 2.4.23pre6aa1

[Marcelo Tosatti]

On Sun, 5 Oct 2003, Andrea Arcangeli wrote:

> > > Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
> > > 
> > > 	Add missing smb_mb().

Ok I see you add smp_mb() in get_request_wait_wakeup()... Can you please 
explain me in more detail why this is required? 

> > > Only in 2.4.23pre6aa1: 00_proc-readlink-1
> > > 
> > > 	Remeber to free tmp buffer (from spender)

Merged.

> > > 
> > > Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
> > > 
> > > 	Don't take the bkl (the same paths runs w/o the bkl elsewhere), from
> > > 	Chris Mason.

I prefer not applying this one.

> > > Only in 2.4.23pre6aa1: 01_softirq-nowait-1
> > > 
> > > 	We must really keep executing softirqs or it may take
> > > 	a too long time before ksoftirqd gets some cpu time.
> > > 	For an embedded device you may want to remove this,
> > > 	on a server we need this still.
> > > 
> > > Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
> > > 
> > > 	Ignore errors on exiting lock cleanups. From Trond.

Talked with Trond and he has other fixes pending... Should have them by 
the weekend.

> > > Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
> > > 
> > > 	To really be able to help and not just waste some
> > > 	seek and cpu, wait_on_buffer should honour the
> > > 	BH_Sync, but this is late in 2.4, and so I prefer
> > > 	to get rid of it instead of giving it the full power
> > > 	it should have.
> > > 
> > > Only in 2.4.23pre6aa1: 9999_z-execve-race-1
> > > 
> > > 	Fix race in exit_mmap.
>
> I recall I sent one of these to you privately already (though not all of
> them). the ones to merge are these:
> 
> 	00_e-nodev-1
> 	00_get_request_wait-race-1
> 	00_proc-readlink-1
> 	00_sync-buffer-scale-1
> 	30_19-nfs-kill-unlock-1
> 	9999900_BH_Sync-remove-1
> 	9999_z-execve-race-1
> 
> I benchmarked BH_Sync as a worthless logic, it increases cpu usage and
> slowdown I/O a little due suprious unplugs, basically it makes no sense
> until we change wait_on_buffer not to call run_task_queue if the BH is
> BH_Sync, but personally I prefer to nuke it than to go mangle
> wait_on_buffer, it wouldn't be a huge optimization anyways (and it's a
> noop without more than one spindle running).

I want to look with more time into this one...

> as you know I tried to fix the execve race w/o removing the fast path,
> but the lazy tlb code didn't work correctly, I'm unsure exactly what
> went wrong with it. The above fix is obviously safe instead and it
> indeed works fine. I'll be busy today and early next week. If something
> doesn't apply cleanly let me know and I can fix it for you.

Thats merged as well.

Apart from this there's a huge pile of fixes all over in -aa. It would be
good if we had them merged in.