* 2.6.6-mm1
@ 2004-05-10 9:45 Andrew Morton
2004-05-10 10:52 ` 2.6.6-mm1 Dominik Karall
` (4 more replies)
0 siblings, 5 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-10 9:45 UTC (permalink / raw)
To: linux-kernel
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm1/
- x86_64 sched-domains support
- Added the sysfs-backing-store patches
- A number of patches to shrink/consolidate dentry fields. Needs careful
testing. The relevant diffs are:
d_flags-locking-fix.patch
d_vfs_flags-locking-fix.patch
dentry-shrinkage.patch
dentry-qstr-consolidation.patch
dentry-qstr-consolidation-fix.patch
dentry-d_bucket-fix.patch
dentry-d_flags-consolidation.patch
dentry-layout-tweaks.patch
- The ia64 CPU hotplug stuff is all here now and doesn't appear to break
anything.
- Lots of fixes/cleanups/etc.
Changes since 2.6.6-rc3-mm2:
bk-agpgart.patch
bk-alsa.patch
bk-cifs.patch
bk-cpufreq.patch
bk-driver-core.patch
bk-drm.patch
bk-i2c.patch
bk-libata.patch
bk-netdev.patch
bk-pci.patch
bk-scsi.patch
bk-usb.patch
External trees (dropped bk-input because it has nasty merge errors against
Linus's tree)
-page_mapping-race-fix.patch
-ppc-ppc64-cleanup-ppc970-cpu-initialization.patch
-benh-credits-update.patch
-ppc32-add-missing-dma_mapping_error.patch
-fix-warn_on-on-xfs-module-unload.patch
-nforce-disconnect-fix.patch
-delete-posix-conformance-testing-by-unifix-message.patch
-netpoll-attributions.patch
Merged
-frame-pointer-based-stack-dumps-tweaks.patch
Folded into frame-pointer-based-stack-dumps.patch
+bk-driver-core-module-fix.patch
Fix compilation of bk-driver-core.patch
+small-numa-api-fixups-fix.patch
Fix small-numa-api-fixups.patch
+rmap-24-no-rmap-fastcalls.patch
+rmap-27-memset-0-vma.patch
+rmap-28-remove_vm_struct.patch
+rmap-29-vm_reserved-safety.patch
+rmap-30-fix-bad-mapcount.patch
+rmap-31-unlikely-bad-memory.patch
+rmap-32-zap_pmd_range-wrap.patch
MM work.
-fix-deadlock-in-journalled-quota-fix.patch
Folded into fix-deadlock-in-journalled-quota.patch
+ppc64-extra-barrier-in-i-o-operations.patch
PPC64 fix
+Move-saved_command_line-to-init-mainc-warnings.patch
Fix warnings due to Move-saved_command_line-to-init-mainc.patch
(serial console work OK for me on x86_64)
-sched-move-cold-task.patch
-sched-migrate-shortcut.patch
Nick wanted these dropped
+sched-enqueue_task_head.patch
But not this part.
-sched-move-migrate_all_tasks-to-cpu_dead-handling-up-fix.patch
-sched-move-migrate_all_tasks-to-cpu_dead-handling-unlikely-cleanup.patch
Folded into sched-move-migrate_all_tasks-to-cpu_dead-handling.patch
+x86_64-convert-sibling-map-to-masks.patch
+sched-x86_64-sched-domains-support.patch
x86_64 sched-domains support
-binfmt_misc-credentials-fixes.patch
-binfmt_misc-credentials-fixes-2.patch
Folded into binfmt_misc-credentials.patch
+ext3_reservation_discard_race_fix.patch
Fix a race in the ext3 reservation code
-neomagic-driver-update-fix.patch
Folded into neomagic-driver-update.patch
+remove-bootsect_helper-on-x86_64-and-pc98.patch
Removed unneeded code
-new-version-of-early-cpu-detect-fix.patch
Folded into new-version-of-early-cpu-detect.patch
-writepage-retval-warning.patch
Dropped - it was temp debug stuff.
+q40-fbdev-updates.patch
Update this fbdev driver
-allow-architectures-to-reenable-interrupts-on-contended-spinlocks-fix.patch
Folded into allow-architectures-to-reenable-interrupts-on-contended-spinlocks.patch
+un-inline-spinlocks-on-ppc64.patch
Make the ppc64 spinlock slowpath not inline.
+ia64-cpu-hotplug-cpu_present-2.patch
+ia64-cpu-hotplug-cpu_present-2-fix.patch
+ia64-cpuhotplug-hotcpu.patch
Finish off the ia64 CPU hotplug work
-proc-sys-kernel-vermagic.patch
This broke, and it's not clear that we need it.
-cyclades-cleanups-cleanups.patch
Folded into cyclades-cleanups.patch
-static-define_per_cpu-vs-modules-2.patch
Dropped - this issue will be fixed in s390 code
-filtered-wakeups-core.patch
-filtered-buffer_head-wakeups.patch
-filtered-buffer_head-wakeups-tweaks.patch
-wake-one-pg_locked-bh_lock-semantics.patch
-wake-one-pg_locked-bh_lock-semantics-tweaks.patch
+wakefunc.patch
+wakeup.patch
+filtered_page.patch
+filtered_buffer.patch
The filtered-wakeup code was redone.
+swsusp-documentation-updates.patch
Documentation
+fix-sysfs-symlinks.patch
+sysfs-leaves-mount.patch
+sysfs-leaves-dir.patch
+sysfs-leaves-file.patch
+sysfs-leaves-symlink.patch
+sysfs-leaves-bin.patch
+sysfs-leaves-misc.patch
sysfs backing store
+cache-queue_congestion_on-off_threshold.patch
Code simplification
+report-size-of-printk-buffer-selinux-interface.patch
Security hook for the recent syslog ehhancement.
+fix-race-on-tty-close.patch
Fix a workqueue flushing race
+die_386_graphic.patch
Make oops messages more entertaining
+force-ide-cache-flush-on-shutdown-flush.patch
+force-ide-cache-flush-on-shutdown-flush-fix.patch
IDE cache flushing fixes
+as-iosched-cleanups.patch
Anticipatory scheduler cleanups/simplifiactions/fixes
+fix-net-tulip-winbond-840c-warning.patch
Fix a warning
+pcmcia-tcicc-warning-fix.patch
And another
+lindent-on-arch-i386-kernel-cpuidc.patch
Lindent cpuid.c
+fix-media-dsbr100c-unused-variable.patch
+fix-warning-in-intermezzo-journalc.patch
+fix-wrong-var-used-in-hotplug-shpchp_ctrlc.patch
Fix warnings
+hugepage-add_to_page_cache-fix.patch
Fix hugetlb error-path handling
+hugetlb_shm_group-sysctl-patch.patch
Add /proc/sys/vm/hugetlb_shm_group: this holds the group ID of users who may
allocate hugetlb shm segments without CAP_IPC_LOCK. For Oracle.
+mlock_group-sysctl.patch
/proc/sys/vm/mlock_group: group ID of users who can do mlock() without
CAP_IPC_LOCK. Not sure that we need this.
+nfs_writepage_sync-stack-reduction.patch
Stack space reduction in NFS
+cpqarray-update-for-26.patch
Update this driver
+i8042-shutdown-fix.patch
Fix a shutdown race in this input driver
+kill-useless-mod_incdec_use_count-in-sound-oss-msndc.patch
+kill-mod_incdec_use_count-gunk-in-arch-cris-arch-v10-drivers-pcf8563c.patch
+fix-mod_incdec_use_count-gunk-in-arch-um-drivers-net_kernc.patch
+drivers-video-mod_inc_use_count-fixes.patch
+fix-mod_inc_use_count-usage-in-mtd.patch
+remove-mod_inc_use_count-usage-in-arch-um-drivers-harddog_kernc.patch
Module refcounting modernisations
+nfs4-stack-reduction.patch
Stack reduction in nfs4
+minor-rcu-optimization.patch
Save a few instructions in the RCU core
+idr-overflow-fixes.patch
+idr-overflow-fixes-fix.patch
+idr-overflow-fixes-2.patch
Fix overflow problems in the IDR code, and a posix-timer race
+timers-signals-rlimits.patch
+timers-signals-rlimits-setuid-fix.patch
+timers-signals-rlimits-fix.patch
+timers-signals-rlimits-rename-stuff.patch
Add rlimits to the posix-timer and rt-signal allocation code. To avoid
various out-of-memory DoS scenarii.
+call-might_sleep-in-tasklet_kill.patch
tasklet_kill() might sleep.
+d_flags-locking-fix.patch
dentry->d_flags will require dentry->d_lock
+d_vfs_flags-locking-fix.patch
cover dentry->d_vfs_flags with dentry->d_lock
+dentry-shrinkage.patch
Reduce the dentry size
+dentry-qstr-consolidation.patch
+dentry-qstr-consolidation-fix.patch
Cleanup/simplify/shrink the dentry qstr handling
+dentry-d_bucket-fix.patch
Be saver and faster about the locking around dentry->d_bucket in __d_lookup()
+dentry-d_flags-consolidation.patch
Move all the d_vfs_flags bits into d_flags, remove d_vfs_flags
+dentry-layout-tweaks.patch
Optimise the layout of dentry fields for lookup.
+binfmt-use-core_initcall.patch
Use core_initcall() to initialise the binfmt handlers. So subsequent
initcalls can call out to userspace executables.
+usermodehelper_init-use-core_initcall.patch
Use core_initcall() to initialise call_usermodehelper().
+export-con_set_default_unimap.patch
Missing EXPORT_SYMBOL()
+crystal-cs4235-mixer-fix.patch
Sound driver fix
+to-fix-i2o_proc-kernel-panic-on-access-of-proc-i2o-iop0-lct.patch
Fix i2o_proc oops, convert to seq_file.
+i2o_proc-module-owner-fix.patch
Set the module owner correctly
+remove-kernel-22-code-from-drivers-net-hamradio-dmasccc-fwd.patch
+telephony-ixjh-remove-kernel-22-ifdefs-fwd.patch
Remove some 2.2 back-compat code
+fix-some-typos-in-sound-docs.patch
Fix tpyos
+make-tags-for-selinux.patch
`make tags' was missing out of some SELinux directories
+remove-intermezzo.patch
Remove references to fs/intermezzo, in preparation for removing intermezzo
altogether.
+ppc-termio-fix.patch
PPC character driver fix
+fix-__down-tainting-kernel-with-config_modversions=y.patch
Fix bogus kernel tainting problem on ppc.
+add-qsort-library-function.patch
lib/qsort.c
+have-xfs-use-kernel-provided-qsort.patch
Use lib/qsort.c in XFS.
All 391 patches:
bk-agpgart.patch
bk-alsa.patch
bk-cifs.patch
bk-cpufreq.patch
bk-driver-core.patch
bk-drm.patch
bk-i2c.patch
bk-libata.patch
bk-netdev.patch
bk-pci.patch
bk-scsi.patch
bk-usb.patch
mm.patch
add -mmN to EXTRAVERSION
frame-pointer-based-stack-dumps.patch
x86: stack dumps using frame pointers
fealnx-bogon-fix.patch
fealnx.c spinlock fix
bk-driver-core-module-fix.patch
bk-driver-core-module-fix
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdbL warning fix
kgdb buffer overflow fix
kgdbL warning fix
kgdb: CONFIG_DEBUG_INFO fix
x86_64 fixes
correct kgdb.txt Documentation link (against 2.6.1-rc1-mm2)
kgdb: fix for recent gcc
kgdb warning fixes
THREAD_SIZE fixes for kgdb
kgdboe-netpoll.patch
kgdb-over-ethernet via netpoll
kgdboe: fix configuration of MAC address
kgdb-x86_64-support.patch
kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
kgdb-x86_64-warning-fixes
rmap-7-object-based-rmap.patch
rmap 7 object-based rmap
ia64-rmap-build-fix.patch
ia64 rmap build fix
rmap-8-unmap-nonlinear.patch
rmap 8 unmap nonlinear
slab-panic.patch
slab: consolidate panic code
rmap-9-remove-pte_chains.patch
rmap 9 remove pte_chains
rmap-9-page_add_anon_rmap-bug-fix.patch
page_add_anon_rmap BUG fix
rmap-10-add-anonmm-rmap.patch
rmap 10 add anonmm rmap
rmap-anonhd-locking-fix.patch
rmap anonhd locking fix
rmap-11-mremap-moves.patch
rmap 11 mremap moves
rmap-12-pgtable-remove-rmap.patch
rmap 12 pgtable remove rmap
rmap-13-include-asm-deletions.patch
rmap 13 include/asm deletions
i_shared_lock.patch
Convert i_shared_sem back to a spinlock
i_shared_lock fix 1
i_shared_lock fix 2
i_shared_lock mremap fix
rmap-14-i_shared_lock-fixes.patch
rmap 14: i_shared_lock fixes
numa-api-x86_64.patch
numa api: -64 support
numa api: Bitmap bugfix
numa-api-i386.patch
numa api: Add i386 support
numa-api-ia64.patch
numa api: Add IA64 support
numa-api-core.patch
numa api: Core NUMA API code
numa api: docs and policy_vma() locking fix
numa-api-core-tweaks
Some fixes for NUMA API
From: Matthew Dobson <colpatch@us.ibm.com>
Subject: [PATCH] include/linux/gfp.h cleanup for NUMA API
numa-api-core bitmap_clear fixes
mpol-in-copy_vma.patch
mpol in copy_vma
numa-api-core-slab-panic.patch
numa-api-core-slab-panic
numa-api-statistics-2.patch
Re-add NUMA API statistics
numa-api-vma-policy-hooks.patch
numa api: Add VMA hooks for policy
numa-api-vma-policy-hooks fix
numa-api-shared-memory-support.patch
numa api: Add shared memory support
numa-api-shared-memory-support-tweaks
small-numa-api-fixups.patch
small numa api fixups
small-numa-api-fixups-fix.patch
small-numa-api-fixups-fix
numa-api-statistics.patch
numa api: Add statistics
numa-api-anon-memory-policy.patch
numa api: Add policy support to anonymous memory
rmap-15-vma_adjust.patch
rmap 15: vma_adjust
rmap-16-pretend-prio_tree.patch
rmap 16: pretend prio_tree
rmap-17-real-prio_tree.patch
rmap 17: real prio_tree
rmap-18-i_mmap_nonlinear.patch
rmap 18: i_mmap_nonlinear
rmap-19-arch-prio_tree.patch
rmap 19: arch prio_tree
vm_area_struct-size-comment.patch
vm_area_struct size comment
rmapc-comment-style-fixups.patch
rmap.c comment/style fixups
rmap-20-i_mmap_shared-into-i_mmap.patch
rmap 20 i_mmap_shared into i_mmap
rmap-21-try_to_unmap_one-mapcount.patch
rmap 21 try_to_unmap_one mapcount
rmap-22-flush_dcache_mmap_lock.patch
rmap 22 flush_dcache_mmap_lock
rmap-23-empty-flush_dcache_mmap_lock.patch
rmap 23 empty flush_dcache_mmap_lock
rmap-24-no-rmap-fastcalls.patch
rmap 24 no rmap fastcalls
rmap-27-memset-0-vma.patch
rmap 27 memset 0 vma
rmap-28-remove_vm_struct.patch
rmap 28 remove_vm_struct
rmap-29-vm_reserved-safety.patch
rmap 29 VM_RESERVED safety
rmap-30-fix-bad-mapcount.patch
rmap 30 fix bad mapcount
rmap-31-unlikely-bad-memory.patch
rmap 31 unlikely bad memory
rmap-32-zap_pmd_range-wrap.patch
rmap 32 zap_pmd_range wrap
partial-prefetch-for-vma_prio_tree_next.patch
partial prefetch for vma_prio_tree_next
fix-deadlock-in-journalled-quota.patch
Fix deadlock in journalled quota
mips-update.patch
MIPS update
mips-fix-mips-26-fb-setup.patch
mips: fix 2.6 fb setup
mips-simplify-expression.patch
mips: Simplify expression
mips-newport-driver-fixes.patch
mips: newport driver fixes
mips-remove-video_type_sni_rm.patch
mips: remove VIDEO_TYPE_SNI_RM
mips-gbe-video-driver.patch
mips: GBE Video Driver
mips-add-missing-ip22-zilog-bit.patch
mips: add missing IP22 Zilog bit
mips-64-bit-mips-needs-compat-stuff.patch
mips: 64-bit MIPS needs compat stuff
mips-remove-dz-driver.patch
mips: remove dz driver
mips-sgiwd93-26-fixes-and-crapectomy.patch
mips: sgiwd93 2.6 fixes and crapectomy
must-fix.patch
must fix lists update
must fix list update
mustfix update
must-fix-update-5.patch
must-fix update
ppc64-extra-barrier-in-i-o-operations.patch
ppc64: extra barrier in I/O operations
ppc64-reloc_hide.patch
invalidate_inodes-speedup.patch
invalidate_inodes speedup
more invalidate_inodes speedup fixes
config_spinline.patch
uninline spinlocks for profiling accuracy.
pdflush-diag.patch
get_user_pages-handle-VM_IO.patch
fix get_user_pages() against mappings of /dev/mem
pci_set_power_state-might-sleep.patch
CONFIG_STANDALONE-default-to-n.patch
Make CONFIG_STANDALONE default to N
slab-leak-detector.patch
slab leak detector
mm/slab.c warning in cache_alloc_debugcheck_after
local_bh_enable-warning-fix.patch
Move-saved_command_line-to-init-mainc.patch
Move saved_command_line to init/main.c
Move-saved_command_line-to-init-mainc-warnings.patch
arch/i386/boot/compressed/misc.c warning fixes
sched-run_list-cleanup.patch
small scheduler cleanup
sched-find_busiest_node-resolution-fix.patch
sched: improved resolution in find_busiest_node
sched-domains.patch
sched: scheduler domain support
sched-domain-debugging.patch
sched_domain debugging
sched-domain-balancing-improvements.patch
scheduler domain balancing improvements
sched-sibling-map-to-cpumask.patch
sched: cpu_sibling_map to cpu_mask
sched-domains-i386-ht.patch
sched: implement domains for i386 HT
sched-no-drop-balance.patch
sched: handle inter-CPU jiffies skew
sched-directed-migration.patch
sched_balance_exec(): don't fiddle with the cpus_allowed mask
sched-group-power.patch
sched-group-power
sched-domains-use-cpu_possible_map.patch
sched_domains: use cpu_possible_map
sched-smt-nice-handling.patch
sched: SMT niceness handling
sched-local-load.patch
sched: add local load metrics
sched-process-migration-speedup.patch
Reduce TLB flushing during process migration
sched-trivial.patch
sched: trivial fixes, cleanups
sched-hotplug-cpu-sched_balance_exec-fix.patch
Hotplug CPU sched_balance_exec Fix
sched-wakebalance-fixes.patch
sched: wakeup balancing fixes
sched-imbalance-fix.patch
sched: fix imbalance calculations
sched-altix-tune1.patch
sched: altix tuning
sched-fix-activelb.patch
sched: oops fix
sched-ppc64-sched-domain-support.patch
ppc64: sched-domain support
sched-ppc64-sched-domain-support-fix.patch
ARCH_HAS_SCHED_WAKE_BALANCE doesnt exist
sched-domain-setup-lock.patch
sched: fix setup races
sched-minor-cleanups.patch
sched: minor cleanups
sched-inline-removals.patch
sched: uninlinings
sched-enqueue_task_head.patch
sched: add enqueeu_task_head()
sched-more-sync-wakeups.patch
sched: extend sync wakeups
sched-boot-fix.patch
sched: lock cpu_attach_domain for hotplug
sched-cleanups.patch
sched: cleanups
sched-damp-passive-balance.patch
sched: passive balancing damping
sched-cpu-load-cleanup.patch
sched: cpu load management cleanup
sched-balance-context.patch
sched: balance-on-clone
sched-less-idle.patch
sched: reduce idle time
sched-wake_up-speedup.patch
sched: micro-optimisation for wake_up
sched-smt-domain-race.patch
sched: Look at another CPU's domain
sched-move-migrate_all_tasks-to-cpu_dead-handling.patch
Move migrate_all_tasks to CPU_DEAD handling
sched-sys_sched_getaffinity_lock_cpu_hotplug.patch
sched_getaffinity vs cpu hotplug race fix
sched-kthread_stop_race_fix.patch
migration_thread() race fix
x86_64-convert-sibling-map-to-masks.patch
x86-64: convert sibling map to masks
sched-x86_64-sched-domains-support.patch
Add SMT setup for domain scheduler on x86-64
schedstats.patch
sched: scheduler statistics
fixes-in-32-bit-ioctl-emulation-code.patch
Fixes in 32 bit ioctl emulation code
cond_resched-might-sleep.patch
cond_resched() might sleep
fa311-mac-address-fix.patch
wrong mac address with netgear FA311 ethernet card
pid_max-fix.patch
Bug when setting pid_max > 32k
use-soft-float.patch
Use -msoft-float
non-readable-binaries.patch
Handle non-readable binfmt_misc executables
binfmt_misc-credentials.patch
binfmt_misc: improve calaulation of interpreter's credentials
poll-select-longer-timeouts.patch
poll()/select(): support longer timeouts
poll-select-range-check-fix.patch
poll()/select() range checking fix
poll-select-handle-large-timeouts.patch
poll()/select(): handle long timeouts
add-a-slab-for-ethernet.patch
Add a kmalloc slab for ethernet packets
siimage-update.patch
ide: update for siimage driver
nmi_watchdog-local-apic-fix.patch
Fix nmi_watchdog=2 and P4 HT
nmi-1-hz-2.patch
reduce NMI watchdog call frequency with local APIC.
shm-do_munmap-check.patch
stack-overflow-test-fix.patch
Fix stack overflow test for non-8k stacks
jbd-remove-livelock-avoidance.patch
JBD: remove livelock avoidance code in journal_dirty_data()
logitech-keyboard-fix.patch
2.6.5-rc2 keyboard breakage
stack-reductions-nfsread.patch
stack reductions: nfs read
speed-up-sata.patch
speed up SATA
advansys-fix.patch
advansys check_region() fix
journal_add_journal_head-debug.patch
journal_add_journal_head-debug
nfs-O_DIRECT-fixes.patch
NFS: O_DIRECT fixes
list_del-debug.patch
list_del debug check
oops-dump-preceding-code.patch
i386 oops output: dump preceding code
lockmeter.patch
lockmeter
ia64 CONFIG_LOCKMETER fix
cciss-logical-device-queues.patch
cciss: per logical device queues
sk98lin-buggy-vpd-workaround.patch
net/sk98lin: correct buggy VPD in ASUS MB
unplug-can-sleep.patch
unplug functions can sleep
firestream-warnings.patch
firestream warnings
ext3_rsv_cleanup.patch
ext3 block reservation patch set -- ext3 preallocation cleanup
ext3_rsv_base.patch
ext3 block reservation patch set -- ext3 block reservation
ext3 reservations: fix performance regression
ext3 block reservation patch set -- mount and ioctl feature
ext3 block reservation patch set -- dynamically increase reservation window
ext3-reservation-default-on.patch
ext3 reservation: default to on
ext3-reservation-ifdef-cleanup-patch.patch
ext3 reservation ifdef cleanup patch
ext3-reservation-max-window-size-check-patch.patch
ext3 reservation max window size check patch
ext3-reservation-file-ioctl-fix.patch
ext3 reservation file ioctl fix
ext3-lazy-discard-reservation-window-patch.patch
ext3 lazy discard reservation window patch
ext3-discard-reservation-in-last-iput-fix-patch.patch
ext3 discard reservation in last iput fix patch
ext3-discard-reservation-in-last-iput-fix-patch-fix.patch
Fix lazy reservation discard
ext3-reservation-bad-inode-fix.patch
ext3 reservations: bad_inode fix
ext3_reservation_discard_race_fix.patch
ext3 reservation discard race fix
ext3-bogus-enospc-fix.patch
Fix ext3 bogus ENOSPC
sched-in_sched_functions.patch
sched: in_sched_functions() cleanup
sysfs-d_fsdata-race-fix-2.patch
kobject/sysfs race fix
0-autofs4-2.6.0-signal-20040405.patch
autofs: dnotify + autofs may create signal/restart syscall loop
add-omitted-autofs4-super-block-field.patch
add omitted autofs4 super block field
1-autofs4-2.6.4-cleanup-20040405.patch
autofs: printk cleanups
2-autofs4-2.6.4-fill_super-20040405.patch
3-autofs4-2.6.0-bkl-20040405.patch
autofs: locking rework
4-autofs4-2.6.0-expire-20040405.patch
autofs: expiry refcount fixes
4-autofs4-260-expire-20040405-fix.patch
4-autofs4-2.6.0-expire-20040405 locking fix
4-autofs4-260-expire-20040405-fix-fix.patch
autofs expiry fix
4-autofs4-2.6.0-expire-20040405-may_umount_tree-cleanup.patch
autofs4: may_umount_tree() cleanup
5-autofs4-2.6.0-readdir-20040405.patch
autofs: readdir fixes
umount-after-bad-chdir.patch
fix umount after bad chdir
autofs4-fix-handling-of-chdir-and-chroot.patch
autofs4: fix handling of chdir and chroot
6-autofs4-2.6.0-may_umount-20040405.patch
autofs: add ioctl to query unmountability
7-autofs4-2.6.0-extra-20040405.patch
autofs: readdir futureproofing
autofs-locking-fix.patch
autofs locking fix
autofs4-race-fix.patch
autofs4 race fix
ext3-error-handling-fixes.patch
ext3 error handling fixes
re-open-descriptors-closed-on-exec-by-selinux-to.patch
selinux: reopen descriptors closed on exec to /dev/null
cyclades-maintainers-update.patch
cyclades MAINTAINERS update
laptop-mode-mutt-noatime-doc-update.patch
Laptop Mode doc update
as-increase-batch-expiry.patch
AS: increase batch expiry intervals
consolidate-sys32_readv-and-sys32_writev.patch
Consolidate sys32_readv and sys32_writev
consolidate-do_execve32.patch
Consolidate do_execve32
consolidate-sys32_select.patch
Consolidate sys32_select
consolidate-sys32_nfsservctl.patch
Consolidate sys32_nfsservctl
clean-up-asm-pgalloch-include.patch
Clean up asm/pgalloc.h include
clean-up-asm-pgalloch-include-2.patch
Clean up asm/pgalloc.h include
clean-up-asm-pgalloch-include-3.patch
Clean up asm/pgalloc.h include 3
ppc64-uninline-__pte_free_tlb.patch
ppc64: uninline __pte_free_tlb()
es7000-subarch-update-2.patch
es7000 subarch update
input-tsdev-fixes.patch
tsdev.c fixes
fix-scancode-keycode-scancode-conversion-for-265.patch
Fix scancode->keycode->scancode conversion
use-less-stack-in-ide_unregister.patch
use less stack in ide_unregister
psmouse-fix-mouse-hotplugging.patch
psmouse: fix mouse hotplugging
kernel_ppc8xx_misc.patch
ppc32: ppc8xx build fixes
remove-bootsect_helper-and-a-comment-fix-iii.patch
Remove bootsect_helper and a comment fix
remove-bootsect_helper-on-x86_64-and-pc98.patch
Remove bootsect_helper on x86_64 and pc98
fealnx-mac-address-and-other-issues.patch
Fealnx. Mac address and other issues
remove-some-unused-variables-in-s2io.patch
remove some unused variables in s2io
new-version-of-early-cpu-detect.patch
New version of early CPU detect
shrink_slab-handle-GFP_NOFS.patch
shrink_slab: improved handling of GFP_NOFS allocations
shrink_slab-handle-GFP_NOFS-fix.patch
shrink_slab-handle-GFP_NOFS-fix
fix-3c59xc-to-allow-3c905c-100bt-fd.patch
fix 3c59x.c to allow 3c905c 100bT-FD
use-dos_extended_partition.patch
partitioning cleanup: use DOS_EXTENDED_PARTITION
reiserfs-commit-default-fix.patch
From: Bart Samwel <bart@samwel.tk>
Subject: [PATCH] Reiserfs commit default fix
reiserfs-acl-mknod.patch
reiserfs: acl device node initialization
reiserfs-xattrs-04.patch
reiserfs: xattr support
reiserfs-acl-02.patch
reiserfs: ACL support
reiserfs-trusted-02.patch
reiserfs: support trusted xattrs
reiserfs-selinux-02.patch
reiserfs: selinux support
reiserfs-xattr-locking-02.patch
reiserfs: xattr locking fixes
reiserfs-quota.patch
reiserfs: quota support
reiserfs-permission.patch
reiserfs: xattr permission fix
reiserfs-warning.patch
reiserfs: add device info to diagnostic messages
reiserfs-group-alloc-9.patch
reiserfs: block allocator optimizations
reiserfs-remove-debugging-warning-from-block-allocator.patch
reiserfs: remove debugging warning from block allocator
reiserfs-group-alloc-9-build-fix.patch
reiserfs-group-alloc-9 build fix
reiserfs-search_reada-5.patch
reiserfs: btree readahead
reiserfs-data-logging-support.patch
reiserfs data logging support
problems-with-atkbd_command--atkbd_interrupt-interaction.patch
Problems with atkbd_command & atkbd_interrupt interaction
mptfusion-depends-on-scsi.patch
mptfusion depends on scsi
mark-config_mac_serial-drivers-macintosh-macserialc-as-broken.patch
Mark CONFIG_MAC_SERIAL (drivers/macintosh/macserial.c) as broken
radeon-garbled-screen-fix.patch
radeonfb: fix garbled screen
neomagic-driver-update.patch
Neomagic driver update.
radeon-fb-screen-corruption-fix.patch
radeonfb display corruption fix
tridentfbc-warning-fix.patch
video/tridentfb.c warning fix
hgafbc-warning-fix.patch
video/hgafb.c warning fix
tdfxfbc-warning-fix.patch
video/tdfxfb.c warning fix
imsttfbc-warning-fix.patch
video/imsttfb.c. warning fix
fbdev-logo-handling-fix.patch
fbdev: clean up logo handling
fbdev-redundant-prows-calculation-removal.patch
fbdev: remove redundant p->vrows calculation
fbdev-remove-redundant-local.patch
fbdev: remove redundant local
fbdev-access_align-default.patch
fbdev: set a default access_align value
fix-null-ptr-dereference-in-pm2fb_probe-2.patch
Fix NULL-ptr dereference in pm2fb_probe
virtual-fbdev-updates.patch
Virtual fbdev updates
vesa-fbdev-update.patch
Vesa Fbdev update
vesa-fbdev-update-fix.patch
Vesa Fbdev update fix
sis-agp-updates.patch
SIS AGP updates
new-asiliant-framebuffer-driver.patch
New Asiliant framebuffer driver.
fbcon-and-unimap.patch
Fix fbcon and unimap
videodev-handle-class_register-failure.patch
videodev: handle class_register() failure
q40-fbdev-updates.patch
Q40 fbdev updates.
8139too-suspend-fix.patch
8139too not running s3 suspend/resume pci fix
acpiphp_glue-oops-fix.patch
acpiphp_glue.c oops fix
clear_backing_dev_congested.patch
clear_baking_dev_congested
dpt_i2o.patch
Fix dpt_i2o
find_user-locking.patch
find_user-locking
improve-laptop-modes-block_dump-output.patch
Improve laptop mode's block_dump output
com90xx_message.patch
com90xx error message patch: check_region() gone
parport_doc_arg.patch
Kill a warning while making pdfdocs.
kernel-api-docs.patch
Kill some 'No description found...' warnings. (kernel-api.sgml)
allow-architectures-to-reenable-interrupts-on-contended-spinlocks.patch
Allow architectures to reenable interrupts on contended spinlocks
allow-i386-to-reenable-interrupts-on-lock-contention.patch
Allow i386 to reenable interrupts on lock contention
un-inline-spinlocks-on-ppc64.patch
Un-inline spinlocks on ppc64
only-print-tainted-message-once.patch
Only Print Taint Message Once
ia64-cpuhotplug-core_kernel_init.patch
oa64 cpu hotplug: core kernel initialisation
ia64-cpuhotplug-init_removal.patch
ia64 cpu hotplug: init section fixes
ia64-cpuhotplug-sysfs_ia64.patch
ia64 cpu hotplug: sysfs additions
ia64-cpuhotplug-irq_affinity_fix.patch
ia64 cpu hotplug: IRQ affinity work
ia64-cpuhotplug-palinfo.patch
ia64 cpu hotplug: /proc rework
ia64-cpu-hotplug-cpu_present-2.patch
Revisited: ia64-cpu-hotplug-cpu_present.patch
ia64-cpu-hotplug-cpu_present-2-fix.patch
ia64-cpu-hotplug-cpu_present-2-fix
ia64-cpuhotplug-hotcpu.patch
ia64 cpu hotplug: core
blk_start_queue-use-kblockd.patch
blk_start_queue() should use kblockd
module-ref-counting-for-vt-console-drivers.patch
Module ref counting for vt console drivers
edd-follow-sysfs-convention-module_version-remove-dead-scsi-symlink.patch
EDD: follow sysfs convention, MODULE_VERSION, remove dead SCSI symlink
cmpci-update.patch
cmpci OSS driver update
i2o-subsystem-fixing-and-cleanup-for-26-i2o-config-cleanpatch.patch
I2O subsystem fixing and cleanup for 2.6 - i2o-config-clean.patch
i2o-subsystem-fixing-and-cleanup-for-26-i2o-passthrupatch.patch
I2O subsystem fixing and cleanup for 2.6 - i2o-passthru.patch
i2o-subsystem-fixing-and-cleanup-for-26-i2o_block-cleanuppatch.patch
I2O subsystem fixing and cleanup for 2.6 - i2o_block-cleanup.patch
i2o-subsystem-fixing-and-cleanup-for-26-i2o-64-bit-fixpatch.patch
I2O subsystem fixing and cleanup for 2.6 - i2o-64-bit-fix.patch
i2o-subsystem-fixing-and-cleanup-for-26-i2o-makefile-cleanuppatch.patch
I2O subsystem fixing and cleanup for 2.6 - i2o-makefile-cleanup.patch
dentry-and-inode-cache-hash-algorithm-performance-changes.patch
dentry and inode cache hash algorithm performance changes.
fix-mtd-suspend-resume.patch
From: Russell King <rmk@arm.linux.org.uk>
Subject: [MTD] Fix MTD suspend/resume
remove-blk_queue_bounce-messages.patch
remove blk_queue_bounce() printks
fix-deadlock-in-__create_workqueue-2.patch
a
throttle-p4-thermal-warnings.patch
throttle P4 thermal warnings
i82365c-warning-fix.patch
pcmcia/i82365.c warning fix
make-4k-stacks-permanent.patch
make 4k stacks permanent
worker_thread-race-fix.patch
worker_thread-race-fix
force-config_regparm-to-y.patch
Force CONFIG_REGPARM to `y'
kernel-syscalls-retval-fix.patch
a
remove-errno-refs.patch
remove-errno-refs
ia64-remove-errno-refs.patch
ia64-remove-errno-refs
warn-when-smp_call_function-is-called-with-interrupts-disabled.patch
Warn when smp_call_function() is called with interrupts disabled
initio-ini-9x00u-uw-error-handling-in-26.patch
Initio INI-9X00U/UW error handling
fixup-68360-module-refcounting.patch
fixup 68360 module refcounting
missing-closing-n-in-printk.patch
missing closing n in printk
intermezzo-stack-reduction.patch
intermezzos stack usage reduction
lance-racal-interlan-fix.patch
lance.c: fix for card with signature 0x52 0x49
gcc-340-fixes-for-266-rc3-x86_64-kernel.patch
gcc-3.4.0 fixes for 2.6.6-rc3 x86_64 kernel
ppc64-use-generic-ipc-syscall-translation.patch
ppc64: use generic ipc syscall translation
ramdisk-size-warning-fix.patch
fix ramdisk size assembler warning
cyclades-cleanups.patch
cyclades cleanups
jiffies-to-clockt-fix_a1.patch
jiffies-to-clockt fix
readahead-private.patch
hack2
introduce-asm--8253pith.patch
CLOCK_TICK_RATE: introduce asm-*/8253pit.h, #define PIT_TICK_RATE constant.
use-pit_tick_rate-in-spkrc.patch
CLOCK_TICK_RATE: use PIT_TICK_RATE in *spkr.c
use-clock_tick_rate.patch
CLOCK_TICK_RATE: use CLOCK_TICK_RATE
265-es7000-subarch-update-for-generic-arch.patch
es7000 subarch update for generic arch
new-i2c-video-decoder-calls.patch
new i2c video decoder calls
new-i2c-video-decoder-calls-saa7111.patch
new i2c video decoder calls: saa7111 driver
get_thread_area-macros.patch
get_thread_area macro fixes
update-documentation-mdtxt.patch
update Documentation/md.txt
invalid-notify_changesymlink-in-nfsd.patch
Invalid notify_change(symlink, [ATTR_MODE]) in nfsd
bfs-filesystem-read-past-the-end-of-dir.patch
bfs filesystem read past the end of dir
simplify-mqueue_inode_info-messages-allocation.patch
simplify mqueue_inode_info->messages allocation
wakefunc.patch
filtered wakeups
wakeup.patch
filtered wakeups: wakeup enhancements
filtered_page.patch
filtered wakeups: apply to pagecache functions
filtered_buffer.patch
filtered wakeups: apply to buffer_head functions
swsusp-documentation-updates.patch
swsusp documentation updates
fix-sysfs-symlinks.patch
fix sysfs symlinks
sysfs-leaves-mount.patch
sysfs backing store: sysfs_direct
sysfs-leaves-dir.patch
sysfs backing store: inode operations
sysfs-leaves-file.patch
sysfs backing store: sysfs operations
sysfs-leaves-symlink.patch
sysfs backing store: sysfs_create_link changes
sysfs-leaves-bin.patch
sysfs backing store: bin file attribute changes
sysfs-leaves-misc.patch
sysfs backing store: attribute groups
cache-queue_congestion_on-off_threshold.patch
blk: cache queue_congestion_on/off_threshold values
report-size-of-printk-buffer-selinux-interface.patch
SElinux interface for reporting size of printk buffer
fix-race-on-tty-close.patch
Fix race on tty close
die_386_graphic.patch
ia32 oops diagnostic fix
force-ide-cache-flush-on-shutdown-flush.patch
Force IDE cache flush on shutdown
force-ide-cache-flush-on-shutdown-flush-fix.patch
force-ide-cache-flush-on-shutdown-flush-fix
as-iosched-cleanups.patch
as-iosched cleanups
fix-net-tulip-winbond-840c-warning.patch
fix net/tulip/winbond-840.c warning.
pcmcia-tcicc-warning-fix.patch
pcmcia/tcic.c warning fix.
lindent-on-arch-i386-kernel-cpuidc.patch
Lindent arch/i386/kernel/cpuid.c
fix-media-dsbr100c-unused-variable.patch
fix media/dsbr100.c unused variable.
fix-warning-in-intermezzo-journalc.patch
fix warning in intermezzo/journal.c.
fix-wrong-var-used-in-hotplug-shpchp_ctrlc.patch
fix wrong var used in hotplug/shpchp_ctrl.c.
hugepage-add_to_page_cache-fix.patch
hugepage: fix add_to_page_cache() error handling
hugetlb_shm_group-sysctl-patch.patch
Add sysctl to define a hugetlb-capable group
mlock_group-sysctl.patch
mlock_group sysctl
nfs_writepage_sync-stack-reduction.patch
nfs_writepage_sync stack reduction
cpqarray-update-for-26.patch
cpqarray update for 2.6
i8042-shutdown-fix.patch
i8042 shutdown fix
kill-useless-mod_incdec_use_count-in-sound-oss-msndc.patch
kill useless MOD_{INC,DEC}_USE_COUNT in sound/oss/msnd.c
kill-mod_incdec_use_count-gunk-in-arch-cris-arch-v10-drivers-pcf8563c.patch
kill MOD_{INC,DEC}_USE_COUNT gunk in arch/cris/arch-v10/drivers/pcf8563.c
fix-mod_incdec_use_count-gunk-in-arch-um-drivers-net_kernc.patch
fix MOD_{INC,DEC}_USE_COUNT gunk in arch/um/drivers/net_kern.c
drivers-video-mod_inc_use_count-fixes.patch
drivers/video/* MOD_INC_USE_COUNT fixes
fix-mod_inc_use_count-usage-in-mtd.patch
fix MOD_INC_USE_COUNT usage in mtd
remove-mod_inc_use_count-usage-in-arch-um-drivers-harddog_kernc.patch
remove MOD_INC_USE_COUNT usage in arch/um/drivers/harddog_kern.c
nfs4-stack-reduction.patch
nfs4 stack reduction
minor-rcu-optimization.patch
minor RCU optimization
idr-overflow-fixes.patch
Fixes for idr code
idr-overflow-fixes fix
More fixes for idr code
Fixes for POSIX timers
timers-signals-rlimits-setuid-fix
timers-signals-rlimits-fix
timers-signals-rlimits-rename-stuff
idr-overflow-fixes-fix.patch
idr-overflow-fixes fix
idr-overflow-fixes-2.patch
More fixes for idr code
timers-signals-rlimits.patch
Fixes for POSIX timers
timers-signals-rlimits-setuid-fix.patch
timers-signals-rlimits-setuid-fix
timers-signals-rlimits-fix.patch
timers-signals-rlimits-fix
timers-signals-rlimits-rename-stuff.patch
timers-signals-rlimits-rename-stuff
call-might_sleep-in-tasklet_kill.patch
Call might_sleep() in tasklet_kill
d_flags-locking-fix.patch
d_flags locking fixes
d_vfs_flags-locking-fix.patch
d_vfs_flags locking fix
dentry-shrinkage.patch
dentry shrinkage
dentry-qstr-consolidation.patch
dentry qstr consolidation
dentry-qstr-consolidation-fix.patch
dentry qstr consolidation fix
dentry-d_bucket-fix.patch
dentry d_bucket fix
dentry-d_flags-consolidation.patch
more dentry shrinkage
dentry-layout-tweaks.patch
dentry layout tweaks
binfmt-use-core_initcall.patch
use core_initcall for binfmt initialisation
usermodehelper_init-use-core_initcall.patch
Make usermodehelper_init() use core_initcall()
export-con_set_default_unimap.patch
export con_set_default_unimap()
crystal-cs4235-mixer-fix.patch
Crystal cs4235 mixer fix
to-fix-i2o_proc-kernel-panic-on-access-of-proc-i2o-iop0-lct.patch
Fix i2o_proc kernel panic on access of /proc/i2o/iop0/lct
i2o_proc-module-owner-fix.patch
i2o_proc module owner fix
remove-kernel-22-code-from-drivers-net-hamradio-dmasccc-fwd.patch
remove kernel 2.2 code from drivers/net/hamradio/dmascc.c
telephony-ixjh-remove-kernel-22-ifdefs-fwd.patch
telephony/ixj.h: remove kernel 2.2 #ifdef's
fix-some-typos-in-sound-docs.patch
fix some typos in sound docs
make-tags-for-selinux.patch
make tags for selinux
remove-intermezzo.patch
remove-intermezzo
ppc-termio-fix.patch
PPC termio fix
fix-__down-tainting-kernel-with-config_modversions=y.patch
Fix __down Tainting Kernel with CONFIG_MODVERSIONS=y
add-qsort-library-function.patch
add qsort library function
have-xfs-use-kernel-provided-qsort.patch
Have XFS use kernel-provided qsort
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 9:45 2.6.6-mm1 Andrew Morton
@ 2004-05-10 10:52 ` Dominik Karall
2004-05-10 11:18 ` 2.6.6-mm1 Dave Jones
2004-05-10 14:38 ` 2.6.6-mm1 Norberto Bensa
` (3 subsequent siblings)
4 siblings, 1 reply; 58+ messages in thread
From: Dominik Karall @ 2004-05-10 10:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel ML
CC arch/i386/kernel/cpu/cpufreq/p4-clockmod.o
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: In Funktion >>cpufreq_p4_get<<:
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:283: error: `sibling' undeclared
(first use in this function)
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:283: error: (Each undeclared
identifier is reported only once
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:283: error: for each function it
appears in.)
make[4]: *** [arch/i386/kernel/cpu/cpufreq/p4-clockmod.o] Fehler 1
greets dominik
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 10:52 ` 2.6.6-mm1 Dominik Karall
@ 2004-05-10 11:18 ` Dave Jones
2004-05-10 12:20 ` 2.6.6-mm1 Nick Piggin
0 siblings, 1 reply; 58+ messages in thread
From: Dave Jones @ 2004-05-10 11:18 UTC (permalink / raw)
To: Dominik Karall; +Cc: Andrew Morton, Linux Kernel ML
On Mon, May 10, 2004 at 12:52:33PM +0200, Dominik Karall wrote:
>
> CC arch/i386/kernel/cpu/cpufreq/p4-clockmod.o
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: In Funktion >>cpufreq_p4_get<<:
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:283: error: `sibling' undeclared
> (first use in this function)
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:283: error: (Each undeclared
> identifier is reported only once
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:283: error: for each function it
> appears in.)
> make[4]: *** [arch/i386/kernel/cpu/cpufreq/p4-clockmod.o] Fehler 1
Oops.
Dave
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/05/10 12:17:30+01:00 davej@redhat.com
# [CPUFREQ] Compilation fix.
#
# arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
# 2004/05/10 12:17:25+01:00 davej@redhat.com +3 -2
# [CPUFREQ] Compilation fix.
#
diff -Nru a/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c b/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
--- a/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c Mon May 10 12:18:08 2004
+++ b/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c Mon May 10 12:18:08 2004
@@ -74,7 +74,7 @@
hyperthreading = ((cpu_has_ht) && (smp_num_siblings == 2));
if (hyperthreading) {
sibling = cpu_sibling_map[cpu];
- cpu_set(sibling, affected_cpu_map);
+ cpu_set(sibling, affected_cpu_map);
}
#endif
set_cpus_allowed(current, affected_cpu_map);
@@ -283,12 +283,13 @@
#ifdef CONFIG_X86_HT
hyperthreading = ((cpu_has_ht) && (smp_num_siblings == 2));
if (hyperthreading) {
+ int sibling;
sibling = cpu_sibling_map[cpu];
cpu_set(sibling, affected_cpu_map);
}
#endif
set_cpus_allowed(current, affected_cpu_map);
- BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
+ BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
rdmsr(MSR_IA32_THERM_CONTROL, l, h);
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 11:18 ` 2.6.6-mm1 Dave Jones
@ 2004-05-10 12:20 ` Nick Piggin
2004-05-10 12:22 ` 2.6.6-mm1 Dave Jones
0 siblings, 1 reply; 58+ messages in thread
From: Nick Piggin @ 2004-05-10 12:20 UTC (permalink / raw)
To: Dave Jones; +Cc: Dominik Karall, Andrew Morton, Linux Kernel ML
Dave Jones wrote:
> On Mon, May 10, 2004 at 12:52:33PM +0200, Dominik Karall wrote:
> >
> > CC arch/i386/kernel/cpu/cpufreq/p4-clockmod.o
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: In Funktion >>cpufreq_p4_get<<:
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:283: error: `sibling' undeclared
> > (first use in this function)
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:283: error: (Each undeclared
> > identifier is reported only once
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:283: error: for each function it
> > appears in.)
> > make[4]: *** [arch/i386/kernel/cpu/cpufreq/p4-clockmod.o] Fehler 1
>
> Oops.
>
In -mm, cpu_sibling_map is a cpumask_t with cpu_sibling_map[cpu]
containing "cpu" and all of its siblings.
Linus' tree looks like it is going to be that way shortly too.
Nick
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 12:20 ` 2.6.6-mm1 Nick Piggin
@ 2004-05-10 12:22 ` Dave Jones
0 siblings, 0 replies; 58+ messages in thread
From: Dave Jones @ 2004-05-10 12:22 UTC (permalink / raw)
To: Nick Piggin; +Cc: Dominik Karall, Andrew Morton, Linux Kernel ML
On Mon, May 10, 2004 at 10:20:07PM +1000, Nick Piggin wrote:
> In -mm, cpu_sibling_map is a cpumask_t with cpu_sibling_map[cpu]
> containing "cpu" and all of its siblings.
>
> Linus' tree looks like it is going to be that way shortly too.
Ughh. Ok, I'm going to wuss out and leave that one for Andrew.
(Unless I get bored enough to go patch up a -mm tree later)
I'll worry about it in upstream cpufreq tree when it hits Linus' tree.
Dave
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: 2.6.6-mm1
@ 2004-05-10 12:43 Sid Boyce
2004-05-12 8:13 ` 2.6.6-mm1 Andrew Morton
0 siblings, 1 reply; 58+ messages in thread
From: Sid Boyce @ 2004-05-10 12:43 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 113 bytes --]
Oops on x86_only, x86_64 is OK.
Regards
Sid.
--
Sid Boyce .... Hamradio G3VBV and keen Flyer
Linux Only Shop.
[-- Attachment #2: BARRABAS_OOPS_2.6.6-mm1 --]
[-- Type: text/plain, Size: 11914 bytes --]
Linux version 2.6.6-mm1 (root@barrabas) (gcc version 3.3.3 (SuSE Linux)) #1 Mon May 10 12:07:55 BST 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 131056
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 126960 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
ACPI: RSDP (v000 Nvidia ) @ 0x000f75e0
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff7640
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:10 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
Built 1 zonelists
Found and enabled local APIC!
Initializing CPU#0
Kernel command line: root=/dev/hda1 vga=0x31a desktop hdb=ide-cd splash=silent 3 console=ttyS1
ide_setup: hdb=ide-cd
CPU 0 irqstacks, hard=c0445000 soft=c0444000
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 2079.662 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Memory: 515232k/524224k available (2226k kernel code, 8228k reserved, 917k data, 172k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 4112.38 BogoMIPS
Security Scaffold v1.0.0 initialized
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm) XP 2800+ stepping 00
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2079.0162 MHz.
..... host bus clock speed is 332.0665 MHz.
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xfb410, last bus=3
PCI: Using configuration type 1
spurious 8259A interrupt: IRQ7.
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040326
tbxface-0117 [03] acpi_load_tables : ACPI Tables successfully acquired
Parsing all Control Methods:....................................................................................................................................................................................................................................................................
Table [DSDT](id F004) - 701 Objects with 75 Devices 260 Methods 27 Regions
ACPI Namespace successfully loaded at root c045589c
ACPI: IRQ9 SCI: Level Trigger.
evxfevnt-0093 [04] acpi_enable : Transition to ACPI mode successful
evgpeblk-0867 [06] ev_create_gpe_block : GPE 00 to 31 [_GPE] 4 regs at 0000000000004020 on int 9
evgpeblk-0925 [06] ev_create_gpe_block : Found 0 Wake, Enabled 9 Runtime GPEs in this block
evgpeblk-0867 [06] ev_create_gpe_block : GPE 32 to 95 [_GPE] 8 regs at 00000000000044A0 on int 9
evgpeblk-0925 [06] ev_create_gpe_block : Found 0 Wake, Enabled 0 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:................................................................................
Initialized 27/27 Regions 1/1 Fields 28/28 Buffers 24/24 Packages (710 nodes)
Executing all Device _STA and_INI methods:.............................................................................
77 Devices found containing: 77 _STA, 1 _INI methods
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: nForce2 C1 Halt Disconnect fixup
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs *17)
ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs *19)
ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs *23)
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fbef0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xbf20, dseg 0xf0000
PnPBIOS: 17 nodes reported by PnP BIOS; 17 recorded by driver
ACPI: PCI Interrupt Link [LSMB] enabled at IRQ 11
ACPI: PCI Interrupt Link [LUBA] enabled at IRQ 9
ACPI: PCI Interrupt Link [LUBB] enabled at IRQ 5
ACPI: PCI Interrupt Link [LUB2] enabled at IRQ 11
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 5
ACPI: PCI Interrupt Link [LAPU] enabled at IRQ 5
ACPI: PCI Interrupt Link [LACI] enabled at IRQ 11
ACPI: PCI Interrupt Link [LFIR] enabled at IRQ 9
ACPI: PCI Interrupt Link [LNK2] enabled at IRQ 5
ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 9
PCI: Using ACPI for IRQ routing
vesafb: framebuffer at 0xd8000000, mapped to 0xe0808000, size 5120k
vesafb: mode is 1280x1024x16, linelength=2560, pages=1
vesafb: protected mode interface info at c000:dfe0
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb0: VESA VGA frame buffer device
vga16fb: mapped to 0xe0d09000
fb1: VGA16 VGA frame buffer device
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1084192248.542:0): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Console: switching to colour frame buffer device 160x64
Real Time Clock Driver v1.12
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Using anticipatory io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
loop: loaded (max 8 devices)
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: Maxtor 6Y120L0, ATA DISK drive
hdb: ATAPI COMBO48XMAX, ATAPI CD/DVD-ROM drive
hdc: Maxtor 6Y160P0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=65535/16/63
hda: hda1 hda2
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
hda: Write Cache FAILED Flushing!
hdc: max request size: 1024KiB
hdc: 320173056 sectors (163928 MB) w/7936KiB Cache, CHS=19929/255/63
hdc: hdc1 hdc2
hdb: ATAPI 40X DVD-ROM CD-R/RW CD-MRW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
ide-floppy driver 0.99.newide
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
input: PS/2 Generic Mouse on isa0060/serio1
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
I2O Core - (C) Copyright 1999 Red Hat Software
I2O: Event thread created as pid 184
i2o: Checking for PCI I2O controllers...
I2O configuration manager v 0.04.
(C) Copyright 1999 Red Hat Software
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET: Registered protocol family 1
ReiserFS: hda1: found reiserfs format "3.6" with standard journal
ReiserFS: hda1: using ordered data mode
ReiserFS: hda1: journal params: device hda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda1: checking transaction log (hda1)
ReiserFS: hda1: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 172k freed
INIT: version 2.85 booting
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c0163921
*pde = 00000000
___ ______
0--,| /OOOOOO\
{_o / /OO plop OO\
\__\_/OO oh dear OOO\s
\OOOOOOOOOOOOOOOO/
__XXX__ __XXX__
Oops: 0000 [#1]
PREEMPT DEBUG_PAGEALLOC
CPU: 0
EIP: 0060:[<c0163921>] Not tainted VLI
EFLAGS: 00010296 (2.6.6-mm1)
EIP is at locks_alloc_lock+0x1/0x20
eax: de016f6c ebx: bffff1e0 ecx: bffff1e0 edx: 00000007
esi: bffff1e0 edi: 00000000 ebp: dff7bf90 esp: dff7bf34
ds: 007b es: 007b ss: 0068
Process init (pid: 1, threadinfo=dff7b000 task=dff7ca70)
Stack: dff7bf90 c0165856 00000000 00000246 fffbd13f fffbd13f 00000007 de016f6c
dff7bf94 c011a52c ffffffff 000001ff bffff008 fa49babf 00000000 003fffff
00000000 fffbd13f dff7bf9c dff7bfac bffff1e0 ffffffea 00000000 dff7bfa4
Call Trace:
[<c01061e6>] show_stack+0xa6/0xb0
[<c0106358>] show_registers+0x148/0x1c0
[<c0106505>] die+0xa5/0x110
[<c0112682>] do_page_fault+0x3b2/0x538
[<c0105e55>] error_code+0x2d/0x38
[<c01618a5>] generic_file_fcntl+0xd5/0x1e0
[<c0161ae0>] sys_fcntl64+0x80/0xa0
[<c0105c4b>] syscall_call+0x7/0xb
Code: e8 81 73 1c 00 e9 6d fd ff ff e8 97 73 1c 00 e9 c2 fd ff ff e8 8d 73 1c 00 e9 28 fe ff ff 90 90 90 90 90 90 90 90 90 90 90 90 55 <a1> 00 00 00 00 ba d0 00 00 00 89 e5 c9 e9 fc ff ff ff 8d b6 00
<0>Kernel panic: Attempted to kill init!
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 9:45 2.6.6-mm1 Andrew Morton
2004-05-10 10:52 ` 2.6.6-mm1 Dominik Karall
@ 2004-05-10 14:38 ` Norberto Bensa
2004-05-10 14:55 ` 2.6.6-mm1 Dominik Karall
2004-05-10 15:20 ` 2.6.6-mm1 Christoph Hellwig
` (2 subsequent siblings)
4 siblings, 1 reply; 58+ messages in thread
From: Norberto Bensa @ 2004-05-10 14:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton wrote:
> make-4k-stacks-permanent.patch
> make 4k stacks permanent
I've reverted this one (nvidia crash blah blah...) but I still can't get a
working system. The box just sits there doing -apparently- nothing.
Which other patch{,es} am I missing?
Best regards,
Norberto
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 14:38 ` 2.6.6-mm1 Norberto Bensa
@ 2004-05-10 14:55 ` Dominik Karall
2004-05-10 15:02 ` 2.6.6-mm1 Norberto Bensa
0 siblings, 1 reply; 58+ messages in thread
From: Dominik Karall @ 2004-05-10 14:55 UTC (permalink / raw)
To: Norberto Bensa; +Cc: Linux Kernel ML
I reverted this patch too, but it works without problems here.
greets dominik
On Monday 10 May 2004 16:38, you wrote:
> Andrew Morton wrote:
> > make-4k-stacks-permanent.patch
> > make 4k stacks permanent
>
> I've reverted this one (nvidia crash blah blah...) but I still can't get a
> working system. The box just sits there doing -apparently- nothing.
>
> Which other patch{,es} am I missing?
>
> Best regards,
> Norberto
> -
> 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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 14:55 ` 2.6.6-mm1 Dominik Karall
@ 2004-05-10 15:02 ` Norberto Bensa
2004-05-10 15:22 ` 2.6.6-mm1 Dominik Karall
0 siblings, 1 reply; 58+ messages in thread
From: Norberto Bensa @ 2004-05-10 15:02 UTC (permalink / raw)
To: Dominik Karall; +Cc: Linux Kernel ML
Dominik Karall wrote:
> I reverted this patch too, but it works without problems here.
Hmmm... Do you use ACPI?
Thanks,
Norberto
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 9:45 2.6.6-mm1 Andrew Morton
2004-05-10 10:52 ` 2.6.6-mm1 Dominik Karall
2004-05-10 14:38 ` 2.6.6-mm1 Norberto Bensa
@ 2004-05-10 15:20 ` Christoph Hellwig
2004-05-11 5:21 ` 2.6.6-mm1 Andrew Morton
2004-05-10 21:37 ` 2.6.6-mm1 Christoph Hellwig
2004-05-12 12:49 ` 2.6.6-mm1 Sean Neakums
4 siblings, 1 reply; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-10 15:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Btw, one more thing as you're probably sending the i_shared_sem re-
spinlockification to Linus just about now: as we're renaming the thing
anyway can we give it a less confusing name like i_mmap_lock? It's not
been about shared mapping only for ages.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 15:02 ` 2.6.6-mm1 Norberto Bensa
@ 2004-05-10 15:22 ` Dominik Karall
2004-05-10 15:33 ` 2.6.6-mm1 Norberto Bensa
0 siblings, 1 reply; 58+ messages in thread
From: Dominik Karall @ 2004-05-10 15:22 UTC (permalink / raw)
To: Norberto Bensa; +Cc: Linux Kernel ML
On Monday 10 May 2004 17:02, you wrote:
> Dominik Karall wrote:
> > I reverted this patch too, but it works without problems here.
>
> Hmmm... Do you use ACPI?
yes
>
> Thanks,
> Norberto
greets dominik
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 15:22 ` 2.6.6-mm1 Dominik Karall
@ 2004-05-10 15:33 ` Norberto Bensa
0 siblings, 0 replies; 58+ messages in thread
From: Norberto Bensa @ 2004-05-10 15:33 UTC (permalink / raw)
To: Dominik Karall; +Cc: Linux Kernel ML
Dominik Karall wrote:
> On Monday 10 May 2004 17:02, you wrote:
> > Dominik Karall wrote:
> > > I reverted this patch too, but it works without problems here.
> >
> > Hmmm... Do you use ACPI?
>
> yes
Ah yes. I found the problem. I was using an unofficial nvidia module (5341.) I
went back to 5336 and everything works again.
$ uname -a
Linux venkman 2.6.6-mm1 #1 Mon May 10 11:18:44 ART 2004 i686 Pentium III
(Coppermine) GenuineIntel GNU/Linux
Many many thanks for your time and help,
Norberto
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
@ 2004-05-10 16:50 Sid Boyce
0 siblings, 0 replies; 58+ messages in thread
From: Sid Boyce @ 2004-05-10 16:50 UTC (permalink / raw)
To: linux-kernel
Norberto Wrote:
Andrew Morton wrote:
> >/ make-4k-stacks-permanent.patch/
> >/ make 4k stacks permanent/
> I've reverted this one (nvidia crash blah blah...) but I still can't
get a
> working system. The box just sits there doing -apparently- nothing.
>
> Which other patch{,es} am I missing?
> Best regards,
> Norberto
I have had 2 serious hard disk problems with the 4KSTACKS patch
installed, once through ignorance and once when I plain forgot and had
only checked that it wasn't on in my .config.
The first disk failed to boot up fully, it just hung somewhere in init,
but I could get at the files, the second one was dead, I had to do a
fresh format/install, reiserfsck /debugreiserfs could not repair either
of them. It's a dangerous patch.
Regards
Sid.
--
Sid Boyce .... Hamradio G3VBV and keen Flyer
Linux Only Shop.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 9:45 2.6.6-mm1 Andrew Morton
` (2 preceding siblings ...)
2004-05-10 15:20 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-10 21:37 ` Christoph Hellwig
2004-05-10 22:02 ` 2.6.6-mm1 Andrew Morton
2004-05-11 14:34 ` 2.6.6-mm1 Stephen Smalley
2004-05-12 12:49 ` 2.6.6-mm1 Sean Neakums
4 siblings, 2 replies; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-10 21:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
> +hugetlb_shm_group-sysctl-patch.patch
>
> Add /proc/sys/vm/hugetlb_shm_group: this holds the group ID of users who may
> allocate hugetlb shm segments without CAP_IPC_LOCK. For Oracle.
>
> +mlock_group-sysctl.patch
>
> /proc/sys/vm/mlock_group: group ID of users who can do mlock() without
> CAP_IPC_LOCK. Not sure that we need this.
These two just introduced a subtile behaviour change during stable series,
possibly (not likely) leading to DoS opportunities from applications running
as gid 0. Really, with capabilities first and now selinux we have moved
away from treating uid 0 special, so introducing special casing of a gid
now is more than just braindead.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 21:37 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-10 22:02 ` Andrew Morton
2004-05-10 22:05 ` 2.6.6-mm1 Christoph Hellwig
` (2 more replies)
2004-05-11 14:34 ` 2.6.6-mm1 Stephen Smalley
1 sibling, 3 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-10 22:02 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
Christoph Hellwig <hch@infradead.org> wrote:
>
> > +hugetlb_shm_group-sysctl-patch.patch
> >
> > Add /proc/sys/vm/hugetlb_shm_group: this holds the group ID of users who may
> > allocate hugetlb shm segments without CAP_IPC_LOCK. For Oracle.
> >
> > +mlock_group-sysctl.patch
> >
> > /proc/sys/vm/mlock_group: group ID of users who can do mlock() without
> > CAP_IPC_LOCK. Not sure that we need this.
>
> These two just introduced a subtile behaviour change during stable series,
> possibly (not likely) leading to DoS opportunities from applications running
> as gid 0.
mlock_group is likely to go away.
Is an unprivileged user likely to have gid 0? Easy enough to fix, anyway.
--- 25/fs/hugetlbfs/inode.c~hugetlb_shm_group-sysctl-gid-0-fix Mon May 10 14:57:31 2004
+++ 25-akpm/fs/hugetlbfs/inode.c Mon May 10 14:58:59 2004
@@ -722,8 +722,11 @@ static unsigned long hugetlbfs_counter(v
static int can_do_hugetlb_shm(void)
{
- return likely(capable(CAP_IPC_LOCK) ||
- in_group_p(sysctl_hugetlb_shm_group));
+ if (capable(CAP_IPC_LOCK))
+ return 1;
+ if (sysctl_hugetlb_shm_group == 0)
+ return 0;
+ return in_group_p(sysctl_hugetlb_shm_group);
}
struct file *hugetlb_zero_setup(size_t size)
> Really, with capabilities first and now selinux we have moved
> away from treating uid 0 special, so introducing special casing of a gid
> now is more than just braindead.
Capabilities are broken and don't work. Nobody has a clue how to provide
the required services with SELinux and nobody has any code and we need the
feature *now* before vendors go shipping even more ghastly stuff.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:02 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-10 22:05 ` Christoph Hellwig
2004-05-10 22:15 ` 2.6.6-mm1 Andrew Morton
2004-05-10 22:27 ` 2.6.6-mm1 Valdis.Kletnieks
2004-05-10 23:11 ` 2.6.6-mm1 Chris Wedgwood
2 siblings, 1 reply; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-10 22:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
> Capabilities are broken and don't work. Nobody has a clue how to provide
> the required services with SELinux and nobody has any code and we need the
> feature *now* before vendors go shipping even more ghastly stuff.
The thing is special privilegues for a group don't fit into any of the
various privilegues schemes we have (capabilities, selinux, etc..),
it's really a horrible hack. What happened to the patch rick promised
to make mlock an rlimit? This is the right approach and could be easily
extended to hugetlb pages.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:05 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-10 22:15 ` Andrew Morton
2004-05-10 22:20 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 23:16 ` 2.6.6-mm1 Matt Mackall
0 siblings, 2 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-10 22:15 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
Christoph Hellwig <hch@infradead.org> wrote:
>
> > Capabilities are broken and don't work. Nobody has a clue how to provide
> > the required services with SELinux and nobody has any code and we need the
> > feature *now* before vendors go shipping even more ghastly stuff.
>
> The thing is special privilegues for a group don't fit into any of the
> various privilegues schemes we have (capabilities, selinux, etc..),
> it's really a horrible hack.
It beats the alternatives which are floating about, which includes a sysctl
which defeats CAP_SYS_MLOCK system-wide.
> What happened to the patch rick promised
> to make mlock an rlimit? This is the right approach and could be easily
> extended to hugetlb pages.
rlimits don't work for this. shm segments persist after process exit and
aren't associated with a particular user.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:15 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-10 22:20 ` Christoph Hellwig
2004-05-10 22:47 ` 2.6.6-mm1 Andrew Morton
2004-05-10 23:16 ` 2.6.6-mm1 Matt Mackall
1 sibling, 1 reply; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-10 22:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Mon, May 10, 2004 at 03:15:54PM -0700, Andrew Morton wrote:
> It beats the alternatives which are floating about, which includes a sysctl
> which defeats CAP_SYS_MLOCK system-wide.
That one might not be nice, but at least it doesn't randomly change
the meaning of a group id. So yeah, although it's a hack too it's
much much better than the junk that just went into Linus tree.
Why btw do we have a staging tree if such sensitive patches go into
mainline without proper review after just one day?
> > What happened to the patch rick promised
> > to make mlock an rlimit? This is the right approach and could be easily
> > extended to hugetlb pages.
>
> rlimits don't work for this. shm segments persist after process exit and
> aren't associated with a particular user.
When did shm segments come into the play? I know we bolted hugetlb
support onto the back of the already horrible sysv shm interface, but
if people want additional interfaces ontop of that they should use
the proper mmap api.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:02 ` 2.6.6-mm1 Andrew Morton
2004-05-10 22:05 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-10 22:27 ` Valdis.Kletnieks
2004-05-10 22:48 ` 2.6.6-mm1 Andrew Morton
2004-05-10 23:11 ` 2.6.6-mm1 Chris Wedgwood
2 siblings, 1 reply; 58+ messages in thread
From: Valdis.Kletnieks @ 2004-05-10 22:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Mon, 10 May 2004 15:02:03 PDT, Andrew Morton said:
> > These two just introduced a subtile behaviour change during stable series,
> > possibly (not likely) leading to DoS opportunities from applications running
> > as gid 0.
>
> mlock_group is likely to go away.
>
> Is an unprivileged user likely to have gid 0? Easy enough to fix, anyway.
Equally important, is gid 0 (with its other possible overloadings) something that we
want to put on a user just because they have a need for mlock??
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:20 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-10 22:47 ` Andrew Morton
2004-05-10 22:48 ` 2.6.6-mm1 Christoph Hellwig
0 siblings, 1 reply; 58+ messages in thread
From: Andrew Morton @ 2004-05-10 22:47 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
Christoph Hellwig <hch@infradead.org> wrote:
>
> On Mon, May 10, 2004 at 03:15:54PM -0700, Andrew Morton wrote:
> > It beats the alternatives which are floating about, which includes a sysctl
> > which defeats CAP_SYS_MLOCK system-wide.
>
> That one might not be nice, but at least it doesn't randomly change
> the meaning of a group id.
If you don't set the sysctl there is no change in system behaviour.
> So yeah, although it's a hack too it's
> much much better than the junk that just went into Linus tree.
Untrue. With the system-wide thing unprivileged local users can
trivially DoS the database.
> Why btw do we have a staging tree if such sensitive patches go into
> mainline without proper review after just one day?
It was discussed on lkml, then later was dicussed extensively off-list
and I lost track of how long it had been in -mm. Sorry.
> > > What happened to the patch rick promised
> > > to make mlock an rlimit? This is the right approach and could be easily
> > > extended to hugetlb pages.
> >
> > rlimits don't work for this. shm segments persist after process exit and
> > aren't associated with a particular user.
>
> When did shm segments come into the play? I know we bolted hugetlb
> support onto the back of the already horrible sysv shm interface, but
> if people want additional interfaces ontop of that they should use
> the proper mmap api.
Rewriting Oracle isn't a practical alternative.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:27 ` 2.6.6-mm1 Valdis.Kletnieks
@ 2004-05-10 22:48 ` Andrew Morton
2004-05-10 23:01 ` 2.6.6-mm1 Valdis.Kletnieks
0 siblings, 1 reply; 58+ messages in thread
From: Andrew Morton @ 2004-05-10 22:48 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: hch, linux-kernel
Valdis.Kletnieks@vt.edu wrote:
>
> On Mon, 10 May 2004 15:02:03 PDT, Andrew Morton said:
>
> > > These two just introduced a subtile behaviour change during stable series,
> > > possibly (not likely) leading to DoS opportunities from applications running
> > > as gid 0.
> >
> > mlock_group is likely to go away.
> >
> > Is an unprivileged user likely to have gid 0? Easy enough to fix, anyway.
>
> Equally important, is gid 0 (with its other possible overloadings) something that we
> want to put on a user just because they have a need for mlock??
You misread the code. The sysctl, when non-zero, specifies the group which is
allowed to allocate hugetlb-backed shm segments.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:47 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-10 22:48 ` Christoph Hellwig
0 siblings, 0 replies; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-10 22:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Mon, May 10, 2004 at 03:47:06PM -0700, Andrew Morton wrote:
> > So yeah, although it's a hack too it's
> > much much better than the junk that just went into Linus tree.
>
> Untrue. With the system-wide thing unprivileged local users can
> trivially DoS the database.
Well, that's your problem if you oracle. At least we don't get magic
groups.
> > Why btw do we have a staging tree if such sensitive patches go into
> > mainline without proper review after just one day?
>
> It was discussed on lkml, then later was dicussed extensively off-list
> and I lost track of how long it had been in -mm. Sorry.
Umm, the two patches appeared in -mm yesterday..
> > When did shm segments come into the play? I know we bolted hugetlb
> > support onto the back of the already horrible sysv shm interface, but
> > if people want additional interfaces ontop of that they should use
> > the proper mmap api.
>
> Rewriting Oracle isn't a practical alternative.
So we can rewrite the kernel but oracle can be fixed? I mean they
have thousands of programmers and can't fix they Database to use a sane
API? I'd even fix it up for them in an hour or two if they gave me the
sources..
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:48 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-10 23:01 ` Valdis.Kletnieks
0 siblings, 0 replies; 58+ messages in thread
From: Valdis.Kletnieks @ 2004-05-10 23:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: hch, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
On Mon, 10 May 2004 15:48:00 PDT, Andrew Morton said:
> You misread the code. The sysctl, when non-zero, specifies the group which is
> allowed to allocate hugetlb-backed shm segments.
OK.. <mode="emily_litella">Nevermind</mode> :)
Using a group ID for this is still somewhat ugly (having just been looking at
similar weirdness in the grsecurity patch) - but at least groups are relatively
cheap and it's there now (as opposed to an rlimit-based solution)...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:02 ` 2.6.6-mm1 Andrew Morton
2004-05-10 22:05 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 22:27 ` 2.6.6-mm1 Valdis.Kletnieks
@ 2004-05-10 23:11 ` Chris Wedgwood
2004-05-10 23:14 ` 2.6.6-mm1 Christoph Hellwig
` (2 more replies)
2 siblings, 3 replies; 58+ messages in thread
From: Chris Wedgwood @ 2004-05-10 23:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel
On Mon, May 10, 2004 at 03:02:03PM -0700, Andrew Morton wrote:
> Capabilities are broken and don't work. Nobody has a clue how to
> provide the required services with SELinux and nobody has any code
> and we need the feature *now* before vendors go shipping even more
> ghastly stuff.
eh? magic groups are nasty... and why is this needed? can't
oracle/whatever just run with a wrapper to give the capabilities out
as required until a better solution is available
merging this as-is IMO is a mistake, how about we get a chance to chew
on this for a while --- superficially it feels like a really nasty
hack
and who cares if vendors show something worse? vendors ship crap all
the time, that's partly why we have vendor kernels --- to ship crap
that people want now w/o having to corrupt and pollute the cleanliness
of the mainline kernel until a sufficiently well thought out sane plan
can be devised
--cw
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 23:11 ` 2.6.6-mm1 Chris Wedgwood
@ 2004-05-10 23:14 ` Christoph Hellwig
2004-05-10 23:28 ` 2.6.6-mm1 Andrew Morton
2004-05-10 23:33 ` 2.6.6-mm1 Chris Wright
2 siblings, 0 replies; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-10 23:14 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: Andrew Morton, Christoph Hellwig, linux-kernel
On Mon, May 10, 2004 at 04:11:46PM -0700, Chris Wedgwood wrote:
> eh? magic groups are nasty... and why is this needed? can't
> oracle/whatever just run with a wrapper to give the capabilities out
> as required until a better solution is available
Well, easiest thing would be to use mmap on hugetlbfs in oracle, then
you just need to chown /dev/hugetlb/ group hugetlb and set +x for the
group - same effect as the kernel hack but keeping policy where it
belongs.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 22:15 ` 2.6.6-mm1 Andrew Morton
2004-05-10 22:20 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-10 23:16 ` Matt Mackall
1 sibling, 0 replies; 58+ messages in thread
From: Matt Mackall @ 2004-05-10 23:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel
On Mon, May 10, 2004 at 03:15:54PM -0700, Andrew Morton wrote:
> Christoph Hellwig <hch@infradead.org> wrote:
> >
> > > Capabilities are broken and don't work. Nobody has a clue how to provide
> > > the required services with SELinux and nobody has any code and we need the
> > > feature *now* before vendors go shipping even more ghastly stuff.
> >
> > The thing is special privilegues for a group don't fit into any of the
> > various privilegues schemes we have (capabilities, selinux, etc..),
> > it's really a horrible hack.
>
> It beats the alternatives which are floating about, which includes a sysctl
> which defeats CAP_SYS_MLOCK system-wide.
>
> > What happened to the patch rick promised
> > to make mlock an rlimit? This is the right approach and could be easily
> > extended to hugetlb pages.
>
> rlimits don't work for this. shm segments persist after process exit and
> aren't associated with a particular user.
The answer here is probably to make quotas work for shmfs, tmpfs,
hugetlbfs, etc. This shouldn't be too bad except for quotactl(2)
insists on having a block special device to manipulate quotas. Adding
an fquotactl(file descriptor, ...) should deal with that.
The mlock rlimits probably still make sense even once this is in place.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 23:11 ` 2.6.6-mm1 Chris Wedgwood
2004-05-10 23:14 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-10 23:28 ` Andrew Morton
2004-05-10 23:33 ` 2.6.6-mm1 Chris Wedgwood
2004-05-10 23:33 ` 2.6.6-mm1 Chris Wright
2 siblings, 1 reply; 58+ messages in thread
From: Andrew Morton @ 2004-05-10 23:28 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: hch, linux-kernel
Chris Wedgwood <cw@f00f.org> wrote:
>
> On Mon, May 10, 2004 at 03:02:03PM -0700, Andrew Morton wrote:
>
> > Capabilities are broken and don't work. Nobody has a clue how to
> > provide the required services with SELinux and nobody has any code
> > and we need the feature *now* before vendors go shipping even more
> > ghastly stuff.
>
> eh? magic groups are nasty... and why is this needed? can't
> oracle/whatever just run with a wrapper to give the capabilities out
> as required until a better solution is available
capabilities all get dropped on the floor across exec(). We discussed this
on this list after Bill and I spent half a day getting cap_pam working,
only to discover that the kernel had been nobbled years ago.
> and who cares if vendors show something worse?
me.
> vendors ship crap all
> the time, that's partly why we have vendor kernels --- to ship crap
> that people want now w/o having to corrupt and pollute the cleanliness
> of the mainline kernel until a sufficiently well thought out sane plan
> can be devised
If vendors are forced to ship a nasty hack it often points at problems in
the mainline kernel. Certainly that's true in this case.
And if we are unable to fix the kernel acceptably then I'd prefer that the
expedient fix be in the mainstream kernel so as to prevent divergence in
user-visible features between vendor kernels.
And let's remember, code-wise, this is a very small change.
If someone comes up with an acceptable SELinux (or whatever)-based solution
then fine. But it's too late. This stuff is going out the door to end 2.6
users and that's just tough luck. The least we can do is to ensure that it
works the same across different vendor's kernels.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 23:11 ` 2.6.6-mm1 Chris Wedgwood
2004-05-10 23:14 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 23:28 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-10 23:33 ` Chris Wright
2004-05-11 1:59 ` 2.6.6-mm1 Matt Mackall
2 siblings, 1 reply; 58+ messages in thread
From: Chris Wright @ 2004-05-10 23:33 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: Andrew Morton, Christoph Hellwig, linux-kernel
* Chris Wedgwood (cw@f00f.org) wrote:
> On Mon, May 10, 2004 at 03:02:03PM -0700, Andrew Morton wrote:
>
> > Capabilities are broken and don't work. Nobody has a clue how to
> > provide the required services with SELinux and nobody has any code
> > and we need the feature *now* before vendors go shipping even more
> > ghastly stuff.
>
> eh? magic groups are nasty... and why is this needed? can't
> oracle/whatever just run with a wrapper to give the capabilities out
> as required until a better solution is available
I agree. I have a patch that at least fixes this bit of capabilities
(currently, what you suggest doesn't work right), which could easily be
dusted off and resent.
And while we're at it, it would be nice to have the working bits of
memlock rlimits going. At least the mlock() users would get some help
(i.e. gpg). Another bit I could resend (removing the broken shm bits,
of course). It's just those pesky shm segs having their own lifecycle
which breaks the hugetlb and SHM_LOCK attempts to use memlock rlimits.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 23:28 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-10 23:33 ` Chris Wedgwood
2004-05-10 23:51 ` 2.6.6-mm1 Andrew Morton
0 siblings, 1 reply; 58+ messages in thread
From: Chris Wedgwood @ 2004-05-10 23:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: hch, linux-kernel
On Mon, May 10, 2004 at 04:28:18PM -0700, Andrew Morton wrote:
> If vendors are forced to ship a nasty hack it often points at
> problems in the mainline kernel. Certainly that's true in this
> case.
Yes, so let's discuss it and think about a nice clean solution rather
than hastily merge something that 'seems to work' without considering
the long term consequences of this.
> And if we are unable to fix the kernel acceptably then I'd prefer
> that the expedient fix be in the mainstream kernel so as to prevent
> divergence in user-visible features between vendor kernels.
And when we have a clean solution we will have to live with this hack
too.
> And let's remember, code-wise, this is a very small change.
It's not the code size --- it's the fact we add a strange new semantic
(magic group) without what IMO is sufficient thought and discussion
into a stable kernel series knowing that we will probably *NEVER* be
able to remove this wart once we have a better solution.
> But it's too late.
Why? Also, most existing users will be 2.4.x --- why does that not
nee this but 2.6.x _MUST_ had it?
> This stuff is going out the door to end 2.6 users and that's just
> tough luck. The least we can do is to ensure that it works the same
> across different vendor's kernels.
When was this issue properly discussed? It seems like it's a new
issue that's be hurried out the door without much consultation.
It might be my interpretation, but this also reads to me like "I don't
think it's too ugly, it's my party so tough shit if you don't like it"
:)
--cw
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 23:33 ` 2.6.6-mm1 Chris Wedgwood
@ 2004-05-10 23:51 ` Andrew Morton
2004-05-10 23:53 ` 2.6.6-mm1 Chris Wedgwood
2004-05-11 6:18 ` 2.6.6-mm1 Christoph Hellwig
0 siblings, 2 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-10 23:51 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: hch, linux-kernel
Chris Wedgwood <cw@f00f.org> wrote:
>
> On Mon, May 10, 2004 at 04:28:18PM -0700, Andrew Morton wrote:
>
> > If vendors are forced to ship a nasty hack it often points at
> > problems in the mainline kernel. Certainly that's true in this
> > case.
>
> Yes, so let's discuss it and think about a nice clean solution rather
> than hastily merge something that 'seems to work' without considering
> the long term consequences of this.
Has been discussed on this list. It requires worrisome changes to the
capability system, changes to PAM, changes to login and changes to
applications.
> > And if we are unable to fix the kernel acceptably then I'd prefer
> > that the expedient fix be in the mainstream kernel so as to prevent
> > divergence in user-visible features between vendor kernels.
>
> And when we have a clean solution we will have to live with this hack
> too.
Maybe that's the price we pay for leaving this problem unsolved for a year.
I must say that it's also to some extent a consequence of ISV's and
vendors quitely working on problems in little corners.
> > And let's remember, code-wise, this is a very small change.
>
> It's not the code size --- it's the fact we add a strange new semantic
> (magic group) without what IMO is sufficient thought and discussion
> into a stable kernel series knowing that we will probably *NEVER* be
> able to remove this wart once we have a better solution.
There is no magic group unless the admin chooses to set the sysctl.
> > But it's too late.
>
> Why? Also, most existing users will be 2.4.x --- why does that not
> nee this but 2.6.x _MUST_ had it?
>
> > This stuff is going out the door to end 2.6 users and that's just
> > tough luck. The least we can do is to ensure that it works the same
> > across different vendor's kernels.
>
> When was this issue properly discussed? It seems like it's a new
> issue that's be hurried out the door without much consultation.
>
> It might be my interpretation, but this also reads to me like "I don't
> think it's too ugly, it's my party so tough shit if you don't like it"
> :)
You misunderstand. Nasty workarounds will be shipped to end users by
vendors. That's a certainty. We cannot change this now.
What I wish to do is to ensure that all users receive the *same* nasty
workaround. Call it damage control.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 23:51 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-10 23:53 ` Chris Wedgwood
2004-05-11 0:14 ` 2.6.6-mm1 Andrew Morton
2004-05-11 6:18 ` 2.6.6-mm1 Christoph Hellwig
1 sibling, 1 reply; 58+ messages in thread
From: Chris Wedgwood @ 2004-05-10 23:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: hch, linux-kernel
On Mon, May 10, 2004 at 04:51:32PM -0700, Andrew Morton wrote:
> Maybe that's the price we pay for leaving this problem unsolved for
> a year.
I didn't know it needed solving until recently. I guess I've been
under a rock or something then.
> You misunderstand. Nasty workarounds will be shipped to end users
> by vendors. That's a certainty. We cannot change this now.
Vendors will support this too presumably.
> What I wish to do is to ensure that all users receive the *same*
> nasty workaround. Call it damage control.
How urgent is this? Can it wait a few more weeks? It seems people
are new looking at this and a little more discussion won't hurt if
it's been a year already.
--cw
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 23:53 ` 2.6.6-mm1 Chris Wedgwood
@ 2004-05-11 0:14 ` Andrew Morton
2004-05-11 0:24 ` 2.6.6-mm1 Wim Coekaerts
2004-05-11 6:21 ` 2.6.6-mm1 Christoph Hellwig
0 siblings, 2 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-11 0:14 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: hch, linux-kernel
Chris Wedgwood <cw@f00f.org> wrote:
>
> On Mon, May 10, 2004 at 04:51:32PM -0700, Andrew Morton wrote:
>
> > Maybe that's the price we pay for leaving this problem unsolved for
> > a year.
>
> I didn't know it needed solving until recently. I guess I've been
> under a rock or something then.
It has stagnated. I think the mindset has been "oh, we need to ship a hack
because upstream is bust" and so nobody did anything.
> > You misunderstand. Nasty workarounds will be shipped to end users
> > by vendors. That's a certainty. We cannot change this now.
>
> Vendors will support this too presumably.
>
> > What I wish to do is to ensure that all users receive the *same*
> > nasty workaround. Call it damage control.
>
> How urgent is this? Can it wait a few more weeks? It seems people
> are new looking at this and a little more discussion won't hurt if
> it's been a year already.
>
Migrating away from this will require work from vendors, Oracle, PAM
developers, /bin/login and /bin/su developers. Until that has happened I
think we should arrange for vendor kernels and kernel.org kernels to offer
the same interfaces.
And I don't think pulling the feature out of kernel.org kernels will
provide any added stimulus, frankly. They'll just ship the hack and go off
to do something else.
If someone had done the kernel and userspace work 6-12 months ago then
sure, we wouldn't be in this situation.
As to whether it is practical to jam all this work through at this stage:
dunno, really. I doubt it. It would be good to try though.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 0:14 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-11 0:24 ` Wim Coekaerts
2004-05-11 1:10 ` 2.6.6-mm1 Andrew Morton
2004-05-11 6:21 ` 2.6.6-mm1 Christoph Hellwig
1 sibling, 1 reply; 58+ messages in thread
From: Wim Coekaerts @ 2004-05-11 0:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Chris Wedgwood, hch, linux-kernel
> Migrating away from this will require work from vendors, Oracle, PAM
> developers, /bin/login and /bin/su developers. Until that has happened I
> think we should arrange for vendor kernels and kernel.org kernels to offer
> the same interfaces.
We have done the work and are going to be ok going forward to just use
hugeltbfs directly, just mounting it with right uid,gid. the main issue
of course is the existing stuff out there and the fact that upgrades
from 2.4 to 2.6 would be a tad more nasty if we had to change so much
stuff around. it's never really a problem if we have advanced warning
and work towards stuff, it's a problem when we rely on stuff that exists
and then it gets pulled out underneath.
> And I don't think pulling the feature out of kernel.org kernels will
> provide any added stimulus, frankly. They'll just ship the hack and go off
> to do something else.
at least we will make the change ;)
> If someone had done the kernel and userspace work 6-12 months ago then
> sure, we wouldn't be in this situation.
right we did the work based on what we were given, shm_hugetlb, was
quite painless. I think the start of this problem in particular was the
bigpages hack that started 2 years ago.
Wim
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 0:24 ` 2.6.6-mm1 Wim Coekaerts
@ 2004-05-11 1:10 ` Andrew Morton
2004-05-11 1:51 ` 2.6.6-mm1 Wim Coekaerts
2004-05-11 6:22 ` 2.6.6-mm1 Christoph Hellwig
0 siblings, 2 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-11 1:10 UTC (permalink / raw)
To: Wim Coekaerts; +Cc: cw, hch, linux-kernel
Wim Coekaerts <wim.coekaerts@oracle.com> wrote:
>
> > Migrating away from this will require work from vendors, Oracle, PAM
> > developers, /bin/login and /bin/su developers. Until that has happened I
> > think we should arrange for vendor kernels and kernel.org kernels to offer
> > the same interfaces.
>
> We have done the work and are going to be ok going forward to just use
> hugeltbfs directly, just mounting it with right uid,gid. the main issue
err, so why did I just merge the hugetlb_shm_group patch?
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 1:10 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-11 1:51 ` Wim Coekaerts
2004-05-11 6:23 ` 2.6.6-mm1 Christoph Hellwig
2004-05-11 15:12 ` 2.6.6-mm1 Wim Coekaerts
2004-05-11 6:22 ` 2.6.6-mm1 Christoph Hellwig
1 sibling, 2 replies; 58+ messages in thread
From: Wim Coekaerts @ 2004-05-11 1:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: Wim Coekaerts, cw, hch, linux-kernel
> >
> > > Migrating away from this will require work from vendors, Oracle, PAM
> > > developers, /bin/login and /bin/su developers. Until that has happened I
> > > think we should arrange for vendor kernels and kernel.org kernels to offer
> > > the same interfaces.
> >
> > We have done the work and are going to be ok going forward to just use
> > hugeltbfs directly, just mounting it with right uid,gid. the main issue
>
> err, so why did I just merge the hugetlb_shm_group patch?
because of what you mentioned. it takes a long time before that goes
out, it's not even tested, and it doesn't apply to those 1000's of
existing systems taht will break on upgrade. exactly what you said, it
makes it possible to get to a different way smoothly in time. my
comments were not "we can use it today".
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 23:33 ` 2.6.6-mm1 Chris Wright
@ 2004-05-11 1:59 ` Matt Mackall
0 siblings, 0 replies; 58+ messages in thread
From: Matt Mackall @ 2004-05-11 1:59 UTC (permalink / raw)
To: Chris Wright
Cc: Chris Wedgwood, Andrew Morton, Christoph Hellwig, linux-kernel
On Mon, May 10, 2004 at 04:33:17PM -0700, Chris Wright wrote:
> * Chris Wedgwood (cw@f00f.org) wrote:
> > On Mon, May 10, 2004 at 03:02:03PM -0700, Andrew Morton wrote:
> >
> > > Capabilities are broken and don't work. Nobody has a clue how to
> > > provide the required services with SELinux and nobody has any code
> > > and we need the feature *now* before vendors go shipping even more
> > > ghastly stuff.
> >
> > eh? magic groups are nasty... and why is this needed? can't
> > oracle/whatever just run with a wrapper to give the capabilities out
> > as required until a better solution is available
>
> I agree. I have a patch that at least fixes this bit of capabilities
> (currently, what you suggest doesn't work right), which could easily be
> dusted off and resent.
>
> And while we're at it, it would be nice to have the working bits of
> memlock rlimits going. At least the mlock() users would get some help
> (i.e. gpg).
mlock() rlimits make sense independent of Oracle. There are a number
of things (realtime, security, iscsi) that might make good use of
small amounts of locked memory.
> Another bit I could resend (removing the broken shm bits,
> of course). It's just those pesky shm segs having their own lifecycle
> which breaks the hugetlb and SHM_LOCK attempts to use memlock rlimits.
They have a lifecycle like files (they live on a filesystem, after
all), which is why I suggest we need quota there. Again, something
that has sensible uses independent of Oracle.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 15:20 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-11 5:21 ` Andrew Morton
0 siblings, 0 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-11 5:21 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
Christoph Hellwig <hch@infradead.org> wrote:
>
> Btw, one more thing as you're probably sending the i_shared_sem re-
> spinlockification to Linus just about now: as we're renaming the thing
> anyway can we give it a less confusing name like i_mmap_lock? It's not
> been about shared mapping only for ages.
sure...
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 23:51 ` 2.6.6-mm1 Andrew Morton
2004-05-10 23:53 ` 2.6.6-mm1 Chris Wedgwood
@ 2004-05-11 6:18 ` Christoph Hellwig
1 sibling, 0 replies; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-11 6:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: Chris Wedgwood, hch, linux-kernel
> What I wish to do is to ensure that all users receive the *same* nasty
> workaround. Call it damage control.
It's not damage control. It increases the damage as we have to support
that hack now forever.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 0:14 ` 2.6.6-mm1 Andrew Morton
2004-05-11 0:24 ` 2.6.6-mm1 Wim Coekaerts
@ 2004-05-11 6:21 ` Christoph Hellwig
2004-05-11 6:37 ` 2.6.6-mm1 William Lee Irwin III
1 sibling, 1 reply; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-11 6:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: Chris Wedgwood, hch, linux-kernel
On Mon, May 10, 2004 at 05:14:13PM -0700, Andrew Morton wrote:
> Migrating away from this will require work from vendors, Oracle, PAM
> developers, /bin/login and /bin/su developers. Until that has happened I
> think we should arrange for vendor kernels and kernel.org kernels to offer
> the same interfaces.
>
> And I don't think pulling the feature out of kernel.org kernels will
> provide any added stimulus, frankly. They'll just ship the hack and go off
> to do something else.
>
> If someone had done the kernel and userspace work 6-12 months ago then
> sure, we wouldn't be in this situation.
Well, the question is why did those folks who care about it (Oracle it
seems) not do it 6-12 month ago?
This oh shit oracle needs it we need to come up with a hack mentality
sucks big time. If oracle (or $ISV/$IHV) they should send patches in
time so we can discuss it. In fact these patches don't even come from
Oracle but from Intel which shows something is seriously wrong with all
this.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 1:10 ` 2.6.6-mm1 Andrew Morton
2004-05-11 1:51 ` 2.6.6-mm1 Wim Coekaerts
@ 2004-05-11 6:22 ` Christoph Hellwig
1 sibling, 0 replies; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-11 6:22 UTC (permalink / raw)
To: Andrew Morton; +Cc: Wim Coekaerts, cw, linux-kernel
On Mon, May 10, 2004 at 06:10:08PM -0700, Andrew Morton wrote:
> > We have done the work and are going to be ok going forward to just use
> > hugeltbfs directly, just mounting it with right uid,gid. the main issue
>
> err, so why did I just merge the hugetlb_shm_group patch?
Because we're lacking communication?
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 1:51 ` 2.6.6-mm1 Wim Coekaerts
@ 2004-05-11 6:23 ` Christoph Hellwig
2004-05-12 2:44 ` 2.6.6-mm1 Andrea Arcangeli
2004-05-11 15:12 ` 2.6.6-mm1 Wim Coekaerts
1 sibling, 1 reply; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-11 6:23 UTC (permalink / raw)
To: Wim Coekaerts; +Cc: Andrew Morton, cw, linux-kernel
On Mon, May 10, 2004 at 06:51:18PM -0700, Wim Coekaerts wrote:
> > err, so why did I just merge the hugetlb_shm_group patch?
>
> because of what you mentioned. it takes a long time before that goes
> out, it's not even tested, and it doesn't apply to those 1000's of
> existing systems taht will break on upgrade. exactly what you said, it
> makes it possible to get to a different way smoothly in time. my
> comments were not "we can use it today".
So it's a hack for legacy oracle versions. nice. and for that we
introduce completely alien concepts like magic groups into the kernel..
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
[not found] ` <fa.gg699ad.b2omr9@ifi.uio.no>
@ 2004-05-11 6:33 ` Andy Lutomirski
0 siblings, 0 replies; 58+ messages in thread
From: Andy Lutomirski @ 2004-05-11 6:33 UTC (permalink / raw)
To: Chris Wright
Cc: Chris Wedgwood, Andrew Morton, Christoph Hellwig, linux-kernel
Chris Wright wrote:
> * Chris Wedgwood (cw@f00f.org) wrote:
>
>>On Mon, May 10, 2004 at 03:02:03PM -0700, Andrew Morton wrote:
>>
>>
>>>Capabilities are broken and don't work. Nobody has a clue how to
>>>provide the required services with SELinux and nobody has any code
>>>and we need the feature *now* before vendors go shipping even more
>>>ghastly stuff.
>>
>>eh? magic groups are nasty... and why is this needed? can't
>>oracle/whatever just run with a wrapper to give the capabilities out
>>as required until a better solution is available
>
>
> I agree. I have a patch that at least fixes this bit of capabilities
> (currently, what you suggest doesn't work right), which could easily be
> dusted off and resent.
I'll try and get my patch ready for testing soon. It got sidetracked by
the compute_creds race (erm... and my inability to fix it right the
first time).
Before I clean it up and rediff it, here's a question:
I would like to make the inheritable mask mean "these are the only
capabilities that this process or its children may ever hold." That
means tweaking setuid to disable itself if the inheritable mask is not
full to avoid auditing every setuid program ever written.. The benefit
is that cap_bset can be removed and securelevel can done sanely (by
adding a sysctl that means "setuid needs this set of capabilities"). It
also means that servers could drop inheritable caps, so, if they are
hacked, the attacker can't try to exploit setpcap / setuid /
(eventually) vfs caps. The downside is added complexity.
If I don't do that, I'm not quite sure what to do with the inheritable
mask. It seems to be only marginally useful.
Thoughts?
--Andy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 6:21 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-11 6:37 ` William Lee Irwin III
0 siblings, 0 replies; 58+ messages in thread
From: William Lee Irwin III @ 2004-05-11 6:37 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton, Chris Wedgwood, linux-kernel
On Mon, May 10, 2004 at 05:14:13PM -0700, Andrew Morton wrote:
>> If someone had done the kernel and userspace work 6-12 months ago then
>> sure, we wouldn't be in this situation.
On Tue, May 11, 2004 at 07:21:32AM +0100, Christoph Hellwig wrote:
> Well, the question is why did those folks who care about it (Oracle it
> seems) not do it 6-12 month ago?
> This oh shit oracle needs it we need to come up with a hack mentality
> sucks big time. If oracle (or $ISV/$IHV) they should send patches in
> time so we can discuss it. In fact these patches don't even come from
> Oracle but from Intel which shows something is seriously wrong with all
> this.
There were a combination of factors contributing to this, including
release-oriented efforts distracting ppl from 2.6 contributions,
disagreements outside kernel.org as to how to resolve this that
resulted in divergent solutions instead of any kind of agreement on a
solution, and so on.
IMHO the only opportunity for convergence etc. is this kind of flamewar
plus actual code rolling in atop it. I'm in the midst of some upheaval
(e.g. on the road plus having getting X running on laptop issues) so
please be patient while I get set up to write whatever code people want
to talk about for whatever alternative solutions they want implemented.
Thanks.
-- wli
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: 2.6.6-mm1
@ 2004-05-11 10:34 Sid Boyce
0 siblings, 0 replies; 58+ messages in thread
From: Sid Boyce @ 2004-05-11 10:34 UTC (permalink / raw)
To: linux-kernel
> Oops on x86_only, x86_64 is OK.
See previous post. The kernel boots when compiled with PREEMPT no set.
Also the nvidia video driver fails to build (4KSTACKS patch reversed),
with or without nvidia_agp and agpgart in the kernel. SuSE 9.1, nForce2
chipset and Athlon 2800+.
barrabas:/ftp/apr04 # gcc -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.3/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.3 (SuSE Linux)
-> Kernel source path: '/lib/modules/2.6.6-mm1/build'
-> Performing cc_version_check with CC="cc".
-> Cleaning kernel module build directory.
executing: 'cd ./usr/src/nv; make clean'...
rm -f -f nv.o os-agp.o os-interface.o os-registry.o nv.o os-agp.o
os-interfa
ce.o os-registry.o nvidia.mod.o
rm -f -f build-in.o nv-linux.o *.d .*.{cmd,flags}
rm -f -f nvidia.{o,ko,mod.{o,c}} nv_compiler.h *~
-> Building kernel module:
executing: 'cd ./usr/src/nv; make module
SYSSRC=/lib/modules/2.6.6-mm1/build
'...
echo \#define NV_COMPILER \"`cc -v 2>&1 | tail -n 1`\" >
/tmp/selfgz9194/NVI
DIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv_compiler.h
CC [M] /tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.o
In file included from include/linux/list.h:7,
from include/linux/wait.h:14,
from include/asm/semaphore.h:41,
from include/linux/sched.h:18,
from include/linux/module.h:10,
from
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src
/nv/nv-linux.h:52,
from
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src
/nv/nv.c:14:
include/linux/prefetch.h: In function `prefetch_range':
include/linux/prefetch.h:62: warning: pointer of type `void *' used
in arith
metic
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In
function
`nvos_malloc_pages':
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:385:
warning:
use of cast expressions as lvalues is deprecated
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In
function
`nvos_create_alloc':
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:513:
warning:
use of cast expressions as lvalues is deprecated
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:523:
warning:
use of cast expressions as lvalues is deprecated
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: At
top level
:
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1185:
warning
: initialization from incompatible pointer type
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In
function
`nv_alloc_file_private':
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1193:
warning
: use of cast expressions as lvalues is deprecated
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1204:
warning
: use of cast expressions as lvalues is deprecated
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In
function
`nv_kern_open':
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1265:
warning
: use of cast expressions as lvalues is deprecated
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In
function
`nv_kern_ctl_open':
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1914:
warning
: use of cast expressions as lvalues is deprecated
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: At
top level
:
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2010:
error:
conflicting types for `nv_set_hotkey_occurred_flag'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:350:
error: p
revious declaration of `nv_set_hotkey_occurred_flag'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2197:
error:
conflicting types for `nv_find_nv_mapping'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:339:
error: p
revious declaration of `nv_find_nv_mapping'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2269:
error:
conflicting types for `nv_find_agp_kernel_mapping'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:341:
error: p
revious declaration of `nv_find_agp_kernel_mapping'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2345:
error:
conflicting types for `nv_get_kern_phys_address'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:342:
error: p
revious declaration of `nv_get_kern_phys_address'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2375:
error:
conflicting types for `nv_get_user_phys_address'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:343:
error: p
revious declaration of `nv_get_user_phys_address'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2406:
error:
conflicting types for `nv_alloc_pages'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:353:
error: p
revious declaration of `nv_alloc_pages'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2594:
error:
conflicting types for `nv_free_pages'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:354:
error: p
revious declaration of `nv_free_pages'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2692:
error:
conflicting types for `nv_lock_rm'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:345:
error: p
revious declaration of `nv_lock_rm'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2712:
error:
conflicting types for `nv_unlock_rm'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:346:
error: p
revious declaration of `nv_unlock_rm'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2726:
error:
conflicting types for `nv_lock_heap'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:347:
error: p
revious declaration of `nv_lock_heap'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2736:
error:
conflicting types for `nv_unlock_heap'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:348:
error: p
revious declaration of `nv_unlock_heap'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2752:
error:
conflicting types for `nv_post_event'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:363:
error: p
revious declaration of `nv_post_event'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2790:
error:
conflicting types for `nv_get_event'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:364:
error: p
revious declaration of `nv_get_event'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2833:
error:
conflicting types for `nv_agp_init'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:356:
error: p
revious declaration of `nv_agp_init'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2895:
error:
conflicting types for `nv_agp_teardown'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:357:
error: p
revious declaration of `nv_agp_teardown'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2936:
error:
conflicting types for `nv_agp_translate_address'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:358:
error: p
revious declaration of `nv_agp_translate_address'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2968:
error:
conflicting types for `nv_int10h_call'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:351:
error: p
revious declaration of `nv_int10h_call'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2977:
error:
conflicting types for `nv_start_rc_timer'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:360:
error: p
revious declaration of `nv_start_rc_timer'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2998:
error:
conflicting types for `nv_stop_rc_timer'
/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:361:
error: p
revious declaration of `nv_stop_rc_timer'
make[3]: ***
[/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.o
] Error 1
make[2]: ***
[/tmp/selfgz9194/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv] Err
or 2
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2
-> Error.
ERROR: Unable to build the NVIDIA kernel module.
ERROR: Installation has failed. Please see the file
'/var/log/nvidia-installer.log' for details. You may find
suggestions
on fixing installation problems in the README available on the Linux
driver download page at www.nvidia.com.
Regards
Sid.
--
Sid Boyce .... Hamradio G3VBV and keen Flyer
Linux Only Shop.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 21:37 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 22:02 ` 2.6.6-mm1 Andrew Morton
@ 2004-05-11 14:34 ` Stephen Smalley
2004-05-11 16:48 ` 2.6.6-mm1 Chris Wright
1 sibling, 1 reply; 58+ messages in thread
From: Stephen Smalley @ 2004-05-11 14:34 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Andrew Morton, lkml, Chris Wright
On Mon, 2004-05-10 at 17:37, Christoph Hellwig wrote:
> > +hugetlb_shm_group-sysctl-patch.patch
> >
> > Add /proc/sys/vm/hugetlb_shm_group: this holds the group ID of users who may
> > allocate hugetlb shm segments without CAP_IPC_LOCK. For Oracle.
> >
> > +mlock_group-sysctl.patch
> >
> > /proc/sys/vm/mlock_group: group ID of users who can do mlock() without
> > CAP_IPC_LOCK. Not sure that we need this.
>
> These two just introduced a subtile behaviour change during stable series,
> possibly (not likely) leading to DoS opportunities from applications running
> as gid 0. Really, with capabilities first and now selinux we have moved
> away from treating uid 0 special, so introducing special casing of a gid
> now is more than just braindead.
Is there anything that would prevent these two patches from being
re-implemented as a LSM module, replacing the can_do_mlock and
can_do_hugetlb_shm functions with security hook calls? They seem like
perfect candidates for security hook calls and keeping security logic
out of the core kernel. Chris, what do you think?
--
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
@ 2004-05-11 14:49 Neil Schemenauer
2004-05-11 18:55 ` 2.6.6-mm1 Andrew Morton
0 siblings, 1 reply; 58+ messages in thread
From: Neil Schemenauer @ 2004-05-11 14:49 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
[Andrew Morton]
> Has been discussed on this list. It requires worrisome changes to
> the capability system, changes to PAM, changes to login and
> changes to applications.
Have you seen my capwrap[1] module? I wouldn't call it elegant but
it is very simple and flexible.
Neil
1. http://marc.theaimsgroup.com/?l=linux-kernel&m=108143257710466&w=2
[-- Attachment #2: binfmt_capwrap.c --]
[-- Type: text/x-csrc, Size: 2634 bytes --]
/*
* linux/fs/binfmt_capwrap.c
*
* Copyright (C) 2002 Neil Schemenauer
*/
#include <linux/module.h>
#include <linux/string.h>
#include <linux/kernel.h>
#include <linux/stat.h>
#include <linux/slab.h>
#include <linux/binfmts.h>
#include <linux/init.h>
#include <linux/file.h>
#include <linux/smp_lock.h>
#include <linux/mount.h>
#include <linux/fs.h>
static int parse_cap(char **cp, unsigned int *cap)
{
char *tok, *endp;
int n;
if ((tok = strsep(cp, " \t")) == NULL)
return 0;
n = simple_strtol(tok, &endp, 16);
if (*endp != '\0')
return 0;
*cap = n;
return 1;
}
static void grant_capabilities(struct linux_binprm *bprm, unsigned int caps)
{
/* This may have to be more complicated if the kernel
* representation of capabilities changes. Right now it's trivial.
*/
bprm->cap_effective |= caps;
bprm->cap_permitted |= caps;
}
static int load_capwrap(struct linux_binprm *bprm, struct pt_regs *regs)
{
struct inode * inode = bprm->file->f_dentry->d_inode;
int mode = inode->i_mode;
char exec_name[BINPRM_BUF_SIZE];
char *cp, *tok;
unsigned int caps = 0;
struct file *file;
int retval;
/* must have magic */
if ((bprm->buf[0] != '&'))
return -ENOEXEC;
/* must be owned by root */
if (inode->i_uid != 0)
return -ENOEXEC;
/* must be SUID */
if ((bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) ||
!(mode & S_ISUID))
return -ENOEXEC;
/*
* Okay, parse the wrapper.
*/
allow_write_access(bprm->file);
fput(bprm->file);
bprm->file = NULL;
/* terminate first line */
bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
if ((cp = strchr(bprm->buf, '\n')) == NULL)
cp = bprm->buf+BINPRM_BUF_SIZE-1;
*cp = '\0';
/* name */
cp = bprm->buf+1;
if ((tok = strsep(&cp, " \t")) == NULL)
return -ENOEXEC;
strcpy(exec_name, tok);
/* capabilities to add */
if (!parse_cap(&cp, &caps))
return -ENOEXEC;
/*
* Restart the process with real executable's dentry.
*/
file = open_exec(exec_name);
if (IS_ERR(file))
return PTR_ERR(file);
bprm->file = file;
retval = prepare_binprm(bprm);
if (retval < 0)
return retval;
grant_capabilities(bprm, caps);
printk(KERN_DEBUG "capwrap: granted %s %x effective now %x\n",
exec_name, caps, bprm->cap_effective);
return search_binary_handler(bprm, regs);
}
struct linux_binfmt capwrap_format = {
.module = THIS_MODULE,
.load_binary = load_capwrap,
};
static int __init init_capwrap_binfmt(void)
{
return register_binfmt(&capwrap_format);
}
static void __exit exit_capwrap_binfmt(void)
{
unregister_binfmt(&capwrap_format);
}
module_init(init_capwrap_binfmt)
module_exit(exit_capwrap_binfmt)
MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 1:51 ` 2.6.6-mm1 Wim Coekaerts
2004-05-11 6:23 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-11 15:12 ` Wim Coekaerts
2004-05-12 5:42 ` 2.6.6-mm1 Christoph Hellwig
1 sibling, 1 reply; 58+ messages in thread
From: Wim Coekaerts @ 2004-05-11 15:12 UTC (permalink / raw)
To: hch; +Cc: Andrew Morton, cw, linux-kernel
oh and for what it's worth, I didn't like the shmgid solution either, I
brought up rlmits first iirc. if there is something better great, but as
that was not going anywhere and this is...
let's see if wli can make things work correctly with physdical pages
with rlmits and go from there.
Wim
On Mon, May 10, 2004 at 06:51:18PM -0700, Wim Coekaerts wrote:
> > >
> > > > Migrating away from this will require work from vendors, Oracle, PAM
> > > > developers, /bin/login and /bin/su developers. Until that has happened I
> > > > think we should arrange for vendor kernels and kernel.org kernels to offer
> > > > the same interfaces.
> > >
> > > We have done the work and are going to be ok going forward to just use
> > > hugeltbfs directly, just mounting it with right uid,gid. the main issue
> >
> > err, so why did I just merge the hugetlb_shm_group patch?
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 14:34 ` 2.6.6-mm1 Stephen Smalley
@ 2004-05-11 16:48 ` Chris Wright
0 siblings, 0 replies; 58+ messages in thread
From: Chris Wright @ 2004-05-11 16:48 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Christoph Hellwig, Andrew Morton, lkml, Chris Wright
* Stephen Smalley (sds@epoch.ncsc.mil) wrote:
> On Mon, 2004-05-10 at 17:37, Christoph Hellwig wrote:
> > > +hugetlb_shm_group-sysctl-patch.patch
> > >
> > > Add /proc/sys/vm/hugetlb_shm_group: this holds the group ID of users who may
> > > allocate hugetlb shm segments without CAP_IPC_LOCK. For Oracle.
> > >
> > > +mlock_group-sysctl.patch
> > >
> > > /proc/sys/vm/mlock_group: group ID of users who can do mlock() without
> > > CAP_IPC_LOCK. Not sure that we need this.
> >
> > These two just introduced a subtile behaviour change during stable series,
> > possibly (not likely) leading to DoS opportunities from applications running
> > as gid 0. Really, with capabilities first and now selinux we have moved
> > away from treating uid 0 special, so introducing special casing of a gid
> > now is more than just braindead.
>
> Is there anything that would prevent these two patches from being
> re-implemented as a LSM module, replacing the can_do_mlock and
> can_do_hugetlb_shm functions with security hook calls? They seem like
> perfect candidates for security hook calls and keeping security logic
> out of the core kernel. Chris, what do you think?
Hrm, it's certainly doable. Not sure if it would help or clutter the
issue. /me ponders that one...
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 14:49 2.6.6-mm1 Neil Schemenauer
@ 2004-05-11 18:55 ` Andrew Morton
0 siblings, 0 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-11 18:55 UTC (permalink / raw)
To: Neil Schemenauer; +Cc: linux-kernel
Neil Schemenauer <nas@arctrix.com> wrote:
>
> Have you seen my capwrap[1] module? I wouldn't call it elegant but
> it is very simple and flexible.
It is.
But if the application which you run does execve(), the capabilties are
dropped. And if it does setuid() without first doing
prctl(PR_SET_KEEPCAPS, 1);
then setuid() also drops capabilities.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 6:23 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-12 2:44 ` Andrea Arcangeli
2004-05-12 5:11 ` 2.6.6-mm1 Chris Wedgwood
0 siblings, 1 reply; 58+ messages in thread
From: Andrea Arcangeli @ 2004-05-12 2:44 UTC (permalink / raw)
To: Christoph Hellwig, Wim Coekaerts, Andrew Morton, cw, linux-kernel
On Tue, May 11, 2004 at 07:23:29AM +0100, Christoph Hellwig wrote:
> On Mon, May 10, 2004 at 06:51:18PM -0700, Wim Coekaerts wrote:
> > > err, so why did I just merge the hugetlb_shm_group patch?
> >
> > because of what you mentioned. it takes a long time before that goes
> > out, it's not even tested, and it doesn't apply to those 1000's of
> > existing systems taht will break on upgrade. exactly what you said, it
> > makes it possible to get to a different way smoothly in time. my
> > comments were not "we can use it today".
>
> So it's a hack for legacy oracle versions. nice. and for that we
> introduce completely alien concepts like magic groups into the kernel..
I don't see why we're trying to complicate the simple things.
I posted a disable_cap_mlock patch several weeks ago, that's the only
needed thing.
Even if there's an attacker on the machine with disable_cap_mlock == 1,
the attacker won't be able to exploit anything, it can only generate a
DoS. The cap-mlock is clearly not nearly as security-critical as most
other capabilities.
There's no reason to get the "hack" any smarter than the disable_cap_mlock
approch, any sysctl will be still an hack anyways. The group thing and
the differentiation between hugetlbfs users and mlock users (like
SHM_LOCK) is a mere attempt to make it more secure, but if you can
change the disable_cap_mlock sysctl from 0 to 1 you for sure can also
change the hugetlb_shm_group from 0 to 500 and the same for the
mlock_group too. Plus I can want to give mlock to the whole system at
the same time, not just to a single group, and for that
disable_cap_mlock is appropriate.
I'm quite confortable to say that disable_cap_mlock can be dropped in
2.8, by that time a replacement solution will be implemented and I don't
expect any application learning about the disable_cap_mlock name, they
really shouldn't, only the bootup procedure of the OS will know about it
and only the login/su will learn about the future replacement.
So I believe the best "hack" is to use the simple disable_cap_mlock and
to concentrate all the efforts on a more flexible solution involving
userspace changes. The one suggested by Andrew by simply dropping the
capabilities in login and su sounded very appealing to me.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-12 2:44 ` 2.6.6-mm1 Andrea Arcangeli
@ 2004-05-12 5:11 ` Chris Wedgwood
0 siblings, 0 replies; 58+ messages in thread
From: Chris Wedgwood @ 2004-05-12 5:11 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Christoph Hellwig, Wim Coekaerts, Andrew Morton, linux-kernel
On Wed, May 12, 2004 at 04:44:25AM +0200, Andrea Arcangeli wrote:
> I'm quite confortable to say that disable_cap_mlock can be dropped
> in 2.8
Cool.
> by that time a replacement solution will be implemented and
> I don't expect any application learning about the disable_cap_mlock
> name, they really shouldn't, only the bootup procedure of the OS
> will know about it and only the login/su will learn about the future
> replacement.
Agreed. It's hack but it's a simpler hack.
> So I believe the best "hack" is to use the simple disable_cap_mlock
> and to concentrate all the efforts on a more flexible solution
> involving userspace changes.
I quite agree here too. I guess as things stand right now I'll take
either approach IFF it will be yanked in 2.7.x when a better
replacement is available.
--cw
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-11 15:12 ` 2.6.6-mm1 Wim Coekaerts
@ 2004-05-12 5:42 ` Christoph Hellwig
2004-05-12 5:50 ` 2.6.6-mm1 Christoph Hellwig
0 siblings, 1 reply; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-12 5:42 UTC (permalink / raw)
To: Wim Coekaerts, torvalds; +Cc: hch, Andrew Morton, cw, linux-kernel
On Tue, May 11, 2004 at 08:12:07AM -0700, Wim Coekaerts wrote:
> oh and for what it's worth, I didn't like the shmgid solution either, I
> brought up rlmits first iirc. if there is something better great, but as
> that was not going anywhere and this is...
>
> let's see if wli can make things work correctly with physdical pages
> with rlmits and go from there.
Okay, so can we please remove the half-backed non-soloutions from the
tree now? Aka, Linus please cset -x
'[PATCH] Add sysctl to define a hugetlb-capable group', current cset num
in the tree is 1.1608.6.126
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-12 5:42 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-12 5:50 ` Christoph Hellwig
0 siblings, 0 replies; 58+ messages in thread
From: Christoph Hellwig @ 2004-05-12 5:50 UTC (permalink / raw)
To: Christoph Hellwig, Wim Coekaerts, torvalds, Andrew Morton, cw,
linux-kernel
torvalds@transmeta.com, yodda, yodda, alzheimer..
On Wed, May 12, 2004 at 06:42:53AM +0100, Christoph Hellwig wrote:
> On Tue, May 11, 2004 at 08:12:07AM -0700, Wim Coekaerts wrote:
> > oh and for what it's worth, I didn't like the shmgid solution either, I
> > brought up rlmits first iirc. if there is something better great, but as
> > that was not going anywhere and this is...
> >
> > let's see if wli can make things work correctly with physdical pages
> > with rlmits and go from there.
>
> Okay, so can we please remove the half-backed non-soloutions from the
> tree now? Aka, Linus please cset -x
>
> '[PATCH] Add sysctl to define a hugetlb-capable group', current cset num
> in the tree is 1.1608.6.126
>
---end quoted text---
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 12:43 2.6.6-mm1 Sid Boyce
@ 2004-05-12 8:13 ` Andrew Morton
0 siblings, 0 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-12 8:13 UTC (permalink / raw)
To: sboyce; +Cc: linux-kernel
Sid Boyce <sboyce@blueyonder.co.uk> wrote:
>
> Oops on x86_only, x86_64 is OK.
>
> ...
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> printing eip:
> c0163921
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT DEBUG_PAGEALLOC
> CPU: 0
> EIP: 0060:[<c0163921>] Not tainted VLI
> EFLAGS: 00010296 (2.6.6-mm1)
> EIP is at locks_alloc_lock+0x1/0x20
> eax: de016f6c ebx: bffff1e0 ecx: bffff1e0 edx: 00000007
> esi: bffff1e0 edi: 00000000 ebp: dff7bf90 esp: dff7bf34
> ds: 007b es: 007b ss: 0068
> Process init (pid: 1, threadinfo=dff7b000 task=dff7ca70)
> Stack: dff7bf90 c0165856 00000000 00000246 fffbd13f fffbd13f 00000007 de016f6c
> dff7bf94 c011a52c ffffffff 000001ff bffff008 fa49babf 00000000 003fffff
> 00000000 fffbd13f dff7bf9c dff7bfac bffff1e0 ffffffea 00000000 dff7bfa4
> Call Trace:
> [<c01061e6>] show_stack+0xa6/0xb0
> [<c0106358>] show_registers+0x148/0x1c0
> [<c0106505>] die+0xa5/0x110
> [<c0112682>] do_page_fault+0x3b2/0x538
> [<c0105e55>] error_code+0x2d/0x38
> [<c01618a5>] generic_file_fcntl+0xd5/0x1e0
> [<c0161ae0>] sys_fcntl64+0x80/0xa0
> [<c0105c4b>] syscall_call+0x7/0xb
Is this repeatable? A null-pointer deref at
locks_alloc_lock+0x1/0x20 seems not possible.
Please send the output of
nm -n vmlinux | grep -5 locks_alloc_lock
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: 2.6.6-mm1
@ 2004-05-12 12:26 Sid Boyce
0 siblings, 0 replies; 58+ messages in thread
From: Sid Boyce @ 2004-05-12 12:26 UTC (permalink / raw)
To: linux-kernel
Andrew Morton wrote:
> Is this repeatable? A null-pointer deref at
> locks_alloc_lock+0x1/0x20 seems not possible.
>
> Please send the output of
>
> nm -n vmlinux | grep -5 locks_alloc_lock
I only tried booting the kernel once, shall have another go later and
gather some other traces if it fails.
barrabas:/usr/src/linux-2.6.6-mm1 # nm -n vmlinux | grep -5 locks_alloc_lock
c015b4e0 T sys_poll
c015b730 t wait_for_partner
c015b770 t wake_up_partner
c015b7a0 t fifo_open
c015ba56 t .text.lock.fifo
c015ba80 t locks_alloc_lock
c015baa0 T locks_init_lock
c015bb20 t init_once
c015bb40 T locks_copy_lock
c015bbb0 t flock_make_lock
c015bc50 t assign_type
Regards
Sid.
--
Sid Boyce .... Hamradio G3VBV and keen Flyer
Linux Only Shop.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-10 9:45 2.6.6-mm1 Andrew Morton
` (3 preceding siblings ...)
2004-05-10 21:37 ` 2.6.6-mm1 Christoph Hellwig
@ 2004-05-12 12:49 ` Sean Neakums
2004-05-12 19:26 ` 2.6.6-mm1 Andrew Morton
4 siblings, 1 reply; 58+ messages in thread
From: Sean Neakums @ 2004-05-12 12:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: vojtech, linux-kernel
Andrew Morton <akpm@osdl.org> writes:
> psmouse-fix-mouse-hotplugging.patch
> psmouse: fix mouse hotplugging
This change seems to cause psmouse.proto=bare to no longer work as a
way of disabling the passthrough port on my laptop's Synaptics touchpad.
However, the effect is not the same as omitting it entirely; I don't
see a separate entry for the trackpoint[1] in /proc/bus/input/devices.
[1] Faulty trackpoint, in my case.
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: 2.6.6-mm1
@ 2004-05-12 15:27 Sid Boyce
0 siblings, 0 replies; 58+ messages in thread
From: Sid Boyce @ 2004-05-12 15:27 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
Second rebuild is OK.
barrabas:/usr/src/linux-2.6.6-mm1 # nm -n vmlinux | grep -5 locks_alloc_lock
c0163250 T sys_poll
c01634a0 t wait_for_partner
c01634e0 t wake_up_partner
c0163510 t fifo_open
c01637c6 t .text.lock.fifo
c01637f0 t locks_alloc_lock
c0163810 T locks_init_lock
c0163890 t init_once
c01638b0 T locks_copy_lock
c0163920 t flock_make_lock
c01639c0 t assign_type
The nvidia 5336 driver fails to build.
Regards
Sid.
--
Sid Boyce .... Hamradio G3VBV and keen Flyer
Linux Only Shop.
[-- Attachment #2: nvidia-installer.log --]
[-- Type: text/plain, Size: 10095 bytes --]
nvidia-installer log file '/var/log/nvidia-installer.log'
creation time: Wed May 12 16:20:05 2004
option status:
license pre-accepted : false
update : false
force update : false
expert : false
uninstall : false
driver info : false
no precompiled interface: false
no ncurses color : false
query latest driver ver : false
OpenGL header files : false
no questions : false
silent : false
XFree86 install prefix : /usr/X11R6
OpenGL install prefix : /usr
Installer install prefix: /usr
kernel source path : (not specified)
kernel install path : (not specified)
proc mount point : /proc
ui : (not specified)
tmpdir : /tmp
ftp site : ftp://download.nvidia.com
Using: nvidia-installer ncurses user interface
-> License accepted.
-> There appears to already be a driver installed on your system (version: 1.0-
5336). As part of installing this driver (version: 1.0-5336), the existing
driver will be uninstalled. Are you sure you want to continue? ('no' will a
bort installation) (Answer: Yes)
-> No precompiled kernel interface was found to match your kernel; would you li
ke the installer to attempt to download a kernel interface for your kernel f
rom the NVIDIA ftp site (ftp://download.nvidia.com)? (Answer: Yes)
-> No matching precompiled kernel interface was found on the NVIDIA ftp site;
this means that the installer will need to compile a kernel interface for
your kernel.
-> Kernel source path: '/lib/modules/2.6.6-mm1/build'
-> Performing cc_version_check with CC="cc".
-> Cleaning kernel module build directory.
executing: 'cd ./usr/src/nv; make clean'...
rm -f -f nv.o os-agp.o os-interface.o os-registry.o nv.o os-agp.o os-interfa
ce.o os-registry.o nvidia.mod.o
rm -f -f build-in.o nv-linux.o *.d .*.{cmd,flags}
rm -f -f nvidia.{o,ko,mod.{o,c}} nv_compiler.h *~
-> Building kernel module:
executing: 'cd ./usr/src/nv; make module SYSSRC=/lib/modules/2.6.6-mm1/build
'...
echo \#define NV_COMPILER \"`cc -v 2>&1 | tail -n 1`\" > /tmp/selfgz19415/NV
IDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv_compiler.h
CC [M] /tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.o
In file included from include/linux/list.h:7,
from include/linux/wait.h:14,
from include/asm/semaphore.h:41,
from include/linux/sched.h:18,
from include/linux/module.h:10,
from /tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/sr
c/nv/nv-linux.h:52,
from /tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/sr
c/nv/nv.c:14:
include/linux/prefetch.h: In function `prefetch_range':
include/linux/prefetch.h:62: warning: pointer of type `void *' used in arith
metic
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In function
`nvos_malloc_pages':
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:385: warning
: use of cast expressions as lvalues is deprecated
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In function
`nvos_create_alloc':
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:513: warning
: use of cast expressions as lvalues is deprecated
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:523: warning
: use of cast expressions as lvalues is deprecated
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: At top leve
l:
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1185: warnin
g: initialization from incompatible pointer type
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In function
`nv_alloc_file_private':
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1193: warnin
g: use of cast expressions as lvalues is deprecated
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1204: warnin
g: use of cast expressions as lvalues is deprecated
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In function
`nv_kern_open':
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1265: warnin
g: use of cast expressions as lvalues is deprecated
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: In function
`nv_kern_ctl_open':
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:1914: warnin
g: use of cast expressions as lvalues is deprecated
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c: At top leve
l:
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2010: error:
conflicting types for `nv_set_hotkey_occurred_flag'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:350: error:
previous declaration of `nv_set_hotkey_occurred_flag'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2197: error:
conflicting types for `nv_find_nv_mapping'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:339: error:
previous declaration of `nv_find_nv_mapping'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2269: error:
conflicting types for `nv_find_agp_kernel_mapping'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:341: error:
previous declaration of `nv_find_agp_kernel_mapping'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2345: error:
conflicting types for `nv_get_kern_phys_address'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:342: error:
previous declaration of `nv_get_kern_phys_address'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2375: error:
conflicting types for `nv_get_user_phys_address'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:343: error:
previous declaration of `nv_get_user_phys_address'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2406: error:
conflicting types for `nv_alloc_pages'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:353: error:
previous declaration of `nv_alloc_pages'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2594: error:
conflicting types for `nv_free_pages'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:354: error:
previous declaration of `nv_free_pages'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2692: error:
conflicting types for `nv_lock_rm'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:345: error:
previous declaration of `nv_lock_rm'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2712: error:
conflicting types for `nv_unlock_rm'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:346: error:
previous declaration of `nv_unlock_rm'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2726: error:
conflicting types for `nv_lock_heap'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:347: error:
previous declaration of `nv_lock_heap'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2736: error:
conflicting types for `nv_unlock_heap'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:348: error:
previous declaration of `nv_unlock_heap'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2752: error:
conflicting types for `nv_post_event'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:363: error:
previous declaration of `nv_post_event'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2790: error:
conflicting types for `nv_get_event'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:364: error:
previous declaration of `nv_get_event'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2833: error:
conflicting types for `nv_agp_init'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:356: error:
previous declaration of `nv_agp_init'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2895: error:
conflicting types for `nv_agp_teardown'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:357: error:
previous declaration of `nv_agp_teardown'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2936: error:
conflicting types for `nv_agp_translate_address'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:358: error:
previous declaration of `nv_agp_translate_address'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2968: error:
conflicting types for `nv_int10h_call'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:351: error:
previous declaration of `nv_int10h_call'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2977: error:
conflicting types for `nv_start_rc_timer'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:360: error:
previous declaration of `nv_start_rc_timer'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.c:2998: error:
conflicting types for `nv_stop_rc_timer'
/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.h:361: error:
previous declaration of `nv_stop_rc_timer'
make[3]: *** [/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv/nv.
o] Error 1
make[2]: *** [/tmp/selfgz19415/NVIDIA-Linux-x86-1.0-5336-pkg1/usr/src/nv] Er
ror 2
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2
-> Error.
ERROR: Unable to build the NVIDIA kernel module.
ERROR: Installation has failed. Please see the file
'/var/log/nvidia-installer.log' for details. You may find suggestions
on fixing installation problems in the README available on the Linux
driver download page at www.nvidia.com.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: 2.6.6-mm1
2004-05-12 12:49 ` 2.6.6-mm1 Sean Neakums
@ 2004-05-12 19:26 ` Andrew Morton
0 siblings, 0 replies; 58+ messages in thread
From: Andrew Morton @ 2004-05-12 19:26 UTC (permalink / raw)
To: Sean Neakums; +Cc: vojtech, linux-kernel, Kim Holviala
Sean Neakums <sneakums@zork.net> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
>
> > psmouse-fix-mouse-hotplugging.patch
> > psmouse: fix mouse hotplugging
>
> This change seems to cause psmouse.proto=bare to no longer work as a
> way of disabling the passthrough port on my laptop's Synaptics touchpad.
OK, thanks. I'll drop it.
This patch fixes hotplugging of PS/2 devices on hardware which don't
support hotplugging of PS/2 devices. In other words, most desktop
machines.
---
25-akpm/drivers/input/mouse/psmouse-base.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/input/mouse/psmouse-base.c~psmouse-fix-mouse-hotplugging drivers/input/mouse/psmouse-base.c
--- 25/drivers/input/mouse/psmouse-base.c~psmouse-fix-mouse-hotplugging 2004-05-08 13:13:40.636484424 -0700
+++ 25-akpm/drivers/input/mouse/psmouse-base.c 2004-05-08 13:13:40.640483816 -0700
@@ -470,7 +470,7 @@ static int psmouse_probe(struct psmouse
* Then we reset and disable the mouse so that it doesn't generate events.
*/
- if (psmouse_command(psmouse, NULL, PSMOUSE_CMD_RESET_DIS))
+ if (psmouse_reset(psmouse))
printk(KERN_WARNING "psmouse.c: Failed to reset mouse on %s\n", psmouse->serio->phys);
/*
_
^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2004-05-12 19:33 UTC | newest]
Thread overview: 58+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-12 12:26 2.6.6-mm1 Sid Boyce
-- strict thread matches above, loose matches on Subject: below --
2004-05-12 15:27 2.6.6-mm1 Sid Boyce
2004-05-11 14:49 2.6.6-mm1 Neil Schemenauer
2004-05-11 18:55 ` 2.6.6-mm1 Andrew Morton
2004-05-11 10:34 2.6.6-mm1 Sid Boyce
[not found] <fa.j4d62qo.1144tpk@ifi.uio.no>
[not found] ` <fa.gg699ad.b2omr9@ifi.uio.no>
2004-05-11 6:33 ` 2.6.6-mm1 Andy Lutomirski
2004-05-10 16:50 2.6.6-mm1 Sid Boyce
2004-05-10 12:43 2.6.6-mm1 Sid Boyce
2004-05-12 8:13 ` 2.6.6-mm1 Andrew Morton
2004-05-10 9:45 2.6.6-mm1 Andrew Morton
2004-05-10 10:52 ` 2.6.6-mm1 Dominik Karall
2004-05-10 11:18 ` 2.6.6-mm1 Dave Jones
2004-05-10 12:20 ` 2.6.6-mm1 Nick Piggin
2004-05-10 12:22 ` 2.6.6-mm1 Dave Jones
2004-05-10 14:38 ` 2.6.6-mm1 Norberto Bensa
2004-05-10 14:55 ` 2.6.6-mm1 Dominik Karall
2004-05-10 15:02 ` 2.6.6-mm1 Norberto Bensa
2004-05-10 15:22 ` 2.6.6-mm1 Dominik Karall
2004-05-10 15:33 ` 2.6.6-mm1 Norberto Bensa
2004-05-10 15:20 ` 2.6.6-mm1 Christoph Hellwig
2004-05-11 5:21 ` 2.6.6-mm1 Andrew Morton
2004-05-10 21:37 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 22:02 ` 2.6.6-mm1 Andrew Morton
2004-05-10 22:05 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 22:15 ` 2.6.6-mm1 Andrew Morton
2004-05-10 22:20 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 22:47 ` 2.6.6-mm1 Andrew Morton
2004-05-10 22:48 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 23:16 ` 2.6.6-mm1 Matt Mackall
2004-05-10 22:27 ` 2.6.6-mm1 Valdis.Kletnieks
2004-05-10 22:48 ` 2.6.6-mm1 Andrew Morton
2004-05-10 23:01 ` 2.6.6-mm1 Valdis.Kletnieks
2004-05-10 23:11 ` 2.6.6-mm1 Chris Wedgwood
2004-05-10 23:14 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 23:28 ` 2.6.6-mm1 Andrew Morton
2004-05-10 23:33 ` 2.6.6-mm1 Chris Wedgwood
2004-05-10 23:51 ` 2.6.6-mm1 Andrew Morton
2004-05-10 23:53 ` 2.6.6-mm1 Chris Wedgwood
2004-05-11 0:14 ` 2.6.6-mm1 Andrew Morton
2004-05-11 0:24 ` 2.6.6-mm1 Wim Coekaerts
2004-05-11 1:10 ` 2.6.6-mm1 Andrew Morton
2004-05-11 1:51 ` 2.6.6-mm1 Wim Coekaerts
2004-05-11 6:23 ` 2.6.6-mm1 Christoph Hellwig
2004-05-12 2:44 ` 2.6.6-mm1 Andrea Arcangeli
2004-05-12 5:11 ` 2.6.6-mm1 Chris Wedgwood
2004-05-11 15:12 ` 2.6.6-mm1 Wim Coekaerts
2004-05-12 5:42 ` 2.6.6-mm1 Christoph Hellwig
2004-05-12 5:50 ` 2.6.6-mm1 Christoph Hellwig
2004-05-11 6:22 ` 2.6.6-mm1 Christoph Hellwig
2004-05-11 6:21 ` 2.6.6-mm1 Christoph Hellwig
2004-05-11 6:37 ` 2.6.6-mm1 William Lee Irwin III
2004-05-11 6:18 ` 2.6.6-mm1 Christoph Hellwig
2004-05-10 23:33 ` 2.6.6-mm1 Chris Wright
2004-05-11 1:59 ` 2.6.6-mm1 Matt Mackall
2004-05-11 14:34 ` 2.6.6-mm1 Stephen Smalley
2004-05-11 16:48 ` 2.6.6-mm1 Chris Wright
2004-05-12 12:49 ` 2.6.6-mm1 Sean Neakums
2004-05-12 19:26 ` 2.6.6-mm1 Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).