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.
Hi Stephen,
Stephen Rothwell wrote:
> Hi Andrew,
>
> On Mon, 5 Jan 2009 00:43:00 -0800 Andrew Morton <[email protected]> wrote:
>> 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.
>
>> 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: [email protected]
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
> #
> 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.
[email protected] reported this patch has bug in
"28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms"
thread.
Nobody answer his question yet.
Hi Andrew.
> 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
(cc's added)
On Mon, 5 Jan 2009 18:00:33 +0900 (JST) KOSAKI Motohiro <[email protected]> wrote:
> > #
> > 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.
>
> [email protected] reported this patch has bug in
> "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?
On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <[email protected]> wrote:
> Hi Andrew.
>
> > 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 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.
From: Andrew Morton <[email protected]>
Date: Mon, 5 Jan 2009 01:12:02 -0800
> On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <[email protected]> wrote:
>
> > Hi Andrew.
> >
> > > 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. :-)
* David Miller <[email protected]> wrote:
> From: Andrew Morton <[email protected]>
> Date: Mon, 5 Jan 2009 01:12:02 -0800
>
> > On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <[email protected]> wrote:
> >
> > > Hi Andrew.
> > >
> > > > 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
On Mon, Jan 05, 2009 at 10:21:10AM +0100, Ingo Molnar wrote:
>
> * David Miller <[email protected]> wrote:
>
> > From: Andrew Morton <[email protected]>
> > Date: Mon, 5 Jan 2009 01:12:02 -0800
> >
> > > On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <[email protected]> wrote:
> > >
> > > > Hi Andrew.
> > > >
> > > > > 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
2009/1/5 Andrew Morton <[email protected]>:
> 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
* Sam Ravnborg <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 10:21:10AM +0100, Ingo Molnar wrote:
> >
> > * David Miller <[email protected]> wrote:
> >
> > > From: Andrew Morton <[email protected]>
> > > Date: Mon, 5 Jan 2009 01:12:02 -0800
> > >
> > > > On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <[email protected]> wrote:
> > > >
> > > > > Hi Andrew.
> > > > >
> > > > > > 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
* Andrew Morton <[email protected]> wrote:
> 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
From: Ingo Molnar <[email protected]>
Date: Mon, 5 Jan 2009 11:10:06 +0100
> 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.
From: Ingo Molnar <[email protected]>
Date: Mon, 5 Jan 2009 11:11:36 +0100
> * Andrew Morton <[email protected]> wrote:
>
> > 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.
On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> 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.
Hi Andrew,
On Mon, 5 Jan 2009 00:43:00 -0800 Andrew Morton <[email protected]> wrote:
>
> 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.
> 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 [email protected]
http://www.canb.auug.org.au/~sfr/
* Stephen Rothwell <[email protected]> wrote:
> Hi Andrew,
>
> On Mon, 5 Jan 2009 00:43:00 -0800 Andrew Morton <[email protected]> wrote:
> >
> > 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
On Monday 05 January 2009 19:43:00 Andrew Morton wrote:
> 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?
> 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.
> make-sure-nobodys-leaking-resources.patch
> releasing-resources-with-children.patch
Any reason why not to add these upstream?
> nr_blockdev_pages-in_interrupt-warning.patch
Lockdep should catch this, I guess.
> 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.
> add-a-refcount-check-in-dput.patch
Again, why not an FS_BUG_ON for things like this too?
* David Miller <[email protected]> wrote:
> From: Ingo Molnar <[email protected]>
> Date: Mon, 5 Jan 2009 11:10:06 +0100
>
> > 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
>> 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 <[email protected]>
Date: 2008/12/30 19:44
>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.
>
>net/built-in.o: In function `skb_dma_map':
>: undefined reference to `dma_mapping_error'
>net/built-in.o: In function `skb_dma_unmap':
>: undefined reference to `dma_unmap_single'
>net/built-in.o: In function `skb_dma_unmap':
>: undefined reference to `dma_unmap_page'
>net/built-in.o: In function `skb_dma_map':
>: undefined reference to `dma_map_single'
>net/built-in.o: In function `skb_dma_map':
>: undefined reference to `dma_map_page'
>net/built-in.o: In function `skb_dma_map':
>: undefined reference to `dma_unmap_page'
>net/built-in.o: In function `skb_dma_map':
>: 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.
>
>
>CC: David S. Miller <[email protected]>
>CC: Geert Uytterhoeven <[email protected]>
>CC: Roman Zippel <[email protected]>
>CC: Greg Ungerer <[email protected]>
>CC: [email protected]
>---
> 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"
We are currently looking into this by trying to reproduce the issue. I
will update the progress later in the thread.
thanks
--Ying
On Mon, Jan 5, 2009 at 1:07 AM, Andrew Morton <[email protected]> wrote:
> (cc's added)
>
> On Mon, 5 Jan 2009 18:00:33 +0900 (JST) KOSAKI Motohiro <[email protected]> wrote:
>
>> > #
>> > 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.
>>
>> [email protected] reported this patch has bug in
>> "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?
>
On Mon, 05 Jan 2009 01:07:26 PST, Andrew Morton said:
> (cc's added)
>
> On Mon, 5 Jan 2009 18:00:33 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro@jp.
fujitsu.com> wrote:
>
> > > #
> > > 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.
> >
> > [email protected] reported this patch has bug in
> > "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.
On Mon, 05 Jan 2009 18:00:33 +0900, KOSAKI Motohiro said:
> > #
> > 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.
>
> [email protected] reported this patch has bug in
> "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.
On Tuesday 06 January 2009 16:27:31 [email protected] wrote:
> On Mon, 05 Jan 2009 18:00:33 +0900, KOSAKI Motohiro said:
> > > #
> > > 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.
> >
> > [email protected] reported this patch has bug in
> > "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.
>
> 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
Hi Ryusuke,
[snip nilfs patches]
On Mon, Jan 5, 2009 at 11:40 AM, Ryusuke Konishi
<[email protected]> wrote:
>> 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
Hi,
> 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, http://www.vanheusden.com
> 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
On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> 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)
> 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.
> 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.
> 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?
> 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.
> 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.
> 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.
> 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.
> 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.
> 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?
> 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.
(suitable cc's added)
On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > 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.
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > 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?
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > 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.
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
>
> > 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?
(cc's added)
On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
>
> > 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?
> 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.
(cc's added)
On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
>
> > 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.
(cc's added)
On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
>
> > 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.
>
> > 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.
>
> > 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?
On Tue, Jan 06, 2009 at 03:17:47PM -0800, Andrew Morton wrote:
> > 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.
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.
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > 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()!
On Tue, Jan 06, 2009 at 03:08:55PM -0800, Andrew Morton wrote:
> > 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.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
---end quoted text---
On Tue, Jan 06, 2009 at 03:11:31PM -0800, Andrew Morton wrote:
> > 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.
On Tue, Jan 06, 2009 at 03:13:44PM -0800, Andrew Morton wrote:
> (cc added)
>
> On Tue, 6 Jan 2009 17:57:44 -0500
> Christoph Hellwig <[email protected]> wrote:
>
> > On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> >
> > > 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.
On Tue, Jan 06, 2009 at 03:15:34PM -0800, Andrew Morton wrote:
> > > 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 :)
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
On Tue, Jan 6, 2009 at 3:19 PM, Christoph Hellwig <[email protected]> wrote:
> On Tue, Jan 06, 2009 at 03:17:47PM -0800, Andrew Morton wrote:
>> > 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.
>
> 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.
>
Just to clarify, by "previous code", I meant I linked to it. It is not
the code I used for the patch.
wt
On Tue, Jan 6, 2009 at 3:26 PM, Warren Turkal <[email protected]> wrote:
> 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
>
> On Tue, Jan 6, 2009 at 3:19 PM, Christoph Hellwig <[email protected]> wrote:
>> On Tue, Jan 06, 2009 at 03:17:47PM -0800, Andrew Morton wrote:
>>> > 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.
>>
>> 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.
>>
>
On Tue, 2009-01-06 at 18:19 -0500, Christoph Hellwig wrote:
> 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.
Yes that one wasn't good at all, and I feel sorry for not having noticed
that before sending it in the first place.
I've sent an updated one (which I'm attaching right now too), and this
one I've been using (on both .28 and .27 before, slightly modified)
without any issue at all (fixed the random disappearence of the path on
my laptop from time to time indeed).
Thanks,
--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
(cc added)
On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
>
> > 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?
> 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)
Yes, the version you attached looks much better, and correct.
Just some minor comments:
> +++ 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.
On Tue, 6 Jan 2009 18:24:39 -0500
Christoph Hellwig <[email protected]> wrote:
> On Tue, Jan 06, 2009 at 03:13:44PM -0800, Andrew Morton wrote:
> > (cc added)
> >
> > On Tue, 6 Jan 2009 17:57:44 -0500
> > Christoph Hellwig <[email protected]> wrote:
> >
> > > On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > >
> > > > 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.
On Tue, 2009-01-06 at 18:31 -0500, Christoph Hellwig wrote:
> Yes, the version you attached looks much better, and correct.
>
> Just some minor comments:
>
> > +++ 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
On Mon, Jan 5, 2009 at 1:43 AM, Andrew Morton <[email protected]> wrote:
> 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
On Tue, 2009-01-06 at 18:31 -0500, Christoph Hellwig wrote:
> Just some minor comments:
I'm attaching a version fixing both yours comments and Harvey's.
> Please don't put filenames in top of file comments. They don't serve
> any purpose and easily get out of date.
I've done that just to make it "fit-in" with the rest of the hfsplus
code, should I send a patch to remove those from the other files?
> 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.
I copied over the code from ext2 sources, so at least one other
filesystem does comment on it ;)
But indeed it's misleading, better for it to be gone.
On Tue, 2009-01-06 at 15:49 -0800, Harvey Harrison wrote:
> One other nit, byteswap the constant so it can be done at compile-time:
>
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.
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 ;)
--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
On Wed, 2009-01-07 at 01:09 +0100, Diego E. 'Flameeyes' Pettenò wrote:
> On Tue, 2009-01-06 at 15:49 -0800, Harvey Harrison wrote:
> > One other nit, byteswap the constant so it can be done at compile-time:
> >
> 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
On Tue, Jan 06, 2009 at 03:08:04PM -0800, Andrew Morton wrote:
> (suitable cc's added)
>
> On Tue, 6 Jan 2009 17:57:44 -0500
> Christoph Hellwig <[email protected]> wrote:
>
> > On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > > 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.
On Tue, Jan 06, 2009 at 06:24:18PM -0500, Christoph Hellwig wrote:
> On Tue, Jan 06, 2009 at 03:11:31PM -0800, Andrew Morton wrote:
> > > 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.
Nick Piggin <[email protected]> writes:
>
> 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
--
[email protected]
On Wed, Jan 07, 2009 at 02:38:45AM +0100, Andi Kleen wrote:
> Nick Piggin <[email protected]> writes:
> >
> > 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.
> 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.
On Wednesday 07 January 2009 10:13:44 Andrew Morton wrote:
> (cc added)
>
> On Tue, 6 Jan 2009 17:57:44 -0500
>
> Christoph Hellwig <[email protected]> wrote:
> > On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > > 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.
On Tue, Jan 06, 2009 at 06:22:08PM -0500, Christoph Hellwig wrote:
> On Tue, Jan 06, 2009 at 03:08:55PM -0800, Andrew Morton wrote:
> > > 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
[email protected]
On Wed, 7 Jan 2009 13:06:44 +1100 Nick Piggin <[email protected]> wrote:
> On Wednesday 07 January 2009 10:13:44 Andrew Morton wrote:
> > (cc added)
> >
> > On Tue, 6 Jan 2009 17:57:44 -0500
> >
> > Christoph Hellwig <[email protected]> wrote:
> > > On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > > > 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.
> /sys/kernel/softirq/*, I suggest.
What would that *improve*?
On Wednesday 07 January 2009 10:28:29 Andrew Morton wrote:
> Christoph Hellwig <[email protected]> wrote:
> > 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)
> 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).
> 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
--
[email protected]
On Wednesday 07 January 2009 13:16:47 Andrew Morton wrote:
> On Wed, 7 Jan 2009 13:06:44 +1100 Nick Piggin <[email protected]>
wrote:
> > On Wednesday 07 January 2009 10:13:44 Andrew Morton wrote:
> > > (cc added)
> > >
> > > On Tue, 6 Jan 2009 17:57:44 -0500
> > >
> > > Christoph Hellwig <[email protected]> wrote:
> > > > On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > > > > 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?
> > /sys/kernel/softirq/*, I suggest.
>
> What would that *improve*?
It would be logically in the right place.
Hi Pekka,
On Tue, 6 Jan 2009 15:30:59 +0200, "Pekka Enberg" wrote:
> Hi Ryusuke,
>
> [snip nilfs patches]
>
> On Mon, Jan 5, 2009 at 11:40 AM, Ryusuke Konishi
> <[email protected]> wrote:
> >> 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 ?
> 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.
> 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.
> 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
On Wed, Jan 07, 2009 at 03:57:25AM +0100, Andi Kleen wrote:
> > 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).
On Wed, 7 Jan 2009 14:05:51 +1100 Nick Piggin <[email protected]> wrote:
> On Wednesday 07 January 2009 13:16:47 Andrew Morton wrote:
> > On Wed, 7 Jan 2009 13:06:44 +1100 Nick Piggin <[email protected]>
> wrote:
> > > On Wednesday 07 January 2009 10:13:44 Andrew Morton wrote:
> > > > (cc added)
> > > >
> > > > On Tue, 6 Jan 2009 17:57:44 -0500
> > > >
> > > > Christoph Hellwig <[email protected]> wrote:
> > > > > On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> > > > > > 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.
>
> > > /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?
On Tue, Jan 06, 2009 at 06:25:04PM -0500, Christoph Hellwig wrote:
> On Tue, Jan 06, 2009 at 03:15:34PM -0800, Andrew Morton wrote:
> > > > 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?
On Wed, 2009-01-07 at 12:26 +0900, Ryusuke Konishi wrote:
> 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.
On Wed, 7 Jan 2009 02:54:31 -0500 Christoph Hellwig <[email protected]> wrote:
> On Tue, Jan 06, 2009 at 06:25:04PM -0500, Christoph Hellwig wrote:
> > On Tue, Jan 06, 2009 at 03:15:34PM -0800, Andrew Morton wrote:
> > > > > 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.
On Tue, Jan 06, 2009 at 11:59:43PM -0800, Andrew Morton wrote:
> 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..
On Wed, 2009-01-07 at 12:26 +0900, Ryusuke Konishi wrote:
> Hi Pekka,
>
> On Tue, 6 Jan 2009 15:30:59 +0200, "Pekka Enberg" wrote:
> > Hi Ryusuke,
> >
> > [snip nilfs patches]
> >
> > On Mon, Jan 5, 2009 at 11:40 AM, Ryusuke Konishi
> > <[email protected]> wrote:
> > >> 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
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);
}
On Mon, Jan 5, 2009 at 2:34 PM, <[email protected]> wrote:
>
> On Mon, 05 Jan 2009 01:07:26 PST, Andrew Morton said:
> > (cc's added)
> >
> > On Mon, 5 Jan 2009 18:00:33 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro@jp.
> fujitsu.com> wrote:
> >
> > > > #
> > > > 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.
> > >
> > > [email protected] reported this patch has bug in
> > > "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.
> Hi Valdis:
> 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.
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
<[email protected]> wrote:
>> Hi Valdis:
>> 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.
>
>
>
>
>
> 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.
On Wed, 7 Jan 2009, Nick Piggin wrote:
> 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
Dave Chinner <[email protected]> writes:
> On Tue, Jan 06, 2009 at 06:22:08PM -0500, Christoph Hellwig wrote:
>> On Tue, Jan 06, 2009 at 03:08:55PM -0800, Andrew Morton wrote:
>> > > 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)
>> > >
>> > > 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
So AFAIU your proposal: for general(DIO_LOCKING) filesystems
ATTR_NO_LOCK means what i_mutex and i_alloc_sem already held.
>
> Cheers,
>
> Dave.
On Tue, Jan 06, 2009 at 03:19:15PM -0800, Andrew Morton wrote:
> (cc's added)
>
> On Tue, 6 Jan 2009 17:57:44 -0500
> Christoph Hellwig <[email protected]> wrote:
>
> > On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> >
> > > 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?
> > Does checkpatch.pl still not catch these things?
No... checkpatch.pl reports everything OK.
> > 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.
> > > 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.
> > > 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... :'(
> 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: [email protected]
Linux Device Driver [email protected]
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
Hi!
> > > 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
On Wed 2009-01-07 03:57:25, Andi Kleen wrote:
> > 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
On Thu, Jan 08, 2009 at 02:24:55PM +0100, Pavel Machek wrote:
> On Wed 2009-01-07 03:57:25, Andi Kleen wrote:
> > > 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
--
[email protected]
On Sat 2009-01-10 16:07:29, Andi Kleen wrote:
> On Thu, Jan 08, 2009 at 02:24:55PM +0100, Pavel Machek wrote:
> > On Wed 2009-01-07 03:57:25, Andi Kleen wrote:
> > > > 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.
> 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.
> 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
On Sat, Jan 10, 2009 at 10:32:23PM +0100, Pavel Machek wrote:
> On Sat 2009-01-10 16:07:29, Andi Kleen wrote:
> > On Thu, Jan 08, 2009 at 02:24:55PM +0100, Pavel Machek wrote:
> > > On Wed 2009-01-07 03:57:25, Andi Kleen wrote:
> > > > > 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.
> 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
--
[email protected]
On Sat 2009-01-10 23:12:32, Andi Kleen wrote:
> On Sat, Jan 10, 2009 at 10:32:23PM +0100, Pavel Machek wrote:
> > On Sat 2009-01-10 16:07:29, Andi Kleen wrote:
> > > On Thu, Jan 08, 2009 at 02:24:55PM +0100, Pavel Machek wrote:
> > > > On Wed 2009-01-07 03:57:25, Andi Kleen wrote:
> > > > > > 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".
> > 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.
> 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
On Wed, 07 Jan 2009 20:18:34 PST, Ying Han said:
> Hi Valdis:
> 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.
> 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. ;)
Hi,
On Tue, 6 Jan 2009, Warren Turkal wrote:
(Sorry for the delay.)
> 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
Thank you Valdis for your work and that is a really good news. :-)
--Ying
On Sat, Jan 10, 2009 at 8:18 PM, <[email protected]> wrote:
> On Wed, 07 Jan 2009 20:18:34 PST, Ying Han said:
>> Hi Valdis:
>> 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.
>
>> 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. ;)
>
Hi,
On Wed, 7 Jan 2009, Diego E. 'Flameeyes' Petten? wrote:
> 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
On Tue, Jan 06, 2009 at 03:19:15PM -0800, Andrew Morton wrote:
> 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.
On Thu, Jan 08, 2009 at 08:11:53PM +0100, Rodolfo Giometti wrote:
> With "kernel-doc" do you mean what explained into
> Documentation/kernel-doc-nano-HOWTO.txt file?
Yes.
> > > 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.
On Mon, 5 Jan 2009 23:28:26 +1100
Nick Piggin <[email protected]> wrote:
> On Monday 05 January 2009 19:43:00 Andrew Morton wrote:
> > 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
> > 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
> > 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.
> > nr_blockdev_pages-in_interrupt-warning.patch
>
> Lockdep should catch this, I guess.
Yup. I forget why I added it.
> > 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.
> > add-a-refcount-check-in-dput.patch
>
> Again, why not an FS_BUG_ON for things like this too?
Ditto.
On Mon, Jan 12, 2009 at 03:22:37PM -0500, Christoph Hellwig wrote:
> On Tue, Jan 06, 2009 at 03:19:15PM -0800, Andrew Morton wrote:
> > 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! :)
> 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: [email protected]
Linux Device Driver [email protected]
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
On Mon, Jan 12, 2009 at 03:23:36PM -0500, Christoph Hellwig wrote:
> On Thu, Jan 08, 2009 at 08:11:53PM +0100, Rodolfo Giometti wrote:
> > With "kernel-doc" do you mean what explained into
> > Documentation/kernel-doc-nano-HOWTO.txt file?
>
> Yes.
Ok, I'll fix it ASAP.
> > > > 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: [email protected]
Linux Device Driver [email protected]
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
On Tuesday 13 January 2009 09:06:06 Andrew Morton wrote:
> On Mon, 5 Jan 2009 23:28:26 +1100
>
> Nick Piggin <[email protected]> wrote:
> > On Monday 05 January 2009 19:43:00 Andrew Morton wrote:
> > > 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.
> > > 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? ;)
> > > 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!
> > > add-a-refcount-check-in-dput.patch
> >
> > Again, why not an FS_BUG_ON for things like this too?
>
> Ditto.
OK.
On Thursday 08 January 2009 19:39:02 Miklos Szeredi wrote:
> On Wed, 7 Jan 2009, Nick Piggin wrote:
> > 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.