Discussion:
2.6.19 -mm merge plans
(too old to reply)
Andrew Morton
2006-09-20 20:55:40 UTC
Permalink
A wander through the -mm patch queue, along with some commentary on my
intentions.


When replying to this email, please rewrite the Subject: to something
appropriate. Please also attempt to cc the appropriate developer(s).


There are quite a lot of patches here which belong in subsystem trees.
I'll patchbomb the relevant maintainers soon. Could I pleeeeeze ask that
they either merge the patches or solidly nack them (with reasons)? Don't
just ignore it all and leave me hanging onto this stuff for ever. Thanks.





autofs4-zero-timeout-prevents-shutdown.patch
rtc-lockdep-fix-workaround.patch
fix-longstanding-load-balancing-bug-in-the-scheduler.patch
trigger-a-syntax-error-if-percpu-macros-are-incorrectly-used.patch
allow-file-systems-to-manually-d_move-inside-of-rename.patch
jbd-fix-commit-of-ordered-data-buffers.patch
update-to-the-kernel-kmap-kunmap-api.patch

Misc random patches.

Will merge most of these, subject to re-review.

acpi-fix-section-for-cpu-init-functions.patch
acpi-fix-printk-format-warnings.patch
acpi-sci-interrupt-source-override.patch
acpi-clear-gpe-before-disabling-it.patch
asus_acpi-fix-proc-files-parsing.patch
asus_acpi-dont-printk-on-writing-garbage-to-proc-files.patch
acpi-mwait-c-state-fixes.patch
acpi-check-if-parent-is-on-dock.patch
acpi-add-removable-drive-bay-support.patch
fix-incorrect-handling-of-pci-express-root-bridge-_hid.patch

ACPI queue -> Len

sound-core-use-seek_set-cur.patch
opl4-use-seek_set-cur.patch
gus-use-seek_set-cur.patch
mixart-use-seek_set-cur.patch

ALSA queue -> Jaroslav

remove-silly-messages-from-input-layer.patch
stowaway-keyboard-support.patch
stowaway-keyboard-support-update.patch
stowaway-vs-driver-tree.patch
input-i8042-disable-keyboard-port-when-panicking-and-blinking.patch
i8042-activate-panic-blink-only-in-x.patch
wistron-fix-detection-of-special-buttons.patch

Input queue -> Dmitry

kerneldoc-error-on-ata_piixc.patch
libata-add-40pin-short-cable-support-honour-drive.patch
libata-add-40pin-short-cable-support-honour-drive-fix.patch
1-of-2-jmicron-driver.patch
1-of-2-jmicron-driver-fix.patch
2-of-2-jmicron-driver-plumbing-and-quirk.patch
2-of-2-jmicron-driver-plumbing-and-quirk-cleanup.patch
non-libata-driver-for-jmicron-devices.patch
via-pata-controller-xfer-fixes.patch
via-pata-controller-xfer-fixes-fix.patch
via-sata-oops-on-init.patch

ATA stuff. I am hopelessly confused regarding which patches pertain to
sata, which to pata and which to legacy IDE. It's a matter of weeding
through all of these and finding an appropriate route to get them merged.

mtd-maps-ixp4xx-partition-parsing.patch
fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch
mtd-printk-format-warning.patch
fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
drivers-mtd-nand-au1550ndc-removal-of-old-code.patch

MTD queue -> dwmw2

e1000-memory-leak-in-e1000_set_ringparam.patch
3x59x-fix-pci-resource-management.patch
update-smc91x-driver-with-arm-versatile-board-info.patch
drivers-net-acenicc-removal-of-old-code.patch
drivers-net-tokenring-lanstreamerc-removal-of-old-code.patch
drivers-net-tokenring-lanstreamerh-removal-of-old-code.patch
drivers-net-typhoonc-removal-of-old-code.patch
signedness-issue-in-drivers-net-phy-phy_devicec.patch
b44-fix-eeprom-endianess-issue.patch
fix-possible-null-ptr-deref-in-forcedeth.patch
ip100a-fix-tx-pause-bug-reset_tx-intr_handler.patch
ip100a-change-phy-address-search-from-phy=1-to-phy=0.patch
ip100a-correct-initial-and-close-hardware-step.patch
ip100a-solve-host-error-problem-in-low-performance.patch
forcedeth-hardirq-lockdep-warning.patch
drivers-net-ns83820c-add-paramter-to-disable-auto.patch
natsemi-add-support-for-using-mii-port-with-no-phy.patch
tulip-fix-shutdown-dma-irq-race.patch
tulip-fix-for-64-bit-mips.patch
tulip-natsemi-dp83840a-phy-fix.patch

netdev queue -> Jeff

net-ipv6-bh_lock_sock_nested-on-tcp_v6_rcv.patch
via-ircc-fix-memory-leak.patch
atm-he-fix-section-mismatch.patch
add-netpoll-netconsole-support-to-vlan-devices.patch
neighbourc-pneigh_get_next-skips-published-entry.patch

net queue -> davem

add-newline-to-nfs-dprintk.patch
fs-nfs-make-code-static.patch

NFS queue -> Trond.

The NFS git tree breaks autofs4 submounts. Still.

pcmcia-update-alloc_io_space-for-conflict-checking-for-multifunction-pc-card-for-linux-kernel-26154.patch
pcmcia-ds-must_check-fixes.patch
config_pm=n-slim-drivers-pcmcia.patch
i82092-wire-up-errors-from-pci_register_driver.patch
drivers-net-pcmcia-xirc2ps_csc-remove-unused-label.patch
pcmcia-au1000_generic-fix.patch

PCMCIA queue -> Dominik

ppc-fix-typo-in-cpm2h.patch
ppc-sbc8560-fixes.patch

PPC queue -> Paul

drivers-returning-proper-error-from-serial-driver.patch
tickle-nmi-watchdog-on-serial-output.patch
tickle-nmi-watchdog-on-serial-output-fix.patch
config_pm=n-slim-drivers-serial-8250_pcic.patch
omap1510-serial-fix-for-115200-baud.patch
magic-sysrq-sak-does-nothing-on-serial-consoles.patch
8250-uart-backup-timer.patch

Serial queue -> Russell

via-irq-quirk-behaviour-change.patch
pcie-check-and-return-bus_register-errors-fix.patch
pci-add-ich7-8-acpi-gpio-io-resource-quirks.patch
pci-quirks-update.patch

PCI queue -> Greg

git-scsi-misc-nlmsg_multicast-fix.patch
drivers-scsi-aic7xxx-possible-cleanups.patch
drivers-scsi-small-cleanups.patch
drivers-scsi-qla2xxx-make-some-functions-static.patch
drivers-scsi-aic7xxx-aic79xx_corec-make-ahd_match_scb-static.patch
aic7xxx-deinline-large-functions-save-80k-of-text.patch
aic7xxx-s-__inline-inline.patch
aic7xxx-fix-byte-i-o-order-in-ahd_inw.patch
drivers-scsi-aic7xxx-possible-cleanups-2.patch
scsi-clean-up-warnings-in-advansys-driver.patch
drivers-scsi-advansysc-cleanups.patch
dc395x-fix-printk-format-warning.patch
make-drivers-scsi-aic7xxx-aic79xx_coreahd_set_tags-static.patch
pci_module_init-conversion-in-scsi-subsys-2nd-try.patch
megaraid-gcc-41-warning-fix.patch
megaraid-fix-warnings-when-config_proc_fs=n.patch
megaraid-use-the-proper-type-to-hold-the-irq-number.patch
drivers-scsi-dpt-dpti_i2oh-removal-of-old.patch
drivers-scsi-gdthh-removal-of-old-scsi-code.patch
drivers-scsi-nsp32h-removal-of-old-scsi-code.patch
drivers-scsi-pcmcia-nsp_csh-removal-of-old.patch
drivers-message-fusion-linux_compath-removal-of-old-code.patch
signedness-issue-in-drivers-scsi-iprc.patch
signedness-issue-in-drivers-scsi-osstc.patch
bodge-scsi-misc-module-reference-count-checks-with-no-module_unload.patch
scsi-remove-seagateh.patch
scsi-seagate-scsi_cmnd-conversion.patch
aha152x-fix.patch
3w-xxxx-fix-ata-udma-upgrade-message-number.patch
scsi-included-header-cleanup.patch

SCSI queue -> James

gregkh-usb-usb-storage-add-rio-karma-eject-support-fix.patch
fix-gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch
gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure-2.patch
usb-storage-unusual_devsh-entry-for-sony.patch
microtek-usb-scanner-scsi_cmnd-conversion.patch
usb-force-root-hub-resume-after-power-loss.patch
usb-fix-root-hub-resume-when-config_usb_suspend-is-not-set.patch

USB queue -> Greg

revert-x86_64-mm-i386-remove-lock-section.patch
unwinder-warning-fixes.patch
fix-x86_64-mm-i386-backtrace-ebp-fallback.patch
fix-x86_64-mm-i386-pda-smp-processorid.patch
fix-x86_64-mm-spinlock-cleanup.patch
x86-remaining-pda-patches.patch

x86/x86_64 queue -> Andi

hot-add-mem-x86_64-fixup-externs.patch
hot-add-mem-x86_64-kconfig-changes.patch
hot-add-mem-x86_64-enable-sparsemem-in-sratc.patch
hot-add-mem-x86_64-memory_add_physaddr_to_nid-enable.patch
hot-add-mem-x86_64-memory_add_physaddr_to_nid-node-fixup.patch
hot-add-mem-x86_64-memory_add_physaddr_to_nid-node-fixup-fix.patch
hot-add-mem-x86_64-memory_add_physaddr_to_nid-node-fixup-fix-2.patch
hot-add-mem-x86_64-use-config_memory_hotplug_sparse.patch
hot-add-mem-x86_64-use-config_memory_hotplug_reserve.patch
hot-add-mem-x86_64-use-config_memory_hotplug_reserve-fix.patch

Will merge.

xfs-add-lock-annotations-to-xfs_trans_update_ail-and-xfs_trans_delete_ail.patch
fs-xfs-xfs_dmapih-removal-of-old-code.patch
xfs-rename-uio_read.patch

XFS queue -> xfs-masters

touchkit-ps-2-touchscreen-driver.patch

Having trouble getting rid of this. Will send to Dmitry.

mm-thrash-detect-process-thrashing-against-itself.patch

Might drop this.

mm-vm_bug_on.patch
radix-tree-rcu-lockless-readside.patch
redo-radix-tree-fixes.patch
adix-tree-rcu-lockless-readside-update.patch
radix-tree-rcu-lockless-readside-semicolon.patch
adix-tree-rcu-lockless-readside-update-tidy.patch
adix-tree-rcu-lockless-readside-fix-2.patch
adix-tree-rcu-lockless-readside-fix-3.patch
radix-tree-cleanup-radix_tree_deref_slot-and.patch
cleanup-radix_tree_derefreplace_slot-calling-conventions.patch
cleanup-radix_tree_derefreplace_slot-calling-conventions-warning-fixes.patch
mm-tracking-shared-dirty-pages.patch
mm-tracking-shared-dirty-pages-nommu-fix-2.patch
mm-balance-dirty-pages.patch
mm-optimize-the-new-mprotect-code-a-bit.patch
mm-small-cleanup-of-install_page.patch
mm-fixup-do_wp_page.patch
mm-msync-cleanup.patch
mm-tracking-shared-dirty-pages-checks.patch
mm-tracking-shared-dirty-pages-wimp.patch
mm-make-functions-static.patch
convert-i386-numa-kva-space-to-bootmem.patch
convert-i386-numa-kva-space-to-bootmem-tidy.patch
bootmem-remove-useless-__init-in-header-file.patch
bootmem-mark-link_bootmem-as-part-of-the-__init-section.patch
bootmem-remove-useless-parentheses-in-bootmem-header.patch
bootmem-limit-to-80-columns-width.patch
bootmem-remove-useless-headers-inclusions.patch
bootmem-use-pfn-page-conversion-macros.patch
bootmem-miscellaneous-coding-style-fixes.patch
reduce-max_nr_zones-remove-two-strange-uses-of-max_nr_zones.patch
reduce-max_nr_zones-fix-max_nr_zones-array-initializations.patch
reduce-max_nr_zones-make-display-of-highmem-counters-conditional-on-config_highmem.patch
reduce-max_nr_zones-make-display-of-highmem-counters-conditional-on-config_highmem-tidy.patch
reduce-max_nr_zones-move-highmem-counters-into-highmemc-h.patch
reduce-max_nr_zones-move-highmem-counters-into-highmemc-h-fix.patch
reduce-max_nr_zones-page-allocator-zone_highmem-cleanup.patch
reduce-max_nr_zones-use-enum-to-define-zones-reformat-and-comment.patch
reduce-max_nr_zones-use-enum-to-define-zones-reformat-and-comment-cleanup.patch
reduce-max_nr_zones-use-enum-to-define-zones-reformat-and-comment-fix.patch
reduce-max_nr_zones-make-zone_dma32-optional.patch
reduce-max_nr_zones-make-zone_highmem-optional.patch
reduce-max_nr_zones-make-zone_highmem-optional-fix.patch
reduce-max_nr_zones-make-zone_highmem-optional-fix-fix.patch
reduce-max_nr_zones-make-zone_highmem-optional-fix-fix-fix.patch
reduce-max_nr_zones-remove-display-of-counters-for-unconfigured-zones.patch
reduce-max_nr_zones-remove-display-of-counters-for-unconfigured-zones-s390-fix.patch
reduce-max_nr_zones-remove-display-of-counters-for-unconfigured-zones-s390-fix-fix.patch
reduce-max_nr_zones-fix-i386-srat-check-for-max_nr_zones.patch
mempolicies-fix-policy_zone-check.patch
apply-type-enum-zone_type.patch
apply-type-enum-zone_type-fix.patch
linearly-index-zone-node_zonelists.patch
out-of-memory-notifier.patch
out-of-memory-notifier-tidy.patch
cpu-hotplug-compatible-alloc_percpu.patch
cpu-hotplug-compatible-alloc_percpu-fix.patch
cpu-hotplug-compatible-alloc_percpu-fix-2.patch
add-kerneldocs-for-some-functions-in-mm-memoryc.patch
mm-remove_mapping-safeness.patch
mm-remove_mapping-safeness-fix.patch
mm-non-syncing-lock_page.patch
slab-respect-architecture-and-caller-mandated-alignment.patch
mm-swap-write-failure-fixup.patch
mm-swap-write-failure-fixup-update.patch
mm-swap-write-failure-fixup-fix.patch
oom-use-unreclaimable-info.patch
oom-reclaim_mapped-on-oom.patch
oom-cpuset-hint.patch
oom-handle-current-exiting.patch
oom-handle-oom_disable-exiting.patch
oom-swapoff-tasks-tweak.patch
oom-kthread-infinite-loop-fix.patch
oom-more-printk.patch
bootmem-use-max_dma_address-instead-of-low32limit.patch
add-some-comments-to-slabc.patch
#mm-speculative-get_page.patch
#mm-speculative-get_page-uninlining.patch
#mm-speculative-get_page-fix.patch
#mm-lockless-pagecache.patch
update-some-mm-comments.patch
slab-optimize-kmalloc_node-the-same-way-as-kmalloc.patch
slab-optimize-kmalloc_node-the-same-way-as-kmalloc-fix.patch
slab-extract-__kmem_cache_destroy-from-kmem_cache_destroy.patch
slab-do-not-panic-when-alloc_kmemlist-fails-and-slab-is-up.patch
slab-fix-lockdep-warnings.patch
slab-fix-lockdep-warnings-fix.patch
slab-fix-lockdep-warnings-fix-2.patch
add-__gfp_thisnode-to-avoid-fallback-to-other-nodes-and-ignore.patch
add-__gfp_thisnode-to-avoid-fallback-to-other-nodes-and-ignore-fix.patch
sys_move_pages-do-not-fall-back-to-other-nodes.patch
guarantee-that-the-uncached-allocator-gets-pages-on-the-correct.patch
cleanup-add-zone-pointer-to-get_page_from_freelist.patch
profiling-require-buffer-allocation-on-the-correct-node.patch
define-easier-to-handle-gfp_thisnode.patch
fix-potential-stack-overflow-in-mm-slabc.patch
standardize-pxx_page-macros.patch
standardize-pxx_page-macros-fix.patch
optimize-free_one_page.patch
do-not-check-unpopulated-zones-for-draining-and-counter.patch
extract-the-allocpercpu-functions-from-the-slab-allocator.patch
introduce-mechanism-for-registering-active-regions-of-memory.patch
have-power-use-add_active_range-and-free_area_init_nodes.patch
have-power-use-add_active_range-and-free_area_init_nodes-ppc-fix.patch
have-x86-use-add_active_range-and-free_area_init_nodes.patch
have-x86-use-add_active_range-and-free_area_init_nodes-fix.patch
have-x86_64-use-add_active_range-and-free_area_init_nodes.patch
have-ia64-use-add_active_range-and-free_area_init_nodes.patch
have-ia64-use-add_active_range-and-free_area_init_nodes-fix.patch
account-for-memmap-and-optionally-the-kernel-image-as-holes.patch
account-for-memmap-and-optionally-the-kernel-image-as-holes-fix.patch
account-for-holes-that-are-outside-the-range-of-physical-memory.patch
allow-an-arch-to-expand-node-boundaries.patch
replace-min_unmapped_ratio-by-min_unmapped_pages-in-struct-zone.patch
zvc-support-nr_slab_reclaimable--nr_slab_unreclaimable.patch
zone_reclaim-dynamic-slab-reclaim.patch
zone_reclaim-dynamic-slab-reclaim-tidy.patch
zone-reclaim-with-slab-avoid-unecessary-off-node-allocations.patch
oom-kill-update-comments-to-reflect-current-code.patch
hugepages-use-page_to_nid-rather-than-traversing-zone-pointers.patch
numa-add-zone_to_nid-function.patch
numa-add-zone_to_nid-function-update.patch
vm-add-per-zone-writeout-counter.patch
own-header-file-for-struct-page.patch
convert-s390-page-handling-macros-to-functions.patch
convert-s390-page-handling-macros-to-functions-fix.patch
page-invalidation-cleanup.patch
slab-fix-kmalloc_node-applying-memory-policies-if-nodeid-==-numa_node_id.patch
slab-fix-kmalloc_node-applying-memory-policies-if-nodeid-==-numa_node_id-fix.patch
condense-output-of-show_free_areas.patch
add-numa_build-definition-in-kernelh-to-avoid-ifdef.patch
disable-gfp_thisnode-in-the-non-numa-case.patch
gfp_thisnode-for-the-slab-allocator-v2.patch
gfp_thisnode-for-the-slab-allocator-v2-fix.patch
add-node-to-zone-for-the-numa-case.patch
add-node-to-zone-for-the-numa-case-fix.patch
get-rid-of-zone_table.patch
get-rid-of-zone_table-fix.patch
do-not-allocate-pagesets-for-unpopulated-zones.patch
zone_statistics-use-hot-node-instead-of-cold-zone_pgdat.patch
deal-with-cases-of-zone_dma-meaning-the-first-zone.patch
introduce-config_zone_dma.patch
optional-zone_dma-in-the-vm.patch
optional-zone_dma-in-the-vm-tidy.patch
optional-zone_dma-for-i386.patch
optional-zone_dma-for-x86_64.patch
optional-zone_dma-for-ia64.patch
remove-zone_dma-remains-from-parisc.patch
remove-zone_dma-remains-from-sh-sh64.patch
mm-micro-optimise-zone_watermark_ok.patch

Memory management queue (big, isn't it?). Will merge.

acx1xx-wireless-driver.patch
fix-tiacx-on-alpha.patch
tiacx-fix-attribute-packed-warnings.patch
tiacx-pci-build-fix.patch
tiacx-ia64-fix.patch
tiacx-build-fix.patch
tiacx-sparse-cleanups.patch

We're unable to work out whether this is safe to merge (it's
reverse-engineered). I might drop it.

selinux-eliminate-selinux_task_ctxid.patch
selinux-rename-selinux_ctxid_to_string.patch
selinux-replace-ctxid-with-sid-in.patch
selinux-enable-configuration-of-max-policy-version.patch
selinux-enable-configuration-of-max-policy-version-improve-security_selinux_policydb_version_max_value-help-texts.patch
selinux-add-support-for-range-transitions-on-object.patch
selinux-1-3-eliminate-inode_security_set_security.patch
selinux-2-3-change-isec-semaphore-to-a-mutex.patch
selinux-3-3-convert-sbsec-semaphore-to-a-mutex.patch
selinux-fix-tty-locking.patch

Will merge.

binfmt_elf-consistently-use-loff_t.patch

Will merge.

frv-use-the-generic-irq-stuff.patch
frv-improve-frvs-use-of-generic-irq-handling.patch
frv-permit-__do_irq-to-be-dispensed-with.patch
frv-fix-fls-to-handle-bit-31-being-set-correctly.patch
frv-implement-fls64.patch
frv-optimise-ffs.patch

Will merge

alchemy-delete-unused-pt_regs-argument-from-au1xxx_dbdma_chan_alloc.patch

MIPS-related IDE changes. Will merge.

avr32-arch.patch
avr32-config_debug_bugverbose-and-config_frame_pointer.patch
avr32-fix-invalid-constraints-for-stcond.patch
avr32-add-support-for-irq-flags-state-tracing.patch
avr32-turn-off-support-for-discontigmem-and-sparsemem.patch
avr32-always-enable-config_embedded.patch
avr32-export-the-find__bit-functions.patch
avr32-add-defconfig-for-at32stk1002.patch
avr32-use-autoconf-instead-of-marker.patch
avr32-dont-assume-anything-about-max_nr_zones.patch
avr32-add-i-o-port-access-primitives.patch
avr32-use-linux-pfnh.patch
avr32-kill-config_discontigmem-support-completely.patch
avr32-fix-bug-in-__avr32_asr64.patch
avr32-switch-to-generic-timekeeping-framework.patch
avr32-set-kbuild_defconfig.patch
avr32-kprobes-compile-fix.patch
avr32-asm-ioh-should-include-asm-byteorderh.patch
avr32-fix-output-constraints-in-asm-bitopsh.patch
avr32-standardize-pxx_page-macros-fix.patch
avr32-rename-at32stk100x-atstk100x.patch
avr32-dont-leave-dbe-set-when-resetting-cpu.patch
avr32-make-prot_write-prot_exec-imply-prot_read.patch
avr32-remove-set_wmb.patch
avr32-use-parse_early_param.patch
avr32-fix-exported-headers.patch
avr32-fix-__const_udelay-overflow-bug.patch
remove-zone_dma-remains-from-avr32.patch

AVR32 architecture. Will fold into a single patch, and will merge.

avr32-mtd-static-memory-controller-driver-try-2.patch
avr32-mtd-at49bv6416-platform-device-for-atstk1000.patch
avr32-mtd-unlock-flash-if-necessary.patch

MTD changes for avr32. Will send to dwmw2.

nommu-check-that-access_process_vm-has-a-valid-target.patch
nommu-set-bdi-capabilities-for-dev-mem-and-dev-kmem.patch
nommu-set-bdi-capabilities-for-dev-mem-and-dev-kmem-tidy.patch
nommu-use-find_vma-rather-than-reimplementing-a-vma-search.patch
check-if-start-address-is-in-vma-region-in-nommu-function-get_user_pages.patch
nommu-check-vma-protections.patch
nommu-permit-ptrace-to-ignore-non-prot_write-vmas-in-nommu-mode.patch
nommu-implement-proc-pid-maps-for-nommu.patch
nommu-order-the-per-mm_struct-vma-list.patch
nommu-make-mremap-partially-work-for-nommu-kernels.patch
nommu-add-docs-about-shared-memory.patch
nommu-make-futexes-work-under-nommu-conditions.patch
nommu-make-futexes-work-under-nommu-conditions-doc.patch
nommu-move-the-fallback-arch_vma_name-to-a-sensible-place.patch
nommu-move-the-fallback-arch_vma_name-to-a-sensible-place-fix.patch

Will merge.

hpet-rtc-emulation-add-watchdog-timer-2.patch
sleazy-fpu-feature-i386-support.patch
add-seccomp_disable_tsc-config-option.patch
i386-fix-recursive-faults-during-oops-when-current.patch
i386-show_registers-try-harder-to-print-failing.patch
use-bug_onfoo-instead-of-if-foo-bug-in-include-asm-i386-dma-mappingh.patch
apm-clean-up-module-initalization.patch
x86-remove-locally-defined-ldt-structure-in-favour-of-standard-type.patch
x86-implement-always-locked-bit-ops-for-memory-shared-with-an-smp-hypervisor.patch
x86-roll-all-the-cpuid-asm-into-one-__cpuid-call.patch
x86-make-__fixaddr_top-variable-to-allow-it-to-make-space-for-a-hypervisor.patch
x86-add-a-bootparameter-to-reserve-high-linear-address-space.patch
x86-put-note-sections-into-a-pt_note-segment-in-vmlinux.patch
x86-put-note-sections-into-a-pt_note-segment-in-vmlinux-fix.patch
x86-enable-vmsplit-for-highmem-kernels.patch
x86-trivial-pgtableh-__assembly__-move.patch
x86-trivial-move-of-__have-macros-in-i386-pagetable-headers.patch
x86-trivial-move-of-ptep_set_access_flags.patch
x86-remove-unused-include-from-efi_stubs.patch
i386-adds-smp_call_function_single.patch
voyager-tty-locking.patch
i386-kill-references-to-xtime.patch
mtrr-add-lock-annotations-for-prepare_set-and.patch
x86-remove-default_ldt-and-simplify-ldt-setting.patch
i386-adds-smp_call_function_single-fix.patch

Random x86 things. Will merge.

I think from hereon I'll be sending all x86 updates through Andi.

convert-i386-summit-subarch-to-use-srat-info-for-apicid_to_node-calls.patch
convert-i386-summit-subarch-to-use-srat-info-for-apicid_to_node-calls-tidy.patch

This patch causes bad performance regression on NUMAQ. Won't merge until
that is resolved.

alpha-fix-alpha_ev56-dependencies-typo.patch

Will merge.

swsusp-write-timer.patch
swsusp-write-speedup.patch
swsusp-read-timer.patch
swsusp-read-speedup.patch
swsusp-read-speedup-fix.patch
swsusp-read-speedup-cleanup.patch
swsusp-read-speedup-cleanup-2.patch
swsusp-read-speedup-fix-fix-2.patch
swsusp-clean-up-browsing-of-pfns.patch
swsusp-struct-snapshot_handle-cleanup.patch
make-swsusp-avoid-memory-holes-and-reserved-memory-regions-on-x86_64.patch
disable-cpu-hotplug-during-suspend-2.patch
swsusp-fix-mark_free_pages.patch
swsusp-reorder-memory-allocating-functions.patch
swsusp-fix-alloc_pagedir.patch
clean-up-suspend-header.patch
change-the-name-of-pagedir_nosave.patch
swsusp-introduce-some-helpful-constants.patch
swsusp-introduce-memory-bitmaps.patch
swsusp-use-memory-bitmaps-during-resume.patch
swsusp-use-memory-bitmaps-during-resume-fix.patch
swsusp-use-suspend_console.patch
pm-make-it-possible-to-disable-console-suspending.patch
pm-make-it-possible-to-disable-console-suspending-fix.patch
pm-make-it-possible-to-disable-console-suspending-fix-2.patch
make-it-possible-to-disable-serial-console-suspend.patch
i386-detect-clock-skew-during-suspend.patch
pm-add-pm_trace-switch.patch
pm-add-pm_trace-switch-doc.patch

Will merge.

uml-use-klibc-setjmp-longjmp.patch
uml-use-array_size-more-assiduously.patch
uml-fix-stack-alignment.patch
uml-whitespace-fixes.patch
uml-fix-handling-of-failed-execs-of-helpers.patch
uml-improve-sigbus-diagnostics.patch
uml-sigio-cleanups.patch
uml-move-signal-handlers-to-arch-code.patch
uml-move-signal-handlers-to-arch-code-fix.patch
uml-timer-cleanups.patch
uml-remove-unused-variable.patch
uml-clean-our-set_ether_mac.patch
uml-stack-usage-reduction.patch
uml-tty-locking.patch
split-i386-and-x86_64-ptraceh.patch
split-i386-and-x86_64-ptraceh-fix.patch
make-uml-use-ptrace-abih.patch

Will merge.

uml-use-mcmodel=kernel-for-x86_64.patch
uml-fix-proc-vs-interrupt-context-spinlock-deadlock.patch

These are on hold. I'll poll Jeff.

uml-remove-pte_mkexec.patch

This is "-mm only"

s390-fix-cmm-kernel-thread-handling.patch

Will merge.

deprecate-smbfs-in-favour-of-cifs.patch

Will poll sfrench, see if we're ready to switch everyone over to CIFS yet.

block-layer-early-detection-of-medium-not-present.patch
scsi-core-and-sd-early-detection-of-medium-not-present.patch
sd-early-detection-of-medium-not-present.patch

James has issues with these. Will poll him and will drop them if that's
negative.

scsi-early-detection-of-medium-not-present-updated.patch

-> James

edac-new-opteron-athlon64-memory-controller-driver.patch
edac-new-opteron-athlon64-memory-controller-driver-tidy.patch

There was a bunfight over these which I need to reignite so we can get some
closure.

add-address_space_operationsbatch_write.patch
add-address_space_operationsbatch_write-fix.patch
pass-io-size-to-batch_write-address-space-operation.patch

These add a new address_space operation. For reiser4, with potential for
use by other filesystems.

Problem is, 2.6.18 has a significant writev() performace regression on NFS
and probably on other filesystems. Because 2.6.18 does
prepare_write/commit_write for each iovec segment. We want to go back to
copying mulitple iovec segments within a single prepare_write/commit_write.

Plus there's still the possible deadlock in our standard write() function
(thw thing which fault_in_pages_readable() tries to prevent).

All of this should be fixed. But these new patches ehshrine the
one-prepare_write-per-segment concept in the filemap.c function layout.
These patches should be dropped.

autofs4-needs-to-force-fail-return-revalidate.patch
kdump-introduce-reset_devices-command-line-option.patch
drivers-edac-make-code-static.patch
fat-cleanup-fat_get_blocks.patch
inode_diet-replace-inodeugeneric_ip-with-inodei_private.patch
inode_diet-replace-inodeugeneric_ip-with-inodei_private-gfs-fix.patch
inode-diet-move-i_pipe-into-a-union.patch
inode-diet-move-i_bdev-into-a-union.patch
inode-diet-move-i_cdev-into-a-union.patch
inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch
inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-fix.patch
inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-fix-fix.patch
reiserfs-warn-about-the-useless-nolargeio-option.patch
x86-microcode-microcode-driver-cleanup.patch
x86-microcode-microcode-driver-cleanup-tidy.patch
x86-microcode-using-request_firmware-to-pull-microcode.patch
x86-microcode-add-sysfs-and-hotplug-support.patch
x86-microcode-add-sysfs-and-hotplug-support-fix.patch
x86-microcode-add-sysfs-and-hotplug-support-fix-fix-2.patch
x86-microcode-dont-check-the-size.patch
consistently-use-max_errno-in-__syscall_return.patch
consistently-use-max_errno-in-__syscall_return-fix.patch
eisa-bus-modalias-attributes-support-1.patch
eisa-bus-modalias-attributes-support-1-fix.patch
eisa-bus-modalias-attributes-support-1-fix-git-kbuild-fix.patch
alloc_fdtable-cleanup.patch
include-__param-section-in-read-only-data-range.patch
msi-use-kmem_cache_zalloc.patch
sysctl-allow-proc-sys-without-sys_sysctl.patch
sysctl-allow-proc-sys-without-sys_sysctl-fix.patch
sysctl-document-that-sys_sysctl-will-be-removed.patch
pid-implement-transfer_pid-and-use-it-to-simplify-de_thread.patch
pid-remove-temporary-debug-code-in-attach_pid.patch
de_thread-use-tsk-not-current.patch
add-probe_kernel_address.patch
x86-use-probe_kernel_address-in-handle_bug.patch
kernel-params-must_check-fixes.patch
blockdevc-check-errors.patch
blockdevc-check-errors-fix.patch
block-handle-subsystem_register-init-errors.patch
fs-namespace-handle-init-registration-errors.patch
make-prot_write-imply-prot_read.patch
debug-variants-of-linked-list-macros.patch
make-touch_nmi_watchdog-imply-touch_softlockup_watchdog-on.patch
make-touch_nmi_watchdog-imply-touch_softlockup_watchdog-on-fix.patch
remove-unnecessary-barrier-in-rtc_get_rtc_time.patch
drivers-char-scx200_gpioc-make-code-static.patch
drivers-char-pc8736x_gpioc-remove-unused-static-functions.patch
let-warn_on-warn_on_once-return-the-condition.patch
let-warn_on-warn_on_once-return-the-condition-fix.patch
let-warn_on-warn_on_once-return-the-condition-fix-2.patch
scx200_gpio-export-cleanups.patch
make-net48xx-led-use-scx200_gpio_ops.patch
libfs-remove-page-up-to-date-check-from-simple_readpage.patch
kernel-doc-for-relay-interface.patch
kernel-doc-move-filesystems-together.patch
kthread-convert-loopc-to-kthread.patch
fs-conversions-from-kmallocmemset-to-kzcalloc.patch
include-documentation-for-functions-in-drivers-base-classc.patch
fix-parameter-names-in-drivers-base-classc.patch
fs-removing-useless-casts.patch
spinlock_debug-dont-recompute-jiffies_per_loop.patch
omap-add-smc91x-support-for-ti-omap2420-h4-board.patch
omap-add-watchdog-driver-support.patch
omap-add-watchdog-driver-support-tweaks.patch
omap-add-keypad-driver-4.patch
omap-update-omap1-2-boards-to-give-keymapsize-and-other.patch
use-gcc-o1-in-fs-reiserfs-only-for-ancient-gcc-versions.patch
irq-fixed-coding-style.patch
irq-removed-a-extra-line.patch
efi-add-lock-annotations-for-efi_call_phys_prelog-and-efi_call_phys_epilog.patch
mbcache-add-lock-annotation-for-__mb_cache_entry_release_unlock.patch
afs-add-lock-annotations-to-afs_proc_cell_servers_startstop.patch
fuse-add-lock-annotations-to-request_end-and-fuse_read_interrupt.patch
hugetlbfs-add-lock-annotation-to-hugetlbfs_forget_inode.patch
lockdep-dont-pull-in-includes-when-lockdep-disabled.patch
jbd-add-lock-annotation-to-jbd_sync_bh.patch
bluetooth-guard-bt_proto-with-rwlock.patch
bluetooth-use-gfp_atomic-in-_sock_creates-sk_alloc.patch
fs-add-lock-annotation-to-grab_super.patch
rcu-add-lock-annotations-to-rcu_bh_torture_read_lockunlock.patch
kthread-drivers-base-firmware_classc.patch
require-mmap-handler-for-aout-executables.patch
module_subsys-initialize-earlier.patch
fuse-use-dentry-in-statfs.patch
vfs-define-new-lookup-flag-for-chdir.patch
timer-add-lock-annotation-to-lock_timer_base.patch
dmi-decode-and-save-oem-string-information.patch
remove-unused-tty_struct-variable.patch
ignore-partition-table-on-disks-with-aix-label.patch
#aio-remove-unused-aio_run_iocbs.patch
task_struct-ifdef-missedem-v-ipc.patch
ifdef-blktrace-debugging-fields.patch
mount-udf-udf_part_flag_read_only-partitions-with-ms_rdonly.patch
fix-intel-rng-detection.patch
rtmutex-clean-up-and-remove-some-extra-spinlocks.patch
rtmutex-clean-up-and-remove-some-extra-spinlocks-more.patch
oom_adj-oom_score-documentation.patch
fix-kerneldoc-comments-in-kernel-timerc.patch
fix-kerneldoc-comments-in-kernel-timerc-fix.patch
there-is-no-devfs-there-has-never-been-a-devfs-we-have.patch
move-valid_dma_direction-from-x86_64-to-generic-code.patch
move-valid_dma_direction-from-x86_64-to-generic-code-fix.patch
use-valid_dma_direction-in-include-asm-i386-dma-mappingh.patch
lsm-remove-bsd-secure-level-security-module.patch
tty_ioc-keep-davej-sane.patch
apple-motion-sensor-driver-2.patch
apple-motion-sensor-driver-2-fixes-update.patch
apple-motion-sensor-driver-kconfig-fix.patch
single-bit-flip-detector.patch
single-bit-flip-detector-tidy.patch
ucb1x00-ts-handle-errors-from-input_register_device.patch
console-utf-8-mode-fixes.patch
make-reiserfs-default-to-barrier=flush.patch
make-ext3-mount-default-to-barrier=1.patch
reiserfs_fsync-should-only-use-barriers-when-they-are-enabled.patch
fix-reiserfs-latencies-caused-by-data=ordered.patch
ifdef-quota_read-quota_write.patch
unwind-fix-unused-variable-warning-when.patch
reiserfs-ifdef-xattr_sem.patch
reiserfs-ifdef-acl-stuff-from-inode.patch
fsh-ifdef-security-fields.patch
oprofile-ppro-need-to-enable-disable-all-the-counters.patch
add-o-flush-for-fat.patch
tty-locking-on-resize.patch
kthread-convert-arch-i386-kernel-apmc.patch
fix-unserialized-task-files-changing.patch
fix-unserialized-task-files-changing-fix.patch
fix-conflict-with-the-is_init-identifier-on-parisc.patch
pidspace-is_init.patch
chardev-checking-of-overlapping-ranges.patch
ahci-ati-sb600-sata-support-for-various-modes.patch
atiixp-ati-sb600-ide-support-for-various-modes.patch
lockdep-print-kernel-version.patch
memory-ordering-in-__kfifo-primitives.patch
small-update-to-credits.patch
fix-wrong-error-code-on-interrupted-close-syscalls.patch
fix-wrong-error-code-on-interrupted-close-syscalls-fix.patch
remove-another-configh.patch
make-ledsh-include-relevant-headers.patch
config_pm=n-slim-drivers-parport-parport_serialc.patch
config_pm=n-slim-sound-oss-tridentc.patch
config_pm=n-slim-sound-oss-cs46xxc.patch
ext3-and-jbd-cleanup-remove-whitespace.patch
remove-old-drivers-char-s3c2410_rtcc.patch
sound-mips-au1x00-use-array_size-macro.patch
sound-sparc-dbri-use-array_size-macro.patch
check-return-value-of-cpu_callback.patch
fix-serial-amba-pl011c-console-kconfig.patch
elf_core_dump-dont-take-tasklist_lock.patch
elf_fdpic_core_dump-dont-take-tasklist_lock.patch
fix-memory-leak-in-vc_resize-vc_allocate.patch
dquot-add-proper-locking-when-using-current-signal-tty.patch
update-documentation-kernel-parameterstxt.patch
posix-timers-fix-clock_nanosleep-doesnt-return-the-remaining-time-in-compatibility-mode-2.patch
posix-timers-fix-the-flags-handling-in-posix_cpu_nsleep-2.patch
i-o-error-attempting-to-read-last-partial-block-of-a-file-in-an-iso9660-file-system.patch
has_stopped_jobs-cleanup.patch
__dequeue_signal-cleanup.patch
simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem-2.patch
kexec-warning-fix.patch
tty-trivial-kzalloc-opportunity.patch
tty-lock-ticogwinsz.patch
tty-stop-the-tty-vanishing-under-procfs-access.patch
exit-fix-crash-case.patch
tty-make-termios_sem-a-mutex.patch
tty-make-termios_sem-a-mutex-fix.patch
cdev-documentation-was-drop-second-arg-of-unregister_chrdev.patch
use-decimal-for-ptrace_attach-and-ptrace_detach.patch
return-better-error-codes-if-drivers-char-rawc-module-init-fails.patch
fix-____call_usermodehelper-errors-being-silently-ignored.patch
kill-extraneous-printk-in-kernel_restart.patch
do_sched_setscheduler-dont-take-tasklist_lock.patch
introduce-is_rt_policy-helper.patch
sched_setscheduler-fix-policy-checks.patch
reparent_to_init-use-has_rt_policy.patch
copy_process-cosmetic-ioprio-tweak.patch
autofs4-autofs4_follow_link-false-negative-fix.patch
autofs4-pending-flag-not-cleared-on-mount-fail.patch
futex_find_get_task-dont-take-tasklist_lock.patch
sys_get_robust_list-dont-take-tasklist_lock.patch
docbook-fix-segfault-in-docprocc.patch
solaris-emulation-incorrect-tty-locking.patch
solaris-emulation-incorrect-tty-locking-fix.patch
solaris-emulation-incorrect-tty-locking-fix-2.patch
tty-fix-bits-and-note-more-bits-to-fix.patch
windfarm_smu_satc-simplify-around-i2c_add_driver.patch
make-spinlock-rwlock-annotations-more-accurate-by-using.patch
replace-_spin_trylock-with-spin_trylock-in-the-irq.patch
ext3-turn-on-reservation-dump-on-block-allocation-errors.patch
ext3-add-more-comments-in-block-allocation-reservation-code.patch
generic-boolean.patch
fs-ntfs-conversion-to-generic-boolean.patch
fs-jfs-conversion-to-generic-boolean.patch
block_devc-mutex_lock_nested-fix.patch
fix-mem_write-return-value.patch
doc-fix-kernel-parameters-quiet.patch
pass-a-lock-expression-to-__cond_lock-like-__acquire-and.patch
cramfs-rewrite-init_cramfs_fs.patch
freevxfs-fix-leak-on-error-path.patch
cramfs-make-cramfs_uncompress_exit-return-void.patch
9p-fix-leak-on-error-path.patch
ban-register_filesystemnull.patch
jbd-use-build_bug_on-in-journal-init.patch
fix-ext3-mounts-at-16t.patch
fix-ext3-mounts-at-16t-fix.patch
fix-ext2-mounts-at-16t.patch
fix-ext2-mounts-at-16t-fix.patch
more-ext3-16t-overflow-fixes.patch
more-ext3-16t-overflow-fixes-fix.patch
ext3-inode-numbers-are-unsigned-long.patch
ext3-inode-numbers-are-unsigned-long-fix.patch
lockdep-core-add-enable-disable_irq_irqsave-irqrestore-apis.patch
really-ignore-kmem_cache_destroy-return-value.patch
make-kmem_cache_destroy-return-void.patch
set-exit_dead-state-in-do_exit-not-in-schedule.patch
kill-pf_dead-flag.patch
introduce-task_dead-state.patch
select_bad_process-kill-a-bogus-pf_dead-task_dead-check.patch
select_bad_process-cleanup-releasing-check.patch
oom_kill_task-cleanup-mm-checks.patch
oom-dont-kill-current-when-another-oom-in-progress.patch
fix-typo-in-rtc-kconfig.patch
cpuset-top_cpuset-tracks-hotplug-changes-to-node_online_map.patch
cpuset-top_cpuset-tracks-hotplug-changes-to-node_online_map-fix.patch
cpuset-top_cpuset-tracks-hotplug-changes-to-node_online_map-fix-2.patch
cpuset-hotunplug-cpus-and-mems-in-all-cpusets.patch
remove-sound-oss-copying.patch
fs-partitions-conversion-to-generic-boolean.patch
loop-forward-port-resource-leak-checks-from-solar.patch
maximum-latency-tracking-infrastructure.patch
maximum-latency-tracking-infrastructure-tidy.patch
maximum-latency-tracking-alsa-support.patch
add-to-maintainers-file.patch
lib-rwsemc-un-inline-rwsem_down_failed_common.patch
add-section-on-function-return-values-to-codingstyle.patch
fs-nameic-replace-multiple-current-fs-by-shortcut-variable.patch
fs-nameic-replace-multiple-current-fs-by-shortcut-variable-tidy.patch
superh-maintainership-change.patch
mem-driver-fix-conditional-on-isa-i-o-support.patch
remove-static-variable-mm-page-writebackctotal_pages.patch
call-mm-page-writebackcset_ratelimit-when-new-pages.patch
call-mm-page-writebackcset_ratelimit-when-new-pages-tidy.patch
valid_swaphandles-fix.patch
mention-documenation-abi-requirements-in-documentation-submitchecklist.patch
rate-limiting-for-the-ldisc-open-failure-messages.patch
lib-ts_fsmc-constify-structs.patch
submittingpatches-cleanups.patch
ibm-acpi-documentation-delete-irrelevant-how-to-compile-external-module.patch
network-block-device-is-mostly-known-as-nbd.patch
superh-list-is-moderated.patch
sys-modules-patch-allow-full-length-section-names.patch
uninitialized-variable-in-drivers-net-wan-syncpppc.patch
enforce-rlimit_nofile-in-poll.patch
generic-infrastructure-for-acls.patch
generic-infrastructure-for-acls-update.patch
access-control-lists-for-tmpfs.patch
access-control-lists-for-tmpfs-cleanup.patch
ext3-wrong-error-behavior.patch
stop_machinec-copyright.patch
build-sound-sound_firmwarec-only-for-oss.patch
build-sound-sound_firmwarec-only-for-oss-doc.patch
rtc-more-xstp-vdet-support-for-rtc-rs5c348-driver.patch
generic_serial-remove-private-decoding-of-baud-rate-bits.patch
istallion-remove-private-baud-rate-decoding-which-is.patch
specialix-remove-private-speed-decoding.patch
fix-locking-for-tty-drivers-when-doing-urgent-characters.patch
audit-accounting-tty-locking.patch
documentation-submittingdrivers-minor-update.patch
clean-up-expand_fdtable-and-expand_files-take-2.patch
expand_fdtable-remove-pointless-unlocklock.patch
kcore-elf-note-namesz-field-fix.patch
lockdep-core-improve-the-lock-chain-hash.patch
linux-kernel-dump-test-module.patch
linux-kernel-dump-test-module-fixes.patch
ext3-more-whitespace-cleanups.patch
ext3-fix-sparse-warnings.patch
submittingpatches-add-a-note-about-format=flowed-when-sending-patches.patch
kmemdup-introduce.patch
kmemdup-some-users.patch
cpuset-fix-obscure-attach_task-vs-exiting-race.patch
create-fs-utimesc.patch
cciss-support-for-2tb-logical-volumes.patch
serial-fix-up-offenders-peering-at-baud-bits-directly.patch
remove-the-old-bd_mutex-lockdep-annotation.patch
new-bd_mutex-lockdep-annotation.patch
codingstyle-cleanup-for-kernel-sysc.patch
allow-proc-configgz-to-be-built-as-a-module.patch
add-config_headers_check-option-to-automatically-run-make-headers_check.patch
add-config_headers_check-option-to-automatically-run-make-headers_check-nobble.patch
pci-via82cxxx_audio-use-pci_get_device.patch
pci-cs46xx-oss-switch-to-pci_get_device.patch
pci-piix-use-refcounted-interface-when-searching-for-a-450nx.patch
pci-serverworks-switch-to-pci-refcounted-interfaces.patch
pci-sis5513-switch-to-pci-refcounting.patch
pci-mtd-switch-to-pci_get_device-and-do-ref-counting.patch
pci-via-switch-to-pci_get_device-refcounted-pci-api.patch
mbcs-use-seek_set-cur.patch
eicon-isdn-removed-unused-definitions-for-os_seek_.patch
vfs-use-seek_set-cur.patch
proper-flags-type-of-spin_lock_irqsave.patch
submit-checklist-mention-headers_check.patch
doc-lockdep-design-explain-display-of-state-bits.patch
leds-turn-led-off-when-changing-triggers.patch
directed-yield-cpu_relax-variants-for-spinlocks-and-rw-locks.patch
directed-yield-direct-yield-of-spinlocks-for-powerpc.patch
directed-yield-direct-yield-of-spinlocks-for-s390.patch
synclink_gt-add-bisync-and-monosync-modes.patch
synclink_gt-increase-max-devices.patch
cciss-remove-unneeded-spaces-in-output-for-attached-volumes-resend.patch

Misc patches. Will merge, subject to re-review.

pass-sparse-the-lock-expression-given-to-lock-annotations.patch

Will merge.

ntp-move-all-the-ntp-related-code-to-ntpc.patch
ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
ntp-add-ntp_update_frequency.patch
ntp-add-ntp_update_frequency-fix.patch
ntp-add-time_adj-to-tick-length.patch
ntp-add-time_freq-to-tick-length.patch
ntp-prescale-time_offset.patch
ntp-add-time_adjust-to-tick-length.patch
ntp-remove-time_tolerance.patch
ntp-convert-time_freq-to-nsec-value.patch
ntp-convert-to-the-ntp4-reference-model.patch
ntp-cleanup-defines-and-comments.patch
kernel-time-ntpc-possible-cleanups.patch
kill-wall_jiffies.patch

Will merge.

reiserfs-fix-is_reusable-bitmap-check-to-not-traverse-the-bitmap-info-array.patch
reiserfs-clean-up-bitmap-block-buffer-head-references.patch
reiserfs-reorganize-bitmap-loading-functions.patch
reiserfs-on-demand-bitmap-loading.patch
reiserfs-use-generic_file_open-for-open-checks.patch
reiserfs-eliminate-minimum-window-size-for-bitmap-searching.patch

Will merge.

vectorize-aio_read-aio_write-fileop-methods.patch
vectorize-aio_read-aio_write-fileop-methods-xfs-fix.patch
vectorize-aio_read-aio_write-fileop-methods-hypfs-fix.patch
remove-readv-writev-methods-and-use-aio_read-aio_write.patch
streamline-generic_file_-interfaces-and-filemap.patch
streamline-generic_file_-interfaces-and-filemap-gfs-fix.patch
add-vector-aio-support.patch
add-vector-aio-support-fix.patch

Will probably merge. It depends upon interactions with the writev() problem
described above.

add-genetlink-utilities-for-payload-length-calculation.patch
fix-taskstats-size-calculation-use-the-new-genetlink-utility-functions.patch
fix-getdelaysc-cpumask-length-and-error-reporting.patch

Will merge.

csa-basic-accounting-over-taskstats.patch
csa-basic-accounting-over-taskstats-fix.patch
csa-extended-system-accounting-over-taskstats.patch
csa-convert-config-tag-for-extended-accounting-routines.patch
csa-accounting-taskstats-update.patch

Will merge.

reiserfs-make-sure-all-dentries-refs-are-released-before-calling-kill_block_super-try-2.patch
fs-cache-provide-a-filesystem-specific-syncable-page-bit.patch
fs-cache-generic-filesystem-caching-facility.patch
fs-cache-release-page-private-in-failed-readahead.patch
fs-cache-release-page-private-after-failed-readahead-12.patch
fs-cache-make-kafs-use-fs-cache.patch
fs-cache-make-kafs-use-fs-cache-fix.patch
fs-cache-make-kafs-use-fs-cache-12.patch
fs-cache-make-kafs-use-fs-cache-12-fix.patch
fs-cache-make-kafs-use-fs-cache-vs-streamline-generic_file_-interfaces-and-filemap.patch
nfs-use-local-caching.patch
nfs-use-local-caching-12.patch
nfs-use-local-caching-12-fix.patch
add-missing-page_copy-export-for-ppc-and-powerpc.patch
fs-cache-cachefiles-ia64-missing-copy_page-export.patch
fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem.patch
fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-cachefiles-printk-format-warning.patch
fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-warning-fixes.patch
fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-cachefiles-cachefiles_write_page-shouldnt-indicate-error-twice.patch
fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-cachefiles-handle-enospc-on-create-mkdir-better.patch
fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-inode-count-maintenance.patch
autofs-make-sure-all-dentries-refs-are-released-before-calling-kill_anon_super.patch
vfs-destroy-the-dentries-contributed-by-a-superblock-on-unmounting.patch

Sigh. Will merge if Trond is OK with it.

r-o-bind-mount-prepare-for-write-access-checks-collapse-if.patch
r-o-bind-mount-prepwork-move-open_nameis-vfs_create.patch
r-o-bind-mount-unlink-monitor-i_nlink.patch
r-o-bind-mount-prepwork-inc_nlink-helper.patch
r-o-bind-mount-clean-up-ocfs2-nlink-handling-2.patch
r-o-bind-mount-monitor-zeroing-of-i_nlink.patch

Will merge.


stack-overflow-safe-kdump-safe_smp_processor_id.patch
stack-overflow-safe-kdump-safe_smp_processor_id_voyager.patch
stack-overflow-safe-kdump-crash_use_safe_smp_processor_id.patch
stack-overflow-safe-kdump-crash_use_safe_smp_processor_id-fix.patch
stack-overflow-safe-kdump-safe_smp_send_nmi_allbutself.patch

Will merge.

generic-ioremap_page_range-implementation.patch
generic-ioremap_page_range-implementation-fix.patch
generic-ioremap_page_range-implementation-nommu-fix.patch
generic-ioremap_page_range-flush_cache_vmap.patch
generic-ioremap_page_range-alpha-conversion.patch
generic-ioremap_page_range-avr32-conversion.patch
generic-ioremap_page_range-cris-conversion.patch
generic-ioremap_page_range-i386-conversion.patch
generic-ioremap_page_range-i386-conversion-fix.patch
generic-ioremap_page_range-m32r-conversion.patch
generic-ioremap_page_range-mips-conversion.patch
generic-ioremap_page_range-mips-conversion-fix.patch
generic-ioremap_page_range-parisc-conversion.patch
generic-ioremap_page_range-s390-conversion.patch
generic-ioremap_page_range-sh-conversion.patch
generic-ioremap_page_range-sh64-conversion.patch
generic-ioremap_page_range-x86_64-conversion.patch
generic-ioremap_page_range-x86_64-conversion-fix.patch

Will merge.

paravirt-remove-read-hazard-from-cow.patch
paravirt-pte-clear-not-present.patch
paravirt-lazy-mmu-mode-hooks.patch
paravirt-combine-flush-accessed-dirty.patch
paravirt-kpte-flush.patch
paravirt-optimize-ptep-establish-for-pae.patch
paravirt-remove-set-pte-atomic.patch
paravirt-pae-compile-fix.patch
paravirt-update-pte-hook.patch

Will merge if they're still suitable.

vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers.patch
vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers-alpha-fix.patch
nfs-represent-64-bit-fileids-as-64-bit-inode-numbers-on-32-bit-systems.patch

Will merge.

some-cleanup-in-the-pipe-code.patch
some-cleanup-in-the-pipe-code-tidy.patch
create-call_usermodehelper_pipe.patch
support-piping-into-commands-in-proc-sys-kernel-core_pattern.patch
support-piping-into-commands-in-proc-sys-kernel-core_pattern-fix.patch
support-piping-into-commands-in-proc-sys-kernel-core_pattern-fix-2.patch

Will merge.

proc-readdir-race-fix-take-3.patch
proc-readdir-race-fix-take-3-race-fix.patch
proc-reorder-the-functions-in-basec.patch
proc-modify-proc_pident_lookup-to-be-completely-table-driven.patch
proc-give-the-root-directory-a-task.patch
pid-implement-access-helpers-for-a-tacks-various-process-groups.patch
pid-add-do_each_pid_task.patch
pid-implement-signal-functions-that-take-a-struct-pid.patch
pid-export-the-symbols-needed-to-use-struct-pid.patch
pid-implement-pid_nr.patch
vt-rework-the-console-spawning-variables.patch
vt-make-vt_pid-a-struct-pid-making-it-pid-wrap-around-safe.patch
file-modify-struct-fown_struct-to-use-a-struct-pid.patch
file-modify-struct-fown_struct-to-use-a-struct-pid-fix.patch
remove-null-check-in-register_nls.patch
fs-inodec-tweaks.patch
const-struct-tty_operations.patch
pids-coding-style-use-struct-pidmap.patch
proc-readdir-race-fix-take-3-fix-1.patch
simplify-pid-iterators.patch
move-pidmap-to-pspaceh.patch
move-pidmap-to-pspaceh-fix.patch
define-struct-pspace.patch
proc-readdir-race-fix-take-3-fix-2.patch
update-mq_notify-to-use-a-struct-pid.patch
file-add-locking-to-f_getown.patch
usb-fixup-usb-so-it-uses-struct-pid.patch
s390-update-fs3270-to-use-a-struct-pid.patch

Will merge.

mxser-make-an-experimental-clone.patch

Will merge.

kprobes-make-kprobe-modules-more-portable.patch
kprobes-make-kprobe-modules-more-portable-update.patch
kprobes-handle-symbol-resolution-when-modulesymbol-is-specified.patch
kprobes-handle-symbol-resolution-when-modulesymbol-is-specified-tidy.patch
add-regs_return_value-helper.patch
update-documentation-kprobestxt.patch
update-documentation-kprobestxt-update.patch

Will merge.

isdn4linux-gigaset-driver-fix-__must_check-warning.patch
isdn-work-around-excessive-udelay.patch
hisax-niccy-cleanup.patch

Will merge.

cpumask-add-highest_possible_node_id.patch
cpumask-export-cpu_online_map-and-cpu_possible_map.patch
cpumask-export-node_to_cpu_mask-consistently.patch

Will merge.

knfsd-knfsd-add-some-missing-newlines-in-printks.patch
knfsd-knfsd-remove-an-unused-variable-from-e_show.patch
knfsd-knfsd-remove-an-unused-variable-from-auth_unix_lookup.patch
knfsd-add-a-callback-for-when-last-rpc-thread-finishes.patch
knfsd-add-a-callback-for-when-last-rpc-thread-finishes-tidy.patch
knfsd-add-a-callback-for-when-last-rpc-thread-finishes-fix.patch
knfsd-be-more-selective-in-which-sockets-lockd-listens-on.patch
knfsd-remove-nfsd_versbits-as-intermediate-storage-for-desired-versions.patch
knfsd-separate-out-some-parts-of-nfsd_svc-which-start-nfs-servers.patch
knfsd-separate-out-some-parts-of-nfsd_svc-which-start-nfs-servers-tweaks.patch
knfsd-define-new-nfsdfs-file-portlist-contains-list-of-ports.patch
knfsd-define-new-nfsdfs-file-portlist-contains-list-of-ports-tidy.patch
knfsd-define-new-nfsdfs-file-portlist-contains-list-of-ports-fix.patch
knfsd-allow-sockets-to-be-passed-to-nfsd-via-portlist.patch
knfsd-use-seq_start_token-instead-of-hardcoded-magic-void1.patch
nfsd-add-lock-annotations-to-e_start-and-e_stop.patch
knfsd-drop-serv-option-to-svc_recv-and-svc_process.patch
knfsd-drop-serv-option-to-svc_recv-and-svc_process-nfs-callback-fix-nfs-callback-fix.patch
knfsd-check-return-value-of-lockd_up-in-write_ports.patch
knfsd-move-makesock-failed-warning-into-make_socks.patch
knfsd-correctly-handle-error-condition-from-lockd_up.patch
knfsd-move-tempsock-aging-to-a-timer.patch
knfsd-move-tempsock-aging-to-a-timer-tidy.patch
knfsd-convert-sk_inuse-to-atomic_t.patch
knfsd-use-new-lock-for-svc_sock-deferred-list.patch
knfsd-convert-sk_reserved-to-atomic_t.patch
knfsd-test-and-set-sk_busy-atomically.patch
knfsd-split-svc_serv-into-pools.patch
knfsd-split-svc_serv-into-pools-fix.patch
knfsd-add-svc_get.patch
knfsd-add-svc_set_num_threads.patch
knfsd-use-svc_set_num_threads-to-manage-threads-in-knfsd.patch
knfsd-make-rpc-threads-pools-numa-aware.patch
knfsd-make-rpc-threads-pools-numa-aware-fix.patch
knfsd-allow-admin-to-set-nthreads-per-node.patch
nfsd-lockdep-annotation.patch
knfsd-nfsd-lockdep-annotation-fix.patch
knfsd-call-lockd_down-when-closing-a-socket-via-a-write-to-nfsd-portlist.patch
knfsd-protect-update-to-sn_nrthreads-with-lock_kernel.patch
knfsd-fixed-handling-of-lockd-fail-when-adding-nfsd-socket.patch
knfsd-replace-two-page-lists-in-struct-svc_rqst-with-one.patch
knfsd-replace-two-page-lists-in-struct-svc_rqst-with-one-fix.patch
knfsd-avoid-excess-stack-usage-in-svc_tcp_recvfrom.patch
knfsd-prepare-knfsd-for-support-of-rsize-wsize-of-up-to-1mb-over-tcp.patch
knfsd-allow-max-size-of-nfsd-payload-to-be-configured.patch
knfsd-make-nfsd-readahead-params-cache-smp-friendly.patch
knfsd-knfsd-cache-ipmap-per-tcp-socket.patch
knfsd-hide-use-of-lockds-h_monitored-flag.patch
knfsd-consolidate-common-code-for-statd-lockd-notification.patch
knfsd-when-looking-up-a-lockd-host-pass-hostname-length.patch
knfsd-lockd-introduce-nsm_handle.patch
knfsd-lockd-introduce-nsm_handle-fix.patch
knfsd-misc-minor-fixes-indentation-changes.patch
knfsd-lockd-make-nlm_host_rebooted-use-the-nsm_handle.patch
knfsd-lockd-make-the-nsm-upcalls-use-the-nsm_handle.patch
knfsd-lockd-make-the-hash-chains-use-a-hlist_node.patch
knfsd-lockd-change-list-of-blocked-list-to-list_node.patch
knfsd-change-nlm_file-to-use-a-hlist.patch
knfsd-lockd-make-nlm_traverse_-more-flexible.patch
knfsd-lockd-add-nlm_destroy_host.patch
knfsd-simplify-nlmsvc_invalidate_all.patch
knfsd-lockd-optionally-use-hostnames-for-identifying-peers.patch
knfsd-make-nlmclnt_next_cookie-smp-safe.patch
knfsd-match-granted_res-replies-using-cookies.patch
knfsd-export-nsm_local_state-to-user-space-via-sysctl.patch
knfsd-lockd-fix-use-of-h_nextrebind.patch
knfsd-register-all-rpc-programs-with-portmapper-by-default.patch
knfsd-lockd-introduce-nsm_handle-sem2mutex.patch
knfsd-svcrpc-gss-factor-out-some-common-wrapping-code.patch
knfsd-svcrpc-gss-fix-failure-on-svc_denied-in-integrity-case.patch
knfsd-svcrpc-use-consistent-variable-name-for-the-reply-state.patch
knfsd-nfsd4-refactor-exp_pseudoroot.patch
knfsd-nfsd4-clean-up-exp_pseudoroot.patch
knfsd-nfsd4-acls-relax-the-nfsv4-posix-mapping.patch
knfsd-nfsd4-acls-fix-inheritance.patch
knfsd-nfsd4-acls-simplify-nfs4_acl_nfsv4_to_posix-interface.patch
knfsd-nfsd4-acls-fix-handling-of-zero-length-acls.patch

Will merge.

sched-force-sbin-init-off-isolated-cpus.patch
sched-remove-unnecessary-sched-group-allocations.patch
sched-remove-unnecessary-sched-group-allocations-fix.patch
sched-dont-print-migration-cost-when-only-1-cpu.patch
lower-migration-thread-stop-machine-prio.patch
sched-generic-sched_group-cpu-power-setup.patch
sched-fixing-wrong-comment-for-find_idlest_cpu.patch
scheduler-numa-aware-placement-of-sched_group_allnodes.patch

Will merge.

sched2-sched-domain-sysctl.patch

-mm only.

sched-add-above-background-load-function.patch
mm-implement-swap-prefetching.patch
swap_prefetch-vs-zoned-counters.patch
zvc-support-nr_slab_reclaimable--nr_slab_unreclaimable-swap_prefetch.patch
reduce-max_nr_zones-swap_prefetch-remove-incorrect-use-of-zone_highmem.patch
sched-cleanup-remove-task_t-convert-to-struct-task_struct-prefetch.patch
numa-add-zone_to_nid-function-swap_prefetch.patch

Will continue to dither.

ecryptfs-fs-makefile-and-fs-kconfig.patch
ecryptfs-fs-makefile-and-fs-kconfig-kconfig-help-update.patch
ecryptfs-documentation.patch
ecryptfs-makefile.patch
ecryptfs-main-module-functions.patch
ecryptfs-header-declarations.patch
ecryptfs-superblock-operations.patch
#ecryptfs-superblock-operations-ecryptfs-build-fix.patch
ecryptfs-dentry-operations.patch
ecryptfs-file-operations.patch
#ecryptfs-vs-streamline-generic_file_-interfaces-and-filemap.patch
#ecryptfs-vs-streamline-generic_file_-interfaces-and-filemap-fix.patch
ecryptfs-inode-operations.patch
ecryptfs-mmap-operations.patch
ecryptfs-mmap-operations-fix.patch
ecryptfs-keystore.patch
ecryptfs-crypto-functions.patch
ecryptfs-crypto-functions-mutex-fixes.patch
fs-ecryptfs-possible-cleanups.patch
ecryptfs-debug-functions.patch
ecryptfs-alpha-build-fix.patch
ecryptfs-convert-assert-to-bug_on.patch
ecryptfs-remove-pointless-bug_ons.patch
ecryptfs-remove-unnecessary-null-checks.patch
ecryptfs-rewrite-ecryptfs_fsync.patch
ecryptfs-overhaul-file-locking.patch
ecryptfs-remove-lock-propagation.patch
ecryptfs-dont-muck-with-the-existing-nameidata-structures.patch
ecryptfs-asm-scatterlisth-linux-scatterlisth.patch
ecryptfs-support-for-larger-maximum-key-size.patch
ecryptfs-add-codes-for-additional-ciphers.patch
ecryptfs-unencrypted-key-size-based-on-encrypted-key-size.patch
ecryptfs-packet-and-key-management-update-for-variable-key-size.patch
ecryptfs-add-ecryptfs_-prefix-to-mount-options-key-size-parameter.patch
ecryptfs-set-the-key-size-from-the-default-for-the-mount.patch
ecryptfs-check-for-weak-keys.patch
ecryptfs-add-define-values-for-cipher-codes-from-rfc2440-openpgp.patch
ecryptfs-convert-bits-to-bytes.patch
ecryptfs-more-elegant-aes-key-size-manipulation.patch
ecryptfs-more-intelligent-use-of-tfm-objects.patch
ecryptfs-remove-debugging-cruft.patch
ecryptfs-get_sb_dev-fix.patch
ecryptfs-validate-minimum-header-extent-size.patch
ecryptfs-validate-body-size.patch
ecryptfs-validate-packet-length-prior-to-parsing-add-comments.patch
ecryptfs-use-the-passed-in-max-value-as-the-upper-bound.patch
ecryptfs-change-the-maximum-size-check-when-writing-header.patch
ecryptfs-print-the-actual-option-that-is-problematic.patch
ecryptfs-add-a-maintainers-entry.patch
ecryptfs-partial-signed-integer-to-size_t-conversion-updated-ii.patch
ecryptfs-graceful-handling-of-mount-error.patch
inode-diet-move-i_pipe-into-a-union-ecryptfs.patch
inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-ecryptfs.patch
streamline-generic_file_-interfaces-and-filemap-ecryptfs.patch
ecryptfs-fix-printk-format-warnings.patch
ecryptfs-associate-vfsmount-with-dentry-rather-than-superblock.patch
ecryptfs-mntput-lower-mount-on-umount_begin.patch
vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers-ecryptfs.patch
make-kmem_cache_destroy-return-void-ecryptfs.patch
ecryptfs-inode-numbering-fixes.patch
ecryptfs-versioning-fixes.patch
ecryptfs-versioning-fixes-tidy.patch

Will fold into a single patch and will then merge.

proc-sysctl-add-_proc_do_string-helper.patch
make-kernel-sysctlc_proc_do_string-static.patch
namespaces-add-nsproxy.patch
namespaces-add-nsproxy-move-init_nsproxy-into-kernel-nsproxyc.patch
namespaces-incorporate-fs-namespace-into-nsproxy.patch
namespaces-incorporate-fs-namespace-into-nsproxy-whitespace.patch
namespaces-utsname-introduce-temporary-helpers.patch
namespaces-utsname-switch-to-using-uts-namespaces.patch
namespaces-utsname-switch-to-using-uts-namespaces-klibc-bit.patch
namespaces-utsname-use-init_utsname-when-appropriate-klibc-bit.patch
namespaces-utsname-switch-to-using-uts-namespaces-klibc-bit-2.patch
namespaces-utsname-switch-to-using-uts-namespaces-klibc-bit-sparc.patch
namespaces-utsname-use-init_utsname-when-appropriate.patch
namespaces-utsname-implement-utsname-namespaces.patch
namespaces-utsname-sysctl-hack.patch
namespaces-utsname-remove-system_utsname.patch
namespaces-utsname-implement-clone_newuts-flag.patch
namespaces-utsname-implement-clone_newuts-flag-fix.patch
uts-copy-nsproxy-only-when-needed.patch

Will merge.

This is prep work for namespace virtualisation. This doesn't really make
sense on its own, so there's an act of faith here - it assumes that Linux
will eventually have full-on virtualisation of the various namespaces with
sufficient coverage to actually be useful to userspace.

Normally I'd just buffer all the functionality into -mm until it's ready to
go and is actually useful to userspace. But for this work that would mean
just too many patches held for too long. So I'll start moving little pieces
like this into mainline.

ipc-namespace-core.patch
ipc-namespace-utils.patch
ipc-namespace-msg.patch
ipc-namespace-sem.patch
ipc-namespace-shm.patch
ipc-namespace-sysctls.patch
ipc-namespace-fix.patch

Will fold into a single patch and shall then merge.

ipc-replace-kmalloc-and-memset-in-get_undo_list-with-kzalloc.patch

Will merge.

introduce-kernel_execve.patch
rename-the-provided-execve-functions-to-kernel_execve.patch
rename-the-provided-execve-functions-to-kernel_execve-fixes.patch
rename-the-provided-execve-functions-to-kernel_execve-headers-fix.patch
provide-kernel_execve-on-all-architectures.patch
provide-kernel_execve-on-all-architectures-fix.patch
provide-kernel_execve-on-all-architectures-mips-fix.patch
provide-kernel_execve-on-all-architectures-fix-2.patch
provide-kernel_execve-on-all-architectures-fix-3.patch
provide-kernel_execve-on-all-architectures-m68knommu-fix.patch
remove-the-use-of-_syscallx-macros-in-uml.patch
sh64-remove-the-use-of-kernel-syscalls.patch
remove-remaining-errno-and-__kernel_syscalls__-references.patch
avr32-implement-kernel_execve.patch

Will merge.

proc-make-the-generation-of-the-self-symlink-table-driven.patch
proc-factor-out-an-instantiate-method-from-every-lookup-method.patch
proc-remove-the-hard-coded-inode-numbers.patch
proc-merge-proc_tid_attr-and-proc_tgid_attr.patch
proc-use-pid_task-instead-of-open-coding-it.patch
proc-convert-task_sig-to-use-lock_task_sighand.patch
proc-convert-do_task_stat-to-use-lock_task_sighand.patch
proc-drop-tasklist-lock-in-task_state.patch
proc-properly-compute-tgid_offset.patch
proc-remove-trailing-blank-entry-from-pid_entry-arrays.patch
proc-remove-the-useless-smp-safe-comments-from-proc.patch
proc-comment-what-proc_fill_cache-does.patch
introduce-get_task_pid-to-fix-unsafe-get_pid.patch

/proc changes. Will merge.

readahead-kconfig-options.patch
radixtree-introduce-radix_tree_scan_hole.patch
mm-introduce-probe_page.patch
mm-introduce-pg_readahead.patch
readahead-add-look-ahead-support-to-__do_page_cache_readahead.patch
readahead-delay-page-release-in-do_generic_mapping_read.patch
readahead-insert-cond_resched-calls.patch
readahead-minmax_ra_pages.patch
readahead-events-accounting.patch
readahead-rescue_pages.patch
readahead-sysctl-parameters.patch
readahead-sysctl-parameters-fix.patch
readahead-min-max-sizes.patch
readahead-state-based-method-aging-accounting.patch
readahead-state-based-method-aging-accounting-apply-type-enum-zone_type-readahead.patch
readahead-state-based-method-routines.patch
readahead-state-based-method.patch
readahead-context-based-method.patch
readahead-initial-method-guiding-sizes.patch
readahead-initial-method-thrashing-guard-size.patch
readahead-initial-method-expected-read-size.patch
readahead-initial-method-user-recommended-size.patch
readahead-initial-method.patch
readahead-backward-prefetching-method.patch
readahead-seeking-reads-method.patch
readahead-thrashing-recovery-method.patch
readahead-call-scheme.patch
readahead-call-scheme-fix.patch
readahead-laptop-mode.patch
readahead-loop-case.patch
readahead-nfsd-case.patch
readahead-turn-on-by-default.patch
readahead-debug-radix-tree-new-functions.patch
readahead-debug-traces-showing-accessed-file-names.patch
readahead-debug-traces-showing-read-patterns.patch
readahead-remove-size-limit-on-read_ahead_kb.patch
readahead-backward-prefetching-method-fix.patch
readahead-remove-the-size-limit-of-max_sectors_kb-on-read_ahead_kb.patch

The readahead code is complex, I'm unconvinced that it has a lot of benefit
and Wu has gone quiet. Will drop.

reiser4-export-handle_ra_miss.patch
reiser4-sb_sync_inodes.patch
reiser4-export-remove_from_page_cache.patch
reiser4-export-radix_tree_preload.patch
reiser4-export-find_get_pages.patch
make-copy_from_user_inatomic-not-zero-the-tail-on-i386-vs-reiser4.patch
reiser4.patch
make-kmem_cache_destroy-return-void-reiser4.patch
reiser4-hardirq-include-fix.patch
reiser4-fix-trivial-tyops-which-were-hard-to-hit.patch
reiser4-run-truncate_inode_pages-in-reiser4_delete_inode.patch
reiser4-bug-fixes.patch
reiser4-write-via-do_sync_write.patch
reiser4-fix-gcc-ws-compains.patch
fs-reiser4-possible-cleanups.patch
reiser4-get_sb_dev-fix.patch
reiser4-vs-zoned-allocator.patch
inode_diet-replace-inodeugeneric_ip-with-inodei_private-reiser4.patch
inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-reiser4.patch
reiser4-vs-streamline-generic_file_-interfaces-and-filemap.patch
reiser4-vs-streamline-generic_file_-interfaces-and-filemap-fix.patch
reiser4-rename-generic_sounding_globalspatch.patch
reiser4-rename-generic_sounding_globalspatch-fix.patch
reiser4-decribe-new-atom-locking-and-nested-atom-locks-to-lock-validator.patch
reiser4-use-generic-file-read.patch
reiser4-simplify-reading-of-partially-converted-files.patch
reiser4-use-page_offset.patch
reiser4-use-reiser4_gfp_mask_get-in-reiser4-inode-allocation.patch
reiser4-re-add-page_count-check-to-reiser4_releasepage.patch
reiser4-restore-fibmap-ioctl-support-for-packed-files.patch
reiser4-possible-cleanups-2.patch

reiser4. I was planning on merging this, but the batch_write/writev problem
might wreck things, and I don't think the patches arising from my recent
partial review have come through yet. So it's looking more like 2.6.20.

ide-claim-extra-dma-ports-regardless-of-channel.patch
ide-always-release-dma-engine.patch
ide-error-handling-fixes.patch
ide-hpt3xxn-clocking-fixes.patch
ide-fix-hpt37x-timing-tables.patch
ide-optimize-hpt37x-timing-tables.patch
ide-fix-hpt3xx-hotswap-support.patch
ide-fix-the-case-of-multiple-hpt3xx-chips-present.patch
ide-hpt3xx-fix-pci-clock-detection.patch
ide-hpt3xx-fix-pci-clock-detection-fix-2.patch
piix-fix-82371mx-enablebits.patch
piix-remove-check-for-broken-mw-dma-mode-0.patch
piix-slc90e66-pio-mode-fallback-fix.patch
make-number-of-ide-interfaces-configurable.patch
ide_dma_speed-fixes.patch
hpt3xx-rework-rate-filtering.patch
hpt3xx-rework-rate-filtering-tidy.patch
hpt3xx-print-the-real-chip-name-at-startup.patch
hpt3xx-switch-to-using-pci_get_slot.patch
hpt3xx-cache-channels-mcr-address.patch
hpt3x7-merge-speedproc-handlers.patch
hpt370-clean-up-dma-timeout-handling.patch
enable-cdrom-dma-access-with-pdc20265_old.patch
ide-fix-revision-comparison-in-ide_in_drive_list.patch
ide-backport-piix-fixes-from-libata-into-the-legacy-driver.patch

Various legacy IDE things from Sergei. These have been in -mm for some
time. Last time around Alan's comments were rather waffly so I held off.
I'll be looking to merge pretty much all of this into 2.6.19, subject to
another round of reviewing.

hpt3xx-init-code-rewrite.patch
move-ide-to-unmaintained-drop-reference-to-old-git-tree.patch
ide-core-must_check-fixes.patch
drivers-ide-cleanups.patch
ide-remove-dma_base2-field-from-ide_hwif_t.patch
# ide-reprogram-disk-pio-timings-on-resume.patch: Sergei Shtylyov <***@ru.mvista.com> has issues
ide-reprogram-disk-pio-timings-on-resume.patch
pcmcia-add-few-ids-into-ide-cs.patch
config_pm=n-slim-drivers-ide-pci-sc1200c.patch
ide-fix-crash-on-repeated-reset.patch
ide-fix-crash-on-repeated-reset-tidy.patch
allow-ide_generic_all-to-be-used-modular-and-built-in.patch

More legacy IDE work. Will merge.

au1100fb-add-option-to-enable-disable-the-cursor.patch
intelfb-documentation-update.patch
rivafb-use-constants-instead-of-magic-values.patch
vfb-document-option-to-enable-the-driver.patch
fbdev-add-generic-ddc-read-functionality.patch
nvidiafb-use-generic-ddc-reading.patch
rivafb-use-generic-ddc-reading.patch
i810fb-use-generic-ddc-reading.patch
savagefb-use-generic-ddc-reading.patch
savagefb-use-generic-ddc-reading-fix.patch
radeonfb-use-generic-ddc-reading.patch
fbcon-use-persistent-allocation-for-cursor-blinking.patch
fbcon-remove-cursor-timer-if-unused.patch
vt-honor-the-return-value-of-device_create_file.patch
fbdev-honor-the-return-value-of-device_create_file.patch
fbcon-honor-the-return-value-of-device_create_file.patch
atyfb-honor-the-return-value-of-pci_register_driver.patch
matroxfb-honor-the-return-value-of-pci_register_driver.patch
nvidiafb-honor-the-return-value-of-pci_enable_device.patch
i810fb-honor-the-return-value-of-pci_enable_device.patch
drivers-video-sis-init301h-removal-of-old.patch
drivers-video-sis-initextlfbc-removal-of.patch
drivers-video-sis-inith-removal-of-old-code.patch
drivers-video-sis-osdefh-removal-of-old-code.patch
drivers-video-sis-sis_accelc-removal-of-old.patch
drivers-video-sis-sis_accelh-removal-of-old.patch
drivers-video-sis-sis_mainc-removal-of-old.patch
drivers-video-sis-sis_mainc-removal-of-old-2.patch
drivers-video-sis-vgatypesh-removal-of-old.patch
drivers-video-sis-sis_mainh-removal-of-old.patch
atyfb-possible-cleanups.patch
mbxfb-fix-a-chip-bug-resulting-in-wrong-pixclock.patch
mbxfb-fix-framebuffer-size-smaller-than-requested.patch
fbcon-make-3-functions-static.patch
vt-proper-prototypes-for-some-console-functions.patch
sstfb-clean-ups.patch

fbdev. Will merge.

dm-support-ioctls-on-mapped-devices.patch
dm-linear-support-ioctls.patch
dm-mpath-support-ioctls.patch
dm-export-blkdev_driver_ioctl.patch
dm-support-ioctls-on-mapped-devices-fix-with-fake-file.patch
dm-fix-alloc_dev-error-path.patch
dm-snapshot-fix-invalidation-enomem.patch
dm-snapshot-allow-zero-chunk_size.patch
dm-snapshot-fix-metadata-error-handling.patch
dm-snapshot-make-read-and-write-exception-functions-void.patch
dm-snapshot-fix-metadata-writing-when-suspending.patch
dm-snapshot-tidy-snapshot_map.patch
dm-snapshot-tidy-pending_complete.patch
dm-snapshot-add-workqueue.patch
dm-snapshot-tidy-pe-ref-counting.patch
dm-snapshot-fix-freeing-pending-exception.patch
dm-mirror-remove-trailing-space-from-table.patch
dm-mpath-tidy-ctr.patch
dm-mpath-use-kzalloc.patch
dm-add-uevent-change-event-on-resume.patch
dm-add-debug-macro.patch
dm-table-add-target-preresume.patch
dm-crypt-add-key-msg.patch
dm-crypt-restructure-for-workqueue-change.patch
dm-crypt-restructure-write-processing.patch
dm-crypt-move-io-to-workqueue.patch
dm-crypt-use-private-biosets.patch
dm-use-private-biosets.patch
dm-extract-device-limit-setting.patch
dm-table-add-target-flush.patch

Device mapper. Will merge.

md-the-scheduled-removal-of-the-start_array-ioctl-for-md.patch
md-fix-a-comment-that-is-wrong-in-raid5h.patch
md-factor-out-part-of-raid10d-into-a-separate-function.patch
md-replace-magic-numbers-in-sb_dirty-with-well-defined-bit-flags.patch
md-remove-the-working_disks-and-failed_disks-from-raid5-state-data.patch
md-remove-working_disks-from-raid10-state.patch
md-new-sysfs-interface-for-setting-bits-in-the-write-intent-bitmap.patch
md-remove-unnecessary-variable-x-in-stripe_to_pdidx.patch
md-factor-out-part-of-raid1d-into-a-separate-function.patch
md-remove-working_disks-from-raid1-state-data.patch
md-improve-locking-around-error-handling.patch
md-define-backing_dev_infocongested_fn-for-raid0-and-linear.patch
md-define-congested_fn-for-raid1-raid10-and-multipath.patch
md-add-a-congested_fn-function-for-raid5-6.patch
md-make-messages-about-resync-recovery-etc-more-specific.patch

RAID. Will merge.

md-dm-reduce-stack-usage-with-stacked-block-devices.patch

Will hold in -mm. But we should do something about DM's stack consumption.

statistics-infrastructure-prerequisite-list.patch
statistics-infrastructure-prerequisite-parser.patch
statistics-infrastructure-prerequisite-timestamp.patch
statistics-infrastructure-prerequisite-timestamp-fix.patch
statistics-infrastructure-make-printk_clock-a-generic-kernel-wide-nsec-resolution.patch
statistics-infrastructure-documentation.patch
statistics-infrastructure.patch
statistics-infrastructure-update-9.patch
statistics-use-the-enhanced-percpu-interface.patch
statistics-replace-inode-ugeneric_ip-with-i_private.patch
statistics-infrastructure-exploitation-zfcp.patch
statistics-infrastructure-exploitation-zfcp-sched_clock-fix.patch
zfcp-gather-hba-specific-latencies-in-statistics.patch

Waffle. Not sure. It seems like nice code but is, perhaps, overly complete.

genirq-msi-restore-__do_irq-compat-logic-temporarily.patch
genirq-convert-the-x86_64-architecture-to-irq-chips.patch
genirq-convert-the-i386-architecture-to-irq-chips.patch
genirq-irq-convert-the-move_irq-flag-from-a-32bit-word-to-a-single-bit.patch
genirq-irq-add-moved_masked_irq.patch
genirq-x86_64-irq-reenable-migrating-irqs-to-other-cpus.patch
genirq-msi-simplify-msi-enable-and-disable.patch
genirq-msi-make-the-msi-boolean-tests-return-either-0-or-1.patch
genirq-msi-implement-helper-functions-read_msi_msg-and-write_msi_msg.patch
genirq-msi-refactor-the-msi_ops.patch
genirq-msi-simplify-the-msi-irq-limit-policy.patch
genirq-irq-add-a-dynamic-irq-creation-api.patch
genirq-ia64-irq-dynamic-irq-support.patch
genirq-i386-irq-dynamic-irq-support.patch
genirq-x86_64-irq-dynamic-irq-support.patch
genirq-msi-make-the-msi-code-irq-based-and-not-vector-based.patch
genirq-x86_64-irq-move-msi-message-composition-into-io_apicc.patch
genirq-i386-irq-move-msi-message-composition-into-io_apicc.patch
genirq-msi-only-build-msi-apicc-on-ia64.patch
genirq-msi-only-build-msi-apicc-on-ia64-fix.patch
genirq-x86_64-irq-remove-the-msi-assumption-that-irq-==-vector.patch
genirq-i386-irq-remove-the-msi-assumption-that-irq-==-vector.patch
genirq-irq-remove-msi-hacks.patch
genirq-irq-generalize-the-check-for-hardirq_bits.patch
genirq-x86_64-irq-make-the-external-irq-handlers-report-their-vector-not-the-irq-number.patch
genirq-x86_64-irq-make-vector_irq-per-cpu.patch
genirq-x86_64-irq-make-vector_irq-per-cpu-fix.patch
genirq-x86_64-irq-make-vector_irq-per-cpu-warning-fix.patch
genirq-x86_64-irq-kill-gsi_irq_sharing.patch
genirq-x86_64-irq-kill-irq-compression.patch

genirq changes. We still need some MSI fixes against this. That's in
progress. Will merge.

add-hypertransport-capability-defines.patch
add-hypertransport-capability-defines-fix.patch
initial-generic-hypertransport-interrupt-support.patch
initial-generic-hypertransport-interrupt-support-Kconfig-fix.patch

Will merge.

srcu-3-rcu-variant-permitting-read-side-blocking.patch
srcu-3-rcu-variant-permitting-read-side-blocking-fix.patch
srcu-3-rcu-variant-permitting-read-side-blocking-srcu-add-lock-annotations.patch
srcu-3-rcu-variant-permitting-read-side-blocking-comments.patch
srcu-3-add-srcu-operations-to-rcutorture.patch
srcu-3-add-srcu-operations-to-rcutorture-fix.patch
add-srcu-based-notifier-chains.patch
add-srcu-based-notifier-chains-cleanup.patch
srcu-report-out-of-memory-errors.patch
srcu-report-out-of-memory-errors-fixlet.patch
cpufreq-make-the-transition_notifier-chain-use-srcu.patch
rcu-add-module_author-to-rcutorture-module.patch
rcu-fix-incorrect-description-of-default-for-rcutorture.patch
rcu-mention-rcu_bh-in-description-of-rcutortures.patch
rcu-avoid-kthread_stop-on-invalid-pointer-if-rcutorture.patch
rcu-fix-sign-bug-making-rcu_random-always-return-the-same.patch
rcu-add-fake-writers-to-rcutorture.patch
rcu-add-fake-writers-to-rcutorture-tidy.patch
rcu-refactor-srcu_torture_deferred_free-to-work-for.patch
rcu-add-rcu_sync-torture-type-to-rcutorture.patch
rcu-add-rcu_bh_sync-torture-type-to-rcutorture.patch
rcu-add-sched-torture-type-to-rcutorture.patch
rcu-simplify-improve-batch-tuning.patch
rcu-credits-and-maintainers.patch

Will merge.

the-scheduled-removal-of-some-oss-drivers.patch
the-scheduled-removal-of-some-oss-drivers-fix.patch
the-scheduled-removal-of-some-oss-drivers-fix-fix.patch
kill-sound-oss-_symsc.patch

Will merge.


kill-include-linux-configh.patch
pci_module_init-convertion-in-ata_genericc.patch
pci_module_init-convertion-in-ata_genericc-fix.patch
pci_module_init-convertion-in-amso1100-driver.patch
pci_module_init-convertion-for-k8_edacc.patch
pci_module_init-convertion-in-the-legacy-megaraid-driver.patch
pci_module_init-convertion-in-olympicc.patch
pci_module_init-conversion-for-pata_pdc2027x.patch
pci_module_init-convertion-in-tmscsimc.patch
mark-pci_module_init-deprecated.patch
pr_debug-aio-use-size_t-length-modifier-in-pr_debug-format-arguments.patch
pr_debug-configfs-use-size_t-length-modifier-in-pr_debug-format-argument.patch
pr_debug-sysfs-use-size_t-length-modifier-in-pr_debug-format-arguments.patch
pr_debug-umem-repair-nonexistant-bh-pr_debug-reference.patch
pr_debug-tipar-repair-nonexistant-pr_debug-argument-use.patch
pr_debug-dell_rbu-fix-pr_debug-argument-warnings.patch
pr_debug-ifb-replace-missing-comma-to-separate-pr_debug-arguments.patch
pr_debug-trident-use-size_t-length-modifier-in-pr_debug-format-arguments.patch
pr_debug-check-pr_debug-arguments-arm-fix.patch
isdn-debug-build-fix.patch
isdn-more-pr_debug-fixes.patch
pr_debug-check-pr_debug-arguments.patch

Will merge.

mprotect-patch-for-use-by-slim.patch
integrity-service-api-and-dummy-provider.patch
integrity-service-api-and-dummy-provider-compilation-warning-fix.patch
slim-main-patch.patch
slim-main-patch-socket_post_create-hook-return-code.patch
slim-secfs-patch.patch
slim-make-and-config-stuff.patch
slim-debug-output.patch
slim-fix-security-issue-with-the-task_post_setuid-hook.patch
slim-secfs-inode-i_private-build-fix.patch
slim-documentation.patch

SLIM is way outside my area of knowledge. I'd like to see more feedback
from the other security developers and preferably some statement of interest
from distros.

documentation-ioctl-messtxt-start-tree-wide-ioctl-registry.patch
ioctl-messtxt-xfs-typos.patch

Will retain in -mm. (What do we need to do to finish this?)

list_del-debug.patch
make-sure-nobodys-leaking-resources.patch
journal_add_journal_head-debug.patch
page-owner-tracking-leak-detector.patch
unplug-can-sleep.patch
firestream-warnings.patch
#periodically-scan-redzone-entries-and-slab-control-structures.patch
releasing-resources-with-children.patch
nr_blockdev_pages-in_interrupt-warning.patch
detect-atomic-counter-underflows.patch
device-suspend-debug.patch
slab-cache-shrinker-statistics.patch
mm-debug-dump-pageframes-on-bad_page.patch
debug-shared-irqs.patch
debug-shared-irqs-kconfig-fix.patch
make-frame_pointer-default=y.patch
i386-enable-4k-stacks-by-default.patch
pidhash-temporary-debug-checks.patch
mutex-subsystem-synchro-test-module.patch
x86-e820-debugging.patch
slab-leaks3-default-y.patch
x86-kmap_atomic-debugging.patch
profile-likely-unlikely-macros.patch
vdso-print-fatal-signals.patch
vdso-improve-print_fatal_signals-support-by-adding-memory-maps.patch
restore-rogue-readahead-printk.patch
put_bh-debug.patch
e1000_7033_dump_ring.patch
acpi_format_exception-debug.patch

This is -mm only debug stuff. It shall remain in -mm.

jmicron-warning-fix.patch

Will merge.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-20 21:09:04 UTC
Permalink
Post by Andrew Morton
kerneldoc-error-on-ata_piixc.patch
libata-add-40pin-short-cable-support-honour-drive.patch
libata-add-40pin-short-cable-support-honour-drive-fix.patch
1-of-2-jmicron-driver.patch
1-of-2-jmicron-driver-fix.patch
2-of-2-jmicron-driver-plumbing-and-quirk.patch
2-of-2-jmicron-driver-plumbing-and-quirk-cleanup.patch
non-libata-driver-for-jmicron-devices.patch
via-pata-controller-xfer-fixes.patch
via-pata-controller-xfer-fixes-fix.patch
via-sata-oops-on-init.patch
ATA stuff. I am hopelessly confused regarding which patches pertain to
sata, which to pata and which to legacy IDE. It's a matter of weeding
through all of these and finding an appropriate route to get them merged.
Should be quite easy, as its all based on path.

drivers/{ata,scsi} -> me
drivers/ide -> not me (Alan?)

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Badari Pulavarty
2006-09-20 21:38:59 UTC
Permalink
On Wed, 2006-09-20 at 13:54 -0700, Andrew Morton wrote:

Sorry, I didn't get back to this earlier. I have been chasing
one more ext2 & ext3 regression (this time with random reads).
Anyway ..
Post by Andrew Morton
add-address_space_operationsbatch_write.patch
add-address_space_operationsbatch_write-fix.patch
pass-io-size-to-batch_write-address-space-operation.patch
These add a new address_space operation. For reiser4, with potential for
use by other filesystems.
Problem is, 2.6.18 has a significant writev() performace regression on NFS
and probably on other filesystems. Because 2.6.18 does
prepare_write/commit_write for each iovec segment. We want to go back to
copying mulitple iovec segments within a single prepare_write/commit_write.
Plus there's still the possible deadlock in our standard write() function
(thw thing which fault_in_pages_readable() tries to prevent).
All of this should be fixed.
What needs to be fixed here ?

Thanks,
Badari

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2006-09-20 21:54:31 UTC
Permalink
Post by Andrew Morton
fix-gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch
gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure-2.patch
Hi Andrew,

a few days ago I submitted a patch [1] to autosupend-autoresume
infrastructure (and Alan Stern submitted a similar patch a few hours later
[2]).

Without this one-liner, all kernels compiled without CONFIG_USB_SUSPEND
will be unable to perform more than one suspend/resume cycle, which is
quite annoying. Would you please reconsider pushing these together with
other autosuspend/autoresume infrastructure fixes?

Thanks.

[1] http://lkml.org/lkml/2006/9/18/290
[2] http://lkml.org/lkml/2006/9/19/93
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-20 22:10:40 UTC
Permalink
On Wed, 20 Sep 2006 23:53:23 +0200 (CEST)
Post by Jiri Kosina
Post by Andrew Morton
fix-gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch
gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure-2.patch
Hi Andrew,
a few days ago I submitted a patch [1] to autosupend-autoresume
infrastructure (and Alan Stern submitted a similar patch a few hours later
[2]).
Without this one-liner, all kernels compiled without CONFIG_USB_SUSPEND
will be unable to perform more than one suspend/resume cycle, which is
quite annoying. Would you please reconsider pushing these together with
other autosuspend/autoresume infrastructure fixes?
Thanks.
[1] http://lkml.org/lkml/2006/9/18/290
[2] http://lkml.org/lkml/2006/9/19/93
I expect the appropriate fixes will automagically appear in Greg's tree, to
be picked up in next -mm. Perhaps they already have appeared - Alan?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
2006-09-20 22:42:03 UTC
Permalink
Post by Andrew Morton
On Wed, 20 Sep 2006 23:53:23 +0200 (CEST)
Post by Jiri Kosina
Post by Andrew Morton
fix-gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch
gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure-2.patch
Hi Andrew,
a few days ago I submitted a patch [1] to autosupend-autoresume
infrastructure (and Alan Stern submitted a similar patch a few hours later
[2]).
Without this one-liner, all kernels compiled without CONFIG_USB_SUSPEND
will be unable to perform more than one suspend/resume cycle, which is
quite annoying. Would you please reconsider pushing these together with
other autosuspend/autoresume infrastructure fixes?
Thanks.
[1] http://lkml.org/lkml/2006/9/18/290
[2] http://lkml.org/lkml/2006/9/19/93
I expect the appropriate fixes will automagically appear in Greg's tree, to
be picked up in next -mm. Perhaps they already have appeared - Alan?
I just added the fix to my tree, am catching up on my pending patch
queue right now...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Trond Myklebust
2006-09-20 21:56:03 UTC
Permalink
Post by Andrew Morton
add-newline-to-nfs-dprintk.patch
fs-nfs-make-code-static.patch
NFS queue -> Trond.
The NFS git tree breaks autofs4 submounts. Still.
I still suspect that is due to a misconfigured selinux setup on your
machine. If autofs4 expects to be able to do mkdir() on your NFS
partition (something which in itself is wrong), then selinux should be
configured to allow it to do so.

Anyhow, does reverting the patch

http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a634904a7de0d3a0bc606f608007a34e8c05bfee;hp=ddeff520f02b92128132c282c350fa72afffb84a

'fix' the issue for you?

Cheers,
Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-20 22:14:13 UTC
Permalink
On Wed, 20 Sep 2006 17:55:33 -0400
Post by Trond Myklebust
Post by Andrew Morton
add-newline-to-nfs-dprintk.patch
fs-nfs-make-code-static.patch
NFS queue -> Trond.
The NFS git tree breaks autofs4 submounts. Still.
I still suspect that is due to a misconfigured selinux setup on your
machine.
"still"? I don't recall being told that. Perhaps I was asleep.

It's an up-to-date-a-few-weeks-ago FC5 machine. So if I'm busted then lots
of people are.
Post by Trond Myklebust
If autofs4 expects to be able to do mkdir() on your NFS
partition (something which in itself is wrong), then selinux should be
configured to allow it to do so.
Anyhow, does reverting the patch
http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a634904a7de0d3a0bc606f608007a34e8c05bfee;hp=ddeff520f02b92128132c282c350fa72afffb84a
'fix' the issue for you?
I'll take a look this evening.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-21 03:40:15 UTC
Permalink
On Wed, 20 Sep 2006 17:55:33 -0400
Post by Trond Myklebust
Post by Andrew Morton
add-newline-to-nfs-dprintk.patch
fs-nfs-make-code-static.patch
NFS queue -> Trond.
The NFS git tree breaks autofs4 submounts. Still.
I still suspect that is due to a misconfigured selinux setup on your
machine. If autofs4 expects to be able to do mkdir() on your NFS
partition (something which in itself is wrong), then selinux should be
configured to allow it to do so.
Anyhow, does reverting the patch
http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a634904a7de0d3a0bc606f608007a34e8c05bfee;hp=ddeff520f02b92128132c282c350fa72afffb84a
'fix' the issue for you?
yes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Trond Myklebust
2006-09-21 23:26:19 UTC
Permalink
Post by Andrew Morton
On Wed, 20 Sep 2006 17:55:33 -0400
Post by Trond Myklebust
Post by Andrew Morton
add-newline-to-nfs-dprintk.patch
fs-nfs-make-code-static.patch
NFS queue -> Trond.
The NFS git tree breaks autofs4 submounts. Still.
I still suspect that is due to a misconfigured selinux setup on your
machine. If autofs4 expects to be able to do mkdir() on your NFS
partition (something which in itself is wrong), then selinux should be
configured to allow it to do so.
Anyhow, does reverting the patch
http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a634904a7de0d3a0bc606f608007a34e8c05bfee;hp=ddeff520f02b92128132c282c350fa72afffb84a
'fix' the issue for you?
yes.
Hmm... but you aren't seeing it with a clean 2.6.18 kernel?

Cheers,
Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-22 15:55:55 UTC
Permalink
On Thu, 21 Sep 2006 19:25:19 -0400
Post by Trond Myklebust
Post by Andrew Morton
On Wed, 20 Sep 2006 17:55:33 -0400
Post by Trond Myklebust
Post by Andrew Morton
add-newline-to-nfs-dprintk.patch
fs-nfs-make-code-static.patch
NFS queue -> Trond.
The NFS git tree breaks autofs4 submounts. Still.
I still suspect that is due to a misconfigured selinux setup on your
machine. If autofs4 expects to be able to do mkdir() on your NFS
partition (something which in itself is wrong), then selinux should be
configured to allow it to do so.
Anyhow, does reverting the patch
http://kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a634904a7de0d3a0bc606f608007a34e8c05bfee;hp=ddeff520f02b92128132c282c350fa72afffb84a
'fix' the issue for you?
yes.
Hmm... but you aren't seeing it with a clean 2.6.18 kernel?
Yes, I am. Mainline broke.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Martin J. Bligh
2006-09-21 00:11:08 UTC
Permalink
Post by Andrew Morton
introduce-config_zone_dma.patch
optional-zone_dma-in-the-vm.patch
optional-zone_dma-in-the-vm-tidy.patch
optional-zone_dma-for-i386.patch
optional-zone_dma-for-x86_64.patch
optional-zone_dma-for-ia64.patch
remove-zone_dma-remains-from-parisc.patch
remove-zone_dma-remains-from-sh-sh64.patch
Would it not make sense to define what ZONE_DMA actually means
consistently before trying to change it? The current mess across
different architectures seems like a disaster area to me.

What DOES requesting ZONE_DMA from a driver actually mean?

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-21 00:23:50 UTC
Permalink
(Subject rewritten, developer cc'ed, thwap delivered)

On Wed, 20 Sep 2006 17:09:57 -0700
Post by Martin J. Bligh
Post by Andrew Morton
introduce-config_zone_dma.patch
optional-zone_dma-in-the-vm.patch
optional-zone_dma-in-the-vm-tidy.patch
optional-zone_dma-for-i386.patch
optional-zone_dma-for-x86_64.patch
optional-zone_dma-for-ia64.patch
remove-zone_dma-remains-from-parisc.patch
remove-zone_dma-remains-from-sh-sh64.patch
Would it not make sense to define what ZONE_DMA actually means
consistently before trying to change it? The current mess across
different architectures seems like a disaster area to me.
What DOES requesting ZONE_DMA from a driver actually mean?
AFAIK it means "floppy disks" ;)

My concern about these patches is that they'll only be useful for
self-compiled kernels, because distros will be forced to enable ZONE_DMA
for evermore anyway.

If that's correct then perhaps we should drop these patches, because they
will serve to weaken ongoing testing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-21 00:32:43 UTC
Permalink
Post by Andrew Morton
Post by Martin J. Bligh
Would it not make sense to define what ZONE_DMA actually means
consistently before trying to change it? The current mess across
different architectures seems like a disaster area to me.
What DOES requesting ZONE_DMA from a driver actually mean?
ZONE_DMA is a memory area that is needed by an arch for devices that
cannot do DMA to all of memory. The high boundary is set by
MAX_DMA_ADDRESS.
Post by Andrew Morton
My concern about these patches is that they'll only be useful for
self-compiled kernels, because distros will be forced to enable ZONE_DMA
for evermore anyway.
We already have 4 arches now that do not need ZONE_DMA at all.

ZONE_DMA does not have a bright future with IOMMUs and other things
around. None of my system uses ZONE_DMA and I have a variety of them.

And yes if we do not have this facility in the kernel then distros cannot
pick it up. At least on IA64 I know that hardware from the major vendors
has not been needing ZONE_DMA for a while now.

Also ZONE_DMA is a very bad concept. Multiple drivers may have different
address requirements. What we need is some way for a driver to tell the
kernel what the required range of addresses is. If a device is only
capable of handling 30 valid address bits then we may have to use
ZONE_DMA and only allow the use of the lower 16MB. It would be better to
develop a different mechanism.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2006-09-21 00:40:47 UTC
Permalink
Post by Christoph Lameter
ZONE_DMA does not have a bright future with IOMMUs and other things
around. None of my system uses ZONE_DMA and I have a variety of them.
IOMMUs don't always help. They IOMMU aperture on AMD64 for example is
too high to help devices with below 32bit limits.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Bottomley
2006-09-21 16:00:55 UTC
Permalink
Post by Alan Cox
IOMMUs don't always help. They IOMMU aperture on AMD64 for example is
too high to help devices with below 32bit limits.
That's because it's not an IOMMU; it's a GART. A true IOMMU separates
the machine physical and bus physical address spaces ... a GART merely
remaps a hole in physical address space.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Martin J. Bligh
2006-09-21 00:51:36 UTC
Permalink
Post by Andrew Morton
(Subject rewritten, developer cc'ed, thwap delivered)
On Wed, 20 Sep 2006 17:09:57 -0700
Post by Martin J. Bligh
Post by Andrew Morton
introduce-config_zone_dma.patch
optional-zone_dma-in-the-vm.patch
optional-zone_dma-in-the-vm-tidy.patch
optional-zone_dma-for-i386.patch
optional-zone_dma-for-x86_64.patch
optional-zone_dma-for-ia64.patch
remove-zone_dma-remains-from-parisc.patch
remove-zone_dma-remains-from-sh-sh64.patch
Would it not make sense to define what ZONE_DMA actually means
consistently before trying to change it? The current mess across
different architectures seems like a disaster area to me.
What DOES requesting ZONE_DMA from a driver actually mean?
AFAIK it means "floppy disks" ;)
That's the problem - it doesn't mean that at all, except on ia32.
It means totally different things on different architectures. IIRC,
on PPC64, it's all of memory.

Having something that's used in generic code that means random
things on different arches just seems like a recipe for disaster
to me.
Post by Andrew Morton
My concern about these patches is that they'll only be useful for
self-compiled kernels, because distros will be forced to enable ZONE_DMA
for evermore anyway.
If that's correct then perhaps we should drop these patches, because they
will serve to weaken ongoing testing.
Well, I think we actually need to define what it means before we
mess with it any more. It's not Christoph's fault that it's broken.
But messing with something that's pretty much undefined will likely
have undefined consequences.
Post by Andrew Morton
Actually the desaster is cleaned up by this patch. A couple of
architectures that were wrongly using ZONE_DMA now use ZONE_NORMAL.
OK ... but requesting ZONE_DMA means what? DMAable for which device?
Is it always a floppy disk? on some platforms a PCI card? And how
is the VM meant to know what the device is capable of anyway?

Having an arch-specific definition of the limit is arbitrary and
useless, is it not? The limit is imposed by the device and its
driver, we're not communicating it into any sensible way into the
VM code, AFAICS. Unless we're pretending we never call it from
generic code, which seems woefully unlikely to me.

Are we redefining ZONE_DMA to always be 16MB limit across all
architectures? At least that'd be consistent.

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-21 01:11:16 UTC
Permalink
Post by Martin J. Bligh
Having something that's used in generic code that means random
things on different arches just seems like a recipe for disaster
to me.
ZONE_DMA is only used as ZONE_NORMAL if the architecture does not
need ZONE_NORMAL because all of memory is reachable via DMA.
Post by Martin J. Bligh
OK ... but requesting ZONE_DMA means what? DMAable for which device?
Is it always a floppy disk? on some platforms a PCI card? And how
is the VM meant to know what the device is capable of anyway?
I already explained that twice to you. I think we all agree that the
situation could be better.
Post by Martin J. Bligh
Having an arch-specific definition of the limit is arbitrary and
useless, is it not? The limit is imposed by the device and its
driver, we're not communicating it into any sensible way into the
VM code, AFAICS. Unless we're pretending we never call it from
generic code, which seems woefully unlikely to me.
Its bad but its not useless. See how various arches use it.
Post by Martin J. Bligh
Are we redefining ZONE_DMA to always be 16MB limit across all
architectures? At least that'd be consistent.
That wont work because many architectures use different limits. Maybe you
should once in a while have a look at the sources.

The patchset leaves the semantics of ZONE_DMA as memory beyond
MAX_DMA_ADDRESS as is. Nothing should break. It only allows us to opt out
of this scheme if we do not need it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Martin J. Bligh
2006-09-21 01:25:15 UTC
Permalink
Post by Christoph Lameter
Post by Martin J. Bligh
Having something that's used in generic code that means random
things on different arches just seems like a recipe for disaster
to me.
ZONE_DMA is only used as ZONE_NORMAL if the architecture does not
need ZONE_NORMAL because all of memory is reachable via DMA.
That's still inconsistent because it doesn't say DMA for *which*
device.
Post by Christoph Lameter
Post by Martin J. Bligh
OK ... but requesting ZONE_DMA means what? DMAable for which device?
Is it always a floppy disk? on some platforms a PCI card? And how
is the VM meant to know what the device is capable of anyway?
I already explained that twice to you.
We seem to be miscommunicating ... you did indeed give a technically
correct definition. But in practice, AFAICS, it's useless. The requestor
has no idea what the arch has implemented, if it's a driver from
arch-independent code.
Post by Christoph Lameter
I think we all agree that the situation could be better.
Indeed, that would seem to cause little dispute.
Post by Christoph Lameter
Post by Martin J. Bligh
Having an arch-specific definition of the limit is arbitrary and
useless, is it not? The limit is imposed by the device and its
driver, we're not communicating it into any sensible way into the
VM code, AFAICS. Unless we're pretending we never call it from
generic code, which seems woefully unlikely to me.
Its bad but its not useless. See how various arches use it.
Post by Martin J. Bligh
Are we redefining ZONE_DMA to always be 16MB limit across all
architectures? At least that'd be consistent.
That wont work because many architectures use different limits. Maybe you
should once in a while have a look at the sources.
I'm perfectly well aware that it's inconsistent, that's my whole point.
However, by some chance of history, it's sort of vaguely working. I
think it's dangerous to mess with it rather than fixing it properly.

AFAICS, the correct way to do this is have the requestor pass a memory
bound into the allocator, and have the arch figure out which zones
are applicable.
Post by Christoph Lameter
Actually the desaster is cleaned up by this patch. A couple of
architectures that were wrongly using ZONE_DMA now use ZONE_NORMAL.
Odd that the PPC64 maintainers didn't seem to know about this.
Perhaps it might be a good idea to talk to them before doing this?

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-21 15:59:11 UTC
Permalink
Post by Martin J. Bligh
ZONE_DMA is only used as ZONE_NORMAL if the architecture does not need
ZONE_NORMAL because all of memory is reachable via DMA.
That's still inconsistent because it doesn't say DMA for *which*
device.
Thats the way ZONE_DMA works right now and AFAIK the only way forward is
to make it optional and then introduce another way of allocating memory
for a device. The migrate away from it. The first step is to allow people
who do not need ZONE_DMA to opt out.
Post by Martin J. Bligh
That wont work because many architectures use different limits. Maybe you
should once in a while have a look at the sources.
I'm perfectly well aware that it's inconsistent, that's my whole point.
However, by some chance of history, it's sort of vaguely working. I
think it's dangerous to mess with it rather than fixing it properly.
I think you are spreading FUD. The existing scheme has been working for a
long time. Come up with something concrete. I am not
changing the definition of ZONE_DMA.
Post by Martin J. Bligh
AFAICS, the correct way to do this is have the requestor pass a memory
bound into the allocator, and have the arch figure out which zones
are applicable.
Exactly. But you cannot do that with ZONE_DMA __GFP_DMA. We likely need a
new page allocator API for that.
Post by Martin J. Bligh
Actually the desaster is cleaned up by this patch. A couple of architectures
that were wrongly using ZONE_DMA now use ZONE_NORMAL.
Odd that the PPC64 maintainers didn't seem to know about this.
Perhaps it might be a good idea to talk to them before doing this?
Maybe they have not been reading linux-arch? It was discussed among arch
maintainers and 4 arches have switched off ZONE_DMA for good.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Martin Bligh
2006-09-21 16:57:48 UTC
Permalink
Post by Christoph Lameter
Post by Martin J. Bligh
ZONE_DMA is only used as ZONE_NORMAL if the architecture does not need
ZONE_NORMAL because all of memory is reachable via DMA.
That's still inconsistent because it doesn't say DMA for *which*
device.
Thats the way ZONE_DMA works right now and AFAIK the only way forward is
to make it optional and then introduce another way of allocating memory
for a device. The migrate away from it. The first step is to allow people
who do not need ZONE_DMA to opt out.
OK. Let's leave aside the issue for a second of whether ZONE_DMA should
be configurable or not (ie your patch), and just worry about how this
works in practice going forwards in the short term. Don't get me wrong,
I'd love to kill ZONE_DMA, or at least the 16MB way it's implemented in
i386 right now.

I presume the fallback order for everything is still
HIGHMEM -> NORMAL -> DMA, and nobody is proposing changing that.
(ignoring DMA32 to keep thing simpler).

If a device driver wants "DMAable" memory, and thus does a ZONE_DMA
allocation, and we've moved all its memory from ZONE_DMA to ZONE_NORMAL
(as I think you're proposing doing for PPC64 (and ia64?)), then the
allocation will fail.

So are we saying that no driver code should be calling with GFP_DMA
(a quick grep turns up 148 instances under driver/), that if they do
they should only work on specific architectures (some instances were
s390-only drivers)? If so, should we not be removing the definiton of
GFP_DMA itself if ZONE_DMA is config'ed out, so that it fails at
compile time, rather than runtime?
Post by Christoph Lameter
Post by Martin J. Bligh
AFAICS, the correct way to do this is have the requestor pass a memory
bound into the allocator, and have the arch figure out which zones
are applicable.
Exactly. But you cannot do that with ZONE_DMA __GFP_DMA. We likely need a
new page allocator API for that.
Glad we're agreed on that, at least.

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-21 17:55:19 UTC
Permalink
Post by Martin Bligh
I presume the fallback order for everything is still
HIGHMEM -> NORMAL -> DMA, and nobody is proposing changing that.
(ignoring DMA32 to keep thing simpler).
It would help if you would actually look at the code instead of presuming.
No changes are made in that area.
Post by Martin Bligh
If a device driver wants "DMAable" memory, and thus does a ZONE_DMA
allocation, and we've moved all its memory from ZONE_DMA to ZONE_NORMAL
(as I think you're proposing doing for PPC64 (and ia64?)), then the
allocation will fail.
I would not presume proposing anything for PPC64 and left everything the
way it is. The arch people can control if they want ZONE DMA or not and
the default is to leave things as is. If PPC64 wants to go ZONE_DMAless
then the arch code needs to be modified not refer to ZONE_DMA anymore and
if that works then we can switch CONFIG_ZONE_DMA off for PPC64. See the
patches in mm for examples how other arches have done it.
Post by Martin Bligh
So are we saying that no driver code should be calling with GFP_DMA
(a quick grep turns up 148 instances under driver/), that if they do
they should only work on specific architectures (some instances were
s390-only drivers)? If so, should we not be removing the definiton of
GFP_DMA itself if ZONE_DMA is config'ed out, so that it fails at
compile time, rather than runtime?
This was covered at length before. Removing all GFP_DMA references would
require extensive #ifdefs. The limited patch in mm is only neutering
GFP_DMA for arches that do not need it. If an arch has removed its definition of
CONFIG_ZONE_DMA then __GFP_DMA will be ignored in the page allocator.
Post by Martin Bligh
Post by Christoph Lameter
Post by Martin J. Bligh
AFAICS, the correct way to do this is have the requestor pass a memory
bound into the allocator, and have the arch figure out which zones
are applicable.
Exactly. But you cannot do that with ZONE_DMA __GFP_DMA. We likely need a
new page allocator API for that.
Glad we're agreed on that, at least.
I think we agree on a lot more. Hopefully when we meet at lunch today we
can sync some more.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Martin Bligh
2006-09-21 23:16:30 UTC
Permalink
Post by Christoph Lameter
Post by Martin Bligh
If a device driver wants "DMAable" memory, and thus does a ZONE_DMA
allocation, and we've moved all its memory from ZONE_DMA to ZONE_NORMAL
(as I think you're proposing doing for PPC64 (and ia64?)), then the
allocation will fail.
I would not presume proposing anything for PPC64 and left everything the
way it is. The arch people can control if they want ZONE DMA or not and
the default is to leave things as is. If PPC64 wants to go ZONE_DMAless
then the arch code needs to be modified not refer to ZONE_DMA anymore and
if that works then we can switch CONFIG_ZONE_DMA off for PPC64. See the
patches in mm for examples how other arches have done it.
Sorry, there was some confusion then, maybe I misunderstood one of your
earlier emails.
Post by Christoph Lameter
Post by Martin Bligh
So are we saying that no driver code should be calling with GFP_DMA
(a quick grep turns up 148 instances under driver/), that if they do
they should only work on specific architectures (some instances were
s390-only drivers)? If so, should we not be removing the definiton of
GFP_DMA itself if ZONE_DMA is config'ed out, so that it fails at
compile time, rather than runtime?
This was covered at length before. Removing all GFP_DMA references would
require extensive #ifdefs. The limited patch in mm is only neutering
GFP_DMA for arches that do not need it. If an arch has removed its definition of
CONFIG_ZONE_DMA then __GFP_DMA will be ignored in the page allocator.
Just ignoring GFP_DMA in the allocator seems like a horrible violation
to me. GFP_DMA means "give me memory from ZONE_DMA". We're both well
aware that the whole concept of ZONE_DMA doesn't make much sense, but
still, that's what it does.

So if you just put all of memory in ZONE_DMA for your particular
machine, and bumped the DMA limit up to infinity, we wouldn't need
any of these patches, right? Which would also match what the other
arches do for this (eg PPC64).

Seems like a much simpler way of solving the problem to me. Or do you
think that won't work for some reason?

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-22 02:59:44 UTC
Permalink
Post by Martin Bligh
Just ignoring GFP_DMA in the allocator seems like a horrible violation
to me. GFP_DMA means "give me memory from ZONE_DMA". We're both well
aware that the whole concept of ZONE_DMA doesn't make much sense, but
still, that's what it does.
We agreed that the definition of ZONE_DMA is not consistent across
architectures.

The concept of ZONE_DMA makes only sense in terms of an architectures
definition if a memory boundary (MAX_DMA_ADDRESS) exists for special DMA
devices not able to reach all of memory. If we do not have ZONE_DMA then the
architecture has to remove the definition of CONFIG_ZONE_DMA
and with that action told us that it is allowable to ignore GFP_DMA since
all devices can do DMA to all of memory (and all of memory is memory
without a border which is of course in ZONE_NORMAL).

GFP_DMA like GFP_HIGHMEM and GFP_DMA32 means give me memory from the zone
if its there. If not (the arch has no such memory) we fall back to ZONE_NORMAL.

This is fully consistent with established uses.
Post by Martin Bligh
So if you just put all of memory in ZONE_DMA for your particular
machine, and bumped the DMA limit up to infinity, we wouldn't need
any of these patches, right? Which would also match what the other
arches do for this (eg PPC64).
That would mean abusing ZONE_DMA for a purpose it was not intended for.
ZOME_DMA is used to partition memory for a DMA not for covering all of
memory. That works yes but it shows a misunderstanding of the purpose for
which ZONE_DMA was created.

Also if you would do that then ZONE_NORMAL would be empty and you would
not be able to reach the goal of a system with a single zone. The slab
allocator gets thoroughly confused and waste pages allocating
memory in different slabs for ZONE_NORMAL and ZONE_DMA but they end up in
the same ZONE_DMA. Various other bits and pieces of the VM behave in
strange way but it works mostly. Seems that you got lucky but this should
be fixed.

ZONE_NORMAL is DMAable. GFP_DMA has never meant this is for DMA but it has
always meant this is for a special restricted DMA zone. That is also why
you have GFP_DMA32. Both GFP_DMA and GFP_DMA32 select special restricted
memory areas for handicapped DMA devices that are not able to reach all of
memory. Neither should cover all of memory.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jesse Barnes
2006-09-22 17:22:06 UTC
Permalink
Post by Christoph Lameter
Post by Martin Bligh
So if you just put all of memory in ZONE_DMA for your particular
machine, and bumped the DMA limit up to infinity, we wouldn't need
any of these patches, right? Which would also match what the other
arches do for this (eg PPC64).
This is what Altix did for a long time (and it looks like it still sets
MAX_DMA_ADDRESS to the top of addressable memory).
Post by Christoph Lameter
That would mean abusing ZONE_DMA for a purpose it was not intended for.
ZOME_DMA is used to partition memory for a DMA not for covering all of
memory. That works yes but it shows a misunderstanding of the purpose
for which ZONE_DMA was created.
AFAIK ZONE_DMA was created for crappy ISA devices that could only DMA to
low addresses. As various architectures were added, they either
misunderstood its purpose, abused it for their own purposes, or ignored it
in some way as it didn't really apply.
Post by Christoph Lameter
ZONE_NORMAL is DMAable. GFP_DMA has never meant this is for DMA but it
has always meant this is for a special restricted DMA zone. That is also
why you have GFP_DMA32. Both GFP_DMA and GFP_DMA32 select special
restricted memory areas for handicapped DMA devices that are not able to
reach all of memory. Neither should cover all of memory.
If you have a decent enough IOMMU both or either could cover all of memory.
In the case of an Altix, the IOMMU is 32 bit capable, so it would make
sense for ZONE_DMA32 to contain all of memory...

But anyway, I agree with your broader point that we really need a different
allocator for this stuff. It has to be arch specific in some way though,
so we can take into account the advantages IOMMUs provide. I think jejb
said he'd come up with a sample implementation a couple of years ago... :)

From a portability and definition perspective, I'd contend that ZONE_DMA
and ZONE_DMA32 are both broken. Only ZONE_NORMAL and ZONE_HIGHMEM have
sane definitions it seems.

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jesse Barnes
2006-09-22 17:44:21 UTC
Permalink
Post by Jesse Barnes
If you have a decent enough IOMMU both or either could cover all of
memory. In the case of an Altix, the IOMMU is 32 bit capable, so it
would make sense for ZONE_DMA32 to contain all of memory...
But anyway, I agree with your broader point that we really need a
different allocator for this stuff. It has to be arch specific in some
way though, so we can take into account the advantages IOMMUs provide.
I think jejb said he'd come up with a sample implementation a couple of
years ago... :)
From a portability and definition perspective, I'd contend that ZONE_DMA
and ZONE_DMA32 are both broken. Only ZONE_NORMAL and ZONE_HIGHMEM have
sane definitions it seems.
Ok and right after I sent this my brain returned from vacation and I
remembered jejb's DMA allocation API. It's powerful enough to cover most
driver use cases I think (users of GFP_DMA should probably be converted),
but for example block layer bounce buffering might need a different
interface as I see you've proposed in another mail.

Hm... s390 driver seem to like GFP_DMA a lot... and there are a few
remaining uses in drivers/scsi... and then of course there are the OSS
drivers...

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-22 18:09:24 UTC
Permalink
Post by Jesse Barnes
Ok and right after I sent this my brain returned from vacation and I
remembered jejb's DMA allocation API. It's powerful enough to cover most
driver use cases I think (users of GFP_DMA should probably be converted),
but for example block layer bounce buffering might need a different
interface as I see you've proposed in another mail.
Could you dig that out and give us some refs or even better port that
thing to a current mm tree?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jesse Barnes
2006-09-22 18:26:17 UTC
Permalink
Post by Christoph Lameter
Post by Jesse Barnes
Ok and right after I sent this my brain returned from vacation and I
remembered jejb's DMA allocation API. It's powerful enough to cover
most driver use cases I think (users of GFP_DMA should probably be
converted), but for example block layer bounce buffering might need a
different interface as I see you've proposed in another mail.
Could you dig that out and give us some refs or even better port that
thing to a current mm tree?
Oh, it's already there in the tree, but obviously some drivers still need
to be converted. See Documentation/DMA-API.txt. It's not PCI specific
like the old PCI DMA interface (Documentation/DMA-mapping.txt) and
provides a way for drivers to specify their addressing limitations
(dma_supported and dma_set_mask), which allows the underlying architecture
code to report a failure if necessary.

I think many of the examples I cited can be converted to use the DMA API,
but block layer bounce buffering might need special treatment or perhaps a
way to get at the underlying struct device for the associated request...

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-22 18:33:11 UTC
Permalink
Post by Jesse Barnes
Oh, it's already there in the tree, but obviously some drivers still need
to be converted. See Documentation/DMA-API.txt. It's not PCI specific
like the old PCI DMA interface (Documentation/DMA-mapping.txt) and
provides a way for drivers to specify their addressing limitations
(dma_supported and dma_set_mask), which allows the underlying architecture
code to report a failure if necessary.
AFAICT this is dealing with special dma issues and not with the problem of
allocating memory for a certain supported address range from the page
allocator. From the first glance at the docs it looks as if it is relying
on __GFP_DMAxx to get the allocations right. I think the code could be
changed though to call a new page allocator function to get the right
memory and that would work for all devices using that API.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jesse Barnes
2006-09-22 18:39:44 UTC
Permalink
Post by Christoph Lameter
Post by Jesse Barnes
Oh, it's already there in the tree, but obviously some drivers still
need to be converted. See Documentation/DMA-API.txt. It's not PCI
specific like the old PCI DMA interface
(Documentation/DMA-mapping.txt) and provides a way for drivers to
specify their addressing limitations (dma_supported and dma_set_mask),
which allows the underlying architecture code to report a failure if
necessary.
AFAICT this is dealing with special dma issues and not with the problem
of allocating memory for a certain supported address range from the page
allocator.
That's right. But OTOH device drivers shouldn't be using the page
allocator to get DMAable memory, they should be using one of the DMA APIs
since only they can portably map memory for DMA.
Post by Christoph Lameter
From the first glance at the docs it looks as if it is
relying on __GFP_DMAxx to get the allocations right. I think the code
could be changed though to call a new page allocator function to get the
right memory and that would work for all devices using that API.
Right, the internals are arch specific and don't necessarily have to rely
on a zone, depending on their DMA constraints.

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-22 18:41:40 UTC
Permalink
Post by Jesse Barnes
Right, the internals are arch specific and don't necessarily have to rely
on a zone, depending on their DMA constraints.
From what I can see the arch specific do some tricks and then pick GFP_DMA
or something to get memory that is appropriately limited. Having the
ability to retrieve pages from a certain range from the page allocator
would fix this issue and improve the ability of devices to allocate
memory.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jesse Barnes
2006-09-22 19:06:41 UTC
Permalink
Post by Christoph Lameter
Post by Jesse Barnes
Right, the internals are arch specific and don't necessarily have to
rely on a zone, depending on their DMA constraints.
From what I can see the arch specific do some tricks and then pick
GFP_DMA or something to get memory that is appropriately limited. Having
the ability to retrieve pages from a certain range from the page
allocator would fix this issue and improve the ability of devices to
allocate memory.
Right, being able to allocate from specific ranges would obviate the need
for GFP_DMA and the various zones. It would come with a cost though since
the VM would have to become aware of pressure at various ranges rather
than just on zones like we have now. I think that's where things get
tricky.

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-22 19:08:41 UTC
Permalink
Post by Jesse Barnes
Right, being able to allocate from specific ranges would obviate the need
for GFP_DMA and the various zones. It would come with a cost though since
the VM would have to become aware of pressure at various ranges rather
than just on zones like we have now. I think that's where things get
tricky.
Here is a hyperthetical use scenario (no code yet to do this in the page
allocator, fake patch for discussion only):

Index: linux-2.6.18-rc7-mm1/arch/i386/kernel/pci-dma.c
===================================================================
--- linux-2.6.18-rc7-mm1.orig/arch/i386/kernel/pci-dma.c 2006-09-12 20:41:36.000000000 -0500
+++ linux-2.6.18-rc7-mm1/arch/i386/kernel/pci-dma.c 2006-09-22 13:59:29.017611573 -0500
@@ -26,6 +26,8 @@ void *dma_alloc_coherent(struct device *
dma_addr_t *dma_handle, gfp_t gfp)
{
void *ret;
+ unsigned long low = 0L;
+ unsigned long high = 0xffffffff;
struct dma_coherent_mem *mem = dev ? dev->dma_mem : NULL;
int order = get_order(size);
/* ignore region specifiers */
@@ -44,10 +46,14 @@ void *dma_alloc_coherent(struct device *
return NULL;
}

- if (dev == NULL || (dev->coherent_dma_mask < 0xffffffff))
- gfp |= GFP_DMA;
+ if (dev == NULL)
+ /* Apply safe ISA LIMITS */
+ high = 16*1024*1024L;
+ else
+ if (dev->coherent_dma_mask < 0xffffffff)
+ high = dev->coherent_dma_mask;

- ret = (void *)__get_free_pages(gfp, order);
+ ret = page_address(alloc_pages_range(low, high, gfp, order));

if (ret != NULL) {
memset(ret, 0, size);
Index: linux-2.6.18-rc7-mm1/include/linux/gfp.h
===================================================================
--- linux-2.6.18-rc7-mm1.orig/include/linux/gfp.h 2006-09-19 09:26:58.000000000 -0500
+++ linux-2.6.18-rc7-mm1/include/linux/gfp.h 2006-09-22 14:02:34.298613635 -0500
@@ -136,6 +136,9 @@ static inline struct page *alloc_pages_n
NODE_DATA(nid)->node_zonelists + gfp_zone(gfp_mask));
}

+extern struct page *alloc_pages_range(unsigned long low, unsigned long high,
+ gfp_t gfp_mask, unsigned int order);
+
#ifdef CONFIG_NUMA
extern struct page *alloc_pages_current(gfp_t gfp_mask, unsigned order);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Martin Bligh
2006-09-22 17:36:05 UTC
Permalink
Post by Christoph Lameter
Post by Martin Bligh
Just ignoring GFP_DMA in the allocator seems like a horrible violation
to me. GFP_DMA means "give me memory from ZONE_DMA". We're both well
aware that the whole concept of ZONE_DMA doesn't make much sense, but
still, that's what it does.
We agreed that the definition of ZONE_DMA is not consistent across
architectures.
The concept of ZONE_DMA makes only sense in terms of an architectures
definition if a memory boundary (MAX_DMA_ADDRESS) exists for special DMA
devices not able to reach all of memory. If we do not have ZONE_DMA then the
architecture has to remove the definition of CONFIG_ZONE_DMA
and with that action told us that it is allowable to ignore GFP_DMA since
all devices can do DMA to all of memory (and all of memory is memory
without a border which is of course in ZONE_NORMAL).
GFP_DMA like GFP_HIGHMEM and GFP_DMA32 means give me memory from the zone
if its there. If not (the arch has no such memory) we fall back to ZONE_NORMAL.
This is fully consistent with established uses.
Given that the definition of ZONE_DMA is, I think we agree, nonsensical
in generic code anyway, whatever we do is going to be a pain.

I disagree that what you're doing is consistent with established
usage, see PPC64 for example, which I assumed you'd changed to be
consistent with what you're doing ... but it seems you haven't.

Your definition is one way of interpreting the current setup. It even
makes some sort of sense, I'll admit. However, there are other
definitions that make perfect sense too, which just goes to show that
the concept of ZONE_DMA is just a frigging inconsistent mess to start
with.
Post by Christoph Lameter
Post by Martin Bligh
So if you just put all of memory in ZONE_DMA for your particular
machine, and bumped the DMA limit up to infinity, we wouldn't need
any of these patches, right? Which would also match what the other
arches do for this (eg PPC64).
That would mean abusing ZONE_DMA for a purpose it was not intended for.
ZOME_DMA is used to partition memory for a DMA not for covering all of
memory. That works yes but it shows a misunderstanding of the purpose for
which ZONE_DMA was created.
That is one possible way of defining it, but seeing as there is no
agreed to, documented definition, it's hard to tell whether this trumps
such other defined constants such as "GFP_DMA means gives me memory from
ZONE_DMA", which you're now violating.
Post by Christoph Lameter
Also if you would do that then ZONE_NORMAL would be empty and you would
not be able to reach the goal of a system with a single zone. The slab
allocator gets thoroughly confused and waste pages allocating
memory in different slabs for ZONE_NORMAL and ZONE_DMA but they end up in
the same ZONE_DMA. Various other bits and pieces of the VM behave in
strange way but it works mostly. Seems that you got lucky but this should
be fixed.
It seems odd that PPC64 has worked fine this way for a long time then?
Post by Christoph Lameter
ZONE_NORMAL is DMAable. GFP_DMA has never meant this is for DMA but it has
always meant this is for a special restricted DMA zone. That is also why
you have GFP_DMA32. Both GFP_DMA and GFP_DMA32 select special restricted
memory areas for handicapped DMA devices that are not able to reach all of
memory. Neither should cover all of memory.
The last sentence in this is your opinion, not an agreed-to definition.

Look, whatever we do is not going to be wholly clean, as the definitons
and requirements we start from are loose, inconsistent and somewhat
contradictary on occasion. So what we are left with is picking something
that is:

1. As consistent as possible across architectures.
2. As simple as possible.

If you can agree with the other arch maintainers (eg PPC64) that
stuffing it all in ZONE_NORMAL is somehow better than ZONE_DMA, then
maybe we can meet (1).

However, whatever you do, meeting (2) is rather hard - it's a damned
sight simpler to stuff it all in ZONE_DMA because that's the end of
the fallback list.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-22 17:38:21 UTC
Permalink
Post by Martin Bligh
However, whatever you do, meeting (2) is rather hard - it's a damned
sight simpler to stuff it all in ZONE_DMA because that's the end of
the fallback list.
That used to be the case. If you switch ZONE_DMA off (like possible in mm)
then ZONE_NORMAL is the end of the fallback. I think we basically want
the same thing and get to the same result.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Lameter
2006-09-21 00:41:08 UTC
Permalink
Post by Martin J. Bligh
Would it not make sense to define what ZONE_DMA actually means
consistently before trying to change it? The current mess across
different architectures seems like a disaster area to me.
Actually the desaster is cleaned up by this patch. A couple of
architectures that were wrongly using ZONE_DMA now use ZONE_NORMAL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
john stultz
2006-09-21 02:38:58 UTC
Permalink
Post by Andrew Morton
A wander through the -mm patch queue, along with some commentary on my
intentions.
When replying to this email, please rewrite the Subject: to something
appropriate. Please also attempt to cc the appropriate developer(s).
ntp-move-all-the-ntp-related-code-to-ntpc.patch
ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
ntp-add-ntp_update_frequency.patch
ntp-add-ntp_update_frequency-fix.patch
ntp-add-time_adj-to-tick-length.patch
ntp-add-time_freq-to-tick-length.patch
ntp-prescale-time_offset.patch
ntp-add-time_adjust-to-tick-length.patch
ntp-remove-time_tolerance.patch
ntp-convert-time_freq-to-nsec-value.patch
ntp-convert-to-the-ntp4-reference-model.patch
ntp-cleanup-defines-and-comments.patch
kernel-time-ntpc-possible-cleanups.patch
kill-wall_jiffies.patch
Will merge.
No objections here, but I wanted to put forth some caution as I've seen
some odd NTP behavior with the full NTP patchset on my laptop (either it
does not converge or it just converges *much* more slowly then without).
Unfortunately I've not been able to collect solid enough data to analyze
the issue (really, each run should go for atleast a full day and always
run on the same network).

However, in trying to narrow it down, the
ntp-add-time_adj-to-tick-length patch is where the behavior seems to
change the most. Again, no solid data, so I could be seeing ghosts, but
I wanted to mention it.

I'll try to put aside some time to run a few longer tests and see if I
can get some clear results.

thanks
-john

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-21 02:42:17 UTC
Permalink
On Wed, 20 Sep 2006 19:28:51 -0700
Post by john stultz
Post by Andrew Morton
A wander through the -mm patch queue, along with some commentary on my
intentions.
When replying to this email, please rewrite the Subject: to something
appropriate. Please also attempt to cc the appropriate developer(s).
ntp-move-all-the-ntp-related-code-to-ntpc.patch
ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
ntp-add-ntp_update_frequency.patch
ntp-add-ntp_update_frequency-fix.patch
ntp-add-time_adj-to-tick-length.patch
ntp-add-time_freq-to-tick-length.patch
ntp-prescale-time_offset.patch
ntp-add-time_adjust-to-tick-length.patch
ntp-remove-time_tolerance.patch
ntp-convert-time_freq-to-nsec-value.patch
ntp-convert-to-the-ntp4-reference-model.patch
ntp-cleanup-defines-and-comments.patch
kernel-time-ntpc-possible-cleanups.patch
kill-wall_jiffies.patch
Will merge.
No objections here, but I wanted to put forth some caution as I've seen
some odd NTP behavior with the full NTP patchset on my laptop (either it
does not converge or it just converges *much* more slowly then without).
Unfortunately I've not been able to collect solid enough data to analyze
the issue (really, each run should go for atleast a full day and always
run on the same network).
However, in trying to narrow it down, the
ntp-add-time_adj-to-tick-length patch is where the behavior seems to
change the most. Again, no solid data, so I could be seeing ghosts, but
I wanted to mention it.
I'll try to put aside some time to run a few longer tests and see if I
can get some clear results.
OK, thanks. Won't merge.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Roman Zippel
2006-09-21 10:25:10 UTC
Permalink
Hi,
Post by john stultz
No objections here, but I wanted to put forth some caution as I've seen
some odd NTP behavior with the full NTP patchset on my laptop (either it
does not converge or it just converges *much* more slowly then without).
Unfortunately I've not been able to collect solid enough data to analyze
the issue (really, each run should go for atleast a full day and always
run on the same network).
grumble...
As I said before it's expected that the initial covergence is slower and I
need the data over multiple days to really say something about it.
There has been really a lot of time for doing this...

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-21 04:22:58 UTC
Permalink
Post by Andrew Morton
A wander through the -mm patch queue, along with some commentary on my
intentions.
When replying to this email, please rewrite the Subject: to something
appropriate. Please also attempt to cc the appropriate developer(s).
There are quite a lot of patches here which belong in subsystem trees.
I'll patchbomb the relevant maintainers soon. Could I pleeeeeze ask that
they either merge the patches or solidly nack them (with reasons)? Don't
just ignore it all and leave me hanging onto this stuff for ever. Thanks.
I know this is probably heresy, but what would happen if we didn't merge
all that stuff at once, and then committed to having a real 4-week cycle?

The cycles seem to be stretching out again, and I don't really think
it's worth it to hold up the entire kernel for every single piddly
little regression to get fixed. We'll _never_ be perfect, even if we
weren't slackers.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-21 05:09:14 UTC
Permalink
On Thu, 21 Sep 2006 00:22:26 -0400
Post by Jeff Garzik
Post by Andrew Morton
A wander through the -mm patch queue, along with some commentary on my
intentions.
When replying to this email, please rewrite the Subject: to something
appropriate. Please also attempt to cc the appropriate developer(s).
There are quite a lot of patches here which belong in subsystem trees.
I'll patchbomb the relevant maintainers soon. Could I pleeeeeze ask that
they either merge the patches or solidly nack them (with reasons)? Don't
just ignore it all and leave me hanging onto this stuff for ever. Thanks.
I know this is probably heresy, but what would happen if we didn't merge
all that stuff at once, and then committed to having a real 4-week cycle?
(where'd 4 weeks come from?)

Why would a shorter cycle be better? What are we trying to achieve?
Post by Jeff Garzik
The cycles seem to be stretching out again, and I don't really think
it's worth it to hold up the entire kernel for every single piddly
little regression to get fixed. We'll _never_ be perfect, even if we
weren't slackers.
People seem to treat the stabilisation period as a wonderful quiet time in
which to run off and develop new features, rather than participating in the
stabilisation. This has the following effects:

1: release cycles get longer

2: the kernel has more bugs

3: we put new features into the kernel faster than we otherwise would
(see 2:, above).


Furthermore, in this period we have 60-odd disjoint trees which are based
on a relatively-slowly-changing mainline. This makes people think they are
free to go berzerk, leaving me bemusedly wondering why there are VFS and
NFS changes in the OCFS2 tree, SATA changes in the powerpc tree, SATA
changes in the scsi tree, configfs changes in the GFS2 tree,
every-goddam-thing changes in the driver tree, MM changes in the parisc
tree, etc, etc, etc.

If you think that shortening the release cycle will cause people to be more
disciplined in their changes, to spend less time going berzerk and to spend
more time working with our users and testers on known bugs then I'm all
ears.



So... it again comes down to "what are we trying to achieve"? Me, I'd
like to see people spending less time developing whizzy new things and more
time fixing bugs, tuning performance, etc. That would fix the lengthy
release cycle problem automatically.

What do _you_ want to achieve by making changes?


And a question. The current batch of git trees has:

2611 files changed, 295643 insertions(+), 130150 deletions(-)

How much of this has been suitably reviewed?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Torvalds
2006-09-21 05:24:04 UTC
Permalink
Post by Andrew Morton
Why would a shorter cycle be better? What are we trying to achieve?
I don't think a shorter cycle is necessarily better, but I think we could
try having a more "directed" cycle, and perhaps merge certain specific
things rather than everything.

That would possibly _cause_ a shorter cycle, if only because the problems
are hopefully more focused from the fact that we merged with a certain
focus.

Of course, it would likely just frustrate the people who didn't get
merged, and would need to wait for the next cycle. So it might be a net
negative, even if we'd bring individual cycles in a bit.
Post by Andrew Morton
Post by Jeff Garzik
The cycles seem to be stretching out again, and I don't really think
it's worth it to hold up the entire kernel for every single piddly
little regression to get fixed. We'll _never_ be perfect, even if we
weren't slackers.
I think that's true. 2.6.18 got delayed partly due to me beign away, but I
also think that it then got delayed too much afterwards too, just because
I felt a bit nervous about having been away ;)

So it definitely stretched out too much.

Whether there is a lot we can do about it, I dunno. In many ways, the real
issue is simply that we have a lot of changes. And people are _never_ as
interested in the testing part as they were in writing new code..

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2006-09-21 08:51:01 UTC
Permalink
Post by Linus Torvalds
Post by Andrew Morton
Why would a shorter cycle be better? What are we trying to achieve?
I don't think a shorter cycle is necessarily better, but I think we could
try having a more "directed" cycle, and perhaps merge certain specific
things rather than everything.
Works for me. We do need to keep pushing drivers each cycle (and we need
faster cycles just to keep up with the chipset people) but a situation
where people are told to keep those driver updates working with the old
core code would be fine (ie as 2.4 sometimes was) for some of the cycles
when they are not the goal.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-21 06:37:28 UTC
Permalink
Post by Andrew Morton
If you think that shortening the release cycle will cause people to be more
disciplined in their changes, to spend less time going berzerk and to spend
more time working with our users and testers on known bugs then I'm all
ears.
Honestly, I do think it would be positive. It would shorten the
feedback loop, and get more changes out to testers.

It would also decrease the pressure of the 60+ trees trying to get
everything in, because they know the next release is 3-4 months away.
It would be _much_ easier to say "break the generic device stuff in
2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007
release.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-21 06:49:00 UTC
Permalink
On Thu, 21 Sep 2006 02:36:55 -0400
Post by Jeff Garzik
Post by Andrew Morton
If you think that shortening the release cycle will cause people to be more
disciplined in their changes, to spend less time going berzerk and to spend
more time working with our users and testers on known bugs then I'm all
ears.
Honestly, I do think it would be positive. It would shorten the
feedback loop, and get more changes out to testers.
It would also decrease the pressure of the 60+ trees trying to get
everything in, because they know the next release is 3-4 months away.
It would be _much_ easier to say "break the generic device stuff in
2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007
release.
Well, it might be worth trying. But there's a practical problem: how do we
get there when there's so much work pending? If we skip some people's
trees then they'll get sore, and it's not obvious that it'll help much, as
the various trees are fairly unrelated (ie: parallelisable).

I guess the most practical way is to incrementally shorten the cycles.


<rerererepeating self>

I do think that any process change we make should send the signal "slow
down, be more careful, test and review it more carefully". Or at least,
"try to make sure it compiles".

A compulsory Reviewed-by: would wedge things up nicely ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rafael J. Wysocki
2006-09-21 11:08:47 UTC
Permalink
Post by Andrew Morton
On Thu, 21 Sep 2006 02:36:55 -0400
Post by Jeff Garzik
Post by Andrew Morton
If you think that shortening the release cycle will cause people to be more
disciplined in their changes, to spend less time going berzerk and to spend
more time working with our users and testers on known bugs then I'm all
ears.
Honestly, I do think it would be positive. It would shorten the
feedback loop, and get more changes out to testers.
It would also decrease the pressure of the 60+ trees trying to get
everything in, because they know the next release is 3-4 months away.
It would be _much_ easier to say "break the generic device stuff in
2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007
release.
Well, it might be worth trying. But there's a practical problem: how do we
get there when there's so much work pending? If we skip some people's
trees then they'll get sore, and it's not obvious that it'll help much, as
the various trees are fairly unrelated (ie: parallelisable).
I guess the most practical way is to incrementally shorten the cycles.
<rerererepeating self>
I do think that any process change we make should send the signal "slow
down, be more careful, test and review it more carefully". Or at least,
"try to make sure it compiles".
A compulsory Reviewed-by: would wedge things up nicely ;)
Well, I think this need not help. Like when some USB-related changes that
had been reviewed and even tested happened to break ohci-hcd because they
had only been tested on uhci ...

IMHO every change should appear in at least three consecutive -mm kernels
without causing any problems before it's allowed to go to the mainline.

Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
2006-09-22 18:54:28 UTC
Permalink
Hi!
Post by Andrew Morton
Post by Jeff Garzik
Post by Andrew Morton
If you think that shortening the release cycle will cause people to be more
disciplined in their changes, to spend less time going berzerk and to spend
more time working with our users and testers on known bugs then I'm all
ears.
Honestly, I do think it would be positive. It would shorten the
feedback loop, and get more changes out to testers.
It would also decrease the pressure of the 60+ trees trying to get
everything in, because they know the next release is 3-4 months away.
It would be _much_ easier to say "break the generic device stuff in
2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007
release.
Well, it might be worth trying. But there's a practical problem: how do we
get there when there's so much work pending? If we skip some people's
trees then they'll get sore, and it's not obvious that it'll help much, as
the various trees are fairly unrelated (ie: parallelisable).
Well, slightly evil way would be 'if we find vfs changes in your ocfs
tree, well, you wait for one more release' :-).

Pavel
--
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2006-09-21 08:53:45 UTC
Permalink
Post by Andrew Morton
If you think that shortening the release cycle will cause people to be more
disciplined in their changes, to spend less time going berzerk and to spend
more time working with our users and testers on known bugs then I'm all
ears.
A suggestion from the department of evil ideas: Call even cycles
development odd ones stabilizing. Nothing gets into an odd one without a
review and linux-kernel signoff/ack ?

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jan Engelhardt
2006-09-21 10:58:35 UTC
Permalink
Post by Alan Cox
Post by Andrew Morton
If you think that shortening the release cycle will cause people to be more
disciplined in their changes, to spend less time going berzerk and to spend
more time working with our users and testers on known bugs then I'm all
ears.
A suggestion from the department of evil ideas: Call even cycles
development odd ones stabilizing. Nothing gets into an odd one without a
review and linux-kernel signoff/ack ?
Why, just open 2.7.0. Harhar!


Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Torvalds
2006-09-21 15:27:07 UTC
Permalink
Post by Alan Cox
A suggestion from the department of evil ideas: Call even cycles
development odd ones stabilizing. Nothing gets into an odd one without a
review and linux-kernel signoff/ack ?
I don't think that's an evil idea, and in fact we've discussed it before.
I personally like it - right now we tend to have that "interminable series
of -rc<n>" (where <n> is 3..) before release, and I'd almost personally
prefer to just have a rule that is more along the lines of

- 2.6.<odd> is "the big initial merges with all the obvious fixes to make
it all work" (ie roughly the current -rc2 or perhaps -rc3).

- 2.6.<even> is "no big merges, just careful fixes" (ie the current "real
release")

Each would be ~3 weeks, leaving us with effectively the same real release
schedule, just a naming change.

That said, I think Andrew was of the opinion that it doesn't really _fix_
anything, and he may well be right. What's the point of the odd release,
if the weekly snapshots after that are supposed to be strictly better than
it anyway?

So I think I may like it just because it _seems_ to combine the good
features of both the old naming scheme and the current one, but I suspect
Andrew may be right in that it doesn't _really_ change anything, deep
down.

Dunno.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jan Engelhardt
2006-09-21 15:55:21 UTC
Permalink
Post by Linus Torvalds
- 2.6.<odd> is "the big initial merges with all the obvious fixes to make
it all work" (ie roughly the current -rc2 or perhaps -rc3).
- 2.6.<even> is "no big merges, just careful fixes" (ie the current "real
release")
That sounds interesting. To me this looks like a careful approach at
more or less marking a release "this contains new stuff" and "this does
not", like 2.<odd>.x and 2.<even>.x, respectively, but of course without
the code divergence that happened between 2.4 and 2.5.

Will there be a -stable branch for 2.6.<odd>s, or will they be limited
to 2.6.<even>, just like there is no -stable for -rcs?
Post by Linus Torvalds
Each would be ~3 weeks, leaving us with effectively the same real release
schedule, just a naming change.
More or less, yes. Let's assume a "good release" (one with a fair number
of -rcs), and compare both approches (hope your MUA does tabs=8):

Week/Current Current style Week/Proposal Your proposal
+0 2.6.18 +0 2.6.18
+2 2.6.19-rc1 - none
+3 2.6.19-rc2 +3 2.6.19
+4 2.6.19-rc3 - none
+5 2.6.19 +6 2.6.20
+7 2.6.20-rc1 - none
+8 2.6.20-rc2 +9 2.6.21
+9 2.6.20-rc3 - none
+10 2.6.21 +12 2.6.22
(+1 between each -rc is purely assumptional)

Though this is a purely dry mathematical table. We did not always stick
to a "-rc3 at most" rule, but gone up to like -rc7 recently. With the
new versioning scheme, no such thing seems likely to be happening
(excluding of course external influences like people travelling).
IOW, the schedule gets more organized. I like that idea.

(Based upon the assumption that 1 week passes between each -rc
release, there would, with the new proposal, 'only' be 243 weeks to hit
2.6.99 instead of 405. That is, version numbers go up faster :)



Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-21 18:00:41 UTC
Permalink
On Thu, 21 Sep 2006 08:25:55 -0700 (PDT)
Post by Linus Torvalds
Post by Alan Cox
A suggestion from the department of evil ideas: Call even cycles
development odd ones stabilizing. Nothing gets into an odd one without a
review and linux-kernel signoff/ack ?
I don't think that's an evil idea, and in fact we've discussed it before.
I personally like it - right now we tend to have that "interminable series
of -rc<n>" (where <n> is 3..) before release, and I'd almost personally
prefer to just have a rule that is more along the lines of
- 2.6.<odd> is "the big initial merges with all the obvious fixes to make
it all work" (ie roughly the current -rc2 or perhaps -rc3).
- 2.6.<even> is "no big merges, just careful fixes" (ie the current "real
release")
Each would be ~3 weeks, leaving us with effectively the same real release
schedule, just a naming change.
That said, I think Andrew was of the opinion that it doesn't really _fix_
anything, and he may well be right. What's the point of the odd release,
if the weekly snapshots after that are supposed to be strictly better than
it anyway?
So I think I may like it just because it _seems_ to combine the good
features of both the old naming scheme and the current one, but I suspect
Andrew may be right in that it doesn't _really_ change anything, deep
down.
Again, before we can implement anything we should describe what problem we are
actually trying to solve here.

Jeff: "I want faster release cycles because <no reason given>"

Me: "I want less bugs"

Anyone else?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-21 18:20:54 UTC
Permalink
Post by Andrew Morton
Jeff: "I want faster release cycles because <no reason given>"
All the standard goodness that "release early, release often" provides.

* Avoiding the achingly long wait where huge amounts of changes pile up,
then go in. It should be OBVIOUS that
merge 10,000 changes. global test. repeat
is worse than
merge 1,000 changes. global test. repeat.

I think it's patently unfair to complain about bugs and regressions,
then limit developers to 3-4 test points [mainline releases] per year.

* Faster release cycles means code doesn't spend a quarter of the year
in limbo before users test it and give good feedback.

* Code stands a better chance of getting more review.

* Regressions are perceived to be fixed more quickly, if the fix
requires more than just 1-2 lines going to ***@kernel.org.

* Submitters don't have to wait for a quarter of a year in order for
their submissions to hit a mainline release.

With this last release, I just didn't see the value at all to going all
the way to -rc7. There weren't huge numbers of testers screaming about
-rc1 and -rc2. It just seemed like we delayed for no good reason other
than a blind hope that the passage of time would fix bugs.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Torvalds
2006-09-21 18:23:21 UTC
Permalink
Post by Andrew Morton
Again, before we can implement anything we should describe what problem we are
actually trying to solve here.
Jeff: "I want faster release cycles because <no reason given>"
Me: "I want less bugs"
Anyone else?
Me: "I want peoples expectations to line up".

(That, btw, is totally independent of this particulay issue - I just like
people to know what to expect..)

One of the things that I think the current model has excelled at is how it
really changed peoples behaviour, simply because they knew and understood
the rules.

I think the "big merges in the first two weeks, and a -rc1 after, and no
new code after that" rule has been working because it brought everybody in
on the same page.

I actually expected people to dislike arbitrary rules more than they do,
but I've come to believe that people _like_ having rules that they have to
obey, as long as it's not a big pain for them. In other words, arbitrary
rules are not actually disliked at all, people actually _like_ them,
because suddenly there's less need for making unnecessary judgement
decisions.

As an example: I thought I'd get a lot of back-lash on the whole sign-off
procedure. Instead, we're basically signing off everything, and having a
few simple rules ended up making it just easier to forward stuff, and we
haven't had any of the discussions about who gets to be attributed as an
author since the sign-off was introduced. That was a totally unexpected
bonus, as far as I was concerned.

The same goes for my anal efforts at trying to make people use a specific
format for sending patches, and sending the "please pull" messages. I'm
not hearing any grumbling about it at all, and in fact I'm getting the
distinct feeling that people like knowing exactly what format to use,
because they didn't really care themselves, and it turns out that having
any rule - even if it's fairly arbitrary - seems to be better than not
having a rule at all.

So I think that a "odd release"/"even release" rule that clarifies what a
certain mid-point in the release cycle actually _means_, even if it
doesn't necessarily add anything else, might be a good thing. It just
solidifies peoples expectations about where we are in a release cycle.

If we make an arbitrary rule to go with the release cycle ("leading up to
the even cycle, you need to get an ack from somebody that actually tested
the fix") that could actually be a good thing, for this reason.

I dunno. Maybe the only arbitrary rule ends up being that an "odd release"
would become a good place for people to try, knowing that we expect bug
reports from them. Right now -rc1 might be _too_ scary, even if it ends up
being exactly that: the only difference is really not about technology,
but about what peoples expectations are.

If we could instill a culture of "if you aren't a developer, but you just
want to help out, try the odd releases", that in itself might be worth the
naming change. If it would allow a group of people who might not feel
comfortable about reporting problems with a "-rc" to feel like they are
_expected_ to report a problem with an odd release, then that would be a
good thing, no?

I'm just throwing this out as an idea. I'm not going to really argue very
strongly for it. It might have horrible downsides too, for all I know, and
we might get people who didn't get the memo on "even vs odd releases"
being really unhappy about somethign they perceive to be a buggy release.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-21 18:34:09 UTC
Permalink
Post by Linus Torvalds
One of the things that I think the current model has excelled at is how it
really changed peoples behaviour, simply because they knew and understood
the rules.
I think the "big merges in the first two weeks, and a -rc1 after, and no
new code after that" rule has been working because it brought everybody in
on the same page.
I definitely agree with all that.

I simply argue that, the more time that passes between releases, the
MORE BUGS that appear in the next release.

After -rc1, you reach a point of diminishing returns where users don't
re-test Release Candidates, developers move on to new code rather than
fix bugs, and we all move into a limbo where 2.6.X-rcY doesn't see much
activity, but the huge "merge snowball" in -mm builds and builds and builds.

As an aside, if a release is getting held up by some key bugs or
regressions, I think it's more than fair for Andrew to loudly shame said
developers into action. "The following nincompoops are holding up the
release: Jeff Garzik [bug #1222, #3391], Greg KH [bug #9987, #4418], ..."

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-21 18:56:33 UTC
Permalink
On Thu, 21 Sep 2006 14:33:41 -0400
Post by Jeff Garzik
I think it's more than fair for Andrew to loudly shame said
developers into action. "The following nincompoops are holding up the
release: Jeff Garzik [bug #1222, #3391], Greg KH [bug #9987, #4418], ..."
I don't have the bandwidth to do that work, alas. I know how to do it, and
have tried to do it, but a) it's dull and b) even I get tired of whining at
people all the time.

The good news is that google is prepared to hire someone to sit next to me
and do it, but I haven't got off my ass and written the job description
yet.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Adrian Bunk
2006-09-21 19:46:37 UTC
Permalink
Post by Jeff Garzik
Post by Linus Torvalds
One of the things that I think the current model has excelled at is how it
really changed peoples behaviour, simply because they knew and understood
the rules.
I think the "big merges in the first two weeks, and a -rc1 after, and no
new code after that" rule has been working because it brought everybody in
on the same page.
I definitely agree with all that.
I simply argue that, the more time that passes between releases, the
MORE BUGS that appear in the next release.
After -rc1, you reach a point of diminishing returns where users don't
re-test Release Candidates, developers move on to new code rather than
fix bugs, and we all move into a limbo where 2.6.X-rcY doesn't see much
activity, but the huge "merge snowball" in -mm builds and builds and builds.
This "there is not enough testing by users" is simply not true:

Even the kernel Bugzilla that contains only a small subset of all bug
reports contains 78 (sic) open bugs reported against 2.6.18-rc kernels [1].

Not all of them are regressions, but this shows that users are testing
-rc kernels and reporting bugs.
Post by Jeff Garzik
As an aside, if a release is getting held up by some key bugs or
regressions, I think it's more than fair for Andrew to loudly shame said
developers into action. "The following nincompoops are holding up the
release: Jeff Garzik [bug #1222, #3391], Greg KH [bug #9987, #4418], ..."
Jeff
cu
Adrian

[1] including bugs reported against 2.6.18-rc?-mm? and 2.6.18-rc?-git*
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Diego Calleja
2006-09-21 20:37:41 UTC
Permalink
El Thu, 21 Sep 2006 21:46:04 +0200,
Post by Adrian Bunk
Even the kernel Bugzilla that contains only a small subset of all bug
reports contains 78 (sic) open bugs reported against 2.6.18-rc kernels [1].
I suspect that not many people is subscribed to the bugzilla mailing list,
not surprising since the URLs doesn't seem to be in the tree :)

After fixing my english, I wonder if the following patch could be applied...

Signed-off-by: Diego Calleja <***@gmail.com>

--- 2.6/Documentation/HOWTO.OLD 2006-09-21 22:14:06.000000000 +0200
+++ 2.6/Documentation/HOWTO 2006-09-21 22:36:17.000000000 +0200
@@ -374,6 +374,26 @@ of information is needed by the kernel d
problem.


+Managing bug reports
+--------------------
+
+One of the best ways to put into practice your hacking skills is by fixing
+bugs reported by other people. Not only you will help to make the kernel
+more stable, you'll learn to fix real world problems and you will improve
+your skills, and other developers will be aware of your presence. Fixing
+bugs is one of the best ways to get merits between other developers, because
+not many people like wasting time fixing other people's bugs.
+
+To work in the already reported bug reports, go to http://bugzilla.kernel.org.
+If you want to be advised of the future bug reports, you can subscribe to the
+bugme-new mailing list (only new bug reports are mailed here) or to the
+bugme-janitor mailing list (every change in the bugzilla is mailed here)
+
+ http://lists.osdl.org/mailman/listinfo/bugme-new
+ http://lists.osdl.org/mailman/listinfo/bugme-janitors
+
+
+
Mailing lists
-------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Randy.Dunlap
2006-09-21 21:35:00 UTC
Permalink
Post by Diego Calleja
El Thu, 21 Sep 2006 21:46:04 +0200,
Post by Adrian Bunk
Even the kernel Bugzilla that contains only a small subset of all bug
reports contains 78 (sic) open bugs reported against 2.6.18-rc kernels [1].
I suspect that not many people is subscribed to the bugzilla mailing list,
not surprising since the URLs doesn't seem to be in the tree :)
After fixing my english, I wonder if the following patch could be applied...
--- 2.6/Documentation/HOWTO.OLD 2006-09-21 22:14:06.000000000 +0200
+++ 2.6/Documentation/HOWTO 2006-09-21 22:36:17.000000000 +0200
@@ -374,6 +374,26 @@ of information is needed by the kernel d
problem.
+Managing bug reports
+--------------------
+
+One of the best ways to put into practice your hacking skills is by fixing
+bugs reported by other people. Not only you will help to make the kernel
+more stable, you'll learn to fix real world problems and you will improve
+your skills, and other developers will be aware of your presence. Fixing
+bugs is one of the best ways to get merits between other developers, because
s/between/among/ :)
Post by Diego Calleja
+not many people like wasting time fixing other people's bugs.
+
+To work in the already reported bug reports, go to http://bugzilla.kernel.org.
+If you want to be advised of the future bug reports, you can subscribe to the
+bugme-new mailing list (only new bug reports are mailed here) or to the
+bugme-janitor mailing list (every change in the bugzilla is mailed here)
+
+ http://lists.osdl.org/mailman/listinfo/bugme-new
+ http://lists.osdl.org/mailman/listinfo/bugme-janitors
+
+
+
Mailing lists
-------------
-
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-21 20:38:51 UTC
Permalink
Post by Adrian Bunk
Not all of them are regressions, but this shows that users are testing
-rc kernels and reporting bugs.
I never claimed otherwise. But every release turns up plenty of bugs
that are otherwise uncaught, because its inevitable that a much larger
set of users tests the full releases.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Adrian Bunk
2006-09-21 20:50:01 UTC
Permalink
Post by Jeff Garzik
Post by Adrian Bunk
Not all of them are regressions, but this shows that users are testing
-rc kernels and reporting bugs.
I never claimed otherwise. But every release turns up plenty of bugs
that are otherwise uncaught, because its inevitable that a much larger
set of users tests the full releases.
My point is that we don't lack testers and bug reports - we lack people
fixing bugs.
Post by Jeff Garzik
Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Bill Davidsen
2006-09-21 21:29:53 UTC
Permalink
Post by Linus Torvalds
Post by Andrew Morton
Again, before we can implement anything we should describe what problem we are
actually trying to solve here.
Jeff: "I want faster release cycles because <no reason given>"
Me: "I want less bugs"
Anyone else?
Me: "I want peoples expectations to line up".
(That, btw, is totally independent of this particulay issue - I just like
people to know what to expect..)
One of the things that I think the current model has excelled at is how it
really changed peoples behaviour, simply because they knew and understood
the rules.
I think the "big merges in the first two weeks, and a -rc1 after, and no
new code after that" rule has been working because it brought everybody in
on the same page.
I actually expected people to dislike arbitrary rules more than they do,
but I've come to believe that people _like_ having rules that they have to
obey, as long as it's not a big pain for them. In other words, arbitrary
rules are not actually disliked at all, people actually _like_ them,
because suddenly there's less need for making unnecessary judgement
decisions.
As an example: I thought I'd get a lot of back-lash on the whole sign-off
procedure. Instead, we're basically signing off everything, and having a
few simple rules ended up making it just easier to forward stuff, and we
haven't had any of the discussions about who gets to be attributed as an
author since the sign-off was introduced. That was a totally unexpected
bonus, as far as I was concerned.
The same goes for my anal efforts at trying to make people use a specific
format for sending patches, and sending the "please pull" messages. I'm
not hearing any grumbling about it at all, and in fact I'm getting the
distinct feeling that people like knowing exactly what format to use,
because they didn't really care themselves, and it turns out that having
any rule - even if it's fairly arbitrary - seems to be better than not
having a rule at all.
So I think that a "odd release"/"even release" rule that clarifies what a
certain mid-point in the release cycle actually _means_, even if it
doesn't necessarily add anything else, might be a good thing. It just
solidifies peoples expectations about where we are in a release cycle.
If we make an arbitrary rule to go with the release cycle ("leading up to
the even cycle, you need to get an ack from somebody that actually tested
the fix") that could actually be a good thing, for this reason.
I dunno. Maybe the only arbitrary rule ends up being that an "odd release"
would become a good place for people to try, knowing that we expect bug
reports from them. Right now -rc1 might be _too_ scary, even if it ends up
being exactly that: the only difference is really not about technology,
but about what peoples expectations are.
If we could instill a culture of "if you aren't a developer, but you just
want to help out, try the odd releases", that in itself might be worth the
naming change. If it would allow a group of people who might not feel
comfortable about reporting problems with a "-rc" to feel like they are
_expected_ to report a problem with an odd release, then that would be a
good thing, no?
I'm just throwing this out as an idea. I'm not going to really argue very
strongly for it. It might have horrible downsides too, for all I know, and
we might get people who didn't get the memo on "even vs odd releases"
being really unhappy about somethign they perceive to be a buggy release.
Linus
I think it would help if you went back to using meaningful names for
releases, because 2.6.19-test1 is pretty clearly a test release even to
people who can't figure out if a number is odd or even. Then after
people stop reporting show stoppers, change to rc numbers, where rc
versions are actually candidates for release without known major bugs.

Test and rc have pretty clear meanings, anyone who puts a test release
on a production machine can't complain they didn't know, and people who
want to wait for the "should not eat your data" stage will be more
willing to try a release.

Automating testing: someone could write a simple web form to report test
results (like sign off, sort of). CPU, distribution, network, display,
filesystems used, that sort of thing. So I say FC4, Radeon-x, HT on X86,
multiple GigE, port blocking and forwarding, SNAT, TV bttv, DVD burn,
smbfs, ext3. When N people have reported no issues with a feature, you
consider it tested. If no one tests something like UML, cryptoloop, nbd,
Reiser4, or UFS, then you poke the list to try stuff. Or when a change
goes in, mark it "needs testing" on some web site. In other words
improve developer <=> tester communication without using a lot of
someone's time.

I know we have a test tracking system, but I don't see "testers needed"
messages on the list, and I'm not sure you get or use feedback from any
test tracking to identify untested features in kernels.
--
Bill Davidsen <***@tmr.com>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-21 21:34:23 UTC
Permalink
Post by Bill Davidsen
I think it would help if you went back to using meaningful names for
releases, because 2.6.19-test1 is pretty clearly a test release even to
people who can't figure out if a number is odd or even. Then after
people stop reporting show stoppers, change to rc numbers, where rc
versions are actually candidates for release without known major bugs.
Actually, considering our group of developers, I think "-rc" has been
remarkably successful at staying on the "bug fixes only" theme.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
2006-09-21 21:52:22 UTC
Permalink
From: Jeff Garzik <***@garzik.org>
Date: Thu, 21 Sep 2006 17:33:27 -0400
Post by Jeff Garzik
Post by Bill Davidsen
I think it would help if you went back to using meaningful names for
releases, because 2.6.19-test1 is pretty clearly a test release even to
people who can't figure out if a number is odd or even. Then after
people stop reporting show stoppers, change to rc numbers, where rc
versions are actually candidates for release without known major bugs.
Actually, considering our group of developers, I think "-rc" has been
remarkably successful at staying on the "bug fixes only" theme.
I agree.

But even on that note I would love to have a release cycle where I
didn't merge any new features and could work entirely on the bugs
that never get worked on.

Sure, I'll still be merging new features into my "N + 1" tree.
But my pure interactions with Linus's tree can focus entirely
on bug fixing, and I really want an environment in which to
concentrate on that exclusively.

I think the even/odd idea is great, personally. And if this
makes some people have to wait a little bit longer for their
favorite feature to get merged, that's tough. :-)

I truly think we need to move towards a more stability minded
mode and back off on the new features just a bit.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Jones
2006-09-21 22:08:38 UTC
Permalink
Post by David Miller
But even on that note I would love to have a release cycle where I
didn't merge any new features and could work entirely on the bugs
that never get worked on.
Would certainly be nice, even if we didn't do it every-other, but
once every half dozen or so releases. I've been looking over the
osdl bugzilla recently (Ironically in a form of escapism from
the Fedora bugzilla). There's a ton of really old reports in there
that could be mopped up with a targetted bugfixing release.
Right now, with so many open bugs, it's difficult to get a real
picture of where the problem areas are because there's so much
crap in there. (Fedora's bugzilla is actually going through the
same problem right now too sadly, at least in part because
the last few releases have taken so damned long to come out, and
the -stable releases whilst an improvement, haven't gone far
enough to fixing a lot of issues users are seeing[*]).
Post by David Miller
Sure, I'll still be merging new features into my "N + 1" tree.
But my pure interactions with Linus's tree can focus entirely
on bug fixing, and I really want an environment in which to
concentrate on that exclusively.
There's nothing actually stopping you from enforcing this rule
in the trees you maintain though. You could do this for networking
in .19 without having a mandate from Linus that the kernel as
a whole is going to do the same.

Not that networking is an area that sees that many regressions
compared to other subsystems IMO. What's your secret? :)
Post by David Miller
I think the even/odd idea is great, personally. And if this
makes some people have to wait a little bit longer for their
favorite feature to get merged, that's tough. :-)
My concern is that people will 'sit out' the even stage, and
just accumulate stuff in a single tree they dump once when
every odd release opens up.

We already have some subsystems that do once-per-release merges,
and then let fixes build up in their out-of-tree SCM for months
until the next window. It won't necessarily get worse, but unless
everyone is participating in the odd/even rules, we won't get
the benefits that it would offer.

Dave

[*] I'm not demeaning Greg & Chris' work here at all, they've
been doing a stellar job, but I think we could use more people
going through the changelogs looking for stuff that needs
backporting.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
2006-09-21 22:44:32 UTC
Permalink
From: Dave Jones <***@redhat.com>
Date: Thu, 21 Sep 2006 18:05:39 -0400
Post by Dave Jones
Post by David Miller
I think the even/odd idea is great, personally. And if this
makes some people have to wait a little bit longer for their
favorite feature to get merged, that's tough. :-)
My concern is that people will 'sit out' the even stage, and
just accumulate stuff in a single tree they dump once when
every odd release opens up.
At least they would be dumping on top of "mostly working".
I kind of like that. It breeds more confidence into the
tree having been working before the dump took place, thus
making the isolation of cause much easier.
Post by Dave Jones
We already have some subsystems that do once-per-release merges,
and then let fixes build up in their out-of-tree SCM for months
until the next window. It won't necessarily get worse, but unless
everyone is participating in the odd/even rules, we won't get
the benefits that it would offer.
Having odd/even rules kind of adds legitimacy to the per-tree folks
doing the same. This avoids situations like "why is XXX being an
asshole with his tree, when there are other trees merging new
features this round?". Having buy-in from everyone is very useful
and gets folks in the correct mindset.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Russell King
2006-09-22 08:36:20 UTC
Permalink
Post by Dave Jones
We already have some subsystems that do once-per-release merges,
and then let fixes build up in their out-of-tree SCM for months
until the next window. It won't necessarily get worse, but unless
everyone is participating in the odd/even rules, we won't get
the benefits that it would offer.
I'm heading in that direction (once-per-release merges) actually.

On one hand, I'm credited with the ARM architecture being one of the
best maintained embedded architectures in the kernel tree. On the
other hand, that appears to be winding Linus up due to the regular
merge requests, which were happening maybe once or twice a week.

Linus seems to be of the opinion that, if anyone can't wait a number
of months for their patch to get into mainline, then they shouldn't
be involved in this game. The content of the tree which that comment
was made at contained (imho) just bug fixes.

At the moment, we're up to 528kB (initial commit Aug 21st) of IOP3xx
and S3C24xx machine updates, and various other developments. As for
the other trees, MMC (9kB since Aug 27) and serial (20kB since Aug 30)
but neither have been looked at for a while, certainly not post 2.6.18.
I'm not even responding to mail about these because I haven't been even
thinking about them yet.

As far as -mm getting these, I have asked Andrew to pull this tree in
the past, but whenever I rebase the trees (eg, when 2.6.18 comes out)
and fix up the rejects, Andrew seems to have a hard time coping. I
guess Andrew finds it too difficult to handle my devel branches.

Where I go from here I'm not sure - I'm running out of ideas for
correct "Care and Operation of (my) Linus Torvalds", except becoming
one of the Bad People who only merge _lots_ of changes once in a blue
moon.

So, what I'm going to be doing this cycle is essentially sitting on
stuff for quite some time and not really caring about where in the
release cycle mainline actually is. (Anyone remember Linus moaning
at various people for doing exactly this? Eg, ALSA people?) It
pains me to do this because it's obviously not the _correct_ thing
to do, but I don't see any other way of keeping Linus happy. And this
does mean giving up all hope of getting anything in mainline.

As far as my future, I will be handing MMC off to Pierre Ossman during
this cycle (there are other reasons for doing this which Pierre has been
aware of for some time.)

I'll also be dropping my serial tree entirely - I have no idea who could
stand in for serial, so there's going to be no real "hand over" for that.
I do have some outstanding in-progress changes which aren't really ready,
but those will probably end up in /dev/null (in much the same way that my
in-progress changes for PCMCIA ended up in a similar place when I handed
that tree over.)

So, it's going to mean that the only thing I'm going to be caring about
post-2.6.19 is ARM again.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Jones
2006-09-22 15:49:22 UTC
Permalink
Post by Russell King
Post by Dave Jones
We already have some subsystems that do once-per-release merges,
and then let fixes build up in their out-of-tree SCM for months
until the next window. It won't necessarily get worse, but unless
everyone is participating in the odd/even rules, we won't get
the benefits that it would offer.
I'm heading in that direction (once-per-release merges) actually.
On one hand, I'm credited with the ARM architecture being one of the
best maintained embedded architectures in the kernel tree. On the
other hand, that appears to be winding Linus up due to the regular
merge requests, which were happening maybe once or twice a week.
Hmm. Some trees do seem to get pulled more often than others.
Linus, is there a upper limit on the number of times you want
to see pull requests? It strikes me as odd, so I'm wondering
if there are some crossed wires here.
Post by Russell King
As far as -mm getting these, I have asked Andrew to pull this tree in
the past, but whenever I rebase the trees (eg, when 2.6.18 comes out)
and fix up the rejects, Andrew seems to have a hard time coping. I
guess Andrew finds it too difficult to handle my devel branches.
Has Andrew commented on why this is proving to be more of a problem?
I've done regular rebases of cpufreq/agpgart (admittedly, they don't
reject hardly ever unless Len has ACPI bits touching cpufreq) without
causing too much headache.
Post by Russell King
So, what I'm going to be doing this cycle is essentially sitting on
stuff for quite some time and not really caring about where in the
release cycle mainline actually is.
That doesn't sound like the right way to fix the 'caring for my Linus' problem :)
Post by Russell King
As far as my future, I will be handing MMC off to Pierre Ossman during
this cycle (there are other reasons for doing this which Pierre has been
aware of for some time.)
I'll also be dropping my serial tree entirely - I have no idea who could
stand in for serial, so there's going to be no real "hand over" for that.
I do have some outstanding in-progress changes which aren't really ready,
but those will probably end up in /dev/null (in much the same way that my
in-progress changes for PCMCIA ended up in a similar place when I handed
that tree over.)
That's unfortunate. If you want someone to scoop bits up and feed Linus,
I'm happy to volunteer for the task, as long as you're still willing
to eyeball serial diffs until I get up to speed.

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2006-09-22 16:01:33 UTC
Permalink
Post by Dave Jones
That's unfortunate. If you want someone to scoop bits up and feed Linus,
I'm happy to volunteer for the task, as long as you're still willing
to eyeball serial diffs until I get up to speed.
I'll give you a hand with that, I've got to do some work in that area
anyway for the arbitary speed support.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Jones
2006-09-22 16:09:46 UTC
Permalink
Post by Alan Cox
Post by Dave Jones
That's unfortunate. If you want someone to scoop bits up and feed Linus,
I'm happy to volunteer for the task, as long as you're still willing
to eyeball serial diffs until I get up to speed.
I'll give you a hand with that, I've got to do some work in that area
anyway for the arbitary speed support.
Cool, sounds good to me. Russell?

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Torvalds
2006-09-22 16:25:23 UTC
Permalink
Post by Dave Jones
Hmm. Some trees do seem to get pulled more often than others.
Linus, is there a upper limit on the number of times you want
to see pull requests? It strikes me as odd, so I'm wondering
if there are some crossed wires here.
I personally prefer to not see _too_ many pull requests, since that to me
indicates that people don't take advantage of the distributed nature of
git, and don't let things "simmer" in their own tree for a while.

[ Side note, just to explain how I personally work: getting too many
requests about the same tree confuses and sometimes irritates me, since
I tend to "batch up" my work. For example, for the last couple of days,
I've been mostly in "discussion mode", and have been talking about
licenses and workflow issues etc.

And then at some point (probably later today) I decide to go into "merge
mode" and go back to old mails I ignored and start applying them and
pulling from other peoples git trees. And so if my "mode switching" has
a longer latency than the "please pull" frequency, I end up seeing two
requests for the same tree during the same "merge mode" thing, which
just means that when I look at the older one, it no longer matches what
is in the tree I'm pulling from.

I've long done this "batching" thing - it's something I eventually
worked out with my patch-flow with Alan, and that I think we've
perfected with Andrew (probably largely _because_ we worked it out with
Alan after a certain amount of friction ;).

I personally at least _feel_ like I'm more efficient when I can just
completely switch gears, rather than having a constant trickle of
different things happening.

Hopefully that explains the other side of why I prefer to not get two
pull requests for the same tree within days of each other - I may simply
not even have gotten _around_ to the first one yet, and then the second
one just irritates me. ]

For example, I think that project maintainers should to some degree just
talk about their _own_ trees, rather than try to get their changes into my
tree, and then point to that. One of the big ideas in distribution (at
least to me) is that I'm _not_ supposed to be the "one and only", and I
think we should aim for a situation where people who develop in certain
specific areas can interact directly with the people who are testing the
results, so that by the time I get a "please pull" request, most of the
bulk of the work should hopefully already have gone through a cycle.

And all this is not even really git-centric. It's obviously what Andrew
does with the -mm tree too - havign a certain amount of "latency" is good.

That said, the "release early, release often" thing still holds, and
letting things wait _too_ long just means that the _only_ people who test
it is some very specific group, and you may not see the problems that a
bigger environment would see.

So it's a balance between "by the time you send it on, it should hopefully
have had a day or two of testing" _and_ a "by the time you send it on you
shouldn't have forgotten the issues and think it's old and all done".

I would _personally_ judge that if you need to push me the same tree more
than once a week (not counting mistakes and brown-paper bugs that
obviously happen - I'm saying "in general" here), there's likely something
strange going on.

But at the same time, please do keep in mind thatr it's partly just a
matter of taste, and it's also very much a matter of work habits (and
about how active the tree is). Some people tend to work in certain ways.

I think rmk keeps his git trees in a private location (and I think it's
because the kernel.org maintainers asked us to not mirror things out
publicly if we didn't need to), so I think part of the reason the ARM
trees get pushed out more actively is simply because Russell has used my
tree as a "distribution point".

I don't think that's necessarily great, and there's been some friction
over it ("people are waiting for this"), but it's not been a _huge_
problem either, so I just lump it in the "different people, different ways
to work" pile..

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Roland Dreier
2006-09-22 20:09:01 UTC
Permalink
Linus> And then at some point (probably later today) I decide to
Linus> go into "merge mode" and go back to old mails I ignored and
Linus> start applying them and pulling from other peoples git
Linus> trees. And so if my "mode switching" has a longer latency
Linus> than the "please pull" frequency, I end up seeing two
Linus> requests for the same tree during the same "merge mode"
Linus> thing, which just means that when I look at the older one,
Linus> it no longer matches what is in the tree I'm pulling from.

My way of handling this has been to wait until you've acted on my
first merge request before sending another one. I also don't touch my
published "for-linus" branch in git until you've pulled it. I just
batch up pending changes in my "for-2.6.19" branch until my next merge
(and I also encourage people interested in Infiniband to run my
for-2.6.19 branch)

If I do see you merging other trees (in "merge mode") and skipping my
merge requests, I'll send a gentle reminder of my first merge request.

- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-22 20:23:19 UTC
Permalink
Post by Roland Dreier
My way of handling this has been to wait until you've acted on my
first merge request before sending another one. I also don't touch my
published "for-linus" branch in git until you've pulled it. I just
batch up pending changes in my "for-2.6.19" branch until my next merge
(and I also encourage people interested in Infiniband to run my
for-2.6.19 branch)
That's pretty much what I do. I run a
git branch upstream-linus upstream

and then submit a pull request for the upstream-linus branch. That way,
I can keep working and committing stuff, and don't have to wait for
Linus to pull.

Then, after the pull, I delete the branch
git branch -D upstream-linus

locally, and repeat the process next time a bunch of changes are queued up.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-22 16:30:07 UTC
Permalink
NOTE: Your mailer generates bogus Mail-Followup-To headers, and you
snipped rmk from the To/CC.
Post by Dave Jones
Hmm. Some trees do seem to get pulled more often than others.
Linus, is there a upper limit on the number of times you want
to see pull requests? It strikes me as odd, so I'm wondering
if there are some crossed wires here.
Not speaking for Linus, but in general it seems like the more pull
requests you send (within reason), the more pulls that occur. Russell
and DaveM certainly seem to send frequent, successful pull requests.
Post by Dave Jones
Has Andrew commented on why this is proving to be more of a problem?
I've done regular rebases of cpufreq/agpgart (admittedly, they don't
reject hardly ever unless Len has ACPI bits touching cpufreq) without
causing too much headache.
Rebasing _inevitably_ causes more headaches than a simple tree update,
for any downstream consumer of your tree(s). It is best to avoid wanton
rebasing.

Think about it: if someone is pulling and merging your tree, all of a
sudden, without warning, the entire hash history is rewritten. So
rather than a Nice and Friendly minor update, the next time they pull
your stuff, the downstream user is forced to suffer through either (a) a
painful merge, or (b) back out your last tree (ugh!) and redo things
from scratch.

Rebasing might make a pretty history, but it is _not_ fun for random
consumers of your trees. It basically punishes people for following
your tree -- not something you want to do.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Jones
2006-09-22 17:10:40 UTC
Permalink
Post by Jeff Garzik
NOTE: Your mailer generates bogus Mail-Followup-To headers, and you
snipped rmk from the To/CC.
Hmm, curious. I'll file a bug.
Post by Jeff Garzik
Post by Dave Jones
Has Andrew commented on why this is proving to be more of a problem?
I've done regular rebases of cpufreq/agpgart (admittedly, they don't
reject hardly ever unless Len has ACPI bits touching cpufreq) without
causing too much headache.
Rebasing _inevitably_ causes more headaches than a simple tree update,
for any downstream consumer of your tree(s). It is best to avoid wanton
rebasing.
Sorry, terminology confusion. I rarely throw away a tree and start afresh,
I meant of course just updating to linus' latest. This may explain the
my lack of understanding over Russell's issues.

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Jones
2006-09-22 17:12:23 UTC
Permalink
Post by Jeff Garzik
NOTE: Your mailer generates bogus Mail-Followup-To headers, and you
snipped rmk from the To/CC.
Actually, my mailer just respected the Mail-Followup-To: that
rmk set in his mail that I replied to. Nothing to see here.

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
2006-09-22 18:27:29 UTC
Permalink
Post by Dave Jones
Post by Jeff Garzik
NOTE: Your mailer generates bogus Mail-Followup-To headers, and you
snipped rmk from the To/CC.
Actually, my mailer just respected the Mail-Followup-To: that
rmk set in his mail that I replied to. Nothing to see here.
Ah, I stand corrected. Hello, RMK. :)

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-22 18:28:22 UTC
Permalink
On Fri, 22 Sep 2006 11:48:16 -0400
Post by Dave Jones
Post by Russell King
As far as -mm getting these, I have asked Andrew to pull this tree in
the past, but whenever I rebase the trees (eg, when 2.6.18 comes out)
and fix up the rejects, Andrew seems to have a hard time coping. I
guess Andrew finds it too difficult to handle my devel branches.
Has Andrew commented on why this is proving to be more of a problem?
I don't recall any particular ARM problems, so I'm curious too. I'm
presently pulling git+ssh://master.kernel.org/home/rmk/linux-2.6-arm.git,
which is coming up empty.

OTOH, I doubt if anyone runtime tests -mm on arm.

OTOH^2, people do cross-compile.

OTOH^3, my attempts to build an arm cross-compiler haven't been very
successful. I do have a .config which compiles, but allmodconfig used to
die due to the compiler not understanding weird `-m' options. <tries it>.
OK, that got fixed, so without CONFIG_AUDIT, arm allmodconfig compiles. Am
happy.


<I maintain that it is in the interests of obscure-arch maintainers to help
others build cross-compilers for their arch..>

<how'd I fall off the cc?>

<looks at viro>

include/asm-generic/audit_dir_write.h:9: error: `__NR_mkdirat' undeclared here (not in a function)
include/asm-generic/audit_dir_write.h:9: error: initializer element is not constant
include/asm-generic/audit_dir_write.h:9: error: (near initialization for `dir_class[8]')
include/asm-generic/audit_dir_write.h:10: error: `__NR_mknodat' undeclared here (not in a function)
include/asm-generic/audit_dir_write.h:10: error: initializer element is not constant
include/asm-generic/audit_dir_write.h:10: error: (near initialization for `dir_class[9]')
include/asm-generic/audit_dir_write.h:11: error: `__NR_unlinkat' undeclared here (not in a function)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Bill Davidsen
2006-09-22 00:59:41 UTC
Permalink
Post by Jeff Garzik
Post by Bill Davidsen
I think it would help if you went back to using meaningful names for
releases, because 2.6.19-test1 is pretty clearly a test release even
to people who can't figure out if a number is odd or even. Then after
people stop reporting show stoppers, change to rc numbers, where rc
versions are actually candidates for release without known major bugs.
Actually, considering our group of developers, I think "-rc" has been
remarkably successful at staying on the "bug fixes only" theme.
Perhaps I misread what Linus said, the issue I was suggesting be
addressed was one of clarity to the testers, not the developers. The
releases identified as test would be for evaluation, while the ones
identified as rc would really be candidates with no "fix before next
version" bugs known. I would think that between test releases some bugs
could be fixed, but new features could be added. That would encourage
more active testing without overly slowing the development process.

Having used that for a long time for 2.2 and 2.4 I think there's quite a
track record of that nomenclature being clear to the users.
--
Bill Davidsen <***@tmr.com>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andi Kleen
2006-09-22 06:33:51 UTC
Permalink
Post by Andrew Morton
Jeff: "I want faster release cycles because <no reason given>"
I think i would also prefer somewhat faster cycles, simple to get
more regular full scale testing.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-23 08:12:00 UTC
Permalink
On Thu, 21 Sep 2006 00:22:26 -0400
Post by Jeff Garzik
Post by Andrew Morton
There are quite a lot of patches here which belong in subsystem trees.
I'll patchbomb the relevant maintainers soon. Could I pleeeeeze ask that
they either merge the patches or solidly nack them (with reasons)? Don't
just ignore it all and leave me hanging onto this stuff for ever. Thanks.
I know this is probably heresy, but what would happen if we didn't merge
all that stuff at once, and then committed to having a real 4-week cycle?
The cycles seem to be stretching out again, and I don't really think
it's worth it to hold up the entire kernel for every single piddly
little regression to get fixed. We'll _never_ be perfect, even if we
weren't slackers.
It's remarkable how one can wait for months for the next kernel release,
carefully lining up, testing and reviewing the patches for the next
release, then whoop! As soon as Linus cuts a new release all sorts of
hitherto unimagined stuff comes out of the woodwork and gets instaslammed
into mainline.

WARNING: "register_mtd_blktrans" [drivers/mtd/rfd_ftl.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/rfd_ftl.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/rfd_ftl.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/rfd_ftl.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/nftl.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/nftl.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/nftl.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/nftl.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/mtdblock_ro.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/mtdblock_ro.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/mtdblock_ro.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/mtdblock_ro.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/mtdblock.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/mtdblock.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/mtdblock.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/mtdblock.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/inftl.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/inftl.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/inftl.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/inftl.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/ftl.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/ftl.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/ftl.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/ftl.ko] undefined!

Please don't do this.

Quick review:

- search for "( " and " )", fix.

- Might want to do something about the 512-byte automatic variable in
get_valid_cis_sector()

- It's full of uint8_t drain bamage.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ingo Molnar
2006-09-21 13:23:34 UTC
Permalink
Post by Andrew Morton
ntp-move-all-the-ntp-related-code-to-ntpc.patch
ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
ntp-add-ntp_update_frequency.patch
ntp-add-ntp_update_frequency-fix.patch
ntp-add-time_adj-to-tick-length.patch
ntp-add-time_freq-to-tick-length.patch
ntp-prescale-time_offset.patch
ntp-add-time_adjust-to-tick-length.patch
ntp-remove-time_tolerance.patch
ntp-convert-time_freq-to-nsec-value.patch
ntp-convert-to-the-ntp4-reference-model.patch
ntp-cleanup-defines-and-comments.patch
kernel-time-ntpc-possible-cleanups.patch
kill-wall_jiffies.patch
Will merge.
would be nice to merge the -hrt queue that goes right ontop this queue.
Even if HIGH_RES_TIMERS is "default n" in the beginning. That gives us
high-res timers and dynticks which are both very important features to
certain classes of users/devices.

The current queue is at:

http://tglx.de/projects/hrtimers/2.6.18/

Hm?

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-21 17:35:43 UTC
Permalink
On Thu, 21 Sep 2006 15:14:33 +0200
Post by Ingo Molnar
Post by Andrew Morton
ntp-move-all-the-ntp-related-code-to-ntpc.patch
ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
ntp-add-ntp_update_frequency.patch
ntp-add-ntp_update_frequency-fix.patch
ntp-add-time_adj-to-tick-length.patch
ntp-add-time_freq-to-tick-length.patch
ntp-prescale-time_offset.patch
ntp-add-time_adjust-to-tick-length.patch
ntp-remove-time_tolerance.patch
ntp-convert-time_freq-to-nsec-value.patch
ntp-convert-to-the-ntp4-reference-model.patch
ntp-cleanup-defines-and-comments.patch
kernel-time-ntpc-possible-cleanups.patch
kill-wall_jiffies.patch
Will merge.
would be nice to merge the -hrt queue that goes right ontop this queue.
Even if HIGH_RES_TIMERS is "default n" in the beginning. That gives us
high-res timers and dynticks which are both very important features to
certain classes of users/devices.
http://tglx.de/projects/hrtimers/2.6.18/
I've never even looked at this work. Just add it to the pipeline I guess.
We can merge it once it passes review by Roman ;)

But the possible problems with the NTP patches which John has possibly
observed were news to me - it's not clear what the situation is there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
2006-09-22 18:53:52 UTC
Permalink
Hi!
Post by Ingo Molnar
Post by Andrew Morton
ntp-move-all-the-ntp-related-code-to-ntpc.patch
ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
ntp-add-ntp_update_frequency.patch
ntp-add-ntp_update_frequency-fix.patch
ntp-add-time_adj-to-tick-length.patch
ntp-add-time_freq-to-tick-length.patch
ntp-prescale-time_offset.patch
ntp-add-time_adjust-to-tick-length.patch
ntp-remove-time_tolerance.patch
ntp-convert-time_freq-to-nsec-value.patch
ntp-convert-to-the-ntp4-reference-model.patch
ntp-cleanup-defines-and-comments.patch
kernel-time-ntpc-possible-cleanups.patch
kill-wall_jiffies.patch
Will merge.
would be nice to merge the -hrt queue that goes right ontop this queue.
Even if HIGH_RES_TIMERS is "default n" in the beginning. That gives us
high-res timers and dynticks which are both very important features to
certain classes of users/devices.
dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on thinkpad
x60... and they were around for way too long. (When baseline is
hz=250, it is 0.5W from hz=1000 baseline). It would be cool to
finally merge them.

Pavel
--
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2006-09-22 19:10:07 UTC
Permalink
Post by Pavel Machek
Post by Ingo Molnar
would be nice to merge the -hrt queue that goes right ontop this
queue. Even if HIGH_RES_TIMERS is "default n" in the beginning. That
gives us high-res timers and dynticks which are both very important
features to certain classes of users/devices.
dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on
thinkpad x60... and they were around for way too long. (When baseline
is hz=250, it is 0.5W from hz=1000 baseline). It would be cool to
finally merge them.
note that this is a new implementation of dynticks though, not Con's
older stuff which you probably used, right? But it's fairly low-impact
(just a few lines ontop of hrtimers, here and there), ontop of the
long-existing -hrt queue.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Bill Rugolsky Jr.
2006-09-22 20:30:13 UTC
Permalink
Post by Ingo Molnar
Post by Pavel Machek
Post by Ingo Molnar
would be nice to merge the -hrt queue that goes right ontop this
queue. Even if HIGH_RES_TIMERS is "default n" in the beginning. That
gives us high-res timers and dynticks which are both very important
features to certain classes of users/devices.
dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on
thinkpad x60... and they were around for way too long. (When baseline
is hz=250, it is 0.5W from hz=1000 baseline). It would be cool to
finally merge them.
note that this is a new implementation of dynticks though, not Con's
older stuff which you probably used, right? But it's fairly low-impact
(just a few lines ontop of hrtimers, here and there), ontop of the
long-existing -hrt queue.
Just a data point, FWIW; I've made no systematic effort to find regressions.

We've been running Thomas's (pre-dynticks) 2.6.16-hrt patchset (and
HZ=1000) without issue as part of my standard kernel build on x86 and
x86_64 UP/SMP production hosts -- workstations, PostgreSQL (and other)
servers, and routers --- since I experienced latency/ntp problems with
an unpatched kernel using sata_nv on Tyan 2895 Nvidia CK804-chipset mobo
back in March 2006. I've also been running the (originally x86-only)
2.6.17-dynticks patch on a Tyan Athlon SMP workstation mobo, and occasionally
on my laptop, so far without issue.

I originally chose Thomas's -hrt variant of John Stultz's timekeeping
patchset because it had known-working x86_64 support ...

We're not doing anything exotic (such as audio, packet capture,
or serving thousands of connections) that might stress the timer or
clock system much, but the x86 routers have GigE traffic and the
x86_64 PostgreSQL servers are often heavily loaded.

Regards,

Bill Rugolsky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Jones
2006-09-22 20:13:57 UTC
Permalink
Post by Pavel Machek
Post by Ingo Molnar
would be nice to merge the -hrt queue that goes right ontop this queue.
Even if HIGH_RES_TIMERS is "default n" in the beginning. That gives us
high-res timers and dynticks which are both very important features to
certain classes of users/devices.
dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on thinkpad
x60... and they were around for way too long. (When baseline is
hz=250, it is 0.5W from hz=1000 baseline). It would be cool to
finally merge them.
I actually saw much bigger wins when I tested with an Athlon XP based compaq laptop
a year or so back. dynticks moved idle from being stuck at 21W to a sinusoidal
cycle in single watt increments between 22W->18W. It would never stay in the
lower ranges for long because of timers firing all the time.

See http://kernelslacker.livejournal.com/33637.html for details.

There is much interest right now in fixing up various bits of userspace
to not do braindead things with timers/polling. The gnome people
have recently come up with a timertop-esque hack (that goes a bit further)
for eg. See http://blogs.gnome.org/ryanl for details.
Arjan also recently did battle with a huge amount of really dumb userspace,
and dwmw2 has been tracking a bunch of these for OLPC:
https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=204948

Damn all these busy people making me feel inadequate :)

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Michael Hanselmann
2006-09-21 14:05:02 UTC
Permalink
Post by Andrew Morton
apple-motion-sensor-driver-2.patch
apple-motion-sensor-driver-2-fixes-update.patch
apple-motion-sensor-driver-kconfig-fix.patch
Please wait with those. We're currently trying to come up with a generic
class for all motion sensor drivers in the kernel. This will change the
userland interface again.

Thanks,
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-21 23:59:47 UTC
Permalink
On Fri, 22 Sep 2006 07:46:37 +0800
Post by Andrew Morton
The readahead code is complex, I'm unconvinced that it has a lot of benefit
and Wu has gone quiet. Will drop.
Sorry, I've been putting efforts to meet the deadline of the google
SoC project "Rapid linux desktop startup through pre-caching", which
still can not be called success for now. And there's my pending paper
work...
Oh, OK.

That's a neat thing to be working on.
I should be able to come back and concentrate on the readahead patch
after one month, whether it be dropped for now. I guess it can be
further improved in complexity and performance. It also needs a good
document for the overall design and benefits. And sure the
performance numbers :-)
I'll hang onto the patches then - they're causing little maintenance
trouble for me.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
l***@horizon.com
2006-09-22 02:02:15 UTC
Permalink
Post by Linus Torvalds
Post by Alan Cox
A suggestion from the department of evil ideas: Call even cycles
development odd ones stabilizing. Nothing gets into an odd one without a
review and linux-kernel signoff/ack ?
I don't think that's an evil idea, and in fact we've discussed it before.
I personally like it - right now we tend to have that "interminable series
of -rc<n>" (where <n> is 3..) before release, and I'd almost personally
prefer to just have a rule that is more along the lines of
- 2.6.<odd> is "the big initial merges with all the obvious fixes to make
it all work" (ie roughly the current -rc2 or perhaps -rc3).
- 2.6.<even> is "no big merges, just careful fixes" (ie the current "real
release")
Each would be ~3 weeks, leaving us with effectively the same real release
schedule, just a naming change.
That said, I think Andrew was of the opinion that it doesn't really _fix_
anything, and he may well be right. What's the point of the odd release,
if the weekly snapshots after that are supposed to be strictly better than
it anyway?
So I think I may like it just because it _seems_ to combine the good
features of both the old naming scheme and the current one, but I suspect
Andrew may be right in that it doesn't _really_ change anything, deep
down.
Not meaning to re-open old wounds, but this is exactly why people
complained about dropping the "-pre" kernels. That was a good way to
distinguish between "the features are in, but so are some obvious bugs;
read the changelog" and, in -rc, "this has no *known* bugs, so please
test and report".

If you want to just go back to that (2.6.<odd>-rcX would be -pre, and
2.6.<odd> would be -rc1), I don't think people would need it explained
to them. And the kernel.org mirror system already understands it.

Although, as you say, its not clear that any of this politically
correct renaming is actually changing anything.


If someone really wants to affect the bug count, figure out a way to
auto-generate a "bugs and regressions in mainline, by contributor" score
and publicize that. As the various distributed computing projects have
found, people can be competitive about the silliest things if you give
them a score to measure themselves by.

Since kudos would flow from the author of a bug to the finder as well
as the fixer, it could simultaneously encourage testers.

Quantifying all of this hand-waving is, of course, a non-trivial
project (how do you compare a printk spelling fix to a silent
IDE data corruption bug?), but it would be very worthwhile.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Woodhouse
2006-09-22 09:24:57 UTC
Permalink
Post by Andrew Morton
mtd-maps-ixp4xx-partition-parsing.patch
fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch
mtd-printk-format-warning.patch
fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
drivers-mtd-nand-au1550ndc-removal-of-old-code.patch
MTD queue -> dwmw2
Merged, with the exception of the unlock addr one which I'm still not
sure about -- about to investigate harder.

Also merged are
pci-mtd-switch-to-pci_get_device-and-do-ref-counting.patch and
avr32-mtd-unlock-flash-if-necessary.patch
--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Woodhouse
2006-09-22 10:11:13 UTC
Permalink
Post by David Woodhouse
Post by Andrew Morton
mtd-maps-ixp4xx-partition-parsing.patch
fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch
mtd-printk-format-warning.patch
fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
drivers-mtd-nand-au1550ndc-removal-of-old-code.patch
MTD queue -> dwmw2
Merged, with the exception of the unlock addr one which I'm still not
sure about -- about to investigate harder.
I just reverted Randy's printk format 'fix', since rq->flags _is_ an
unsigned long, so changing from %ld to %d actually _introduces_ a
warning.

Randy, that's the second time I recall recently that I've ended up
reverting a printk format fix from you -- what are you doing? How did
you manage to get the warning you reported:

drivers/mtd/mtd_blkdevs.c:72: warning: long int format, different type arg (arg 2)
--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jan Engelhardt
2006-09-22 10:46:29 UTC
Permalink
Post by David Woodhouse
Post by David Woodhouse
Post by Andrew Morton
mtd-maps-ixp4xx-partition-parsing.patch
fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch
mtd-printk-format-warning.patch
fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
drivers-mtd-nand-au1550ndc-removal-of-old-code.patch
MTD queue -> dwmw2
Merged, with the exception of the unlock addr one which I'm still not
sure about -- about to investigate harder.
I just reverted Randy's printk format 'fix', since rq->flags _is_ an
unsigned long, so changing from %ld to %d actually _introduces_ a
warning.
If it is an unsigned long, it should neither be %ld nor %d, but %lu.



Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Woodhouse
2006-09-22 11:21:51 UTC
Permalink
Post by Jan Engelhardt
If it is an unsigned long, it should neither be %ld nor %d, but %lu.
It'll never be negative.
--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Randy.Dunlap
2006-09-22 17:30:48 UTC
Permalink
Post by David Woodhouse
Post by David Woodhouse
Post by Andrew Morton
mtd-maps-ixp4xx-partition-parsing.patch
fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch
mtd-printk-format-warning.patch
fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
drivers-mtd-nand-au1550ndc-removal-of-old-code.patch
MTD queue -> dwmw2
Merged, with the exception of the unlock addr one which I'm still not
sure about -- about to investigate harder.
I just reverted Randy's printk format 'fix', since rq->flags _is_ an
unsigned long, so changing from %ld to %d actually _introduces_ a
warning.
Randy, that's the second time I recall recently that I've ended up
reverting a printk format fix from you -- what are you doing? How did
drivers/mtd/mtd_blkdevs.c:72: warning: long int format, different type arg (arg 2)
That was originally posted as a patch to -mm, where that field
has been changed to (unsigned?) int. Maybe it should be part
of Jens's block patches, since that is what changes the field
size.

---
~~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Haavard Skinnemoen
2006-09-22 12:34:00 UTC
Permalink
On Wed, 20 Sep 2006 13:54:38 -0700
Post by Andrew Morton
AVR32 architecture. Will fold into a single patch, and will merge.
Thanks a lot :-) I will do my best to ensure it stays in good shape
during the -rc series.
Post by Andrew Morton
avr32-mtd-static-memory-controller-driver-try-2.patch
avr32-mtd-at49bv6416-platform-device-for-atstk1000.patch
avr32-mtd-unlock-flash-if-necessary.patch
MTD changes for avr32. Will send to dwmw2.
It might actually make more sense to fold the first two into the avr32
architecture patch. Especially now that David has picked up the third
one (which ended up not being AVR32-specific at all.)

The static memory controller driver isn't really specific to MTD
anyway, it should be equally useful for all kinds of external
memory-mapped devices including CompactFlash.

Haavard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2006-09-22 14:43:38 UTC
Permalink
Post by Andrew Morton
ecryptfs-fs-makefile-and-fs-kconfig.patch
ecryptfs-fs-makefile-and-fs-kconfig-kconfig-help-update.patch
ecryptfs-documentation.patch
ecryptfs-makefile.patch
ecryptfs-main-module-functions.patch
ecryptfs-header-declarations.patch
ecryptfs-superblock-operations.patch
#ecryptfs-superblock-operations-ecryptfs-build-fix.patch
ecryptfs-dentry-operations.patch
ecryptfs-file-operations.patch
#ecryptfs-vs-streamline-generic_file_-interfaces-and-filemap.patch
#ecryptfs-vs-streamline-generic_file_-interfaces-and-filemap-fix.patch
ecryptfs-inode-operations.patch
ecryptfs-mmap-operations.patch
ecryptfs-mmap-operations-fix.patch
ecryptfs-keystore.patch
ecryptfs-crypto-functions.patch
ecryptfs-crypto-functions-mutex-fixes.patch
fs-ecryptfs-possible-cleanups.patch
ecryptfs-debug-functions.patch
ecryptfs-alpha-build-fix.patch
ecryptfs-convert-assert-to-bug_on.patch
ecryptfs-remove-pointless-bug_ons.patch
ecryptfs-remove-unnecessary-null-checks.patch
ecryptfs-rewrite-ecryptfs_fsync.patch
ecryptfs-overhaul-file-locking.patch
ecryptfs-remove-lock-propagation.patch
ecryptfs-dont-muck-with-the-existing-nameidata-structures.patch
ecryptfs-asm-scatterlisth-linux-scatterlisth.patch
ecryptfs-support-for-larger-maximum-key-size.patch
ecryptfs-add-codes-for-additional-ciphers.patch
ecryptfs-unencrypted-key-size-based-on-encrypted-key-size.patch
ecryptfs-packet-and-key-management-update-for-variable-key-size.patch
ecryptfs-add-ecryptfs_-prefix-to-mount-options-key-size-parameter.patch
ecryptfs-set-the-key-size-from-the-default-for-the-mount.patch
ecryptfs-check-for-weak-keys.patch
ecryptfs-add-define-values-for-cipher-codes-from-rfc2440-openpgp.patch
ecryptfs-convert-bits-to-bytes.patch
ecryptfs-more-elegant-aes-key-size-manipulation.patch
ecryptfs-more-intelligent-use-of-tfm-objects.patch
ecryptfs-remove-debugging-cruft.patch
ecryptfs-get_sb_dev-fix.patch
ecryptfs-validate-minimum-header-extent-size.patch
ecryptfs-validate-body-size.patch
ecryptfs-validate-packet-length-prior-to-parsing-add-comments.patch
ecryptfs-use-the-passed-in-max-value-as-the-upper-bound.patch
ecryptfs-change-the-maximum-size-check-when-writing-header.patch
ecryptfs-print-the-actual-option-that-is-problematic.patch
ecryptfs-add-a-maintainers-entry.patch
ecryptfs-partial-signed-integer-to-size_t-conversion-updated-ii.patch
ecryptfs-graceful-handling-of-mount-error.patch
inode-diet-move-i_pipe-into-a-union-ecryptfs.patch
inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-ecryptfs.patch
streamline-generic_file_-interfaces-and-filemap-ecryptfs.patch
ecryptfs-fix-printk-format-warnings.patch
ecryptfs-associate-vfsmount-with-dentry-rather-than-superblock.patch
ecryptfs-mntput-lower-mount-on-umount_begin.patch
vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers-ecryptfs.patch
make-kmem_cache_destroy-return-void-ecryptfs.patch
ecryptfs-inode-numbering-fixes.patch
ecryptfs-versioning-fixes.patch
ecryptfs-versioning-fixes-tidy.patch
Will fold into a single patch and will then merge.
Please add a

Not-Acked-By: Christoph Hellwig <***@lst.de>

here as you don't seem to listen to any of the comments I had against
the current state and I want this clearly documented.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2006-09-22 16:04:33 UTC
Permalink
On Fri, 22 Sep 2006 15:42:33 +0100
Post by Christoph Hellwig
Post by Andrew Morton
ecryptfs-versioning-fixes-tidy.patch
Will fold into a single patch and will then merge.
Please add a
here as you don't seem to listen to any of the comments I had against
the current state and I want this clearly documented.
I thought everything got addressed, apart from

- please split all the generic stackable filesystem passthorugh routines
into a separated stackfs layer, in a few files in fs/stackfs/ that
you depend on. They'll get _GPL exported to all possible stackable
filesystem. They'll need their own store underlying object helpers,
but that can be made to work by embedding the generic stackfs data
as first thing in the ecryptfs object.

which seemed rather a lot to ask.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Michael Halcrow
2006-09-22 16:54:05 UTC
Permalink
Post by Andrew Morton
On Fri, 22 Sep 2006 15:42:33 +0100
Post by Christoph Hellwig
Post by Andrew Morton
ecryptfs-versioning-fixes-tidy.patch
Will fold into a single patch and will then merge.
Please add a
here as you don't seem to listen to any of the comments I had
against the current state and I want this clearly documented.
I thought everything got addressed, apart from
- please split all the generic stackable filesystem passthorugh routines
into a separated stackfs layer, in a few files in fs/stackfs/ that
you depend on. They'll get _GPL exported to all possible stackable
filesystem. They'll need their own store underlying object helpers,
but that can be made to work by embedding the generic stackfs data
as first thing in the ecryptfs object.
which seemed rather a lot to ask.
A common framework that would be useful for all potential stackable
filesystems is indeed a major project in and of itself, and such a
thing right now would be premature. We need to see how code for other
stackable filesystems will look once it is actually in the
kernel. There is core behavior that differs between eCryptfs and
Unionfs -- for instance, how inodes are referenced. eCryptfs, in its
current form, can do just fine with referencing the internal inode
struct pointer, whereas Unionfs implements persistent inodes. Then
there are issues with readdir/filldir semantics, wherein Unionfs needs
a mechanism to implement whiteout operations. eCryptfs just has a
simple one-to-one VFS layer mapping, while Unionfs has to merge
several VFS mounts under it. The core *_info data structure diverge
quite a bit between the two. Right now, eCryptfs and Unionfs can get
by with a page-to-page mapping between the upper and lower files, but
that would not necessarily be the case for a compressing stacked
layer; the common framework would have to take that into
consideration.

Stacked filesystem authors are certainly interested in addressing
these sorts of issues, but an iterative strategy for solving them is
the most reasonable approach. The first step is to get at least two
stacked filesystems into the kernel (eCryptfs and Unionfs) and then
follow up with a series of patches to extract the common functionality
once we see somewhat finalized code bases for both.

Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Voluspa
2006-09-23 02:18:44 UTC
Permalink
Sorry about dropping CC-s. I'm reading archived lkml and can't see them.
Adding the obvious candidates instead (Andrew, you're not obvious, but if
you'll pull in Thomas's stuff, you'll be...)
Post by Bill Rugolsky Jr.
Post by Ingo Molnar
Post by Ingo Molnar
would be nice to merge the -hrt queue that goes right ontop
[...]
Post by Bill Rugolsky Jr.
Post by Ingo Molnar
note that this is a new implementation of dynticks though, not Con's
older stuff which you probably used, right? But it's fairly
low-impact (just a few lines ontop of hrtimers, here and there),
ontop of the long-existing -hrt queue.
Just a data point, FWIW; I've made no systematic effort to find
regressions.
We've been running Thomas's (pre-dynticks) 2.6.16-hrt patchset (and
HZ=1000) without issue as part of my standard kernel build on x86 and
x86_64 UP/SMP production hosts -- workstations, PostgreSQL (and other)
servers, and routers --- since I experienced latency/ntp problems with
an unpatched kernel using sata_nv on Tyan 2895 Nvidia CK804-chipset
mobo back in March 2006. I've also been running the (originally
x86-only) 2.6.17-dynticks patch on a Tyan Athlon SMP workstation mobo,
and occasionally on my laptop, so far without issue.
Here's another data point: I tried 2.6.18-rt3 today on a x86_64
notebook. I'm on an eternal quest for extended battery time, so
NO_HZ would be perfect. Long story shortened, HIGH_RES_TIMERS
(prerequisite for NO_HZ) caused the CPU to never step down from max
speed (ondemand, powernow_k8) at 2200 MHz.

In addition, something invisible used very frequent bursts of ~30% SYS
CPU. Turning from PREEMPT_RT to PREEMPT_DESKTOP introduced occasional
bursts of ~50% USER CPU (mixed with the SYS). Toggling RCU model
made no difference.

Going from the default HIGH_RES_RESOLUTION=1000 to 10000 and even
100000 had no impact on the level or frequency of the bursts.

This resulted in the CPU temp never going lower than 53C, and thusly
the fan kept spinning at 'level 2' - it needs 49C to fall back to
normal speed. That sound tend to drive me insane...

Turning off HIGH_RES_TIMER allowed the CPU to enter the lowest 800 MHz
immediately, and fan to slow down after the normal time, post-boot.

I'd be glad to help investigate this issue, but since -rt is completely
new territory I'd need exact instructions about which knobs to turn.
The CPU usage cause _was_ invisible, at least to "top". And I had all
USB stuff unplugged, and no ehci_hcd loaded (that's another story,
written in the bugzilla). Completely plain console, no X, no net, no
nothing.

Here's a snippet from dmesg pertaining to the timers:

ACPI: PM-Timer IO Port: 0x4008
[...]
Event source pit configured with caps set: 07
time.c: Detected 2201.306 MHz processor.
[...]
Calibrating delay using timer specific routine.. 4404.80 BogoMIPS
(lpj=2202402)
[...]
Using local APIC timer interrupts.
result 12507441
Detected 12.507 MHz APIC timer.
lapic max_delta_ns: 670689262
Event source pit new caps set: 03
Event source lapic configured with caps set: 04
[...]
Real Time Clock Driver v1.12ac
[...]
Time: tsc clocksource has been installed.
Event source pit disabled
Event source lapic configured with caps set: 08
hrtimers: Switched to high resolution mode CPU 0

Oh, and here's a compiler warning fix (when PREEMPT_RT is off):

diff -Nurp linux-2.6.18-rt3/kernel/hrtimer.c linux-2.6.18-rt3-db/kernel/hrtimer.c
--- linux-2.6.18-rt3/kernel/hrtimer.c 2006-09-23 01:12:41.000000000 +0200
+++ linux-2.6.18-rt3-db/kernel/hrtimer.c 2006-09-23 02:16:29.000000000 +0200
@@ -786,7 +786,7 @@ static inline void hrtimer_raise_softirq
raise_softirq_irqoff(HRTIMER_SOFTIRQ);
}

-static inline int hrtimer_adjust_softirq_prio(struct hrtimer_cpu_base *base)
+static inline void hrtimer_adjust_softirq_prio(struct hrtimer_cpu_base *base)
{
}

Mvh
Mats Johannesson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Loading...