linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).