linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.6.6-rc1-mm1
@ 2004-04-19  6:01 Andrew Morton
  2004-04-19  6:29 ` 2.6.6-rc1-mm1 William Lee Irwin III
                   ` (5 more replies)
  0 siblings, 6 replies; 30+ messages in thread
From: Andrew Morton @ 2004-04-19  6:01 UTC (permalink / raw)
  To: linux-kernel


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 <david@gibson.dropbear.id.au>
  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




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-19  6:01 2.6.6-rc1-mm1 Andrew Morton
@ 2004-04-19  6:29 ` William Lee Irwin III
  2004-04-19  6:42   ` 2.6.6-rc1-mm1 Andrew Morton
  2004-04-19  6:58   ` 2.6.6-rc1-mm1 Nick Piggin
  2004-04-19  9:13 ` 2.6.6-rc1-mm1 failure: kmod.o didn't compile with module-less setup Helge Hafting
                   ` (4 subsequent siblings)
  5 siblings, 2 replies; 30+ messages in thread
From: William Lee Irwin III @ 2004-04-19  6:29 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-19  6:29 ` 2.6.6-rc1-mm1 William Lee Irwin III
@ 2004-04-19  6:42   ` Andrew Morton
  2004-04-19  6:49     ` 2.6.6-rc1-mm1 William Lee Irwin III
  2004-04-19  6:58   ` 2.6.6-rc1-mm1 Nick Piggin
  1 sibling, 1 reply; 30+ messages in thread
From: Andrew Morton @ 2004-04-19  6:42 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: linux-kernel

William Lee Irwin III <wli@holomorphy.com> 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 ;)


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-19  6:42   ` 2.6.6-rc1-mm1 Andrew Morton
@ 2004-04-19  6:49     ` William Lee Irwin III
  2004-04-19  7:06       ` 2.6.6-rc1-mm1 William Lee Irwin III
  0 siblings, 1 reply; 30+ messages in thread
From: William Lee Irwin III @ 2004-04-19  6:49 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, pj

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-19  6:29 ` 2.6.6-rc1-mm1 William Lee Irwin III
  2004-04-19  6:42   ` 2.6.6-rc1-mm1 Andrew Morton
@ 2004-04-19  6:58   ` Nick Piggin
  1 sibling, 0 replies; 30+ messages in thread
From: Nick Piggin @ 2004-04-19  6:58 UTC (permalink / raw)
  To: Andrew Morton; +Cc: William Lee Irwin III, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

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.

[-- Attachment #2: fix-big-cpumask.patch --]
[-- Type: text/x-patch, Size: 899 bytes --]

 linux-2.6-npiggin/include/asm-generic/cpumask_array.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -puN include/asm-generic/cpumask.h~fix-big-cpumask include/asm-generic/cpumask.h
diff -puN include/asm-generic/cpumask_array.h~fix-big-cpumask include/asm-generic/cpumask_array.h
--- linux-2.6/include/asm-generic/cpumask_array.h~fix-big-cpumask	2004-04-19 16:51:55.000000000 +1000
+++ linux-2.6-npiggin/include/asm-generic/cpumask_array.h	2004-04-19 16:53:15.000000000 +1000
@@ -48,7 +48,7 @@
 /*
  * um, these need to be usable as static initializers
  */
-#define CPU_MASK_ALL	{ {[0 ... CPU_ARRAY_SIZE-1] = ~0UL} }
-#define CPU_MASK_NONE	{ {[0 ... CPU_ARRAY_SIZE-1] =  0UL} }
+#define CPU_MASK_ALL	((cpumask_t) { {[0 ... CPU_ARRAY_SIZE-1] = ~0UL} })
+#define CPU_MASK_NONE	((cpumask_t) { {[0 ... CPU_ARRAY_SIZE-1] =  0UL} })
 
 #endif /* __ASM_GENERIC_CPUMASK_ARRAY_H */

_

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-19  6:49     ` 2.6.6-rc1-mm1 William Lee Irwin III
@ 2004-04-19  7:06       ` William Lee Irwin III
  2004-04-19 18:39         ` bitmap, cpumask_arith (was: 2.6.6-rc1-mm1) Paul Jackson
  0 siblings, 1 reply; 30+ messages in thread
From: William Lee Irwin III @ 2004-04-19  7:06 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel, pj

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1 failure: kmod.o didn't compile with module-less setup
  2004-04-19  6:01 2.6.6-rc1-mm1 Andrew Morton
  2004-04-19  6:29 ` 2.6.6-rc1-mm1 William Lee Irwin III
@ 2004-04-19  9:13 ` Helge Hafting
  2004-04-19  9:17   ` Andrew Morton
  2004-04-19 15:26 ` 2.6.6-rc1-mm1 (compile stats) John Cherry
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 30+ messages in thread
From: Helge Hafting @ 2004-04-19  9:13 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1 failure: kmod.o didn't compile with module-less setup
  2004-04-19  9:13 ` 2.6.6-rc1-mm1 failure: kmod.o didn't compile with module-less setup Helge Hafting
@ 2004-04-19  9:17   ` Andrew Morton
  0 siblings, 0 replies; 30+ messages in thread
From: Andrew Morton @ 2004-04-19  9:17 UTC (permalink / raw)
  To: Helge Hafting; +Cc: linux-kernel

Helge Hafting <helgehaf@aitel.hist.no> 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.
 */

_


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1 (compile stats)
  2004-04-19  6:01 2.6.6-rc1-mm1 Andrew Morton
  2004-04-19  6:29 ` 2.6.6-rc1-mm1 William Lee Irwin III
  2004-04-19  9:13 ` 2.6.6-rc1-mm1 failure: kmod.o didn't compile with module-less setup Helge Hafting
@ 2004-04-19 15:26 ` John Cherry
  2004-04-19 19:25 ` 2.6.6-rc1-mm1 Christoph Hellwig
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 30+ messages in thread
From: John Cherry @ 2004-04-19 15:26 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* bitmap, cpumask_arith (was: 2.6.6-rc1-mm1)
  2004-04-19  7:06       ` 2.6.6-rc1-mm1 William Lee Irwin III
@ 2004-04-19 18:39         ` Paul Jackson
  2004-04-20 21:17           ` Paul Jackson
  0 siblings, 1 reply; 30+ messages in thread
From: Paul Jackson @ 2004-04-19 18:39 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: linux-kernel

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 <pj@sgi.com> 1.650.933.1373

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-19  6:01 2.6.6-rc1-mm1 Andrew Morton
                   ` (2 preceding siblings ...)
  2004-04-19 15:26 ` 2.6.6-rc1-mm1 (compile stats) John Cherry
@ 2004-04-19 19:25 ` Christoph Hellwig
  2004-04-20  1:13   ` 2.6.6-rc1-mm1 Ian Kent
  2004-04-20 14:27 ` 2.6.6-rc1-mm1 raven
  2004-04-20 15:06 ` 2.6.6-rc1-mm1 Rik van Riel
  5 siblings, 1 reply; 30+ messages in thread
From: Christoph Hellwig @ 2004-04-19 19:25 UTC (permalink / raw)
  To: Andrew Morton, raven, viro; +Cc: linux-kernel

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.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-19 19:25 ` 2.6.6-rc1-mm1 Christoph Hellwig
@ 2004-04-20  1:13   ` Ian Kent
  2004-04-20  1:26     ` 2.6.6-rc1-mm1 Andrew Morton
  0 siblings, 1 reply; 30+ messages in thread
From: Ian Kent @ 2004-04-20  1:13 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, viro, linux-kernel

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


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-20  1:13   ` 2.6.6-rc1-mm1 Ian Kent
@ 2004-04-20  1:26     ` Andrew Morton
  2004-04-21  9:08       ` 2.6.6-rc1-mm1 Christoph Hellwig
  0 siblings, 1 reply; 30+ messages in thread
From: Andrew Morton @ 2004-04-20  1:26 UTC (permalink / raw)
  To: Ian Kent; +Cc: hch, viro, linux-kernel

Ian Kent <raven@themaw.net> 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.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-19  6:01 2.6.6-rc1-mm1 Andrew Morton
                   ` (3 preceding siblings ...)
  2004-04-19 19:25 ` 2.6.6-rc1-mm1 Christoph Hellwig
@ 2004-04-20 14:27 ` raven
  2004-04-20 15:06 ` 2.6.6-rc1-mm1 Rik van Riel
  5 siblings, 0 replies; 30+ messages in thread
From: raven @ 2004-04-20 14:27 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel


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:

 


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-19  6:01 2.6.6-rc1-mm1 Andrew Morton
                   ` (4 preceding siblings ...)
  2004-04-20 14:27 ` 2.6.6-rc1-mm1 raven
@ 2004-04-20 15:06 ` Rik van Riel
  2004-04-21  7:37   ` 2.6.6-rc1-mm1 Sean Neakums
  5 siblings, 1 reply; 30+ messages in thread
From: Rik van Riel @ 2004-04-20 15:06 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: bitmap, cpumask_arith (was: 2.6.6-rc1-mm1)
  2004-04-19 18:39         ` bitmap, cpumask_arith (was: 2.6.6-rc1-mm1) Paul Jackson
@ 2004-04-20 21:17           ` Paul Jackson
  2004-04-20 21:38             ` William Lee Irwin III
  0 siblings, 1 reply; 30+ messages in thread
From: Paul Jackson @ 2004-04-20 21:17 UTC (permalink / raw)
  To: Paul Jackson, William Lee Irwin III; +Cc: linux-kernel

[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 <pj@sgi.com> 1.650.933.1373

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: bitmap, cpumask_arith (was: 2.6.6-rc1-mm1)
  2004-04-20 21:17           ` Paul Jackson
@ 2004-04-20 21:38             ` William Lee Irwin III
  0 siblings, 0 replies; 30+ messages in thread
From: William Lee Irwin III @ 2004-04-20 21:38 UTC (permalink / raw)
  To: Paul Jackson; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-20 15:06 ` 2.6.6-rc1-mm1 Rik van Riel
@ 2004-04-21  7:37   ` Sean Neakums
  2004-04-21 12:16     ` 2.6.6-rc1-mm1 Hugh Dickins
  0 siblings, 1 reply; 30+ messages in thread
From: Sean Neakums @ 2004-04-21  7:37 UTC (permalink / raw)
  To: linux-kernel

Rik van Riel <riel@redhat.com> 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 |
                ||     ||


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-20  1:26     ` 2.6.6-rc1-mm1 Andrew Morton
@ 2004-04-21  9:08       ` Christoph Hellwig
  2004-04-21 12:31         ` 2.6.6-rc1-mm1 raven
  2004-04-21 12:39         ` 2.6.6-rc1-mm1 raven
  0 siblings, 2 replies; 30+ messages in thread
From: Christoph Hellwig @ 2004-04-21  9:08 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Ian Kent, hch, viro, linux-kernel

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.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21  7:37   ` 2.6.6-rc1-mm1 Sean Neakums
@ 2004-04-21 12:16     ` Hugh Dickins
  0 siblings, 0 replies; 30+ messages in thread
From: Hugh Dickins @ 2004-04-21 12:16 UTC (permalink / raw)
  To: Sean Neakums; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21  9:08       ` 2.6.6-rc1-mm1 Christoph Hellwig
@ 2004-04-21 12:31         ` raven
  2004-04-21 13:18           ` 2.6.6-rc1-mm1 Christoph Hellwig
  2004-04-21 12:39         ` 2.6.6-rc1-mm1 raven
  1 sibling, 1 reply; 30+ messages in thread
From: raven @ 2004-04-21 12:31 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, Al Viro, Kernel Mailing List

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));

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21  9:08       ` 2.6.6-rc1-mm1 Christoph Hellwig
  2004-04-21 12:31         ` 2.6.6-rc1-mm1 raven
@ 2004-04-21 12:39         ` raven
  2004-04-21 13:19           ` 2.6.6-rc1-mm1 Christoph Hellwig
  1 sibling, 1 reply; 30+ messages in thread
From: raven @ 2004-04-21 12:39 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, viro, linux-kernel

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?


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21 12:31         ` 2.6.6-rc1-mm1 raven
@ 2004-04-21 13:18           ` Christoph Hellwig
  2004-04-21 13:34             ` 2.6.6-rc1-mm1 raven
  2004-04-21 15:52             ` 2.6.6-rc1-mm1 raven
  0 siblings, 2 replies; 30+ messages in thread
From: Christoph Hellwig @ 2004-04-21 13:18 UTC (permalink / raw)
  To: raven; +Cc: Christoph Hellwig, Andrew Morton, Al Viro, Kernel Mailing List

On Wed, Apr 21, 2004 at 08:31:38PM +0800, raven@themaw.net 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.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21 12:39         ` 2.6.6-rc1-mm1 raven
@ 2004-04-21 13:19           ` Christoph Hellwig
  2004-04-21 13:52             ` 2.6.6-rc1-mm1 raven
  0 siblings, 1 reply; 30+ messages in thread
From: Christoph Hellwig @ 2004-04-21 13:19 UTC (permalink / raw)
  To: raven; +Cc: Andrew Morton, viro, linux-kernel

On Wed, Apr 21, 2004 at 08:39:59PM +0800, raven@themaw.net 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.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21 13:18           ` 2.6.6-rc1-mm1 Christoph Hellwig
@ 2004-04-21 13:34             ` raven
  2004-04-21 15:52             ` 2.6.6-rc1-mm1 raven
  1 sibling, 0 replies; 30+ messages in thread
From: raven @ 2004-04-21 13:34 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, Al Viro, Kernel Mailing List

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
 


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21 13:19           ` 2.6.6-rc1-mm1 Christoph Hellwig
@ 2004-04-21 13:52             ` raven
  2004-04-21 14:56               ` 2.6.6-rc1-mm1 Christoph Hellwig
  0 siblings, 1 reply; 30+ messages in thread
From: raven @ 2004-04-21 13:52 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, viro, linux-kernel

On Wed, 21 Apr 2004, Christoph Hellwig wrote:

> On Wed, Apr 21, 2004 at 08:39:59PM +0800, raven@themaw.net 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


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21 13:52             ` 2.6.6-rc1-mm1 raven
@ 2004-04-21 14:56               ` Christoph Hellwig
  2004-04-21 15:39                 ` 2.6.6-rc1-mm1 raven
  0 siblings, 1 reply; 30+ messages in thread
From: Christoph Hellwig @ 2004-04-21 14:56 UTC (permalink / raw)
  To: raven; +Cc: Andrew Morton, viro, linux-kernel

On Wed, Apr 21, 2004 at 09:52:01PM +0800, raven@themaw.net wrote:
> > On Wed, Apr 21, 2004 at 08:39:59PM +0800, raven@themaw.net 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.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21 14:56               ` 2.6.6-rc1-mm1 Christoph Hellwig
@ 2004-04-21 15:39                 ` raven
  0 siblings, 0 replies; 30+ messages in thread
From: raven @ 2004-04-21 15:39 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, viro, linux-kernel

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


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21 13:18           ` 2.6.6-rc1-mm1 Christoph Hellwig
  2004-04-21 13:34             ` 2.6.6-rc1-mm1 raven
@ 2004-04-21 15:52             ` raven
  2004-04-21 16:09               ` 2.6.6-rc1-mm1 Christoph Hellwig
  1 sibling, 1 reply; 30+ messages in thread
From: raven @ 2004-04-21 15:52 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, Al Viro, Kernel Mailing List

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.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: 2.6.6-rc1-mm1
  2004-04-21 15:52             ` 2.6.6-rc1-mm1 raven
@ 2004-04-21 16:09               ` Christoph Hellwig
  0 siblings, 0 replies; 30+ messages in thread
From: Christoph Hellwig @ 2004-04-21 16:09 UTC (permalink / raw)
  To: raven; +Cc: Andrew Morton, Al Viro, Kernel Mailing List

On Wed, Apr 21, 2004 at 11:52:18PM +0800, raven@themaw.net 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 :)


^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2004-04-21 16:10 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-19  6:01 2.6.6-rc1-mm1 Andrew Morton
2004-04-19  6:29 ` 2.6.6-rc1-mm1 William Lee Irwin III
2004-04-19  6:42   ` 2.6.6-rc1-mm1 Andrew Morton
2004-04-19  6:49     ` 2.6.6-rc1-mm1 William Lee Irwin III
2004-04-19  7:06       ` 2.6.6-rc1-mm1 William Lee Irwin III
2004-04-19 18:39         ` bitmap, cpumask_arith (was: 2.6.6-rc1-mm1) Paul Jackson
2004-04-20 21:17           ` Paul Jackson
2004-04-20 21:38             ` William Lee Irwin III
2004-04-19  6:58   ` 2.6.6-rc1-mm1 Nick Piggin
2004-04-19  9:13 ` 2.6.6-rc1-mm1 failure: kmod.o didn't compile with module-less setup Helge Hafting
2004-04-19  9:17   ` Andrew Morton
2004-04-19 15:26 ` 2.6.6-rc1-mm1 (compile stats) John Cherry
2004-04-19 19:25 ` 2.6.6-rc1-mm1 Christoph Hellwig
2004-04-20  1:13   ` 2.6.6-rc1-mm1 Ian Kent
2004-04-20  1:26     ` 2.6.6-rc1-mm1 Andrew Morton
2004-04-21  9:08       ` 2.6.6-rc1-mm1 Christoph Hellwig
2004-04-21 12:31         ` 2.6.6-rc1-mm1 raven
2004-04-21 13:18           ` 2.6.6-rc1-mm1 Christoph Hellwig
2004-04-21 13:34             ` 2.6.6-rc1-mm1 raven
2004-04-21 15:52             ` 2.6.6-rc1-mm1 raven
2004-04-21 16:09               ` 2.6.6-rc1-mm1 Christoph Hellwig
2004-04-21 12:39         ` 2.6.6-rc1-mm1 raven
2004-04-21 13:19           ` 2.6.6-rc1-mm1 Christoph Hellwig
2004-04-21 13:52             ` 2.6.6-rc1-mm1 raven
2004-04-21 14:56               ` 2.6.6-rc1-mm1 Christoph Hellwig
2004-04-21 15:39                 ` 2.6.6-rc1-mm1 raven
2004-04-20 14:27 ` 2.6.6-rc1-mm1 raven
2004-04-20 15:06 ` 2.6.6-rc1-mm1 Rik van Riel
2004-04-21  7:37   ` 2.6.6-rc1-mm1 Sean Neakums
2004-04-21 12:16     ` 2.6.6-rc1-mm1 Hugh Dickins

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).