Discussion:
2.6.29 -mm merge plans
(too old to reply)
Andrew Morton
2009-01-05 08:50:06 UTC
Permalink
The individual patches are mostly at
http://userweb.kernel.org/~akpm/mmotm/broken-out/


mm-remove-the-might_sleep-from-lock_page.patch

Need to think about this.

repeatable-slab-corruption-with-ltp-msgctl08.patch

Probably will drop this now.

acpi-fix-acpi_fadt_s4_rtc_wake-comment.patch
acpi-check-_pss-invalidation-when-bios-report-_pss-with-all-0x80000000.patch
eeepc-laptop-enable-bluetooth-for-asus-eee-901.patch
misc-add-dell-wmi-driver-for-hotkey-control.patch
drivers-acpi-hardware-hwsleepc-fix-warning-msg.patch
kgdb-fix-kernel-doc-error.patch
arm-use-the-new-byteorder-headers.patch
arch-avr32-eliminate-null-test-and-memset-after-alloc_bootmem.patch
dmatest-flush-and-invalidate-destination-buffer-before-dma.patch
pcmcia-pccard-deadlock-fix.patch
powerpc-powermac-add-missing-of_node_put.patch
powerpc-change-u64-s64-to-a-long-long-integer-type.patch
i2c-fix-i2c-mpc-driver-for-multi-master-i2c-busses.patch
clocksource-pass-clocksource-to-read-callback.patch
clocksource-pass-clocksource-to-read-callback-v2.patch
clocksource-pass-clocksource-to-read-callback-v2-fix.patch
clocksource-add-enable-and-disable-callbacks.patch
ia64-use-the-new-byteorder-headers.patch
drivers-input-touchscreen-ucb1400_tsc-needs-gpio.patch
input-touchscreen-driver-add-support-ad7877-touchscreen-driver.patch
serio_raw-add-support-for-translated-serio_i8042xl-ports.patch
input-mousedev-distinguish-a-moving-finger-from-a-tapping-finger.patch
i8042-add-blue-fb5601-to-noloop-execption-table.patch
input-ad7879-touchscreen-driver.patch
input-mouse-alpsc-handle-touchpoints-buttons-correctly.patch
input-ads7846c-sparse-lock-annotation.patch
drivers-input-keyboard-atkbdc-use-function-for-generation-of-keyrelease-events.patch
drivers-input-keyboard-atkbdc-make-forced_release_keys-static.patch
drivers-input-keyboard-atkbdc-fujitsu-siemens-amilo-pa-1510-quirks.patch
input-uvc-the-button-on-the-camera-is-key_camera.patch
input-allow-certain-ev_abs-events-to-bypass-all-filtering.patch
es-input-allow-certain-ev_abs-events-to-bypass-all-filtering-fix.patch
input-add-a-detailed-multi-touch-finger-data-report-protocol-rev2.patch
input-keyboard-hilkbdc-fix-crash-when-removing-hilkbd-module.patch
drivers-input-serio-hp_sdcc-fix-crash-when-removing-hp_sdc-module.patch
leds-ledtrig-timer-on-deactivation-hardware-blinking-should-be-disabled.patch
leds-allow-led-drivers-to-use-a-wider-than-0255-range-of-brightness-values.patch
leds-add-a-dac124s085-spi-led-driver.patch
m32r-kernel-smpbootc-must-include-linux-cpuh.patch
m32r-use-the-new-byteorder-headers.patch
ricoh_mmc-use-suspend-resume_noirq-v2.patch
physmap-make-map_info-customizable.patch
jffs2-force-the-jffs2-gc-daemon-to-behave-a-bit-better.patch
mtd-fix-nettel-printk-formats.patch
net-tipc-bcasth-use-array_size.patch
net-bridge-netfilter-move-a-dereference-below-a-null-test.patch
misdn-indentation-braces-disagree-add-braces.patch
misdn-one-handmade-array_size-converted.patch
misdn-indentation-and-braces-disagree-add-braces.patch
drivers-isdn-hardware-misdn-move-a-dereference-below-a-null-test.patch
forcedeth-fix-mac-address-detection-on-network-card-regression-in-2623.patch
drivers-net-hamradio-6packc-move-a-dereference-below-a-null-test.patch
drivers-net-wireless-libertas-move-a-dereference-below-a-null-test.patch
netdev-gianfar-add-mii-ioctl-handler.patch
video-mbp_nvidia_bl-fix-brightness-after-suspend-hibernation.patch
video-mbp_nvidia_bl-add-support-for-macbook-5-macbook-air-2-and-macbook-pro-5.patch
video-mbp_nvidia_bl-add-support-for-macbook-5-macbook-air-2-and-macbook-pro-5-fix.patch
video-mbp_nvidia_bl-add-a-debug-switch.patch
gpio_free-might-sleep-blackfin-architecture.patch
blackfin-use-the-new-byteorder-headers.patch
ext4-allocate-s_blockgroup_lock-separately.patch
ext4-dont-inherit-inappropriate-inode-flags-from-parent.patch
ext4-tighten-restrictions-on-inode-flags.patch
proc-move-inode-comment-text-file-to-source-file.patch
pci-msi-bugfix-utilize-for-msi_capability_init.patch
fakephp-allocate-pci-resources-before-adding-the-device.patch
aerdrv-fix-sanity-check-in-report_resume.patch
aspm-use-msleep-instead-of-cpu_relax-during-link-retraining.patch
pci-quirks-unhide-overflow-device-on-i828675p-pe-chipsets.patch
pci-quirks-unhide-overflow-device-on-i828675p-pe-chipsets-checkpatch-fixes.patch
pci-quirks-hp-hides-smbus-controller-in-compaq-nx9500-laptops.patch
irq-free-setup_irq-interrupt-using-free_irq.patch
if-0-ses_match_host.patch
scsi-replace-__inline-with-inline.patch
mpt-remove-unused-struct-mpt_proc_entry_t.patch
scsi-use-the-common-hex_asc-array-rather-than-a-private-one.patch
drivers-scsi-a2091c-make-2-functions-static.patch
drivers-scsi-a3000c-make-2-functions-static.patch
scsi-gdthc-use-unaligned-access-helpers.patch
scsi-annotate-gdth_rdcap_data-gdth_rdcap16_data-endianness.patch
esp-fix-section-mismatch-warning.patch
scsi-fix-bad-use-of-udelay-in-atp870uc.patch
libsas-fix-test-for-negative-unsigned-and-typos.patch
drivers-scsi-move-a-dereference-below-a-null-test.patch
drivers-message-fusion-move-a-dereference-below-a-null-test.patch
bio-zero-inlined-bio_vec.patch
sparc64-use-unsigned-long-long-for-u64.patch
sparc64-fix-unsigned-long-long-warnings-in-drivers.patch
radio-si470x-add-usb-id-for-dealextreme-usb-radio.patch
usb-another-unusual_devs-entry-for-another-bad-argosy-storage-device.patch
usb-driver-for-freescale-quicc-engine-usb-host-controller.patch
usb-fsl_qe_udc-fix-oops-on-qe-udc-probe-failure.patch
usb-fsl_qe_udc-fix-recursive-locking-bug-in-ch9getstatus.patch
usb-fsl_qe_udc-fix-qe-usb-controller-initialization.patch
usb-fsl_qe_udc-fix-disconnects-reporting-during-bus-reset.patch
usb-fsl_qe_udc-fix-muram-corruption-by-disabled-endpoints.patch
usb-fsl_qe_udc-fix-stalled-tx-requests-bug.patch
usb-emi26-fix-oops-on-load.patch
vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems.patch
kill-suid-bit-only-for-regular-files.patch
vfs-lseekfd-0-seek_cur-race-condition.patch
raw-fix-rawctl-compat-ioctls-breakage-on-amd64-and-itanic.patch
raw-fix-rawctl-compat-ioctls-breakage-on-amd64-and-itanic-checkpatch-fixes.patch
vfs-factor-out-duplicated-code-in-get_fs_type.patch
inotify-fix-type-errors-in-interfaces.patch
pika-warp-appliance-watchdog-timer.patch

These are all patches which subsystem maintainers slept through. Will
send them to the relevant tree owners.

powerpc-fix-code-for-reserved-memory-spanning-across-nodes.patch

This might be busted.

mm-report-the-pagesize-backing-a-vma-in-proc-pid-smaps.patch
mm-report-the-mmu-pagesize-in-proc-pid-smaps.patch
mm-dont-mark_page_accessed-in-fault-path.patch
mm-dont-mark_page_accessed-in-shmem_fault.patch
mm-rework-do_pages_move-to-work-on-page_sized-chunks.patch
mm-rework-do_pages_move-to-work-on-page_sized-chunks-update.patch
mm-move_pages-no-need-to-set-pp-page-to-zero_page0-by-default.patch
mm-invoke-oom-killer-from-page-fault.patch
mm-invoke-oom-killer-from-page-fault-fix.patch
mm-invoke-oom-killer-from-page-fault-fix-fix-2.patch
oom-fix-zone_scan_mutex-name.patch
oom-print-triggering-tasks-cpuset-and-mems-allowed.patch
oom-print-triggering-tasks-cpuset-and-mems-allowed-fix.patch
do_mpage_readpage-dont-submit-lots-of-small-bios-on-boundary.patch
mm-write_cache_pages-cyclic-fix.patch
mm-write_cache_pages-cyclic-fix-fix.patch
mm-write_cache_pages-early-loop-termination.patch
mm-write_cache_pages-writepage-error-fix.patch
mm-write_cache_pages-integrity-fix.patch
mm-write_cache_pages-cleanups.patch
mm-write_cache_pages-optimise-page-cleaning.patch
mm-write_cache_pages-terminate-quickly.patch
mm-write_cache_pages-more-terminate-quickly.patch
#mm-do_sync_mapping_range-integrity-fix.patch: this sucks
mm-do_sync_mapping_range-integrity-fix.patch
#
mm-show-node-to-memory-section-relationship-with-symlinks-in-sysfs.patch
mm-show-node-to-memory-section-relationship-with-symlinks-in-sysfs-v3.patch
mm-print-out-memmap-number-only-it-is-not-zero.patch
#
mm-get-rid-of-pagevec_release_nonlru.patch
cleanup-get-rid-of-ifdef-config_migration.patch
mm-more-likely-reclaim-madv_sequential-mappings.patch
#
mm-vmalloc-tweak-failure-printk.patch
mm-vmalloc-improve-vmallocinfo.patch
mm-vmalloc-use-mutex-for-purge.patch
mm-vmalloc-make-lazy-unmapping-configurable.patch
#
mm-apply_to_range-call-pte-function-with-lazy-updates.patch
do_mpage_readpage-remove-useless-clear_buffer_mapped-call.patch
#
mm-remove-cgroup_mm_owner_callbacks.patch
mm-remove-gfp_highuser_pagecache.patch
mm-add-setclearpageswapcache-stubs.patch
mm-replace-some-bug_ons-by-vm_bug_ons.patch
mm-add_active_or_unevictable-into-rmap.patch
mm-make-page_lock_anon_vma-static.patch
mm-further-cleanup-page_add_new_anon_rmap.patch
#
mm-page_allocc-eliminate-null-test-and-memset-after-alloc_bootmem.patch
#
mm-change-dirty-limit-type-specifiers-to-unsigned-long.patch
mm-add-dirty_background_bytes-and-dirty_bytes-sysctls.patch
mm-add-dirty_background_bytes-and-dirty_bytes-sysctls-fix.patch
#
mm-gup-persist-for-write-permission.patch
mm-wp-lock-page-before-deciding-cow.patch
mm-reuse_swap_page-replaces-can_share_swap_page.patch
mm-try_to_free_swap-replaces-remove_exclusive_swap_page.patch
mm-try_to_unuse-check-removing-right-swap.patch
mm-remove-try_to_munlock-from-vmscan.patch
mm-remove-gfp_mask-from-add_to_swap.patch
mm-add-add_to_swap-stub.patch
mm-optimize-get_scan_ratio-for-no-swap.patch
#
memcg-reclaim-shouldnt-change-zone-recent_rotated-statistics.patch
#
mm-make-init_section_page_cgroup-static.patch
mm-make-maddr-__iomem.patch
mm-make-mem_cgroup_resize_limit-static.patch
mm-make-scan_all_zones_unevictable_pages-static.patch
mm-make-scan_zone_unevictable_pages-static.patch
mm-make-setup_per_zone_inactive_ratio-static.patch
mm-make-vread-and-vwrite-declaration.patch
#
swapfile-swapon-needs-larger-size-type.patch
swapfile-remove-swp_active-mask.patch
swapfile-remove-surplus-whitespace.patch
swapfile-remove-v0-swap-space-message.patch
swapfile-rearrange-scan-and-swap_info.patch
swapfile-swapon-use-discard-trim.patch
swapfile-swap-allocation-use-discard.patch
swapfile-swapon-randomize-if-nonrot.patch
swapfile-swap-allocation-cycle-if-nonrot.patch
swapfile-change-discard-pgoff_t-to-sector_t.patch
swapfile-change-discard-pgoff_t-to-sector_t-fix.patch
swapfile-let-others-seed-random.patch
#
hugetlb-fix-sparse-warnings.patch
vmscan-bail-out-of-direct-reclaim-after-swap_cluster_max-pages.patch
vmscan-improve-reclaim-throughput-to-bail-out-patch.patch
mm-kill-zone_is_near_oom.patch
fs-truncate-blocks-outside-i_size-after-o_direct-write-error.patch
fs-truncate-blocks-outside-i_size-after-o_direct-write-error-fix.patch
#
badpage-simplify-page_alloc-flag-checkclear.patch
badpage-keep-any-bad-page-out-of-circulation.patch
badpage-replace-page_remove_rmap-eeek-and-bug.patch
badpage-vm_normal_page-use-print_bad_pte.patch
badpage-zap-print_bad_pte-on-swap-and-file.patch
badpage-remove-vma-from-page_remove_rmap.patch
badpage-ratelimit-print_bad_pte-and-bad_page.patch
badpage-kern_alert-bug-instead-of-kern_emerg.patch
#
vmscan-shrink_active_list-reduce-lru_lock-hold-time.patch
hugetlb-unsigned-ret-cannot-be-negative.patch
mm-make-get_user_pages-interruptible.patch
mm-make-get_user_pages-interruptible-mmotm-ignore-sigkill-in-get_user_pages-during-munlock.patch
block_write_begin-remove-useless-goto.patch
shmem-unify-regular-and-tiny-shmem.patch
#
page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch
#
mm-mmapc-fix-coding-style.patch
mm-mmapc-fix-coding-style-fix.patch
#
mm-direct-io-starvation-improvement.patch
fs-remove-wb_sync_hold.patch
fs-sync_sb_inodes-fix.patch
fs-sys_sync-fix.patch
radix-tree-gang-set-if-tagged-operation.patch
#
mm-pagecache-gfp-flags-fix.patch
introduce-get_mm_hiwater_xxx-fix-taskstats-hiwater_xxx-accounting.patch
mm-remove-config_out_of_line_pfn_to_page.patch
mm-kill-page_queue_congested.patch
#mm-shmemc-fix-division-by-zero.patch: hugh probs
mm-shmemc-fix-division-by-zero.patch
mm-check-for-no-mmaps-in-exit_mmap.patch
mm-check-for-no-mmaps-in-exit_mmap-fix.patch

Memory management. Will merge, subject to a bit of final checking.

frv-use-the-new-byteorder-headers.patch
m68knommu-use-the-new-byteorder-headers.patch
m68knommu-set-no_dma.patch
h8300-use-the-new-byteorder-headers.patch
alpha-use-generic-percpu-support.patch
alpha-use-the-new-byteorder-headers.patch
uml-get-rid-of-the-last-symlink-in-uml-build.patch

Architecture things. Will merge.

init-properly-placing-noinline-keyword.patch
atomic_t-unify-all-arch-definitions.patch
pci-use-pci_ioremap_bar-in-drivers-misc.patch
check-fops_get-return-value.patch
oops-handling-ensure-that-any-oops-is-flushed-to-the-mtdoops-console.patch
block-do_mounts-add-device-info-to-mount-message.patch
fs-execc-__bprm_mm_init-clean-up-error-handling.patch
remove-remaining-unwinder-code.patch
forkc-cleanup-for-copy_sighand.patch
linux-ratelimith-fixed-missing-initializer-warning.patch
hp-wmi-handle-rfkill_register-failure.patch
lib-fix-sparse-shadowed-variable-warning.patch
lib-radix_treec-make-percpu-variable-static.patch
lib-proportionsc-trivial-sparse-lock-annotation.patch
create-a-div_round_closest-macro-to-do-division-with-rounding.patch
add-pr_prefix-to-pr_xyz-macros-checkpatch-fixes.patch
samples-mark-static__init__exit-for-initexit-functions.patch
autodetect_raid-add-missing-__init-marking.patch
strict_strto-is-not-strict-enough.patch
#poll-allow-f_op-poll-to-sleep-take-4.patch: Oleg had issues
oops-increment-the-oops-uuid-every-time-we-oops.patch
scripts-script-from-kerneloopsorg-to-pretty-print-oops-dumps.patch
fs-use-menuconfig-to-control-the-misc-filesystems-menu.patch
poll-allow-f_op-poll-to-sleep-take6.patch
documentation-when-to-bug-and-when-to-not-bug.patch
allow-times-and-time-system-calls-to-return-small-negative-values.patch
percpu_counter-fbc_batch-should-be-a-variable.patch
dmitry-has-been-renamed.patch
ioc4-automatically-load-sgiioc4-subordinate-module.patch
ioc4-automatically-load-sgiioc4-subordinate-module-checkpatch-fixes.patch
remove-linux-hardirqh-from-asm-generic-localh.patch
remove-linux-hardirqh-from-asm-generic-localh-add-include-linux-irqflagsh-to-acpi-processor_idlec.patch
remove-linux-hardirqh-from-asm-generic-localh-fix.patch
fs-fix-name-overwrite-in-__register_chrdev_region.patch
smp_call_function_single-be-slightly-less-stupid.patch
add-missing-accounting-calls-to-compat_sys_readvwritev.patch
mark-late_time_init-as-__initdata.patch
sys_execve-and-sys_uselib-do-not-call-into-fsnotify.patch
profile-dont-include-asm-ptraceh-twice.patch
do_coredump-check-return-from-argv_split.patch
sg_io-fix-sg_io_hdrinfo-corruption-in-compat-code.patch
remove-obsolete-config_resources_64bit.patch

Misc. Will merge, subject to re-review.

softirq-introduce-statistics-for-softirq.patch
proc-export-statistics-for-softirq-to-proc.patch
proc-update-document-for-proc-softirqs-and-proc-stat.patch

Will merge.

checkpatch-add-checks-for-in_atomic.patch
checkpatch-comment-detection-may-miss-an-implied-comment-on-the-last-hunk.patch
checkpatch-widen-implied-comment-detection-to-allow-multiple-stars.patch
checkpatch-structure-member-assignments-are-not-complex.patch
checkpatch-__weak-is-an-official-attribute.patch
checkpatch-detect-multiple-bitfield-declarations.patch
checkpatch-comment-ends-inside-strings-is-most-likely-not-an-open-comment.patch
checkpatch-dissallow-spaces-between-stars-in-pointer-types.patch
checkpatch-version-025.patch
#
checkpatch-update-maintainers-entry.patch
checkpatch-update-copyrights.patch
checkpatch-add-warning-for-p0-patches.patch
checkpatch-allow-parentheses-on-return-for-comparisons.patch
checkpatch-try-to-catch-missing-vmlinux_symbol-in-vmlinuxldsh.patch
checkpatch-loosen-spacing-on-typedef-function-checks.patch
checkpatch-fix-continuation-detection-when-handling-spacing-on-operators.patch
checkpatch-track-ifdef-else-endif-when-tracking-blocks.patch
checkpatch-do-not-report-nr_static-as-a-static-declaration.patch
checkpatch-ensure-we-actually-detect-if-assignments-split-across-lines.patch
checkpatch-struct-file_operations-should-normally-be-const.patch
checkpatch-fix-the-perlcritic-errors.patch
checkpatch-version-026.patch

Will merge.

adt7462-70-73-use-div_round_closest-for-rounded-division.patch
lis3lv02d-separate-the-core-from-hp-acpi-api.patch
lis3lv02d-merge-with-leds-hp-disk.patch
adt7470-fix-pwm-at-a-certain-level-during-temperature-sensor-scan.patch
adt7470-observe-the-number-of-temperature-sensors-to-shorten-update-time.patch
adt7470-make-automatic-fan-control-really-work.patch
drivers-macintosh-add-missing-of_node_put-in-therm_adt746xc.patch
hwmon-applesmc-add-support-for-macbook-air-2.patch

hwmon. Will merge.

ibmpex-add-endian-annotation-to-extract_data-helper.patch

Will merge.

binfmtsh-include-listh.patch
binfmtsh-include-listh-fix.patch
fs-binfmt_miscc-add-terminating-newline-to-proc-sys-fs-binfmt_misc-status.patch

binfmt. Will merge.

fs-ncpfs-getoptc-cleanup-keneldoc.patch

Will merge.

pci-use-pci_ioremap_bar-in-drivers-serial.patch
atmel_serial-might-lose-modem-status-change.patch
#serial-add-support-for-the-cell-network-processor-nwp-device.patch: needs update
serial-add-support-for-the-cell-network-processor-nwp-device.patch
serial-add-support-for-the-cell-network-processor-nwp-device-update.patch
8250-add-back-missing-space-from-banner-printk.patch
#
8250_pci-add-support-for-netmos-9835.patch

Serial stuff. Will send to Alan, or will merge. Or something.

#max3100-spi-uart-driver.patch: wait until major number is settled
max3100-spi-uart-driver.patch
max3100-spi-uart-driver-fix.patch
max3100-spi-uart-driver-select-serial_core.patch

afaik this has been stuck for ages due to LANANA sleepiness. Maybe we
should just take that function over.

spi_gpio-driver.patch
spi_gpio-driver-cleanups.patch
atmel_spi-clean-up-spiv1-quirk-handling.patch
spi-atmel_spi-update-chipselect-handling.patch
spi-use-generic-gpio-calls-in-spi_s3c24xx_gpio.patch
drivers-spi-move-a-dereference-below-a-null-test.patch

SPI - will merge.

mfd-da903x-section-fix.patch
sm501-fix-section-mismatches.patch

MFD: send to maintainer.

kprobes-bugfix-try_module_get-even-if-calling_mod-is-null.patch
kprobes-indirectly-call-kprobe_target.patch
kprobes-add-tests-for-register_kprobes.patch
#
module-add-within_module_core-and-within_module_init.patch
kprobes-add-kprobe_insn_mutex-and-cleanup-arch_remove_kprobe.patch
kprobes-add-__kprobes-to-kprobe-internal-functions.patch
kprobes-support-probing-module-__exit-function.patch
kprobes-support-probing-module-__exit-function-fix.patch
kprobes-support-probing-module-__exit-function-fix-2.patch
kprobes-support-probing-module-__exit-function-fix-3.patch
kprobes-remove-called_from-argument.patch
kprobes-remove-called_from-argument-fix.patch
module-add-module_state_live-notify.patch
kprobes-support-probing-module-__init-function.patch

kprobes: will merge.

i2o-remove-extraneous-kernel-doc.patch

Will merge.

drivers-xen-xenbus-xenbus_clientc-cleanup-kerneldoc.patch
xen-add-xenfs-to-allow-usermode-xen-interaction.patch
xen-add-xenfs-to-allow-usermode-xen-interaction-fix-xenbus-message-reads.patch

Send to Jeremy.

ecryptfs-filename-encryption-tag-70-packets.patch
ecryptfs-filename-encryption-header-updates.patch
ecryptfs-filename-encryption-encoding-and-encryption-functions.patch
ecryptfs-filename-encryption-filldir-lookup-and-readlink.patch
ecryptfs-filename-encryption-mount-option.patch
ecryptfs-replace-%z-with-%z.patch
ecryptfs-fix-data-types-int-size_t.patch
ecryptfs-kerneldoc-for-ecryptfs_parse_tag_70_packet.patch
ecryptfs-clean-up-ecryptfs_decode_from_filename.patch
fs-ecryptfs-inodec-cleanup-kerneldoc.patch

Merge.

autofs4-improve-parameter-usage.patch
autofs4-fix-var-shadowed-by-local-delaration.patch
autofs4-make-autofs-type-usage-explicit.patch
autofs4-fix-string-validation-check-order.patch

Merge.

genrtc-disable-genrtc-on-blackfin-systems.patch
rtc-ds1307-smbus-compatibility.patch
rtc-ds1307-remove-legacy-probe-checks.patch
rtc-struct-device-replace-bus_id-with-dev_name-dev_set_name.patch
rtc-bunch-of-drivers-fix-no-irq-case-handing.patch
rtc-move-power-of-2-periodic-frequency-check-down-into-drivers-v2.patch
rtc-driver-for-pxa27x-and-pxa3xx-soc.patch
rtc-pxa27x-pxa3xx-driver-fixes-revised.patch
rtc-rtc-ds1390-probe-sequence-and-misc-fixes.patch
rtc-kconfig-cleanup.patch
rtc-au1000-on-chip-counter0-as-rtc-driver.patch
rtc-au1000-on-chip-counter0-as-rtc-driver-fix.patch
rtc-rtc-max6902-fixes-v3.patch
rtc-rtc-ds3234-fixes-v2.patch
rtc-use-set_mmss-when-set_time-is-not-available.patch
rtc-add-rtc-tx4939-driver-v2.patch
rtc-rtc-ds1216-fixes.patch
rtc-driver-for-marvells-socs-88f6281-and-88f6192.patch
drivers-rtc-correct-an-error-test.patch

RTC. Will merge.

twl4030-gpio-cleanup-debounce.patch
gpio-pca953x-handles-more-chips-i2c-fault-codes.patch

gpio. Will merge.

pci-use-pci_ioremap_bar-in-drivers-video.patch
fbdev-fix-typo-in-drivers-video-modedbc.patch
blackfin-remove-__function__-in-video-driver.patch
fb-carminefb-trivial-annotation-packing-color-register.patch
gbefb-unsigned-var-pixclock-cannot-be-less-than-0.patch
nvidia-fix-sparse-warnings.patch
viafb-fix-sparse-warnings.patch
pm3fb-fix-sparse-warning.patch
neofb-fix-sparse-warnings.patch
i810-fix-sparse-warnings.patch
intelfb-fix-sparse-warnings.patch
sm501-unsigned-ptr-cannot-be-negative.patch
fbdev-logo-check-compatibility-of-main-and-extra-logos.patch

fbdev. Will merge.

intelfb-support-i854.patch

This one might hae DRM problems. Need to check with airlied.

minix-fix-add-links-wrong-position-calculation.patch
minix-fix-add-links-wrong-position-calculation-checkpatch-fixes.patch

Merge.

ext2-fix-ext2_splice_branch-comments.patch
ext2-allocate-s_blockgroup_lock-separately.patch
ext2-dont-inherit-inappropriate-inode-flags-from-parent.patch
ext2-tighten-restrictions-on-inode-flags.patch

Merge.

jbd-improve-fsync-batching.patch
jbd-improve-fsync-batching-update.patch
ext3-allocate-s_blockgroup_lock-separately.patch
ext3-dont-inherit-inappropriate-inode-flags-from-parent.patch
ext3-tighten-restrictions-on-inode-flags.patch

Merge.

coda-fix-fs-coda-sysctlc-build-warnings-when-config_sysctl.patch

Merge.

hfsplus-identify-journal-info-block-in-volume-header.patch
#hfsplus-fix-journal-detection.patch: Roman had q?
hfsplus-fix-journal-detection.patch
#hfs-add-basic-export-support.patch: hch issues
hfs-add-basic-export-support.patch

Need to sort this out with Roman & Christoph.

ufs-sector_t-cannot-be-negative.patch

Send to Evgeniy.

quota-dont-set-grace-time-when-user-isnt-above-softlimit.patch

Merge.

kmod-fix-varargs-kernel-doc.patch
docs-document-how-to-write-varargs-in-kernel-doc.patch
rapidio-remove-excess-kernel-doc-notation.patch
documentation-update-header-file-paths.patch
documentation-update-s390-header-file-paths.patch
documentation-how-to-use-doc-section-blocks.patch
docs-add-more-early-params-to-kernel-parameterstxt.patch
doc-reformat-some-long-lines-in-kernel-parameterstxt.patch

Documentation. Merge.

cgroups-make-cgroup-config-a-submenu.patch
cgroups-documentation-updates.patch
cgroups-remove-some-redundant-null-checks.patch
ns_cgroup-remove-unused-spinlock.patch
memcg-fix-a-typo-in-kconfig.patch
cgroups-add-lock-for-child-cgroups-in-cgroup_post_fork.patch
cgroups-fix-cgroup_iter_next-bug.patch
cgroups-dont-put-struct-cgroupfs_root-protected-by-rcu.patch
cgroups-use-task_lock-for-access-tsk-cgroups-safe-in-cgroup_clone.patch
cgroups-call-find_css_set-safely-in-cgroup_attach_task.patch
cgroups-remove-rcu_read_lock-in-cgroupstats_build.patch
#
cgroups-make-root_list-contains-active-hierarchies-only.patch
cgroups-add-inactive-subsystems-to-rootnodesubsys_list.patch
cgroups-add-inactive-subsystems-to-rootnodesubsys_list-fix.patch
cgroups-introduce-link_css_set-to-remove-duplicate-code.patch
cgroups-introduce-link_css_set-to-remove-duplicate-code-fix.patch
#
cgroups-skip-processes-from-other-namespaces-when-listing-a-cgroup.patch
cgroups-skip-processes-from-other-namespaces-when-listing-a-cgroup-checkpatch-fixes.patch
#
cgroups-make-cgroup_path-rcu-safe.patch
cgroups-make-cgroup_path-rcu-safe-fixlet.patch

cgroups core. Merge.

devcgroup-use-list_for_each_entry_rcu.patch
devices-cgroup-allow-mkfifo.patch

devcgroup. Merge.

memcg-introduce-charge-commit-cancel-style-of-functions.patch
memcg-introduce-charge-commit-cancel-style-of-functions-fix.patch
memcg-fix-gfp_mask-of-callers-of-charge.patch
memcg-simple-migration-handling.patch
memcg-do-not-recalculate-section-unnecessarily-in-init_section_page_cgroup.patch
memcg-move-all-acccounts-to-parent-at-rmdir.patch
#
memcg-reduce-size-of-mem_cgroup-by-using-nr_cpu_ids.patch
memcg-new-force_empty-to-free-pages-under-group.patch
memcg-new-force_empty-to-free-pages-under-group-fix.patch
memcg-new-force_empty-to-free-pages-under-group-fix-fix.patch
memcg-handle-swap-caches.patch
memcg-handle-swap-caches-build-fix.patch
memcg-memswap-controller-kconfig.patch
memcg-swap-cgroup-for-remembering-usage.patch
memcg-memswap-controller-core.patch
memcg-memswap-controller-core-make-resize-limit-hold-mutex.patch
memcg-memswap-controller-core-swapcache-fixes.patch
memcg-synchronized-lru.patch
memcg-add-mem_cgroup_disabled.patch
memcg-add-mem_cgroup_disabled-fix.patch
#
memory-cgroup-hierarchy-documentation-v4.patch
memory-cgroup-resource-counters-for-hierarchy-v4.patch
memory-cgroup-resource-counters-for-hierarchy-v4-checkpatch-fixes.patch
#memory-cgroup-hierarchical-reclaim-v4.patch: Daisuke Nishimura found deadlock
memory-cgroup-hierarchical-reclaim-v4.patch
memory-cgroup-hierarchical-reclaim-v4-checkpatch-fixes.patch
memory-cgroup-hierarchical-reclaim-v4-fix-for-hierarchical-reclaim.patch
memory-cgroup-hierarchy-feature-selector-v4.patch
memory-cgroup-hierarchy-feature-selector-v4-fix.patch
#
memcontrol-rcu_read_lock-to-protect-mm_match_cgroup.patch
#
memcg-avoid-unnecessary-system-wide-oom-killer.patch
memcg-avoid-unnecessary-system-wide-oom-killer-fix.patch
memcg-fix-reclaim-result-checks.patch
#
memcg-revert-gfp-mask-fix.patch
memcg-check-group-leader-fix.patch
memcg-memoryswap-controller-fix-limit-check.patch
memcg-swapout-refcnt-fix.patch
memcg-hierarchy-avoid-unnecessary-reclaim.patch
inactive_anon_is_low-move-to-vmscan.patch
mm-introduce-zone_reclaim-struct.patch
mm-add-zone-nr_pages-helper-function.patch
mm-make-get_scan_ratio-safe-for-memcg.patch
memcg-add-null-check-to-page_cgroup_zoneinfo.patch
memcg-add-inactive_anon_is_low.patch
memcg-add-inactive_anon_is_low-vmscan-style-cleanup.patch
memcg-add-mem_cgroup_zone_nr_pages.patch
memcg-add-zone_reclaim_stat.patch
memcg-add-zone_reclaim_stat-reclaim-stat-trivial-fixes.patch
memcg-add-zone_reclaim_stat-reclaim-stat-trivial-fixes-fix.patch
memcg-remove-mem_cgroup_cal_reclaim.patch
memcg-show-reclaim-stat.patch
memcg-rename-scan-global-lru.patch
memcg-protect-prev_priority.patch
memcg-swappiness.patch
memcg-fix-calclation-of-active_ratio.patch
memcg-fix-calclation-of-active_ratio-build-error-fix.patch
memcg-show-real-limit-under-hierarchy-mode.patch
memcg-explain-details-and-test-document.patch
memcg-explain-details-and-test-document-fix.patch
#
memcg-dont-trigger-oom-at-page-migration.patch
memcg-remove-mem_cgroup_try_charge.patch
memcg-avoid-dead-lock-caused-by-race-between-oom-and-cpuset_attach.patch
memcg-change-try_to_free_pages-to-hierarchical_reclaim.patch
memcg-fix-swap-accounting-leak-v3.patch
memcg-fix-swap-accounting-leak-doc-fix.patch
#
memcg-fix-double-free-and-make-refcnt-sane.patch
memcg-use-css_tryget-in-memcg.patch
memcg-use-css_tryget-in-memcg-fix.patch
memcg-fix-lru-accounting-for-swapcache-v2.patch
memcg-fix-shmems-swap-accounting.patch

memory control group. Merge.

cgroups-add-a-per-subsystem-hierarchy_mutex.patch
cgroups-use-hierarchy_mutex-in-memory-controller.patch
cgroups-add-css_tryget.patch

More cgroups core. Merge.

cpuset-rcu_read_lock-to-protect-task_cs.patch
cpusets-set-tasks-cpu_allowed-to-cpu_possible_map-when-attaching-it-into-top-cpuset.patch

cpusets. Merge.

#cpuset-remove-on-stack-cpumask_t-in-cpuset_sprintf_cpulist.patch: leaky?
cpuset-remove-on-stack-cpumask_t-in-cpuset_sprintf_cpulist.patch
cpuset-remove-on-stack-cpumask_t-in-cpuset_can_attach.patch
cpuset-convert-cpuset_attach-to-use-cpumask_var_t.patch
cpuset-dont-allocate-trial-cpuset-on-stack.patch
cpuset-convert-cpuset-cpus_allowed-to-cpumask_var_t.patch
cpuset-remove-remaining-pointers-to-cpumask_t.patch

More cpusets. Very fresh code, seems to have at least one bug in it.
We'll see.

send_sig_noinfo-masquerade-si_pid-when-crossing-pid-ns-boundary.patch
send_sig_noinfo-set-si_pid-to-tgid-instead-of-pid.patch

Signals. Merge.

coredump_filter-permit-changing-of-the-default-filter.patch
fs-execc-make-do_coredump-void.patch
fs-execc-make-do_coredump-void-checkpatch-fixes.patch

Coredump. Merge.

workqueues-kill-cpu_singlethread_map-use-get_cpu_mask-instead.patch
workqueues-kill-cpu_singlethread_map-use-get_cpu_mask-instead-fix.patch

Workqueues. Merge.

ipc-clean-up-ipc-shmc.patch
ipc-do-not-goto-to-the-next-line.patch
ipc-ipc_sysctlc-move-the-definition-of-ipc_auto_callback.patch

IPC. Merge.

elf-implement-at_random-for-glibc-prng-seeding.patch

elf. Merge.

make-firmware-dsp56k-bootstrapasm-buildable-on-a56.patch
consolemap-indentation-braces-disagree-reindent.patch

Misc char drivers. Merge.

dcdbas-export-functionality-for-use-in-other-drivers.patch

Firmware. merge.

misc-add-dell-laptop-driver.patch

Needs dcdbas-export-functionality-for-use-in-other-drivers.patch.
Will directly merge, I guess.

pid-implement-ns_of_pid.patch
pid-implement-ns_of_pid-update.patch
pid-generalize-task_active_pid_ns.patch
mqueue-fix-si_pid-value-in-mqueue-do_notify.patch

PID namespace. Merge.

random-dont-try-to-look-at-entropy_count-outside-the-lock.patch

Random driver. Merge.

relay-reset-consumed.patch
trace-code-and-documentation.patch
trace-code-and-documentation-merging-documentation-tracetxt-with-documentation-filesystems-relaytxt.patch
trace-sample.patch

Hold. Still awaiting a convincing case for merging this?

pci-use-pci_ioremap_bar-in-drivers-edac.patch
edac-struct-device-replace-bus_id-with-dev_name-dev_set_name.patch
edac-struct-device-replace-bus_id-with-dev_name-dev_set_name-checkpatch-fixes.patch
edac-x38-use-the-architectures-readq-function.patch
edac-x38-use-the-architectures-readq-function-fix.patch
edac-x38-use-the-architectures-readq-function-fix-fix.patch
edac-fix-mpc85xx-and-add-mpc8536-mpc8560.patch
edac-driver-for-i5400-mch.patch
edac-driver-for-i5400-mch-seaburg.patch

EDAC. Merge.

loop-add-ioctl-to-resize-a-loop-device.patch

Loop. Merge.

dma_alloc_from_coherent-fix-fallback-to-generic-memory.patch
dma_alloc_coherent-clean-it-up.patch
dma-coherent-catch-oversized-requests-to-dma_alloc_from_coherent.patch

DMA mapping. Merge.

bfs-add-some-basic-sanity-checks.patch
bfs-check-that-filesystem-fits-on-the-blockdevice.patch

Merge.

parport-ieee1284-use-del_timer_sync-in-parport_wait_event.patch
parport-ieee1284-use-del_timer_sync-in-parport_wait_event-checkpatch-fixes.patch

Merge.

tpm-clean-up-tpm_nsc-driver-for-platform_device-suspend-resume-compliance.patch

Merge.

memstick-annotate-endianness-of-attribute-structs.patch

Send to maintainer.

w1-add-1-wire-master-driver-for-imx27-imx31.patch
w1-add-1-wire-master-driver-for-imx27-imx31-update.patch
w1-add-list-masters-w1-command.patch
w1-add-touch-block-command.patch
w1-list-slaves-commands.patch
w1-documentation-update.patch
#
w1-allow-master-io-commands.patch
w1-allow-master-io-commands-fix.patch
w1-move-w1-commands-from-defines-to-enum.patch
w1-added-w1-reset-command.patch
w1-send-status-messages-after-command-processing.patch

Merge.

vmcore-remove-saved_max_pfn-check.patch

kexec stuff. Merge.

byteorder-add-load_-store_endian-api.patch

Merge.

unaligned-consolidate-unaligned-headers-add-load_-store_endian_noalign.patch
unaligned-wire-up-trivial-arches-for-new-common-unaligned-header.patch
sh-wire-up-arch-overrides-for-unaligned-access-on-the-sh4a.patch
unaligned-wire-up-h8300-and-m32r-arches.patch
unaligned-wire-up-arm-arch-overrides-for-unaligned-access.patch
unaligned-remove-the-old-implementation.patch
#
ata-replace-byteshifting-with-unaligned-endian-helpers.patch
usb-use-unaligned-endian-helpers-in-storage-drivers.patch

unaligned stuff. Merge.

romfs-romfs_iget-unsigned-ino-=-0-is-always-true.patch
romfs-romfs_iget-unsigned-ino-=-0-is-always-true-checkpatch-fixes.patch

Merge.

filesystem-freeze-add-error-handling-of-write_super_lockfs-unlockfs.patch
filesystem-freeze-implement-generic-freeze-feature.patch
filesystem-freeze-implement-generic-freeze-feature-fix.patch
filesystem-freeze-remove-xfs-specific-ioctl-interfaces-for-freeze-feature.patch

Filesystem freeze feature. Merge.

linuxpps-core-support.patch
linuxpps-core-support-sysfs-not-needed-variables-removed.patch
pps-userland-header-file-for-pps-api.patch
pps-documentation-programs-and-examples.patch
pps-linuxpps-clients-support.patch
ldisc-new-dcd_change-method-for-line-disciplines.patch
#ldisc-n_tty-export-all-n_tty-ldisc-methods.patch
#ldisc-n_tty-export-all-n_tty-ldisc-methods-fix.patch
#pps-serial-clients-support.patch
#pps-serial-clients-support-avoid-noisy-compilation-on-64bits-architecture.patch
pps-parallel-port-clients-support.patch
#pps-low-level-irq-timestamps-recording.patch: don't merge!
#pps-low-level-irq-timestamps-recording.patch

Some of PPS. Will merge. Some stuff got left out because Alan was
being cryptic. We'll get there.

factor-out-ifdefs-from-kernel-spinlockc-to-lock_contended_flags.patch
allow-rwlocks-to-re-enable-interrupts.patch
ia64-implement-interrupt-enabling-rwlocks.patch
ia64-implement-interrupt-enabling-rwlocks-fix.patch

Merge, I think.

remove-lots-of-double-semicolons.patch

Merge.

generic-swap-sparc-rename-swap-to-swap_ulong.patch
generic-swap-iphase-rename-swap-to-swap_byte_order.patch
generic-swap-lib-sortc-rename-swap-to-swap_func.patch
generic-swap-introduce-global-macro-swapa-b.patch
generic-swap-ext3-remove-local-swap-macro.patch
generic-swap-ext4-remove-local-swap-macro.patch
generic-swap-sched-remove-local-swap-macro.patch
generic-swap-dcache-use-swap-instead-of-private-do_switch.patch

Add a kernel-wide swap() macro, use it. Merge.

make-various-things-static.patch

Merge.

fix-similar-typos-to-successfull-v2.patch

Merge.

nilfs2-add-document.patch
nilfs2-disk-format-and-userland-interface.patch
nilfs2-add-inode-and-other-major-structures.patch
nilfs2-integrated-block-mapping.patch
nilfs2-b-tree-based-block-mapping.patch
nilfs2-direct-block-mapping.patch
nilfs2-b-tree-node-cache.patch
nilfs2-buffer-and-page-operations.patch
nilfs2-meta-data-file.patch
nilfs2-persistent-object-allocator.patch
nilfs2-disk-address-translator.patch
nilfs2-inode-map-file.patch
nilfs2-checkpoint-file.patch
nilfs2-segment-usage-file.patch
nilfs2-inode-operations.patch
nilfs2-inode-operations-fix.patch
nilfs2-file-operations.patch
nilfs2-directory-entry-operations.patch
nilfs2-pathname-operations.patch
nilfs2-pathname-operations-fix.patch
nilfs2-operations-for-the_nilfs-core-object.patch
nilfs2-super-block-operations.patch
nilfs2-super-block-operations-fix.patch
nilfs2-segment-buffer.patch
nilfs2-segment-constructor.patch
nilfs2-recovery-functions.patch
nilfs2-another-dat-for-garbage-collection.patch
nilfs2-block-cache-for-garbage-collection.patch
nilfs2-ioctl-operations.patch
nilfs2-update-makefile-and-kconfig.patch
#
nilfs2-fix-problems-of-memory-allocation-in-ioctl.patch
nilfs2-cleanup-nilfs_clear_inode.patch
nilfs2-avoid-double-error-caused-by-nilfs_transaction_end.patch
nilfs2-insert-explanations-in-gcinode-file.patch
nilfs2-add-maintainer.patch
nilfs2-fix-gc-failure-on-volumes-keeping-numerous-snapshots.patch

Dunno. Has this been reviewed enough?

kmemleak-add-the-base-support.patch
kmemleak-add-the-base-support-fix.patch
kmemleak-add-documentation-on-the-memory-leak-detector.patch
kmemleak-add-the-slab-memory-allocation-freeing-hooks.patch
kmemleak-add-the-slob-memory-allocation-freeing-hooks.patch
kmemleak-add-the-slub-memory-allocation-freeing-hooks.patch
kmemleak-add-the-vmalloc-memory-allocation-freeing-hooks.patch
kmemleak-add-kmemleak_alloc-callback-from-alloc_large_system_hash.patch
kmemleak-add-modules-support.patch
x86-provide-_sdata-in-the-vmlinux_ldss-files.patch
arm-provide-_sdata-and-__bss_stop-in-the-vmlinuxldss-file.patch
kmemleak-remove-some-of-the-kmemleak-false-positives.patch
kmemleak-enable-the-building-of-the-memory-leak-detector.patch
kmemleak-simple-testing-module-for-kmemleak.patch
kmemleak-add-the-corresponding-maintainers-entry.patch

Merge, I suppose. I hope it proves worthwhile - I'm not terribly
convinced?

reiser4-vfs-add-super_operationssync_inodes-2.patch
reiser4-export-remove_from_page_cache.patch
reiser4-export-find_get_pages.patch
reiser4.patch
reiser4-adjust-to-the-new-aops.patch
reiser4-adjust-to-the-new-aops-fixup.patch
reiser4-remove-simple_prepare_write-usage.patch
reiser4-remove-simple_prepare_write-usage-checkpatch-fixes.patch
fs-symlink-write_begin-allocation-context-fix-reiser4-fix.patch
reiser4-handling-error-returned-by-d_obtain_alias-fixup.patch

Hold.

make-sure-nobodys-leaking-resources.patch
journal_add_journal_head-debug.patch
releasing-resources-with-children.patch
nr_blockdev_pages-in_interrupt-warning.patch
make-frame_pointer-default=y.patch
mutex-subsystem-synchro-test-module.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
add-debugging-aid-for-memory-initialisation-problems.patch
shrink_slab-handle-bad-shrinkers.patch
keep-track-of-network-interface-renaming.patch
workaround-for-a-pci-restoring-bug.patch
prio_tree-debugging-patch.patch
single_open-seq_release-leak-diagnostics.patch
add-a-refcount-check-in-dput.patch
getblk-handle-2tb-devices.patch
getblk-handle-2tb-devices-fix.patch
undeprecate-pci_find_device.patch
notify_change-callers-must-hold-i_mutex.patch
drivers-net-bonding-bond_sysfsc-suppress-uninitialized-var-warning.patch
w1-build-fix.patch

mm-only debugging stuff. No plans to merge this, ever.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-05 09:10:08 UTC
Permalink
(cc's added)
Post by Andrew Morton
#
page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch
I oppose this.
"28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms"
thread.
Nobody answer his question yet.
OK, thanks. I actually thought we'd fixed that?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
V***@vt.edu
2009-01-05 22:40:08 UTC
Permalink
Post by Andrew Morton
(cc's added)
Post by Andrew Morton
#
page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch
I oppose this.
"28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms"
thread.
Nobody answer his question yet.
OK, thanks. I actually thought we'd fixed that?
I'll check mmotm-0105 later tonight, I was still seeing the issue in -1230.
Ying Han
2009-01-08 04:20:05 UTC
Permalink
Hi Valdis:
Please try this fix and i tested on ubunbu8.10 with xmms and it helps.

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9e268b6..f4bbd9b 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -593,6 +593,7 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigne
unsigned long flags;
int sig;
#endif
+ unsigned int retry_flag = FAULT_FLAG_RETRY;

tsk = current;
mm = tsk->mm;
@@ -690,6 +691,7 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigne
down_read(&mm->mmap_sem);
}

+retry:
vma = find_vma(mm, address);
if (!vma)
goto bad_area;
@@ -716,6 +718,7 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigne
good_area:
si_code = SEGV_ACCERR;
write = 0;
+ write |= retry_flag;
switch (error_code & (PF_PROT|PF_WRITE)) {
default: /* 3: write, present */
/* fall through */
@@ -744,6 +747,21 @@ good_area:
goto do_sigbus;
BUG();
}
+
+ /*
+ * Here we retry fault once and switch to synchronous mode. The
+ * main reason is to prevent us from the cases of starvation.
+ * The retry logic open a starvation hole in which case pages might
+ * be removed or changed after the retry.
+ */
+ if (fault & VM_FAULT_RETRY) {
+ if (write & FAULT_FLAG_RETRY) {
+ retry_flag &= ~FAULT_FLAG_RETRY;
+ goto retry;
+ }
+ BUG();
+ }
+
if (fault & VM_FAULT_MAJOR)
tsk->maj_flt++;
else
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 4a3d28c..be770f9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -144,6 +144,7 @@ extern pgprot_t protection_map[16];

#define FAULT_FLAG_WRITE 0x01 /* Fault was a write access */
#define FAULT_FLAG_NONLINEAR 0x02 /* Fault was via a nonlinear mapping */
+#define FAULT_FLAG_RETRY 0x04 /* Retry major fault */

/*
* This interface is used by x86 PAT code to identify a pfn mapping that is
@@ -707,6 +708,7 @@ static inline int page_mapped(struct page *page)

#define VM_FAULT_MINOR 0 /* For backwards compat. Remove me quickly. */

+#define VM_FAULT_RETRY 0x0010
#define VM_FAULT_OOM 0x0001
#define VM_FAULT_SIGBUS 0x0002
#define VM_FAULT_MAJOR 0x0004
diff --git a/mm/filemap.c b/mm/filemap.c
index 2f55a1e..aed5a3f 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -714,6 +714,58 @@ repeat:
EXPORT_SYMBOL(find_lock_page);

/**
+ * find_lock_page_retry - locate, pin and lock a pagecache page
+ * @mapping: the address_space to search
+ * @offset: the page index
+ * @vma: vma in which the fault was taken
+ * @ppage: zero if page not present, otherwise point to the page in pagecache
+ * @retry: 1 indicate caller tolerate a retry.
+ *
+ * If retry flag is on, and page is already locked by someone else, return
+ * a hint of retry.
+ *
+ * Return *ppage==NULL if page is not in pagecache. Otherwise return *ppage
+ * points to the page in the pagecache with ret=VM_FAULT_RETRY indicate a
+ * hint to caller for retry, or ret=0 which means page is succefully
+ * locked.
+ */
+unsigned find_lock_page_retry(struct address_space *mapping, pgoff_t offset,
+ struct vm_area_struct *vma, struct page **ppage,
+ int retry)
+{
+ unsigned int ret = 0;
+ struct page *page;
+
+repeat:
+ page = find_get_page(mapping, offset);
+ if (page) {
+ if (!retry)
+ lock_page(page);
+ else {
+ if (!trylock_page(page)) {
+ struct mm_struct *mm = vma->vm_mm;
+
+ up_read(&mm->mmap_sem);
+ wait_on_page_locked(page);
+ down_read(&mm->mmap_sem);
+
+ page_cache_release(page);
+ return VM_FAULT_RETRY;
+ }
+ }
+ if (unlikely(page->mapping != mapping)) {
+ unlock_page(page);
+ page_cache_release(page);
+ goto repeat;
+ }
+ VM_BUG_ON(page->index != offset);
+ }
+ *ppage = page;
+ return ret;
+}
+EXPORT_SYMBOL(find_lock_page_retry);
+
+/**
* find_or_create_page - locate or add a pagecache page
* @mapping: the page's address_space
* @index: the page's index into the mapping
@@ -1452,6 +1504,8 @@ int filemap_fault(struct vm_area_struct *vma, struct vm_
pgoff_t size;
int did_readaround = 0;
int ret = 0;
+ int retry_flag = vmf->flags & FAULT_FLAG_RETRY;
+ int retry_ret;

size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
if (vmf->pgoff >= size)
@@ -1466,6 +1520,8 @@ int filemap_fault(struct vm_area_struct *vma, struct vm_
*/
retry_find:
page = find_lock_page(mapping, vmf->pgoff);
+
+retry_find_nopage:
/*
* For sequential accesses, we use the generic readahead logic.
*/
@@ -1473,9 +1529,12 @@ retry_find:
if (!page) {
page_cache_sync_readahead(mapping, ra, file,
vmf->pgoff, 1);
- page = find_lock_page(mapping, vmf->pgoff);
+ retry_ret = find_lock_page_retry(mapping, vmf->pgoff,
+ vma, &page, retry_flag);
if (!page)
goto no_cached_page;
+ if (retry_ret == VM_FAULT_RETRY)
+ return retry_ret;
}
if (PageReadahead(page)) {
page_cache_async_readahead(mapping, ra, file, page,
@@ -1512,14 +1571,18 @@ retry_find:
start = vmf->pgoff - ra_pages / 2;
do_page_cache_readahead(mapping, file, start, ra_pages);
}
- page = find_lock_page(mapping, vmf->pgoff);
+ retry_ret = find_lock_page_retry(mapping, vmf->pgoff,
+ vma, &page, retry_flag);
if (!page)
goto no_cached_page;
+ if (retry_ret == VM_FAULT_RETRY)
+ return retry_ret;
}

if (!did_readaround)
ra->mmap_miss--;

+retry_page_update:
/*
* We have a locked page in the page cache, now we need to check
* that it's up-to-date. If not, it is going to be due to an error.
@@ -1554,8 +1617,23 @@ no_cached_page:
* In the unlikely event that someone removed it in the
* meantime, we'll just come back here and read it again.
*/
- if (error >= 0)
- goto retry_find;
+ if (error >= 0) {
+ /*
+ * If caller cannot tolerate a retry in the ->fault path
+ * go back to check the page again.
+ */
+ if (!retry_flag)
+ goto retry_find;
+
+ retry_ret = find_lock_page_retry(mapping, vmf->pgoff,
+ vma, &page, retry_flag);
+ if (!page)
+ goto retry_find_nopage;
+ else if (retry_ret == VM_FAULT_RETRY)
+ return retry_ret;
+ else
+ goto retry_page_update;
+ }

/*
* An error return from page_cache_read can result if the
diff --git a/mm/memory.c b/mm/memory.c
index 3f8fa06..534ba1d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2572,6 +2572,13 @@ static int __do_fault(struct mm_struct *mm, struct vm_a
vmf.page = NULL;

ret = vma->vm_ops->fault(vma, &vmf);
+
+ /* page may be available, but we have to restart the process
+ * because mmap_sem was dropped during the ->fault
+ */
+ if (ret & VM_FAULT_RETRY)
+ return ret;
+
if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE)))
return ret;

@@ -2713,8 +2720,10 @@ static int do_linear_fault(struct mm_struct *mm, struct
{
pgoff_t pgoff = (((address & PAGE_MASK)
- vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
- unsigned int flags = (write_access ? FAULT_FLAG_WRITE : 0);
+ int write = write_access & ~FAULT_FLAG_RETRY;
+ unsigned int flags = (write ? FAULT_FLAG_WRITE : 0);

+ flags |= (write_access & FAULT_FLAG_RETRY);
pte_unmap(page_table);
return __do_fault(mm, vma, address, pmd, pgoff, flags, orig_pte);
}
Post by V***@vt.edu
Post by Andrew Morton
(cc's added)
Post by Andrew Morton
#
page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch
I oppose this.
"28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms"
thread.
Nobody answer his question yet.
OK, thanks. I actually thought we'd fixed that?
I'll check mmotm-0105 later tonight, I was still seeing the issue in -1230.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
KOSAKI Motohiro
2009-01-08 04:50:03 UTC
Permalink
Post by Ying Han
Please try this fix and i tested on ubunbu8.10 with xmms and it helps.
Hi, Ying-san
Could you please explain which was wrong and how to fix.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ying Han
2009-01-08 08:00:10 UTC
Permalink
yes. the change is in the last few lines of the patch. I found out
that the flags was set as FAULT_FLAG_WRITE no matter what(write/read)
whence FAULT_FLAG_RETRY is set. the new patch changed the logic which
only set the flag in the "write" case.

@@ -2713,8 +2720,10 @@ static int do_linear_fault(struct mm_struct *mm, struct
{
pgoff_t pgoff = (((address & PAGE_MASK)
- vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
- unsigned int flags = (write_access ? FAULT_FLAG_WRITE : 0);

+ int write = write_access & ~FAULT_FLAG_RETRY;
+ unsigned int flags = (write ? FAULT_FLAG_WRITE : 0);

--Ying


On Wed, Jan 7, 2009 at 8:41 PM, KOSAKI Motohiro
Post by KOSAKI Motohiro
Post by Ying Han
Please try this fix and i tested on ubunbu8.10 with xmms and it helps.
Hi, Ying-san
Could you please explain which was wrong and how to fix.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
KOSAKI Motohiro
2009-01-08 08:40:05 UTC
Permalink
Post by Ying Han
yes. the change is in the last few lines of the patch. I found out
that the flags was set as FAULT_FLAG_WRITE no matter what(write/read)
whence FAULT_FLAG_RETRY is set. the new patch changed the logic which
only set the flag in the "write" case.
@@ -2713,8 +2720,10 @@ static int do_linear_fault(struct mm_struct *mm, struct
{
pgoff_t pgoff = (((address & PAGE_MASK)
- vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
- unsigned int flags = (write_access ? FAULT_FLAG_WRITE : 0);
+ int write = write_access & ~FAULT_FLAG_RETRY;
+ unsigned int flags = (write ? FAULT_FLAG_WRITE : 0);
ok. it seems makes sense.
thanks.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
V***@vt.edu
2009-01-11 05:10:07 UTC
Permalink
Post by Ying Han
Please try this fix and i tested on ubunbu8.10 with xmms and it helps.
Sorry for the long delay in testing, I was offline Wed-Friday taking some
much-needed leave time.
Post by Ying Han
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9e268b6..f4bbd9b 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
This didn't apply cleanly to a mmotm-0105 tree, but did apply cleanly
with the following 3 patches reverted and then this new patch applied.

page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch

not surprising, since it looks like this patch is a replacement for all 3. It
built and booted nicely, and xmms on the resulting kernel behaves properly.

Congrats on being able to debug the problem based on my fairly weird bug
report. ;)
Ying Han
2009-01-12 04:20:06 UTC
Permalink
Thank you Valdis for your work and that is a really good news. :-)

--Ying
Post by V***@vt.edu
Post by Ying Han
Please try this fix and i tested on ubunbu8.10 with xmms and it helps.
Sorry for the long delay in testing, I was offline Wed-Friday taking some
much-needed leave time.
Post by Ying Han
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9e268b6..f4bbd9b 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
This didn't apply cleanly to a mmotm-0105 tree, but did apply cleanly
with the following 3 patches reverted and then this new patch applied.
page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch
not surprising, since it looks like this patch is a replacement for all 3. It
built and booted nicely, and xmms on the resulting kernel behaves properly.
Congrats on being able to debug the problem based on my fairly weird bug
report. ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ying Han
2009-01-05 22:40:14 UTC
Permalink
We are currently looking into this by trying to reproduce the issue. I
will update the progress later in the thread.

thanks

--Ying
Post by Andrew Morton
(cc's added)
Post by Andrew Morton
#
page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch
I oppose this.
"28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms"
thread.
Nobody answer his question yet.
OK, thanks. I actually thought we'd fixed that?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
KOSAKI Motohiro
2009-01-05 09:10:09 UTC
Permalink
Post by Andrew Morton
#
page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch
I oppose this.

***@vt.edu reported this patch has bug in
"28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms"
thread.

Nobody answer his question yet.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
V***@vt.edu
2009-01-06 05:30:10 UTC
Permalink
Post by Andrew Morton
#
page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch
I oppose this.
"28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms"
thread.
Nobody answer his question yet.
It's still present in -mmotm0105. I'm open to suggestions and any
debugging/instrumentation patches you might suggest - I'm completely at a
loss as to how the patch manages to mess up xmms the way it does.
Nick Piggin
2009-01-06 05:50:06 UTC
Permalink
Post by V***@vt.edu
Post by Andrew Morton
#
page_fault-retry-with-nopage_retry.patch
page_fault-retry-with-nopage_retry-fix.patch
page_fault-retry-with-nopage_retry-fix-fix.patch
I oppose this.
"28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms"
thread.
Nobody answer his question yet.
It's still present in -mmotm0105. I'm open to suggestions and any
debugging/instrumentation patches you might suggest - I'm completely at a
loss as to how the patch manages to mess up xmms the way it does.
It's pretty soon for such a patch to go in too, IMO, even if there wasn't
a known problem with it.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sam Ravnborg
2009-01-05 09:10:10 UTC
Permalink
Hi Andrew.
Post by Andrew Morton
sparc64-use-unsigned-long-long-for-u64.patch
sparc64-fix-unsigned-long-long-warnings-in-drivers.patch
Please drop these two.
They are not complete (break build on certain configurations).
I will get back to them when I get my sparc64 setup functional.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
2009-01-05 09:20:09 UTC
Permalink
From: Andrew Morton <***@linux-foundation.org>
Date: Mon, 5 Jan 2009 01:12:02 -0800
Post by Sam Ravnborg
Hi Andrew.
Post by Andrew Morton
sparc64-use-unsigned-long-long-for-u64.patch
sparc64-fix-unsigned-long-long-warnings-in-drivers.patch
Please drop these two.
Might, if they break my build.
They don't build, I tested them when I tried integrated Sam's
patches.

Please toss these, Sam and I will make sure it gets added once we sort
out the build failures.
I tend to hang onto things I like, even if they aren't right yet.
We really really need to push ahead with fixing this stuff.
If we are working on making the patches actually work, and they are
known to break the build, you should just toss let us take care of it.

At least in cases like this one. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2009-01-05 09:30:12 UTC
Permalink
Post by David Miller
Date: Mon, 5 Jan 2009 01:12:02 -0800
Post by Sam Ravnborg
Hi Andrew.
Post by Andrew Morton
sparc64-use-unsigned-long-long-for-u64.patch
sparc64-fix-unsigned-long-long-warnings-in-drivers.patch
Please drop these two.
Might, if they break my build.
They don't build, I tested them when I tried integrated Sam's patches.
do they break due to some warnings caught by -Werror?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sam Ravnborg
2009-01-05 09:40:09 UTC
Permalink
Post by Ingo Molnar
Post by David Miller
Date: Mon, 5 Jan 2009 01:12:02 -0800
Post by Sam Ravnborg
Hi Andrew.
Post by Andrew Morton
sparc64-use-unsigned-long-long-for-u64.patch
sparc64-fix-unsigned-long-long-warnings-in-drivers.patch
Please drop these two.
Might, if they break my build.
They don't build, I tested them when I tried integrated Sam's patches.
do they break due to some warnings caught by -Werror?
Yup.
In my setup I did not see the warnings.
Most likely because I'm sitting on an older i386 and the
64 bit version of gcc emits more warnings than my 32 bit version.

The build broke in with Dave's native gcc and will most likely with
a 64 bit cross compiler too.

I do not want to remove the -Werror just due to this as it
is only a limited effort to fix up the patches when I get
my setup fixed.

But due to other issues (you know work and such) it it not the next week
that I have a proper setup.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2009-01-05 10:20:12 UTC
Permalink
Post by Ingo Molnar
Post by David Miller
Date: Mon, 5 Jan 2009 01:12:02 -0800
Post by Sam Ravnborg
Hi Andrew.
Post by Andrew Morton
sparc64-use-unsigned-long-long-for-u64.patch
sparc64-fix-unsigned-long-long-warnings-in-drivers.patch
Please drop these two.
Might, if they break my build.
They don't build, I tested them when I tried integrated Sam's patches.
do they break due to some warnings caught by -Werror?
Yup.
So your patches "dont build" because some Sparc configs produce new
(presumably harmless) warnings?

And the solution is to not do your patch and export other warnings to the
core kerne, which then get reported as bugs there and which result in
fugly fixes? (and which resulted in a crapload of ugly fixes in the past
10 years)

That is quite backwards, no matter how i look at it. Why doesnt Sparc do
the obvious and turn off -Werror until it has gotten around to fix those
few remaining warnings? It took me 30 minutes to fix up PowerPC defconfig
with a similar change, it cannot be that much harder on Sparc either
(powerpc arch code is a lot larger in fact). I'd be surprised if it took
more than 10 minutes of davem's time.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
2009-01-05 10:40:06 UTC
Permalink
From: Ingo Molnar <***@elte.hu>
Date: Mon, 5 Jan 2009 11:10:06 +0100
Post by Ingo Molnar
That is quite backwards, no matter how i look at it. Why doesnt Sparc do
the obvious and turn off -Werror until it has gotten around to fix those
few remaining warnings?
Are you kidding me?

-Werror has been on for 5+ years under arch/sparc, and the tree in
those subdirectories always built warning free.

For crying out loud, Sam and I are asking for a few days to freshen
up these patches so they build properly. What is the big deal?

The changes will go in, probably within the next week, just give us
a chance to fix them up.

I really can't believe what a big stink is being made in response
to an arch maintainer and one of his helpers wanting to clean up
a patch before it gets integrated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2009-01-05 12:40:09 UTC
Permalink
Post by David Miller
Date: Mon, 5 Jan 2009 11:10:06 +0100
Post by Ingo Molnar
That is quite backwards, no matter how i look at it. Why doesnt Sparc do
the obvious and turn off -Werror until it has gotten around to fix those
few remaining warnings?
Are you kidding me?
-Werror has been on for 5+ years under arch/sparc, and the tree in those
subdirectories always built warning free.
For crying out loud, Sam and I are asking for a few days to freshen up
these patches so they build properly. What is the big deal?
The changes will go in, probably within the next week, just give us a
chance to fix them up.
I really can't believe what a big stink is being made in response to an
arch maintainer and one of his helpers wanting to clean up a patch
before it gets integrated.
I'm glad that things are accelerating that it will only take a few days
now. Your earlier reaction of asking Andrew to remove it from -mm gave me
the opposite impression - your reactions made it seem as if you saw it the
duty of Sam to fix any problems with this patch.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-05 09:20:11 UTC
Permalink
Post by Sam Ravnborg
Hi Andrew.
Post by Andrew Morton
sparc64-use-unsigned-long-long-for-u64.patch
sparc64-fix-unsigned-long-long-warnings-in-drivers.patch
Please drop these two.
Might, if they break my build.
Post by Sam Ravnborg
They are not complete (break build on certain configurations).
I will get back to them when I get my sparc64 setup functional.
I tend to hang onto things I like, even if they aren't right yet.

We really really need to push ahead with fixing this stuff. Because of
this problem the number of bugs which people are adding, and the number
of subsequent fixup patches (ALL of which are fugly and stupid) is just
out of control, and quite unnecessary.

Maybe we should just do the switch, send best-effort fixup patches at
the arch maintainers and move on.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2009-01-05 10:20:10 UTC
Permalink
Post by Andrew Morton
Maybe we should just do the switch, send best-effort fixup patches at
the arch maintainers and move on.
agreed - we should have done that 5 years ago. This is really an arch
problem and i'm willing to help this effort and fix any new sparc64
warnings in any sparc64 config that davem sends me.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
2009-01-05 10:40:10 UTC
Permalink
From: Ingo Molnar <***@elte.hu>
Date: Mon, 5 Jan 2009 11:11:36 +0100
Post by Ingo Molnar
Post by Andrew Morton
Maybe we should just do the switch, send best-effort fixup patches at
the arch maintainers and move on.
agreed - we should have done that 5 years ago. This is really an arch
problem and i'm willing to help this effort and fix any new sparc64
warnings in any sparc64 config that davem sends me.
Can you guys wait like 2 or 3 days for Sam and I to do the work?

Sam even bought a sparc64 machine on EBAY so that he could do this
work with me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ryusuke Konishi
2009-01-05 09:50:06 UTC
Permalink
Post by Andrew Morton
nilfs2-add-document.patch
nilfs2-disk-format-and-userland-interface.patch
nilfs2-add-inode-and-other-major-structures.patch
nilfs2-integrated-block-mapping.patch
nilfs2-b-tree-based-block-mapping.patch
nilfs2-direct-block-mapping.patch
nilfs2-b-tree-node-cache.patch
nilfs2-buffer-and-page-operations.patch
nilfs2-meta-data-file.patch
nilfs2-persistent-object-allocator.patch
nilfs2-disk-address-translator.patch
nilfs2-inode-map-file.patch
nilfs2-checkpoint-file.patch
nilfs2-segment-usage-file.patch
nilfs2-inode-operations.patch
nilfs2-inode-operations-fix.patch
nilfs2-file-operations.patch
nilfs2-directory-entry-operations.patch
nilfs2-pathname-operations.patch
nilfs2-pathname-operations-fix.patch
nilfs2-operations-for-the_nilfs-core-object.patch
nilfs2-super-block-operations.patch
nilfs2-super-block-operations-fix.patch
nilfs2-segment-buffer.patch
nilfs2-segment-constructor.patch
nilfs2-recovery-functions.patch
nilfs2-another-dat-for-garbage-collection.patch
nilfs2-block-cache-for-garbage-collection.patch
nilfs2-ioctl-operations.patch
nilfs2-update-makefile-and-kconfig.patch
#
nilfs2-fix-problems-of-memory-allocation-in-ioctl.patch
nilfs2-cleanup-nilfs_clear_inode.patch
nilfs2-avoid-double-error-caused-by-nilfs_transaction_end.patch
nilfs2-insert-explanations-in-gcinode-file.patch
nilfs2-add-maintainer.patch
nilfs2-fix-gc-failure-on-volumes-keeping-numerous-snapshots.patch
Dunno. Has this been reviewed enough?
I'm now working to follow some comments from Chris, and
I think nilfs should be reviewed more widely.

I'll aim for the next merge window or so.

Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pekka Enberg
2009-01-06 13:40:11 UTC
Permalink
Hi Ryusuke,

[snip nilfs patches]

On Mon, Jan 5, 2009 at 11:40 AM, Ryusuke Konishi
Post by Ryusuke Konishi
Post by Andrew Morton
Dunno. Has this been reviewed enough?
I'm now working to follow some comments from Chris, and
I think nilfs should be reviewed more widely.
I'll aim for the next merge window or so.
It would be nice if BUG(), BUG_ON(), and panic() calls would be
converted to proper error handling using WARN_ON() calls. The BUG()
call in nilfs_cpfile_delete_checkpoints(), for example, looks to be
triggerable from user-space via the ioctl() system call (albeit I
didn't look too closely). Furthermore, the BUG() calls in error paths
of fs/nilfs2/ioctl.c look really fishy.

On a related note, there are quite a few new ioctls there. Are they
described somewhere? Also, can they be converted to use
->unlocked_ioctl? It's bit sad that we're adding new users of BKL in
shiny new code.

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ryusuke Konishi
2009-01-07 03:30:15 UTC
Permalink
Hi Pekka,
Post by Pekka Enberg
Hi Ryusuke,
[snip nilfs patches]
On Mon, Jan 5, 2009 at 11:40 AM, Ryusuke Konishi
Post by Ryusuke Konishi
Post by Andrew Morton
Dunno. Has this been reviewed enough?
I'm now working to follow some comments from Chris, and
I think nilfs should be reviewed more widely.
I'll aim for the next merge window or so.
It would be nice if BUG(), BUG_ON(), and panic() calls would be
converted to proper error handling using WARN_ON() calls. The BUG()
call in nilfs_cpfile_delete_checkpoints(), for example, looks to be
triggerable from user-space via the ioctl() system call (albeit I
didn't look too closely).
Thanks for looking at the code.

Well, there are too many BUG() and BUG_ON() calls.
I'll try to convert them as your advice.

The use of panic() call is a mimic of ext2/3, and this is called only
if an "errors=panic" mount option is specified.
Do you think it should be removed along with the mount option for
new filesystems ?
Post by Pekka Enberg
Furthermore, the BUG() calls in error paths
of fs/nilfs2/ioctl.c look really fishy.
I agree, but this seems to need some consideration.
I'll try to remove them separately if not easy.
Post by Pekka Enberg
On a related note, there are quite a few new ioctls there. Are they
described somewhere?
Not yet. Where is the recommended place to put it in?

And, Chris Mason today gave me another comment on the ioctls; he
pointed out there is a structure using unfixed sized types (compat
ioctls are used to instead).

I agree with his comment. I'd like to rewrite the ioctl declarations
and remove compat ioctls some time soon.
Post by Pekka Enberg
Also, can they be converted to use
->unlocked_ioctl? It's bit sad that we're adding new users of BKL in
shiny new code.
All right, I'll do some tests for it.

Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pekka Enberg
2009-01-07 08:00:20 UTC
Permalink
Post by Ryusuke Konishi
The use of panic() call is a mimic of ext2/3, and this is called only
if an "errors=panic" mount option is specified.
Do you think it should be removed along with the mount option for
new filesystems ?
No, no, that's fine. I didn't look where the panic was just spotted it
along the BUG_ON calls.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Chris Mason
2009-01-07 14:20:09 UTC
Permalink
Post by Ryusuke Konishi
Hi Pekka,
Post by Pekka Enberg
Hi Ryusuke,
[snip nilfs patches]
On Mon, Jan 5, 2009 at 11:40 AM, Ryusuke Konishi
Post by Ryusuke Konishi
Post by Andrew Morton
Dunno. Has this been reviewed enough?
I'm now working to follow some comments from Chris, and
I think nilfs should be reviewed more widely.
I'll aim for the next merge window or so.
Overall nilfs is pretty clean and clearly well maintained. I don't see
any major reason to keep it out.

-chris


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Al Viro
2009-01-05 11:40:09 UTC
Permalink
Post by Andrew Morton
kill-suid-bit-only-for-regular-files.patch
vfs-lseekfd-0-seek_cur-race-condition.patch
vfs-factor-out-duplicated-code-in-get_fs_type.patch
inotify-fix-type-errors-in-interfaces.patch
These are in tonight's (oh, fsck - this morning's already) VFS pile.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Stephen Rothwell
2009-01-05 11:50:10 UTC
Permalink
Hi Andrew,
Post by Andrew Morton
powerpc-change-u64-s64-to-a-long-long-integer-type.patch
I am working on this starting from this (Ingo's) patch. I'll feed stuff
through the powerpc tree.
Post by Andrew Morton
m68knommu-use-the-new-byteorder-headers.patch
m68knommu-set-no_dma.patch
Architecture things. Will merge.
I have an m68nommu tree as part of linux-next should these go there?
(though the last - still outstanding - commit was in November).
--
Cheers,
Stephen Rothwell ***@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Ingo Molnar
2009-01-05 12:20:07 UTC
Permalink
Post by Stephen Rothwell
Hi Andrew,
Post by Andrew Morton
powerpc-change-u64-s64-to-a-long-long-integer-type.patch
I am working on this starting from this (Ingo's) patch. I'll feed stuff
through the powerpc tree.
thanks - the ideal handling is to do it from the arch tree like you do,
the patch is quite wide so it's good to sync it up to the PowerPC queue
instead of feeding it externally (and causing rejects/mismerges possibly).

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
KOSAKI Motohiro
2009-01-05 17:40:12 UTC
Permalink
Post by Stephen Rothwell
Post by Andrew Morton
m68knommu-use-the-new-byteorder-headers.patch
m68knommu-set-no_dma.patch
Architecture things. Will merge.
I have an m68nommu tree as part of linux-next should these go there?
(though the last - still outstanding - commit was in November).
I guess m68knommu-set-no_dma.patch isn't right and pci code in
m68knommu use DMA.
because ..

arch/m64knommu/include/asm/dma-mapping.h is

---------------------------------------------------
#ifndef _M68KNOMMU_DMA_MAPPING_H
#define _M68KNOMMU_DMA_MAPPING_H

#ifdef CONFIG_PCI
#include <asm-generic/dma-mapping.h>
#else
#include <asm-generic/dma-mapping-broken.h>
#endif

#endif /* _M68KNOMMU_DMA_MAPPING_H */
---------------------------------------------------

At least, original author think m68k pci driver use dma.

Recently, I propose following patch.
but nobody replay it ;)


but I also guess it doesn't matter because I guess nobody use m68knommu now ;-/




Subject: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig
can't build
From: KOSAKI Motohiro <***@jp.fujitsu.com>
Date: 2008/12/30 19:44
Post by Stephen Rothwell
I guess nobody don't test m68knommu at all last three month.
Do we still need to maintain this architecture?
==
Currently, m68knommu defconfig can't build. it cause following error.
: undefined reference to `dma_mapping_error'
: undefined reference to `dma_unmap_single'
: undefined reference to `dma_unmap_page'
: undefined reference to `dma_map_single'
: undefined reference to `dma_map_page'
: undefined reference to `dma_unmap_page'
: undefined reference to `dma_unmap_single'
because
- CONFIG_DMA depend on !NO_DMA
- m68knommu always doesn't turn on NO_DMA
- if CONFIG_PCI=n, m68knommu/include/asm/dma-magging.h include
asm-generic/dma-mapping-broken.h
- dma-mapping-broken.h generate link time error.
- m68knommu defconfig doesn't have CONFIG_PCI
- On the other hand, net/core/skb_dma_map.c assume CONFIG_DMA=y mean
dma related function is callable
So, we want to turn on CONFIG_DMA if CONFIG_PCI=y only.
---
arch/m68knommu/Kconfig | 3 +++
1 file changed, 3 insertions(+)
Index: b/arch/m68knommu/Kconfig
===================================================================
--- a/arch/m68knommu/Kconfig 2008-12-25 08:26:37.000000000 +0900
+++ b/arch/m68knommu/Kconfig 2008-12-28 21:09:58.000000000 +0900
@@ -73,6 +73,9 @@ config GENERIC_CLOCKEVENTS
config NO_IOPORT
def_bool y
+config NO_DMA
+ def_bool !PCI
+
source "init/Kconfig"
source "kernel/Kconfig.freezer"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg Ungerer
2009-01-12 06:20:06 UTC
Permalink
Hi Stephen,
Post by Stephen Rothwell
Hi Andrew,
Post by Andrew Morton
powerpc-change-u64-s64-to-a-long-long-integer-type.patch
I am working on this starting from this (Ingo's) patch. I'll feed stuff
through the powerpc tree.
Post by Andrew Morton
m68knommu-use-the-new-byteorder-headers.patch
m68knommu-set-no_dma.patch
Architecture things. Will merge.
I have an m68nommu tree as part of linux-next should these go there?
(though the last - still outstanding - commit was in November).
I have been away the last few weeks, so nothing has happened
on the m68knommu (or uclinux) git trees. I should be updating
them and getting of some patches to Linus this week (I hope...).

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: ***@snapgear.com
SnapGear, a McAfee Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-05 12:30:16 UTC
Permalink
Post by Andrew Morton
The individual patches are mostly at
http://userweb.kernel.org/~akpm/mmotm/broken-out/
mm-remove-the-might_sleep-from-lock_page.patch
Need to think about this.
Removing this reduces a lot of might_sleep coverage scope. Page
lock isn't contended in a lot of cases. Why would you drop a
good debugging feature?
Post by Andrew Morton
mm-direct-io-starvation-improvement.patch
fs-remove-wb_sync_hold.patch
fs-sync_sb_inodes-fix.patch
fs-sys_sync-fix.patch
radix-tree-gang-set-if-tagged-operation.patch
This one is unneeded because you didn't take the fsync livelock avoidance
patch that makes use of the new function.
Post by Andrew Morton
make-sure-nobodys-leaking-resources.patch
releasing-resources-with-children.patch
Any reason why not to add these upstream?
Post by Andrew Morton
nr_blockdev_pages-in_interrupt-warning.patch
Lockdep should catch this, I guess.
Post by Andrew Morton
put_bh-debug.patch
This could just be implemented with a VM_BUG_ON (or FS_BUG_ON) like the
pagecache refcounting. Wouldn't be a bad idea.
Post by Andrew Morton
add-a-refcount-check-in-dput.patch
Again, why not an FS_BUG_ON for things like this too?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-12 22:10:14 UTC
Permalink
On Mon, 5 Jan 2009 23:28:26 +1100
Post by Nick Piggin
Post by Andrew Morton
The individual patches are mostly at
http://userweb.kernel.org/~akpm/mmotm/broken-out/
mm-remove-the-might_sleep-from-lock_page.patch
Need to think about this.
Removing this reduces a lot of might_sleep coverage scope. Page
lock isn't contended in a lot of cases. Why would you drop a
good debugging feature?
For the reasons described in the changelog, of course.

http://userweb.kernel.org/~akpm/mmotm/broken-out/mm-remove-the-might_sleep-from-lock_page.patch
Post by Nick Piggin
Post by Andrew Morton
mm-direct-io-starvation-improvement.patch
fs-remove-wb_sync_hold.patch
fs-sync_sb_inodes-fix.patch
fs-sys_sync-fix.patch
radix-tree-gang-set-if-tagged-operation.patch
This one is unneeded because you didn't take the fsync livelock avoidance
patch that makes use of the new function.
OK
Post by Nick Piggin
Post by Andrew Morton
make-sure-nobodys-leaking-resources.patch
releasing-resources-with-children.patch
Any reason why not to add these upstream?
Dunno. Are they valuable? I've never had a report of them triggering,
I don't think.
Post by Nick Piggin
Post by Andrew Morton
nr_blockdev_pages-in_interrupt-warning.patch
Lockdep should catch this, I guess.
Yup. I forget why I added it.
Post by Nick Piggin
Post by Andrew Morton
put_bh-debug.patch
This could just be implemented with a VM_BUG_ON (or FS_BUG_ON) like the
pagecache refcounting. Wouldn't be a bad idea.
yup, I guess so. Again, no reports of it triggering in ages.
Post by Nick Piggin
Post by Andrew Morton
add-a-refcount-check-in-dput.patch
Again, why not an FS_BUG_ON for things like this too?
Ditto.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-15 06:40:07 UTC
Permalink
Post by Andrew Morton
On Mon, 5 Jan 2009 23:28:26 +1100
Post by Nick Piggin
Post by Andrew Morton
The individual patches are mostly at
http://userweb.kernel.org/~akpm/mmotm/broken-out/
mm-remove-the-might_sleep-from-lock_page.patch
Need to think about this.
Removing this reduces a lot of might_sleep coverage scope. Page
lock isn't contended in a lot of cases. Why would you drop a
good debugging feature?
For the reasons described in the changelog, of course.
http://userweb.kernel.org/~akpm/mmotm/broken-out/mm-remove-the-might_sleep-
from-lock_page.patch
Yeah, but that's because voluntary preempt is somewhat of a hack.
In fact, we recently decided to turn this off in SLES11 because it
was causing a measurable performance slowdown.

If you are actually debugging a page lock problem or writing new
code, you would be very very happy to have a problem caught here
rather than the potentially much harder task of causing a
schedule on this lock.
Post by Andrew Morton
Post by Nick Piggin
Post by Andrew Morton
make-sure-nobodys-leaking-resources.patch
releasing-resources-with-children.patch
Any reason why not to add these upstream?
Dunno. Are they valuable? I've never had a report of them triggering,
I don't think.
I don't really know the code, but if it gives extra help to
people writing or testing new devices... is it difficult to
carry around? If not, then why *not* have it upstream? ;)
Post by Andrew Morton
Post by Nick Piggin
Post by Andrew Morton
put_bh-debug.patch
This could just be implemented with a VM_BUG_ON (or FS_BUG_ON) like the
pagecache refcounting. Wouldn't be a bad idea.
yup, I guess so. Again, no reports of it triggering in ages.
Maybe I'll go through and add some such assertions for fs developers.
fsblock is riddled with them and it really really helps catching weird
and wonderful problems in the buffer layer, the pagecache layer, or
the filesystem, or some combination of them ;) Maybe that's just
because I write a lot of bugs though!
Post by Andrew Morton
Post by Nick Piggin
Post by Andrew Morton
add-a-refcount-check-in-dput.patch
Again, why not an FS_BUG_ON for things like this too?
Ditto.
OK.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
2009-01-06 09:50:06 UTC
Permalink
Post by Andrew Morton
The individual patches are mostly at
http://userweb.kernel.org/~akpm/mmotm/broken-out/
I must say that I got addicted to ketchup and miss the old -mm
releases... Yes, these days it can be downloaded using git, which is
not bad either, but... :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Folkert van Heusden
2009-01-06 22:50:04 UTC
Permalink
Hi,
Post by Andrew Morton
linuxpps-core-support.patch
linuxpps-core-support-sysfs-not-needed-variables-removed.patch
pps-userland-header-file-for-pps-api.patch
pps-documentation-programs-and-examples.patch
pps-linuxpps-clients-support.patch
ldisc-new-dcd_change-method-for-line-disciplines.patch
#ldisc-n_tty-export-all-n_tty-ldisc-methods.patch
#ldisc-n_tty-export-all-n_tty-ldisc-methods-fix.patch
#pps-serial-clients-support.patch
#pps-serial-clients-support-avoid-noisy-compilation-on-64bits-architecture.patch
pps-parallel-port-clients-support.patch
#pps-low-level-irq-timestamps-recording.patch: don't merge!
#pps-low-level-irq-timestamps-recording.patch
Some of PPS. Will merge. Some stuff got left out because Alan was
being cryptic. We'll get there.
What are the current problems with this patch? Because especially the
serial-pps patches are interesting as most users connect their
gps/atomic clock/etc. to a serial port for their timekeeping.


Folkert van Heusden
--
Multi tail barnamaj mowahib li mora9abat attasjilat wa nataij awamir
al 7asoub. damj, talwin, mora9abat attarchi7 wa ila akhirih.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2009-01-06 22:50:08 UTC
Permalink
Post by Folkert van Heusden
What are the current problems with this patch? Because especially the
serial-pps patches are interesting as most users connect their
gps/atomic clock/etc. to a serial port for their timekeeping.
The pps ldisc code wants redoing differently. I'll sort that once the
rest is merged and it won't take very long.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-06 23:00:17 UTC
Permalink
Post by Andrew Morton
mm-invoke-oom-killer-from-page-fault.patch
mm-invoke-oom-killer-from-page-fault-fix.patch
mm-invoke-oom-killer-from-page-fault-fix-fix-2.patch
Just implementing this behaviour for x86 and uml is extremly
counter-productive. Please fix up all architectures as this
behaviour needs to be the same on all ports (at least those
with a MMU)
Post by Andrew Morton
fs-truncate-blocks-outside-i_size-after-o_direct-write-error.patch
fs-truncate-blocks-outside-i_size-after-o_direct-write-error-fix.patch
Btw, this code is still not quite right. We really need to call
->setattr instead of vmtruncate here. Complex filesystem need
transaction to properly free blocks, and those transactions are in
->setattr not inside vmtruncate where ->truncate doesn't even have
a chance to get the handle to the transaction passed.

As these patches don't make it worse this is not a NACK, but more of
a heads up.
Post by Andrew Morton
fs-sys_sync-fix.patch
I'm not sure this is a good idea. Concurrent syncs are a bad idea
to start with and we should just synchronyze do_sync completely.
sync_filesystems as one of the main components of do_sync already
is synchronized in that way, and taking that to a higher level would
get rid of all the worries about concurrent syncs.
Post by Andrew Morton
softirq-introduce-statistics-for-softirq.patch
proc-export-statistics-for-softirq-to-proc.patch
proc-update-document-for-proc-softirqs-and-proc-stat.patch
Why is this in procfs?
Post by Andrew Morton
ecryptfs-filename-encryption-tag-70-packets.patch
ecryptfs-filename-encryption-header-updates.patch
ecryptfs-filename-encryption-encoding-and-encryption-functions.patch
ecryptfs-filename-encryption-filldir-lookup-and-readlink.patch
ecryptfs-filename-encryption-mount-option.patch
ecryptfs-replace-%z-with-%z.patch
ecryptfs-fix-data-types-int-size_t.patch
ecryptfs-kerneldoc-for-ecryptfs_parse_tag_70_packet.patch
ecryptfs-clean-up-ecryptfs_decode_from_filename.patch
fs-ecryptfs-inodec-cleanup-kerneldoc.patch
By using lookup_one_len on an arbitrary underlying filesystem this
breaks the assumption that a nameidata is always available. Please
redo to use proper lookup helpers. Also whole code feels rather
fragile from a 10000 feet view, but beeing plsit in so many
patches it's almost impossible to properly review it anywya.
Post by Andrew Morton
hfs-add-basic-export-support.patch
I'm pretty sure we already had a version better than that in your
tree on the list. But I've lost track and we should just restart
the review cycle on -fsdevel.
Post by Andrew Morton
linuxpps-core-support.patch
looks generally good, but the comments should get a little loving.
Please remove the stupid filenames that always get out of sync in
the top of file comments, and make the documentation of exported
symbols kernel-doc instead of it's weird own format.

Does checkpatch.pl still not catch these things?

Also the ioctl certainly should be an unlocked_ioctl and not the
old BKL-locked variant. The !uarg checks in the ioctls can go,
copy_to/from_users does this automatically.

pps.h shoulkd be split into one header only defining the
kernel<->userspace ABI, and a kernel-internal one. That way
also the conditional includes can go away.
Post by Andrew Morton
pps-documentation-programs-and-examples.patch
Once again this stuff is in and utterly wrong place where it can't
easily be package for distros. ppsfind belongs into util-linux and
needs a proper mangage, ppsldisc is not nessecary but ldattach in
util-linux needs to grow support for N_PPS instead, and ppstest
should probably go into util-linux in a more polished version, too.
Post by Andrew Morton
pps-userland-header-file-for-pps-api.patch
This one is utterly wrong. It provides what should be a userspace
library as inlines in a kernel header.

Please do a proper libpps library package.
Post by Andrew Morton
generic-swap-sparc-rename-swap-to-swap_ulong.patch
generic-swap-iphase-rename-swap-to-swap_byte_order.patch
generic-swap-lib-sortc-rename-swap-to-swap_func.patch
generic-swap-introduce-global-macro-swapa-b.patch
generic-swap-ext3-remove-local-swap-macro.patch
generic-swap-ext4-remove-local-swap-macro.patch
generic-swap-sched-remove-local-swap-macro.patch
generic-swap-dcache-use-swap-instead-of-private-do_switch.patch
Add a kernel-wide swap() macro, use it. Merge.
Hmm, must have missed this when it went to lkml. Having this helper
generic is a good idea, but swap is far too generic for something
in kernel.h as indicated by the various renaming patches. How about
swap_vars?
Post by Andrew Morton
nilfs2-add-document.patch
nilfs2-disk-format-and-userland-interface.patch
nilfs2-add-inode-and-other-major-structures.patch
nilfs2-integrated-block-mapping.patch
nilfs2-b-tree-based-block-mapping.patch
nilfs2-direct-block-mapping.patch
nilfs2-b-tree-node-cache.patch
nilfs2-buffer-and-page-operations.patch
nilfs2-meta-data-file.patch
nilfs2-persistent-object-allocator.patch
nilfs2-disk-address-translator.patch
nilfs2-inode-map-file.patch
nilfs2-checkpoint-file.patch
nilfs2-segment-usage-file.patch
nilfs2-inode-operations.patch
nilfs2-inode-operations-fix.patch
nilfs2-file-operations.patch
nilfs2-directory-entry-operations.patch
nilfs2-pathname-operations.patch
nilfs2-pathname-operations-fix.patch
nilfs2-operations-for-the_nilfs-core-object.patch
nilfs2-super-block-operations.patch
nilfs2-super-block-operations-fix.patch
nilfs2-segment-buffer.patch
nilfs2-segment-constructor.patch
nilfs2-recovery-functions.patch
nilfs2-another-dat-for-garbage-collection.patch
nilfs2-block-cache-for-garbage-collection.patch
nilfs2-ioctl-operations.patch
nilfs2-update-makefile-and-kconfig.patch
#
nilfs2-fix-problems-of-memory-allocation-in-ioctl.patch
nilfs2-cleanup-nilfs_clear_inode.patch
nilfs2-avoid-double-error-caused-by-nilfs_transaction_end.patch
nilfs2-insert-explanations-in-gcinode-file.patch
nilfs2-add-maintainer.patch
nilfs2-fix-gc-failure-on-volumes-keeping-numerous-snapshots.patch
Dunno. Has this been reviewed enough?
No. I might eventually take a look, but looking into btrfs has a little
higher priority right now, and split into gazillions of
non-selfcontained patches certainly doesn't help reviewing it.

BTW, the current influx of higher-complexity filesystems certainly worries
me a little.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-06 23:10:12 UTC
Permalink
(cc added)

On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
fs-truncate-blocks-outside-i_size-after-o_direct-write-error.patch
fs-truncate-blocks-outside-i_size-after-o_direct-write-error-fix.patch
Btw, this code is still not quite right. We really need to call
->setattr instead of vmtruncate here. Complex filesystem need
transaction to properly free blocks, and those transactions are in
->setattr not inside vmtruncate where ->truncate doesn't even have
a chance to get the handle to the transaction passed.
As these patches don't make it worse this is not a NACK, but more of
a heads up.
Sure. Maybe add a FIXME comment for now?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-06 23:30:13 UTC
Permalink
Post by Andrew Morton
Post by Christoph Hellwig
Btw, this code is still not quite right. We really need to call
->setattr instead of vmtruncate here. Complex filesystem need
transaction to properly free blocks, and those transactions are in
->setattr not inside vmtruncate where ->truncate doesn't even have
a chance to get the handle to the transaction passed.
As these patches don't make it worse this is not a NACK, but more of
a heads up.
Sure. Maybe add a FIXME comment for now?
Ok. I was planning to look into this again, and IIRC Dave already did
when he was at SGI, but his proof of concept patches got lost somewhere.
Post by Andrew Morton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
---end quoted text---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Chinner
2009-01-07 02:20:05 UTC
Permalink
Post by Christoph Hellwig
Post by Andrew Morton
Post by Christoph Hellwig
Btw, this code is still not quite right. We really need to call
->setattr instead of vmtruncate here. Complex filesystem need
transaction to properly free blocks, and those transactions are in
->setattr not inside vmtruncate where ->truncate doesn't even have
a chance to get the handle to the transaction passed.
As these patches don't make it worse this is not a NACK, but more of
a heads up.
Sure. Maybe add a FIXME comment for now?
Ok. I was planning to look into this again, and IIRC Dave already did
when he was at SGI, but his proof of concept patches got lost somewhere.
Hmmmm - I think I posted the "it works for XFs but nothing else" POC
patches to fsdevel when I first found this....

<rummage>

http://marc.info/?l=linux-fsdevel&m=120952722315259&w=2

The thread starts here for those that want the whole story:

http://marc.info/?l=linux-fsdevel&m=120946361527726&w=2

Cheers,

Dave.
--
Dave Chinner
***@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dmitri Monakhov
2009-01-08 16:00:15 UTC
Permalink
Post by Dave Chinner
Post by Christoph Hellwig
Post by Andrew Morton
Post by Christoph Hellwig
Btw, this code is still not quite right. We really need to call
->setattr instead of vmtruncate here. Complex filesystem need
transaction to properly free blocks, and those transactions are in
->setattr not inside vmtruncate where ->truncate doesn't even have
a chance to get the handle to the transaction passed.
In fact ext3/4 opens transaction inside ->truncate() callback, but
because of function signature we can not properly handle any
errors inside truncate(see akpm's comment inside function)
Post by Dave Chinner
Post by Christoph Hellwig
Post by Andrew Morton
Post by Christoph Hellwig
As these patches don't make it worse this is not a NACK, but more of
a heads up.
Sure. Maybe add a FIXME comment for now?
Ok. I was planning to look into this again, and IIRC Dave already did
when he was at SGI, but his proof of concept patches got lost somewhere.
Hmmmm - I think I posted the "it works for XFs but nothing else" POC
patches to fsdevel when I first found this....
<rummage>
http://marc.info/?l=linux-fsdevel&m=120952722315259&w=2
http://marc.info/?l=linux-fsdevel&m=120946361527726&w=2
So AFAIU your proposal: for general(DIO_LOCKING) filesystems
ATTR_NO_LOCK means what i_mutex and i_alloc_sem already held.
Post by Dave Chinner
Cheers,
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-06 23:10:14 UTC
Permalink
(suitable cc's added)

On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
mm-invoke-oom-killer-from-page-fault.patch
mm-invoke-oom-killer-from-page-fault-fix.patch
mm-invoke-oom-killer-from-page-fault-fix-fix-2.patch
Just implementing this behaviour for x86 and uml is extremly
counter-productive. Please fix up all architectures as this
behaviour needs to be the same on all ports (at least those
with a MMU)
Yes, that would be nice.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-07 01:10:08 UTC
Permalink
Post by Andrew Morton
(suitable cc's added)
On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
mm-invoke-oom-killer-from-page-fault.patch
mm-invoke-oom-killer-from-page-fault-fix.patch
mm-invoke-oom-killer-from-page-fault-fix-fix-2.patch
Just implementing this behaviour for x86 and uml is extremly
counter-productive. Please fix up all architectures as this
behaviour needs to be the same on all ports (at least those
with a MMU)
Yes, that would be nice.
Yes I will do that. I cc'ed the linux-arch list a few times with hints ;)
But if this is now going upstream I'll do a quick pass to convert the rest
for 2.6.29.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-06 23:20:09 UTC
Permalink
(cc's added)

On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
hfs-add-basic-export-support.patch
I'm pretty sure we already had a version better than that in your
tree on the list. But I've lost track and we should just restart
the review cycle on -fsdevel.
Yeah, I have the three hfs patches:

hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
hfs-add-basic-export-support.patch

in a holding pattern awaiting a second round, due to laggy, incomplete
and confusing noises from various people. It all needs a revisit.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-06 23:30:11 UTC
Permalink
Post by Andrew Morton
Post by Christoph Hellwig
I'm pretty sure we already had a version better than that in your
tree on the list. But I've lost track and we should just restart
the review cycle on -fsdevel.
hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
hfs-add-basic-export-support.patch
in a holding pattern awaiting a second round, due to laggy, incomplete
and confusing noises from various people. It all needs a revisit.
The first two are not for me to decide. They look fine code-wise,
but IIRC Roman had some issues with wether the condition should be
possible at all.

The third one is where I requested a respin, and I'm pretty sure I've
seen a version with some improvement over the one in your tree. Let's
get the latests version back on -fsdevel and review it again.

The one in your tree certainly is not ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Warren Turkal
2009-01-06 23:30:11 UTC
Permalink
I have a drive at home with the condition. So empirically, it can happen.

I would also argue that having a journal bit set and then saying that
the journal info block is at 0 makes no sense anyhow since the first
1024 bytes of the volume must be empty on HFS+.

And, I found the previous code from Apple saying that a 0 in the
journal_info_block field indicated that there was no journal.

Is there anything else I should be doing?

wt
Post by Christoph Hellwig
Post by Andrew Morton
Post by Christoph Hellwig
I'm pretty sure we already had a version better than that in your
tree on the list. But I've lost track and we should just restart
the review cycle on -fsdevel.
hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
hfs-add-basic-export-support.patch
in a holding pattern awaiting a second round, due to laggy, incomplete
and confusing noises from various people. It all needs a revisit.
The first two are not for me to decide. They look fine code-wise,
but IIRC Roman had some issues with wether the condition should be
possible at all.
The third one is where I requested a respin, and I'm pretty sure I've
seen a version with some improvement over the one in your tree. Let's
get the latests version back on -fsdevel and review it again.
The one in your tree certainly is not ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Warren Turkal
2009-01-06 23:30:14 UTC
Permalink
Just to clarify, by "previous code", I meant I linked to it. It is not
the code I used for the patch.

wt
Post by Warren Turkal
I have a drive at home with the condition. So empirically, it can happen.
I would also argue that having a journal bit set and then saying that
the journal info block is at 0 makes no sense anyhow since the first
1024 bytes of the volume must be empty on HFS+.
And, I found the previous code from Apple saying that a 0 in the
journal_info_block field indicated that there was no journal.
Is there anything else I should be doing?
wt
Post by Christoph Hellwig
Post by Andrew Morton
Post by Christoph Hellwig
I'm pretty sure we already had a version better than that in your
tree on the list. But I've lost track and we should just restart
the review cycle on -fsdevel.
hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
hfs-add-basic-export-support.patch
in a holding pattern awaiting a second round, due to laggy, incomplete
and confusing noises from various people. It all needs a revisit.
The first two are not for me to decide. They look fine code-wise,
but IIRC Roman had some issues with wether the condition should be
possible at all.
The third one is where I requested a respin, and I'm pretty sure I've
seen a version with some improvement over the one in your tree. Let's
get the latests version back on -fsdevel and review it again.
The one in your tree certainly is not ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Roman Zippel
2009-01-12 03:40:12 UTC
Permalink
Hi,

On Tue, 6 Jan 2009, Warren Turkal wrote:

(Sorry for the delay.)
Post by Warren Turkal
I have a drive at home with the condition. So empirically, it can happen.
One problem is that there is no explanation how it happened.
The other problem is that in the Apple driver or tools I haven't found an
equivalent (unless you disable journaling completely), there is simply no
special handling of a zero in this field.
I find it more likely that some repair tool simply sets this field to
zero, so it forces the OS X driver to reinitialize the journal file. It
might help to look at the last_mount field to have some idea who accessed
the volume last.
So your first patch is kinda trivial, although most of comment isn't
needed and is irrelevant to the patch itself, however I don't see a reason
to apply the second patch.

bye, Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-06 23:40:09 UTC
Permalink
Yes, the version you attached looks much better, and correct.
+++ b/fs/hfsplus/export.c
@@ -0,0 +1,118 @@
+/*
+ * linux/fs/hfsplus/export.c
+ *
Please don't put filenames in top of file comments. They don't serve
any purpose and easily get out of date.
+ if ( be16_to_cpu(entry.type) != HFSPLUS_FOLDER_THREAD) {
no space after the opening brace, please/
+ inode = hfsplus_iget(child->d_sb, be32_to_cpu(entry.thread.parentID));
+ if (IS_ERR(inode)) {
+ printk(KERN_ERR "hfs: unable to find parent, call the social services\n");
+ return ERR_CAST(inode);
+ }
no lines longer than 80 characters please.
+ inode = hfsplus_iget(sb, ino);
+ if (IS_ERR(inode))
+ return ERR_CAST(inode);
+
+ /* probably superfluous but it does not seem to hurt */
+ if (generation && inode->i_generation != generation) {
+ /* we didn't find the right inode.. */
+ iput(inode);
+ return ERR_PTR(-ESTALE);
+ }
+ return inode;
Given that hfsplus never sets i_generation it's superflous. So just
write the above as

return hfsplus_iget(sb, ino);

And maybe write a little comment that there is no generation number
in hfsplus.
+/* Yes, most of these are left as NULL!!
+ * A NULL value implies the default, which works with hfs+-like file
+ * systems, but can be improved upon.
+ */
No need for this comment I think. All this is pretty well documented
in Documentation/filesystems/Exporting, and all the other filesystems
that just fill out these three methods don't comment on it either.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Harvey Harrison
2009-01-06 23:50:08 UTC
Permalink
Post by Christoph Hellwig
Yes, the version you attached looks much better, and correct.
+++ b/fs/hfsplus/export.c
@@ -0,0 +1,118 @@
+/*
+ * linux/fs/hfsplus/export.c
+ *
Please don't put filenames in top of file comments. They don't serve
any purpose and easily get out of date.
+ if ( be16_to_cpu(entry.type) != HFSPLUS_FOLDER_THREAD) {
no space after the opening brace, please/
One other nit, byteswap the constant so it can be done at compile-time:

if (entry.type != cpu_to_be16(HFSPLUS_FOLDER_THREAD)) {

Harvey

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Harvey Harrison
2009-01-07 00:20:09 UTC
Permalink
I copied over the code from dir.c, so I've propagated the change to
that, and also to super.c where a similar case was present, I'm
attaching it at 0002 (but maybe it should go in before the NFS export
support?).
I've not checked if there are other cases where this can be optimised
though, maybe I should.
Depending on how often they are used, perhaps just define those constants
directly as be values and get the cpu_to_beXX out of the codepaths. If
they're also used on cpu-endian values, this isn't so great...but I haven't
actually looked.

Cheers,

Harvey
If you all are in mood of HFS+ patches review, I might try to run the
code through a couple of my tools, I had in my TODO list to try them on
kernel code for a while ;)
Feel free to send me whatever your most recent patchset is and I'll have a
look at it. (at least a good sparse-checkup)

Cheers,

Harvey

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Roman Zippel
2009-01-12 04:30:18 UTC
Permalink
Hi,
Yes that one wasn't good at all, and I feel sorry for not having noticed
that before sending it in the first place.
In general you could also use the create_date field to initialize the
generation field (it's set in hfsplus_cat_build_record and should be read
in hfsplus_cat_read_inode). (BTW OS X doesn't use create_date because it
can be changed by the user, which isn't an issue for Linux).
I have some doubts about the hfsplus_get_parent() function. One has to
know about HFS+ that every hard link has it's own link id (which is
usually not visible) and the common inode id. If you lookup the parent
like this you expose the usually hidden and private directory.
The link id is stored in d_fsdata under Linux, which seems not to be
restored by hfsplus_fh_to_dentry(), so any catalog manipulations are
likely to hit the wrong catalog entry. Any catalog change requires the
correct link id, but with just the common id you currently can't find back
the link entry.
Newer HFS+ OS X driver support a link chain, which would make it possible
to find back the link entry using the common id and create_date in case
the normal file became a hard link, but this isn't implemented under Linux
yet.
So it seems the hard link handling may need a bit more work...

bye, Roman
Andrew Morton
2009-01-06 23:20:11 UTC
Permalink
(cc added)

On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
fs-sys_sync-fix.patch
I'm not sure this is a good idea. Concurrent syncs are a bad idea
to start with and we should just synchronyze do_sync completely.
sync_filesystems as one of the main components of do_sync already
is synchronized in that way, and taking that to a higher level would
get rid of all the worries about concurrent syncs.
Yes, single-threading sys_sync() would fix the problem which that patch
addresses.

However there are a lot of performance and correctness issues around
sys_sync()-versus-fsync(), etc for which such a simple fix won't be
acceptable.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-06 23:30:17 UTC
Permalink
Post by Andrew Morton
Post by Christoph Hellwig
I'm not sure this is a good idea. Concurrent syncs are a bad idea
to start with and we should just synchronyze do_sync completely.
sync_filesystems as one of the main components of do_sync already
is synchronized in that way, and taking that to a higher level would
get rid of all the worries about concurrent syncs.
Yes, single-threading sys_sync() would fix the problem which that patch
addresses.
However there are a lot of performance and correctness issues around
sys_sync()-versus-fsync(), etc for which such a simple fix won't be
acceptable.
fsync should really not much interac with sync at that level. While
they both end up at same primitives at the lowest level those aren't
the ones we're trying to protect against. I'm currently in the process
of a major rework of sys_sync/do_sync to make it work properly for
modern filesystems and the global synchronization was one of the first
things I did..

So if you have any workloads where that causes a problem please send
them my way. Not that I can really thing of them, given the global
nature of sys_sync I can't see any benefit of doing multiple of these
in parallel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-07 01:20:06 UTC
Permalink
Post by Christoph Hellwig
Post by Andrew Morton
Post by Christoph Hellwig
I'm not sure this is a good idea. Concurrent syncs are a bad idea
to start with and we should just synchronyze do_sync completely.
sync_filesystems as one of the main components of do_sync already
is synchronized in that way, and taking that to a higher level would
get rid of all the worries about concurrent syncs.
Yes, single-threading sys_sync() would fix the problem which that patch
addresses.
However there are a lot of performance and correctness issues around
sys_sync()-versus-fsync(), etc for which such a simple fix won't be
acceptable.
fsync should really not much interac with sync at that level. While
they both end up at same primitives at the lowest level those aren't
the ones we're trying to protect against. I'm currently in the process
of a major rework of sys_sync/do_sync to make it work properly for
modern filesystems and the global synchronization was one of the first
things I did..
So if you have any workloads where that causes a problem please send
them my way. Not that I can really thing of them, given the global
nature of sys_sync I can't see any benefit of doing multiple of these
in parallel.
I can't see a problem with putting a global mutex around sys_sync (almost
by definition, any app in the last 10+ years that calls sys_sync is not
performance critical).

But this patch fixes a correctness problem, so I think it is OK to go
upstream now.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andi Kleen
2009-01-07 01:40:05 UTC
Permalink
Post by Nick Piggin
I can't see a problem with putting a global mutex around sys_sync (almost
by definition, any app in the last 10+ years that calls sys_sync is not
performance critical).
Hmm, but sync() used to (is still?) livelocky and when it takes a
minute or so to flush (and I've seen that) do you really want any
other sync user to block for a minute too?

-Andi
--
***@linux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-07 01:50:05 UTC
Permalink
Post by Andi Kleen
Post by Nick Piggin
I can't see a problem with putting a global mutex around sys_sync (almost
by definition, any app in the last 10+ years that calls sys_sync is not
performance critical).
Hmm, but sync() used to (is still?) livelocky and when it takes a
It's not livelocky because it no longer has to do repeated passes
over the superblock list. It is subject to the single inode syncing
issue where it can get stuck behind a process dirtying memory (same
as fsync) but we've decided not to add complexity to improve that
just yet, and see whether it turns out to be a real problem.
Post by Andi Kleen
minute or so to flush (and I've seen that) do you really want any
other sync user to block for a minute too?
sys_sync B which is invoked *after* sys_sync caller A should not
return before A. If you didn't have a global lock, they'd tend to
block one another's pages anyway. I think it's OK.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andi Kleen
2009-01-07 02:50:06 UTC
Permalink
Post by Nick Piggin
sys_sync B which is invoked *after* sys_sync caller A should not
return before A. If you didn't have a global lock, they'd tend to
block one another's pages anyway. I think it's OK.
It means that you cannot reboot because reboot does sync.
What happens when the sync gets stuck somewhere on a really
slow device?

-Andi
--
***@linux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-07 03:30:10 UTC
Permalink
Post by Andi Kleen
Post by Nick Piggin
sys_sync B which is invoked *after* sys_sync caller A should not
return before A. If you didn't have a global lock, they'd tend to
block one another's pages anyway. I think it's OK.
It means that you cannot reboot because reboot does sync.
What happens when the sync gets stuck somewhere on a really
slow device?
I don't follow you.

The sync gets "stuck" because it is writing out dirty data. You
don't want to reboot before that happens, which is exactly the
reason why sync gets called (although it is probably not needed
anyway if all filesystems get unmounted).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
2009-01-10 10:20:05 UTC
Permalink
Post by Andi Kleen
Post by Nick Piggin
sys_sync B which is invoked *after* sys_sync caller A should not
return before A. If you didn't have a global lock, they'd tend to
block one another's pages anyway. I think it's OK.
It means that you cannot reboot because reboot does sync.
What happens when the sync gets stuck somewhere on a really
slow device?
And what do you propose? Silently corrupt data on the slow device?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andi Kleen
2009-01-10 15:00:11 UTC
Permalink
Post by Pavel Machek
Post by Andi Kleen
Post by Nick Piggin
sys_sync B which is invoked *after* sys_sync caller A should not
return before A. If you didn't have a global lock, they'd tend to
block one another's pages anyway. I think it's OK.
It means that you cannot reboot because reboot does sync.
What happens when the sync gets stuck somewhere on a really
slow device?
And what do you propose? Silently corrupt data on the slow device?
Yes not writing is better than being unable to reboot.

There should be always a timeout at least for the reboot case.

Consider it from a uptime perspective: if something is really
screwed up (and that happens sometimes; classical example
was the IO stack getting hung up forever in error handling
loops) the only way to get running again is to reboot and try again.

-Andi
--
***@linux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
2009-01-10 21:40:10 UTC
Permalink
Post by Andi Kleen
Post by Pavel Machek
Post by Andi Kleen
Post by Nick Piggin
sys_sync B which is invoked *after* sys_sync caller A should not
return before A. If you didn't have a global lock, they'd tend to
block one another's pages anyway. I think it's OK.
It means that you cannot reboot because reboot does sync.
What happens when the sync gets stuck somewhere on a really
slow device?
And what do you propose? Silently corrupt data on the slow device?
Yes not writing is better than being unable to reboot.
Disagreed.
Post by Andi Kleen
There should be always a timeout at least for the reboot case.
Why? If you don't want to sync the data on disk, don't call the sync
syscall.
Post by Andi Kleen
Consider it from a uptime perspective: if something is really
screwed up (and that happens sometimes; classical example
was the IO stack getting hung up forever in error handling
loops) the only way to get running again is to reboot and try again.
reboot() syscall should not sync.

sync() syscall should not return unless data are written on disk,
however slow that may be.

maybe reboot utility should not call sync()...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andi Kleen
2009-01-10 22:00:09 UTC
Permalink
Post by Pavel Machek
Post by Andi Kleen
Post by Pavel Machek
Post by Andi Kleen
Post by Nick Piggin
sys_sync B which is invoked *after* sys_sync caller A should not
return before A. If you didn't have a global lock, they'd tend to
block one another's pages anyway. I think it's OK.
It means that you cannot reboot because reboot does sync.
What happens when the sync gets stuck somewhere on a really
slow device?
And what do you propose? Silently corrupt data on the slow device?
Yes not writing is better than being unable to reboot.
Disagreed.
Well you're just forcing the user to press power/reset/sysrq-b which
will pretty much guarantee data loss if anything is unwritten.
Post by Pavel Machek
maybe reboot utility should not call sync()...
I think it should call sync(), but have a suitable timeout.
Never spend more than 10 seconds on the sync. And give user visible
feedback during the countdown.

Now of course fixing the complete IO stack to support timeouts
might be too hard (although in theory they're already supposed
to have them, but as we know that doesn't always work reliable)

One alternative would be to do it with a background thread
(which seems to be en vogue right now anyways)
Ok I suppose with that Nick's lock is actually ok, although
I still don't like it very much.

-Andi
--
***@linux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
2009-01-10 22:30:11 UTC
Permalink
Post by Andi Kleen
Post by Pavel Machek
Post by Andi Kleen
Post by Pavel Machek
Post by Andi Kleen
Post by Nick Piggin
sys_sync B which is invoked *after* sys_sync caller A should not
return before A. If you didn't have a global lock, they'd tend to
block one another's pages anyway. I think it's OK.
It means that you cannot reboot because reboot does sync.
What happens when the sync gets stuck somewhere on a really
slow device?
And what do you propose? Silently corrupt data on the slow device?
Yes not writing is better than being unable to reboot.
Disagreed.
Well you're just forcing the user to press power/reset/sysrq-b which
will pretty much guarantee data loss if anything is unwritten.
Well, ok, data loss is expected in such case. It is not expected on
"clean reboot".
Post by Andi Kleen
Post by Pavel Machek
maybe reboot utility should not call sync()...
I think it should call sync(), but have a suitable timeout.
Never spend more than 10 seconds on the sync. And give user visible
feedback during the countdown.
if fork() {
sync()
} else {
sleep(10)
reboot()
}

..is perfectly doable in userspace.
Post by Andi Kleen
One alternative would be to do it with a background thread
(which seems to be en vogue right now anyways)
Ok I suppose with that Nick's lock is actually ok, although
I still don't like it very much.
Yes, I believe Nick's lock is okay and needed.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
2009-01-10 10:20:06 UTC
Permalink
Hi!
Post by Christoph Hellwig
Post by Andrew Morton
Post by Christoph Hellwig
I'm not sure this is a good idea. Concurrent syncs are a bad idea
to start with and we should just synchronyze do_sync completely.
sync_filesystems as one of the main components of do_sync already
is synchronized in that way, and taking that to a higher level would
get rid of all the worries about concurrent syncs.
Yes, single-threading sys_sync() would fix the problem which that patch
addresses.
However there are a lot of performance and correctness issues around
sys_sync()-versus-fsync(), etc for which such a simple fix won't be
acceptable.
fsync should really not much interac with sync at that level. While
they both end up at same primitives at the lowest level those aren't
the ones we're trying to protect against. I'm currently in the process
of a major rework of sys_sync/do_sync to make it work properly for
modern filesystems and the global synchronization was one of the first
things I did..
So if you have any workloads where that causes a problem please send
them my way. Not that I can really thing of them, given the global
nature of sys_sync I can't see any benefit of doing multiple of these
in parallel.
I did play with fsync() a bit, and realized it mostly does not
work. (Yes, I did physically unplug the media). I have some scripts,
and am currently converting them to nbd so that I will not have to
physically pull anything.

Jack has some ext2 fix provoked by those tests...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-06 23:20:12 UTC
Permalink
(cc's added)

On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
ecryptfs-filename-encryption-tag-70-packets.patch
ecryptfs-filename-encryption-header-updates.patch
ecryptfs-filename-encryption-encoding-and-encryption-functions.patch
ecryptfs-filename-encryption-filldir-lookup-and-readlink.patch
ecryptfs-filename-encryption-mount-option.patch
ecryptfs-replace-%z-with-%z.patch
ecryptfs-fix-data-types-int-size_t.patch
ecryptfs-kerneldoc-for-ecryptfs_parse_tag_70_packet.patch
ecryptfs-clean-up-ecryptfs_decode_from_filename.patch
fs-ecryptfs-inodec-cleanup-kerneldoc.patch
By using lookup_one_len on an arbitrary underlying filesystem this
breaks the assumption that a nameidata is always available. Please
redo to use proper lookup helpers.
It that a nack, or do we think we can address this in the next week or
three?
Post by Christoph Hellwig
Also whole code feels rather
fragile from a 10000 feet view, but beeing plsit in so many
patches it's almost impossible to properly review it anywya.
Yes, it made my brain hurt.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-06 23:30:13 UTC
Permalink
Post by Andrew Morton
Post by Christoph Hellwig
Post by Andrew Morton
ecryptfs-filename-encryption-tag-70-packets.patch
ecryptfs-filename-encryption-header-updates.patch
ecryptfs-filename-encryption-encoding-and-encryption-functions.patch
ecryptfs-filename-encryption-filldir-lookup-and-readlink.patch
ecryptfs-filename-encryption-mount-option.patch
ecryptfs-replace-%z-with-%z.patch
ecryptfs-fix-data-types-int-size_t.patch
ecryptfs-kerneldoc-for-ecryptfs_parse_tag_70_packet.patch
ecryptfs-clean-up-ecryptfs_decode_from_filename.patch
fs-ecryptfs-inodec-cleanup-kerneldoc.patch
By using lookup_one_len on an arbitrary underlying filesystem this
breaks the assumption that a nameidata is always available. Please
redo to use proper lookup helpers.
It that a nack, or do we think we can address this in the next week or
three?
Together we the state of the rest of that code that's a NACK, yes :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-07 08:00:22 UTC
Permalink
Post by Christoph Hellwig
Post by Andrew Morton
Post by Christoph Hellwig
Post by Andrew Morton
ecryptfs-filename-encryption-tag-70-packets.patch
ecryptfs-filename-encryption-header-updates.patch
ecryptfs-filename-encryption-encoding-and-encryption-functions.patch
ecryptfs-filename-encryption-filldir-lookup-and-readlink.patch
ecryptfs-filename-encryption-mount-option.patch
ecryptfs-replace-%z-with-%z.patch
ecryptfs-fix-data-types-int-size_t.patch
ecryptfs-kerneldoc-for-ecryptfs_parse_tag_70_packet.patch
ecryptfs-clean-up-ecryptfs_decode_from_filename.patch
fs-ecryptfs-inodec-cleanup-kerneldoc.patch
By using lookup_one_len on an arbitrary underlying filesystem this
breaks the assumption that a nameidata is always available. Please
redo to use proper lookup helpers.
It that a nack, or do we think we can address this in the next week or
three?
Together we the state of the rest of that code that's a NACK, yes :)
Umm, why did you you just push this in anyway without comment?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-07 08:10:08 UTC
Permalink
Post by Christoph Hellwig
Post by Christoph Hellwig
Post by Andrew Morton
Post by Christoph Hellwig
Post by Andrew Morton
ecryptfs-filename-encryption-tag-70-packets.patch
ecryptfs-filename-encryption-header-updates.patch
ecryptfs-filename-encryption-encoding-and-encryption-functions.patch
ecryptfs-filename-encryption-filldir-lookup-and-readlink.patch
ecryptfs-filename-encryption-mount-option.patch
ecryptfs-replace-%z-with-%z.patch
ecryptfs-fix-data-types-int-size_t.patch
ecryptfs-kerneldoc-for-ecryptfs_parse_tag_70_packet.patch
ecryptfs-clean-up-ecryptfs_decode_from_filename.patch
fs-ecryptfs-inodec-cleanup-kerneldoc.patch
By using lookup_one_len on an arbitrary underlying filesystem this
breaks the assumption that a nameidata is always available. Please
redo to use proper lookup helpers.
It that a nack, or do we think we can address this in the next week or
three?
Together we the state of the rest of that code that's a NACK, yes :)
Umm, why did you you just push this in anyway without comment?
I'd sent them before you sent your comments. I didn't think I had
done that, so I didn't mention it earlier.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-07 08:20:04 UTC
Permalink
Post by Andrew Morton
I'd sent them before you sent your comments. I didn't think I had
done that, so I didn't mention it earlier.
Ok. Someone's gotta sort that pile out now, fun..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-06 23:20:14 UTC
Permalink
(cc added)

On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
softirq-introduce-statistics-for-softirq.patch
proc-export-statistics-for-softirq-to-proc.patch
proc-update-document-for-proc-softirqs-and-proc-stat.patch
Why is this in procfs?
softirq stuff in /proc seems appropriate? It's alongside
/proc/interrupts. We could put it in /trendy-fs-of-the-day, but what
would it gain us?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-06 23:30:16 UTC
Permalink
Post by Andrew Morton
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
softirq-introduce-statistics-for-softirq.patch
proc-export-statistics-for-softirq-to-proc.patch
proc-update-document-for-proc-softirqs-and-proc-stat.patch
Why is this in procfs?
softirq stuff in /proc seems appropriate? It's alongside
/proc/interrupts. We could put it in /trendy-fs-of-the-day, but what
would it gain us?
debugfs seems to be the normal thing for these.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-06 23:40:11 UTC
Permalink
On Tue, 6 Jan 2009 18:24:39 -0500
Post by Christoph Hellwig
Post by Andrew Morton
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
softirq-introduce-statistics-for-softirq.patch
proc-export-statistics-for-softirq-to-proc.patch
proc-update-document-for-proc-softirqs-and-proc-stat.patch
Why is this in procfs?
softirq stuff in /proc seems appropriate? It's alongside
/proc/interrupts. We could put it in /trendy-fs-of-the-day, but what
would it gain us?
debugfs seems to be the normal thing for these.
hm. I'm not a huge fan of debugfs (for other reasons, nicely explained
by Matt Mackall a while back).

But I don't think we actually *gain* anything by putting softirq stats
into debugfs, whereas it makes sense that it lives in /proc?

otoh, the internal implementation might be nicer if it uses debugfs
helper infrastructure. But the existing code is pretty
straightforward.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-07 02:10:07 UTC
Permalink
Post by Andrew Morton
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
softirq-introduce-statistics-for-softirq.patch
proc-export-statistics-for-softirq-to-proc.patch
proc-update-document-for-proc-softirqs-and-proc-stat.patch
Why is this in procfs?
softirq stuff in /proc seems appropriate? It's alongside
/proc/interrupts. We could put it in /trendy-fs-of-the-day, but what
would it gain us?
Haven't we kind of agreed to use sysfs for things like this? A few years
too late to be raising objections now ;)

One problem I have with sysfs is that it (the directory structure, rather
than the sysfs code itself) really needs to be policed and maintained
by a central and coherent place/person with taste. Otherwise people put
their own random crap with their own random naming schemes and becomes
a crazy mess.

softirqs are not hardware but purely kernel subsystem construct, as such
they probably go under /sys/kernel/. People unfortunately have already
added random crap to the /sys/kernel/ root directory, but future additions
really should go into a good subdirectory structure (putting it into the
root directory is equivalent to ditching all subdirectories from /proc/sys/).

/sys/kernel/softirq/*, I suggest.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-07 02:20:07 UTC
Permalink
Post by Nick Piggin
Post by Andrew Morton
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
softirq-introduce-statistics-for-softirq.patch
proc-export-statistics-for-softirq-to-proc.patch
proc-update-document-for-proc-softirqs-and-proc-stat.patch
Why is this in procfs?
softirq stuff in /proc seems appropriate? It's alongside
/proc/interrupts. We could put it in /trendy-fs-of-the-day, but what
would it gain us?
Haven't we kind of agreed to use sysfs for things like this? A few years
too late to be raising objections now ;)
One problem I have with sysfs is that it (the directory structure, rather
than the sysfs code itself) really needs to be policed and maintained
by a central and coherent place/person with taste. Otherwise people put
their own random crap with their own random naming schemes and becomes
a crazy mess.
softirqs are not hardware but purely kernel subsystem construct, as such
they probably go under /sys/kernel/. People unfortunately have already
added random crap to the /sys/kernel/ root directory, but future additions
really should go into a good subdirectory structure (putting it into the
root directory is equivalent to ditching all subdirectories from /proc/sys/).
All sounds like pointless wank^Wbikeshed painting to me.
Post by Nick Piggin
/sys/kernel/softirq/*, I suggest.
What would that *improve*?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-07 03:10:07 UTC
Permalink
Post by Andrew Morton
Post by Nick Piggin
Post by Andrew Morton
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
softirq-introduce-statistics-for-softirq.patch
proc-export-statistics-for-softirq-to-proc.patch
proc-update-document-for-proc-softirqs-and-proc-stat.patch
Why is this in procfs?
softirq stuff in /proc seems appropriate? It's alongside
/proc/interrupts. We could put it in /trendy-fs-of-the-day, but what
would it gain us?
Haven't we kind of agreed to use sysfs for things like this? A few years
too late to be raising objections now ;)
One problem I have with sysfs is that it (the directory structure, rather
than the sysfs code itself) really needs to be policed and maintained
by a central and coherent place/person with taste. Otherwise people put
their own random crap with their own random naming schemes and becomes
a crazy mess.
softirqs are not hardware but purely kernel subsystem construct, as such
they probably go under /sys/kernel/. People unfortunately have already
added random crap to the /sys/kernel/ root directory, but future
additions really should go into a good subdirectory structure (putting it
into the root directory is equivalent to ditching all subdirectories from
/proc/sys/).
All sounds like pointless wank^Wbikeshed painting to me.
Really? Our userspace ABI? You think it works bestter when there is as
little thought as possible put into it and everybody just does what
they feel is best?
Post by Andrew Morton
Post by Nick Piggin
/sys/kernel/softirq/*, I suggest.
What would that *improve*?
It would be logically in the right place.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-07 04:20:08 UTC
Permalink
Post by Nick Piggin
Post by Andrew Morton
Post by Nick Piggin
Post by Andrew Morton
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
softirq-introduce-statistics-for-softirq.patch
proc-export-statistics-for-softirq-to-proc.patch
proc-update-document-for-proc-softirqs-and-proc-stat.patch
Why is this in procfs?
softirq stuff in /proc seems appropriate? It's alongside
/proc/interrupts. We could put it in /trendy-fs-of-the-day, but what
would it gain us?
Haven't we kind of agreed to use sysfs for things like this? A few years
too late to be raising objections now ;)
One problem I have with sysfs is that it (the directory structure, rather
than the sysfs code itself) really needs to be policed and maintained
by a central and coherent place/person with taste. Otherwise people put
their own random crap with their own random naming schemes and becomes
a crazy mess.
softirqs are not hardware but purely kernel subsystem construct, as such
they probably go under /sys/kernel/. People unfortunately have already
added random crap to the /sys/kernel/ root directory, but future
additions really should go into a good subdirectory structure (putting it
into the root directory is equivalent to ditching all subdirectories from
/proc/sys/).
All sounds like pointless wank^Wbikeshed painting to me.
Really? Our userspace ABI? You think it works bestter when there is as
little thought as possible put into it and everybody just does what
they feel is best?
If I thought that, I would say it.
Post by Nick Piggin
Post by Andrew Morton
Post by Nick Piggin
/sys/kernel/softirq/*, I suggest.
What would that *improve*?
It would be logically in the right place.
That's STILL not a *reason*. Nobody has provded a reason.

Here's a reason: look in /proc. It contains "interrupts", "irq",
"vmstat", "meminfo", etc. All simple files which provide realtime view
of core kernel activity. Which is precisely what /proc/softirq does!

So putting it in /proc/softirq is "logical", and yanking it out and
stuffing it in some random other place for reasons which nobody can
explain is illogical.

Plus the patch adds a summary line to the existing /proc/stat. Which
is also logical. Do we do that in debugfs too?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-06 23:30:08 UTC
Permalink
(cc added)

On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
generic-swap-sparc-rename-swap-to-swap_ulong.patch
generic-swap-iphase-rename-swap-to-swap_byte_order.patch
generic-swap-lib-sortc-rename-swap-to-swap_func.patch
generic-swap-introduce-global-macro-swapa-b.patch
generic-swap-ext3-remove-local-swap-macro.patch
generic-swap-ext4-remove-local-swap-macro.patch
generic-swap-sched-remove-local-swap-macro.patch
generic-swap-dcache-use-swap-instead-of-private-do_switch.patch
Add a kernel-wide swap() macro, use it. Merge.
Hmm, must have missed this when it went to lkml. Having this helper
generic is a good idea, but swap is far too generic for something
in kernel.h as indicated by the various renaming patches. How about
swap_vars?
I thought that swap() was a good name, actually.

Sure, it's bold. But we only have one swap() implementation,
kernel-wide, forever, right? So what the heck: call it swap()!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2009-01-06 23:30:14 UTC
Permalink
(cc added)

On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
nilfs2-add-document.patch
nilfs2-disk-format-and-userland-interface.patch
nilfs2-add-inode-and-other-major-structures.patch
nilfs2-integrated-block-mapping.patch
nilfs2-b-tree-based-block-mapping.patch
nilfs2-direct-block-mapping.patch
nilfs2-b-tree-node-cache.patch
nilfs2-buffer-and-page-operations.patch
nilfs2-meta-data-file.patch
nilfs2-persistent-object-allocator.patch
nilfs2-disk-address-translator.patch
nilfs2-inode-map-file.patch
nilfs2-checkpoint-file.patch
nilfs2-segment-usage-file.patch
nilfs2-inode-operations.patch
nilfs2-inode-operations-fix.patch
nilfs2-file-operations.patch
nilfs2-directory-entry-operations.patch
nilfs2-pathname-operations.patch
nilfs2-pathname-operations-fix.patch
nilfs2-operations-for-the_nilfs-core-object.patch
nilfs2-super-block-operations.patch
nilfs2-super-block-operations-fix.patch
nilfs2-segment-buffer.patch
nilfs2-segment-constructor.patch
nilfs2-recovery-functions.patch
nilfs2-another-dat-for-garbage-collection.patch
nilfs2-block-cache-for-garbage-collection.patch
nilfs2-ioctl-operations.patch
nilfs2-update-makefile-and-kconfig.patch
#
nilfs2-fix-problems-of-memory-allocation-in-ioctl.patch
nilfs2-cleanup-nilfs_clear_inode.patch
nilfs2-avoid-double-error-caused-by-nilfs_transaction_end.patch
nilfs2-insert-explanations-in-gcinode-file.patch
nilfs2-add-maintainer.patch
nilfs2-fix-gc-failure-on-volumes-keeping-numerous-snapshots.patch
Dunno. Has this been reviewed enough?
No. I might eventually take a look, but looking into btrfs has a little
higher priority right now, and split into gazillions of
non-selfcontained patches certainly doesn't help reviewing it.
nilfs will remain under development for a couple of months and we'll
take a look at a 2.6.20 merge. Can you please find time to take a
closer look during this cycle?
Post by Christoph Hellwig
BTW, the current influx of higher-complexity filesystems certainly worries
me a little.
Well yes. Each new filesystem (complex or not) is an additional
boatanchor on development of core kernel: block, vfs, MM, etc. So each
filesystem should be justified on the basis that it adds sufficient
benefit to justify that cost. (And I got mau-muaed for pointing this
out in the omfs context, I might add).

Will nilfs bring enough value to justify it's cost? Hard call. What
do you think?

(otoh, we could probably randomly delete ten old filesystems and
practically nobody would notice)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-07 02:30:07 UTC
Permalink
Post by Andrew Morton
Post by Christoph Hellwig
BTW, the current influx of higher-complexity filesystems certainly
worries me a little.
Well yes. Each new filesystem (complex or not) is an additional
boatanchor on development of core kernel: block, vfs, MM, etc. So each
filesystem should be justified on the basis that it adds sufficient
benefit to justify that cost. (And I got mau-muaed for pointing this
out in the omfs context, I might add).
I've found that if the filesystems have active maintainers who are willing
to help eg. if some MM APIs need to change, then it isn't such a big problem.

It simply doesn't scale and will not work if an MM developer is expected to
go through and try to understand *every* filesystem, attempt to change them,
and test them even though it's non-trivial to even set up and mount a lot
of these things to test them.

Each individual filesystem development community already knows their fs code,
has test environments set up (or presumably can at least mount the thing),
and only need to understand one little changed aspect of the MM, with the
help from the MM developer.

Latter system is efficient and scales, former does not.

If a filesystem is merged it has to have a pretty good promise that it will
be well maintained. (obviously it still has to justify a cost, but that cost
becomes sane)
Post by Andrew Morton
Will nilfs bring enough value to justify it's cost? Hard call. What
do you think?
(otoh, we could probably randomly delete ten old filesystems and
practically nobody would notice)
I don't know how stable fuse APIs are (ie. whether we'd just be handing the
anchors to FUSE), but if it is very stable, then it would be nice to push a
lot of them out of the kernel (although OTOH the old ones tend not to have
complex interactions with mm or block layer).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Miklos Szeredi
2009-01-08 08:40:07 UTC
Permalink
Post by Nick Piggin
I don't know how stable fuse APIs are (ie. whether we'd just be handing the
anchors to FUSE), but if it is very stable, then it would be nice to push a
lot of them out of the kernel (although OTOH the old ones tend not to have
complex interactions with mm or block layer).
Fuse APIs are very stable, so pushing old filesystems out to userspace
makes sense. Porting them, however, is not entirely trivial. Amit
Singh (of MacFUSE) got minix, ufs and sysvfs to work on OSX using only
lightly modified linux source code. That framework could probably be
used to port other filesystems to userspace.

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Piggin
2009-01-15 06:50:09 UTC
Permalink
Post by Miklos Szeredi
Post by Nick Piggin
I don't know how stable fuse APIs are (ie. whether we'd just be handing
the anchors to FUSE), but if it is very stable, then it would be nice to
push a lot of them out of the kernel (although OTOH the old ones tend not
to have complex interactions with mm or block layer).
Fuse APIs are very stable, so pushing old filesystems out to userspace
makes sense. Porting them, however, is not entirely trivial. Amit
Singh (of MacFUSE) got minix, ufs and sysvfs to work on OSX using only
lightly modified linux source code. That framework could probably be
used to port other filesystems to userspace.
That might be nice. OTOH it is just a random suggestion from me. I don't
know what core fs developers think about requiring fuse and user code to
mount these old things...

Would we have to distribute the user code with the kernel? I guess then
we would still need to maintain it, but I guess the key improvement would
be that fuse APIs are very stable.

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

Andrew Morton
2009-01-06 23:30:17 UTC
Permalink
(cc's added)

On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
linuxpps-core-support.patch
looks generally good, but the comments should get a little loving.
Please remove the stupid filenames that always get out of sync in
the top of file comments, and make the documentation of exported
symbols kernel-doc instead of it's weird own format.
Does checkpatch.pl still not catch these things?
Also the ioctl certainly should be an unlocked_ioctl and not the
old BKL-locked variant. The !uarg checks in the ioctls can go,
copy_to/from_users does this automatically.
pps.h shoulkd be split into one header only defining the
kernel<->userspace ABI, and a kernel-internal one. That way
also the conditional includes can go away.
Post by Andrew Morton
pps-documentation-programs-and-examples.patch
Once again this stuff is in and utterly wrong place where it can't
easily be package for distros. ppsfind belongs into util-linux and
needs a proper mangage, ppsldisc is not nessecary but ldattach in
util-linux needs to grow support for N_PPS instead, and ppstest
should probably go into util-linux in a more polished version, too.
Post by Andrew Morton
pps-userland-header-file-for-pps-api.patch
This one is utterly wrong. It provides what should be a userspace
library as inlines in a kernel header.
Please do a proper libpps library package.
Well that's a drop-it-all-and-start again scale of thing.

Rodolfo, do you have sufficient information here?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rodolfo Giometti
2009-01-08 19:20:11 UTC
Permalink
Post by Andrew Morton
(cc's added)
On Tue, 6 Jan 2009 17:57:44 -0500
Post by Christoph Hellwig
Post by Andrew Morton
linuxpps-core-support.patch
looks generally good, but the comments should get a little loving.
Please remove the stupid filenames that always get out of sync in
the top of file comments, and make the documentation of exported
symbols kernel-doc instead of it's weird own format.
With "kernel-doc" do you mean what explained into
Documentation/kernel-doc-nano-HOWTO.txt file?
Post by Andrew Morton
Post by Christoph Hellwig
Does checkpatch.pl still not catch these things?
No... checkpatch.pl reports everything OK.
Post by Andrew Morton
Post by Christoph Hellwig
Also the ioctl certainly should be an unlocked_ioctl and not the
old BKL-locked variant. The !uarg checks in the ioctls can go,
copy_to/from_users does this automatically.
pps.h shoulkd be split into one header only defining the
kernel<->userspace ABI, and a kernel-internal one. That way
also the conditional includes can go away.
I don't understand well what I should do here... I supposed __KERNEL__
define was defined to allow mixing kernel and userland code.
Post by Andrew Morton
Post by Christoph Hellwig
Post by Andrew Morton
pps-documentation-programs-and-examples.patch
Once again this stuff is in and utterly wrong place where it can't
easily be package for distros. ppsfind belongs into util-linux and
needs a proper mangage, ppsldisc is not nessecary but ldattach in
util-linux needs to grow support for N_PPS instead, and ppstest
should probably go into util-linux in a more polished version, too.
Regarding ldisc support we should ask to Alan which solution he
preferes: ldisc & N_PPS or setserial & HARDPPS.

However I suppose is better having the LinuxPPS's core inclusion and
then solve the serial support issue.
Post by Andrew Morton
Post by Christoph Hellwig
Post by Andrew Morton
pps-userland-header-file-for-pps-api.patch
This one is utterly wrong. It provides what should be a userspace
library as inlines in a kernel header.
Please do a proper libpps library package.
Well that's a drop-it-all-and-start again scale of thing.
I think so... :'(
Post by Andrew Morton
Rodolfo, do you have sufficient information here?
I'll start changing the code ASAP and I'll ask to you if something
will be still obscure to me. :)

Thanks for your help and time,

Rodolfo
--
GNU/Linux Solutions e-mail: ***@enneenne.com
Linux Device Driver ***@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-12 20:30:12 UTC
Permalink
Post by Rodolfo Giometti
With "kernel-doc" do you mean what explained into
Documentation/kernel-doc-nano-HOWTO.txt file?
Yes.
Post by Rodolfo Giometti
Post by Christoph Hellwig
pps.h shoulkd be split into one header only defining the
kernel<->userspace ABI, and a kernel-internal one. That way
also the conditional includes can go away.
I don't understand well what I should do here... I supposed __KERNEL__
define was defined to allow mixing kernel and userland code.
Yes, __KERNEL__ works, but it's still better to just keep things
entirely separate.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rodolfo Giometti
2009-01-13 09:50:09 UTC
Permalink
Post by Christoph Hellwig
Post by Rodolfo Giometti
With "kernel-doc" do you mean what explained into
Documentation/kernel-doc-nano-HOWTO.txt file?
Yes.
Ok, I'll fix it ASAP.
Post by Christoph Hellwig
Post by Rodolfo Giometti
Post by Christoph Hellwig
pps.h shoulkd be split into one header only defining the
kernel<->userspace ABI, and a kernel-internal one. That way
also the conditional includes can go away.
I don't understand well what I should do here... I supposed __KERNEL__
define was defined to allow mixing kernel and userland code.
Yes, __KERNEL__ works, but it's still better to just keep things
entirely separate.
Ok, I'll see what I can do considering the userland interface we
decide to use. I'll ask also to Alan about this topic.

Thanks for your suggestions,

Rodolfo
--
GNU/Linux Solutions e-mail: ***@enneenne.com
Linux Device Driver ***@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Christoph Hellwig
2009-01-12 20:30:11 UTC
Permalink
Post by Andrew Morton
Well that's a drop-it-all-and-start again scale of thing.
Rodolfo, do you have sufficient information here?
I think the core is pretty solid and the few things mentioned there
can be easily fixed up even after the initial merge.

pps-documentation-programs-and-examples.patch and
pps-userland-header-file-for-pps-api.patch should just be dropped
for now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rodolfo Giometti
2009-01-13 09:50:09 UTC
Permalink
Post by Christoph Hellwig
Post by Andrew Morton
Well that's a drop-it-all-and-start again scale of thing.
Rodolfo, do you have sufficient information here?
I think the core is pretty solid and the few things mentioned there
can be easily fixed up even after the initial merge.
Great, thanks a lot! :)
Post by Christoph Hellwig
pps-documentation-programs-and-examples.patch and
pps-userland-header-file-for-pps-api.patch should just be dropped
for now.
Ok.

Ciao,

Rodolfo
--
GNU/Linux Solutions e-mail: ***@enneenne.com
Linux Device Driver ***@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dan Williams
2009-01-07 00:10:05 UTC
Permalink
Post by Andrew Morton
dmatest-flush-and-invalidate-destination-buffer-before-dma.patch
Please drop this one for now. There is an open question to Ralf [1]
over whether the MIPS dma_map_single() implementation should behave
more like ARM's i.e flush and invalidate partial cachelines in the
DMA_FROM_DEVICE case. Currently it only invalidates.

Thanks,
Dan

[1] http://marc.info/?l=linux-kernel&m=123120765106336&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Continue reading on narkive:
Loading...