2006-12-05 04:40:35

by Andrew Morton

[permalink] [raw]
Subject: -mm merge plans for 2.6.20



add-bottom_half.h.patch
drm-sis-linkage-fix.patch
skip-data-conversion-in-compat_sys_mount-when-data_page-is-null.patch

Will merge

revert-generic_file_buffered_write-handle-zero-length-iovec-segments.patch
revert-generic_file_buffered_write-deadlock-on-vectored-write.patch
generic_file_buffered_write-cleanup.patch
mm-only-mm-debug-write-deadlocks.patch
mm-fix-pagecache-write-deadlocks.patch
mm-fix-pagecache-write-deadlocks-comment.patch
mm-fix-pagecache-write-deadlocks-xip.patch
mm-fix-pagecache-write-deadlocks-mm-pagecache-write-deadlocks-efault-fix.patch
mm-fix-pagecache-write-deadlocks-zerolength-fix.patch
mm-fix-pagecache-write-deadlocks-stale-holes-fix.patch
fs-prepare_write-fixes.patch
fs-prepare_write-fixes-fuse-fix.patch
fs-prepare_write-fixes-jffs-fix.patch
fs-prepare_write-fixes-fat-fix.patch
fs-fix-cont-vs-deadlock-patches.patch

This is the writev-speedup and pagefault-in-write() deadlock fix. Not ready.

acpi-clear-gpe-before-disabling-it.patch
acpi-fix-single-linked-list-manipulation.patch
acpi-processor-prevent-loading-module-on-failures.patch
make-drivers-acpi-baycdrive_bays-static.patch
acpi-replace-kmallocmemset-with-kzalloc.patch
make-drivers-acpi-eccec_ecdt-static.patch
drivers-acpi-oslc-fix-a-null-check.patch
acpi-dont-select-pm.patch
implementation-of-acpi_video_get_next_level.patch
video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
add-display-output-class-support.patch
add-output-class-document.patch
add-support-for-asus-a6va-m6v-w5f-v6v-laptops-in-asus-acpi.patch
add-support-for-acpi_load_table-acpi_unload_table_id.patch
altix-acpi-ssdt-pci-device-support.patch
altix-add-acpi-ssdt-pci-device-support-hotplug.patch

Sent to APCI maintainers

cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch
remove-hotplug-cpu-crap-from-cpufreq.patch
cpufreq-select-consistently-re-2619-rc5-mm1.patch
cpufreq-set-policy-curfreq-on-initialization.patch
bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch

Sent to cpufreq maintainer

ppc-m48t35-add-missing-bracket.patch
ppc-cs4218_tdm-remove-extra-brace.patch
powerpc-replace-kmallocmemset-with-kzalloc.patch

Am holding onto these until the powerpc git tree gets un-messied up.

fix2-gregkh-driver-modules-state.patch
platform_driver_probe-can-save-codespace-save-codespace.patch
driver-core-per-subsystem-multithreaded-probing.patch
driver-core-dont-fail-attaching-the-device-if-it.patch
make-platform_device_add_data-accept-a-const-pointer.patch

Sent to Greg.

drm-fix-return-value-check.patch
drm-handle-pci_enable_device-failure.patch

Sent to Dave.

ia64-resolve-name-clash-by-renaming-is_available_memory.patch
ia64-replace-kmallocmemset-with-kzalloc.patch

Sent to Tony

crash-on-evdev-disconnect.patch

Sent to Dmitry.

kconfig-new-function-bool-conf_get_changedvoid.patch
kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch
kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch
kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch
pa-risc-fix-bogus-warnings-from-modpost.patch
kconfig-refactoring-for-better-menu-nesting.patch
kbuild-fix-rr-is-now-default.patch
kbuild-dont-put-temp-files-in-the-source-tree.patch
actually-delete-the-as-instr-ld-option-tmp-file.patch

Sent to Sam, but Sam's presently busy. I might need to make some kbuild
decisions..

pci-move-pci_vdevice-from-libata-to-core.patch
pata_cs5530-suspend-resume-support-tweak.patch
pata_sil680-suspend-resume-tidy.patch
ata-fix-platform_device_register_simple-error-check.patch
initializer-entry-defined-twice-in-pata_rz1000.patch
ata_piix-ide-mode-sata-patch-for-intel-ich9.patch
pata_via-suspend-resume-support-fix.patch
sata_nv-add-suspend-resume-support.patch
trivial-piix-swap-bogus-dot-for-comma-space.patch
pata_ali-small-fixes.patch
pata_via-via-8251-bridged-systems-are-now-out-and-about.patch
pata_it8213-add-new-driver-for-the-it8213-card.patch
pata_it8213-add-new-driver-for-the-it8213-card-tidy.patch

Sent to Jeff

via-pata-controller-xfer-fixes.patch
via-pata-controller-xfer-fixes-fix.patch
libata_resume_fix.patch
ahci-ati-sb600-sata-support-for-various-modes.patch

libata random cruft. Am sitting on these until things get resolved one way
or the other.

git-mtd-ssfdc-build-fix.patch
mtd-esb2rom-uses-pci.patch
remove-mtd-jffs2-userh.patch
jffs2-replace-kmallocmemset-with-kzalloc.patch

Sent to David.

libphy-dont-do-that.patch
3x59x-fix-pci-resource-management.patch
update-smc91x-driver-with-arm-versatile-board-info.patch
8139too-force-media-setting-fix.patch
sundance-change-phy-address-search-from-phy=1-to-phy=0.patch
bonding-incorrect-bonding-state-reported-via-ioctl.patch
declance-fix-pmax-and-pmad-support.patch
declance-support-the-i-o-asic-lance-w-o-turbochannel.patch
sk98lin-debug-build-fix.patch
net-smc91x-add-missing-bracket.patch

Sent to Jeff

nfs-kill-obsolete-nfs_paranoia.patch
nfs-represent-64-bit-fileids-as-64-bit-inode-numbers-on-32-bit-systems.patch
gss_spkm3-fix-error-handling-in-module-init.patch
auth_gss-unregister-gss_domain-when-unloading-module.patch
fix-sunrpc-wakeup-execute-race-condition.patch

Sent to Trond

8250-uart-backup-timer.patch
serial-trivial-code-flow-simplification.patch
make-sure-uart-is-powered-up-when-dumping-mctrl-status.patch
perle-multimodem-card-pci-ras-detection.patch
serial-replace-kmallocmemset-with-kzalloc.patch

Serial patches, and we don't have a serial maintainer. Hopefully Russell
will have time to comment on these, otherwise I'll take a shot at it.

pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch
pci-introduce-pci_find_present.patch
pci-fix-multiple-problems-with-via-hardware.patch
fix-gregkh-pci-pci-enable-disable-device-is-nestable.patch
pci-check-szhi-when-sz-is-0-when-64-bit-iomem-bigger-than-4g.patch
dont-export-device-ids-to-userspace.patch
sys-bus-pci-drivers-driver-new_id-search-dynamics-ids-first.patch
be-a-bit-defensive-in-quirk_nvidia_ck804-so-we-dont-risk-dereferencing-a-null-pdev.patch

Sent to Greg.

s390-preparatory-cleanup-in-common-i-o-layer.patch
s390-make-the-per-subchannel-lock-dynamic.patch
s390-dynamic-subchannel-mapping-of-ccw-devices.patch
s390-use-dev-groups-for-subchannel-attributes.patch
s390-update-cio-documentation.patch

Sent to Martin.

drivers-scsi-small-cleanups.patch
drivers-scsi-aic7xxx-aic79xx_corec-make-ahd_match_scb-static.patch
scsi-clean-up-warnings-in-advansys-driver.patch
drivers-scsi-advansysc-cleanups.patch
megaraid-fix-warnings-when-config_proc_fs=n.patch
drivers-scsi-pcmcia-nsp_csh-removal-of-old.patch
remove-unnecessary-check-in-drivers-scsi-sgc.patch
remove-extra-newline-from-info-message.patch
fix-scsi-scsi_transporth-compile-error.patch
pci_module_init-convertion-in-the-legacy-megaraid-driver.patch
pci_module_init-convertion-in-tmscsimc.patch
drivers-scsi-dpt_i2oc-remove-dead-code.patch
mpt-fusion-handle-pci-layer-error-on-resume.patch
drivers-scsi-ncr5380c-replacing-yield-with-a.patch
drivers-scsi-megaraidc-replacing-yield-with-a.patch
scsi-whitespace-cleanup-in-the-dpt-driver.patch
scsi-fix-uaccess-handling.patch
drivers-scsi-mca_53c9xc-save_flags-cli-removal.patch
drivers-scsi-aic7xxx-make-functions-static.patch
scsi-advansys-wrap-pci-table-inside-ifdef-config_pci.patch
scsi-in2000-scsi_cmnd-convertion.patch
make-qla2x00_reg_remote_port-static.patch
iscsi-fix-crypto_alloc_hash-error-check.patch
scsi-sic7xxx-stray-bracket-fix.patch
scsi-53c7xx-brackets-fix.patch
fix-sense-key-medium-error-processing-and-retry.patch
sym53c8xx_2-claims-cpqarray-device.patch
aic79xx-wrong-max-memory-at-driver-init.patch
drivers-scsi-wd33c93c-cleanups.patch
scsi-megaraid-fix-mmio-casts.patch
scsi-cover-up-bugs-fix-up-compiler-warnings-in-megaraid-driver.patch

Sent to James.

nokia-e70-is-an-unusual-device.patch
usb-auerswald-replace-kmallocmemset-with-kzalloc.patch
usb-fix-ohcih-over-use-warnings.patch
usb_rtl8150-must-select-mii.patch

Sent to Greg.

hostap-replace-kmallocmemset-with-kzalloc.patch
prism54-replace-kmallocmemset-with-kzalloc.patch
ipw2200-replace-kmallocmemset-with-kcalloc.patch
softmac-fix-unbalanced-mutex_lock-unlock-in-ieee80211softmac_wx_set_mlme.patch

Not sent to John - I forgot.

fix-x86_64-mm-patch-inline-replacements-for-section-warnings.patch
fix-x86_64-mm-i386-config-core2.patch
genapic-optimize-fix-apic-mode-setup.patch
mtrr-replace-kmallocmemset-with-kzalloc.patch
i386-correct-documentation-for-bzimage-protocol-v205.patch
fix-asm-constraints-in-i386-atomic_add_return.patch
i386-msr-remove-unused-variable.patch
arch-i386-kernel-remove-remaining-pc98-code.patch
i386-replace-kmallocmemset-with-kzalloc.patch
cleanup-arch-i386-kernel-smpbootcsmp_tune_scheduling.patch
make-i386-default-to-highmem4g-instead-of-nohighmem.patch
convert-i386-pda-code-to-use-%fs.patch
x86_64-check-vector-in-setup_ioapic_dest-to-verify-if-need-setup_io_apic_irq.patch
x86_64-make-the-numa-hash-function-nodemap-allocation.patch
x86_64-make-the-numa-hash-function-nodemap-allocation-fix.patch
include-asm-x86_64-cpufeatureh-isnt-a-userspace-header.patch
i386-kernel-smpc-dont-use-set_irq_regs.patch
fix-numaq-build-error.patch
x86_64-i386-kernel-mode-faults-pollute-current-thead.patch

Sent to Andi.

memory-page-alloc-minor-cleanups.patch
memory-page-alloc-minor-cleanups-fix.patch
__unmap_hugepage_range-add-comment.patch
get-rid-of-zone_table.patch

Shall merge.

deal-with-cases-of-zone_dma-meaning-the-first-zone.patch
get-rid-of-zone_table-fix-3.patch
introduce-config_zone_dma.patch
optional-zone_dma-in-the-vm.patch
optional-zone_dma-in-the-vm-no-gfp_dma-check-in-the-slab-if-no-config_zone_dma-is-set.patch
optional-zone_dma-in-the-vm-no-gfp_dma-check-in-the-slab-if-no-config_zone_dma-is-set-reduce-config_zone_dma-ifdefs.patch
optional-zone_dma-for-ia64.patch
remove-zone_dma-remains-from-parisc.patch
remove-zone_dma-remains-from-sh-sh64.patch
set-config_zone_dma-for-arches-with-generic_isa_dma.patch
zoneid-fix-up-calculations-for-zoneid_pgshift.patch

Might drop, don't know yet. These make a mess of core MM for dubiuous gain.

memory-page_alloc-zonelist-caching-speedup.patch
memory-page_alloc-zonelist-caching-reorder-structure.patch
oom-dont-kill-unkillable-children-or-siblings.patch
oom-cleanup-messages.patch
oom-less-memdie.patch
mm-incorrect-vm_fault_oom-returns-from-drivers.patch
grab-swap-token-reordered.patch
new-scheme-to-preempt-swap-token.patch
new-scheme-to-preempt-swap-token-tidy.patch
mm-add-arch_alloc_page.patch
balance_pdgat-cleanup.patch
shared-page-table-for-hugetlb-page-v4.patch
htlb-forget-rss-with-pt-sharing.patch
slab-debug-and-arch_slab_minalign-dont-get-along.patch
mm-slab-eliminate-lock_cpu_hotplug-from-slab.patch
add-noaliencache-boot-option-to-disable-numa-alien-caches.patch
mm-arch-do_page_fault-vs-in_atomic.patch
mm-pagefault_disableenable.patch
mm-pagefault_disableenable-s390-fix.patch
mm-kummap_atomic-vs-in_atomic.patch
fix-kunmap_atomics-use-of-kpte_clear_flush.patch
allowing-user-processes-to-rise-their-oom_adj-value.patch
mlock-cleanup.patch
oom-can-panic-due-to-processes-stuck-in-__alloc_pages.patch
always-print-out-the-header-line-in-proc-swaps.patch
leak-tracking-for-kmalloc_node.patch
leak-tracking-for-kmalloc_node-fix.patch
add-numa-node-information-to-struct-device.patch
add-numa-node-information-to-struct-device-tidy.patch
node-aware-skb-allocation.patch
node-aware-skb-allocation-fix-for-device-tree-changes.patch
allow-null-pointers-in-percpu_free.patch
enables-booting-a-numa-system-where-some-nodes-have-no.patch
make-mm-thrashcglobal_faults-static.patch
remove-bio_cachep-from-slabh.patch
move-sighand_cachep-to-include-signalh.patch
move-vm_area_cachep-to-include-mmh.patch
move-files_cachep-to-include-fileh.patch
move-filep_cachep-to-include-fileh.patch
move-fs_cachep-to-linux-fs_structh.patch
move-names_cachep-to-linux-fsh.patch
remove-uses-of-kmem_cache_t-from-mm-and-include-linux-slabh.patch
drain_node_page-drain-pages-in-batch-units.patch
numa-node-ids-are-int-page_to_nid-and-zone_to_nid-should-return-int.patch
silence-unused-pgdat-warning-from-alloc_bootmem_node-and-friends.patch
reject-corrupt-swapfiles-earlier.patch
mm-cleanup-indentation-on-switch-for-cpu-operations.patch
kill-install_file_ptes-pte_val.patch
slab-remove-slab_no_grow.patch
slab-remove-slab_level_mask.patch
slab-remove-slab_noio.patch
slab-remove-slab_nofs.patch
slab-remove-slab_user.patch
slab-remove-slab_atomic.patch
slab-remove-slab_kernel.patch
slab-remove-slab_dma.patch
slab-remove-kmem_cache_t.patch
slab-deprecate-kmem_cache-t.patch
slab-fixup-two-issues-in-kmalloc_node--__cache_alloc_node.patch
gfp_thisnode-must-not-trigger-global-reclaim.patch
slab-better-fallback-allocation-behavior.patch
mm-make-compound-page-destructor-handling-explicit.patch
mm-make-compound-page-destructor-handling-explicit-tidy.patch
save-some-bytes-in-struct-mm_struct.patch

Memory management queue. Shall merge, subject to re-review

mm-call-into-direct-reclaim-without-pf_memalloc-set.patch
mm-cleanup-and-document-reclaim-recursion.patch
congestion-wait-dont-wait-when-there-are-no-pages-under-writeback.patch

Might merge - need to check these out a bit more closely.

radix-tree-rcu-lockless-readside.patch

There's no reason to merge this yet.

acx1xx-wireless-driver.patch

This is -mm-only material.

security-keys-user-kmemdup.patch
implement-file-posix-capabilities.patch

Security - shall merge.

arch-frv-kernel-futexc-must-include-linux-uaccessh.patch
avr32-fixup-kprobes-preemption-handling.patch
h8300-stray-bracket-fix.patch
alpha-switch-to-pci_get-api.patch
m68k-replace-kmallocmemset-with-kzalloc.patch
uml-fix-prototypes.patch
fix-v850-compilation.patch

Misc arch fixes - shall merge.

uswsusp-add-pmops-prepareenterfinish-support-aka-platform-mode.patch
swsusp-use-partition-device-and-offset-to-identify-swap-areas.patch
swsusp-rearrange-swap-handling-code.patch
swsusp-use-block-device-offsets-to-identify-swap-locations-rev-2.patch
swsusp-add-resume_offset-command-line-parameter-rev-2.patch
swsusp-document-support-for-swap-files-rev-2.patch
swsusp-add-ioctl-for-swap-files-support.patch
swsusp-update-userland-interface-documentation.patch
swsusp-improve-handling-of-highmem.patch
swsusp-improve-handling-of-highmem-fix.patch
swsusp-use-__gfp_wait.patch
swsusp-fix-platform-mode.patch
add-include-linux-freezerh-and-move-definitions-from.patch
add-include-linux-freezerh-and-move-definitions-from-ueagle-fix.patch
add-include-linux-freezerh-and-move-definitions-from-ucb1400_ts-fix.patch
quieten-freezer-if-config_pm_debug.patch
swsusp-cleanup-whitespace-in-freezer-output.patch
swsusp-thaw-userspace-and-kernel-space-separately.patch
swsusp-support-i386-systems-with-pae-or-without-pse.patch
suspend-dont-change-cpus_allowed-for-task-initiating-the-suspend.patch
swsusp-measure-memory-shrinking-time.patch
suspend-to-disk-fails-if-gdb-is-suspended-with-a-traced-child.patch
convert-pm_sem-to-a-mutex.patch
convert-pm_sem-to-a-mutex-fix.patch
swsusp-untangle-thaw_processes.patch
swsusp-untangle-freeze_processes.patch
swsusp-fix-coding-style-in-suspendc.patch
swsusp-fix-labels.patch
s2ram-debugging-documentation.patch
pm-fix-swsusp-debug-mode-testproc.patch
swsusp-kill-write-only-variable.patch
support-for-freezeable-workqueues.patch
use-freezeable-workqueues-in-xfs.patch

power/swsusp - shall merge.

cciss-version-change.patch
cciss-reference-driver-support.patch
cciss-increase-number-of-commands-on-controller.patch
cciss-fix-pci-ssid-for-the-e500-controller.patch
cciss-disable-dma-prefetch-on-p600.patch
cciss-set-sector_size-to-2048-for-performance.patch
cciss-set-sector_size-to-2048-for-performance-tidy.patch
cciss-change-cciss_open-for-consistency.patch
cciss-remove-unused-revalidate_allvol-function.patch
cciss-add-support-for-1024-logical-volumes.patch
cciss-cleanup-cciss_interrupt-mode.patch

Shall merge.

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

Am still waiting to hear from sfrench on the appropriateness of this.

edac-new-opteron-athlon64-memory-controller-driver.patch
drivers-edac-make-code-static.patch

This stuff seems to be permanently stalled by Andi/Alan disagreement.

pci_module_init-convertion-for-k8_edacc.patch
fix-rescan_partitions-to-return-errors-properly.patch
fix-check_partition-routines.patch
serial-uartlite-driver.patch
serial-uartlite-driver-fix.patch
fix-serial-uartlite-after-global-pt_regs.patch
serial-uartlite-support-multiple-devices.patch
serial-uartlite-initialize-port-parameters-in-console_setup.patch
ioremap-balanced-with-iounmap-for-drivers-char-rio-rio_linuxc.patch
ioremap-balanced-with-iounmap-for-drivers-char-moxac.patch
ioremap-balanced-with-iounmap-for-drivers-char-istallionc.patch
sound-oss-btaudioc-ioremap-balanced-with-iounmap.patch
lockdep-annotate-nfs-nfsd-in-kernel-sockets.patch
lockdep-annotate-nfs-nfsd-in-kernel-sockets-tidy.patch
honour-mnt_noexec-for-access.patch
ext2-fsid-for-statvfs.patch
ext3-fsid-for-statvfs.patch
ext4-fsid-for-statvfs.patch
kernel-proc-kallsyms-reports-lower-case.patch
i2o-more-error-checking.patch
pnp-handle-sysfs-errors.patch
rtc-handle-sysfs-errors.patch
sound-oss-emu10k1-handle-userspace-copy-errors.patch
spi-improve-sysfs-compiler-complaint-handling.patch
drivers-add-lcd-support-3.patch
drivers-add-lcd-support-3-Kconfig-fix.patch
drivers-add-lcd-support-update-4.patch
drivers-add-lcd-support-update-5.patch
drivers-add-lcd-support-update6.patch
drivers-add-lcd-support-update-7.patch
drivers-add-lcd-support-update-8.patch
constify-inode-accessors.patch
ide-complete-switch-to-pci_get.patch
remove-drivers-pci-searchcpci_find_device_reverse.patch
fuse-update-userspace-interface-to-version-78.patch
fuse-minor-cleanup-in-fuse_dentry_revalidate.patch
fuse-add-support-for-block-device-based-filesystems.patch
fuse-add-blksize-option.patch
fuse-add-bmap-support.patch
fuse-add-destroy-operation.patch
fuse-fix-compile-without-config_block.patch
sysrq-x-show-blocked-tasks.patch
#sysrq-t-broke-and-no-one-noticed.patch
file-kill-unnecessary-timer-in-fdtable_defer.patch
remove-double-cast-to-same-type.patch
io-storage-documentation-update-to-as-ioschedtxt.patch
export-pm_suspend-for-the-shared-apm-emulation.patch
patch-to-fix-reiserfs-bad-path-release-panic-on-2619-rc1.patch
via82cxxx-handle-error-condition-properly.patch
lockdep-fix-ide-proc-interaction.patch
pull-in-necessary-header-files-for-cdevh.patch
cpuset-minor-code-refinements.patch
remove-superfluous-lock_super-in-ext2-and-ext3-xattr-code.patch
correct-bus_num-and-buffer-bug-in-spi-core.patch
spi-set-kset-of-master-class-dev-explicitly.patch
paride-rename-pi_register-and-pi_unregister.patch
paride_register-shuffle-return-values.patch
lockdep-internal-locking-fixes.patch
lockdep-misc-fixes-in-lockdepc.patch
cpuset-remove-sched-domain-hooks-from-cpusets.patch
binfmt_elf-randomize-pie-binaries.patch
handle-ext3-directory-corruption-better.patch
handle-ext4-directory-corruption-better.patch
tifm-fix-null-ptr-and-style.patch
function-v9fs_get_idpool-returns-int-not-u32-as-called-twice.patch
disable-clone_child_cleartid-for-abnormal-exit.patch
binfmt-fix-uaccess-handling.patch
compat-fix-uaccess-handling.patch
profile-fix-uaccess-handling.patch
kconfig-printk_time-depends-on-printk.patch
parport_pc-add-support-for-ox16pci952-parallel-port.patch
probe_kernel_address-needs-to-do-set_fs.patch
slab-use-probe_kernel_address.patch
paride-return-proper-error-code.patch
read_cache_pages-cleanup.patch
taskstats_exit_alloc-optimize-simplify.patch
taskstats-cleanup-do_exit-path.patch
taskstats-cleanup-signal-stats-allocation.patch
taskstats-factor-out-reply-assembling.patch
taskstats-use-nla_reserve-for-reply-assembling.patch
taskstats-cleanup-reply-assembling.patch
cpuset-allow-a-larger-buffer-for-writes-to-cpuset-files.patch
compile-time-check-re-world-writeable-module-params.patch
lockdep-annotate-bcsp-driver.patch
exar-quad-port-serial.patch
exar-quad-port-serial-fix.patch
fs-trivial-vsnprintf-conversion.patch
hpfs-bring-hpfs_error-into-shape.patch
hpfs-fix-printk-format-warnings.patch
drivers-cdrom-trivial-vsnprintf-conversion.patch
vfs-extra-check-inside-dentry_unhash.patch
correct-misc_register-return-code-handling-in-several-drivers.patch
more-list-debugging-context.patch
get_options-to-allow-a-hypenated-range-for-isolcpus.patch
vfs_getattr-remove-dead-code.patch
ext3-uninline-large-functions.patch
ext4-uninline-large-functions.patch
uninline-module_put.patch
i2lib-unused-variable-cleanup.patch
make-initramfs-printk-a-warning-on-incorrect-cpio-type.patch
corrupted-cramfs-filesystems-cause-kernel-oops.patch
lockdep-print-current-locks-on-in_atomic-warnings.patch
lockdep-name-some-old-style-locks.patch
documentation-remount_fs-needs-lock_kernel.patch
sleep-profiling.patch
sleep-profiling-fixes.patch
sleep-profiling-fix.patch
ext4_ext_split-remove-dead-code.patch
debug-workqueue-locking-sanity.patch
debug-workqueue-locking-sanity-fix.patch
hz-300hz-support.patch
pcengines-wrap-led-support.patch
pcengines-wrap-led-support-fix.patch
driver-base-memoryc-remove-warnings-of.patch
remove-kernel-syscalls.patch
remove-kernel-syscalls-x86_64-fix.patch
protect-ext2-ioctl-modifying-append_only-immutable-etc-with-i_mutex.patch
remove-hash_highmem.patch
retries-in-ext3_prepare_write-violate-ordering-requirements.patch
retries-in-ext3_prepare_write-violate-ordering-requirements-fix.patch
ktime-fix-signed--unsigned-mismatch-in-ktime_to_ns.patch
qconf-support-old-qt.patch
remove-the-syslog-interface-when-printk-is-disabled.patch
ver_linux-additions.patch
initrd-remove-unused-false-condition-for.patch
fix-the-size-limit-of-compat-space-msgsize.patch
elf-always-define-elf_addr_t-in-linux-elfh.patch
elf-include-terminating-zero-in-n_namesz.patch
elf-fix-kcore-note-size-calculation.patch
elf-fix-kcore-note-size-calculation-fix.patch
reiserfs-add-missing-d-cache-flushing.patch
reiserfs-add-missing-d-cache-flushing-tweak.patch
the-scheduled-removal-of-some-oss-options.patch
make-1-bit-bitfields-unsigned.patch
hvcs-char-driver-janitoring-move-block-of-code.patch
hvcs-char-driver-janitoring-rm-compiler-warnings.patch
kprobes-enable-booster-on-the-preemptible-kernel.patch
declare-smp_call_function_single-in-generic-code.patch
up-smp_call_function_single-should-disable-interrupts.patch
smp_call_function_single-check-that-local-interrupts-are-enabled.patch
hotplug-cpu-clean-up-hotcpu_notifier-use.patch
hotplug-cpu-clean-up-hotcpu_notifier-use-vs-gregkh-driver-cpu-topology-consider-sysfs_create_group-return-value.patch
ext3-fix-reservation-extension.patch
ext4-fix-reservation-extension.patch
allow-hwrandom-core-to-be-a-module.patch
make-mm-shmemcshmem_xattr_security_handler-static.patch
remove-kernel-lockdepclockdep_internal.patch
make-kernel-signalckill_proc_info-static.patch
i2o-handle-__copy_from_user.patch
i2o-fix-i2o_config-without-adaptec-extension.patch
make-ecryptfs_version_str_map-static.patch
make-fs-jbd-transactionc__journal_temp_unlink_buffer-static.patch
make-fs-jbd2-transactionc__jbd2_journal_temp_unlink_buffer-static.patch
fs-lockd-hostc-make-2-functions-static.patch
make-fs-proc-basecproc_pid_instantiate-static.patch
parport-section-mismatches-with-hotplug=n.patch
agp-amd64-section-mismatches-with-hotplug=n.patch
add-rtc-omap-driver.patch
add-return-value-checking-of-get_user-in.patch
add-return-value-checking-of-get_user-in-fix.patch
ciss-require-same-scsi-module-support.patch
export-toshiba-smm-support-for-neofb-module.patch
kernel-doc-add-fusion-and-i2o-to-kernel-api-book.patch
kernel-doc-fix-fusion-and-i2o-docs.patch
kernel-api-book-remove-videodev-chapter.patch
rcu-add-a-prefetch-in-rcu_do_batch.patch
dont-insert-pipe-dentries-into-dentry_hashtable.patch
dcache-avoid-rcu-for-never-hashed-dentries.patch
net-dont-insert-socket-dentries-into-dentry_hashtable.patch
kernel-core-replace-kmallocmemset-with-kzalloc.patch
kernel-doc-stricter-function-pointer-recognition.patch
fs-reorder-some-struct-inode-fields-to-speedup-i_size-manipulations.patch
add-struct-dev-pointer-to-dma_is_consistent.patch
pass-struct-dev-pointer-to-dma_cache_sync.patch
handle-per-subsystem-mutexes-for-config_hotplug_cpu-not-set.patch
handle-per-subsystem-mutexes-for-config_hotplug_cpu-not-set-tidy.patch
dz-fixes-to-make-it-work.patch
dz-fixes-to-make-it-work-fix.patch
reiser-replace-kmallocmemset-with-kzalloc.patch
futex-init-error-check.patch
spi-check-platform_device_register_simple-error.patch
synclink_gt-fix-init-error-handling.patch
sysctl-string-length-calculated-is-wrong-if-it-contains-negative-numbers.patch
sched-correct-output-of-show_state.patch
reiserfs-do-not-add-save-links-for-o_direct-writes.patch
reiserfs-do-not-add-save-links-for-o_direct-writes-fix.patch
rtc-rs5c372-change-register-reading-method.patch
reporting-bugs-request-config-file.patch
remove-useless-carta_random32h.patch
lib-functions-always-build-hweight-for-loadable-modules.patch
jbd2-wait-for-already-submitted-t_sync_datalist-buffer.patch
ext4-balloc-reset-windowsz-when-full.patch
ext4-balloc-fix-off-by-one-against-grp_goal.patch
ext4-balloc-fix-off-by-one-against-rsv_end.patch
ext4-balloc-say-rb_entry-not-list_entry.patch
ext4-balloc-use-io_error-label.patch
ext4-balloc-fix-_with_rsv-freeze.patch
better-config_w1_slave_ds2433_crc-handling.patch
lockdep-more-chains.patch
lockdep-show-more-details-about-self-test-failures.patch
ide_scsi-allow-it-to-be-used-for-non-cd-only.patch
ide_scsi-allow-it-to-be-used-for-non-cd-only-fix.patch
make-8250_pnp-serial-driver-work-after.patch
make-8250_pnp-serial-driver-work-after-tidy.patch
maintainers-update-the-i2c-and-hwmon-subsystems-info.patch
autofs-fix-error-code-path-in-autofs_fill_sb.patch
autofs-fix-error-code-path-in-autofs_fill_sb-fix.patch
doc-atomic_add_unless-doesnt-imply-mb-on-failure.patch
softirq-remove-bug_ons-which-can-incorrectly-trigger.patch
rtc-ds1743-support.patch
char-ip2-remove-broken-macro.patch
save-some-bytes-in-struct-inode.patch
winbond-ide-depends-on-idedma.patch
readme-updated.patch
amba-pl010-clear-error-flags-on-rx-error.patch
gcc-4-1-0-is-bust.patch
fs-sysv-doc-cleanup.patch
proper-prototype-for-remove_inode_dquot_ref.patch
remove-drivers-char-riscom8cbaud_table.patch
arch-i386-kernel-rebootc-should-include-linux-rebooth.patch
trivial-cleanup-in-the-pci-ids-for-the-cs5535.patch
fs-ufs-add-missing-bracket.patch
m68knommu-scatterlist-add-missing-bracket.patch
fs-reiserfs-add-missing-brackets.patch
kbuild-add-3-more-header-files-to-get-properly-unifdefed.patch
ext3-4-dont-do-orphan-processing-on-readonly-devices.patch
remove-export_unused_symboled-symbols.patch
fs-remove-unused-variable.patch
sys-remove-unused-variable.patch
add-sparse-annotations-to-srcu-wrapper-functions-in-rcutorture.patch
new-updated-devicestxt-lanana.patch
include-asm-cris-extern-inline-static-inline.patch
include-asm-h8300-extern-inline-static-inline.patch
include-asm-powerpc-extern-inline-static-inline.patch
remove-nfsd_optimize_space.patch
generic-hdlc-synclink-config-mismatch-fix.patch
maintainers-remove-the-non-existing-sun3-list.patch
futex-remove-unneeded-barrier.patch
cleanup-include-asm-generic-atomich.patch
paride-remove-parport-ifdefs.patch
remove-drivers-block-paride-jumbo.patch
affs-replace-kmallocmemset-with-kzalloc.patch
arm26-replace-kmallocmemset-with-kzalloc.patch
jffs-replace-kmallocmemset-with-kzalloc.patch
struct-seq_operations-and-struct-file_operations-constification.patch
struct-seq_operations-and-struct-file_operations-constification-fix.patch
struct-seq_operations-and-struct-file_operations-constification-fix-2.patch
fs-make-nls_cp936c-handle-some-u00xy-characters-and-u20ac.patch
cleanup-asm-setuph-userspace-visibility-v2.patch
do_coredump-and-not-stopping-rewrite-attacks.patch
kexec--kdump-unify-elf-note-code.patch
enable-raid-autorun-on-mac-partition-tables.patch
aio-kill-pointless-ki_nbytes-assignment-in-aio_setup_single_vector.patch
aio-remove-ki_retried-debugging-member.patch
ext4-fix-credit-calculation-in-ext4_ext_calc_credits_for_insert.patch
update-ext-mailing-list-address.patch
update-ext-mailing-list-address-fix.patch

Misc. Shall merge, subject to re-review.

ipmi-fix-device-model-name.patch
ipmi-remove-interface-number-limits.patch
ipmi-pass-sysfs-name-from-lower-level-driver.patch
ipmi-allow-hot-system-interface-remove.patch
ipmi-add-maintenance-mode.patch
ipmi-fix-request-events.patch
ipmi-add-poll-delay.patch
ipmi-system-interface-hotplug.patch
ipmi-add-pigeonpoint-poweroff.patch
ipmi-fix-pci-warning.patch
ipmi-fix-bt-long-busy.patch
ipmi-increase-kcs-message-size.patch
ipmi-fix-proc_fs=n-warnings.patch

Shall merge

jbd-wait-for-already-submitted-t_sync_datalist-buffer.patch
ext3-balloc-reset-windowsz-when-full.patch
ext3-balloc-fix-off-by-one-against-grp_goal.patch
ext3-balloc-fix-off-by-one-against-rsv_end.patch
ext3-balloc-say-rb_entry-not-list_entry.patch
ext3-balloc-use-io_error-label.patch
ext3-balloc-fix-_with_rsv-freeze.patch

Shall merge.

io-accounting-core-statistics.patch
clean-up-__set_page_dirty_nobuffers.patch
io-accounting-write-accounting.patch
io-accounting-write-cancel-accounting.patch
io-accounting-read-accounting-2.patch
io-accounting-read-accounting-nfs-fix.patch
io-accounting-read-accounting-nfs-fix-fix.patch
io-accounting-read-accounting-cifs-fix.patch
io-accounting-direct-io.patch
io-accounting-report-in-procfs.patch
cleanup-taskstatsh.patch
io-accounting-via-taskstats.patch
getdelays-various-fixes.patch
io-accounting-add-to-getdelays.patch

I need to get these sent out for proper review. Shall merge, all being well.

move-page-writeback-acounting-out-of-macros.patch
per-backing_dev-dirty-and-writeback-page-accounting.patch

This is some stuff I'm working on to address writeback latency problems.
Not ready yet.

ext2-reservations.patch
ext2-fix-reservation-extension.patch
make-ext2_get_blocks-static.patch
ext2-balloc-fix-_with_rsv-freeze.patch
ext2-balloc-reset-windowsz-when-full.patch
ext2-balloc-fix-off-by-one-against-rsv_end.patch
ext2-balloc-fix-off-by-one-against-grp_goal.patch
ext2-balloc-say-rb_entry-not-list_entry.patch
ext2-balloc-use-io_error-label.patch

Not for 2.6.20. In fact it's unclear whether this should ever be merged -
ext2 is more an "example filesytem" nowadays. We'll see.

ext4-if-expression-format.patch
ext4-kmalloc-to-kzalloc.patch
ext4-eliminate-inline-functions.patch

ext4 maintenance. Shall merge.

tty-signal-tty-locking.patch
tty-signal-tty-locking-3270-fix.patch
do_task_stat-dont-take-tty_mutex.patch
do_acct_process-dont-take-tty_mutex.patch
trivial-make-set_special_pids-static.patch
sys_unshare-remove-a-broken-clone_sighand-code.patch

tty rework - shall merge

pktcdvd-reusability-of-procfs-functions.patch
pktcdvd-make-procfs-interface-optional.patch
pktcdvd-bio-write-congestion-using-blk_congestion_wait.patch
pktcdvd-bio-write-congestion-using-blk_congestion_wait-fix.patch
pktcdvd-add-sysfs-and-debugfs-interface.patch

Shall merge

remove-the-old-bd_mutex-lockdep-annotation.patch
new-bd_mutex-lockdep-annotation.patch
remove-lock_key-approach-to-managing-nested-bd_mutex-locks.patch
simplify-some-aspects-of-bd_mutex-nesting.patch
use-mutex_lock_nested-for-bd_mutex-to-avoid-lockdep-warning.patch
avoid-lockdep-warning-in-md.patch
bdev-fix-bd_part_count-leak.patch

Shall merge.

generic-bug-implementation.patch
generic-bug-implementation-handle-bug=n.patch
generic-bug-implementation-include-linux-bugh-must-always-include-linux-moduleh.patch
generic-bug-for-i386.patch
generic-bug-for-x86-64.patch
uml-add-generic-bug-support.patch
use-generic-bug-for-ppc.patch
fix-generic-warn_on-message.patch

Shall merge.

#generic-bug-for-powerpc.patch
#generic-bug-for-powerpc-fix.patch

Shall then send these to the powerpc guys to look at - it crashes for me.

bit-revese-library.patch
crc32-replace-bitreverse-by-bitrev32.patch
video-use-bitrev8.patch
net-use-bitrev8.patch
net-use-bitrev8-tidy.patch
isdn-hisax-use-bitrev8.patch
atm-ambassador-use-bitrev8.patch
isdn-gigaset-use-bitrev8.patch

Shall merge.

fsstack-introduce-fsstack_copy_attrinode_.patch
fsstack-introduce-fsstack_copy_attrinode_-tidy.patch
fsstack-introduce-fsstack_copy_attrinode_-fs-stackc-should-include-linux-fs_stackh.patch
ecryptfs-use-fsstacks-generic-copy-inode-attr.patch
ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix.patch
ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix-fix.patch
struct-path-rename-reiserfss-struct-path.patch
struct-path-rename-dms-struct-path.patch
struct-path-move-struct-path-from-fs-nameic-into.patch
struct-path-make-ecryptfs-a-user-of-struct-path.patch
vfs-change-struct-file-to-use-struct-path.patch
sysfs-change-uses-of-f_dentry.patch
proc-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ext2-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ext3-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ext4-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
fat-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
isofs-change-uses-of-f_dentry.patch
nfs-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
nfsd-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ntfs-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
i386-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
x86_64-change-uses-of-f_dentry.patch
kernel-change-uses-of-f_dentry.patch
mm-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
9p-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
affs-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
autofs-change-uses-of-f_dentry.patch
autofs4-change-uses-of-f_dentry.patch
configfs-change-uses-of-f_dentry.patch
cifs-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ecryptfs-change-uses-of-f_dentry.patch
xfs-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
struct-path-convert-adfs.patch
struct-path-convert-afs.patch
struct-path-convert-alpha.patch
struct-path-convert-atm.patch
struct-path-convert-befs.patch
struct-path-convert-bfs.patch
struct-path-convert-block.patch
struct-path-convert-block_drivers.patch
struct-path-convert-char-drivers.patch
struct-path-convert-coda.patch
struct-path-convert-cosa.patch
struct-path-convert-cramfs.patch
struct-path-convert-cris.patch
struct-path-convert-drm.patch
struct-path-convert-efs.patch
struct-path-convert-freevxfs.patch
struct-path-convert-frv.patch
struct-path-convert-fuse.patch
struct-path-convert-gfs2.patch
struct-path-convert-hfs.patch
struct-path-convert-hfsplus.patch
struct-path-convert-hostfs.patch
struct-path-convert-hpfs.patch
struct-path-convert-hppfs.patch
struct-path-convert-hugetlbfs.patch
struct-path-convert-i2c-drivers.patch
struct-path-convert-ia64.patch
struct-path-convert-ieee1394.patch
struct-path-convert-infiniband.patch
struct-path-convert-ipc.patch
struct-path-convert-ipmi.patch
struct-path-convert-isapnp.patch
struct-path-convert-isdn.patch
struct-path-convert-ixj.patch
struct-path-convert-jffs.patch
struct-path-convert-jffs2.patch
struct-path-convert-jfs.patch
struct-path-convert-kernel.patch
struct-path-convert-lockd.patch
struct-path-convert-md.patch
struct-path-convert-minix.patch
struct-path-convert-mips.patch
struct-path-convert-mm.patch
struct-path-convert-nbd.patch
struct-path-convert-ncpfs.patch
struct-path-convert-net.patch
struct-path-convert-netfilter.patch
struct-path-convert-netlink.patch
struct-path-convert-ocfs2.patch
struct-path-convert-openpromfs.patch
struct-path-convert-oprofile.patch
struct-path-convert-parisc.patch
struct-path-convert-pci.patch
struct-path-convert-pcmcia.patch
struct-path-convert-powerpc.patch
struct-path-convert-ppc.patch
struct-path-convert-qnx4.patch
struct-path-convert-ramfs.patch
struct-path-convert-reiserfs.patch
struct-path-convert-romfs.patch
struct-path-convert-s390-drivers.patch
struct-path-convert-s390.patch
struct-path-convert-sbus.patch
struct-path-convert-scsi.patch
struct-path-convert-selinux.patch
struct-path-convert-sh.patch
struct-path-convert-smbfs.patch
struct-path-convert-sound.patch
struct-path-convert-sparc.patch
struct-path-convert-sparc64.patch
struct-path-convert-sunrpc.patch
struct-path-convert-sysv.patch
struct-path-convert-udf.patch
struct-path-convert-ufs.patch
struct-path-convert-unix.patch
struct-path-convert-usb.patch
struct-path-convert-v4l.patch
struct-path-convert-video.patch
struct-path-convert-zorro.patch

Shall merge. I guess. Doesn't seem very useful.

log2-implement-a-general-integer-log2-facility-in-the-kernel.patch
log2-implement-a-general-integer-log2-facility-in-the-kernel-fix.patch
log2-implement-a-general-integer-log2-facility-in-the-kernel-vs-git-cryptodev.patch
log2-implement-a-general-integer-log2-facility-in-the-kernel-ppc-fix.patch
log2-alter-roundup_pow_of_two-so-that-it-can-use-a-ilog2-on-a-constant.patch
log2-alter-get_order-so-that-it-can-make-use-of-ilog2-on-a-constant.patch
log2-provide-ilog2-fallbacks-for-powerpc.patch

Shall merge.

add-process_session-helper-routine.patch
add-process_session-helper-routine-deprecate-old-field.patch
add-process_session-helper-routine-deprecate-old-field-tidy.patch
add-process_session-helper-routine-deprecate-old-field-fix-warnings.patch
add-process_session-helper-routine-deprecate-old-field-fix-warnings-2.patch
add-process_session-helper-routine-deprecate-old-field-fix-warnings-fix.patch
rename-struct-namespace-to-struct-mnt_namespace.patch
add-an-identifier-to-nsproxy.patch
rename-struct-pspace-to-struct-pid_namespace.patch
add-pid_namespace-to-nsproxy.patch
use-current-nsproxy-pid_ns.patch
add-child-reaper-to-pid_namespace.patch
sys_setpgid-eliminate-unnecessary-do_each_task_pidpidtype_pgid.patch
session_of_pgrp-kill-unnecessary-do_each_task_pidpidtype_pgid.patch

Shall merge.

generic-ioremap_page_range-mips-conversion.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

Shall merge.

mxser-correct-tty-driver-name.patch
pci-mxser-pci-refcounts.patch
mxser-make-an-experimental-clone.patch
mxser-session-warning-fix.patch
char-mxser_new-correct-include-file.patch
char-mxser_new-upgrade-to-191.patch
char-mxser_new-rework-to-allow-dynamic-structs.patch
char-mxser_new-use-__devinit-macros.patch
char-mxser_new-pci_request_region-for-pci-regions.patch
char-mxser_new-check-request_region-retvals.patch
char-mxser_new-kill-unneeded-memsets.patch
char-mxser_new-revert-spin_lock-changes.patch
char-mxser_new-remove-request-for-testers-line.patch
char-mxser_new-debug-printk-dependent-on-debug.patch
char-mxser_new-alter-license-terms.patch
char-mxser_new-code-upside-down.patch
char-mxser_new-cmspar-is-defined.patch
char-remove-unneded-termbits-redefinitions-mxser_new.patch
char-mxser_new-eliminate-tty-ldisc-deref.patch
char-mxser_new-testbit-for-bit-testing.patch
char-mxser_new-correct-fail-paths.patch
char-mxser_new-dont-check-tty_unregister-retval.patch
char-mxser_new-compress-isa-finding.patch
char-mxser_new-register-tty-devices-on-the-fly.patch
char-mxser_new-compact-structures-round2.patch
char-mxser_new-reverse-if-else-paths-patch.patch
char-mxser_new-comments-cleanup.patch
char-mxser_new-correct-intr-handler-proto.patch
char-mxser_new-delete-ttys-and-termios.patch
char-mxser_new-pci-probing.patch
char-mxser_new-clean-macros.patch
maintainers-add-me-to-isicom-mxser.patch
mxser_new-correct-tty-driver-name.patch
char-stallion-use-pr_debug-macro.patch
char-stallion-remove-unneeded-casts.patch
char-stallion-kill-typedefs.patch
char-stallion-move-init-deinit.patch
char-stallion-uninline-functions.patch
char-stallion-mark-functions-as-init.patch
char-stallion-remove-many-prototypes.patch

Shall merge.

tty-preparatory-structures-for-termios-revamp.patch
tty-preparatory-structures-for-termios-revamp-strip-fix.patch
tty-switch-to-ktermios-and-new-framework.patch
tty-switch-to-ktermios-and-new-framework-warning-fix.patch
tty-switch-to-ktermios-and-new-framework-irda-fix.patch
tty-switch-to-ktermios.patch
tty-switch-to-ktermios-nozomi-fix.patch
tty-switch-to-ktermios-bluetooth-fix.patch
tty-switch-to-ktermios-sclp-fix.patch
tty-switch-to-ktermios-3270-fix.patch
tty-switch-to-ktermios-powerpc-fix.patch
tty-switch-to-ktermios-uml-fix.patch
tty-switch-to-ktermios-uml-fix-2.patch
tty_ioctl-use-termios-for-the-old-structure-and-termios2.patch
tty_ioctl-use-termios-for-the-old-structure-and-termios2-fix.patch
tty_ioctl-use-termios-for-the-old-structure-and-termios2-update.patch
termios-enable-new-style-termios-ioctls-on-x86-64.patch

termios -> ktermios work. Shall merge.

char-isicom-expand-function.patch
char-isicom-rename-init-function.patch
char-isicom-remove-isa-code.patch
char-isicom-remove-unneeded-memset.patch
char-isicom-move-to-tty_register_device.patch
char-isicom-use-pci_request_region.patch
char-isicom-check-kmalloc-retval.patch
char-isicom-use-completion.patch
char-isicom-simplify-timer.patch
char-isicom-remove-cvs-stuff.patch
char-isicom-fix-tty-index-check.patch
char-sx-convert-to-pci-probing.patch
char-sx-use-kcalloc.patch
char-sx-mark-functions-as-devinit.patch
char-sx-use-eisa-probing.patch
char-sx-ifdef-isa-code.patch
char-sx-lock-boards-struct.patch
char-sx-remove-duplicite-code.patch
char-sx-whitespace-cleanup.patch
char-sx-simplify-timer-logic.patch
char-sx-fix-return-in-module-init.patch
char-sx-use-pci_iomap.patch
char-sx-request-regions.patch
char-stallion-convert-to-pci-probing.patch
char-stallion-prints-cleanup.patch
char-stallion-implement-fail-paths.patch
char-stallion-correct-__init-macros.patch
char-stallion-functions-cleanup.patch
char-stallion-fix-fail-paths.patch
char-stallion-brd-struct-locking.patch
char-stallion-remove-syntactic-sugar.patch
char-stallion-variables-cleanup.patch
char-stallion-use-dynamic-dev.patch
char-istallion-convert-to-pci-probing.patch
char-istallion-remove-the-mess.patch
char-istallion-eliminate-typedefs.patch
char-istallion-variables-cleanup.patch
char-istallion-ifdef-eisa-code.patch
char-istallion-brdnr-locking.patch
char-istallion-free-only-isa.patch
char-istallion-correct-fail-paths.patch
char-istallion-fix-enabling.patch
char-istallion-move-init-and-exit-code.patch
char-istallion-change-init-sequence.patch
char-istallion-dynamic-tty-device.patch
char-istallion-use-mod_timer.patch
char-cyclades-save-indent-levels.patch
char-cyclades-lindent-the-code.patch
char-cyclades-cleanup.patch
char-cyclades-fix-warnings.patch

Shall merge.

drivers-isdn-handcrafted-min-max-macro-removal.patch
drivers-isdn-handcrafted-min-max-macro-removal-fix.patch
isdn-fix-missing-unregister_capi_driver.patch
isdn-avoid-a-potential-null-ptr-deref-in-ippp.patch
drivers-isdn-trivial-vsnprintf-conversion.patch
isdn-replace-kmallocmemset-with-kzalloc.patch
i4l-remove-the-broken-hisax_amd7930-option.patch
isdn-fix-warnings.patch

ISDN. Shall merge.

lockdep-annotate-nfsd4-recover-code.patch
nfs2-calculate-w-a-bit-later-in-nfsaclsvc_encode_getaclres.patch
nfs3-calculate-w-a-bit-later-in-nfs3svc_encode_getaclres.patch
nfsd-replace-kmallocmemset-with-kcalloc.patch

nfsd - shall merge.

fault-injection-documentation-and-scripts.patch
fault-injection-capabilities-infrastructure.patch
fault-injection-capabilities-infrastructure-tidy.patch
fault-injection-capabilities-infrastructure-tweaks.patch
fault-injection-capability-for-kmalloc.patch
fault-injection-capability-for-kmalloc-failslab-remove-__gfp_highmem-filtering.patch
fault-injection-capability-for-alloc_pages.patch
fault-injection-capability-for-disk-io.patch
fault-injection-process-filtering-for-fault-injection-capabilities.patch
fault-injection-stacktrace-filtering.patch
fault-injection-stacktrace-filtering-reject-failure-if-any-caller-lies-within-specified-range.patch
fault-injection-Kconfig-cleanup.patch
fault-injection-stacktrace-filtering-kconfig-fix.patch
fault-injection-Kconfig-cleanup-config_fault_injection-help-text.patch

Shall merge.

schedc-correct-comment-for-this_rq_lock-routine.patch
sched-fix-migration-cost-estimator.patch
sched-domain-move-sched-group-allocations-to-percpu-area.patch
move_task_off_dead_cpu-should-be-called-with-disabled-ints.patch
sched-domain-increase-the-smt-busy-rebalance-interval.patch
#
sched-avoid-taking-rq-lock-in-wake_priority_sleeper.patch
sched-remove-staggering-of-load-balancing.patch
sched-disable-interrupts-for-locking-in-load_balance.patch
sched-extract-load-calculation-from-rebalance_tick.patch
sched-move-idle-status-calculation-into-rebalance_tick.patch
sched-use-softirq-for-load-balancing.patch
sched-call-tasklet-less-frequently.patch
sched-add-option-to-serialize-load-balancing.patch
sched-add-option-to-serialize-load-balancing-fix.patch
sched-improve-migration-accuracy.patch
sched-improve-migration-accuracy-tidy.patch
sched-improve-migration-accuracy-fix.patch
sched-decrease-number-of-load-balances.patch
#
sched-optimize-activate_task-for-rt-task.patch
kernel-schedc-whitespace-cleanups.patch
kernel-schedc-whitespace-cleanups-more.patch

CPU scheduler - shall merge subject to maintainer re-review.

sysctl-simplify-sysctl_uts_string.patch
sysctl-implement-sysctl_uts_string.patch
sysctl-simplify-ipc-ns-specific-sysctls.patch
sysctl-fix-sys_sysctl-interface-of-ipc-sysctls.patch
sysctl-fix-sys_sysctl-interface-of-ipc-sysctls-fix-2.patch

sysctl cleanup - shall merge.

readahead-kconfig-options.patch
readahead-kconfig-options-fix.patch
radixtree-introduce-scan-hole-data-functions.patch
mm-introduce-probe_page.patch
mm-introduce-pg_readahead.patch
readahead-add-look-ahead-support-to-__do_page_cache_readahead.patch
readahead-insert-cond_resched-calls.patch
readahead-minmax_ra_pages.patch
readahead-events-accounting.patch
readahead-events-accounting-make-readahead_debug_level-static.patch
readahead-rescue_pages.patch
readahead-sysctl-parameters.patch
readahead-sysctl-parameters-use-ctl_unnumbered.patch
readahead-sysctl-parameters-fix.patch
readahead-min-max-sizes.patch
readahead-state-based-method-aging-accounting.patch
readahead-state-based-method-routines.patch
readahead-state-based-method.patch
readahead-context-based-method.patch
readahead-context-based-method-locking-fix.patch
readahead-context-based-method-locking-fix-2.patch
readahead-initial-method-guiding-sizes.patch
readahead-initial-method-thrashing-guard-size.patch
readahead-initial-method-user-recommended-size.patch
readahead-initial-method.patch
readahead-backward-prefetching-method.patch
readahead-thrashing-recovery-method.patch
readahead-call-scheme.patch
readahead-call-scheme-ifdef-fix.patch
readahead-call-scheme-build-fix.patch
readahead-laptop-mode.patch
readahead-loop-case.patch
readahead-nfsd-case.patch
readahead-nfsd-case-fix.patch
readahead-nfsd-case-fix-uninitialized-ra_min-ra_max.patch
readahead-turn-on-by-default.patch
readahead-remove-size-limit-on-read_ahead_kb.patch
readahead-remove-size-limit-of-max_sectors_kb-on-read_ahead_kb.patch

Shall hold in -mm.

reiser4-sb_sync_inodes.patch
reiser4-export-remove_from_page_cache.patch
reiser4-export-remove_from_page_cache-fix.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
reiser4-configh.patch
resier4-add-include-linux-freezerh-and-move-definitions-from.patch
reiser4-reiser4_drop_page-dont-call-remove_from_page_cache.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-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-get-rid-of-semaphores-wherever-it-is-possible.patch
reiser4-decribe-new-atom-locking-and-nested-atom-locks-to-lock-validator.patch
reiser4-use-generic-file-read.patch
reiser4-use-generic-file-read-fix-readpages-unix-file.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-format-subversion-numbers-heir-set-and-file-conversion.patch
reiser4-format-subversion-numbers-heir-set-and-file-conversion-fix-readpages-cryptcompress.patch
reiser4-cleanups-in-lzo-compression-library.patch
reiser4-get-rid-of-deprecated-crypto-api.patch
reiser4-get-rid-of-deprecated-crypto-api-build-fix.patch
reiser4-fix-missed-unlock-and-exit_context.patch
reiser4-use-list_head-instead-of-struct-blocknr.patch
reiser4-use-list_empty-instead-of-list_empty_careful-for.patch
reiser4-update-comments-fix-write-and-truncate-cryptcompress.patch
reiser4-temp-fix.patch
fs-reiser4-possible-cleanups-2.patch
fs-reiser4-more-possible-cleanups.patch
reiser4-use-null-for-pointers.patch

Shall hold in -mm.

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
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
hpt3xx-init-code-rewrite.patch
jmicron-warning-fix.patch

Scary IDE changes. Shall poll Alan again.

ide-more-conversion-to-pci_get-apis.patch
pdc202xx_new-fix-pio-mode-setup.patch
ide-cd-handle-strange-interrupt-on-the-intel-esb2.patch

Shall merge.

ioremap-balanced-with-iounmap-for-drivers-video-virgefb.patch
ioremap-balanced-with-iounmap-for-drivers-video-vesafb.patch
ioremap-balanced-with-iounmap-for-drivers-video-tridentfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-tgafb.patch
ioremap-balanced-with-iounmap-for-drivers-video-stifb.patch
ioremap-balanced-with-iounmap-for-drivers-video-retz3fb.patch
ioremap-balanced-with-iounmap-for-drivers-video-pvr2fb.patch
ioremap-balanced-with-iounmap-for-drivers-video-platinumfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-offb.patch
ioremap-balanced-with-iounmap-for-drivers-video-macfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-hpfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-fm2fb.patch
ioremap-balanced-with-iounmap-for-drivers-video-ffb.patch
ioremap-balanced-with-iounmap-for-drivers-video-cyberfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-cirrusfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-atyfb_base.patch
ioremap-balanced-with-iounmap-for-drivers-video-atafb.patch
ioremap-balanced-with-iounmap-for-drivers-video-amifb.patch
ioremap-balanced-with-iounmap-for-drivers-video-S3triofb.patch
atyfb-rivafb-minor-fixes.patch
igafb-switch-to-pci_get-api.patch
video-sis-remove-unnecessary-variables-in-sis_ddc2delay.patch
pmagb-b-fb-fix-a-default-clock.patch
video-get-the-default-mode-from-the-right-database.patch
s3c2410fb-add-support-for-stn-displays.patch
fbcmapc-mark-structs-const-or.patch
various-fbdev-files-mark-structs.patch
various-fbdev-files-mark-structs-fix.patch
constify-and-annotate-__read_mostly.patch
annotate-some-variables-in-vesafb.patch
constify-vga16fbc.patch
au1100fb-fix-to-remove-flickering.patch
mbxfb-fix-hscoeff3-register-address.patch
mbxfb-add-more-registers-bits.patch
mbxfb-add-more-registers-to-debugfs.patch
mbxfb-add-yuv-video-overlay-support.patch
mbxfb-document-the-new-ioctl.patch
atyfb-remove-fixme.patch
atyfb-fix-compiler-warnings.patch
atyfb-fix-sparse-warnings.patch
atyfb-fix-blanking-level.patch
atyfb-remove-pointless-aty_init.patch
atyfb-fix-__init-and-__devinit.patch
atyfb-remove-aty_cmap_regs.patch
atyfb-improve-atyfb_atari_probe.patch
atyfb-improve-power-management.patch
drivers-video-use-kmemdup.patch
visws-sgivwfb-is-module-needs-exports.patch
backlight-lcd-remove-dependenct-from-the-framebuffer-layer.patch
backlight-lcd-remove-dependenct-from-the-framebuffer-layer-tidy.patch
softcursorc-avoid-unaligned-accesses.patch
backlight-do-not-power-off-backlight-when-unregistering-try-3.patch
fb-get-the-geode-gx-frambuffer-size-from-the-bios.patch
gxfb-fixups-for-the-amd-geode-gx.patch
gxfb-fixups-for-the-amd-geode-gx-tidy.patch
gxfb-support-flat-panel-timings.patch
gxfb-support-flat-panel-timings-tidy.patch
gxfb-support-command-line-options.patch
gxfb-support-command-line-options-tidy.patch
gxfb-fixup-flatpanel-detection.patch
gxfb-turn-on-the-flatpanel-power-and-data.patch
video-select-set-for-vesa-fb.patch
video-cyberfb-broken-macro-removal.patch
video-neofb-stray-bracket-fix.patch
video-pm3fb-macros-fix.patch

Shall merge.

dm-io-fix-bi_max_vecs.patch
dm-tidy-core-formatting.patch
dm-suspend-parameter-change.patch
dm-map-and-endio-return-code-clarification.patch
dm-map-and-endio-symbolic-return-codes.patch
dm-ioctl-add-noflush-suspend.patch
dm-suspend-add-noflush-pushback.patch
dm-mpath-use-noflush-suspending.patch
dm-snapshot-abstract-memory-release.patch
dm-log-rename-complete_resync_work.patch
dm-raid1-reset-sync_search-on-resume.patch
make-drivers-md-dm-snapcksnapd-static.patch

Shall merge.

md-tidy-up-device-change-notification-when-an-md-array-is-stopped.patch
md-define-raid5_mergeable_bvec.patch
md-handle-bypassing-the-read-cache-assuming-nothing-fails.patch
md-allow-reads-that-have-bypassed-the-cache-to-be-retried-on-failure.patch
md-allow-reads-that-have-bypassed-the-cache-to-be-retried-on-failure-fix.patch
md-allow-reads-that-have-bypassed-the-cache-to-be-retried-on-failure-misc-fixes-for-aligned-read-handling-including-raid6-read-corruption.patch
md-allow-reads-that-have-bypassed-the-cache-to-be-retried-on-failure-misc-fixes-for-error-handling-of-aligned-reads.patch
md-enable-bypassing-cache-for-reads.patch
md-fix-innocuous-bug-in-raid6-stripe_to_pdidx.patch
md-conditionalize-some-code.patch

I have a note here "The MD patches probably broke jurriaan
<[email protected]>'s setup". Need to work out whether that got resolved.

md-change-lifetime-rules-for-md-devices.patch

This caused oopses for Jiri Kosina <[email protected]>

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

Shall hold in -mm.

statistics-infrastructure-prerequisite-list.patch
statistics-infrastructure-prerequisite-parser.patch
statistics-infrastructure-prerequisite-timestamp.patch
statistics-infrastructure-make-printk_clock-a-generic-kernel-wide-nsec-resolution.patch
statistics-infrastructure-make-printk_clock-a-generic-kernel-wide-nsec-resolution-ia64-fix.patch
statistics-infrastructure-documentation.patch
statistics-infrastructure.patch
statistics-infrastructure-fix-buffer-overflow-in-histogram-with-linear.patch
statistics-infrastructure-fix-buffer-overflow-in-histogram-with-linear-tidy.patch
statistics-infrastructure-adapt-output-format-of-utilisation-indicator.patch
statistics-use-the-enhanced-percpu-interface.patch
statistics-replace-inode-ugeneric_ip-with-i_private.patch
statistics-infrastructure-exploitation-zfcp.patch
zfcp-gather-hba-specific-latencies-in-statistics.patch

Still trying to generate a case for merging this.

extend-notifier_call_chain-to-count-nr_calls-made.patch
extend-notifier_call_chain-to-count-nr_calls-made-fixes.patch
extend-notifier_call_chain-to-count-nr_calls-made-fixes-2.patch
define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release.patch
define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release-fix.patch
eliminate-lock_cpu_hotplug-in-kernel-schedc.patch
eliminate-lock_cpu_hotplug-in-kernel-schedc-fix.patch
handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch

Shall merge.

mark-pci_module_init-deprecated.patch

Send to Greg.

dio-centralize-completion-in-dio_complete.patch
dio-call-blk_run_address_space-once-per-op.patch
dio-formalize-bio-counters-as-a-dio-reference-count.patch
dio-remove-duplicate-bio-wait-code.patch
dio-only-call-aio_complete-after-returning-eiocbqueued.patch
dio-lock-refcount-operations.patch

Shall merge.

fdtable-delete-pointless-code-in-dup_fd.patch
fdtable-make-fdarray-and-fdsets-equal-in-size.patch
fdtable-remove-the-free_files-field.patch
fdtable-implement-new-pagesize-based-fdtable-allocator.patch
fdtable-implement-new-pagesize-based-fdtable-allocator-fix.patch
fdtable-implement-new-pagesize-based-fdtable-allocator-bound-minimum-allocation-size.patch
fdtable-implement-new-pagesize-based-fdtable-allocator-avoid-fdset-cacheline-ping-pong.patch

Shall merge.

gtod-exponential-update_wall_time.patch

Roman wanted this dropped, and afaik that's unresolved.

gtod-persistent-clock-support-core.patch
gtod-persistent-clock-support-core-remove-kernel-timercwall_jiffies.patch
gtod-persistent-clock-support-i386.patch
gtod-persistent-clock-support-i386-i386-unexport-read_persistent_clock.patch
time-uninline-jiffiesh.patch
time-uninline-jiffiesh-fix.patch
time-fix-msecs_to_jiffies-bug.patch
time-fix-timeout-overflow.patch
cleanup-uninline-irq_enter-and-move-it-into-a-function.patch
dynticks-extend-next_timer_interrupt-to-use-a-reference-jiffie.patch
dynticks-extend-next_timer_interrupt-to-use-a-reference-jiffie-remove-incorrect-warning-in-kernel-timerc.patch
dynticks-extend-next_timer_interrupt-to-use-a-reference-jiffie-make-kernel-timerc__next_timer_interrupt-static.patch
hrtimers-namespace-and-enum-cleanup.patch
hrtimers-clean-up-locking.patch
hrtimers-clean-up-locking-fix.patch
updated-hrtimers-state-tracking.patch
updated-hrtimers-clean-up-callback-tracking.patch
updated-hrtimers-move-and-add-documentation.patch
updated-add-a-framework-to-manage-clock-event-devices.patch
updated-acpi-include-apich.patch
updated-acpi-keep-track-of-timer-broadcast.patch
updated-acpi-add-state-propagation-for-dynamic-broadcasting.patch
updated-i386-cleanup-apic-code.patch
updated-i386-convert-to-clock-event-devices.patch
updated-i386-convert-to-clock-event-devices-fix.patch
updated-i386-convert-to-clock-event-devices-arch-i386-kernel-apicc-make-a-function-static.patch
updated-i386-convert-to-clock-event-devices-remove-arch-i386-kernel-time_hpetchpet_reenable.patch
updated-pm_timer-allow-early-access-and-move-externs-to-a-header-file.patch
updated-i386-rework-local-apic-calibration.patch
updated-high-res-timers-core.patch
updated-high-res-timers-core-high-res-timers-do-itimer-rearming-in-process-context.patch
updated-gtod-mark-tsc-unusable-for-highres-timers.patch
high-res-timers-utilize-tsc-clocksource-again.patch
high-res-timers-utilize-tsc-clocksource-again-fix.patch
updated-dynticks-core-code.patch
updated-dynticks-core-code-fix-resume-bug.patch
updated-dyntick-add-nohz-stats-to-proc-stat.patch
updated-dynticks-i386-arch-code.patch
updated-dynticks-fix-nmi-watchdog.patch
updated-high-res-timers-dynticks-enable-i386-support.patch
updated-debugging-feature-timer-stats.patch

Shall merge, I guess. My confidence is low, but it's Kconfigurable and it
needs to get sorted out.

clockevents-core-check-for-clock-event-device-handler-being-non-null-before-calling-it.patch
round_jiffies-infrastructure.patch
round_jiffies-infrastructure-fix.patch
user-of-the-jiffies-rounding-patch-ata-subsystem.patch
user-of-the-jiffies-rounding-code-jbd.patch
user-of-the-jiffies-rounding-code-networking.patch
user-of-the-jiffies-rounding-patch-slab.patch
clocksource-add-usage-of-config_sysfs.patch
clocksource-small-cleanup-2.patch
clocksource-small-cleanup-2-fix.patch
clocksource-small-acpi_pm-cleanup.patch

Shall merge.

kvm-userspace-interface.patch
kvm-userspace-interface-make-enum-values-in-userspace-interface-explicit.patch
kvm-intel-virtual-mode-extensions-definitions.patch
kvm-kvm-data-structures.patch
kvm-random-accessors-and-constants.patch
kvm-virtualization-infrastructure.patch
kvm-virtualization-infrastructure-kvm-fix-guest-cr4-corruption.patch
kvm-virtualization-infrastructure-include-desch.patch
kvm-virtualization-infrastructure-fix-segment-state-changes-across-processor-mode-switches.patch
kvm-virtualization-infrastructure-fix-asm-constraints-for-segment-loads.patch
kvm-virtualization-infrastructure-fix-mmu-reset-locking-when-setting-cr0.patch
kvm-memory-slot-management.patch
kvm-memory-slot-management-zero-guest-memory-before-use.patch
kvm-vcpu-creation-and-maintenance.patch
kvm-vcpu-creation-and-maintenance-segment-access-cleanup.patch
kvm-workaround-cr0cd-cache-disable-bit-leak-from-guest-to.patch
kvm-vcpu-execution-loop.patch
kvm-define-exit-handlers.patch
kvm-define-exit-handlers-pass-fs-gs-segment-bases-to-x86-emulator.patch
kvm-less-common-exit-handlers.patch
kvm-less-common-exit-handlers-handle-rdmsrmsr_efer.patch
kvm-mmu.patch
kvm-mmu-mmu-honor-global-bit-on-huge-pages.patch
kvm-x86-emulator.patch
kvm-x86-emulator-x86-emulator-handle-smsw.patch
kvm-clarify-licensing.patch
kvm-x86-emulator-fix-emulator-mov-cr-decoding.patch
kvm-plumbing.patch
kvm-dynamically-determine-which-msrs-to-load-and-save.patch
kvm-fix-calculation-of-initial-value-of-rdx-register.patch
kvm-avoid-using-vmx-instruction-directly.patch
kvm-avoid-using-vmx-instruction-directly-fix-asm-constraints.patch
kvm-expose-interrupt-bitmap.patch
kvm-add-time-stamp-counter-msr-and-accessors.patch
kvm-expose-msrs-to-userspace.patch
kvm-expose-msrs-to-userspace-v2.patch
kvm-create-kvm-intelko-module.patch
kvm-make-dev-registration-happen-when-the-arch.patch
kvm-make-hardware-detection-an-arch-operation.patch
kvm-make-the-per-cpu-enable-disable-functions-arch.patch
kvm-make-the-hardware-setup-operations-non-percpu.patch
kvm-make-the-guest-debugger-an-arch-operation.patch
kvm-make-msr-accessors-arch-operations.patch
kvm-make-the-segment-accessors-arch-operations.patch
kvm-cache-guest-cr4-in-vcpu-structure.patch
kvm-cache-guest-cr0-in-vcpu-structure.patch
kvm-add-get_segment_base-arch-accessor.patch
kvm-add-idt-and-gdt-descriptor-accessors.patch
kvm-make-syncing-the-register-file-to-the-vcpu.patch
kvm-make-the-vcpu-execution-loop-an-arch-operation.patch
kvm-make-the-vcpu-execution-loop-an-arch-operation-build-fix.patch
kvm-move-the-vmx-exit-handlers-to-vmxc.patch
kvm-make-vcpu_setup-an-arch-operation.patch
kvm-make-__set_cr0-and-dependencies-arch-operations.patch
kvm-make-__set_cr4-an-arch-operation.patch
kvm-make-__set_efer-an-arch-operation.patch
kvm-make-__set_efer-an-arch-operation-build-fix.patch
kvm-make-set_cr3-and-tlb-flushing-arch-operations.patch
kvm-make-inject_page_fault-an-arch-operation.patch
kvm-make-inject_gp-an-arch-operation.patch
kvm-use-the-idt-and-gdt-accessors-in-realmode-emulation.patch
kvm-use-the-general-purpose-register-accessors-rather.patch
kvm-move-the-vmx-tsc-accessors-to-vmxc.patch
kvm-access-rflags-through-an-arch-operation.patch
kvm-move-the-vmx-segment-field-definitions-to-vmxc.patch
kvm-add-an-arch-accessor-for-cs-d-b-and-l-bits.patch
kvm-add-a-set_cr0_no_modeswitch-arch-accessor.patch
kvm-make-vcpu_load-and-vcpu_put-arch-operations.patch
kvm-make-vcpu-creation-and-destruction-arch-operations.patch
kvm-move-vmcs-static-variables-to-vmxc.patch
kvm-make-is_long_mode-an-arch-operation.patch
kvm-use-the-tlb-flush-arch-operation-instead-of-an.patch
kvm-remove-guest_cpl.patch
kvm-move-vmcs-accessors-to-vmxc.patch
kvm-move-vmx-helper-inlines-to-vmxc.patch
kvm-remove-vmx-includes-from-arch-independent-code.patch
kvm-amd-svm-add-architecture-definitions-for-amd-svm.patch
kvm-amd-svm-enhance-x86-emulator.patch
kvm-amd-svm-enhance-x86-emulator-fix-mov-to-from-control-register-emulation.patch
kvm-amd-svm-add-missing-tlb-flushes-to-the-guest-mmu.patch
kvm-amd-svm-add-data-structures.patch
kvm-amd-svm-implementation.patch
kvm-amd-svm-implementation-avoid-three-more-new-instructions.patch
kvm-amd-svm-implementation-more-i386-fixes.patch
kvm-amd-svm-implementation-printk-log-levels.patch
kvm-amd-svm-plumbing.patch
kvm-fix-null-and-c99-init-sparse-warnings.patch
kvm-load-i386-segment-bases.patch

Shall fold into a single patch and merge it.

mprotect-patch-for-use-by-slim.patch
integrity-service-api-and-dummy-provider.patch
integrity-service-api-and-dummy-provider-cleanup-use-of-configh.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-main-patch-misc-cleanups-requested-at-inclusion-time.patch
slim-main-patch-handle-failure-to-register.patch
slim-main-patch-fix-bug-with-mm_users-usage.patch
slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch
slim-secfs-patch.patch
slim-secfs-patch-slim-correct-use-of-snprintf.patch
slim-secfs-patch-cleanup-use-of-configh.patch
slim-make-and-config-stuff.patch
slim-make-and-config-stuff-makefile-fix.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
fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch

Shall hold in -mm.



2006-12-05 04:57:01

by Jeff Garzik

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Andrew Morton wrote:
> via-pata-controller-xfer-fixes.patch
> via-pata-controller-xfer-fixes-fix.patch

Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
reporter as fixing things, so these two shouldn't be needed.


> libata_resume_fix.patch

I thought this was resolved long ago? Are there still open reports that
this solves, where upstream doesn't work?


> ahci-ati-sb600-sata-support-for-various-modes.patch

With the PCI quirk, I thought ATI was finally sorted?

Jeff


2006-12-05 05:32:33

by Paul Mackerras

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Andrew Morton writes:

> ppc-m48t35-add-missing-bracket.patch
> powerpc-replace-kmallocmemset-with-kzalloc.patch

These are already in Linus' tree.

> Am holding onto these until the powerpc git tree gets un-messied up.

It should be fine now. Linus has pulled it, so there are currently no
changes in powerpc.git relative to Linus' tree.

> radix-tree-rcu-lockless-readside.patch
>
> There's no reason to merge this yet.

We want to use it in some powerpc arch code. Currently we use a
per-cpu array of spinlocks, and this patch would let us get rid of
that array.

Paul.

2006-12-05 05:41:33

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Mon, 04 Dec 2006 23:56:42 -0500
Jeff Garzik <[email protected]> wrote:

> Andrew Morton wrote:
> > via-pata-controller-xfer-fixes.patch
> > via-pata-controller-xfer-fixes-fix.patch
>
> Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
> reporter as fixing things, so these two shouldn't be needed.

OK thanks, I dropped it.

>
> > libata_resume_fix.patch
>
> I thought this was resolved long ago? Are there still open reports that
> this solves, where upstream doesn't work?

Heck, I don't know.

>
> > ahci-ati-sb600-sata-support-for-various-modes.patch
>
> With the PCI quirk, I thought ATI was finally sorted?

Was it? I don't know that either.

I'll drop these too.

2006-12-05 05:42:41

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Tue, 5 Dec 2006 16:14:03 +1100
Paul Mackerras <[email protected]> wrote:

> > radix-tree-rcu-lockless-readside.patch
> >
> > There's no reason to merge this yet.
>
> We want to use it in some powerpc arch code. Currently we use a
> per-cpu array of spinlocks, and this patch would let us get rid of
> that array.

ok, let's merge it then.

2006-12-05 05:50:40

by Nick Piggin

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Paul Mackerras wrote:
> Andrew Morton writes:

>>radix-tree-rcu-lockless-readside.patch
>>
>> There's no reason to merge this yet.
>
>
> We want to use it in some powerpc arch code. Currently we use a
> per-cpu array of spinlocks, and this patch would let us get rid of
> that array.

I'd like to get another patch in here before going upstream if possible.
It is not a correctness fix, but it is a bit of a rework.

I also wouldn't mind getting the readahead path, if not the full
pagecache readside, out from under tree_lock in -mm kernels to exercise
the radix-tree concurrency a bit more.

It's just been painfully slow, recently because of these more important
buffered write vs deadlock and pagefault vs invalidate problems that
I've been working on. I don't feel I can load up -mm with too much
unrelated stuff that messes with mm/pagecache internals.

I guess the per-cpu spinlocks are pretty reasonable for scalability,
and you are mainly looking to eliminate the lock/unlock cost in your
interrupt path?

Nick

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com

2006-12-05 05:54:39

by Nick Piggin

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Andrew Morton wrote:
> On Tue, 5 Dec 2006 16:14:03 +1100
> Paul Mackerras <[email protected]> wrote:
>
>
>>>radix-tree-rcu-lockless-readside.patch
>>>
>>> There's no reason to merge this yet.
>>
>>We want to use it in some powerpc arch code. Currently we use a
>>per-cpu array of spinlocks, and this patch would let us get rid of
>>that array.
>
>
> ok, let's merge it then.

Well that wasn't as hard as I thought ;) No arguments from me!

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com

2006-12-05 07:04:08

by Jens Axboe

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Mon, Dec 04 2006, Andrew Morton wrote:
> >
> > > libata_resume_fix.patch
> >
> > I thought this was resolved long ago? Are there still open reports that
> > this solves, where upstream doesn't work?
>
> Heck, I don't know.

I'm not aware of any, and resume works for me. Did that patch ever get
verified as fixing something for anybody? I think it can be safely
dropped.

--
Jens Axboe

Subject: Re: -mm merge plans for 2.6.20

Hi Andrew,

> remove-hotplug-cpu-crap-from-cpufreq.patch
>
> Sent to cpufreq maintainer

I suspect that Davej posted this patch because he was getting lockdep
warnings-reports from people complaining of ondemand-governor
performing spurious unlock_cpu_hotplug.
That problem has been fixed in the mainline by the commit
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4b96b1a10cb00c867103b21f0f2a6c91b705db11

If there are any other issues with cpufreq-cpuhotplug in the mainline,
I'm more than willing to help out fix them. As of now, I cannot seem
to spot anything serious in the mainline as such.
Hence, merging this isn't an immediate need IMHO.

> hotplug-cpu-clean-up-hotcpu_notifier-use.patch
> hotplug-cpu-clean-up-hotcpu_notifier-use-vs-gregkh-driver-cpu-topology-consider-sysfs_create_group-return-value.patch

>
> extend-notifier_call_chain-to-count-nr_calls-made.patch
> extend-notifier_call_chain-to-count-nr_calls-made-fixes.patch
> extend-notifier_call_chain-to-count-nr_calls-made-fixes-2.patch
> define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release.patch
> define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release-fix.patch
> eliminate-lock_cpu_hotplug-in-kernel-schedc.patch
> eliminate-lock_cpu_hotplug-in-kernel-schedc-fix.patch
> handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch
>
> Shall merge.
>

Merging this would still give the circular-locking dependency warnings
which I posted the other day. Unless we have a clean way to get
cpu-hotplug-protection for cpufreq, I don't see a point in merging this
stuff.

Cpufreq hotplug-interactions can be sorted out.
I have a few patches which I need to test out before posting them.

Other than that, there are issues regarding the
workqueue-hotplug-"locking" which needs to be addressed,
probably in a seperate thread.

So could you please reconsider this decision to merge the
hotplug-locking rework, and let it stabilize in -mm for sometime ?

Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"

2006-12-05 08:55:23

by Peter Zijlstra

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


> mm-call-into-direct-reclaim-without-pf_memalloc-set.patch
> mm-cleanup-and-document-reclaim-recursion.patch

Drop these, I'm not sure of them anymore. And I am starting to grow a
nagging feeling they are wrong.


2006-12-05 11:06:24

by Pavel Machek

[permalink] [raw]
Subject: ext2 future [was Re: -mm merge plans for 2.6.20]

Hi!


> ext2-reservations.patch
> ext2-fix-reservation-extension.patch
> make-ext2_get_blocks-static.patch
> ext2-balloc-fix-_with_rsv-freeze.patch
> ext2-balloc-reset-windowsz-when-full.patch
> ext2-balloc-fix-off-by-one-against-rsv_end.patch
> ext2-balloc-fix-off-by-one-against-grp_goal.patch
> ext2-balloc-say-rb_entry-not-list_entry.patch
> ext2-balloc-use-io_error-label.patch
>
> Not for 2.6.20. In fact it's unclear whether this should ever be merged -
> ext2 is more an "example filesytem" nowadays. We'll see.

If ext2 is "example filesystem"... perhaps we should add "no journal"
mode to ext3 or something? We still want high-performance,
not-journalled filesystem, I believe.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2006-12-05 13:23:40

by John W. Linville

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:

> hostap-replace-kmallocmemset-with-kzalloc.patch
> prism54-replace-kmallocmemset-with-kzalloc.patch
> ipw2200-replace-kmallocmemset-with-kcalloc.patch
> softmac-fix-unbalanced-mutex_lock-unlock-in-ieee80211softmac_wx_set_mlme.patch
>
> Not sent to John - I forgot.

I've got them, and I plan to merge them.

Thanks,

John
--
John W. Linville
[email protected]

2006-12-05 14:27:42

by Roman Zippel

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Hi,

On Mon, 4 Dec 2006, Andrew Morton wrote:

> kbuild-dont-put-temp-files-in-the-source-tree.patch
> actually-delete-the-as-instr-ld-option-tmp-file.patch

Andi had objections about the mktemp usage and I agree with him.
The proposed patch in bugzilla didn't have this and no further
justification was given for why it's needed.
Below is a replacement patch with some improvements:
- kbuild doesn't use $(AS), so use $(CC)
- tmp dir needs only to be calculated once
- reformat a bit to keep it under 80 columns and to be more readable

bye, Roman

Signed-off-by: Roman Zippel <[email protected]>

---
scripts/Kbuild.include | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)

Index: linux-2.6-git/scripts/Kbuild.include
===================================================================
--- linux-2.6-git.orig/scripts/Kbuild.include 2006-12-05 13:44:50.000000000 +0100
+++ linux-2.6-git/scripts/Kbuild.include 2006-12-05 15:09:09.000000000 +0100
@@ -56,6 +56,9 @@ endef
# gcc support functions
# See documentation in Documentation/kbuild/makefiles.txt

+# output directory for tests below
+TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/)
+
# as-option
# Usage: cflags-y += $(call as-option, -Wa$(comma)-isa=foo,)

@@ -66,9 +69,11 @@ as-option = $(shell if $(CC) $(CFLAGS) $
# as-instr
# Usage: cflags-y += $(call as-instr, instr, option1, option2)

-as-instr = $(shell if echo -e "$(1)" | $(AS) >/dev/null 2>&1 -W -Z -o astest$$$$.out ; \
- then echo "$(2)"; else echo "$(3)"; fi; \
- rm -f astest$$$$.out)
+as-instr = $(shell if echo -e "$(1)" | \
+ $(CC) $(AFLAGS) -c -xassembler - \
+ -o $(TMPOUT)astest$$$$.out > /dev/null 2>&1; \
+ then rm $(TMPOUT)astest$$$$.out; echo "$(2)"; \
+ else echo "$(3)"; fi)

# cc-option
# Usage: cflags-y += $(call cc-option, -march=winchip-c6, -march=i586)
@@ -97,10 +102,10 @@ cc-ifversion = $(shell if [ $(call cc-ve

# ld-option
# Usage: ldflags += $(call ld-option, -Wl$(comma)--hash-style=both)
-ld-option = $(shell if $(CC) $(1) \
- -nostdlib -o ldtest$$$$.out -xc /dev/null \
- > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi; \
- rm -f ldtest$$$$.out)
+ld-option = $(shell if $(CC) $(1) -nostdlib -xc /dev/null \
+ -o $(TMPOUT)ldtest$$$$.out > /dev/null 2>&1; \
+ then rm $(TMPOUT)ldtest$$$$.out; echo "$(1)"; \
+ else echo "$(2)"; fi)

###
# Shorthand for $(Q)$(MAKE) -f scripts/Makefile.build obj=

2006-12-05 15:00:41

by Mark Lord

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Andrew Morton wrote:
> On Mon, 04 Dec 2006 23:56:42 -0500
> Jeff Garzik <[email protected]> wrote:
>
>> Andrew Morton wrote:
>
>>> libata_resume_fix.patch
>> I thought this was resolved long ago? Are there still open reports that
>> this solves, where upstream doesn't work?
>
> Heck, I don't know.

You probably pinched it from my website originally, and I nabbed it from
an LKML posting 18 months ago. It's a patch that was required here back
in the 2.6.12 - 2.6.16 era, and it is no longer needed now.

Drop it.

2006-12-05 16:02:53

by Dave Jones

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:

> cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch
> remove-hotplug-cpu-crap-from-cpufreq.patch
> cpufreq-select-consistently-re-2619-rc5-mm1.patch
> cpufreq-set-policy-curfreq-on-initialization.patch
> bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch
>
> Sent to cpufreq maintainer

I'm travelling right now, and somehow managed to oops my home router
3000 miles away making it hard for me to access mail & stuff.
(That "page count went negative" BUG() bit me when I did a killall -9 vpnc)

Full bug report, and processing of this backlog will happen
as soon as I get back on Sunday :)

Dave

2006-12-05 17:35:23

by James Simmons

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


> video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch

Does this patch update the fbdev drivers?

> add-display-output-class-support.patch
> add-output-class-document.patch
> drivers-add-lcd-support-3.patch
> drivers-add-lcd-support-3-Kconfig-fix.patch
> drivers-add-lcd-support-update-4.patch
> drivers-add-lcd-support-update-5.patch
> drivers-add-lcd-support-update6.patch
> drivers-add-lcd-support-update-7.patch
> drivers-add-lcd-support-update-8.patch

Ug. We have alot of interfaces attempting to do the same thing. We also
have the lcd class_dev in drivers/video/backlight. I did some work which I
will post to interested parties in the hopes of getting one interface to
make everyone happy.

2006-12-05 18:01:53

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Tue, 5 Dec 2006 17:35:20 +0000 (GMT)
James Simmons <[email protected]> wrote:

>
> > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
>
> Does this patch update the fbdev drivers?

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch

Seems not. Should it?

> > add-display-output-class-support.patch
> > add-output-class-document.patch
> > drivers-add-lcd-support-3.patch
> > drivers-add-lcd-support-3-Kconfig-fix.patch
> > drivers-add-lcd-support-update-4.patch
> > drivers-add-lcd-support-update-5.patch
> > drivers-add-lcd-support-update6.patch
> > drivers-add-lcd-support-update-7.patch
> > drivers-add-lcd-support-update-8.patch
>
> Ug. We have alot of interfaces attempting to do the same thing. We also
> have the lcd class_dev in drivers/video/backlight. I did some work which I
> will post to interested parties in the hopes of getting one interface to
> make everyone happy.

Well can you please work out what we should do with Miguel?

2006-12-05 18:26:00

by James Simmons

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


> > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> >
> > Does this patch update the fbdev drivers?
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
>
> Seems not. Should it?

Yes. Its bizarre. The drivers compile with the wrong method prototype. I
updated the fbdev drivers to the new backlight_device_register and it
compiled as expect. There are a few other problems with teh fbdev drivers.
I will send a patch.

> > > add-display-output-class-support.patch
> > > add-output-class-document.patch
> > > drivers-add-lcd-support-3.patch
> > > drivers-add-lcd-support-3-Kconfig-fix.patch
> > > drivers-add-lcd-support-update-4.patch
> > > drivers-add-lcd-support-update-5.patch
> > > drivers-add-lcd-support-update6.patch
> > > drivers-add-lcd-support-update-7.patch
> > > drivers-add-lcd-support-update-8.patch
> >
> > Ug. We have alot of interfaces attempting to do the same thing. We also
> > have the lcd class_dev in drivers/video/backlight. I did some work which I
> > will post to interested parties in the hopes of getting one interface to
> > make everyone happy.
>
> Well can you please work out what we should do with Miguel?

I sent a email already. The details will be hammered out.

2006-12-05 18:37:33

by James Simmons

[permalink] [raw]
Subject: [PATCH] backlight sysfs change to the fbdev drivers


This patch updates the framebuffer drivers that use the backlight api to
the change of passing in the struct device to backlight_device_register
in the -mm tree.

Please apply.

Signed-off: James Simmons <[email protected]>

diff --git a/drivers/video/aty/aty128fb.c b/drivers/video/aty/aty128fb.c
index 276a215..00254d5 100644
--- a/drivers/video/aty/aty128fb.c
+++ b/drivers/video/aty/aty128fb.c
@@ -1829,7 +1829,7 @@ static void aty128_bl_init(struct aty128

snprintf(name, sizeof(name), "aty128bl%d", info->node);

- bd = backlight_device_register(name, par, &aty128_bl_data);
+ bd = backlight_device_register(name, par->dev, par, &aty128_bl_data);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
printk(KERN_WARNING "aty128: Backlight registration failed\n");
diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
index e815b35..4916a7b 100644
--- a/drivers/video/aty/atyfb_base.c
+++ b/drivers/video/aty/atyfb_base.c
@@ -2221,7 +2221,7 @@ static void aty_bl_init(struct atyfb_par

snprintf(name, sizeof(name), "atybl%d", info->node);

- bd = backlight_device_register(name, par, &aty_bl_data);
+ bd = backlight_device_register(name, par->dev, par, &aty_bl_data);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
printk(KERN_WARNING "aty: Backlight registration failed\n");
diff --git a/drivers/video/aty/radeon_backlight.c b/drivers/video/aty/radeon_backlight.c
index 585eb7b..0faa720 100644
--- a/drivers/video/aty/radeon_backlight.c
+++ b/drivers/video/aty/radeon_backlight.c
@@ -163,7 +163,7 @@ void radeonfb_bl_init(struct radeonfb_in

snprintf(name, sizeof(name), "radeonbl%d", rinfo->info->node);

- bd = backlight_device_register(name, pdata, &radeon_bl_data);
+ bd = backlight_device_register(name, rinfo->pdev, pdata, &radeon_bl_data);
if (IS_ERR(bd)) {
rinfo->info->bl_dev = NULL;
printk("radeonfb: Backlight registration failed\n");
diff --git a/drivers/video/nvidia/nv_backlight.c b/drivers/video/nvidia/nv_backlight.c
index 5b75ae4..b0d5d85 100644
--- a/drivers/video/nvidia/nv_backlight.c
+++ b/drivers/video/nvidia/nv_backlight.c
@@ -141,7 +141,7 @@ void nvidia_bl_init(struct nvidia_par *p

snprintf(name, sizeof(name), "nvidiabl%d", info->node);

- bd = backlight_device_register(name, par, &nvidia_bl_data);
+ bd = backlight_device_register(name, par->pci_dev, par, &nvidia_bl_data);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
printk(KERN_WARNING "nvidia: Backlight registration failed\n");
diff --git a/drivers/video/riva/fbdev.c b/drivers/video/riva/fbdev.c
index a433cc7..d7dfdb6 100644
--- a/drivers/video/riva/fbdev.c
+++ b/drivers/video/riva/fbdev.c
@@ -383,7 +383,7 @@ static void riva_bl_init(struct riva_par

snprintf(name, sizeof(name), "rivabl%d", info->node);

- bd = backlight_device_register(name, par, &riva_bl_data);
+ bd = backlight_device_register(name, par->pdev, par, &riva_bl_data);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
printk(KERN_WARNING "riva: Backlight registration failed\n");

2006-12-05 19:18:29

by Josef Sipek

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:
...
> fsstack-introduce-fsstack_copy_attrinode_.patch
> fsstack-introduce-fsstack_copy_attrinode_-tidy.patch
> fsstack-introduce-fsstack_copy_attrinode_-fs-stackc-should-include-linux-fs_stackh.patch
> ecryptfs-use-fsstacks-generic-copy-inode-attr.patch
> ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix.patch
> ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix-fix.patch
> struct-path-rename-reiserfss-struct-path.patch
> struct-path-rename-dms-struct-path.patch
> struct-path-move-struct-path-from-fs-nameic-into.patch
> struct-path-make-ecryptfs-a-user-of-struct-path.patch
> vfs-change-struct-file-to-use-struct-path.patch
...
>
> Shall merge. I guess. Doesn't seem very useful.

I have two more fixes for fsstack/ecryptfs. I'll send them as a reply to
this email...

Josef "Jeff" Sipek.

--
FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #19
A: To be or not to be.
Q: What is the square root of 4b^2?

2006-12-05 19:21:31

by Josef Sipek

[permalink] [raw]
Subject: [PATCH 1/2] fsstack: Make fsstack_copy_attr_all copy inode size

fsstack_copy_attr_all should copy the inode size in addition to all the
other attributes.

Signed-off-by: Josef "Jeff" Sipek <[email protected]>
---
fs/stack.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fs/stack.c b/fs/stack.c
index 8ffb880..5ddbc34 100644
--- a/fs/stack.c
+++ b/fs/stack.c
@@ -34,5 +34,7 @@ void fsstack_copy_attr_all(struct inode
dest->i_ctime = src->i_ctime;
dest->i_blkbits = src->i_blkbits;
dest->i_flags = src->i_flags;
+
+ fsstack_copy_inode_size(dest, src);
}
EXPORT_SYMBOL_GPL(fsstack_copy_attr_all);
--
1.4.3.3

2006-12-05 19:22:36

by Josef Sipek

[permalink] [raw]
Subject: [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage

Fix up a stray ecryptfs_copy_attr_all call and remove prototypes for
ecryptfs_copy_* as they no longer exist.

Signed-off-by: Josef "Jeff" Sipek <[email protected]>
---
fs/ecryptfs/dentry.c | 2 +-
fs/ecryptfs/ecryptfs_kernel.h | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/ecryptfs/dentry.c b/fs/ecryptfs/dentry.c
index 52d1e36..b0352d8 100644
--- a/fs/ecryptfs/dentry.c
+++ b/fs/ecryptfs/dentry.c
@@ -61,7 +61,7 @@ static int ecryptfs_d_revalidate(struct
struct inode *lower_inode =
ecryptfs_inode_to_lower(dentry->d_inode);

- ecryptfs_copy_attr_all(dentry->d_inode, lower_inode);
+ fsstack_copy_attr_all(dentry->d_inode, lower_inode, NULL);
}
out:
return rc;
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 870a65b..afb64bd 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -28,6 +28,7 @@

#include <keys/user-type.h>
#include <linux/fs.h>
+#include <linux/fs_stack.h>
#include <linux/namei.h>
#include <linux/scatterlist.h>

@@ -413,9 +414,6 @@ int ecryptfs_encode_filename(struct ecry
const char *name, int length,
char **encoded_name);
struct dentry *ecryptfs_lower_dentry(struct dentry *this_dentry);
-void ecryptfs_copy_attr_atime(struct inode *dest, const struct inode *src);
-void ecryptfs_copy_attr_all(struct inode *dest, const struct inode *src);
-void ecryptfs_copy_inode_size(struct inode *dst, const struct inode *src);
void ecryptfs_dump_hex(char *data, int bytes);
int virt_to_scatterlist(const void *addr, int size, struct scatterlist *sg,
int sg_size);
--
1.4.3.3

2006-12-05 19:43:22

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Tue, 5 Dec 2006 18:25:58 +0000 (GMT)
James Simmons <[email protected]> wrote:

> > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > >
> > > Does this patch update the fbdev drivers?
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> >
> > Seems not. Should it?
>
> Yes. Its bizarre.

It is.

> The drivers compile with the wrong method prototype.

No, it doesn't get compiled at all.

CONFIG_FB_ATY128_BACKLIGHT has no Kconfig record at all.

CONFIG_FB_NVIDIA_BACKLIGHT has no Kconfig record at all.

CONFIG_FB_RIVA_BACKLIGHT has no Kconfig record at all.

So this is all dead code. There is no way to enable any of it within the
config system.

> I
> updated the fbdev drivers to the new backlight_device_register and it
> compiled as expect. There are a few other problems with teh fbdev drivers.
> I will send a patch.

It's a start ;)

2006-12-05 19:59:06

by James Simmons

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


> > > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > > >
> > > > Does this patch update the fbdev drivers?
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > >
> > > Seems not. Should it?
> >
> > Yes. Its bizarre.
>
> It is.
>
> > The drivers compile with the wrong method prototype.
>
> No, it doesn't get compiled at all.
>
> CONFIG_FB_ATY128_BACKLIGHT has no Kconfig record at all.
>
> CONFIG_FB_NVIDIA_BACKLIGHT has no Kconfig record at all.
>
> CONFIG_FB_RIVA_BACKLIGHT has no Kconfig record at all.
>
> So this is all dead code. There is no way to enable any of it within the
> config system.

Ug. Kconfig in drivers/video has all the above drivers enable the
backlight only if PMAC_BACKLIGHT is set. The problem is backlight
is after the framebuffer. We should move the backlight menu before
the framebuffer configuration.

2006-12-05 20:21:10

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Tue, 5 Dec 2006 19:59:01 +0000 (GMT)
James Simmons <[email protected]> wrote:

>
> > > > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > > > >
> > > > > Does this patch update the fbdev drivers?
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > > >
> > > > Seems not. Should it?
> > >
> > > Yes. Its bizarre.
> >
> > It is.
> >
> > > The drivers compile with the wrong method prototype.
> >
> > No, it doesn't get compiled at all.
> >
> > CONFIG_FB_ATY128_BACKLIGHT has no Kconfig record at all.
> >
> > CONFIG_FB_NVIDIA_BACKLIGHT has no Kconfig record at all.
> >
> > CONFIG_FB_RIVA_BACKLIGHT has no Kconfig record at all.
> >
> > So this is all dead code. There is no way to enable any of it within the
> > config system.
>
> Ug. Kconfig in drivers/video has all the above drivers enable the
> backlight only if PMAC_BACKLIGHT is set.

erp, I grepped for CONFIG_foo and not foo. Again.

> The problem is backlight
> is after the framebuffer. We should move the backlight menu before
> the framebuffer configuration.

OK. Can you do a patch sometime please?

2006-12-05 20:40:57

by Miguel Ojeda

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On 12/5/06, James Simmons <[email protected]> wrote:
>
> > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > >
> > > Does this patch update the fbdev drivers?
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> >
> > Seems not. Should it?
>
> Yes. Its bizarre. The drivers compile with the wrong method prototype. I
> updated the fbdev drivers to the new backlight_device_register and it
> compiled as expect. There are a few other problems with teh fbdev drivers.
> I will send a patch.
>
> > > > add-display-output-class-support.patch
> > > > add-output-class-document.patch
> > > > drivers-add-lcd-support-3.patch
> > > > drivers-add-lcd-support-3-Kconfig-fix.patch
> > > > drivers-add-lcd-support-update-4.patch
> > > > drivers-add-lcd-support-update-5.patch
> > > > drivers-add-lcd-support-update6.patch
> > > > drivers-add-lcd-support-update-7.patch
> > > > drivers-add-lcd-support-update-8.patch
> > >
> > > Ug. We have alot of interfaces attempting to do the same thing. We also
> > > have the lcd class_dev in drivers/video/backlight. I did some work which I
> > > will post to interested parties in the hopes of getting one interface to
> > > make everyone happy.
> >
> > Well can you please work out what we should do with Miguel?
>
> I sent a email already. The details will be hammered out.
>
>

Right back from exams and with lots of spare time :)

I got your patch, so I'm going to try your patch and exchange all the
"platform_device_*" stuff with your display class and move ks0108,
cfag12864b and cfag12864bfb to drivers/video/display/

--
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm

2006-12-05 21:01:38

by Ingo Molnar

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


* Andrew Morton <[email protected]> wrote:

> gtod-exponential-update_wall_time.patch
>
> Roman wanted this dropped, and afaik that's unresolved.

please drop this one for now, we'll rework it. It's an optimization, not
a showstopper must-have component.

Ingo

2006-12-05 21:18:11

by Ingo Molnar

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20, scheduler bits


* Andrew Morton <[email protected]> wrote:

> schedc-correct-comment-for-this_rq_lock-routine.patch
> sched-fix-migration-cost-estimator.patch
> sched-domain-move-sched-group-allocations-to-percpu-area.patch

(already acked)

> move_task_off_dead_cpu-should-be-called-with-disabled-ints.patch

Acked-by: Ingo Molnar <[email protected]>

> sched-domain-increase-the-smt-busy-rebalance-interval.patch

Acked-by: Ingo Molnar <[email protected]>

> sched-avoid-taking-rq-lock-in-wake_priority_sleeper.patch

Acked-by: Ingo Molnar <[email protected]>

> sched-remove-staggering-of-load-balancing.patch

Acked-by: Ingo Molnar <[email protected]>

> sched-disable-interrupts-for-locking-in-load_balance.patch

Acked-by: Ingo Molnar <[email protected]>

> sched-extract-load-calculation-from-rebalance_tick.patch

Acked-by: Ingo Molnar <[email protected]>

> sched-move-idle-status-calculation-into-rebalance_tick.patch

Acked-by: Ingo Molnar <[email protected]>

> sched-use-softirq-for-load-balancing.patch

Acked-by: Ingo Molnar <[email protected]>

> sched-call-tasklet-less-frequently.patch

patch is misnamed, otherwise:

Acked-by: Ingo Molnar <[email protected]>

> sched-add-option-to-serialize-load-balancing.patch
> sched-add-option-to-serialize-load-balancing-fix.patch

(please merge these two patches into one, the first one is not
bisectable.)

Acked-by: Ingo Molnar <[email protected]>

> sched-improve-migration-accuracy.patch
> sched-improve-migration-accuracy-tidy.patch
> sched-improve-migration-accuracy-fix.patch

please merge into one patch.

Acked-by: Ingo Molnar <[email protected]>

> sched-decrease-number-of-load-balances.patch

this one goes away as per Ken's observation.

> sched-optimize-activate_task-for-rt-task.patch

Acked-by: Ingo Molnar <[email protected]>

> kernel-schedc-whitespace-cleanups.patch

Acked-by: Ingo Molnar <[email protected]>

i dont like these:

- cost1 += measure_one(cache, size - i*1024, cpu1, cpu2);
+ cost1 += measure_one(cache, size - i * 1024, cpu1, cpu2);

as it's quite OK to have no spaces in "i*1024", just to indicate
precedence of arithmetic ops. But the good bits dominate in this patch
so lets have it and i'll undo the bad ones.

> kernel-schedc-whitespace-cleanups-more.patch

Acked-by: Ingo Molnar <[email protected]>

Ingo

2006-12-05 21:25:07

by Suresh Siddha

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20, scheduler bits

On Tue, Dec 05, 2006 at 10:17:23PM +0100, Ingo Molnar wrote:
> > sched-decrease-number-of-load-balances.patch
>
> this one goes away as per Ken's observation.

Not really. Ken posted a cleanup patch on top of the above patch. Ken pointed
one more cleanup which I will work on it and send it across in a day.

thanks,
suresh

2006-12-05 21:29:25

by Miguel Ojeda

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20, scheduler bits

On 12/5/06, Ingo Molnar <[email protected]> wrote:
>
> > kernel-schedc-whitespace-cleanups.patch
>
> Acked-by: Ingo Molnar <[email protected]>
>
> i dont like these:
>
> - cost1 += measure_one(cache, size - i*1024, cpu1, cpu2);
> + cost1 += measure_one(cache, size - i * 1024, cpu1, cpu2);
>
> as it's quite OK to have no spaces in "i*1024", just to indicate
> precedence of arithmetic ops. But the good bits dominate in this patch
> so lets have it and i'll undo the bad ones.
>

Ok, I will take care of that for future whitespace cleanups, as I see
they are welcome :)

--
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm

2006-12-05 21:34:19

by James Simmons

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


> > Ug. Kconfig in drivers/video has all the above drivers enable the
> > backlight only if PMAC_BACKLIGHT is set.
>
> erp, I grepped for CONFIG_foo and not foo. Again.
>
> > The problem is backlight
> > is after the framebuffer. We should move the backlight menu before
> > the framebuffer configuration.
>
> OK. Can you do a patch sometime please?

Here you go. This patch places the backlight before the framebuffers. You
will now be able to select using the backlight with various framebuffer
drivers.

Signed-off: James Simmons <[email protected]>

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 7a43020..40f6bea 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -4,20 +4,9 @@

menu "Graphics support"

-config FIRMWARE_EDID
- bool "Enable firmware EDID"
- default y
- ---help---
- This enables access to the EDID transferred from the firmware.
- On the i386, this is from the Video BIOS. Enable this if DDC/I2C
- transfers do not work for your driver and if you are using
- nvidiafb, i810fb or savagefb.
-
- In general, choosing Y for this option is safe. If you
- experience extremely long delays while booting before you get
- something on your display, try setting this to N. Matrox cards in
- combination with certain motherboards and monitors are known to
- suffer from this problem.
+if SYSFS
+ source "drivers/video/backlight/Kconfig"
+endif

config FB
tristate "Support for frame buffer devices"
@@ -53,6 +42,22 @@ config FB
(e.g. an accelerated X server) and that are not frame buffer
device-aware may cause unexpected results. If unsure, say N.

+config FIRMWARE_EDID
+ bool "Enable firmware EDID"
+ depends on FB
+ default n
+ ---help---
+ This enables access to the EDID transferred from the firmware.
+ On the i386, this is from the Video BIOS. Enable this if DDC/I2C
+ transfers do not work for your driver and if you are using
+ nvidiafb, i810fb or savagefb.
+
+ In general, choosing Y for this option is safe. If you
+ experience extremely long delays while booting before you get
+ something on your display, try setting this to N. Matrox cards in
+ combination with certain motherboards and monitors are known to
+ suffer from this problem.
+
config FB_DDC
tristate
depends on FB && I2C && I2C_ALGOBIT
@@ -90,13 +95,6 @@ config FB_MACMODES
depends on FB
default n

-config FB_BACKLIGHT
- bool
- depends on FB
- select BACKLIGHT_LCD_SUPPORT
- select BACKLIGHT_CLASS_DEVICE
- default n
-
config FB_MODE_HELPERS
bool "Enable Video Mode Handling Helpers"
depends on FB
@@ -126,6 +124,9 @@ config FB_TILEBLITTING
This is particularly important to one driver, matroxfb. If
unsure, say N.

+comment "Frambuffer hardware drivers"
+ depends on FB
+
config FB_CIRRUS
tristate "Cirrus Logic support"
depends on FB && (ZORRO || PCI)
@@ -728,8 +729,7 @@ config FB_NVIDIA_I2C

config FB_NVIDIA_BACKLIGHT
bool "Support for backlight control"
- depends on FB_NVIDIA && PMAC_BACKLIGHT
- select FB_BACKLIGHT
+ depends on FB_NVIDIA && BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -775,8 +775,7 @@ config FB_RIVA_DEBUG

config FB_RIVA_BACKLIGHT
bool "Support for backlight control"
- depends on FB_RIVA && PMAC_BACKLIGHT
- select FB_BACKLIGHT
+ depends on FB_RIVA && BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -1049,8 +1048,7 @@ config FB_RADEON_I2C

config FB_RADEON_BACKLIGHT
bool "Support for backlight control"
- depends on FB_RADEON && PMAC_BACKLIGHT
- select FB_BACKLIGHT
+ depends on FB_RADEON && BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -1081,8 +1079,7 @@ config FB_ATY128

config FB_ATY128_BACKLIGHT
bool "Support for backlight control"
- depends on FB_ATY128 && PMAC_BACKLIGHT
- select FB_BACKLIGHT
+ depends on FB_ATY128 && BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -1131,8 +1128,7 @@ config FB_ATY_GX

config FB_ATY_BACKLIGHT
bool "Support for backlight control"
- depends on FB_ATY && PMAC_BACKLIGHT
- select FB_BACKLIGHT
+ depends on FB_ATY && BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -1632,6 +1628,7 @@ config FB_VIRTUAL
the vfb_enable=1 option.

If unsure, say N.
+
if VT
source "drivers/video/console/Kconfig"
endif
@@ -1640,9 +1637,5 @@ if FB || SGI_NEWPORT_CONSOLE
source "drivers/video/logo/Kconfig"
endif

-if SYSFS
- source "drivers/video/backlight/Kconfig"
-endif
-
endmenu


2006-12-05 21:47:49

by Ingo Molnar

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20, scheduler bits


* Siddha, Suresh B <[email protected]> wrote:

> On Tue, Dec 05, 2006 at 10:17:23PM +0100, Ingo Molnar wrote:
> > > sched-decrease-number-of-load-balances.patch
> >
> > this one goes away as per Ken's observation.
>
> Not really. Ken posted a cleanup patch on top of the above patch. Ken
> pointed one more cleanup which I will work on it and send it across in
> a day.

ok.

Ingo

2006-12-05 22:28:37

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage

On Tue, 5 Dec 2006 14:22:32 -0500
Josef Sipek <[email protected]> wrote:

> Fix up a stray ecryptfs_copy_attr_all call and remove prototypes for
> ecryptfs_copy_* as they no longer exist.
>
> Signed-off-by: Josef "Jeff" Sipek <[email protected]>
> ---
> fs/ecryptfs/dentry.c | 2 +-
> fs/ecryptfs/ecryptfs_kernel.h | 4 +---
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ecryptfs/dentry.c b/fs/ecryptfs/dentry.c
> index 52d1e36..b0352d8 100644
> --- a/fs/ecryptfs/dentry.c
> +++ b/fs/ecryptfs/dentry.c
> @@ -61,7 +61,7 @@ static int ecryptfs_d_revalidate(struct
> struct inode *lower_inode =
> ecryptfs_inode_to_lower(dentry->d_inode);
>
> - ecryptfs_copy_attr_all(dentry->d_inode, lower_inode);
> + fsstack_copy_attr_all(dentry->d_inode, lower_inode, NULL);

I fixed that two weeks ago.

When your patches are queued in -mm please do test them there, and review
others' changes to them, and raise patches against them. Raising patches
against one's private tree and not testing the code which is planned to be
merged can introduce errors.

2006-12-05 22:38:15

by Josef Sipek

[permalink] [raw]
Subject: Re: [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage

On Tue, Dec 05, 2006 at 02:28:31PM -0800, Andrew Morton wrote:
> On Tue, 5 Dec 2006 14:22:32 -0500
> Josef Sipek <[email protected]> wrote:
>
> > Fix up a stray ecryptfs_copy_attr_all call and remove prototypes for
> > ecryptfs_copy_* as they no longer exist.
> >
> > Signed-off-by: Josef "Jeff" Sipek <[email protected]>
> > ---
> > fs/ecryptfs/dentry.c | 2 +-
> > fs/ecryptfs/ecryptfs_kernel.h | 4 +---
> > 2 files changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/ecryptfs/dentry.c b/fs/ecryptfs/dentry.c
> > index 52d1e36..b0352d8 100644
> > --- a/fs/ecryptfs/dentry.c
> > +++ b/fs/ecryptfs/dentry.c
> > @@ -61,7 +61,7 @@ static int ecryptfs_d_revalidate(struct
> > struct inode *lower_inode =
> > ecryptfs_inode_to_lower(dentry->d_inode);
> >
> > - ecryptfs_copy_attr_all(dentry->d_inode, lower_inode);
> > + fsstack_copy_attr_all(dentry->d_inode, lower_inode, NULL);
>
> I fixed that two weeks ago.
>
> When your patches are queued in -mm please do test them there, and review
> others' changes to them, and raise patches against them. Raising patches
> against one's private tree and not testing the code which is planned to be
> merged can introduce errors.

Sorry about that. I noticed your fix, and the one by Adrian. And I did add
them to my fsstack queue.

I must have dropped it accidentally.

Josef "Jeff" Sipek.

--
If I have trouble installing Linux, something is wrong. Very wrong.
- Linus Torvalds

2006-12-05 22:49:19

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage

On Tue, 5 Dec 2006 17:38:07 -0500
Josef Sipek <[email protected]> wrote:

> > When your patches are queued in -mm please do test them there, and review
> > others' changes to them, and raise patches against them. Raising patches
> > against one's private tree and not testing the code which is planned to be
> > merged can introduce errors.
>
> Sorry about that. I noticed your fix, and the one by Adrian. And I did add
> them to my fsstack queue.

you don't have an fsstack queue any more ;)

Please, I really do want developers to test their code in -mm once I've
merged it. What happens if there's some nasty interaction between your
patch and someone else's? We'll not find out about it and it'll get
merged.

2006-12-05 23:16:30

by Josef Sipek

[permalink] [raw]
Subject: Re: [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage

On Tue, Dec 05, 2006 at 02:49:13PM -0800, Andrew Morton wrote:
> On Tue, 5 Dec 2006 17:38:07 -0500
> Josef Sipek <[email protected]> wrote:
>
> > > When your patches are queued in -mm please do test them there, and review
> > > others' changes to them, and raise patches against them. Raising patches
> > > against one's private tree and not testing the code which is planned to be
> > > merged can introduce errors.
> >
> > Sorry about that. I noticed your fix, and the one by Adrian. And I did add
> > them to my fsstack queue.
>
> you don't have an fsstack queue any more ;)

Good point :)

> Please, I really do want developers to test their code in -mm once I've
> merged it. What happens if there's some nasty interaction between your
> patch and someone else's? We'll not find out about it and it'll get
> merged.

Point taken.

Josef "Jeff" Sipek.

--
I already backed up the box once, I can do it again.

2006-12-05 23:55:00

by Alessandro Guido

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Sorry, I didn't find in your list the patches regarding the sony_acpi
driver that were present in 2.6.19-rc6-mm2. I'm talking about:

2.6-sony_acpi4.patch
sony_apci-resume.patch
acpi-add-backlight-support-to-the-sony_acpi.patch
acpi-add-backlight-support-to-the-sony_acpi-v2.patch

What is the future of these?

Thanks.
Alessandro

2006-12-06 00:13:43

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Wed, 6 Dec 2006 00:55:29 +0100
Alessandro Guido <[email protected]> wrote:

> Sorry, I didn't find in your list the patches regarding the sony_acpi
> driver that were present in 2.6.19-rc6-mm2. I'm talking about:
>
> 2.6-sony_acpi4.patch
> sony_apci-resume.patch
> acpi-add-backlight-support-to-the-sony_acpi.patch
> acpi-add-backlight-support-to-the-sony_acpi-v2.patch
>
> What is the future of these?
>

I spose I need to talk Len into merging the sony-acpi driver.

Before that I need to work out why /sys/class/backlight/sony/brightness
magically vanished on me after a suspend-to-ram operation.

2006-12-06 02:59:49

by Roman Zippel

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Hi,

On Mon, 4 Dec 2006, Andrew Morton wrote:

> [dyntick]
>
> Shall merge, I guess. My confidence is low, but it's Kconfigurable and it
> needs to get sorted out.

IMO it least at needs one more iteration to address the comments that
were made (not just mine), in the short term the less it touches
unconditionally the less I care right now.
In the long term IMO this might need a major rework, the basic problem I
have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how
to dynamically manage multiple timer.

bye, Roman

2006-12-06 03:30:04

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

> On Wed, 6 Dec 2006 03:59:41 +0100 (CET) Roman Zippel <[email protected]> wrote:
> Hi,
>
> On Mon, 4 Dec 2006, Andrew Morton wrote:
>
> > [dyntick]
> >
> > Shall merge, I guess. My confidence is low, but it's Kconfigurable and it
> > needs to get sorted out.
>
> IMO it least at needs one more iteration to address the comments that
> were made (not just mine), in the short term the less it touches
> unconditionally the less I care right now.

I don't have a clue which review comments remain unaddressed - do you recall?

I never saw an item-by-item accounting of my own (extensive) review
comments, actually. And then an avalanche of new stuff got sent and I
didn't have time to go through it all at the same level of detail.

So yeah, I don't have a lot of confidence from that POV either. But otoh,
I'm confident that Ingo and Thomas will competently and promptly address
regressions, so the risk factor isn't too bad. And changing APIC and
timekeeping code sure is risky.

Yes, I too am wobbly about a 2.6.20 merge. But otoh I doubt if much will
get changed if it sits in -mm for another two months. As long as it's
heading in the right direction and doesn't break things when it is
configged-off then OK.

> In the long term IMO this might need a major rework, the basic problem I
> have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how
> to dynamically manage multiple timer.

I'm not sure I understand that. Are you referring to multiple,
concurrently-operating hardware clock sources? <wonders how that could
work> If so, that's more a clocksource thing than a dynticks/hrtimer thing,
isn't it?

2006-12-06 03:46:45

by Horst Schirmeier

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Hi,

On Tue, 05 Dec 2006, Roman Zippel wrote:
> On Mon, 4 Dec 2006, Andrew Morton wrote:
> > kbuild-dont-put-temp-files-in-the-source-tree.patch
> > actually-delete-the-as-instr-ld-option-tmp-file.patch
>
> Andi had objections about the mktemp usage and I agree with him.
> The proposed patch in bugzilla didn't have this and no further
> justification was given for why it's needed.
> Below is a replacement patch with some improvements:
> - kbuild doesn't use $(AS), so use $(CC)
> - tmp dir needs only to be calculated once
> - reformat a bit to keep it under 80 columns and to be more readable
>
> bye, Roman
>
> Signed-off-by: Roman Zippel <[email protected]>

This patch looks good to me, and I'd prefer it over the (twice
corrected) one currently in -mm.

- It's close to what Daniel Drake proposed recently [1] (main
difference: corrects the very same problem for ld-option, which might
otherwise bite us later) and what's already in Gentoo's patchkernel,

- it abstains from using mktemp, hopefully making Andi happy ;),

- resolves the current Gentoo sandbox issues without touching more
kbuild code than necessary.

Kind regards,
Horst

[1]Message-Id: <[email protected]>

--
PGP-Key 0xD40E0E7A


Attachments:
(No filename) (1.23 kB)
signature.asc (189.00 B)
Digital signature
Download all attachments

2006-12-06 08:29:02

by Thomas Gleixner

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Tue, 2006-12-05 at 20:30 -0800, Andrew Morton wrote:
> I don't have a clue which review comments remain unaddressed - do you recall?
>
> I never saw an item-by-item accounting of my own (extensive) review
> comments, actually. And then an avalanche of new stuff got sent and I
> didn't have time to go through it all at the same level of detail.

Arjan did a review of the replacement and I'm in the process to go
through that and Romans comments again. I'll add a complete list of the
review issues and the resolution state. Sorry that this was delayed, but
I was busy regression testing and hunting nasty details in the last
weeks.

> So yeah, I don't have a lot of confidence from that POV either. But otoh,
> I'm confident that Ingo and Thomas will competently and promptly address
> regressions, so the risk factor isn't too bad. And changing APIC and
> timekeeping code sure is risky.

Timekeeping is mostly untouched and the APIC change was done to solve
real world issues:

- lapic verification gets stuck for ever
- lapic timer runs too fast

> > In the long term IMO this might need a major rework, the basic problem I
> > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how
> > to dynamically manage multiple timer.
>
> I'm not sure I understand that. Are you referring to multiple,
> concurrently-operating hardware clock sources? <wonders how that could
> work> If so, that's more a clocksource thing than a dynticks/hrtimer thing,
> isn't it?

If I understand it correctly, Roman wants clockevents to be usable for
other things aside hrtimer/dyntick, i.e. let other code request unused
timer event hardware for special purposes. I thought about that in the
originally but I stayed away from it, as there are no users at the
moment and I wanted to avoid the usual "who needs that" comment. Granted
that clockevents is not perfect, but it's rather self contained and has
no user space exposure, so it can be replaced by something better
anytime.

tglx


2006-12-06 12:33:56

by Roman Zippel

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Hi,

On Tue, 5 Dec 2006, Andrew Morton wrote:

> > IMO it least at needs one more iteration to address the comments that
> > were made (not just mine), in the short term the less it touches
> > unconditionally the less I care right now.
>
> I don't have a clue which review comments remain unaddressed - do you recall?

Outside clockevents I'd like to see at least the flag handling fixed
before it gets merged.
Inside clockevents I could poke around forever...

> > In the long term IMO this might need a major rework, the basic problem I
> > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how
> > to dynamically manage multiple timer.
>
> I'm not sure I understand that. Are you referring to multiple,
> concurrently-operating hardware clock sources? <wonders how that could
> work> If so, that's more a clocksource thing than a dynticks/hrtimer thing,
> isn't it?

A rather simple example would be profiling, where a separate timer is
useful to see stuff that runs from the main timer, which is currently
invisible.
It's insofar a clocksource thing as clock source and clock events should
form a union, currently it's separate and that's a big problem. It's not
really problem to have multiple clock sources and they don't really have
to be synchronized with each other, but events _are_ connected to the
source they are coming from.
In the end we could even expose multiple clocks via the posix clock/timer
interface, but with the current design I don't see how this is possible.

bye, Roman

2006-12-06 12:54:16

by Roman Zippel

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Hi,

On Wed, 6 Dec 2006, Thomas Gleixner wrote:

> If I understand it correctly, Roman wants clockevents to be usable for
> other things aside hrtimer/dyntick, i.e. let other code request unused
> timer event hardware for special purposes. I thought about that in the
> originally but I stayed away from it, as there are no users at the
> moment and I wanted to avoid the usual "who needs that" comment.

Nonsense, one obvious user would be the scheduler, the current scheduler
tick emulation is rather ugly and sort of explains why you need the
special wakeup logic I saw in previous versions.
The scheduler should be completely separate from hrtimer, in the long term
they might optionally not even use the same clock source (e.g. the
scheduler would use a low resolution, but fast clock, while posix timer
whould use the high resolution timer).

bye, Roman

2006-12-06 13:12:43

by Ingo Molnar

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


* Roman Zippel <[email protected]> wrote:

> On Wed, 6 Dec 2006, Thomas Gleixner wrote:
>
> > If I understand it correctly, Roman wants clockevents to be usable
> > for other things aside hrtimer/dyntick, i.e. let other code request
> > unused timer event hardware for special purposes. I thought about
> > that in the originally but I stayed away from it, as there are no
> > users at the moment and I wanted to avoid the usual "who needs that"
> > comment.
>
> Nonsense, [...]

why do you call Thomas' observation nonsense? Fact: there is no current
user of such a facility. What we implemented, high-res timers and
dynticks does not need such a facility.

we wholeheartedly agree that such a facility 'would be nice', and 'could
be used by existing kernel code' but we didnt want to chew too much at a
time.

> [...] one obvious user would be the scheduler, [...]

But cleaning up the scheduler tick was not our purpose with high-res
timers nor with dynticks. One of your previous complaints was that the
patches are too intrusive to be trusted. Now they are too simple?

We'll clean up the scheduler tick and profiling too, but not now.

> [...] the current scheduler tick emulation is rather ugly [...]

i disagree with you and it's pretty low-impact anyway. There's still
quite many HZ/tick assumptions all around the time code (NTP being one
example), we'll deal with those via other patches.

Ingo

2006-12-06 14:33:23

by Roman Zippel

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Hi,

On Wed, 6 Dec 2006, Ingo Molnar wrote:

> * Roman Zippel <[email protected]> wrote:
>
> > On Wed, 6 Dec 2006, Thomas Gleixner wrote:
> >
> > > If I understand it correctly, Roman wants clockevents to be usable
> > > for other things aside hrtimer/dyntick, i.e. let other code request
> > > unused timer event hardware for special purposes. I thought about
> > > that in the originally but I stayed away from it, as there are no
> > > users at the moment and I wanted to avoid the usual "who needs that"
> > > comment.
> >
> > Nonsense, [...]
>
> why do you call Thomas' observation nonsense?

What's the point of this question? Your answer is/was in the "[...]" part.

> Fact: there is no current
> user of such a facility. What we implemented, high-res timers and
> dynticks does not need such a facility.

Fact: there _are_ users which need a timer facility (e.g. the scheduler).

> we wholeheartedly agree that such a facility 'would be nice', and 'could
> be used by existing kernel code' but we didnt want to chew too much at a
> time.

Maybe the existing code should have been cleaned up first? Unfortunately
the dynticks feature seems to more appealing than clean code...

> > [...] one obvious user would be the scheduler, [...]
>
> But cleaning up the scheduler tick was not our purpose with high-res
> timers nor with dynticks. One of your previous complaints was that the
> patches are too intrusive to be trusted. Now they are too simple?

Would you please stop these personal attacks?

> We'll clean up the scheduler tick and profiling too, but not now.

Since this is very important code, it would be rather useful to know
what's coming and to get to an agreement about the general direction this
code is taking. This code has to cover a wide range of applications, where
as you guys are rather focused on realtime applications, which is ok, but
we need to _carefully_ rethink how time is managed within the kernel,
instead of randomly poking around in the kernel.

> > [...] the current scheduler tick emulation is rather ugly [...]
>
> i disagree with you and it's pretty low-impact anyway. There's still
> quite many HZ/tick assumptions all around the time code (NTP being one
> example), we'll deal with those via other patches.

Why do you pick on the NTP code? That's actually one of the places where
assumptions about HZ are largely gone. NTP state is updated incrementally
and this won't change, but the update frequency can now be easily
disconnected from HZ.

bye, Roman

2006-12-06 14:42:39

by James Simmons

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


>
> Right back from exams and with lots of spare time :)
>
> I got your patch, so I'm going to try your patch and exchange all the
> "platform_device_*" stuff with your display class and move ks0108,
> cfag12864b and cfag12864bfb to drivers/video/display/

Thanks. I will post a new patch soon.

2006-12-06 15:23:37

by Ingo Molnar

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


* Roman Zippel <[email protected]> wrote:

> > > > If I understand it correctly, Roman wants clockevents to be usable
> > > > for other things aside hrtimer/dyntick, i.e. let other code request
> > > > unused timer event hardware for special purposes. I thought about
> > > > that in the originally but I stayed away from it, as there are no
> > > > users at the moment and I wanted to avoid the usual "who needs that"
> > > > comment.
> > >
> > > Nonsense, [...]
> >
> > why do you call Thomas' observation nonsense?
>
> What's the point of this question? [...]

the point of my question was what it said: to ask you why you called
Thomas' pretty fair observation 'nonsense'.

> [...] Your answer is/was in the "[...]" part.

meaning:

> > > [...] one obvious user would be the scheduler, [...]

but that is not a refutation of what Thomas said, at all. You say that
the scheduler /could/ use such a facility. What Thomas said was that
/there are no current users of such a facility/. It is a really simple
(and unconditionally true) observation from Thomas. Yes, we could change
other kernel code not directly related to high-res timers, but we chose
not to.

[ The word 'nonsense' is in general a negative descriptor and implies
that what Thomas said was 'obviously false' - while in reality what we
have is /at most/ a difference in opinion. I.e. even if our opinion
differs you shouldnt call his opinion "nonsense", unless you are
willing to prove that it's false - which you didnt do so far. I claim
that what Thomas said is /unconditionally true/, and i can prove it:
it is unconditionally true that such a new facility is not needed
by our code, and that no other kernel code is using it at the moment -
because the facility does not exist yet. If you misunderstood what
Thomas said then please point that out, or prove that his claims are
untrue - thanks. ]

> > Fact: there is no current user of such a facility. What we
> > implemented, high-res timers and dynticks does not need such a
> > facility.
>
> Fact: there _are_ users which need a timer facility (e.g. the
> scheduler).

this is something we are not contesting at all: that a new timer
facility /could/ be used by /other/ kernel code, which does /not/ use it
right now.

our point is simple: the code we add does not in itself necessiate the
new facility, hence we didnt add it. We didnt want to impact other
kernel code, just yet. We repeat: we agree (in theory) with such a
facility, but we wanted to do it separately.

> > we wholeheartedly agree that such a facility 'would be nice', and
> > 'could be used by existing kernel code' but we didnt want to chew
> > too much at a time.
>
> Maybe the existing code should have been cleaned up first?

yes, we'll do that, and we have a good track record doing such cleanups.

> Unfortunately the dynticks feature seems to more appealing than clean
> code...

i think this accusation against us is very unfair.

> > > [...] one obvious user would be the scheduler, [...]
> >
> > But cleaning up the scheduler tick was not our purpose with high-res
> > timers nor with dynticks. One of your previous complaints was that the
> > patches are too intrusive to be trusted. Now they are too simple?
>
> Would you please stop these personal attacks?

please point it out which portion of the above two sentences you
consider a personal attack - or if you cannot, please retract your
baseless accusation.

Fact: you did complain in the past about the complexity and/or
intrusiveness of our high-res timers patches - we've been working on
getting high-res timers upstream for more than a year now.

Fact: you did complain about unused facilities in past patches of ours,
and your feedback caused us significant extra work to remove those
facilities, just to reintroduce them later again.

(i can provide URLs and Message-IDs for these facts)

this time around we chose the minimalistic approach, we didnt add
anything that is not immediately needed, and we didnt want to increase
intrusiveness by "cleaning up" other code and changing it over to the
new facilities.

It cannot be had both ways: either we stay simpler and less intrusive,
or we go more generic but more intrusive.

Ingo

2006-12-06 16:43:26

by Roman Zippel

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Hi,

On Wed, 6 Dec 2006, Ingo Molnar wrote:

> > > > > If I understand it correctly, Roman wants clockevents to be usable
> > > > > for other things aside hrtimer/dyntick, i.e. let other code request
> > > > > unused timer event hardware for special purposes. I thought about
> > > > > that in the originally but I stayed away from it, as there are no
> > > > > users at the moment and I wanted to avoid the usual "who needs that"
> > > > > comment.
> > > >
> > > > Nonsense, [...]
> > >
> > > why do you call Thomas' observation nonsense?
> >
> > What's the point of this question? [...]
>
> the point of my question was what it said: to ask you why you called
> Thomas' pretty fair observation 'nonsense'.

The nonsense comment was regarding the 'the usual "who needs that"
comment', how is it possible that Thomas can observe something that hasn't
happened yet?

> > [...] Your answer is/was in the "[...]" part.
>
> meaning:
>
> > > > [...] one obvious user would be the scheduler, [...]
>
> but that is not a refutation of what Thomas said, at all. You say that
> the scheduler /could/ use such a facility. What Thomas said was that
> /there are no current users of such a facility/. It is a really simple
> (and unconditionally true) observation from Thomas. Yes, we could change
> other kernel code not directly related to high-res timers, but we chose
> not to.

I didn't say "/could/", the scheduler _needs_ such a facility. If hrtimer
and scheduler have to use the same facility, they have to be coordinated
somehow. The current patches don't clean up anything here and actually
introduce extra complexity via the scheduler tick emulation, with little
to no indication how this will be cleaned up. Others may have more faith,
that it will somehow work out, but I'd like to get a bit more information
beforehand.

> > > Fact: there is no current user of such a facility. What we
> > > implemented, high-res timers and dynticks does not need such a
> > > facility.
> >
> > Fact: there _are_ users which need a timer facility (e.g. the
> > scheduler).
>
> this is something we are not contesting at all: that a new timer
> facility /could/ be used by /other/ kernel code, which does /not/ use it
> right now.
>
> our point is simple: the code we add does not in itself necessiate the
> new facility, hence we didnt add it. We didnt want to impact other
> kernel code, just yet. We repeat: we agree (in theory) with such a
> facility, but we wanted to do it separately.

You don't really refute that this eventually will impact other code. The
problem here is that there is pretty much no plan how this will happen.
Without this information most developers cannot tell (without diving deep
into these issues), how this will impact existing code (e.g. all the arch
timer code) or how much more cruft this is going to add, which may have to
be cleaned up later again. Maybe this code is perfect, but how is anyone
going to tell?

> > > we wholeheartedly agree that such a facility 'would be nice', and
> > > 'could be used by existing kernel code' but we didnt want to chew
> > > too much at a time.
> >
> > Maybe the existing code should have been cleaned up first?
>
> yes, we'll do that, and we have a good track record doing such cleanups.

You didn't answer my question, how are you going to do this _first_?

> > > > [...] one obvious user would be the scheduler, [...]
> > >
> > > But cleaning up the scheduler tick was not our purpose with high-res
> > > timers nor with dynticks. One of your previous complaints was that the
> > > patches are too intrusive to be trusted. Now they are too simple?
> >
> > Would you please stop these personal attacks?
>
> please point it out which portion of the above two sentences you
> consider a personal attack - or if you cannot, please retract your
> baseless accusation.

Ingo, above it's you who makes a baseless accusation in the first place.
Your accusation is so generic, that I have no other way than to take this
personally.

> Fact: you did complain in the past about the complexity and/or
> intrusiveness of our high-res timers patches - we've been working on
> getting high-res timers upstream for more than a year now.
>
> Fact: you did complain about unused facilities in past patches of ours,
> and your feedback caused us significant extra work to remove those
> facilities, just to reintroduce them later again.

As long as you see my comments only as "complaining", I'm not really
surprised we don't get nowhere...

> this time around we chose the minimalistic approach, we didnt add
> anything that is not immediately needed, and we didnt want to increase
> intrusiveness by "cleaning up" other code and changing it over to the
> new facilities.

At the risk of repeating myself:

Since this is very important code, it would be rather useful to know
what's coming and to get to an agreement about the general direction this
code is taking. This code has to cover a wide range of applications, where
as you guys are rather focused on realtime applications, which is ok, but
we need to _carefully_ rethink how time is managed within the kernel,
instead of randomly poking around in the kernel.

> It cannot be had both ways: either we stay simpler and less intrusive,
> or we go more generic but more intrusive.

You miss the point, I don't care how intrusive this is, but with every
step we make we have to keep the big picture in mind and the latter is
seriously lacking here.
I have my doubts about where this is going and all I'm getting from you
now (again) is that you try to turn this around and put all the blame on
me. Sorry, Ingo, I'm not taking it and if you continue like this it will
end like this every single time.

bye, Roman

2006-12-06 16:59:39

by Ingo Molnar

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


* Roman Zippel <[email protected]> wrote:

> > > > > [...] one obvious user would be the scheduler, [...]
> >
> > but that is not a refutation of what Thomas said, at all. You say
> > that the scheduler /could/ use such a facility. What Thomas said was
> > that /there are no current users of such a facility/. It is a really
> > simple (and unconditionally true) observation from Thomas. Yes, we
> > could change other kernel code not directly related to high-res
> > timers, but we chose not to.
>
> I didn't say "/could/", the scheduler _needs_ such a facility. [...]

i disagree that the scheduler unconditionally 'needs' such a facility.
The scheduler clock is pretty special and has other requirements and
constraints than generic timekeeping clocks. It /might/ and /could/
utilize such an infrastructure, but it's not at all clear that it
'needs' such a facility.

in any case, i very much entertain the possibility of more synergy in
this space, but it's far from obvious and it's definitely not
unconditionally 'necessary'. The scheduler and profiling code certainly
worked for 15 years without such synergy. What we concentrated on in
this patchset is high-resolution timers and dynticks, not scheduler or
profiler clock cleanups. We cleaned up everything that we impacted
directly, but we also tried to limit the scope of the changes wherever
possible.

Ingo

2006-12-06 17:01:20

by Ingo Molnar

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


* Roman Zippel <[email protected]> wrote:

> > It cannot be had both ways: either we stay simpler and less
> > intrusive, or we go more generic but more intrusive.
>
> You miss the point, I don't care how intrusive this is, [...]

we do care about how intrusive this is. I guess we'll have to agree to
disagree on that.

Ingo

2006-12-06 19:19:40

by Conke Hu

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> On Mon, 04 Dec 2006 23:56:42 -0500
> Jeff Garzik <[email protected]> wrote:
>
> > Andrew Morton wrote:
> > > via-pata-controller-xfer-fixes.patch
> > > via-pata-controller-xfer-fixes-fix.patch
> >
> > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
> > reporter as fixing things, so these two shouldn't be needed.
>
> OK thanks, I dropped it.
>
> >
> > > libata_resume_fix.patch
> >
> > I thought this was resolved long ago? Are there still open reports that
> > this solves, where upstream doesn't work?
>
> Heck, I don't know.
>
> >
> > > ahci-ati-sb600-sata-support-for-various-modes.patch
> >
> > With the PCI quirk, I thought ATI was finally sorted?
>
> Was it? I don't know that either.
>
> I'll drop these too.
> -

Hi Jeff, Andrew
The following patch is ATI's final solution. It was ACKed by Alan.
Jeff, you're the maintainer of libata, but this patch is based on
pci/quirks.c, so I don't know who will apply this patch? You or somebody
else?
Andrew, could you please drop ATI's previous patch and add this one
in next -mm patch? The previous patch I sent
(ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
this one :)


Best regards,
Conke @AMD/ATI


[------------------PATCH------------------]

--- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
19:45:49.000000000 +0800
+++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
19:34:23.000000000 +0800
@@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
}
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
+
+#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
+static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
+{
+ /* set sb600 sata to ahci mode */
+ if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
+ u8 tmp;
+
+ pci_read_config_byte(pdev, 0x40, &tmp);
+ pci_write_config_byte(pdev, 0x40, tmp|1);
+ pci_write_config_byte(pdev, 0x9, 1);
+ pci_write_config_byte(pdev, 0xa, 6);
+ pci_write_config_byte(pdev, 0x40, tmp);
+
+ pdev->class = 0x010601;
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
+#endif

/*
* As per PCI spec, ignore base address registers 0-3 of the IDE
controllers

2006-12-06 19:25:43

by Randy Dunlap

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Thu, 07 Dec 2006 03:19:40 +0800 Conke Hu wrote:

> On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> > On Mon, 04 Dec 2006 23:56:42 -0500
> > Jeff Garzik <[email protected]> wrote:
> >
> > > Andrew Morton wrote:
> > > > via-pata-controller-xfer-fixes.patch
> > > > via-pata-controller-xfer-fixes-fix.patch
> > >
> > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
> > > reporter as fixing things, so these two shouldn't be needed.
> >
> > OK thanks, I dropped it.
> >
> > >
> > > > libata_resume_fix.patch
> > >
> > > I thought this was resolved long ago? Are there still open reports that
> > > this solves, where upstream doesn't work?
> >
> > Heck, I don't know.
> >
> > >
> > > > ahci-ati-sb600-sata-support-for-various-modes.patch
> > >
> > > With the PCI quirk, I thought ATI was finally sorted?
> >
> > Was it? I don't know that either.
> >
> > I'll drop these too.
> > -
>
> Hi Jeff, Andrew
> The following patch is ATI's final solution. It was ACKed by Alan.
> Jeff, you're the maintainer of libata, but this patch is based on
> pci/quirks.c, so I don't know who will apply this patch? You or somebody
> else?
> Andrew, could you please drop ATI's previous patch and add this one
> in next -mm patch? The previous patch I sent
> (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
> this one :)
>
>
> Best regards,
> Conke @AMD/ATI
>
>
> [------------------PATCH------------------]
>
> --- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
> 19:45:49.000000000 +0800
> +++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
> 19:34:23.000000000 +0800
> @@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
> }
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
> PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
> +
> +#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
> +static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
> +{
> + /* set sb600 sata to ahci mode */
> + if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> + u8 tmp;
> +
> + pci_read_config_byte(pdev, 0x40, &tmp);
> + pci_write_config_byte(pdev, 0x40, tmp|1);
> + pci_write_config_byte(pdev, 0x9, 1);
> + pci_write_config_byte(pdev, 0xa, 6);
> + pci_write_config_byte(pdev, 0x40, tmp);
> +
> + pdev->class = 0x010601;
> + }
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
> PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
> +#endif
>
> /*
> * As per PCI spec, ignore base address registers 0-3 of the IDE
> controllers


Can you use fewer magic numbers, please?
At least some of those are already #defined in
include/linux/pci_regs.h.

---
~Randy

2006-12-06 19:40:27

by Jeff Garzik

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Conke Hu wrote:
> The following patch is ATI's final solution. It was ACKed by Alan.
> Jeff, you're the maintainer of libata, but this patch is based on
> pci/quirks.c, so I don't know who will apply this patch? You or somebody
> else?
> Andrew, could you please drop ATI's previous patch and add this one
> in next -mm patch? The previous patch I sent
> (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
> this one :)


I ACK'd it as well, though probably Andrew or Greg should push it.

Jeff


2006-12-06 22:36:27

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Thu, 07 Dec 2006 03:19:40 +0800
Conke Hu <[email protected]> wrote:

> On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> > On Mon, 04 Dec 2006 23:56:42 -0500
> > Jeff Garzik <[email protected]> wrote:
> >
> > > Andrew Morton wrote:
> > > > via-pata-controller-xfer-fixes.patch
> > > > via-pata-controller-xfer-fixes-fix.patch
> > >
> > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
> > > reporter as fixing things, so these two shouldn't be needed.
> >
> > OK thanks, I dropped it.
> >
> > >
> > > > libata_resume_fix.patch
> > >
> > > I thought this was resolved long ago? Are there still open reports that
> > > this solves, where upstream doesn't work?
> >
> > Heck, I don't know.
> >
> > >
> > > > ahci-ati-sb600-sata-support-for-various-modes.patch
> > >
> > > With the PCI quirk, I thought ATI was finally sorted?
> >
> > Was it? I don't know that either.
> >
> > I'll drop these too.
> > -
>
> Hi Jeff, Andrew
> The following patch is ATI's final solution. It was ACKed by Alan.
> Jeff, you're the maintainer of libata, but this patch is based on
> pci/quirks.c, so I don't know who will apply this patch? You or somebody
> else?
> Andrew, could you please drop ATI's previous patch and add this one
> in next -mm patch? The previous patch I sent
> (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
> this one :)
>
>
> Best regards,
> Conke @AMD/ATI

Please send a signed-off-by: for this work, and a changelog which tells us
what it does and why the kernel needs this change.

I shall then remove the ifdef (it's __devinit, and other quirks don't do
this, and vmlinux doesn't know whether or not this driver will later be
loaded) and I shall fix up the word wrapping and I shall convert the spaces
back into tabs and I shall then send it on to Greg, thanks.


> [------------------PATCH------------------]
>
> --- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
> 19:45:49.000000000 +0800
> +++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
> 19:34:23.000000000 +0800
> @@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
> }
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
> PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
> +
> +#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
> +static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
> +{
> + /* set sb600 sata to ahci mode */
> + if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> + u8 tmp;
> +
> + pci_read_config_byte(pdev, 0x40, &tmp);
> + pci_write_config_byte(pdev, 0x40, tmp|1);
> + pci_write_config_byte(pdev, 0x9, 1);
> + pci_write_config_byte(pdev, 0xa, 6);
> + pci_write_config_byte(pdev, 0x40, tmp);
> +
> + pdev->class = 0x010601;
> + }
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
> PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
> +#endif


2006-12-06 23:40:32

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Tue, 5 Dec 2006 21:34:16 +0000 (GMT)
James Simmons <[email protected]> wrote:

> Here you go. This patch places the backlight before the framebuffers. You
> will now be able to select using the backlight with various framebuffer
> drivers.

This doesn't work right for me. x86_64 allmodconfig enables
CONFIG_FB_ATY_BACKLIGHT but fails to enable FB_BACKLIGHT so things won't
build.

drivers/video/aty/atyfb_base.c: In function 'aty_bl_get_level_brightness':
drivers/video/aty/atyfb_base.c:2130: error: 'struct fb_info' has no member named 'bl_curve'

I'm not sure how to fix it, either. Are things like
CONFIG_FB_ATY_BACKLIGHT _really_ supposed to be pmac-only?

menuconfig says:

Symbol: FB_BACKLIGHT [=FB_BACKLIGHT]
Selected by: PMAC_BACKLIGHT && (PPC || MAC) && ADB_PMU && FB=y && (BROKEN || !PPC64)


Surely CONFIG_FB_ATY_BACKLIGHT should depend upon FB_BACKLIGHT?

How come I have CONFIG_BACKLIGHT_CLASS_DEVICE and things like that but
CONFIG_FB_BACKLIGHT=n?

And a `make oldconfig' says

drivers/macintosh/Kconfig:126:warning: 'select' used by config symbol 'PMAC_BACKLIGHT' refer to undefined symbol 'FB_BACKLIGHT'


Here's what allmodconfig gave:

akpm2:/usr/src/25> grep BACKL .config
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA_BACKLIGHT=y
CONFIG_FB_RADEON_BACKLIGHT=y
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY_BACKLIGHT=y


Anyway, it seems all screwed up - I'll drop the patch.

2006-12-07 14:31:39

by James Simmons

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


> Anyway, it seems all screwed up - I'll drop the patch.

I'm working on a new patch. The build system has changed quite a bit
from the last time I worked with it 2 years ago.

2006-12-08 14:16:10

by Stephen Smalley

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Mon, 2006-12-04 at 20:40 -0800, Andrew Morton wrote:
> mprotect-patch-for-use-by-slim.patch
> integrity-service-api-and-dummy-provider.patch
> integrity-service-api-and-dummy-provider-cleanup-use-of-configh.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-main-patch-misc-cleanups-requested-at-inclusion-time.patch
> slim-main-patch-handle-failure-to-register.patch
> slim-main-patch-fix-bug-with-mm_users-usage.patch
> slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch
> slim-secfs-patch.patch
> slim-secfs-patch-slim-correct-use-of-snprintf.patch
> slim-secfs-patch-cleanup-use-of-configh.patch
> slim-make-and-config-stuff.patch
> slim-make-and-config-stuff-makefile-fix.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
> fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch
>
> Shall hold in -mm.

Why? I haven't seen any evidence that prior review comments have been
addressed so far, and a fresh patch set would be beneficial anyway to
facilitate full review of the updated code and to allow them to fix
their patch descriptions as well (as they were wrong in some instances,
describing older versions of the code).

--
Stephen Smalley
National Security Agency

2006-12-08 18:31:22

by Steve French (smfltc)

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

akpm wrote:
>deprecate-smbfs-in-favour-of-cifs.patch
>deprecate-smbfs-in-favour-of-cifs-docs.patch
>
> Am still waiting to hear from sfrench on the appropriateness of this.


smbfs deprecation is ok but there are a few things to consider:
1) Secure mounts: although more secure mounts are possible now to
Windows (not just Samba) with the most recent NTLMv2 patch in the cifs
tree, implementation of Kerberized mounts are stuck in debates about the
right upcall mechanisms (gssapi/spnego blobs can be almost 64K in size,
and userspace turned out to need to keep state across a sequence of two
to three
upcalls before discarding its state which complicates things). smbfs
can handle
kerberos mounts in some cases so this is critical, even though in
practice ntlmv2
is often good enough.

2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support
cifs is better in many cases than smbfs for this now, but cifs does
not handle utimes() remotely to them yet ie setting date/time the old
style
DOS or OS/2 way (cifs can of course query the time fine). This may not
matter
for most cases and would be pretty easy to finish up

3) Documentation - minor cifs vs. smbfs differences in
syntax/behavior. I have
added some of this to the cifs documentation .odt file but have not
posted the
pdf yet nor updated the shorter fs/cifs/README with some of this
helpful information (differences in syntax to help users migrating from
smbfs).
I will post that to the cifs project site as PDF and .ODT this weekend.

4) Hot bugs ... For most users we should be ok here, but there is one major
unresolved bug that worries me: the cache_reap bug ("sleeping function
called from invalid context" in list_del+0x9/0x6c)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214622
Not sure whose bug that will turn out to be and ACPI settings seem to
affect it but it obviously affects some 2.6.19 users.

Running simple tests on smbfs, I run into so many problems now though, it
is probably time to mark it as deprecated as Fedora etc. apparently
already have.

2006-12-08 21:02:15

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Fri, 08 Dec 2006 09:09:34 -0500
Stephen Smalley <[email protected]> wrote:

> On Mon, 2006-12-04 at 20:40 -0800, Andrew Morton wrote:
> > mprotect-patch-for-use-by-slim.patch
> > integrity-service-api-and-dummy-provider.patch
> > integrity-service-api-and-dummy-provider-cleanup-use-of-configh.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-main-patch-misc-cleanups-requested-at-inclusion-time.patch
> > slim-main-patch-handle-failure-to-register.patch
> > slim-main-patch-fix-bug-with-mm_users-usage.patch
> > slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch
> > slim-secfs-patch.patch
> > slim-secfs-patch-slim-correct-use-of-snprintf.patch
> > slim-secfs-patch-cleanup-use-of-configh.patch
> > slim-make-and-config-stuff.patch
> > slim-make-and-config-stuff-makefile-fix.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
> > fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch
> >
> > Shall hold in -mm.
>
> Why?

They're on hold awaiting further development and awaiting a merge/no-merge
decision.

They're not causing me any trouble.

> I haven't seen any evidence that prior review comments have been
> addressed so far, and a fresh patch set would be beneficial anyway to
> facilitate full review of the updated code and to allow them to fix
> their patch descriptions as well (as they were wrong in some instances,
> describing older versions of the code).

If/when the developers start doing more work, we can then decide whether
to use incremental patches or to take a drop-them-and-start-again approach.

(If a whole new patch series comes out, I have tricks which allow me to
check that none of the above fixup patches got lost. Those tricks don't
work if I drop all the patches first)

But yes, it has been pretty quiet. If there's no intention to proceed with
these patches, someone please tell me.

2006-12-08 21:39:39

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Fri, 08 Dec 2006 12:32:05 -0600
Steve French <[email protected]> wrote:

> akpm wrote:
> >deprecate-smbfs-in-favour-of-cifs.patch
> >deprecate-smbfs-in-favour-of-cifs-docs.patch
> >
> > Am still waiting to hear from sfrench on the appropriateness of this.
>
>
> smbfs deprecation is ok but there are a few things to consider:

OK, thanks for the update. We would like to make smbfs go away asap, but
from my POV it's up to you to say when we should do that.

otoh, it might be a good idea to merge a variant of that patch which
doesn't mention a specific data. Say,

if (warn_count < 5) {
warn_count++;
printk(KERN_EMERG "smbfs is not being maintained."
" Please migrate to cifs\n");
}

?

>
> ...
>
> Running simple tests on smbfs, I run into so many problems now though, it
> is probably time to mark it as deprecated as Fedora etc. apparently
> already have.

No, smbfs is not in very good shape.


2006-12-09 09:30:21

by Randy Dunlap

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote:

> kconfig-new-function-bool-conf_get_changedvoid.patch
> kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch
> kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch
> kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch
> pa-risc-fix-bogus-warnings-from-modpost.patch
> kconfig-refactoring-for-better-menu-nesting.patch
> kbuild-fix-rr-is-now-default.patch
> kbuild-dont-put-temp-files-in-the-source-tree.patch
> actually-delete-the-as-instr-ld-option-tmp-file.patch
>
> Sent to Sam, but Sam's presently busy. I might need to make some kbuild
> decisions..

<groan> /me digs thru 65 KB email.


I can/will help on some of these if you want it...

---
~Randy

2006-12-09 09:44:54

by Andrew Morton

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Sat, 9 Dec 2006 01:30:55 -0800
Randy Dunlap <[email protected]> wrote:

> On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote:
>
> > kconfig-new-function-bool-conf_get_changedvoid.patch
> > kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch
> > kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch
> > kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch
> > pa-risc-fix-bogus-warnings-from-modpost.patch
> > kconfig-refactoring-for-better-menu-nesting.patch
> > kbuild-fix-rr-is-now-default.patch
> > kbuild-dont-put-temp-files-in-the-source-tree.patch
> > actually-delete-the-as-instr-ld-option-tmp-file.patch
> >
> > Sent to Sam, but Sam's presently busy. I might need to make some kbuild
> > decisions..
>
> <groan> /me digs thru 65 KB email.
>
>
> I can/will help on some of these if you want it...
>

feel free. I'm planning on going through the above, see which of then have
a sufficiently high obviousness*urgency product.

2006-12-10 03:22:57

by Chuck Ebbert

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

In-Reply-To: <[email protected]>

On Fri, 08 Dec 2006 12:32:05 -0600, Steve French wrote:

> smbfs deprecation is ok but there are a few things to consider:

> 2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support

How well-tested is the plaintext password support?

By default the /proc/fs/cifs/SecurityFlags setting is 0x7 (MAY_SIGN |
MAY_NTLM | MAYNTLMV2). Trying to connect to an old Samba server
with that, I got a message that the server requested a plain text
password but client support was disabled.

After changing the flags to 0x37 (adding MAY_LANMAN | MAY_PLNTXT),
I got "invalid password." Looking at the ethereal traces, it seemed
that the password was being sent as encrypted Unicode, and the only
way to make it connect was to set the flags to 0x30.

Also, the client doesn't automatically pick up the domain name from
smb.conf like smbfs does.

--
Chuck
"Even supernovas have their duller moments."

2006-12-10 15:07:20

by Mimi Zohar

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20


Andrew Morton <[email protected]> wrote on 12/08/2006 03:58:51 PM:

> > > Shall hold in -mm.
> > Why?
>
> They're on hold awaiting further development and awaiting a
merge/no-merge
> They're not causing me any trouble.

Thank you! We are getting ready to re-release EVM as an integrity
provider. As this version of EVM will not be using the LSM hooks,
which mailing list should we be posting the code?

As for SLIM, we will be addressing Stephen's comments and
submitting changes as necessary shortly thereafter.

Mimi Zohar

2006-12-10 20:11:56

by Randy Dunlap

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Sat, 9 Dec 2006 01:44:45 -0800 Andrew Morton wrote:

> On Sat, 9 Dec 2006 01:30:55 -0800
> Randy Dunlap <[email protected]> wrote:
>
> > On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote:
> >
> > > kconfig-new-function-bool-conf_get_changedvoid.patch
> > > kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch
> > > kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch
> > > kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch
> > > pa-risc-fix-bogus-warnings-from-modpost.patch
> > > kconfig-refactoring-for-better-menu-nesting.patch
> > > kbuild-fix-rr-is-now-default.patch
> > > kbuild-dont-put-temp-files-in-the-source-tree.patch
> > > actually-delete-the-as-instr-ld-option-tmp-file.patch
> > >
> > > Sent to Sam, but Sam's presently busy. I might need to make some kbuild
> > > decisions..
> >
> > <groan> /me digs thru 65 KB email.
> >
> >
> > I can/will help on some of these if you want it...
> >
>
> feel free. I'm planning on going through the above, see which of then have
> a sufficiently high obviousness*urgency product.

I see that you merged a few (or one?) of these. (obvious ones)

My review didn't come up with much help, I'm afraid. And you
already asked for help on the series-of-4 gui-config patches.


actually-delete-the-as-instr-ld-option-tmp-file.patch
I couldn't find this patch.

pa-risc-fix-bogus-warnings-from-modpost.patch
looks obvious w/ medium priority

I'm little help on the Makefile changes, sorry.

My -git15 build finds lots of Section mismatch problems with
.parainstructions. These could be false reports that need a
change in modpost (section checker). I'll look into that
later today.

---
~Randy

2006-12-11 04:18:16

by Steve French (smfltc)

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Chuck Ebbert wrote:
> In-Reply-To: <[email protected]>
>
> On Fri, 08 Dec 2006 12:32:05 -0600, Steve French wrote:
>
>
>> smbfs deprecation is ok but there are a few things to consider:
>>
>
> How well-tested is the plaintext password support?
>
> By default the /proc/fs/cifs/SecurityFlags setting is 0x7 (MAY_SIGN |
> MAY_NTLM | MAYNTLMV2). Trying to connect to an old Samba server
> with that, I got a message that the server requested a plain text
> password but client support was disabled.
>
> After changing the flags to 0x37 (adding MAY_LANMAN | MAY_PLNTXT),
> I got "invalid password." Looking at the ethereal traces, it seemed
> that the password was being sent as encrypted Unicode, and the only
> way to make it connect was to set the flags to 0x30.
>
I don't remember any problems reported with plain text password
support on current cifs and I have certainly seen it negotiated with no
problem,
but I will double check with your reported flag combination.
> Also, the client doesn't automatically pick up the domain name from
> smb.conf like smbfs does.
>
>
That is true, and is intentional. cifs sends a domain of null (ie use
the server's
default domain) - but it can be overridden on mount

2006-12-11 09:39:26

by Chuck Ebbert

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

In-Reply-To: <[email protected]>

On Sun, 10 Dec 2006 22:19:04 -0600, Steve French wrote:

> I don't remember any problems reported with plain text password
> support on current cifs and I have certainly seen it negotiated with no
> problem,
> but I will double check with your reported flag combination.

I played around with it some more.

With SecurityFlags = 0x7 (default) the server asks for a plaintext
password and the client refuses. That's fine.

With 0x37 the client agrees to send a plaintext password (or at least
fails to reject the server's request for one,) but actually sends:

< ANSI Password Length: 24
< Unicode Password Length: 24

< ANSI Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C
< Unicode Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C

(my password was aaaaaaaa). This fails with error -13 (invalid password.)

With 0x30 the client sends:

> Password Length: 24

> Password: 61616161616161610000000000000000681C1DCF00002200

and everything works.

> > Also, the client doesn't automatically pick up the domain name from
> > smb.conf like smbfs does.
> >
> >
> That is true, and is intentional. cifs sends a domain of null (ie use
> the server's
> default domain) - but it can be overridden on mount

That's OK then. I just happened to notice it when I was comparing
traces of smbfs mounts to the ones from cifs. Maybe the manpage should
mention this difference for those who are converting, though.

--
MBTI: IXTP

2006-12-12 17:49:20

by Dave Jones

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Tue, Dec 05, 2006 at 11:02:50AM -0500, Dave Jones wrote:
> On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:
>
> > cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch
> > remove-hotplug-cpu-crap-from-cpufreq.patch
> > cpufreq-select-consistently-re-2619-rc5-mm1.patch
> > cpufreq-set-policy-curfreq-on-initialization.patch
> > bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch
> >
> > Sent to cpufreq maintainer
>
> I'm travelling right now, and somehow managed to oops my home router
> 3000 miles away making it hard for me to access mail & stuff.
> (That "page count went negative" BUG() bit me when I did a killall -9 vpnc)

Finally managed to fish this out of the logs..


Eeek! page_mapcount(page) went negative! (-2)
page->flags = 404
page->count = 1
page->mapping = 00000000
------------[ cut here ]------------
kernel BUG at mm/rmap.c:587!
invalid opcode: 0000 [#2]
SMP
last sysfs file: /class/net/lo/type
Modules linked in: tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6 ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU: 0
EIP: 0060:[<c046396c>] Not tainted VLI
EFLAGS: 00010246 (2.6.18-1.2849.fc6 #1)
EIP is at page_remove_rmap+0x8b/0xac
eax: 00000000 ebx: c1000000 ecx: ffffffff edx: 00000046
esi: dcaa2f98 edi: 00000020 ebp: cd3f7f00 esp: cd3e4ddc
ds: 007b es: 007b ss: 0068
Process vpnc (pid: 3367, ti=cd3e4000 task=cd3a0b50 task.ti=cd3e4000)
Stack: c0638bad 00000000 c1000000 09bc0000 c045e199 00000000 dcaa2f98 cd3e4e54
003ebff8 00000000 00000001 09bdb000 cd377098 c1624a80 c13e5f60 fffffffa
ffffffff c1624ad4 cd377098 09bdb000 00000000 cd3e4e54 c1485d4c c1624a80
Call Trace:
[<c045e199>] unmap_vmas+0x28e/0x504
[<c0460c0f>] exit_mmap+0x77/0xf1
[<c0422d75>] mmput+0x34/0x7a
[<c0427818>] do_exit+0x20b/0x776
[<c0427df9>] sys_exit_group+0x0/0xd
[<cd39a644>] 0xcd39a644
DWARF2 unwinder stuck at 0xcd39a644
Leftover inexact backtrace:
[<c0615375>] do_page_fault+0x0/0x4db
[<c0430828>] get_signal_to_deliver+0x38b/0x3b3
[<c04068d1>] do_IRQ+0xb0/0xbc
[<c0615375>] do_page_fault+0x0/0x4db
[<c0403626>] do_notify_resume+0x7e/0x6c1
[<c045f135>] __handle_mm_fault+0x82c/0x860
[<c04068d1>] do_IRQ+0xb0/0xbc
[<c061455e>] _spin_unlock_irq+0x5/0x7
[<c0612ccc>] schedule+0x960/0x9dd
[<c0615375>] do_page_fault+0x0/0x4db
[<c04040a2>] work_notifysig+0x13/0x19
=======================
Code: 82 1e fc ff 8b 43 10 c7 04 24 ad 8b 63 c0 89 44 24 04 e8 6f 1e fc ff 8b 46 40 85 c0 74 0d 8b 50 08 b8 c6 8b 63 c0 e8 07 ce fd ff <0f> 0b 4b 02 42 8b 63 c0 8b 53 10 89 d8 59 5b 5b 5e 83 f2 01 83
EIP: [<c046396c>] page_remove_rmap+0x8b/0xac SS:ESP 0068:cd3e4ddc
<3>BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():1, irqs_disabled():0
[<c04051db>] dump_trace+0x69/0x1af
[<c0405339>] show_trace_log_lvl+0x18/0x2c
[<c04058ed>] show_trace+0xf/0x11
[<c04059ea>] dump_stack+0x15/0x17
[<c04394a2>] down_read+0x12/0x20
[<c0431601>] blocking_notifier_call_chain+0xe/0x29
[<c0427628>] do_exit+0x1b/0x776
[<c040588e>] die+0x29d/0x2c2
[<c0405fd3>] do_invalid_op+0xa2/0xab
[<c0404b85>] error_code+0x39/0x40
DWARF2 unwinder stuck at error_code+0x39/0x40
Leftover inexact backtrace:
[<c046396c>] page_remove_rmap+0x8b/0xac
[<c045e199>] unmap_vmas+0x28e/0x504
[<c0460c0f>] exit_mmap+0x77/0xf1
[<c0422d75>] mmput+0x34/0x7a
[<c0427818>] do_exit+0x20b/0x776
[<c042f153>] __dequeue_signal+0x151/0x15c
[<c0615375>] do_page_fault+0x0/0x4db
[<c0427df9>] sys_exit_group+0x0/0xd
[<c0615375>] do_page_fault+0x0/0x4db
[<c0430828>] get_signal_to_deliver+0x38b/0x3b3
[<c04068d1>] do_IRQ+0xb0/0xbc
[<c0615375>] do_page_fault+0x0/0x4db
[<c0403626>] do_notify_resume+0x7e/0x6c1
[<c045f135>] __handle_mm_fault+0x82c/0x860
[<c04068d1>] do_IRQ+0xb0/0xbc
[<c061455e>] _spin_unlock_irq+0x5/0x7
[<c0612ccc>] schedule+0x960/0x9dd
[<c0615375>] do_page_fault+0x0/0x4db
[<c04040a2>] work_notifysig+0x13/0x19
=======================
Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: vpnc/0x00000001/3367
[<c04051db>] dump_trace+0x69/0x1af
[<c0405339>] show_trace_log_lvl+0x18/0x2c
[<c04058ed>] show_trace+0xf/0x11
[<c04059ea>] dump_stack+0x15/0x17
[<c06123af>] schedule+0x43/0x9dd
[<c04276f7>] do_exit+0xea/0x776
[<c040588e>] die+0x29d/0x2c2
[<c0405fd3>] do_invalid_op+0xa2/0xab
[<c0404b85>] error_code+0x39/0x40
DWARF2 unwinder stuck at error_code+0x39/0x40
Leftover inexact backtrace:
[<c046396c>] page_remove_rmap+0x8b/0xac
[<c045e199>] unmap_vmas+0x28e/0x504
[<c0460c0f>] exit_mmap+0x77/0xf1
[<c0422d75>] mmput+0x34/0x7a
[<c0427818>] do_exit+0x20b/0x776
[<c042f153>] __dequeue_signal+0x151/0x15c
[<c0615375>] do_page_fault+0x0/0x4db
[<c0427df9>] sys_exit_group+0x0/0xd
[<c0615375>] do_page_fault+0x0/0x4db
[<c0430828>] get_signal_to_deliver+0x38b/0x3b3
[<c04068d1>] do_IRQ+0xb0/0xbc
[<c0615375>] do_page_fault+0x0/0x4db
[<c0403626>] do_notify_resume+0x7e/0x6c1
[<c045f135>] __handle_mm_fault+0x82c/0x860
[<c04068d1>] do_IRQ+0xb0/0xbc
[<c061455e>] _spin_unlock_irq+0x5/0x7
[<c0612ccc>] schedule+0x960/0x9dd
[<c0615375>] do_page_fault+0x0/0x4db
[<c04040a2>] work_notifysig+0x13/0x19
=======================


That was from a 2.6.18.3 kernel iirc.

Dave

--
http://www.codemonkey.org.uk

2006-12-12 20:46:41

by john stultz

[permalink] [raw]
Subject: [RFC] HZ free ntp

On Wed, 2006-12-06 at 15:33 +0100, Roman Zippel wrote:
> On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > i disagree with you and it's pretty low-impact anyway. There's still
> > quite many HZ/tick assumptions all around the time code (NTP being one
> > example), we'll deal with those via other patches.
>
> Why do you pick on the NTP code? That's actually one of the places where
> assumptions about HZ are largely gone. NTP state is updated incrementally
> and this won't change, but the update frequency can now be easily
> disconnected from HZ.

Hey Roman,
Here's my rough first attempt at doing so. I'd not call it easy, but
maybe you have some suggestions for a simpler way?

Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that the
time code will use to accumulate with. In this patch I've pushed it out
to a full second, but it could be set via config (NSEC_PER_SEC/HZ for
regular systems, something larger for systems using dynticks).

Thoughts?

-john


diff --git a/include/linux/timex.h b/include/linux/timex.h
index db501dc..be13daf 100644
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -286,9 +286,10 @@ #endif /* !CONFIG_TIME_INTERPOLATION */

#define TICK_LENGTH_SHIFT 32

-/* Returns how long ticks are at present, in ns / 2^(SHIFT_SCALE-10). */
-extern u64 current_tick_length(void);
+#define INTERVAL_LENGTH_NSEC (NSEC_PER_SEC)

+/* Returns how long NTP intervals are at present, in ns / 2^(SHIFT_SCALE-10).*/
+extern u64 ntp_interval_length(void);
extern void second_overflow(void);
extern void update_ntp_one_tick(void);
extern int do_adjtimex(struct timex *);
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index d0ba190..53979a9 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -127,12 +127,14 @@ EXPORT_SYMBOL_GPL(ktime_get_ts);
*/
static void hrtimer_get_softirq_time(struct hrtimer_base *base)
{
+ struct timespec ts;
ktime_t xtim, tomono;
unsigned long seq;

do {
seq = read_seqbegin(&xtime_lock);
- xtim = timespec_to_ktime(xtime);
+ getnstimeofday(&ts);
+ xtim = timespec_to_ktime(ts);
tomono = timespec_to_ktime(wall_to_monotonic);

} while (read_seqretry(&xtime_lock, seq));
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 3afeaa3..812c56f 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -20,11 +20,12 @@ #include <asm/timex.h>
*/
unsigned long tick_usec = TICK_USEC; /* USER_HZ period (usec) */
unsigned long tick_nsec; /* ACTHZ period (nsec) */
-static u64 tick_length, tick_length_base;
+static u64 interval_length, interval_length_base;

#define MAX_TICKADJ 500 /* microsecs */
-#define MAX_TICKADJ_SCALED (((u64)(MAX_TICKADJ * NSEC_PER_USEC) << \
- TICK_LENGTH_SHIFT) / HZ)
+#define MAX_TICKADJ_SCALED \
+ ((((u64)MAX_TICKADJ * NSEC_PER_USEC * INTERVAL_LENGTH_NSEC) \
+ / NSEC_PER_SEC)<< TICK_LENGTH_SHIFT)

/*
* phase-lock loop variables
@@ -44,15 +45,45 @@ #define CLOCK_TICK_OVERFLOW (LATCH * HZ
#define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC) / \
(s64)CLOCK_TICK_RATE)

+/**
+ * ntp_update_frequency - Calculates base values used for NTP adjustments
+ *
+ */
static void ntp_update_frequency(void)
{
- tick_length_base = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);
-
- do_div(tick_length_base, HZ);
-
- tick_nsec = tick_length_base >> TICK_LENGTH_SHIFT;
+ u64 second_length;
+ s64 adj_length;
+ u64 tick_length;
+ int neg = 0;
+ /* calculate the length of one NTP adjusted second */
+ second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ);
+ second_length += (s64)CLOCK_TICK_ADJUST;
+ adj_length = (s64)time_freq;
+
+ /* calculate tick length @ HZ*/
+ tick_length = (second_length << TICK_LENGTH_SHIFT)
+ + (adj_length << (TICK_LENGTH_SHIFT - SHIFT_NSEC));
+ do_div(tick_length, HZ);
+ tick_nsec = tick_length >> TICK_LENGTH_SHIFT;
+
+
+ /* calculate interval_length_base */
+ /* XXX - this is broken up to avoid 64bit overlfows */
+ interval_length_base = second_length * INTERVAL_LENGTH_NSEC;
+ interval_length_base <<= 2;
+ do_div(interval_length_base, NSEC_PER_SEC);
+ interval_length_base <<= TICK_LENGTH_SHIFT-2;
+
+ if (adj_length < 0) {
+ neg = 1;
+ adj_length = -adj_length;
+ }
+ adj_length *= INTERVAL_LENGTH_NSEC;
+ do_div(adj_length, NSEC_PER_SEC);
+ adj_length <<= (TICK_LENGTH_SHIFT - SHIFT_NSEC);
+ if(neg)
+ adj_length = -adj_length;
+ interval_length_base += adj_length;
}

/**
@@ -69,7 +100,7 @@ void ntp_clear(void)

ntp_update_frequency();

- tick_length = tick_length_base;
+ interval_length = interval_length_base;
time_offset = 0;
}

@@ -148,37 +179,39 @@ void second_overflow(void)
* Compute the phase adjustment for the next second. The offset is
* reduced by a fixed factor times the time constant.
*/
- tick_length = tick_length_base;
+ interval_length = interval_length_base;
time_adj = shift_right(time_offset, SHIFT_PLL + time_constant);
time_offset -= time_adj;
- tick_length += (s64)time_adj << (TICK_LENGTH_SHIFT - SHIFT_UPDATE);
+ interval_length += (s64)time_adj << (TICK_LENGTH_SHIFT - SHIFT_UPDATE);

if (unlikely(time_adjust)) {
if (time_adjust > MAX_TICKADJ) {
time_adjust -= MAX_TICKADJ;
- tick_length += MAX_TICKADJ_SCALED;
+ interval_length += MAX_TICKADJ_SCALED;
} else if (time_adjust < -MAX_TICKADJ) {
time_adjust += MAX_TICKADJ;
- tick_length -= MAX_TICKADJ_SCALED;
+ interval_length -= MAX_TICKADJ_SCALED;
} else {
- tick_length += (s64)(time_adjust * NSEC_PER_USEC /
- HZ) << TICK_LENGTH_SHIFT;
+ u64 adjlen = ((s64)time_adjust * NSEC_PER_USEC
+ * INTERVAL_LENGTH_NSEC) << TICK_LENGTH_SHIFT;
+ do_div(adjlen, NSEC_PER_SEC);
+ interval_length += adjlen;
time_adjust = 0;
}
}
}

/*
- * Return how long ticks are at the moment, that is, how much time
- * update_wall_time_one_tick will add to xtime next time we call it
+ * Return how long NTP intervals are at the moment, that is, how
+ * much time update_wall_time will add to xtime next time we call it
* (assuming no calls to do_adjtimex in the meantime).
* The return value is in fixed-point nanoseconds shifted by the
* specified number of bits to the right of the binary point.
* This function has no side-effects.
*/
-u64 current_tick_length(void)
+u64 ntp_interval_length(void)
{
- return tick_length;
+ return interval_length;
}


diff --git a/kernel/timer.c b/kernel/timer.c
index 0256ab4..3a9f2b4 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -890,7 +890,7 @@ void __init timekeeping_init(void)
ntp_clear();

clock = clocksource_get_next();
- clocksource_calculate_interval(clock, tick_nsec);
+ clocksource_calculate_interval(clock, INTERVAL_LENGTH_NSEC);
clock->cycle_last = clocksource_read(clock);

write_sequnlock_irqrestore(&xtime_lock, flags);
@@ -980,7 +980,7 @@ static __always_inline int clocksource_b
* Now calculate the error in (1 << look_ahead) ticks, but first
* remove the single look ahead already included in the error.
*/
- tick_error = current_tick_length() >>
+ tick_error = ntp_interval_length() >>
(TICK_LENGTH_SHIFT - clock->shift + 1);
tick_error -= clock->xtime_interval >> 1;
error = ((error - tick_error) >> look_ahead) + tick_error;
@@ -1077,7 +1077,7 @@ #endif
>> clock->shift);

/* accumulate error between NTP and clock interval */
- clock->error += current_tick_length();
+ clock->error += ntp_interval_length();
clock->error -= clock->xtime_interval << (TICK_LENGTH_SHIFT - clock->shift);
}

@@ -1092,7 +1092,7 @@ #endif
if (change_clocksource()) {
clock->error = 0;
clock->xtime_nsec = 0;
- clocksource_calculate_interval(clock, tick_nsec);
+ clocksource_calculate_interval(clock, INTERVAL_LENGTH_NSEC);
}
}




2006-12-13 01:20:36

by Chuck Ebbert

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

In-Reply-To: <[email protected]>

On Tue, 12 Dec 2006 12:49:09 -0500, Dave Jones wrote:

> EFLAGS: 00010246 (2.6.18-1.2849.fc6 #1)

> That was from a 2.6.18.3 kernel iirc.

Here's an idea from Michael Tokarev <[email protected]>:
since .version always contains 1 when you build an RPM,
you can modify it and put your base kernel version there
during the build. Then you would see:

EFLAGS: 00010246 (2.6.18-1.2849.fc6 #2.6.18.3)

--
MBTI: IXTP

2006-12-13 09:54:09

by Ingo Molnar

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp


* john stultz <[email protected]> wrote:

> On Wed, 2006-12-06 at 15:33 +0100, Roman Zippel wrote:
> > On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > > i disagree with you and it's pretty low-impact anyway. There's still
> > > quite many HZ/tick assumptions all around the time code (NTP being one
> > > example), we'll deal with those via other patches.
> >
> > Why do you pick on the NTP code? That's actually one of the places where
> > assumptions about HZ are largely gone. NTP state is updated incrementally
> > and this won't change, but the update frequency can now be easily
> > disconnected from HZ.
>
> Hey Roman,
> Here's my rough first attempt at doing so. I'd not call it easy, but
> maybe you have some suggestions for a simpler way?
>
> Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that
> the time code will use to accumulate with. In this patch I've pushed
> it out to a full second, but it could be set via config
> (NSEC_PER_SEC/HZ for regular systems, something larger for systems
> using dynticks).

cool! I'll give this one a go in -rt, combined with the exponential
second-overflow patch. (that one is now algorithmically safe, right?)

Ingo

2006-12-13 13:58:45

by Roman Zippel

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

Hi,

On Tue, 12 Dec 2006, john stultz wrote:

> Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that the
> time code will use to accumulate with. In this patch I've pushed it out
> to a full second, but it could be set via config (NSEC_PER_SEC/HZ for
> regular systems, something larger for systems using dynticks).

Why do you want to use such an interval? This makes everything only more
complicated.
The largest possible interval is freq cycles (or 1 second without
adjustments). That is the base interval and without redesigning NTP we
can't change that. This base interval can be subdivided into smaller
intervals for incremental updates.
You cannot choose arbitrary intervals otherwise you get other problems,
e.g. with your patch time_offset handling is broken.

> + /* calculate the length of one NTP adjusted second */
> + second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ);
> + second_length += (s64)CLOCK_TICK_ADJUST;
> + adj_length = (s64)time_freq;
> +
> + /* calculate tick length @ HZ*/
> + tick_length = (second_length << TICK_LENGTH_SHIFT)
> + + (adj_length << (TICK_LENGTH_SHIFT - SHIFT_NSEC));
> + do_div(tick_length, HZ);
> + tick_nsec = tick_length >> TICK_LENGTH_SHIFT;
> +
> +
> + /* calculate interval_length_base */
> + /* XXX - this is broken up to avoid 64bit overlfows */
> + interval_length_base = second_length * INTERVAL_LENGTH_NSEC;
> + interval_length_base <<= 2;
> + do_div(interval_length_base, NSEC_PER_SEC);
> + interval_length_base <<= TICK_LENGTH_SHIFT-2;

You don't have to introduce anything new, it's tick_length that changes
and HZ that becomes a variable in this function.

bye, Roman

2006-12-13 18:49:00

by john stultz

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

On Wed, 2006-12-13 at 10:51 +0100, Ingo Molnar wrote:
> * john stultz <[email protected]> wrote:
>
> > On Wed, 2006-12-06 at 15:33 +0100, Roman Zippel wrote:
> > > On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > > > i disagree with you and it's pretty low-impact anyway. There's still
> > > > quite many HZ/tick assumptions all around the time code (NTP being one
> > > > example), we'll deal with those via other patches.
> > >
> > > Why do you pick on the NTP code? That's actually one of the places where
> > > assumptions about HZ are largely gone. NTP state is updated incrementally
> > > and this won't change, but the update frequency can now be easily
> > > disconnected from HZ.
> >
> > Hey Roman,
> > Here's my rough first attempt at doing so. I'd not call it easy, but
> > maybe you have some suggestions for a simpler way?
> >
> > Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that
> > the time code will use to accumulate with. In this patch I've pushed
> > it out to a full second, but it could be set via config
> > (NSEC_PER_SEC/HZ for regular systems, something larger for systems
> > using dynticks).
>
> cool! I'll give this one a go in -rt, combined with the exponential
> second-overflow patch. (that one is now algorithmically safe, right?)

No, this one will replace the exponential accumulation patch. So we'll
accumulate on second intervals, which should be far enough apart that we
won't be spinning in that loop for long.

thanks
-john


2006-12-13 19:19:17

by john stultz

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

On Wed, 2006-12-13 at 14:47 +0100, Roman Zippel wrote:
> Hi,
>
> On Tue, 12 Dec 2006, john stultz wrote:
>
> > Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that the
> > time code will use to accumulate with. In this patch I've pushed it out
> > to a full second, but it could be set via config (NSEC_PER_SEC/HZ for
> > regular systems, something larger for systems using dynticks).
>
> Why do you want to use such an interval? This makes everything only more
> complicated.
> The largest possible interval is freq cycles (or 1 second without
> adjustments). That is the base interval and without redesigning NTP we
> can't change that. This base interval can be subdivided into smaller
> intervals for incremental updates.

Indeed, larger then 1 second intervals would require the second_overflow
code to be reworked too. However, I'm not proposing larger then 1 second
intervals at this point. I'm just allowing for non-HZ intervals.

> You cannot choose arbitrary intervals otherwise you get other problems,
> e.g. with your patch time_offset handling is broken.

I'm not seeing this yet. Any more details?


> > + /* calculate the length of one NTP adjusted second */
> > + second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ);
> > + second_length += (s64)CLOCK_TICK_ADJUST;
> > + adj_length = (s64)time_freq;
> > +
> > + /* calculate tick length @ HZ*/
> > + tick_length = (second_length << TICK_LENGTH_SHIFT)
> > + + (adj_length << (TICK_LENGTH_SHIFT - SHIFT_NSEC));
> > + do_div(tick_length, HZ);
> > + tick_nsec = tick_length >> TICK_LENGTH_SHIFT;
> > +
> > +
> > + /* calculate interval_length_base */
> > + /* XXX - this is broken up to avoid 64bit overlfows */
> > + interval_length_base = second_length * INTERVAL_LENGTH_NSEC;
> > + interval_length_base <<= 2;
> > + do_div(interval_length_base, NSEC_PER_SEC);
> > + interval_length_base <<= TICK_LENGTH_SHIFT-2;
>
> You don't have to introduce anything new, it's tick_length that changes
> and HZ that becomes a variable in this function.

So, forgive me for rehashing this, but it seems we're cross talking
again. The context here is the dynticks code. Where HZ doesn't change,
but we get interrupts at much reduced rates. The problem is, if the
interrupts slow to ~1 per second frequencies, we end up spending a ton
of time in the main update_wall_time loop, processing that 1 second in
1/HZ chunks. The current code is correct, but just wastes a lot of time.

So I'm trying to come up w/ an approach (the earlier, and broken,
exponential accumulation patch had the same intention), that allows us
to accumulate time in larger chunks. However, in doing so we have to
work w/ the ntp.c code which (as Ingo earlier mentioned) has a number of
HZ based assumptions.

This last patch tries to give NTP and the timekeeping an agreed upon
chunk (I chose "interval" as the term, since "tick" is somewhat
connected to HZ) of time upon which accumulation is done, so we can have
courser second updates, or finer grained updates, depending on config
settings.

In fairness, the patch probably going about this in a less then perfect
way, but that's why I'm asking for your feedback and suggestions. What
are your thoughts for reducing the time spent in the update_wall_time
loop in the context of dynticks?

thanks
-john

2006-12-13 20:44:15

by Roman Zippel

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

Hi,

On Wed, 13 Dec 2006, john stultz wrote:

> > The largest possible interval is freq cycles (or 1 second without
> > adjustments). That is the base interval and without redesigning NTP we
> > can't change that. This base interval can be subdivided into smaller
> > intervals for incremental updates.
>
> Indeed, larger then 1 second intervals would require the second_overflow
> code to be reworked too.

There isn't much to rework without a complete redesign.

> > You cannot choose arbitrary intervals otherwise you get other problems,
> > e.g. with your patch time_offset handling is broken.
>
> I'm not seeing this yet. Any more details?

time_offset is scaled to HZ in do_adjtimex, which needs to be changed as
well.

> > You don't have to introduce anything new, it's tick_length that changes
> > and HZ that becomes a variable in this function.
>
> So, forgive me for rehashing this, but it seems we're cross talking
> again. The context here is the dynticks code. Where HZ doesn't change,
> but we get interrupts at much reduced rates.

I know and all you have to change in the ntp and some related code is to
replace HZ there with a variable, thus make it changable, so you can
increase the update interval (i.e. it becomes 1s/hz instead of 1s/HZ).

> However, in doing so we have to
> work w/ the ntp.c code which (as Ingo earlier mentioned) has a number of
> HZ based assumptions.

Repeating Ingo's nonsense doesn't make it any more true. :-(

bye, Roman

2006-12-19 06:20:40

by Nick Piggin

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Index: linux-2.6/include/linux/rmap.h
===================================================================
--- linux-2.6.orig/include/linux/rmap.h 2006-12-04 19:56:17.000000000 +1100
+++ linux-2.6/include/linux/rmap.h 2006-12-19 16:14:30.000000000 +1100
@@ -72,7 +72,7 @@ void __anon_vma_link(struct vm_area_stru
void page_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
void page_add_new_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
void page_add_file_rmap(struct page *);
-void page_remove_rmap(struct page *);
+void page_remove_rmap(struct page *, struct vm_area_struct *);

/**
* page_dup_rmap - duplicate pte mapping to a page
Index: linux-2.6/mm/filemap_xip.c
===================================================================
--- linux-2.6.orig/mm/filemap_xip.c 2006-12-04 19:07:10.000000000 +1100
+++ linux-2.6/mm/filemap_xip.c 2006-12-19 16:14:30.000000000 +1100
@@ -189,7 +189,7 @@ __xip_unmap (struct address_space * mapp
/* Nuke the page table entry. */
flush_cache_page(vma, address, pte_pfn(*pte));
pteval = ptep_clear_flush(vma, address, pte);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
dec_mm_counter(mm, file_rss);
BUG_ON(pte_dirty(pteval));
pte_unmap_unlock(pte, ptl);
Index: linux-2.6/mm/fremap.c
===================================================================
--- linux-2.6.orig/mm/fremap.c 2006-12-04 19:56:20.000000000 +1100
+++ linux-2.6/mm/fremap.c 2006-12-19 16:14:30.000000000 +1100
@@ -33,7 +33,7 @@ static int zap_pte(struct mm_struct *mm,
if (page) {
if (pte_dirty(pte))
set_page_dirty(page);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);
}
} else {
Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c 2006-12-04 19:56:21.000000000 +1100
+++ linux-2.6/mm/memory.c 2006-12-19 16:14:30.000000000 +1100
@@ -681,7 +681,7 @@ static unsigned long zap_pte_range(struc
mark_page_accessed(page);
file_rss--;
}
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
tlb_remove_page(tlb, page);
continue;
}
@@ -1576,7 +1576,7 @@ gotten:
page_table = pte_offset_map_lock(mm, pmd, address, &ptl);
if (likely(pte_same(*page_table, orig_pte))) {
if (old_page) {
- page_remove_rmap(old_page);
+ page_remove_rmap(old_page, vma);
if (!PageAnon(old_page)) {
dec_mm_counter(mm, file_rss);
inc_mm_counter(mm, anon_rss);
Index: linux-2.6/mm/rmap.c
===================================================================
--- linux-2.6.orig/mm/rmap.c 2006-12-04 19:56:21.000000000 +1100
+++ linux-2.6/mm/rmap.c 2006-12-19 16:20:13.000000000 +1100
@@ -47,6 +47,7 @@
#include <linux/rmap.h>
#include <linux/rcupdate.h>
#include <linux/module.h>
+#include <linux/kallsyms.h>

#include <asm/tlbflush.h>

@@ -567,7 +568,7 @@ void page_add_file_rmap(struct page *pag
*
* The caller needs to hold the pte lock.
*/
-void page_remove_rmap(struct page *page)
+void page_remove_rmap(struct page *page, struct vm_area_struct *vma)
{
if (atomic_add_negative(-1, &page->_mapcount)) {
if (unlikely(page_mapcount(page) < 0)) {
@@ -575,6 +576,9 @@ void page_remove_rmap(struct page *page)
printk (KERN_EMERG " page->flags = %lx\n", page->flags);
printk (KERN_EMERG " page->count = %x\n", page_count(page));
printk (KERN_EMERG " page->mapping = %p\n", page->mapping);
+ print_symbol (KERN_EMERG " vma->vm_ops = %s\n", (unsigned long)vma->vm_ops);
+ if (vma->vm_ops)
+ print_symbol (KERN_EMERG " vma->vm_ops->nopage = %s\n", (unsigned long)vma->vm_ops->nopage);
BUG();
}

@@ -679,7 +683,7 @@ static int try_to_unmap_one(struct page
dec_mm_counter(mm, file_rss);


- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);

out_unmap:
@@ -769,7 +773,7 @@ static void try_to_unmap_cluster(unsigne
if (pte_dirty(pteval))
set_page_dirty(page);

- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);
dec_mm_counter(mm, file_rss);
(*mapcount)--;


Attachments:
mm-rmap-debug-more.patch (4.05 kB)

2006-12-19 06:45:09

by Dave Jones

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote:
> Dave Jones wrote:
>
> > Eeek! page_mapcount(page) went negative! (-2)
>
> Hmm, probably happened once before, too.

You're right. Going back further in the log, I noticed
that it had happened again exactly at the time that cron restarted vpnc.
The first time, the flags were different..

Dec 4 00:01:03 firewall kernel: Eeek! page_mapcount(page) went negative! (-1)
Dec 4 00:01:03 firewall kernel: page->flags = 400
Dec 4 00:01:03 firewall kernel: page->count = 1
Dec 4 00:01:03 firewall kernel: page->mapping = 00000000

> > page->flags = 404
>
> What's that? PG_referenced|PG_reserved? So I'd say it is likely
> that some driver has got its refcounting wrong.

At the time that it bit me, here's what was loaded..

tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac
parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine
via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3
jbd ehci_hcd ohci_hcd uhci_hcd

The scary ones (i2c, irda) weren't in use at all, and had never been opened afaik,
so the potential for those to be corrupting memory is slim, but not out of the
question. (Why the hell asus_acpi is loaded is a mystery, this isn't an Asus,
or a laptop. Probably dumb initscripts).

> And I see we've got another report for 2.6.19.1 from Chris, which
> is equally vague.

I'll be moving that box to 2.6.19.x at some point real soon, so I'll holler
if I see it again on a later kernel.

> IMO the pattern is much too consistent to be able to attribute
> them all to hardware problems. And considering it takes so long
> for these things to appear, can we get something like the attached
> patch upstream at least until we manage to stamp them out?

Sounds like a good idea to me.

ACKed-by: Dave Jones <[email protected]>

> Any other debugging info we can add?

Would it be useful to print the pfn of the page ?
In cases like mine, where it bit twice before it killed the box, it
might be interesting to see if its always the same page. Not sure
what that would prove/disprove though.

Dave

--
http://www.codemonkey.org.uk

2006-12-19 07:03:13

by Nick Piggin

[permalink] [raw]
Subject: Re: -mm merge plans for 2.6.20

Index: linux-2.6/include/linux/rmap.h
===================================================================
--- linux-2.6.orig/include/linux/rmap.h 2006-12-04 19:56:17.000000000 +1100
+++ linux-2.6/include/linux/rmap.h 2006-12-19 16:14:30.000000000 +1100
@@ -72,7 +72,7 @@ void __anon_vma_link(struct vm_area_stru
void page_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
void page_add_new_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
void page_add_file_rmap(struct page *);
-void page_remove_rmap(struct page *);
+void page_remove_rmap(struct page *, struct vm_area_struct *);

/**
* page_dup_rmap - duplicate pte mapping to a page
Index: linux-2.6/mm/filemap_xip.c
===================================================================
--- linux-2.6.orig/mm/filemap_xip.c 2006-12-04 19:07:10.000000000 +1100
+++ linux-2.6/mm/filemap_xip.c 2006-12-19 16:14:30.000000000 +1100
@@ -189,7 +189,7 @@ __xip_unmap (struct address_space * mapp
/* Nuke the page table entry. */
flush_cache_page(vma, address, pte_pfn(*pte));
pteval = ptep_clear_flush(vma, address, pte);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
dec_mm_counter(mm, file_rss);
BUG_ON(pte_dirty(pteval));
pte_unmap_unlock(pte, ptl);
Index: linux-2.6/mm/fremap.c
===================================================================
--- linux-2.6.orig/mm/fremap.c 2006-12-04 19:56:20.000000000 +1100
+++ linux-2.6/mm/fremap.c 2006-12-19 16:14:30.000000000 +1100
@@ -33,7 +33,7 @@ static int zap_pte(struct mm_struct *mm,
if (page) {
if (pte_dirty(pte))
set_page_dirty(page);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);
}
} else {
Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c 2006-12-04 19:56:21.000000000 +1100
+++ linux-2.6/mm/memory.c 2006-12-19 16:14:30.000000000 +1100
@@ -681,7 +681,7 @@ static unsigned long zap_pte_range(struc
mark_page_accessed(page);
file_rss--;
}
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
tlb_remove_page(tlb, page);
continue;
}
@@ -1576,7 +1576,7 @@ gotten:
page_table = pte_offset_map_lock(mm, pmd, address, &ptl);
if (likely(pte_same(*page_table, orig_pte))) {
if (old_page) {
- page_remove_rmap(old_page);
+ page_remove_rmap(old_page, vma);
if (!PageAnon(old_page)) {
dec_mm_counter(mm, file_rss);
inc_mm_counter(mm, anon_rss);
Index: linux-2.6/mm/rmap.c
===================================================================
--- linux-2.6.orig/mm/rmap.c 2006-12-04 19:56:21.000000000 +1100
+++ linux-2.6/mm/rmap.c 2006-12-19 18:02:18.000000000 +1100
@@ -47,6 +47,7 @@
#include <linux/rmap.h>
#include <linux/rcupdate.h>
#include <linux/module.h>
+#include <linux/kallsyms.h>

#include <asm/tlbflush.h>

@@ -567,14 +568,20 @@ void page_add_file_rmap(struct page *pag
*
* The caller needs to hold the pte lock.
*/
-void page_remove_rmap(struct page *page)
+void page_remove_rmap(struct page *page, struct vm_area_struct *vma)
{
if (atomic_add_negative(-1, &page->_mapcount)) {
if (unlikely(page_mapcount(page) < 0)) {
printk (KERN_EMERG "Eeek! page_mapcount(page) went negative! (%d)\n", page_mapcount(page));
+ printk (KERN_EMERG " page pfn = %lx\n", page_to_pfn(page));
printk (KERN_EMERG " page->flags = %lx\n", page->flags);
printk (KERN_EMERG " page->count = %x\n", page_count(page));
printk (KERN_EMERG " page->mapping = %p\n", page->mapping);
+ print_symbol (KERN_EMERG " vma->vm_ops = %s\n", (unsigned long)vma->vm_ops);
+ if (vma->vm_ops)
+ print_symbol (KERN_EMERG " vma->vm_ops->nopage = %s\n", (unsigned long)vma->vm_ops->nopage);
+ if (vma->vm_file && vma->vm_file->f_op)
+ print_symbol (KERN_EMERG " vma->vm_file->f_op->mmap = %s\n", (unsigned long)vma->vm_file->f_op->mmap);
BUG();
}

@@ -679,7 +686,7 @@ static int try_to_unmap_one(struct page
dec_mm_counter(mm, file_rss);


- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);

out_unmap:
@@ -769,7 +776,7 @@ static void try_to_unmap_cluster(unsigne
if (pte_dirty(pteval))
set_page_dirty(page);

- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);
dec_mm_counter(mm, file_rss);
(*mapcount)--;


Attachments:
mm-rmap-debug-more.patch (4.30 kB)

2006-12-20 01:36:15

by john stultz

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

On Wed, 2006-12-13 at 21:40 +0100, Roman Zippel wrote:
> On Wed, 13 Dec 2006, john stultz wrote:
> > > You cannot choose arbitrary intervals otherwise you get other problems,
> > > e.g. with your patch time_offset handling is broken.
> >
> > I'm not seeing this yet. Any more details?
>
> time_offset is scaled to HZ in do_adjtimex, which needs to be changed as
> well.

Ah, thanks! Fixed.

> > > You don't have to introduce anything new, it's tick_length that changes
> > > and HZ that becomes a variable in this function.
> >
> > So, forgive me for rehashing this, but it seems we're cross talking
> > again. The context here is the dynticks code. Where HZ doesn't change,
> > but we get interrupts at much reduced rates.
>
> I know and all you have to change in the ntp and some related code is to
> replace HZ there with a variable, thus make it changable, so you can
> increase the update interval (i.e. it becomes 1s/hz instead of 1s/HZ).

Untested patch below. Does this vibe better with you are suggesting?

Any other suggestions or feedback?

thanks
-john


diff --git a/include/linux/timex.h b/include/linux/timex.h
index db501dc..8241e6e 100644
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -286,6 +286,9 @@ #endif /* !CONFIG_TIME_INTERPOLATION */

#define TICK_LENGTH_SHIFT 32

+#define NTP_INTERVAL_FREQ (HZ)
+#define NTP_INTERVAL_LENGTH (NSEC_PER_SEC/NTP_INTERVAL_FREQ)
+
/* Returns how long ticks are at present, in ns / 2^(SHIFT_SCALE-10). */
extern u64 current_tick_length(void);

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 3afeaa3..eb12509 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -24,7 +24,7 @@ static u64 tick_length, tick_length_base

#define MAX_TICKADJ 500 /* microsecs */
#define MAX_TICKADJ_SCALED (((u64)(MAX_TICKADJ * NSEC_PER_USEC) << \
- TICK_LENGTH_SHIFT) / HZ)
+ TICK_LENGTH_SHIFT) / NTP_INTERVAL_FREQ)

/*
* phase-lock loop variables
@@ -46,13 +46,17 @@ #define CLOCK_TICK_ADJUST (((s64)CLOCK_T

static void ntp_update_frequency(void)
{
- tick_length_base = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);
+ u64 second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ)
+ << TICK_LENGTH_SHIFT;
+ second_length += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
+ second_length += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);

- do_div(tick_length_base, HZ);
+ tick_length_base = second_length;

- tick_nsec = tick_length_base >> TICK_LENGTH_SHIFT;
+ do_div(second_length, HZ);
+ tick_nsec = second_length >> TICK_LENGTH_SHIFT;
+
+ do_div(tick_length_base, NTP_INTERVAL_FREQ);
}

/**
@@ -162,7 +166,7 @@ void second_overflow(void)
tick_length -= MAX_TICKADJ_SCALED;
} else {
tick_length += (s64)(time_adjust * NSEC_PER_USEC /
- HZ) << TICK_LENGTH_SHIFT;
+ NTP_INTERVAL_FREQ) << TICK_LENGTH_SHIFT;
time_adjust = 0;
}
}
@@ -239,7 +243,8 @@ #endif
result = -EINVAL;
goto leave;
}
- time_freq = ((s64)txc->freq * NSEC_PER_USEC) >> (SHIFT_USEC - SHIFT_NSEC);
+ time_freq = ((s64)txc->freq * NSEC_PER_USEC)
+ >> (SHIFT_USEC - SHIFT_NSEC);
}

if (txc->modes & ADJ_MAXERROR) {
@@ -309,7 +314,8 @@ #endif
freq_adj += time_freq;
freq_adj = min(freq_adj, (s64)MAXFREQ_NSEC);
time_freq = max(freq_adj, (s64)-MAXFREQ_NSEC);
- time_offset = (time_offset / HZ) << SHIFT_UPDATE;
+ time_offset = (time_offset / NTP_INTERVAL_FREQ)
+ << SHIFT_UPDATE;
} /* STA_PLL */
} /* txc->modes & ADJ_OFFSET */
if (txc->modes & ADJ_TICK)
@@ -324,8 +330,10 @@ leave: if ((time_status & (STA_UNSYNC|ST
if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
txc->offset = save_adjust;
else
- txc->offset = shift_right(time_offset, SHIFT_UPDATE) * HZ / 1000;
- txc->freq = (time_freq / NSEC_PER_USEC) << (SHIFT_USEC - SHIFT_NSEC);
+ txc->offset = shift_right(time_offset, SHIFT_UPDATE)
+ * NTP_INTERVAL_FREQ / 1000;
+ txc->freq = (time_freq / NSEC_PER_USEC)
+ << (SHIFT_USEC - SHIFT_NSEC);
txc->maxerror = time_maxerror;
txc->esterror = time_esterror;
txc->status = time_status;
diff --git a/kernel/timer.c b/kernel/timer.c
index 0256ab4..616b7fd 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -890,7 +890,7 @@ void __init timekeeping_init(void)
ntp_clear();

clock = clocksource_get_next();
- clocksource_calculate_interval(clock, tick_nsec);
+ clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
clock->cycle_last = clocksource_read(clock);

write_sequnlock_irqrestore(&xtime_lock, flags);
@@ -1092,7 +1092,7 @@ #endif
if (change_clocksource()) {
clock->error = 0;
clock->xtime_nsec = 0;
- clocksource_calculate_interval(clock, tick_nsec);
+ clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
}
}



2006-12-20 01:57:56

by john stultz

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

On Tue, 2006-12-19 at 17:32 -0800, john stultz wrote:
> On Wed, 2006-12-13 at 21:40 +0100, Roman Zippel wrote:
> > On Wed, 13 Dec 2006, john stultz wrote:
> > > > You don't have to introduce anything new, it's tick_length that changes
> > > > and HZ that becomes a variable in this function.
> > >
> > > So, forgive me for rehashing this, but it seems we're cross talking
> > > again. The context here is the dynticks code. Where HZ doesn't change,
> > > but we get interrupts at much reduced rates.
> >
> > I know and all you have to change in the ntp and some related code is to
> > replace HZ there with a variable, thus make it changable, so you can
> > increase the update interval (i.e. it becomes 1s/hz instead of 1s/HZ).
>
> Untested patch below. Does this vibe better with you are suggesting?

And here would be the follow on patch (again *untested*) for
CONFIG_NO_HZ slowing the time accumulation down to once per second.

thanks
-john


diff --git a/include/linux/timex.h b/include/linux/timex.h
index 8241e6e..3beb539 100644
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -286,7 +286,11 @@ #endif /* !CONFIG_TIME_INTERPOLATION */

#define TICK_LENGTH_SHIFT 32

+#ifdef CONFIG_NO_HZ
+#define NTP_INTERVAL_FREQ (1)
+#else
#define NTP_INTERVAL_FREQ (HZ)
+#endif
#define NTP_INTERVAL_LENGTH (NSEC_PER_SEC/NTP_INTERVAL_FREQ)

/* Returns how long ticks are at present, in ns / 2^(SHIFT_SCALE-10). */
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index d0ba190..53979a9 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -127,12 +127,14 @@ EXPORT_SYMBOL_GPL(ktime_get_ts);
*/
static void hrtimer_get_softirq_time(struct hrtimer_base *base)
{
+ struct timespec ts;
ktime_t xtim, tomono;
unsigned long seq;

do {
seq = read_seqbegin(&xtime_lock);
- xtim = timespec_to_ktime(xtime);
+ getnstimeofday(&ts);
+ xtim = timespec_to_ktime(ts);
tomono = timespec_to_ktime(wall_to_monotonic);

} while (read_seqretry(&xtime_lock, seq));


2006-12-21 04:26:51

by Andrew Morton

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

On Tue, 19 Dec 2006 17:54:18 -0800
john stultz <[email protected]> wrote:

> On Tue, 2006-12-19 at 17:32 -0800, john stultz wrote:
> > On Wed, 2006-12-13 at 21:40 +0100, Roman Zippel wrote:
> > > On Wed, 13 Dec 2006, john stultz wrote:
> > > > > You don't have to introduce anything new, it's tick_length that changes
> > > > > and HZ that becomes a variable in this function.
> > > >
> > > > So, forgive me for rehashing this, but it seems we're cross talking
> > > > again. The context here is the dynticks code. Where HZ doesn't change,
> > > > but we get interrupts at much reduced rates.
> > >
> > > I know and all you have to change in the ntp and some related code is to
> > > replace HZ there with a variable, thus make it changable, so you can
> > > increase the update interval (i.e. it becomes 1s/hz instead of 1s/HZ).
> >
> > Untested patch below. Does this vibe better with you are suggesting?
>
> And here would be the follow on patch (again *untested*) for
> CONFIG_NO_HZ slowing the time accumulation down to once per second.

I'm still awaiting a final-looking version of this patch, fyi.

I don't understand whether this is a theoretical might-happen thing,
or if NTP problems have actually been observed in the field?

Either way, I'm sure the final changelog will clear that up ;)

2007-01-01 19:23:15

by Roman Zippel

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

Hi,

On Wednesday 20 December 2006 02:32, john stultz wrote:

> > I know and all you have to change in the ntp and some related code is to
> > replace HZ there with a variable, thus make it changable, so you can
> > increase the update interval (i.e. it becomes 1s/hz instead of 1s/HZ).
>
> Untested patch below. Does this vibe better with you are suggesting?

Yes, thanks.
tick_nsec doesn't require special treatment, in the middle term it's obsolete
anyway, it could be replaced with (current_tick_length() >>
TICK_LENGTH_SHIFT) and current_tick_length() being inlined.
NTP_INTERVAL_FREQ could be a real variable (so it can be initialized at
runtime), it's already gone from all important paths.
In the short term I'd prefered a clock would store its frequency instead of
using NTP_INTERVAL_LENGTH in clocksource_calculate_interval(), so it doesn't
has to be derived there.

bye, Roman

2007-01-01 19:28:51

by Roman Zippel

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

On Wednesday 20 December 2006 02:54, john stultz wrote:

> And here would be the follow on patch (again *untested*) for
> CONFIG_NO_HZ slowing the time accumulation down to once per second.

Changing it to one creates a potential problem with calling second_overflow().
It should be called every NTP_INTERVAL_FREQ times, but occasionally it's off
by one (when xtime is close to a full second and the tick length is different
from 1sec). At a higher frequency that's not much of a problem, but at one it
means second_overflow() is occasionally called twice a second or skipped for
a second. Usually the error should be quite small, but sometimes it can be
significant.
So in this case the loop in update_wall_time() should rather look like this:

while (offset >= clock->cycle_interval) {
...
second_overflow();
while (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) {
clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift;
xtime.tv_sec++;
}
...
}

(Also note the change from "if" to "while".)

Another problem area is that the clock shift value might need adjustments,
since when you reduce the update frequency, it also increases the error
adjustment steps and thus influences the jitter. This is especially important
if we want to synchronize the TSC on multiple cpu's.

bye, Roman

2007-01-02 19:46:19

by john stultz

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

On Mon, 2007-01-01 at 17:27 +0100, Roman Zippel wrote:
> On Wednesday 20 December 2006 02:32, john stultz wrote:
>
> > > I know and all you have to change in the ntp and some related code is to
> > > replace HZ there with a variable, thus make it changable, so you can
> > > increase the update interval (i.e. it becomes 1s/hz instead of 1s/HZ).
> >
> > Untested patch below. Does this vibe better with you are suggesting?
>
> Yes, thanks.
> tick_nsec doesn't require special treatment, in the middle term it's obsolete
> anyway, it could be replaced with (current_tick_length() >>
> TICK_LENGTH_SHIFT) and current_tick_length() being inlined.

If NTP_INTERVAL_FREQ is different then HZ, then tick_nsec still has a
different meaning then (current_tick_length() >> TICK_LENGTH_SHIFT).
So since tick_nsec is still used in quite a few places, so I'm hesitant
to pull it.

> NTP_INTERVAL_FREQ could be a real variable (so it can be initialized at
> runtime), it's already gone from all important paths.

Wait, so you're suggesting NTP_INTERVAL_FREQ be a dynamic variable
instead of a constant? Curious, could you give a bit more detail on why?

> In the short term I'd prefered a clock would store its frequency instead of
> using NTP_INTERVAL_LENGTH in clocksource_calculate_interval(), so it doesn't
> has to be derived there.

I don't follow this at all. clocksources do store their own frequency
(via mult/shift). Could you explain?

thanks
-john

2007-01-02 19:50:30

by john stultz

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

On Mon, 2007-01-01 at 19:29 +0100, Roman Zippel wrote:
> On Wednesday 20 December 2006 02:54, john stultz wrote:
>
> > And here would be the follow on patch (again *untested*) for
> > CONFIG_NO_HZ slowing the time accumulation down to once per second.
>
> Changing it to one creates a potential problem with calling second_overflow().
> It should be called every NTP_INTERVAL_FREQ times, but occasionally it's off
> by one (when xtime is close to a full second and the tick length is different
> from 1sec). At a higher frequency that's not much of a problem, but at one it
> means second_overflow() is occasionally called twice a second or skipped for
> a second. Usually the error should be quite small, but sometimes it can be
> significant.
> So in this case the loop in update_wall_time() should rather look like this:
>
> while (offset >= clock->cycle_interval) {
> ...
> second_overflow();
> while (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) {
> clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift;
> xtime.tv_sec++;
> }
> ...
> }
>
> (Also note the change from "if" to "while".)

Ah, good catch! Thank you, I'll add that, retest and send it to akpm.

thanks
-john



2007-01-02 20:55:23

by john stultz

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

On Tue, 2007-01-02 at 11:46 -0800, john stultz wrote:
> On Mon, 2007-01-01 at 19:29 +0100, Roman Zippel wrote:
> > On Wednesday 20 December 2006 02:54, john stultz wrote:
> >
> > > And here would be the follow on patch (again *untested*) for
> > > CONFIG_NO_HZ slowing the time accumulation down to once per second.
> >
> > Changing it to one creates a potential problem with calling second_overflow().

Wait, at first I thought I understood this, but looking closer, I'm not
so sure I do.

> > It should be called every NTP_INTERVAL_FREQ times, but occasionally it's off

Wait, so second_overflow should be called every NTP_INTERVAL_FREQ times
(instead of every second)? Surely that's not right.

> > by one (when xtime is close to a full second and the tick length is different
> > from 1sec). At a higher frequency that's not much of a problem, but at one it
> > means second_overflow() is occasionally called twice a second or skipped for
> > a second. Usually the error should be quite small, but sometimes it can be
> > significant.
> > So in this case the loop in update_wall_time() should rather look like this:
> >
> > while (offset >= clock->cycle_interval) {
> > ...
> > second_overflow();
> > while (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) {
> > clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift;
> > xtime.tv_sec++;
> > }
> > ...
> > }
> >
> > (Also note the change from "if" to "while".)

This would assume that clock->cycle_interval would *always* be the
length of a full second and that isn't what the patch trying to do.

Maybe could you explain this some more?

thanks
-john


2007-01-07 02:09:11

by Roman Zippel

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

Hi,

On Tuesday 02 January 2007 20:42, john stultz wrote:

> > tick_nsec doesn't require special treatment, in the middle term it's
> > obsolete anyway, it could be replaced with (current_tick_length() >>
> > TICK_LENGTH_SHIFT) and current_tick_length() being inlined.
>
> If NTP_INTERVAL_FREQ is different then HZ, then tick_nsec still has a
> different meaning then (current_tick_length() >> TICK_LENGTH_SHIFT).
> So since tick_nsec is still used in quite a few places, so I'm hesitant
> to pull it.

The current usage under arch is pretty much bogus and they likely can't use
dyntick anyway, so it would be easier to disable tick_nsec completely if
dyntick is enabled.

> > NTP_INTERVAL_FREQ could be a real variable (so it can be initialized at
> > runtime), it's already gone from all important paths.
>
> Wait, so you're suggesting NTP_INTERVAL_FREQ be a dynamic variable
> instead of a constant? Curious, could you give a bit more detail on why?

We already have more than enough config options, where the user has barely any
idea what to do, so we should try to configure and initialize as much as
possible at runtime depending on what the hardware is capable of.

That reminds me that the main problem left for a dynamic variable is
time_offset. It should become a 64 bit value, so SHIFT_UPDATE isn't needed
anymore. Right now it depends on HZ to maximize the value range.

> > In the short term I'd prefered a clock would store its frequency instead
> > of using NTP_INTERVAL_LENGTH in clocksource_calculate_interval(), so it
> > doesn't has to be derived there.
>
> I don't follow this at all. clocksources do store their own frequency
> (via mult/shift). Could you explain?

mult is not a constant and calculating the frequency like this is not very
precise.

bye, Roman

2007-01-07 02:09:13

by Roman Zippel

[permalink] [raw]
Subject: Re: [RFC] HZ free ntp

Hi,

On Tuesday 02 January 2007 21:50, john stultz wrote:

> > > It should be called every NTP_INTERVAL_FREQ times, but occasionally
> > > it's off
>
> Wait, so second_overflow should be called every NTP_INTERVAL_FREQ times
> (instead of every second)? Surely that's not right.

But it is, that's the reason the various adjustment values are divided by it,
so they are applied to the next NTP_INTERVAL_FREQ times.

BTW I think NTP_INTERVAL_FREQ isn't the right name, CLOCK_UPDATE_FREQ would be
a better name, currently ntp is the main user, but a clock can also be
updated via other means (e.g. adjtimex or another clock).

> > > So in this case the loop in update_wall_time() should rather look like
> > > this:
> > >
> > > while (offset >= clock->cycle_interval) {
> > > ...
> > > second_overflow();
> > > while (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) {
> > > clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift;
> > > xtime.tv_sec++;
> > > }
> > > ...
> > > }
> > >
> > > (Also note the change from "if" to "while".)
>
> This would assume that clock->cycle_interval would *always* be the
> length of a full second and that isn't what the patch trying to do.
>
> Maybe could you explain this some more?

As I said this was the case for a value of one.
Anyway, to avoid these problems, I'd prefer to keep it at least at 2 or better
at 4. This would still drastically reduce the time spent in the loop and we
can revisit the issue later.

bye, Roman

2007-01-07 17:36:29

by Dave Jones

[permalink] [raw]
Subject: Re: page_mapcount(page) went negative

On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote:
> Dave Jones wrote:
>
> > Eeek! page_mapcount(page) went negative! (-2)
>
> Hmm, probably happened once before, too.
>
> > page->flags = 404
>
> What's that? PG_referenced|PG_reserved? So I'd say it is likely
> that some driver has got its refcounting wrong.
>
> Unfortunately, this debugging output is almost useless when it
> comes to trying to track down the problem any further.
>
> And I see we've got another report for 2.6.19.1 from Chris, which
> is equally vague.
>
> IMO the pattern is much too consistent to be able to attribute
> them all to hardware problems. And considering it takes so long
> for these things to appear, can we get something like the attached
> patch upstream at least until we manage to stamp them out? Any
> other debugging info we can add?

I finally got another trace out of a 2.6.19.1 with this debug patch..
I'm starting to wonder if this is hardware related.
That box makes me suspicious as its motherboard has a bunch
of bulging capacitors on it. I had three of these, the previous
two died like so: http://www.flickr.com/photos/kernelslacker/251807263/in/set-72157594298237090/
This board hasn't started 'oozing' yet, but I think it may be on
the cards.

iirc, the previous oopses were around the same time of morning,
whilst cron.daily was hammering the hell out of the disk.
Either there's a subtle bug, or this board just can't take the pressure.

Dave

Jan 7 04:24:35 firewall kernel: Eeek! page_mapcount(page) went negative! (-1)
Jan 7 04:24:35 firewall kernel: page->flags = 414
Jan 7 04:24:35 firewall kernel: page->count = 1
Jan 7 04:24:35 firewall kernel: page->mapping = 00000000
Jan 7 04:24:35 firewall kernel: vma->vm_ops->nopage = filemap_nopage+0x0/0x33e
Jan 7 04:24:35 firewall kernel: ------------[ cut here ]------------
Jan 7 04:24:35 firewall kernel: kernel BUG at mm/rmap.c:581!
Jan 7 04:24:35 firewall kernel: invalid opcode: 0000 [#1]
Jan 7 04:24:35 firewall kernel: SMP
Jan 7 04:24:35 firewall kernel: last sysfs file: /class/net/lo/type
Jan 7 04:24:35 firewall kernel: Modules linked in: tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6 ip_conntrack_netbios_ns ipt_REJECT xt_state i
p_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac parport_pc lp parport sr_mod sg pcspkr i2c_via
pro ide_cd i2c_core 3c59x via_rhine cdrom mii via_ircc irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
Jan 7 04:24:35 firewall kernel: CPU: 0
Jan 7 04:24:35 firewall kernel: EIP: 0060:[<c046d995>] Not tainted VLI
Jan 7 04:24:35 firewall kernel: EFLAGS: 00010286 (2.6.19-1.2886.fc6debug #1)
Jan 7 04:24:35 firewall kernel: EIP is at page_remove_rmap+0x8b/0xac
Jan 7 04:24:35 firewall kernel: eax: 00000034 ebx: c1000000 ecx: c042818c edx: da0b3550
Jan 7 04:24:35 firewall kernel: esi: daecd0c0 edi: 00000020 ebp: cd386140 esp: ce2f4dc4
Jan 7 04:24:35 firewall kernel: ds: 007b es: 007b ss: 0068
Jan 7 04:24:35 firewall kernel: Process zcat (pid: 22721, ti=ce2f4000 task=da0b3550 task.ti=ce2f4000)
Jan 7 04:24:35 firewall kernel: Stack: c066b7b6 00000000 c1000000 08050000 c0467c63 c06c7f10 00000046 00000000
Jan 7 04:24:35 firewall kernel: daecd0c0 ce2f4e44 003f7ffd 00000000 00000001 08055000 cf354080 dde93520
Jan 7 04:24:35 firewall kernel: c1401e80 00000000 fffffff9 dde9358c cf354080 08055000 00000000 ce2f4e44
Jan 7 04:24:35 firewall kernel: Call Trace:
Jan 7 04:24:35 firewall kernel: [<c0467c63>] unmap_vmas+0x2a6/0x536
Jan 7 04:24:35 firewall kernel: [<c046aaa8>] exit_mmap+0x77/0x105
Jan 7 04:24:35 firewall kernel: [<c0425471>] mmput+0x37/0x80
Jan 7 04:24:35 firewall kernel: [<c042a4b5>] do_exit+0x21c/0x7a3
Jan 7 04:24:35 firewall kernel: [<c042aac9>] sys_exit_group+0x0/0xd
Jan 7 04:24:35 firewall kernel: [<c043383d>] get_signal_to_deliver+0x38b/0x3b3
Jan 7 04:24:35 firewall kernel: [<c0403677>] do_notify_resume+0x83/0x6c6
Jan 7 04:24:35 firewall kernel: [<c0404159>] work_notifysig+0x13/0x1a
Jan 7 04:24:35 firewall kernel: [<0804a84e>] 0x804a84e
Jan 7 04:24:35 firewall kernel: =======================
Jan 7 04:24:35 firewall kernel: Code: 4c a4 fb ff 8b 43 10 c7 04 24 b6 b7 66 c0 89 44 24 04 e8 39 a4 fb ff 8b 46 40 85 c0 74 0d 8b 50 08 b8 cf b7 66 c0 e8 d
8 a9 fd ff <0f> 0b 45 02 4b b7 66 c0 8b 53 10 89 d8 59 5b 5b 5e 83 f2 01 83
Jan 7 04:24:35 firewall kernel: EIP: [<c046d995>] page_remove_rmap+0x8b/0xac SS:ESP 0068:ce2f4dc4
Jan 7 04:24:35 firewall kernel: <3>BUG: sleeping function called from invalid context at kernel/rwsem.c:20
Jan 7 04:24:35 firewall kernel: in_atomic():1, irqs_disabled():0
Jan 7 04:24:35 firewall kernel: [<c0405108>] dump_trace+0x69/0x1b6
Jan 7 04:24:35 firewall kernel: [<c040526d>] show_trace_log_lvl+0x18/0x2c
Jan 7 04:24:35 firewall kernel: [<c0405868>] show_trace+0xf/0x11
Jan 7 04:24:35 firewall kernel: [<c0405965>] dump_stack+0x15/0x17
Jan 7 04:24:35 firewall kernel: [<c043ccca>] down_read+0x15/0x4e
Jan 7 04:24:35 firewall kernel: [<c04345b6>] blocking_notifier_call_chain+0xe/0x29
Jan 7 04:24:35 firewall kernel: [<c042a2b4>] do_exit+0x1b/0x7a3
Jan 7 04:24:35 firewall kernel: [<c0405809>] die+0x2c3/0x2e8
Jan 7 04:24:35 firewall kernel: [<c0405d4a>] do_invalid_op+0xa2/0xab
Jan 7 04:24:35 firewall kernel: [<c063f7a1>] error_code+0x39/0x40
Jan 7 04:24:35 firewall kernel: [<c046d995>] page_remove_rmap+0x8b/0xac
Jan 7 04:24:35 firewall kernel: [<c0467c63>] unmap_vmas+0x2a6/0x536
Jan 7 04:24:35 firewall kernel: [<c046aaa8>] exit_mmap+0x77/0x105
Jan 7 04:24:35 firewall kernel: [<c0425471>] mmput+0x37/0x80
Jan 7 04:24:35 firewall kernel: [<c042a4b5>] do_exit+0x21c/0x7a3
Jan 7 04:24:35 firewall kernel: [<c042aac9>] sys_exit_group+0x0/0xd
Jan 7 04:24:35 firewall kernel: [<c043383d>] get_signal_to_deliver+0x38b/0x3b3
Jan 7 04:24:35 firewall kernel: [<c0403677>] do_notify_resume+0x83/0x6c6
Jan 7 04:24:35 firewall kernel: [<c0404159>] work_notifysig+0x13/0x1a
Jan 7 04:24:35 firewall kernel: [<0804a84e>] 0x804a84e
Jan 7 04:24:35 firewall kernel: =======================
Jan 7 04:24:35 firewall kernel: Fixing recursive fault but reboot is needed!
Jan 7 04:24:35 firewall kernel: BUG: scheduling while atomic: zcat/0x00000001/22721
Jan 7 04:24:35 firewall kernel: [<c0405108>] dump_trace+0x69/0x1b6
Jan 7 04:24:35 firewall kernel: [<c040526d>] show_trace_log_lvl+0x18/0x2c
Jan 7 04:24:35 firewall kernel: [<c0405868>] show_trace+0xf/0x11
Jan 7 04:24:35 firewall kernel: [<c0405965>] dump_stack+0x15/0x17
Jan 7 04:24:35 firewall kernel: [<c063c72f>] __sched_text_start+0x4f/0xa58
Jan 7 04:24:35 firewall kernel: [<c042a397>] do_exit+0xfe/0x7a3
Jan 7 04:24:35 firewall kernel: [<c0405809>] die+0x2c3/0x2e8
Jan 7 04:24:35 firewall kernel: [<c0405d4a>] do_invalid_op+0xa2/0xab
Jan 7 04:24:35 firewall kernel: [<c063f7a1>] error_code+0x39/0x40
Jan 7 04:24:35 firewall kernel: [<c046d995>] page_remove_rmap+0x8b/0xac
Jan 7 04:24:35 firewall kernel: [<c0467c63>] unmap_vmas+0x2a6/0x536
Jan 7 04:24:35 firewall kernel: [<c046aaa8>] exit_mmap+0x77/0x105
Jan 7 04:24:35 firewall kernel: [<c0425471>] mmput+0x37/0x80
Jan 7 04:24:35 firewall kernel: [<c042a4b5>] do_exit+0x21c/0x7a3
Jan 7 04:24:35 firewall kernel: [<c042aac9>] sys_exit_group+0x0/0xd
Jan 7 04:24:35 firewall kernel: [<c043383d>] get_signal_to_deliver+0x38b/0x3b3
Jan 7 04:24:35 firewall kernel: [<c0403677>] do_notify_resume+0x83/0x6c6
Jan 7 04:24:35 firewall kernel: [<c0404159>] work_notifysig+0x13/0x1a
Jan 7 04:24:35 firewall kernel: [<0804a84e>] 0x804a84e
Jan 7 04:24:35 firewall kernel: =======================


--
http://www.codemonkey.org.uk

2007-01-10 23:53:42

by Nick Piggin

[permalink] [raw]
Subject: Re: page_mapcount(page) went negative

Dave Jones wrote:
> On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote:

> > IMO the pattern is much too consistent to be able to attribute
> > them all to hardware problems. And considering it takes so long
> > for these things to appear, can we get something like the attached
> > patch upstream at least until we manage to stamp them out? Any
> > other debugging info we can add?
>
> I finally got another trace out of a 2.6.19.1 with this debug patch..
> I'm starting to wonder if this is hardware related.
> That box makes me suspicious as its motherboard has a bunch
> of bulging capacitors on it. I had three of these, the previous
> two died like so: http://www.flickr.com/photos/kernelslacker/251807263/in/set-72157594298237090/
> This board hasn't started 'oozing' yet, but I think it may be on
> the cards.
>
> iirc, the previous oopses were around the same time of morning,
> whilst cron.daily was hammering the hell out of the disk.
> Either there's a subtle bug, or this board just can't take the pressure.

The reason why I'm inclined to think there might be a kernel bug is that this
bug seems to trigger a disproportionately high number of times if you consider
the frequency of reports vs frequency of reports of bad page state or bad
pte bugs, for example.

> Jan 7 04:24:35 firewall kernel: Eeek! page_mapcount(page) went negative! (-1)
> Jan 7 04:24:35 firewall kernel: page->flags = 414

referenced|dirty|reserved

> Jan 7 04:24:35 firewall kernel: page->count = 1
> Jan 7 04:24:35 firewall kernel: page->mapping = 00000000

OK, so it is !PageAnon. Seems like the file was truncated?! Then it shouldn't
be mapped at all? OTOH the truncate could easily have skipped such a page:
truncate doesn't rely on mapcount like invalidate.

Hmm, it could be invalidated or vmtruncate_range()d, if you've hit the nopage
vs invalidate race. But would that cause the mapcount to skew? I don't see
how...

> Jan 7 04:24:35 firewall kernel: vma->vm_ops->nopage = filemap_nopage+0x0/0x33e

filemap_nopage. Then PG_reserved should not be getting set, AFAIKS.

Might pte corruption have caused us to get completely the wrong page here?



> Jan 7 04:24:35 firewall kernel: ------------[ cut here ]------------
> Jan 7 04:24:35 firewall kernel: kernel BUG at mm/rmap.c:581!
> Jan 7 04:24:35 firewall kernel: invalid opcode: 0000 [#1]
> Jan 7 04:24:35 firewall kernel: SMP
> Jan 7 04:24:35 firewall kernel: last sysfs file: /class/net/lo/type
> Jan 7 04:24:35 firewall kernel: Modules linked in: tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6 ip_conntrack_netbios_ns ipt_REJECT xt_state i
> p_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac parport_pc lp parport sr_mod sg pcspkr i2c_via
> pro ide_cd i2c_core 3c59x via_rhine cdrom mii via_ircc irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
> Jan 7 04:24:35 firewall kernel: CPU: 0
> Jan 7 04:24:35 firewall kernel: EIP: 0060:[<c046d995>] Not tainted VLI
> Jan 7 04:24:35 firewall kernel: EFLAGS: 00010286 (2.6.19-1.2886.fc6debug #1)
> Jan 7 04:24:35 firewall kernel: EIP is at page_remove_rmap+0x8b/0xac
> Jan 7 04:24:35 firewall kernel: eax: 00000034 ebx: c1000000 ecx: c042818c edx: da0b3550
> Jan 7 04:24:35 firewall kernel: esi: daecd0c0 edi: 00000020 ebp: cd386140 esp: ce2f4dc4
> Jan 7 04:24:35 firewall kernel: ds: 007b es: 007b ss: 0068
> Jan 7 04:24:35 firewall kernel: Process zcat (pid: 22721, ti=ce2f4000 task=da0b3550 task.ti=ce2f4000)
> Jan 7 04:24:35 firewall kernel: Stack: c066b7b6 00000000 c1000000 08050000 c0467c63 c06c7f10 00000046 00000000
> Jan 7 04:24:35 firewall kernel: daecd0c0 ce2f4e44 003f7ffd 00000000 00000001 08055000 cf354080 dde93520
> Jan 7 04:24:35 firewall kernel: c1401e80 00000000 fffffff9 dde9358c cf354080 08055000 00000000 ce2f4e44
> Jan 7 04:24:35 firewall kernel: Call Trace:
> Jan 7 04:24:35 firewall kernel: [<c0467c63>] unmap_vmas+0x2a6/0x536
> Jan 7 04:24:35 firewall kernel: [<c046aaa8>] exit_mmap+0x77/0x105
> Jan 7 04:24:35 firewall kernel: [<c0425471>] mmput+0x37/0x80
> Jan 7 04:24:35 firewall kernel: [<c042a4b5>] do_exit+0x21c/0x7a3
> Jan 7 04:24:35 firewall kernel: [<c042aac9>] sys_exit_group+0x0/0xd
> Jan 7 04:24:35 firewall kernel: [<c043383d>] get_signal_to_deliver+0x38b/0x3b3
> Jan 7 04:24:35 firewall kernel: [<c0403677>] do_notify_resume+0x83/0x6c6
> Jan 7 04:24:35 firewall kernel: [<c0404159>] work_notifysig+0x13/0x1a
> Jan 7 04:24:35 firewall kernel: [<0804a84e>] 0x804a84e
> Jan 7 04:24:35 firewall kernel: =======================
> Jan 7 04:24:35 firewall kernel: Code: 4c a4 fb ff 8b 43 10 c7 04 24 b6 b7 66 c0 89 44 24 04 e8 39 a4 fb ff 8b 46 40 85 c0 74 0d 8b 50 08 b8 cf b7 66 c0 e8 d
> 8 a9 fd ff <0f> 0b 45 02 4b b7 66 c0 8b 53 10 89 d8 59 5b 5b 5e 83 f2 01 83


--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com

2007-01-22 19:28:41

by Ingo Molnar

[permalink] [raw]
Subject: [patch] HZ-free NTP


* john stultz <[email protected]> wrote:

> And here would be the follow on patch (again *untested*) for
> CONFIG_NO_HZ slowing the time accumulation down to once per second.

thanks John - i've applied the combined patch below to -rt. It appears
to work fine for me.

Ingo

------------------------>
From: John Stultz <[email protected]>
Subject: [patch] HZ-free NTP

Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that the
time code will use to accumulate with. In this patch I've pushed it out
to a full second, but it could be set via config (NSEC_PER_SEC/HZ for
regular systems, something larger for systems using dynticks).

Signed-off-by: Ingo Molnar <[email protected]>
---
include/linux/timex.h | 4 ++++
kernel/hrtimer.c | 4 +++-
kernel/time/ntp.c | 30 +++++++++++++++++++-----------
kernel/timer.c | 4 ++--
4 files changed, 28 insertions(+), 14 deletions(-)

Index: linux/include/linux/timex.h
===================================================================
--- linux.orig/include/linux/timex.h
+++ linux/include/linux/timex.h
@@ -286,7 +286,11 @@ static inline void time_interpolator_upd

#define TICK_LENGTH_SHIFT 32

+#ifdef CONFIG_NO_HZ
+#define NTP_INTERVAL_FREQ (1)
+#else
#define NTP_INTERVAL_FREQ (HZ)
+#endif
#define NTP_INTERVAL_LENGTH (NSEC_PER_SEC/NTP_INTERVAL_FREQ)

/* Returns how long ticks are at present, in ns / 2^(SHIFT_SCALE-10). */
Index: linux/kernel/hrtimer.c
===================================================================
--- linux.orig/kernel/hrtimer.c
+++ linux/kernel/hrtimer.c
@@ -135,12 +135,14 @@ EXPORT_SYMBOL_GPL(ktime_get_ts);
*/
static void hrtimer_get_softirq_time(struct hrtimer_cpu_base *base)
{
+ struct timespec ts;
ktime_t xtim, tomono;
unsigned long seq;

do {
seq = read_seqbegin(&xtime_lock);
- xtim = timespec_to_ktime(xtime);
+ getnstimeofday(&ts);
+ xtim = timespec_to_ktime(ts);
tomono = timespec_to_ktime(wall_to_monotonic);

} while (read_seqretry(&xtime_lock, seq));
Index: linux/kernel/time/ntp.c
===================================================================
--- linux.orig/kernel/time/ntp.c
+++ linux/kernel/time/ntp.c
@@ -24,7 +24,7 @@ static u64 tick_length, tick_length_base

#define MAX_TICKADJ 500 /* microsecs */
#define MAX_TICKADJ_SCALED (((u64)(MAX_TICKADJ * NSEC_PER_USEC) << \
- TICK_LENGTH_SHIFT) / HZ)
+ TICK_LENGTH_SHIFT) / NTP_INTERVAL_FREQ)

/*
* phase-lock loop variables
@@ -46,13 +46,17 @@ long time_adjust;

static void ntp_update_frequency(void)
{
- tick_length_base = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);
+ u64 second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ)
+ << TICK_LENGTH_SHIFT;
+ second_length += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
+ second_length += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);

- do_div(tick_length_base, HZ);
+ tick_length_base = second_length;

- tick_nsec = tick_length_base >> TICK_LENGTH_SHIFT;
+ do_div(second_length, HZ);
+ tick_nsec = second_length >> TICK_LENGTH_SHIFT;
+
+ do_div(tick_length_base, NTP_INTERVAL_FREQ);
}

/**
@@ -164,7 +168,7 @@ void second_overflow(void)
tick_length -= MAX_TICKADJ_SCALED;
} else {
tick_length += (s64)(time_adjust * NSEC_PER_USEC /
- HZ) << TICK_LENGTH_SHIFT;
+ NTP_INTERVAL_FREQ) << TICK_LENGTH_SHIFT;
time_adjust = 0;
}
}
@@ -241,7 +245,8 @@ int do_adjtimex(struct timex *txc)
result = -EINVAL;
goto leave;
}
- time_freq = ((s64)txc->freq * NSEC_PER_USEC) >> (SHIFT_USEC - SHIFT_NSEC);
+ time_freq = ((s64)txc->freq * NSEC_PER_USEC)
+ >> (SHIFT_USEC - SHIFT_NSEC);
}

if (txc->modes & ADJ_MAXERROR) {
@@ -311,7 +316,8 @@ int do_adjtimex(struct timex *txc)
freq_adj += time_freq;
freq_adj = min(freq_adj, (s64)MAXFREQ_NSEC);
time_freq = max(freq_adj, (s64)-MAXFREQ_NSEC);
- time_offset = (time_offset / HZ) << SHIFT_UPDATE;
+ time_offset = (time_offset / NTP_INTERVAL_FREQ)
+ << SHIFT_UPDATE;
} /* STA_PLL */
} /* txc->modes & ADJ_OFFSET */
if (txc->modes & ADJ_TICK)
@@ -326,8 +332,10 @@ leave: if ((time_status & (STA_UNSYNC|ST
if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
txc->offset = save_adjust;
else
- txc->offset = shift_right(time_offset, SHIFT_UPDATE) * HZ / 1000;
- txc->freq = (time_freq / NSEC_PER_USEC) << (SHIFT_USEC - SHIFT_NSEC);
+ txc->offset = shift_right(time_offset, SHIFT_UPDATE)
+ * NTP_INTERVAL_FREQ / 1000;
+ txc->freq = (time_freq / NSEC_PER_USEC)
+ << (SHIFT_USEC - SHIFT_NSEC);
txc->maxerror = time_maxerror;
txc->esterror = time_esterror;
txc->status = time_status;
Index: linux/kernel/timer.c
===================================================================
--- linux.orig/kernel/timer.c
+++ linux/kernel/timer.c
@@ -1030,7 +1030,7 @@ static void change_clocksource(void)

clock->error = 0;
clock->xtime_nsec = 0;
- clocksource_calculate_interval(clock, tick_nsec);
+ clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);

tick_clock_notify();

@@ -1086,7 +1086,7 @@ void __init timekeeping_init(void)
ntp_clear();

clock = clocksource_get_next();
- clocksource_calculate_interval(clock, tick_nsec);
+ clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
clock->cycle_last = clocksource_read(clock);

xtime.tv_sec = sec;

2007-01-22 19:41:15

by Ingo Molnar

[permalink] [raw]
Subject: Re: [patch] HZ-free NTP


* Ingo Molnar <[email protected]> wrote:

> thanks John - i've applied the combined patch below to -rt. It appears
> to work fine for me.

updated patch below. (previous one was a delta in timex.h)

Ingo

---------------->
From: John Stultz <[email protected]>
Subject: [patch] HZ-free NTP

Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that the
time code will use to accumulate with. In this patch I've pushed it out
to a full second, but it could be set via config (NSEC_PER_SEC/HZ for
regular systems, something larger for systems using dynticks).

Signed-off-by: Ingo Molnar <[email protected]>
---
include/linux/timex.h | 7 +++++++
kernel/hrtimer.c | 4 +++-
kernel/time/ntp.c | 30 +++++++++++++++++++-----------
kernel/timer.c | 4 ++--
4 files changed, 31 insertions(+), 14 deletions(-)

Index: linux/include/linux/timex.h
===================================================================
--- linux.orig/include/linux/timex.h
+++ linux/include/linux/timex.h
@@ -286,6 +286,13 @@ static inline void time_interpolator_upd

#define TICK_LENGTH_SHIFT 32

+#ifdef CONFIG_NO_HZ
+#define NTP_INTERVAL_FREQ (1)
+#else
+#define NTP_INTERVAL_FREQ (HZ)
+#endif
+#define NTP_INTERVAL_LENGTH (NSEC_PER_SEC/NTP_INTERVAL_FREQ)
+
/* Returns how long ticks are at present, in ns / 2^(SHIFT_SCALE-10). */
extern u64 current_tick_length(void);

Index: linux/kernel/hrtimer.c
===================================================================
--- linux.orig/kernel/hrtimer.c
+++ linux/kernel/hrtimer.c
@@ -135,12 +135,14 @@ EXPORT_SYMBOL_GPL(ktime_get_ts);
*/
static void hrtimer_get_softirq_time(struct hrtimer_cpu_base *base)
{
+ struct timespec ts;
ktime_t xtim, tomono;
unsigned long seq;

do {
seq = read_seqbegin(&xtime_lock);
- xtim = timespec_to_ktime(xtime);
+ getnstimeofday(&ts);
+ xtim = timespec_to_ktime(ts);
tomono = timespec_to_ktime(wall_to_monotonic);

} while (read_seqretry(&xtime_lock, seq));
Index: linux/kernel/time/ntp.c
===================================================================
--- linux.orig/kernel/time/ntp.c
+++ linux/kernel/time/ntp.c
@@ -24,7 +24,7 @@ static u64 tick_length, tick_length_base

#define MAX_TICKADJ 500 /* microsecs */
#define MAX_TICKADJ_SCALED (((u64)(MAX_TICKADJ * NSEC_PER_USEC) << \
- TICK_LENGTH_SHIFT) / HZ)
+ TICK_LENGTH_SHIFT) / NTP_INTERVAL_FREQ)

/*
* phase-lock loop variables
@@ -46,13 +46,17 @@ long time_adjust;

static void ntp_update_frequency(void)
{
- tick_length_base = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);
+ u64 second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ)
+ << TICK_LENGTH_SHIFT;
+ second_length += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
+ second_length += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);

- do_div(tick_length_base, HZ);
+ tick_length_base = second_length;

- tick_nsec = tick_length_base >> TICK_LENGTH_SHIFT;
+ do_div(second_length, HZ);
+ tick_nsec = second_length >> TICK_LENGTH_SHIFT;
+
+ do_div(tick_length_base, NTP_INTERVAL_FREQ);
}

/**
@@ -164,7 +168,7 @@ void second_overflow(void)
tick_length -= MAX_TICKADJ_SCALED;
} else {
tick_length += (s64)(time_adjust * NSEC_PER_USEC /
- HZ) << TICK_LENGTH_SHIFT;
+ NTP_INTERVAL_FREQ) << TICK_LENGTH_SHIFT;
time_adjust = 0;
}
}
@@ -241,7 +245,8 @@ int do_adjtimex(struct timex *txc)
result = -EINVAL;
goto leave;
}
- time_freq = ((s64)txc->freq * NSEC_PER_USEC) >> (SHIFT_USEC - SHIFT_NSEC);
+ time_freq = ((s64)txc->freq * NSEC_PER_USEC)
+ >> (SHIFT_USEC - SHIFT_NSEC);
}

if (txc->modes & ADJ_MAXERROR) {
@@ -311,7 +316,8 @@ int do_adjtimex(struct timex *txc)
freq_adj += time_freq;
freq_adj = min(freq_adj, (s64)MAXFREQ_NSEC);
time_freq = max(freq_adj, (s64)-MAXFREQ_NSEC);
- time_offset = (time_offset / HZ) << SHIFT_UPDATE;
+ time_offset = (time_offset / NTP_INTERVAL_FREQ)
+ << SHIFT_UPDATE;
} /* STA_PLL */
} /* txc->modes & ADJ_OFFSET */
if (txc->modes & ADJ_TICK)
@@ -326,8 +332,10 @@ leave: if ((time_status & (STA_UNSYNC|ST
if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
txc->offset = save_adjust;
else
- txc->offset = shift_right(time_offset, SHIFT_UPDATE) * HZ / 1000;
- txc->freq = (time_freq / NSEC_PER_USEC) << (SHIFT_USEC - SHIFT_NSEC);
+ txc->offset = shift_right(time_offset, SHIFT_UPDATE)
+ * NTP_INTERVAL_FREQ / 1000;
+ txc->freq = (time_freq / NSEC_PER_USEC)
+ << (SHIFT_USEC - SHIFT_NSEC);
txc->maxerror = time_maxerror;
txc->esterror = time_esterror;
txc->status = time_status;
Index: linux/kernel/timer.c
===================================================================
--- linux.orig/kernel/timer.c
+++ linux/kernel/timer.c
@@ -1030,7 +1030,7 @@ static void change_clocksource(void)

clock->error = 0;
clock->xtime_nsec = 0;
- clocksource_calculate_interval(clock, tick_nsec);
+ clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);

tick_clock_notify();

@@ -1086,7 +1086,7 @@ void __init timekeeping_init(void)
ntp_clear();

clock = clocksource_get_next();
- clocksource_calculate_interval(clock, tick_nsec);
+ clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
clock->cycle_last = clocksource_read(clock);

xtime.tv_sec = sec;