ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc1/2.6.6-rc1-mm1/
- All of the anonmm rmap work is now merged up. No pte chains.
- Various cleanups and fixups, as usual.
- The list of external bk trees is getting a little short, due to problems
at bkbits.net. The ones which are here are not necessarily very up-to-date
with the various development trees.
Changes since 2.6.5-mm6:
linus.patch
bk-acpi.patch
bk-agpgart.patch
bk-alsa.patch
bk-cifs.patch
bk-cpufreq.patch
bk-drm.patch
bk-input.patch
bk-netdev.patch
External trees
-fix-mq_notify-with-sigev_none-notification.patch
-radix-tree-comment-fix.patch
-mq_open-and-close_on_exec.patch
-rmap-4-flush_dcache-revisited.patch
-rmap-5-swap_unplug-page.patch
-rmap-6-nonlinear-truncation.patch
-ext3-journalled-quotas.patch
-slab-panic.patch
-dm-fix-64-32-bit-ioctl-problems.patch
-dm-check-the-uptodate-flag-in-sub-bios.patch
-dm-handle-interrupts-within-suspend.patch
-dm-use-wake_up-rather-than-wake_up_interruptible.patch
-dm-log-an-error-if-the-target-has-unknown-target-type.patch
-dm-correctly-align-the-dm_target_spec-structures.patch
-dm-clarify-a-comment.patch
-dm-retrieve_status-prevent-overrunning-the-ioctl-buffer.patch
-dm-use-an-emit-macro.patch
-kNFSdv4-4-of-10-nfsd4_readdir-fixes.patch
-kNFSdv4-5-of-10-Fix-bad-error-returm-from-svcauth_gss_accept.patch
-kNFSdv4-6-of-10-Keep-state-to-allow-replays-for-close-to-work.patch
-kNFSdv4-7-of-10-Allow-locku-replays-aswell.patch
-kNFSdv4-8-of-10-Improve-how-locking-copes-with-replays.patch
-kNFSdv4-9-of-10-Set-credentials-properly-when-puutrootfh-is-used.patch
-kNFSdv4-10-of-10-Implement-server-side-reboot-recovery-mostly.patch
-kill-submit_bhbio-return-value.patch
-pci-msi-kconfig-consolidation.patch
-remove-buffer_error.patch
-add-mqueue-support-to-x86-64.patch
-light-weight-auditing-framework-for-s390.patch
-posix-messages-queues-for-s390.patch
-ppc64-fix-possible-duplicate-mmu-hash-entries.patch
-fix-mq-32-bit-compatibility.patch
-reiserfs-commit-default.patch
-jbd-journal_dirty_metadata-locking-speedup.patch
-sctp-printk-warnings.patch
-atm-warning-fixes.patch
-sir_dev-warnings.patch
-donauboe-ptr-fix.patch
-strip-warnings.patch
-strip-warnings-2.patch
-print-warning-for-common-symbols-in-modules.patch
-set_anon_super-locking-fix.patch
Merged
-kstrdup-and-friends.patch
-call_usermodehelper_async.patch
-call_usermodehelper_async-always.patch
Dropped, replaced with...
+create_singlethread_workqueue.patch
Extend workqueues so they don't unconditionally create one thread per cpu.
(They still display as "khelper/0" in ps though..)
+use-workqueue-for-call_usermodehelper.patch
Use single-threaded workqueues for call_usermodehelper()
+ppc64-rtas-build-fix.patch
ppc64 compile fix
+rmap-7-object-based-rmap.patch
+ia64-rmap-build-fix.patch
+rmap-8-unmap-nonlinear.patch
+slab-panic.patch
+rmap-9-remove-pte_chains.patch
+rmap-10-add-anonmm-rmap.patch
+rmap-11-mremap-moves.patch
+rmap-12-pgtable-remove-rmap.patch
+rmap-13-include-asm-deletions.patch
The rest of anonmm-based rmap
-sched-config_sched_numa.patch
Dropped, wasn't popular.
+sched-fixes.patch
Scheduler tweaks
+nfs-direct-warning-fix.patch
Fix warning in nfs-O_DIRECT-fixes.patch
+numa-api-fixes.patch
Fixes to the NUMA API code
+numa-api-statistics-2.patch
Re-add statistical infrastructure to NUMA API.
These are currently undocumented. Hint.
+add-omitted-autofs4-super-block-field.patch
Fixup for the autofs4 patches
+autofs4-fix-handling-of-chdir-and-chroot.patch
Rework the autofs4 late mounting readdir support. Removes the racy handling
in fs/open.c
+as-increase-batch-expiry.patch
Anticipatory scheduler tuning.
+direct-IO-retval-fix.patch
+direct-io-retval-fix-2.patch
Fix up the direct-IO code paths to correctly perform >2G I/O's on 64-bit
architectures.
+populate-rootfs-later.patch
Call populate_rootfs() much later in boot, when the scheduler is actually
ready for us to call schedule() without going splat.
+remove-amd7saucy_tco.patch
Remove defunct driver
+fix-default-value-for-commit-interval-for-older-reiserfs-filesystems.patch
Laptop-miode reiserfs fix
+consolidate-sys32_readv-and-sys32_writev.patch
+consolidate-do_execve32.patch
+consolidate-sys32_select.patch
+consolidate-sys32_nfsservctl.patch
Consolidate the code which performs emulation of readv & writev on 64-bit
architectures.
+kill-off-hugepage_vma.patch
Remove hugepage_vma()
+ehci-oops-fix.patch
Fix some USB oops
+h8300-stack-bounds-checking.patch
+m68k-stack-bounds-checking.patch
+m68knommu-stack-bounds-checking.patch
+ppc32-stack-bounds-checking.patch
+sparc32-stack-bounds-checking.patch
Correctly calculate the top of stack in the backtracing code.
+3c509-oops-fix.patch
Fix an oops in 3c509.c
+lockfs-vfs-bits.patch
+lockfs-xfs-bits.patch
+lockfs-dm-bits.patch
+lockfs-dm-bits-2.patch
Move support for LVM snapshotting out of XFS and into core kernel.
+nfs-tokens-initdata.patch
Save a scrap of RAM.
+warn-if-module_param-and-module_parm-mixed.patch
Warn if a module uses both module_param() and the old MODULE_PARM()
+ide-cleanups-1.patch
+ide-cleanups-2.patch
+ide-cleanups-3.patch
IDE cleanups
+intel8x0-resume-fix.patch
Fix the intel8x0 driver for suspend/resume
+clean-up-asm-pgalloch-include.patch
+clean-up-asm-pgalloch-include-2.patch
+clean-up-asm-pgalloch-include-3.patch
Attempt to bring some sanity to the memory management include file
ordering.
+ppc64-uninline-__pte_free_tlb.patch
Fix the ppc64 build for the above.
+lec-warning-fix.patch
Fix a warning in an ATM driver
All 212 patches:
linus.patch
create_singlethread_workqueue.patch
reate_singlethread_workqueue()
use-workqueue-for-call_usermodehelper.patch
Use workqueue for call_usermodehelper
ppc64-rtas-build-fix.patch
ppc64: rtas build fix
mc.patch
Add -mcN to EXTRAVERSION
bk-acpi.patch
bk-agpgart.patch
bk-alsa.patch
bk-cifs.patch
bk-cpufreq.patch
bk-drm.patch
bk-input.patch
bk-netdev.patch
mm.patch
add -mmN to EXTRAVERSION
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-ga-recent-gcc-fix.patch
kgdb: fix for recent gcc
kgdboe-netpoll.patch
kgdb-over-ethernet via netpoll
kgdboe-configuration-logic-fix.patch
kgdboe: fix configuration of MAC address
kgdboe-configuration-logic-fix-fix.patch
kgdboe-non-ia32-build-fix.patch
kgdb-warning-fixes.patch
kgdb warning fixes
kgdb-x86_64-support.patch
kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
kgdb-x86_64-warning-fixes.patch
kgdb-x86_64-warning-fixes
wchan-use-ELF-sections-kgdb-fix.patch
wchan-use-ELF-sections-kgdb-fix
kgdb-THREAD_SIZE-fixes.patch
THREAD_SIZE fixes for kgdb
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-10-add-anonmm-rmap.patch
rmap 10 add anonmm rmap
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
must-fix.patch
must fix lists update
must fix list update
mustfix update
must-fix-update-5.patch
must-fix update
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
selinux-inode-race-trap.patch
Try to diagnose Bug 2153
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
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: fix for NR_CPUS > BITS_PER_LONG
sched: clarify find_busiest_group
sched: find_busiest_group arithmetic fix
sched-find-busiest-fix.patch
sched-find-busiest-fix
sched-sibling-map-to-cpumask.patch
sched: cpu_sibling_map to cpu_mask
p4-clockmod sibling_map fix
p4-clockmod: handle more than two siblings
sched-domains-i386-ht.patch
sched: implement domains for i386 HT
sched: Fix CONFIG_SMT oops on UP
sched: fix SMT + NUMA bug
Change arch_init_sched_domains to use cpu_online_map
Fix build with NR_CPUS > BITS_PER_LONG
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-domain-debugging.patch
sched_domain debugging
sched-domain-balancing-improvements.patch
scheduler domain balancing improvements
sched-group-power.patch
sched-group-power
sched-group-power warning fixes
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
process-migration-speedup.patch
Reduce TLB flushing during process migration
sched-trivial.patch
sched: trivial fixes, cleanups
sched-misc-fixes.patch
sched: misc fixes
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
ppc64-sched-domain-support.patch
ppc64: sched-domain support
sched-domain-setup-lock.patch
sched: fix setup races
ppc64-sched_domains-fix.patch
ppc64-sched_domains-fix
sched-domain-setup-lock-ppc64-fix.patch
sched-minor-cleanups.patch
sched: minor cleanups
sched-inline-removals.patch
sched: uninlinings
sched-move-cold-task.patch
sched: move cold task in mysteriouis ways
sched-migrate-shortcut.patch
sched: add migration shortcut
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-fixes.patch
sched: clean up leftovers
schedstats.patch
sched: scheduler statistics
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
aic7xxx-deadlock-fix.patch
aic7xxx deadlock fix
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.
pcmcia-netdev-ordering-fixes.patch
PCMCIA netdevice ordering issues
3ware-update.patch
3ware driver update
idr-extra-features.patch
idr.c: extra features enhancements
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()
jgarzik-warnings.patch
logitech-keyboard-fix.patch
2.6.5-rc2 keyboard breakage
signal-race-fix.patch
signal handling race fix
signal-race-fix-ia64.patch
signal-race-fix: ia64
signal-race-fix-s390.patch
signal-race fixes for s390
signal-race-fix-x86_64.patch
signal-race-fixes: x86-64 support
signal-race-fixes-ppc.patch
signal-race fixes for ppc32 and ppc64
warn-on-mdelay-in-irq-handlers.patch
Warn on mdelay() in irq handlers
stack-reductions-nfsread.patch
stack reductions: nfs read
speed-up-sata.patch
speed up SATA
advansys-fix.patch
advansys check_region() fix
aic7xxx-unload-fix.patch
aic7xxx: fix oops whe hardware is not present
journal_add_journal_head-debug.patch
journal_add_journal_head-debug
nfs-O_DIRECT-fixes.patch
NFS: O_DIRECT fixes
nfs-direct-warning-fix.patch
nfs/direct.c warning fix
aic7xxx-swsusp-support.patch
support swsusp for aic7xxx
xfs-laptop-mode.patch
Laptop mode support for XFS
xfs-laptop-mode-syncd-synchronization.patch
Synchronize XFS sync daemon with laptop mode syncs.
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
numa-api-x86_64.patch
numa api: -64 support
numa-api-bitmap-fix.patch
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
mpol-in-copy_vma.patch
mpol in copy_vma
numa-api-core-slab-panic.patch
numa-api-core-slab-panic
numa-api-core-tweaks.patch
numa-api-core-tweaks
numa-api-fixes.patch
Some fixes for NUMA API
numa-api-statistics-2.patch
Re-add NUMA API statistics
numa-api-core-bitmap_clear-fixes.patch
numa-api-core bitmap_clear fixes
numa-api-vma-policy-hooks.patch
numa api: Add VMA hooks for policy
numa-api-vma-policy-hooks-fix.patch
numa-api-vma-policy-hooks fix
numa-api-shared-memory-support.patch
numa api: Add shared memory support
numa-api-shared-memory-support-tweaks.patch
numa-api-shared-memory-support-tweaks
numa-api-statistics.patch
numa api: Add statistics
numa-api-anon-memory-policy.patch
numa api: Add policy support to anonymous memory
sk98lin-buggy-vpd-workaround.patch
net/sk98lin: correct buggy VPD in ASUS MB
skvpd-build-fix
unplug-can-sleep.patch
unplug functions can sleep
fix-load_elf_binary-error-path-on-unshare_files-error.patch
fix load_elf_binary error path on unshare_files error
firestream-warnings.patch
firestream warnings
cpufreq_userspace-warning.patch
cpufreq_userspace warning
compute-creds-race-fix.patch
compute_creds race
compute-creds-race-fix-fix.patch
compute-creds-race-fix-fix
compute-creds-race-fix-fix-fix.patch
fix must_not_trace_exec() even more
rndis-fix.patch
usb/gadget/rndis.c fix
pc300_drv-warnings.patch
pc300_drv-warnings
fix-acer-travelmate-360-interrupt-routing.patch
fix Acer TravelMate 360 interrupt routing
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_rsv_mount.patch
ext3 block reservation patch set -- mount and ioctl feature
ext3_rsv_dw.patch
ext3 block reservation patch set -- dynamically increase reservation window
ext3-reservation-default-on.patch
ext3 reservation: default to on
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
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
lindent-rwsem.patch
cleanup lib/rwsem.c lib/rwsem-spinlock.c
de-racify-rwsem-take-2.patch
de-racify rwsem take 2
scale-rwsem-take-2.patch
scale rwsem take 2
increase-number-of-dynamic-inodes-in-procfs-265.patch
Increase number of dynamic inodes in procfs
increase-number-of-dynamic-inodes-in-procfs-265-idr-init.patch
increase-number-of-dynamic-inodes-in-procfs-265-idr-init
ext3-data-leak-fix.patch
ext3 avoid writing kernel memory to disk
as-increase-batch-expiry.patch
AS: increase batch expiry intervals
direct-IO-retval-fix.patch
direct-IO-retval-fix
direct-io-retval-fix-2.patch
more direct-io retval fixes
populate-rootfs-later.patch
Call populate_rootfs later in boot
remove-amd7saucy_tco.patch
remove amd7xx_tco
fix-default-value-for-commit-interval-for-older-reiserfs-filesystems.patch
Fix default value for commit interval for older reiserfs filesystems.
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
kill-off-hugepage_vma.patch
From: David Gibson <[email protected]>
Subject: Kill off hugepage_vma()
ehci-oops-fix.patch
oops when loading ehci_hcd
h8300-stack-bounds-checking.patch
h8300 stack bounds checking
m68k-stack-bounds-checking.patch
m68k stack bounds checking
m68knommu-stack-bounds-checking.patch
m68knommu stack bounds checking
ppc32-stack-bounds-checking.patch
ppc32 stack bounds checking
sparc32-stack-bounds-checking.patch
sparc32 stack bounds checking
3c509-oops-fix.patch
3c509 oops fix
lockfs-vfs-bits.patch
lockfs - vfs bits
lockfs-xfs-bits.patch
lockfs - xfs bits
lockfs-dm-bits.patch
lockfs - dm bits
lockfs-dm-bits-2.patch
lockfs - dm bits
nfs-tokens-initdata.patch
nfs token table can be __initdata
warn-if-module_param-and-module_parm-mixed.patch
Warn if module_param and MODULE_PARM mixed
ide-cleanups-1.patch
IDE cleanups/fixups for 2.6.6-rc1 [1/3]
ide-cleanups-2.patch
IDE cleanups/fixups for 2.6.6-rc1 [2/3]
ide-cleanups-3.patch
IDE cleanups/fixups for 2.6.6-rc1 [3/3]
intel8x0-resume-fix.patch
intel8x0 suspend/resume fix
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()
lec-warning-fix.patch
ATM warning fix
On Sun, Apr 18, 2004 at 11:01:31PM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc1/2.6.6-rc1-mm1/
> - All of the anonmm rmap work is now merged up. No pte chains.
> - Various cleanups and fixups, as usual.
> - The list of external bk trees is getting a little short, due to problems
> at bkbits.net. The ones which are here are not necessarily very up-to-date
> with the various development trees.
Okay, the cpumask_arith.h fixes aren't in here. What do I have to do to
get the bare minimal correctness fixes in this area propagated to mainline?
The important aspect of these is that they're pertinent to small SMP
systems, for instance, the dual Pee Cee shenanigans with all kinds of pins
clipped along with all the other things used in larger boxen castrated.
-- wli
William Lee Irwin III <[email protected]> wrote:
>
> On Sun, Apr 18, 2004 at 11:01:31PM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc1/2.6.6-rc1-mm1/
> > - All of the anonmm rmap work is now merged up. No pte chains.
> > - Various cleanups and fixups, as usual.
> > - The list of external bk trees is getting a little short, due to problems
> > at bkbits.net. The ones which are here are not necessarily very up-to-date
> > with the various development trees.
>
> Okay, the cpumask_arith.h fixes aren't in here. What do I have to do to
> get the bare minimal correctness fixes in this area propagated to mainline?
>
> The important aspect of these is that they're pertinent to small SMP
> systems, for instance, the dual Pee Cee shenanigans with all kinds of pins
> clipped along with all the other things used in larger boxen castrated.
>
I confess to being moderately exhasperated at the amount of talk and
patching going on in the bitmap and cpumask areas. So when your patch
floated past with a terse description which was bristling with ifs, buts
and maybes I decided to take a pass.
If you want to send it again, cc'ing your co-conspirators and imparting some
confidence that this darned thing is actually meandering toward a conclusion,
please feel free ;)
On Sun, Apr 18, 2004 at 11:42:14PM -0700, Andrew Morton wrote:
> I confess to being moderately exhasperated at the amount of talk and
> patching going on in the bitmap and cpumask areas. So when your patch
> floated past with a terse description which was bristling with ifs, buts
> and maybes I decided to take a pass.
> If you want to send it again, cc'ing your co-conspirators and imparting some
> confidence that this darned thing is actually meandering toward a conclusion,
> please feel free ;)
Quick story is that what I sent is (what I believe) to be the bare
minimum change to restore correctnes.
I'll start arguing with people to make sure bugfixes start moving and
cleanups start waiting.
Paul, please remove akpm from the cc: list in future replies until we
have come to a consensus and get this nailed down (hopefully ASAP) to
a coherent cross-vendor story.
What I believe I have sent is the bare minimum change, with no cleanups
or semantic changes. If you could review and/or send approval or the
like that would be very helpful for the users of small SMP systems who
are affected by the bug(s) you reported.
-- wli
William Lee Irwin III wrote:
> On Sun, Apr 18, 2004 at 11:01:31PM -0700, Andrew Morton wrote:
>
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc1/2.6.6-rc1-mm1/
>>- All of the anonmm rmap work is now merged up. No pte chains.
>>- Various cleanups and fixups, as usual.
>>- The list of external bk trees is getting a little short, due to problems
>> at bkbits.net. The ones which are here are not necessarily very up-to-date
>> with the various development trees.
>
>
> Okay, the cpumask_arith.h fixes aren't in here. What do I have to do to
> get the bare minimal correctness fixes in this area propagated to mainline?
>
Speaking of which, the CPU_MASK_ALL, CPU_MASK_NONE fix for
cpumask_array.h still isn't there either.
It seems that in all the excitement a fix wasn't applied.
Here is Linus' version, which is obviously the best one.
On Sun, Apr 18, 2004 at 11:49:43PM -0700, William Lee Irwin III wrote:
> Quick story is that what I sent is (what I believe) to be the bare
> minimum change to restore correctnes.
> I'll start arguing with people to make sure bugfixes start moving and
> cleanups start waiting.
> Paul, please remove akpm from the cc: list in future replies until we
> have come to a consensus and get this nailed down (hopefully ASAP) to
> a coherent cross-vendor story.
> What I believe I have sent is the bare minimum change, with no cleanups
> or semantic changes. If you could review and/or send approval or the
> like that would be very helpful for the users of small SMP systems who
> are affected by the bug(s) you reported.
One last thing: I'm not opposed to cleanups in the least.
What I'm most concerned about is that arch maintainers have their needs
satisfied by whatever internals you choose to back cpumask* with.
In all honesty, what you've been proposing is very close to what I wanted
to have done to begin with. I would be glad to have you (or whoever else
has the wherewithal to push the issue) get things down to the cleanest and
most generally applicable implementation of API or definition of API as
possible.
I have taken issue only where I believe you need to acquire arch maintainer
feedback. IMHO, the changes proposed would be cleanups and more extensible,
but only need the review from arch maintainers to bring them to full
mainline merging. This is an API. When you have semantic equivalence, as
approved by arch maintainers, this has no reason _not_ to go in.
All this said, you have pointed out immediate needs for fixes. Please let
these fixes go through. There is a difference between the best code
possible and what makes things work.
-- wli
This one zonked out. I haven't configured module support, I simply
compile a monolithic kernel tailored for this particular machine.
I got this error, where 2.6.5-mm6 works well:
CC kernel/kmod.o
kernel/kmod.c: In function `call_usermodehelper':
kernel/kmod.c:253: error: `khelper_wq' undeclared (first use in this function)
kernel/kmod.c:253: error: (Each undeclared identifier is reported only once
kernel/kmod.c:253: error: for each function it appears in.)
kernel/kmod.c: In function `usermodehelper_init':
kernel/kmod.c:267: error: `khelper_wq' undeclared (first use in this function)
make[1]: *** [kernel/kmod.o] Error 1
make: *** [kernel] Error 2
Helge Hafting
Helge Hafting <[email protected]> wrote:
>
> This one zonked out. I haven't configured module support, I simply
> compile a monolithic kernel tailored for this particular machine.
> I got this error, where 2.6.5-mm6 works well:
>
> CC kernel/kmod.o
> kernel/kmod.c: In function `call_usermodehelper':
> kernel/kmod.c:253: error: `khelper_wq' undeclared (first use in this function)
> kernel/kmod.c:253: error: (Each undeclared identifier is reported only once
> kernel/kmod.c:253: error: for each function it appears in.)
> kernel/kmod.c: In function `usermodehelper_init':
> kernel/kmod.c:267: error: `khelper_wq' undeclared (first use in this function)
> make[1]: *** [kernel/kmod.o] Error 1
> make: *** [kernel] Error 2
>
diff -puN kernel/kmod.c~use-workqueue-for-call_usermodehelper-fix kernel/kmod.c
--- 25/kernel/kmod.c~use-workqueue-for-call_usermodehelper-fix 2004-04-19 01:45:50.561866616 -0700
+++ 25-akpm/kernel/kmod.c 2004-04-19 01:45:56.323990640 -0700
@@ -40,9 +40,10 @@
extern int max_threads;
-#ifdef CONFIG_KMOD
static struct workqueue_struct *khelper_wq;
+#ifdef CONFIG_KMOD
+
/*
modprobe_path is set via /proc/sys.
*/
_
Good run. Just have one new error in the allnoconfig compile
(which developers tend not to run)...
CC kernel/kmod.o
kernel/kmod.c: In function `call_usermodehelper':
kernel/kmod.c:253: `khelper_wq' undeclared (first use in this function)
kernel/kmod.c:253: (Each undeclared identifier is reported only once
kernel/kmod.c:253: for each function it appears in.)
kernel/kmod.c: In function `usermodehelper_init':
kernel/kmod.c:267: `khelper_wq' undeclared (first use in this function)
make[1]: [kernel/kmod.o] Error 1 (ignored)
Linux 2.6 (mm tree) Compile Statistics (gcc 3.2.2)
Warnings/Errors Summary
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
--------------- ---------- -------- -------- -------- -------- --------
2.6.6-rc1-mm1 0w/0e 0w/7e 122w/ 0e 7w/0e 4w/0e 122w/0e
2.6.5-mm6 0w/0e 0w/0e 123w/ 0e 7w/0e 4w/0e 124w/0e
2.6.5-mm5 0w/0e 0w/0e 119w/ 0e 7w/0e 4w/0e 120w/0e
2.6.5-mm4 0w/0e 0w/0e 120w/ 0e 7w/0e 4w/0e 121w/0e
2.6.5-mm3 0w/0e 1w/0e 121w/12e 7w/0e 3w/0e 123w/0e
2.6.5-mm2 0w/0e 0w/0e 128w/12e 7w/0e 3w/0e 134w/0e
2.6.5-mm1 0w/0e 5w/0e 122w/ 0e 7w/0e 3w/0e 124w/0e
2.6.5-rc3-mm4 0w/0e 0w/0e 124w/ 0e 8w/0e 4w/0e 126w/0e
2.6.5-rc3-mm3 0w/0e 5w/0e 129w/14e 8w/0e 4w/0e 129w/6e
2.6.5-rc3-mm2 0w/0e 5w/0e 130w/14e 8w/0e 4w/0e 129w/6e
2.6.5-rc3-mm1 0w/0e 5w/0e 129w/ 0e 8w/0e 4w/0e 129w/0e
2.6.5-rc2-mm5 0w/0e 5w/0e 130w/ 0e 8w/0e 4w/0e 129w/0e
2.6.5-rc2-mm4 0w/0e 5w/0e 134w/ 0e 8w/0e 3w/0e 133w/0e
2.6.5-rc2-mm3 0w/0e 5w/0e 134w/ 0e 8w/0e 3w/0e 133w/0e
2.6.5-rc2-mm2 0w/0e 5w/0e 137w/ 0e 8w/0e 3w/0e 134w/0e
2.6.5-rc2-mm1 0w/0e 5w/0e 136w/ 0e 8w/0e 3w/0e 134w/0e
2.6.5-rc1-mm2 0w/0e 5w/0e 135w/ 5e 8w/0e 3w/0e 133w/0e
2.6.5-rc1-mm1 0w/0e 5w/0e 135w/ 5e 8w/0e 3w/0e 133w/0e
2.6.4-mm2 1w/2e 5w/2e 144w/10e 8w/0e 3w/2e 144w/0e
2.6.4-mm1 1w/0e 5w/0e 146w/ 5e 8w/0e 3w/0e 144w/0e
2.6.4-rc2-mm1 1w/0e 5w/0e 146w/12e 11w/0e 3w/0e 147w/2e
2.6.4-rc1-mm2 1w/0e 5w/0e 144w/ 0e 11w/0e 3w/0e 145w/0e
2.6.4-rc1-mm1 1w/0e 5w/0e 147w/ 5e 11w/0e 3w/0e 147w/0e
2.6.3-mm4 1w/0e 5w/0e 146w/ 0e 7w/0e 3w/0e 142w/0e
2.6.3-mm3 1w/2e 5w/2e 146w/15e 7w/0e 3w/2e 144w/5e
2.6.3-mm2 1w/8e 5w/0e 140w/ 0e 7w/0e 3w/0e 138w/0e
2.6.3-mm1 1w/0e 5w/0e 143w/ 5e 7w/0e 3w/0e 141w/0e
2.6.3-rc3-mm1 1w/0e 0w/0e 144w/13e 7w/0e 3w/0e 142w/3e
2.6.3-rc2-mm1 1w/0e 0w/265e 144w/ 5e 7w/0e 3w/0e 145w/0e
2.6.3-rc1-mm1 1w/0e 0w/265e 141w/ 5e 7w/0e 3w/0e 143w/0e
2.6.2-mm1 2w/0e 0w/264e 147w/ 5e 7w/0e 3w/0e 173w/0e
2.6.2-rc3-mm1 2w/0e 0w/265e 146w/ 5e 7w/0e 3w/0e 172w/0e
2.6.2-rc2-mm2 0w/0e 0w/264e 145w/ 5e 7w/0e 3w/0e 171w/0e
2.6.2-rc2-mm1 0w/0e 0w/264e 146w/ 5e 7w/0e 3w/0e 172w/0e
2.6.2-rc1-mm3 0w/0e 0w/265e 144w/ 8e 7w/0e 3w/0e 169w/0e
2.6.2-rc1-mm2 0w/0e 0w/264e 144w/ 5e 10w/0e 3w/0e 171w/0e
2.6.2-rc1-mm1 0w/0e 0w/264e 144w/ 5e 10w/0e 3w/0e 171w/0e
2.6.1-mm5 2w/5e 0w/264e 153w/11e 10w/0e 3w/0e 180w/0e
2.6.1-mm4 0w/821e 0w/264e 154w/ 5e 8w/1e 5w/0e 179w/0e
2.6.1-mm3 0w/0e 0w/0e 151w/ 5e 10w/0e 3w/0e 177w/0e
2.6.1-mm2 0w/0e 0w/0e 143w/ 5e 12w/0e 3w/0e 171w/0e
2.6.1-mm1 0w/0e 0w/0e 146w/ 9e 12w/0e 6w/0e 171w/0e
2.6.1-rc2-mm1 0w/0e 0w/0e 149w/ 0e 12w/0e 6w/0e 171w/4e
2.6.1-rc1-mm2 0w/0e 0w/0e 157w/15e 12w/0e 3w/0e 185w/4e
2.6.1-rc1-mm1 0w/0e 0w/0e 156w/10e 12w/0e 3w/0e 184w/2e
2.6.0-mm2 0w/0e 0w/0e 161w/ 0e 12w/0e 3w/0e 189w/0e
2.6.0-mm1 0w/0e 0w/0e 173w/ 0e 12w/0e 3w/0e 212w/0e
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
John
4-autofs4-2.6.0-expire-20040405.patch exports vfsmount_lock which is probably
not exactly a good design. It's only used by autofs4_may_umount which isn't
autofs-specific at all.
On Mon, 19 Apr 2004, Christoph Hellwig wrote:
> 4-autofs4-2.6.0-expire-20040405.patch exports vfsmount_lock which is probably
> not exactly a good design. It's only used by autofs4_may_umount which isn't
> autofs-specific at all.
>
Sorry Christoph, your recommendation is?
Ian
Ian Kent <[email protected]> wrote:
>
> On Mon, 19 Apr 2004, Christoph Hellwig wrote:
>
> > 4-autofs4-2.6.0-expire-20040405.patch exports vfsmount_lock which is probably
> > not exactly a good design. It's only used by autofs4_may_umount which isn't
> > autofs-specific at all.
> >
>
> Sorry Christoph, your recommendation is?
>
May as well rename that function to may_umount(), document it, suck it into
fs/namespace.c or fs/namei.c and export it to modules.
That does increase the size of the static kernel a little, so arguably we
shouldn't make this change until/unless we see a second user of the
function.
Looking at the autofs4_may_umount I think I take the vfsmount_lock to
late.
--- linux-2.6.6-rc1-mm1.orig/fs/autofs4/expire.c 2004-04-20 22:08:39.000000000 +0800
+++ linux-2.6.6-rc1-mm1/fs/autofs4/expire.c 2004-04-20 22:20:06.000000000 +0800
@@ -53,10 +53,9 @@
int actual_refs;
int minimum_refs;
+ spin_lock(&vfsmount_lock);
actual_refs = atomic_read(&mnt->mnt_count);
minimum_refs = 2;
-
- spin_lock(&vfsmount_lock);
repeat:
next = this_parent->mnt_mounts.next;
resume:
On Sun, 18 Apr 2004, Andrew Morton wrote:
> - All of the anonmm rmap work is now merged up. No pte chains.
Wonderful!
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
[I sent this message 24 hours ago, but don't see it on lkml - try again. - pj]
Ok ... lets see here.
This message is in reply to 4 messages from Bill Irwin, dated:
Sat, 17 Apr 2004 19:26:38 -0700
Sun, 18 Apr 2004 23:29:14 -0700
Sun, 18 Apr 2004 23:49:43 -0700
Mon, 19 Apr 2004 00:06:43 -0700
> I'm having enough trouble remembering what Paul Jackson's take on things
My take was that in my work-in-progress bitmap/cpumask patches, I have:
1) Slightly strengthened the constraints (post-conditions) on
bitmap ops to not set tail bits so long as none were set on
input. This mostly means that the complement operator zeros
out the tail. The operators that return scalar (weight,
for example) or boolean (empty and full, for example) are
still careful to avoid depending on the state of the tail.
This changes Bill Irwin's "don't care" rule into a "don't
care, but don't pollute further" rule.
2) Removed cpumask_arith entirely, along with 30 odd other files,
to be replaced by a single cpumask.h set of macros, layered
rather thinly on top of bitmap/bitop.
> The important aspect of these is that they're pertinent to small SMP
> systems, ...
I tried making this point before, but failed to communicate. Let me try
again. So far as I know, there is no instance in current Linux kernel
code using this cpumask facility that is affected (currently broken) by
the cpumask_arith bugs addressed by Bill's patch. Do you know of any
breakage in other _current_ code caused by these cpumask_arith bugs,
Bill?
As a consequence of my seeing nothing else yet overtly busted by this,
it was, and remains, my recommendation to Bill to hold off on these
patches. Little sense in correcting the semantics of a piece of code
that I expected to remove shortly anyway, if nothing else cared for now.
However, I realize that Bill takes considerable pride in his work, and
would like to see this fixed. It's not worth a big fuss, either way,
so far as I can tell.
> Paul, please remove akpm from the cc: list
I have removed akpm from this reply.
> the users of small SMP systems who are affected by the bug(s) you
> reported.
I am unaware that any user of any small SMP (or other) system
is affected by these bugs.
> If you could review and/or send approval or the like that would be
> very helpful ...
If we can agree on the actual state of affairs, then I will readily
agree to such to Andrew, and let him decide on the merits and
appropriate timing of this patch.
>From what I know now, this would mean telling Andrew, of Bill's patch:
This patch fixes some bugs in the small SMP system (2 to 32 CPU) flavor
of cpumasks. From what we know now, these bugs aren't breaking any
other existing code, but they are an accident waiting to happen.
If Paul Jackson's bitmap/cpumask rework is adapted in the future,
then this code being patched would be replaced anyway. But for now,
these fixes are a definite improvement.
If this does not seem like a correct statement of affairs, lets hash
that out. Then when we agree, you should present your patch to him on
the lkml again, and I will gladly chime in with my endorsement.
Unless, of course, you change your mind and decide to hold off on this
patch, to which I would even more readily agree <grin>.
> I have taken issue only where I believe you need to acquire arch
> maintainer feedback.
And I have agreed that this is an excellent request. I was out on
vacation last week, and hesitated to start the arch maintainer discussion
the week before, knowing that I would be on vacation, and not wanting to
start something I would not be around to follow through on.
But I am back now, and expect later this week to begin that discussion,
as you have recommended.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373
On Tue, Apr 20, 2004 at 02:17:13PM -0700, Paul Jackson wrote:
> I tried making this point before, but failed to communicate. Let me try
> again. So far as I know, there is no instance in current Linux kernel
> code using this cpumask facility that is affected (currently broken) by
> the cpumask_arith bugs addressed by Bill's patch. Do you know of any
> breakage in other _current_ code caused by these cpumask_arith bugs,
> Bill?
> As a consequence of my seeing nothing else yet overtly busted by this,
> it was, and remains, my recommendation to Bill to hold off on these
> patches. Little sense in correcting the semantics of a piece of code
> that I expected to remove shortly anyway, if nothing else cared for now.
> However, I realize that Bill takes considerable pride in his work, and
> would like to see this fixed. It's not worth a big fuss, either way,
> so far as I can tell.
I thought you were reporting some instance affected by it. Since there's
no report of anyone affected by it, and a cleanup/whatever pending, I'm
dropping the bugfix patch(es).
-- wli
Ok ... lets see here.
This message is in reply to 4 messages from Bill Irwin, dated:
Sat, 17 Apr 2004 19:26:38 -0700
Sun, 18 Apr 2004 23:29:14 -0700
Sun, 18 Apr 2004 23:49:43 -0700
Mon, 19 Apr 2004 00:06:43 -0700
> I'm having enough trouble remembering what Paul Jackson's take on things
My take was that in my work-in-progress bitmap/cpumask patches, I have:
1) Slightly strengthened the constraints (post-conditions) on
bitmap ops to not set tail bits so long as none were set on
input. This mostly means that the complement operator zeros
out the tail. The operators that return scalar (weight,
for example) or boolean (empty and full, for example) are
still careful to avoid depending on the state of the tail.
This changes Bill Irwin's "don't care" rule into a "don't
care, but don't pollute further" rule.
2) Removed cpumask_arith entirely, along with 30 odd other files,
to be replaced by a single cpumask.h set of macros, layered
rather thinly on top of bitmap/bitop.
> The important aspect of these is that they're pertinent to small SMP
> systems, ...
I tried making this point before, but failed to communicate. Let me try
again. So far as I know, there is no instance in current Linux kernel
code using this cpumask facility that is affected (currently broken) by
the cpumask_arith bugs addressed by Bill's patch. Do you know of any
breakage in other _current_ code caused by these cpumask_arith bugs,
Bill?
As a consequence of my seeing nothing else yet overtly busted by this,
it was, and remains, my recommendation to Bill to hold off on these
patches. Little sense in correcting the semantics of a piece of code
that I expected to remove shortly anyway, if nothing else cared for now.
However, I realize that Bill takes considerable pride in his work, and
would like to see this fixed. It's not worth a big fuss, either way,
so far as I can tell.
> Paul, please remove akpm from the cc: list
I have removed akpm from this reply.
> the users of small SMP systems who are affected by the bug(s) you
> reported.
I am unaware that any user of any small SMP (or other) system
is affected by these bugs.
> If you could review and/or send approval or the like that would be
> very helpful ...
If we can agree on the actual state of affairs, then I will readily
agree to such to Andrew, and let him decide on the merits and
appropriate timing of this patch.
>From what I know now, this would mean telling Andrew, of Bill's patch:
This patch fixes some bugs in the small SMP system (2 to 32 CPU) flavor
of cpumasks. From what we know now, these bugs aren't breaking any
other existing code, but they are an accident waiting to happen.
If Paul Jackson's bitmap/cpumask rework is adapted in the future,
then this code being patched would be replaced anyway. But for now,
these fixes are a definite improvement.
If this does not seem like a correct statement of affairs, lets hash
that out. Then when we agree, you should present your patch to him on
the lkml again, and I will gladly chime in with my endorsement.
Unless, of course, you change your mind and decide to hold off on this
patch, to which I would even more readily agree <grin>.
> I have taken issue only where I believe you need to acquire arch
> maintainer feedback.
And I have agreed that this is an excellent request. I was out on
vacation last week, and hesitated to start the arch maintainer discussion
the week before, knowing that I would be on vacation, and not wanting to
start something I would not be around to follow through on.
But I am back now, and expect later this week to begin that discussion,
as you have recommended.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373
Rik van Riel <[email protected]> writes:
> On Sun, 18 Apr 2004, Andrew Morton wrote:
>
>> - All of the anonmm rmap work is now merged up. No pte chains.
>
> Wonderful!
As is this (I assume debugging) message:
Apr 20 16:20:24 slagpiece kernel: xterm: mremap moved 49 cows
______
< Moo! >
------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
On Mon, Apr 19, 2004 at 06:26:57PM -0700, Andrew Morton wrote:
> May as well rename that function to may_umount(), document it, suck it into
> fs/namespace.c or fs/namei.c and export it to modules.
>
> That does increase the size of the static kernel a little, so arguably we
> shouldn't make this change until/unless we see a second user of the
> function.
That's what I meant. Simply exporting vfsmount_lock to modules is a no-go.
On Wed, 21 Apr 2004, Sean Neakums wrote:
>
> As is this (I assume debugging) message:
>
> Apr 20 16:20:24 slagpiece kernel: xterm: mremap moved 49 cows
>
> ______
> < Moo! >
> ------
> \ ^__^
> \ (oo)\_______
> (__)\ )\/\
> ||----w |
> || ||
Lovely! Thanks for your report, and especially your art - you are the
lucky winner of a huge churn of milk for first report of this message,
just send your details etc. etc.
Yes, more or less a debugging message: nothing bad has happened, just
something rather inefficient, and we'd like to get some idea of how
much it occurs in practice. xterm, eh? I wouldn't have guessed that.
Quite a herd.
I hoped a whimsical message might be reported more than a boring one!
Hugh
On Wed, 21 Apr 2004, Christoph Hellwig wrote:
> On Mon, Apr 19, 2004 at 06:26:57PM -0700, Andrew Morton wrote:
> > May as well rename that function to may_umount(), document it, suck it into
> > fs/namespace.c or fs/namei.c and export it to modules.
> >
> > That does increase the size of the static kernel a little, so arguably we
> > shouldn't make this change until/unless we see a second user of the
> > function.
>
> That's what I meant. Simply exporting vfsmount_lock to modules is a no-go.
>
Cool.
If it is decided to do this then would something like this be approiate
Andrew?
I have
- renamed autofs4_may_umount to may_umount_tree and moved
it to namespace.c
- removed the EXPORT_SYMBOL for vfsmount_lock
- updated autofs4 to suit
It is not possible to merge the functionality of may_umount into this as,
it stands, as autofs v3 requires a slightly different semantic. That is if
there are submounts that are not busy then it should return -EBUSY but
may_umount_tree would return not busy.
--- linux-2.6.6-rc1-mm1.orig/fs/namespace.c 2004-04-20 22:08:41.000000000 +0800
+++ linux-2.6.6-rc1-mm1/fs/namespace.c 2004-04-20 23:10:08.000000000 +0800
@@ -37,8 +37,6 @@
/* spinlock for vfsmount related operations, inplace of dcache_lock */
spinlock_t vfsmount_lock __cacheline_aligned_in_smp = SPIN_LOCK_UNLOCKED;
-EXPORT_SYMBOL(vfsmount_lock);
-
static struct list_head *mount_hashtable;
static int hash_mask, hash_bits;
static kmem_cache_t *mnt_cache;
@@ -262,6 +260,55 @@
.show = show_vfsmnt
};
+/**
+ * may_umount_tree - check if a mount tree is busy
+ * @mnt: root of mount tree
+ *
+ * This is called to check if a tree of mounts has any
+ * open files, pwds or chroots. ie. if it is busy.
+ */
+int may_umount_tree(struct vfsmount *mnt)
+{
+ struct list_head *next;
+ struct vfsmount *this_parent = mnt;
+ int actual_refs;
+ int minimum_refs;
+
+ spin_lock(&vfsmount_lock);
+ actual_refs = atomic_read(&mnt->mnt_count);
+ minimum_refs = 2;
+repeat:
+ next = this_parent->mnt_mounts.next;
+resume:
+ while (next != &this_parent->mnt_mounts) {
+ struct vfsmount *p = list_entry(next, struct vfsmount, mnt_child);
+
+ next = next->next;
+
+ actual_refs += atomic_read(&p->mnt_count);
+ minimum_refs += 2;
+
+ if ( !list_empty(&p->mnt_mounts) ) {
+ this_parent = p;
+ goto repeat;
+ }
+ }
+
+ if (this_parent != mnt) {
+ next = this_parent->mnt_child.next;
+ this_parent = this_parent->mnt_parent;
+ goto resume;
+ }
+ spin_unlock(&vfsmount_lock);
+
+ if (actual_refs > minimum_refs)
+ return -EBUSY;
+
+ return 0;
+}
+
+EXPORT_SYMBOL(may_umount_tree);
+
/*
* Doesn't take quota and stuff into account. IOW, in some cases it will
* give false negatives. The main reason why it's here is that we need
--- linux-2.6.6-rc1-mm1.orig/fs/autofs4/expire.c 2004-04-20 23:27:18.000000000 +0800
+++ linux-2.6.6-rc1-mm1/fs/autofs4/expire.c 2004-04-20 23:13:43.000000000 +0800
@@ -45,47 +45,6 @@
return 1;
}
-/* Sorry I can't solve the problem without using counts either */
-static int autofs4_may_umount(struct vfsmount *mnt)
-{
- struct list_head *next;
- struct vfsmount *this_parent = mnt;
- int actual_refs;
- int minimum_refs;
-
- spin_lock(&vfsmount_lock);
- actual_refs = atomic_read(&mnt->mnt_count);
- minimum_refs = 2;
-repeat:
- next = this_parent->mnt_mounts.next;
-resume:
- while (next != &this_parent->mnt_mounts) {
- struct vfsmount *p = list_entry(next, struct vfsmount, mnt_child);
-
- next = next->next;
-
- actual_refs += atomic_read(&p->mnt_count);
- minimum_refs += 2;
-
- if ( !list_empty(&p->mnt_mounts) ) {
- this_parent = p;
- goto repeat;
- }
- }
-
- if (this_parent != mnt) {
- next = this_parent->mnt_child.next;
- this_parent = this_parent->mnt_parent;
- goto resume;
- }
- spin_unlock(&vfsmount_lock);
-
- DPRINTK(("autofs4_may_umount: done actual = %d, minimum = %d\n",
- actual_refs, minimum_refs));
-
- return actual_refs > minimum_refs;
-}
-
/* Check a mount point for busyness return 1 if not busy, otherwise */
static int autofs4_check_mount(struct vfsmount *mnt, struct dentry *dentry)
{
@@ -108,7 +67,7 @@
goto done;
/* The big question */
- if (autofs4_may_umount(mnt) == 0)
+ if (may_umount_tree(mnt) == 0)
status = 1;
done:
DPRINTK(("autofs4_check_mount: returning = %d\n", status));
On Wed, 21 Apr 2004, Christoph Hellwig wrote:
>
> That's what I meant. Simply exporting vfsmount_lock to modules is a no-go.
>
While I understand the motive for not exporting the lock the question of
how one should obtain vfsmount structs when needed remains?
On Wed, Apr 21, 2004 at 08:31:38PM +0800, [email protected] wrote:
> If it is decided to do this then would something like this be approiate
> Andrew?
>
> I have
> - renamed autofs4_may_umount to may_umount_tree and moved
> it to namespace.c
> - removed the EXPORT_SYMBOL for vfsmount_lock
> - updated autofs4 to suit
>
> It is not possible to merge the functionality of may_umount into this as,
> it stands, as autofs v3 requires a slightly different semantic. That is if
> there are submounts that are not busy then it should return -EBUSY but
> may_umount_tree would return not busy.
What about adding a paramter 'ignore_busy_submounts' and use most of the
function in common for both autofs3 and autofs4?
> + struct list_head *next;
> + struct vfsmount *this_parent = mnt;
> + int actual_refs;
> + int minimum_refs;
> +
> + spin_lock(&vfsmount_lock);
> + actual_refs = atomic_read(&mnt->mnt_count);
> + minimum_refs = 2;
> +repeat:
> + next = this_parent->mnt_mounts.next;
> +resume:
> + while (next != &this_parent->mnt_mounts) {
> + struct vfsmount *p = list_entry(next, struct vfsmount, mnt_child);
> +
> + next = next->next;
Any chance to use list_for_each_entry here?
> + if ( !list_empty(&p->mnt_mounts) ) {
This wants a white-space fixup.
On Wed, Apr 21, 2004 at 08:39:59PM +0800, [email protected] wrote:
> While I understand the motive for not exporting the lock the question of
> how one should obtain vfsmount structs when needed remains?
You shouldn't.
On Wed, 21 Apr 2004, Christoph Hellwig wrote:
> >
> > It is not possible to merge the functionality of may_umount into this as,
> > it stands, as autofs v3 requires a slightly different semantic. That is if
> > there are submounts that are not busy then it should return -EBUSY but
> > may_umount_tree would return not busy.
>
> What about adding a paramter 'ignore_busy_submounts' and use most of the
> function in common for both autofs3 and autofs4?
Thought of that as I was writing the response.
I'll merge the two functions then and produce an updated patch.
>
> > + struct list_head *next;
> > + struct vfsmount *this_parent = mnt;
> > + int actual_refs;
> > + int minimum_refs;
> > +
> > + spin_lock(&vfsmount_lock);
> > + actual_refs = atomic_read(&mnt->mnt_count);
> > + minimum_refs = 2;
> > +repeat:
> > + next = this_parent->mnt_mounts.next;
> > +resume:
> > + while (next != &this_parent->mnt_mounts) {
> > + struct vfsmount *p = list_entry(next, struct vfsmount, mnt_child);
> > +
> > + next = next->next;
>
> Any chance to use list_for_each_entry here?
Same thought occured to me as well. As above.
>
> > + if ( !list_empty(&p->mnt_mounts) ) {
>
> This wants a white-space fixup.
Yes it's not quite the format I like most atm. I'll also do that.
May take a couple of days though.
Thanks for you continuing interest and help.
Ian
On Wed, 21 Apr 2004, Christoph Hellwig wrote:
> On Wed, Apr 21, 2004 at 08:39:59PM +0800, [email protected] wrote:
> > While I understand the motive for not exporting the lock the question of
> > how one should obtain vfsmount structs when needed remains?
>
> You shouldn't.
>
Shouldn't need them?
But your point is that they shouldn't need to be used and an different
design is should be used, right.
Could make life hard for the automounter.
Possibly somewhat harder to solve the remaining limitations of autofs.
But I haven't got a clear enough picture of what's needed yet (still).
I guess your point is that these services should reside in the VFS proper?
Ian
On Wed, Apr 21, 2004 at 09:52:01PM +0800, [email protected] wrote:
> > On Wed, Apr 21, 2004 at 08:39:59PM +0800, [email protected] wrote:
> > > While I understand the motive for not exporting the lock the question of
> > > how one should obtain vfsmount structs when needed remains?
> >
> > You shouldn't.
> >
>
> Shouldn't need them?
Exactly.
> But your point is that they shouldn't need to be used and an different
> design is should be used, right.
>
> Could make life hard for the automounter.
> Possibly somewhat harder to solve the remaining limitations of autofs.
> But I haven't got a clear enough picture of what's needed yet (still).
>
> I guess your point is that these services should reside in the VFS proper?
If you ask me much of what autofs does should reside in the VFS, namely
triggering userspace upcalls as soon someone enters a special trigger
(aka delayed mountpount) directory and expiry of vfsmounts.
On Wed, 21 Apr 2004, Christoph Hellwig wrote:
>
> If you ask me much of what autofs does should reside in the VFS, namely
> triggering userspace upcalls as soon someone enters a special trigger
> (aka delayed mountpount) directory and expiry of vfsmounts.
>
That's am approach that I've not had the luxury of pondering till now.
I'll have to think about the potential of that for a while.
In the past I have thought that automount functionality is specialised
enough to warrant seperation from the core VFS services. But now (after
several months of consideration) I'm not sure that the functionality
needed can be done without some general VFS support.
At the moment I think that if it was decided to add these services to
the VFS then they would need to be general, not automount specific. As VFS
services should be. But alas there are no clear requirements. For
example, the recent proposal by Mike Waychison, although an excellent
paper, requires a kernel expiry service but has no discussion of what is
actually needed.
Sorry, I must be boring you with all this ranting.
Ian
On Wed, 21 Apr 2004, Christoph Hellwig wrote:
> > +
> > + spin_lock(&vfsmount_lock);
> > + actual_refs = atomic_read(&mnt->mnt_count);
> > + minimum_refs = 2;
> > +repeat:
> > + next = this_parent->mnt_mounts.next;
> > +resume:
> > + while (next != &this_parent->mnt_mounts) {
> > + struct vfsmount *p = list_entry(next, struct vfsmount, mnt_child);
> > +
> > + next = next->next;
>
> Any chance to use list_for_each_entry here?
It looks to me like this macro can't be used for a tree traversal.
Please enlighten me if I'm wrong.
On Wed, Apr 21, 2004 at 11:52:18PM +0800, [email protected] wrote:
> > Any chance to use list_for_each_entry here?
>
> It looks to me like this macro can't be used for a tree traversal.
> Please enlighten me if I'm wrong.
Umm, indeed. The control flow in that function is a little too convoluted :)