* 2.6.29 -mm merge plans @ 2009-01-05 8:43 Andrew Morton 2009-01-05 9:00 ` KOSAKI Motohiro ` (9 more replies) 0 siblings, 10 replies; 94+ messages in thread From: Andrew Morton @ 2009-01-05 8:43 UTC (permalink / raw) To: linux-kernel 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton @ 2009-01-05 9:00 ` KOSAKI Motohiro 2009-01-05 9:07 ` Andrew Morton 2009-01-06 5:27 ` Valdis.Kletnieks 2009-01-05 9:02 ` Sam Ravnborg ` (8 subsequent siblings) 9 siblings, 2 replies; 94+ messages in thread From: KOSAKI Motohiro @ 2009-01-05 9:00 UTC (permalink / raw) To: Andrew Morton; +Cc: kosaki.motohiro, linux-kernel > # > 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. Valdis.Kletnieks@vt.edu reported this patch has bug in "28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms" thread. Nobody answer his question yet. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:00 ` KOSAKI Motohiro @ 2009-01-05 9:07 ` Andrew Morton 2009-01-05 22:31 ` Ying Han 2009-01-05 22:34 ` Valdis.Kletnieks 2009-01-06 5:27 ` Valdis.Kletnieks 1 sibling, 2 replies; 94+ messages in thread From: Andrew Morton @ 2009-01-05 9:07 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: linux-kernel, Ying Han, Mike Waychison, Valdis.Kletnieks (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. > > Valdis.Kletnieks@vt.edu reported this patch has bug in > "28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms" > thread. > > Nobody answer his question yet. OK, thanks. I actually thought we'd fixed that? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:07 ` Andrew Morton @ 2009-01-05 22:31 ` Ying Han 2009-01-05 22:34 ` Valdis.Kletnieks 1 sibling, 0 replies; 94+ messages in thread From: Ying Han @ 2009-01-05 22:31 UTC (permalink / raw) To: Andrew Morton Cc: KOSAKI Motohiro, linux-kernel, Mike Waychison, Valdis.Kletnieks 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 <akpm@linux-foundation.org> wrote: > (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. >> >> Valdis.Kletnieks@vt.edu reported this patch has bug in >> "28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms" >> thread. >> >> Nobody answer his question yet. > > OK, thanks. I actually thought we'd fixed that? > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:07 ` Andrew Morton 2009-01-05 22:31 ` Ying Han @ 2009-01-05 22:34 ` Valdis.Kletnieks 2009-01-08 4:18 ` Ying Han 1 sibling, 1 reply; 94+ messages in thread From: Valdis.Kletnieks @ 2009-01-05 22:34 UTC (permalink / raw) To: Andrew Morton; +Cc: KOSAKI Motohiro, linux-kernel, Ying Han, Mike Waychison [-- Attachment #1: Type: text/plain, Size: 683 bytes --] 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. > > > > Valdis.Kletnieks@vt.edu reported this patch has bug in > > "28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms" > > thread. > > > > Nobody answer his question yet. > > OK, thanks. I actually thought we'd fixed that? I'll check mmotm-0105 later tonight, I was still seeing the issue in -1230. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 22:34 ` Valdis.Kletnieks @ 2009-01-08 4:18 ` Ying Han 2009-01-08 4:41 ` KOSAKI Motohiro 2009-01-11 4:18 ` Valdis.Kletnieks 0 siblings, 2 replies; 94+ messages in thread From: Ying Han @ 2009-01-08 4:18 UTC (permalink / raw) To: Valdis.Kletnieks Cc: Andrew Morton, KOSAKI Motohiro, linux-kernel, Mike Waychison 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, <Valdis.Kletnieks@vt.edu> 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. > > > > > > Valdis.Kletnieks@vt.edu reported this patch has bug in > > > "28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms" > > > thread. > > > > > > Nobody answer his question yet. > > > > OK, thanks. I actually thought we'd fixed that? > > I'll check mmotm-0105 later tonight, I was still seeing the issue in -1230. ^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-08 4:18 ` Ying Han @ 2009-01-08 4:41 ` KOSAKI Motohiro 2009-01-08 7:57 ` Ying Han 2009-01-11 4:18 ` Valdis.Kletnieks 1 sibling, 1 reply; 94+ messages in thread From: KOSAKI Motohiro @ 2009-01-08 4:41 UTC (permalink / raw) To: Ying Han Cc: kosaki.motohiro, Valdis.Kletnieks, Andrew Morton, linux-kernel, Mike Waychison > 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-08 4:41 ` KOSAKI Motohiro @ 2009-01-08 7:57 ` Ying Han 2009-01-08 8:31 ` KOSAKI Motohiro 0 siblings, 1 reply; 94+ messages in thread From: Ying Han @ 2009-01-08 7:57 UTC (permalink / raw) To: KOSAKI Motohiro Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel, Mike Waychison 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 <kosaki.motohiro@jp.fujitsu.com> 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. > > > > > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-08 7:57 ` Ying Han @ 2009-01-08 8:31 ` KOSAKI Motohiro 0 siblings, 0 replies; 94+ messages in thread From: KOSAKI Motohiro @ 2009-01-08 8:31 UTC (permalink / raw) To: Ying Han Cc: kosaki.motohiro, Valdis.Kletnieks, Andrew Morton, linux-kernel, Mike Waychison > 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-08 4:18 ` Ying Han 2009-01-08 4:41 ` KOSAKI Motohiro @ 2009-01-11 4:18 ` Valdis.Kletnieks 2009-01-12 4:18 ` Ying Han 1 sibling, 1 reply; 94+ messages in thread From: Valdis.Kletnieks @ 2009-01-11 4:18 UTC (permalink / raw) To: Ying Han; +Cc: Andrew Morton, KOSAKI Motohiro, linux-kernel, Mike Waychison [-- Attachment #1: Type: text/plain, Size: 907 bytes --] 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. ;) [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-11 4:18 ` Valdis.Kletnieks @ 2009-01-12 4:18 ` Ying Han 0 siblings, 0 replies; 94+ messages in thread From: Ying Han @ 2009-01-12 4:18 UTC (permalink / raw) To: Valdis.Kletnieks Cc: Andrew Morton, KOSAKI Motohiro, linux-kernel, Mike Waychison Thank you Valdis for your work and that is a really good news. :-) --Ying On Sat, Jan 10, 2009 at 8:18 PM, <Valdis.Kletnieks@vt.edu> 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. ;) > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:00 ` KOSAKI Motohiro 2009-01-05 9:07 ` Andrew Morton @ 2009-01-06 5:27 ` Valdis.Kletnieks 2009-01-06 5:41 ` Nick Piggin 1 sibling, 1 reply; 94+ messages in thread From: Valdis.Kletnieks @ 2009-01-06 5:27 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 619 bytes --] 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. > > Valdis.Kletnieks@vt.edu reported this patch has bug in > "28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms" > thread. > > Nobody answer his question yet. 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. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 5:27 ` Valdis.Kletnieks @ 2009-01-06 5:41 ` Nick Piggin 0 siblings, 0 replies; 94+ messages in thread From: Nick Piggin @ 2009-01-06 5:41 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: KOSAKI Motohiro, Andrew Morton, linux-kernel On Tuesday 06 January 2009 16:27:31 Valdis.Kletnieks@vt.edu 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. > > > > Valdis.Kletnieks@vt.edu reported this patch has bug in > > "28-rc9-mmotm1219 page_fault-retry-with-nopage_retry.patch hoses xmms" > > thread. > > > > Nobody answer his question yet. > > 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton 2009-01-05 9:00 ` KOSAKI Motohiro @ 2009-01-05 9:02 ` Sam Ravnborg 2009-01-05 9:12 ` Andrew Morton 2009-01-05 9:40 ` Ryusuke Konishi ` (7 subsequent siblings) 9 siblings, 1 reply; 94+ messages in thread From: Sam Ravnborg @ 2009-01-05 9:02 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:02 ` Sam Ravnborg @ 2009-01-05 9:12 ` Andrew Morton 2009-01-05 9:17 ` David Miller 2009-01-05 10:11 ` Ingo Molnar 0 siblings, 2 replies; 94+ messages in thread From: Andrew Morton @ 2009-01-05 9:12 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linux-kernel On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <sam@ravnborg.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:12 ` Andrew Morton @ 2009-01-05 9:17 ` David Miller 2009-01-05 9:21 ` Ingo Molnar 2009-01-05 10:11 ` Ingo Molnar 1 sibling, 1 reply; 94+ messages in thread From: David Miller @ 2009-01-05 9:17 UTC (permalink / raw) To: akpm; +Cc: sam, linux-kernel From: Andrew Morton <akpm@linux-foundation.org> Date: Mon, 5 Jan 2009 01:12:02 -0800 > On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <sam@ravnborg.org> 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. :-) ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:17 ` David Miller @ 2009-01-05 9:21 ` Ingo Molnar 2009-01-05 9:39 ` Sam Ravnborg 0 siblings, 1 reply; 94+ messages in thread From: Ingo Molnar @ 2009-01-05 9:21 UTC (permalink / raw) To: David Miller; +Cc: akpm, sam, linux-kernel * David Miller <davem@davemloft.net> wrote: > From: Andrew Morton <akpm@linux-foundation.org> > Date: Mon, 5 Jan 2009 01:12:02 -0800 > > > On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <sam@ravnborg.org> 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:21 ` Ingo Molnar @ 2009-01-05 9:39 ` Sam Ravnborg 2009-01-05 10:10 ` Ingo Molnar 0 siblings, 1 reply; 94+ messages in thread From: Sam Ravnborg @ 2009-01-05 9:39 UTC (permalink / raw) To: Ingo Molnar; +Cc: David Miller, akpm, linux-kernel On Mon, Jan 05, 2009 at 10:21:10AM +0100, Ingo Molnar wrote: > > * David Miller <davem@davemloft.net> wrote: > > > From: Andrew Morton <akpm@linux-foundation.org> > > Date: Mon, 5 Jan 2009 01:12:02 -0800 > > > > > On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <sam@ravnborg.org> 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:39 ` Sam Ravnborg @ 2009-01-05 10:10 ` Ingo Molnar 2009-01-05 10:36 ` David Miller 0 siblings, 1 reply; 94+ messages in thread From: Ingo Molnar @ 2009-01-05 10:10 UTC (permalink / raw) To: Sam Ravnborg; +Cc: David Miller, akpm, linux-kernel * Sam Ravnborg <sam@ravnborg.org> wrote: > On Mon, Jan 05, 2009 at 10:21:10AM +0100, Ingo Molnar wrote: > > > > * David Miller <davem@davemloft.net> wrote: > > > > > From: Andrew Morton <akpm@linux-foundation.org> > > > Date: Mon, 5 Jan 2009 01:12:02 -0800 > > > > > > > On Mon, 5 Jan 2009 10:02:39 +0100 Sam Ravnborg <sam@ravnborg.org> 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 10:10 ` Ingo Molnar @ 2009-01-05 10:36 ` David Miller 2009-01-05 12:32 ` Ingo Molnar 0 siblings, 1 reply; 94+ messages in thread From: David Miller @ 2009-01-05 10:36 UTC (permalink / raw) To: mingo; +Cc: sam, akpm, linux-kernel From: Ingo Molnar <mingo@elte.hu> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 10:36 ` David Miller @ 2009-01-05 12:32 ` Ingo Molnar 0 siblings, 0 replies; 94+ messages in thread From: Ingo Molnar @ 2009-01-05 12:32 UTC (permalink / raw) To: David Miller; +Cc: sam, akpm, linux-kernel * David Miller <davem@davemloft.net> wrote: > From: Ingo Molnar <mingo@elte.hu> > 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:12 ` Andrew Morton 2009-01-05 9:17 ` David Miller @ 2009-01-05 10:11 ` Ingo Molnar 2009-01-05 10:37 ` David Miller 1 sibling, 1 reply; 94+ messages in thread From: Ingo Molnar @ 2009-01-05 10:11 UTC (permalink / raw) To: Andrew Morton, David S. Miller; +Cc: Sam Ravnborg, linux-kernel * Andrew Morton <akpm@linux-foundation.org> 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 10:11 ` Ingo Molnar @ 2009-01-05 10:37 ` David Miller 0 siblings, 0 replies; 94+ messages in thread From: David Miller @ 2009-01-05 10:37 UTC (permalink / raw) To: mingo; +Cc: akpm, sam, linux-kernel From: Ingo Molnar <mingo@elte.hu> Date: Mon, 5 Jan 2009 11:11:36 +0100 > * Andrew Morton <akpm@linux-foundation.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton 2009-01-05 9:00 ` KOSAKI Motohiro 2009-01-05 9:02 ` Sam Ravnborg @ 2009-01-05 9:40 ` Ryusuke Konishi 2009-01-06 13:30 ` Pekka Enberg 2009-01-05 11:34 ` Al Viro ` (6 subsequent siblings) 9 siblings, 1 reply; 94+ messages in thread From: Ryusuke Konishi @ 2009-01-05 9:40 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel 2009/1/5 Andrew Morton <akpm@linux-foundation.org>: > 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 9:40 ` Ryusuke Konishi @ 2009-01-06 13:30 ` Pekka Enberg 2009-01-07 3:26 ` Ryusuke Konishi 0 siblings, 1 reply; 94+ messages in thread From: Pekka Enberg @ 2009-01-06 13:30 UTC (permalink / raw) To: Ryusuke Konishi; +Cc: Andrew Morton, linux-kernel Hi Ryusuke, [snip nilfs patches] On Mon, Jan 5, 2009 at 11:40 AM, Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 13:30 ` Pekka Enberg @ 2009-01-07 3:26 ` Ryusuke Konishi 2009-01-07 7:58 ` Pekka Enberg 2009-01-07 14:17 ` Chris Mason 0 siblings, 2 replies; 94+ messages in thread From: Ryusuke Konishi @ 2009-01-07 3:26 UTC (permalink / raw) To: penberg; +Cc: konishi.ryusuke, akpm, linux-kernel, Chris Mason 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 > <konishi.ryusuke@lab.ntt.co.jp> 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 3:26 ` Ryusuke Konishi @ 2009-01-07 7:58 ` Pekka Enberg 2009-01-07 14:17 ` Chris Mason 1 sibling, 0 replies; 94+ messages in thread From: Pekka Enberg @ 2009-01-07 7:58 UTC (permalink / raw) To: Ryusuke Konishi; +Cc: akpm, linux-kernel, Chris Mason 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 3:26 ` Ryusuke Konishi 2009-01-07 7:58 ` Pekka Enberg @ 2009-01-07 14:17 ` Chris Mason 1 sibling, 0 replies; 94+ messages in thread From: Chris Mason @ 2009-01-07 14:17 UTC (permalink / raw) To: Ryusuke Konishi; +Cc: penberg, akpm, linux-kernel 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 > > <konishi.ryusuke@lab.ntt.co.jp> 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton ` (2 preceding siblings ...) 2009-01-05 9:40 ` Ryusuke Konishi @ 2009-01-05 11:34 ` Al Viro 2009-01-05 11:40 ` Stephen Rothwell ` (5 subsequent siblings) 9 siblings, 0 replies; 94+ messages in thread From: Al Viro @ 2009-01-05 11:34 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton ` (3 preceding siblings ...) 2009-01-05 11:34 ` Al Viro @ 2009-01-05 11:40 ` Stephen Rothwell 2008-10-06 6:14 ` Greg Ungerer ` (2 more replies) 2009-01-05 12:28 ` Nick Piggin ` (4 subsequent siblings) 9 siblings, 3 replies; 94+ messages in thread From: Stephen Rothwell @ 2009-01-05 11:40 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Greg Ungerer [-- Attachment #1: Type: text/plain, Size: 634 bytes --] Hi Andrew, On Mon, 5 Jan 2009 00:43:00 -0800 Andrew Morton <akpm@linux-foundation.org> 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 sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 11:40 ` Stephen Rothwell @ 2008-10-06 6:14 ` Greg Ungerer 2009-01-05 12:17 ` Ingo Molnar 2009-01-05 17:38 ` KOSAKI Motohiro 2 siblings, 0 replies; 94+ messages in thread From: Greg Ungerer @ 2008-10-06 6:14 UTC (permalink / raw) To: Stephen Rothwell; +Cc: Andrew Morton, linux-kernel Hi Stephen, Stephen Rothwell wrote: > Hi Andrew, > > On Mon, 5 Jan 2009 00:43:00 -0800 Andrew Morton <akpm@linux-foundation.org> 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: gerg@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 11:40 ` Stephen Rothwell 2008-10-06 6:14 ` Greg Ungerer @ 2009-01-05 12:17 ` Ingo Molnar 2009-01-05 17:38 ` KOSAKI Motohiro 2 siblings, 0 replies; 94+ messages in thread From: Ingo Molnar @ 2009-01-05 12:17 UTC (permalink / raw) To: Stephen Rothwell; +Cc: Andrew Morton, linux-kernel, Greg Ungerer * Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi Andrew, > > On Mon, 5 Jan 2009 00:43:00 -0800 Andrew Morton <akpm@linux-foundation.org> 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 11:40 ` Stephen Rothwell 2008-10-06 6:14 ` Greg Ungerer 2009-01-05 12:17 ` Ingo Molnar @ 2009-01-05 17:38 ` KOSAKI Motohiro 2 siblings, 0 replies; 94+ messages in thread From: KOSAKI Motohiro @ 2009-01-05 17:38 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Greg Ungerer, Adrian Bunk, Stephen Rothwell >> 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 <kosaki.motohiro@jp.fujitsu.com> 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 <davem@davemloft.net> >CC: Geert Uytterhoeven <geert@linux-m68k.org> >CC: Roman Zippel <zippel@linux-m68k.org> >CC: Greg Ungerer <gerg@uclinux.org> >CC: linux-m68k@lists.linux-m68k.org >--- > 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" ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton ` (4 preceding siblings ...) 2009-01-05 11:40 ` Stephen Rothwell @ 2009-01-05 12:28 ` Nick Piggin 2009-01-12 22:06 ` Andrew Morton 2009-01-06 9:46 ` Pavel Machek ` (3 subsequent siblings) 9 siblings, 1 reply; 94+ messages in thread From: Nick Piggin @ 2009-01-05 12:28 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel 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? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 12:28 ` Nick Piggin @ 2009-01-12 22:06 ` Andrew Morton 2009-01-15 6:37 ` Nick Piggin 0 siblings, 1 reply; 94+ messages in thread From: Andrew Morton @ 2009-01-12 22:06 UTC (permalink / raw) To: Nick Piggin; +Cc: linux-kernel On Mon, 5 Jan 2009 23:28:26 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-12 22:06 ` Andrew Morton @ 2009-01-15 6:37 ` Nick Piggin 0 siblings, 0 replies; 94+ messages in thread From: Nick Piggin @ 2009-01-15 6:37 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Tuesday 13 January 2009 09:06:06 Andrew Morton wrote: > On Mon, 5 Jan 2009 23:28:26 +1100 > > Nick Piggin <nickpiggin@yahoo.com.au> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton ` (5 preceding siblings ...) 2009-01-05 12:28 ` Nick Piggin @ 2009-01-06 9:46 ` Pavel Machek 2009-01-06 22:33 ` Folkert van Heusden ` (2 subsequent siblings) 9 siblings, 0 replies; 94+ messages in thread From: Pavel Machek @ 2009-01-06 9:46 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel > > 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton ` (6 preceding siblings ...) 2009-01-06 9:46 ` Pavel Machek @ 2009-01-06 22:33 ` Folkert van Heusden 2009-01-06 22:38 ` Alan Cox 2009-01-06 22:57 ` Christoph Hellwig 2009-01-07 0:01 ` Dan Williams 9 siblings, 1 reply; 94+ messages in thread From: Folkert van Heusden @ 2009-01-06 22:33 UTC (permalink / raw) To: alan; +Cc: Andrew Morton, linux-kernel, udovdh 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, www.vanheusden.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:33 ` Folkert van Heusden @ 2009-01-06 22:38 ` Alan Cox 0 siblings, 0 replies; 94+ messages in thread From: Alan Cox @ 2009-01-06 22:38 UTC (permalink / raw) To: Folkert van Heusden; +Cc: Andrew Morton, linux-kernel, udovdh > 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton ` (7 preceding siblings ...) 2009-01-06 22:33 ` Folkert van Heusden @ 2009-01-06 22:57 ` Christoph Hellwig 2009-01-06 23:08 ` Andrew Morton ` (8 more replies) 2009-01-07 0:01 ` Dan Williams 9 siblings, 9 replies; 94+ messages in thread From: Christoph Hellwig @ 2009-01-06 22:57 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:57 ` Christoph Hellwig @ 2009-01-06 23:08 ` Andrew Morton 2009-01-07 1:05 ` Nick Piggin 2009-01-06 23:08 ` Andrew Morton ` (7 subsequent siblings) 8 siblings, 1 reply; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:08 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel, Nick Piggin, linux-arch (suitable cc's added) On Tue, 6 Jan 2009 17:57:44 -0500 Christoph Hellwig <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:08 ` Andrew Morton @ 2009-01-07 1:05 ` Nick Piggin 0 siblings, 0 replies; 94+ messages in thread From: Nick Piggin @ 2009-01-07 1:05 UTC (permalink / raw) To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel, linux-arch 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 <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:57 ` Christoph Hellwig 2009-01-06 23:08 ` Andrew Morton @ 2009-01-06 23:08 ` Andrew Morton 2009-01-06 23:22 ` Christoph Hellwig 2009-01-06 23:11 ` Andrew Morton ` (6 subsequent siblings) 8 siblings, 1 reply; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:08 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel, Dmitri Monakhov (cc added) On Tue, 6 Jan 2009 17:57:44 -0500 Christoph Hellwig <hch@infradead.org> 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? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:08 ` Andrew Morton @ 2009-01-06 23:22 ` Christoph Hellwig 2009-01-07 2:16 ` Dave Chinner 0 siblings, 1 reply; 94+ messages in thread From: Christoph Hellwig @ 2009-01-06 23:22 UTC (permalink / raw) To: Andrew Morton Cc: Christoph Hellwig, linux-kernel, Dmitri Monakhov, Dave Chinner 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ---end quoted text--- ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:22 ` Christoph Hellwig @ 2009-01-07 2:16 ` Dave Chinner 2009-01-08 15:50 ` Dmitri Monakhov 0 siblings, 1 reply; 94+ messages in thread From: Dave Chinner @ 2009-01-07 2:16 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Andrew Morton, linux-kernel, Dmitri Monakhov 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 david@fromorbit.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 2:16 ` Dave Chinner @ 2009-01-08 15:50 ` Dmitri Monakhov 0 siblings, 0 replies; 94+ messages in thread From: Dmitri Monakhov @ 2009-01-08 15:50 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Andrew Morton, linux-kernel Dave Chinner <david@fromorbit.com> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:57 ` Christoph Hellwig 2009-01-06 23:08 ` Andrew Morton 2009-01-06 23:08 ` Andrew Morton @ 2009-01-06 23:11 ` Andrew Morton 2009-01-06 23:24 ` Christoph Hellwig 2009-01-06 23:13 ` Andrew Morton ` (5 subsequent siblings) 8 siblings, 1 reply; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:11 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel, Nick Piggin (cc added) On Tue, 6 Jan 2009 17:57:44 -0500 Christoph Hellwig <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:11 ` Andrew Morton @ 2009-01-06 23:24 ` Christoph Hellwig 2009-01-07 1:14 ` Nick Piggin 2009-01-08 13:22 ` 2.6.29 -mm merge plans Pavel Machek 0 siblings, 2 replies; 94+ messages in thread From: Christoph Hellwig @ 2009-01-06 23:24 UTC (permalink / raw) To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel, Nick Piggin 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:24 ` Christoph Hellwig @ 2009-01-07 1:14 ` Nick Piggin 2009-01-07 1:38 ` Andi Kleen 2009-01-08 13:22 ` 2.6.29 -mm merge plans Pavel Machek 1 sibling, 1 reply; 94+ messages in thread From: Nick Piggin @ 2009-01-07 1:14 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Andrew Morton, linux-kernel 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 1:14 ` Nick Piggin @ 2009-01-07 1:38 ` Andi Kleen 2009-01-07 1:49 ` Nick Piggin 0 siblings, 1 reply; 94+ messages in thread From: Andi Kleen @ 2009-01-07 1:38 UTC (permalink / raw) To: Nick Piggin; +Cc: Christoph Hellwig, Andrew Morton, linux-kernel Nick Piggin <npiggin@suse.de> 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 -- ak@linux.intel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 1:38 ` Andi Kleen @ 2009-01-07 1:49 ` Nick Piggin 2009-01-07 2:57 ` Andi Kleen 0 siblings, 1 reply; 94+ messages in thread From: Nick Piggin @ 2009-01-07 1:49 UTC (permalink / raw) To: Andi Kleen; +Cc: Christoph Hellwig, Andrew Morton, linux-kernel On Wed, Jan 07, 2009 at 02:38:45AM +0100, Andi Kleen wrote: > Nick Piggin <npiggin@suse.de> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 1:49 ` Nick Piggin @ 2009-01-07 2:57 ` Andi Kleen 2009-01-07 3:28 ` Nick Piggin 2009-01-08 13:24 ` Pavel Machek 0 siblings, 2 replies; 94+ messages in thread From: Andi Kleen @ 2009-01-07 2:57 UTC (permalink / raw) To: Nick Piggin; +Cc: Andi Kleen, Christoph Hellwig, Andrew Morton, linux-kernel > 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 -- ak@linux.intel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 2:57 ` Andi Kleen @ 2009-01-07 3:28 ` Nick Piggin 2009-01-08 13:24 ` Pavel Machek 1 sibling, 0 replies; 94+ messages in thread From: Nick Piggin @ 2009-01-07 3:28 UTC (permalink / raw) To: Andi Kleen; +Cc: Christoph Hellwig, Andrew Morton, linux-kernel 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). ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 2:57 ` Andi Kleen 2009-01-07 3:28 ` Nick Piggin @ 2009-01-08 13:24 ` Pavel Machek 2009-01-10 15:07 ` Andi Kleen 1 sibling, 1 reply; 94+ messages in thread From: Pavel Machek @ 2009-01-08 13:24 UTC (permalink / raw) To: Andi Kleen; +Cc: Nick Piggin, Christoph Hellwig, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-08 13:24 ` Pavel Machek @ 2009-01-10 15:07 ` Andi Kleen 2009-01-10 21:32 ` sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans] Pavel Machek 0 siblings, 1 reply; 94+ messages in thread From: Andi Kleen @ 2009-01-10 15:07 UTC (permalink / raw) To: Pavel Machek Cc: Andi Kleen, Nick Piggin, Christoph Hellwig, Andrew Morton, linux-kernel 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 -- ak@linux.intel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans] 2009-01-10 15:07 ` Andi Kleen @ 2009-01-10 21:32 ` Pavel Machek 2009-01-10 22:12 ` Andi Kleen 0 siblings, 1 reply; 94+ messages in thread From: Pavel Machek @ 2009-01-10 21:32 UTC (permalink / raw) To: Andi Kleen; +Cc: Nick Piggin, Christoph Hellwig, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans] 2009-01-10 21:32 ` sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans] Pavel Machek @ 2009-01-10 22:12 ` Andi Kleen 2009-01-10 22:26 ` Pavel Machek 0 siblings, 1 reply; 94+ messages in thread From: Andi Kleen @ 2009-01-10 22:12 UTC (permalink / raw) To: Pavel Machek Cc: Andi Kleen, Nick Piggin, Christoph Hellwig, Andrew Morton, linux-kernel 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 -- ak@linux.intel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans] 2009-01-10 22:12 ` Andi Kleen @ 2009-01-10 22:26 ` Pavel Machek 0 siblings, 0 replies; 94+ messages in thread From: Pavel Machek @ 2009-01-10 22:26 UTC (permalink / raw) To: Andi Kleen; +Cc: Nick Piggin, Christoph Hellwig, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:24 ` Christoph Hellwig 2009-01-07 1:14 ` Nick Piggin @ 2009-01-08 13:22 ` Pavel Machek 1 sibling, 0 replies; 94+ messages in thread From: Pavel Machek @ 2009-01-08 13:22 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Andrew Morton, linux-kernel, Nick Piggin, jack 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:57 ` Christoph Hellwig ` (2 preceding siblings ...) 2009-01-06 23:11 ` Andrew Morton @ 2009-01-06 23:13 ` Andrew Morton 2009-01-06 23:24 ` Christoph Hellwig 2009-01-07 2:06 ` Nick Piggin 2009-01-06 23:15 ` Andrew Morton ` (4 subsequent siblings) 8 siblings, 2 replies; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:13 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel, Keika Kobayashi (cc added) On Tue, 6 Jan 2009 17:57:44 -0500 Christoph Hellwig <hch@infradead.org> 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? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:13 ` Andrew Morton @ 2009-01-06 23:24 ` Christoph Hellwig 2009-01-06 23:38 ` Andrew Morton 2009-01-07 2:06 ` Nick Piggin 1 sibling, 1 reply; 94+ messages in thread From: Christoph Hellwig @ 2009-01-06 23:24 UTC (permalink / raw) To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel, Keika Kobayashi 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 <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:24 ` Christoph Hellwig @ 2009-01-06 23:38 ` Andrew Morton 0 siblings, 0 replies; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:38 UTC (permalink / raw) To: Christoph Hellwig; +Cc: hch, linux-kernel, kobayashi.kk On Tue, 6 Jan 2009 18:24:39 -0500 Christoph Hellwig <hch@infradead.org> 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 <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:13 ` Andrew Morton 2009-01-06 23:24 ` Christoph Hellwig @ 2009-01-07 2:06 ` Nick Piggin 2009-01-07 2:16 ` Andrew Morton 1 sibling, 1 reply; 94+ messages in thread From: Nick Piggin @ 2009-01-07 2:06 UTC (permalink / raw) To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel, Keika Kobayashi On Wednesday 07 January 2009 10:13:44 Andrew Morton wrote: > (cc added) > > On Tue, 6 Jan 2009 17:57:44 -0500 > > Christoph Hellwig <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 2:06 ` Nick Piggin @ 2009-01-07 2:16 ` Andrew Morton 2009-01-07 3:05 ` Nick Piggin 0 siblings, 1 reply; 94+ messages in thread From: Andrew Morton @ 2009-01-07 2:16 UTC (permalink / raw) To: Nick Piggin; +Cc: Christoph Hellwig, linux-kernel, Keika Kobayashi On Wed, 7 Jan 2009 13:06:44 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 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 <hch@infradead.org> 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*? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 2:16 ` Andrew Morton @ 2009-01-07 3:05 ` Nick Piggin 2009-01-07 4:16 ` Andrew Morton 0 siblings, 1 reply; 94+ messages in thread From: Nick Piggin @ 2009-01-07 3:05 UTC (permalink / raw) To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel, Keika Kobayashi On Wednesday 07 January 2009 13:16:47 Andrew Morton wrote: > On Wed, 7 Jan 2009 13:06:44 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 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 <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 3:05 ` Nick Piggin @ 2009-01-07 4:16 ` Andrew Morton 0 siblings, 0 replies; 94+ messages in thread From: Andrew Morton @ 2009-01-07 4:16 UTC (permalink / raw) To: Nick Piggin; +Cc: Christoph Hellwig, linux-kernel, Keika Kobayashi On Wed, 7 Jan 2009 14:05:51 +1100 Nick Piggin <nickpiggin@yahoo.com.au> wrote: > On Wednesday 07 January 2009 13:16:47 Andrew Morton wrote: > > On Wed, 7 Jan 2009 13:06:44 +1100 Nick Piggin <nickpiggin@yahoo.com.au> > 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 <hch@infradead.org> 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? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:57 ` Christoph Hellwig ` (3 preceding siblings ...) 2009-01-06 23:13 ` Andrew Morton @ 2009-01-06 23:15 ` Andrew Morton 2009-01-06 23:25 ` Christoph Hellwig 2009-01-06 23:17 ` Andrew Morton ` (3 subsequent siblings) 8 siblings, 1 reply; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:15 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel, Michael Halcrow, ecryptfs-devel (cc's added) On Tue, 6 Jan 2009 17:57:44 -0500 Christoph Hellwig <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:15 ` Andrew Morton @ 2009-01-06 23:25 ` Christoph Hellwig 2009-01-07 7:54 ` Christoph Hellwig 0 siblings, 1 reply; 94+ messages in thread From: Christoph Hellwig @ 2009-01-06 23:25 UTC (permalink / raw) To: Andrew Morton Cc: Christoph Hellwig, linux-kernel, Michael Halcrow, ecryptfs-devel 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 :) ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:25 ` Christoph Hellwig @ 2009-01-07 7:54 ` Christoph Hellwig 2009-01-07 7:59 ` Andrew Morton 0 siblings, 1 reply; 94+ messages in thread From: Christoph Hellwig @ 2009-01-07 7:54 UTC (permalink / raw) To: Andrew Morton Cc: Christoph Hellwig, linux-kernel, Michael Halcrow, ecryptfs-devel 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? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 7:54 ` Christoph Hellwig @ 2009-01-07 7:59 ` Andrew Morton 2009-01-07 8:10 ` Christoph Hellwig 0 siblings, 1 reply; 94+ messages in thread From: Andrew Morton @ 2009-01-07 7:59 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel, Michael Halcrow, ecryptfs-devel On Wed, 7 Jan 2009 02:54:31 -0500 Christoph Hellwig <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 7:59 ` Andrew Morton @ 2009-01-07 8:10 ` Christoph Hellwig 0 siblings, 0 replies; 94+ messages in thread From: Christoph Hellwig @ 2009-01-07 8:10 UTC (permalink / raw) To: Andrew Morton Cc: Christoph Hellwig, linux-kernel, Michael Halcrow, ecryptfs-devel 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.. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:57 ` Christoph Hellwig ` (4 preceding siblings ...) 2009-01-06 23:15 ` Andrew Morton @ 2009-01-06 23:17 ` Andrew Morton 2009-01-06 23:19 ` Christoph Hellwig 2009-01-06 23:19 ` Andrew Morton ` (2 subsequent siblings) 8 siblings, 1 reply; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:17 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-kernel, Warren Turkal, Roman Zippel, Diego Elio 'Flameeyes' Pettenò (cc's added) On Tue, 6 Jan 2009 17:57:44 -0500 Christoph Hellwig <hch@infradead.org> 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:17 ` Andrew Morton @ 2009-01-06 23:19 ` Christoph Hellwig 2009-01-06 23:26 ` Warren Turkal 2009-01-06 23:27 ` Diego E. 'Flameeyes' Pettenò 0 siblings, 2 replies; 94+ messages in thread From: Christoph Hellwig @ 2009-01-06 23:19 UTC (permalink / raw) To: Andrew Morton Cc: Christoph Hellwig, linux-kernel, Warren Turkal, Roman Zippel, Diego Elio 'Flameeyes' Petten? 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:19 ` Christoph Hellwig @ 2009-01-06 23:26 ` Warren Turkal 2009-01-06 23:26 ` Warren Turkal 2009-01-12 3:19 ` Roman Zippel 2009-01-06 23:27 ` Diego E. 'Flameeyes' Pettenò 1 sibling, 2 replies; 94+ messages in thread From: Warren Turkal @ 2009-01-06 23:26 UTC (permalink / raw) To: Christoph Hellwig Cc: Andrew Morton, linux-kernel, Roman Zippel, Diego Elio 'Flameeyes' Petten? 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 <hch@infradead.org> 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. > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:26 ` Warren Turkal @ 2009-01-06 23:26 ` Warren Turkal 2009-01-12 3:19 ` Roman Zippel 1 sibling, 0 replies; 94+ messages in thread From: Warren Turkal @ 2009-01-06 23:26 UTC (permalink / raw) To: Christoph Hellwig Cc: Andrew Morton, linux-kernel, Roman Zippel, Diego Elio 'Flameeyes' Petten? 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 <wt@penguintechs.org> 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 <hch@infradead.org> 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. >> > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:26 ` Warren Turkal 2009-01-06 23:26 ` Warren Turkal @ 2009-01-12 3:19 ` Roman Zippel 1 sibling, 0 replies; 94+ messages in thread From: Roman Zippel @ 2009-01-12 3:19 UTC (permalink / raw) To: Warren Turkal Cc: Christoph Hellwig, Andrew Morton, linux-kernel, Diego Elio 'Flameeyes' Petten? 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:19 ` Christoph Hellwig 2009-01-06 23:26 ` Warren Turkal @ 2009-01-06 23:27 ` Diego E. 'Flameeyes' Pettenò 2009-01-06 23:31 ` Christoph Hellwig 2009-01-12 4:21 ` Roman Zippel 1 sibling, 2 replies; 94+ messages in thread From: Diego E. 'Flameeyes' Pettenò @ 2009-01-06 23:27 UTC (permalink / raw) To: Christoph Hellwig Cc: Andrew Morton, linux-kernel, Warren Turkal, Roman Zippel [-- Attachment #1.1: Type: text/plain, Size: 774 bytes --] 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/ [-- Attachment #1.2: 0001-Add-basic-export-support-to-HFS-filesystem.patch --] [-- Type: text/x-patch, Size: 5719 bytes --] From 7f6df1ee70ffdd7ac75f6990463ef3a48582ad8e Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Diego=20E.=20'Flameeyes'=20Petten=C3=B2?= <flameeyes@gmail.com> Date: Thu, 4 Dec 2008 13:32:06 +0100 Subject: [PATCH] Add basic export support to HFS+ filesystem. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit The functions' skeleton is taken from ext2/super.c and seems to work fine for R/W access to HFS+ non-journaled case-sensitive filesystems. Signed-off-by: Diego E. 'Flameeyes' Pettenò <flameeyes@gmail.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Neil Brown <neilb@suse.de> --- fs/hfsplus/Makefile | 3 +- fs/hfsplus/export.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++ fs/hfsplus/hfsplus_fs.h | 3 + fs/hfsplus/super.c | 1 + 4 files changed, 124 insertions(+), 1 deletions(-) create mode 100644 fs/hfsplus/export.c diff --git a/fs/hfsplus/Makefile b/fs/hfsplus/Makefile index 3cc0df7..374131e 100644 --- a/fs/hfsplus/Makefile +++ b/fs/hfsplus/Makefile @@ -5,5 +5,6 @@ obj-$(CONFIG_HFSPLUS_FS) += hfsplus.o hfsplus-objs := super.o options.o inode.o ioctl.o extents.o catalog.o dir.o btree.o \ - bnode.o brec.o bfind.o tables.o unicode.o wrapper.o bitmap.o part_tbl.o + bnode.o brec.o bfind.o tables.o unicode.o wrapper.o bitmap.o part_tbl.o \ + export.o diff --git a/fs/hfsplus/export.c b/fs/hfsplus/export.c new file mode 100644 index 0000000..91e5cb9 --- /dev/null +++ b/fs/hfsplus/export.c @@ -0,0 +1,118 @@ +/* + * linux/fs/hfsplus/export.c + * + * Copyright (C) 2001 + * Brad Boyer (flar@allandria.com) + * (C) 2003 Ardis Technologies <roman@ardistech.com> + * (C) 2008 Diego E. Pettenò <flameeyes@gmail.com> + * + * Export for NFS + */ + +#include <linux/errno.h> +#include <linux/fs.h> +#include <linux/exportfs.h> + +#include "hfsplus_fs.h" +#include "hfsplus_raw.h" + +/* + * This is very different from most get_parent functions, since HFS+ + * does not have a ".." entry on their directories. + * + * Instead, the filesystem uses Catalog Thread Records to connect + * directories and files to their ancestors. + */ +static struct dentry *hfsplus_get_parent(struct dentry *child) +{ + struct super_block *sb; + hfsplus_cat_entry entry; + struct hfs_find_data fd; + struct inode *inode; + int err; + + sb = child->d_sb; + + hfs_find_init(HFSPLUS_SB(sb).cat_tree, &fd); + hfsplus_cat_build_key(sb, fd.search_key, child->d_inode->i_ino, NULL); + err = hfs_brec_find(&fd); + + if (err) { + printk(KERN_ERR "hfs: unable to find child, call the police\n"); + goto out; + } + + hfs_bnode_read(fd.bnode, &entry, fd.entryoffset, fd.entrylength); + if ( be16_to_cpu(entry.type) != HFSPLUS_FOLDER_THREAD) { + printk(KERN_ERR "hfs: bad catalog folder thread\n"); + err = -EIO; + goto out; + } + + if (fd.entrylength < HFSPLUS_MIN_THREAD_SZ) { + printk(KERN_ERR "hfs: truncated catalog thread\n"); + err = -EIO; + goto out; + } + + hfs_find_exit(&fd); + + 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); + } + + return d_obtain_alias(inode); + +out: + hfs_find_exit(&fd); + return ERR_PTR(err); +} + +static struct inode *hfsplus_export_get_inode(struct super_block *sb, + u64 ino, u32 generation) +{ + struct inode *inode; + + if (ino < HFSPLUS_FIRSTUSER_CNID && ino != HFSPLUS_ROOT_CNID) + return ERR_PTR(-ESTALE); + + 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; +} + +static struct dentry *hfsplus_fh_to_dentry(struct super_block *sb, struct fid *fid, + int fh_len, int fh_type) + +{ + return generic_fh_to_dentry(sb, fid, fh_len, fh_type, + hfsplus_export_get_inode); +} + +static struct dentry *hfsplus_fh_to_parent(struct super_block *sb, struct fid *fid, + int fh_len, int fh_type) + +{ + return generic_fh_to_parent(sb, fid, fh_len, fh_type, + hfsplus_export_get_inode); +} + +/* 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. + */ +const struct export_operations hfsplus_export_ops = { + .get_parent = hfsplus_get_parent, + .fh_to_dentry = hfsplus_fh_to_dentry, + .fh_to_parent = hfsplus_fh_to_parent, +}; diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h index f027a90..7c78525 100644 --- a/fs/hfsplus/hfsplus_fs.h +++ b/fs/hfsplus/hfsplus_fs.h @@ -371,6 +371,9 @@ int hfsplus_read_wrapper(struct super_block *); int hfs_part_find(struct super_block *, sector_t *, sector_t *); +/* export.c */ +extern const struct export_operations hfsplus_export_ops; + /* access macros */ /* static inline struct hfsplus_sb_info *HFSPLUS_SB(struct super_block *sb) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index eb74531..b5d1153 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -345,6 +345,7 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) /* Set up operations so we can load metadata */ sb->s_op = &hfsplus_sops; + sb->s_export_op = &hfsplus_export_ops; sb->s_maxbytes = MAX_LFS_FILESIZE; if (!(vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_UNMNT))) { -- 1.6.0.6 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:27 ` Diego E. 'Flameeyes' Pettenò @ 2009-01-06 23:31 ` Christoph Hellwig 2009-01-06 23:49 ` Harvey Harrison 2009-01-07 0:09 ` Diego E. 'Flameeyes' Pettenò 2009-01-12 4:21 ` Roman Zippel 1 sibling, 2 replies; 94+ messages in thread From: Christoph Hellwig @ 2009-01-06 23:31 UTC (permalink / raw) To: Diego E. 'Flameeyes' Petten? Cc: Christoph Hellwig, Andrew Morton, linux-kernel, Warren Turkal, Roman Zippel 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:31 ` Christoph Hellwig @ 2009-01-06 23:49 ` Harvey Harrison 2009-01-07 0:09 ` Diego E. 'Flameeyes' Pettenò 1 sibling, 0 replies; 94+ messages in thread From: Harvey Harrison @ 2009-01-06 23:49 UTC (permalink / raw) To: Christoph Hellwig Cc: Diego E. 'Flameeyes' Petten?, Andrew Morton, linux-kernel, Warren Turkal, Roman Zippel 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:31 ` Christoph Hellwig 2009-01-06 23:49 ` Harvey Harrison @ 2009-01-07 0:09 ` Diego E. 'Flameeyes' Pettenò 2009-01-07 0:16 ` Harvey Harrison 1 sibling, 1 reply; 94+ messages in thread From: Diego E. 'Flameeyes' Pettenò @ 2009-01-07 0:09 UTC (permalink / raw) To: Christoph Hellwig Cc: Andrew Morton, linux-kernel, Warren Turkal, Roman Zippel [-- Attachment #1.1: Type: text/plain, Size: 1484 bytes --] 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/ [-- Attachment #1.2: 0001-Add-basic-export-support-to-HFS-filesystem.patch --] [-- Type: text/x-patch, Size: 5312 bytes --] From 854146b9bc0143e9e3bffc765388b9dacb490527 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Diego=20E.=20'Flameeyes'=20Petten=C3=B2?= <flameeyes@gmail.com> Date: Thu, 4 Dec 2008 13:32:06 +0100 Subject: [PATCH] Add basic export support to HFS+ filesystem. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit The functions' skeleton is taken from ext2/super.c and seems to work fine for R/W access to HFS+ non-journaled case-sensitive filesystems. Signed-off-by: Diego E. 'Flameeyes' Pettenò <flameeyes@gmail.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Neil Brown <neilb@suse.de> --- fs/hfsplus/Makefile | 3 +- fs/hfsplus/export.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++ fs/hfsplus/hfsplus_fs.h | 3 + fs/hfsplus/super.c | 1 + 4 files changed, 110 insertions(+), 1 deletions(-) create mode 100644 fs/hfsplus/export.c diff --git a/fs/hfsplus/Makefile b/fs/hfsplus/Makefile index 3cc0df7..374131e 100644 --- a/fs/hfsplus/Makefile +++ b/fs/hfsplus/Makefile @@ -5,5 +5,6 @@ obj-$(CONFIG_HFSPLUS_FS) += hfsplus.o hfsplus-objs := super.o options.o inode.o ioctl.o extents.o catalog.o dir.o btree.o \ - bnode.o brec.o bfind.o tables.o unicode.o wrapper.o bitmap.o part_tbl.o + bnode.o brec.o bfind.o tables.o unicode.o wrapper.o bitmap.o part_tbl.o \ + export.o diff --git a/fs/hfsplus/export.c b/fs/hfsplus/export.c new file mode 100644 index 0000000..3486e54 --- /dev/null +++ b/fs/hfsplus/export.c @@ -0,0 +1,104 @@ +/* + * Copyright (C) 2001 + * Brad Boyer (flar@allandria.com) + * (C) 2003 Ardis Technologies <roman@ardistech.com> + * (C) 2008 Diego E. Pettenò <flameeyes@gmail.com> + * + * Export for NFS + */ + +#include <linux/errno.h> +#include <linux/fs.h> +#include <linux/exportfs.h> + +#include "hfsplus_fs.h" +#include "hfsplus_raw.h" + +/* + * This is very different from most get_parent functions, since HFS+ + * does not have a ".." entry on their directories. + * + * Instead, the filesystem uses Catalog Thread Records to connect + * directories and files to their ancestors. + */ +static struct dentry *hfsplus_get_parent(struct dentry *child) +{ + struct super_block *sb; + hfsplus_cat_entry entry; + struct hfs_find_data fd; + struct inode *inode; + int err; + + sb = child->d_sb; + + hfs_find_init(HFSPLUS_SB(sb).cat_tree, &fd); + hfsplus_cat_build_key(sb, fd.search_key, child->d_inode->i_ino, NULL); + err = hfs_brec_find(&fd); + + if (err) { + printk(KERN_ERR "hfs: unable to find child, call police\n"); + goto out; + } + + hfs_bnode_read(fd.bnode, &entry, fd.entryoffset, fd.entrylength); + if (entry.type != cpu_to_be16(HFSPLUS_FOLDER_THREAD)) { + printk(KERN_ERR "hfs: bad catalog folder thread\n"); + err = -EIO; + goto out; + } + + if (fd.entrylength < HFSPLUS_MIN_THREAD_SZ) { + printk(KERN_ERR "hfs: truncated catalog thread\n"); + err = -EIO; + goto out; + } + + hfs_find_exit(&fd); + + 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 social services\n"); + return ERR_CAST(inode); + } + + return d_obtain_alias(inode); + +out: + hfs_find_exit(&fd); + return ERR_PTR(err); +} + +static struct inode *hfsplus_export_get_inode(struct super_block *sb, + u64 ino, u32 generation) +{ + struct inode *inode; + + if (ino < HFSPLUS_FIRSTUSER_CNID && ino != HFSPLUS_ROOT_CNID) + return ERR_PTR(-ESTALE); + + /* hfsplus doesn't set i_generation so no need to check for it. */ + return hfsplus_iget(sb, ino); +} + +static struct dentry *hfsplus_fh_to_dentry(struct super_block *sb, struct fid *fid, + int fh_len, int fh_type) + +{ + return generic_fh_to_dentry(sb, fid, fh_len, fh_type, + hfsplus_export_get_inode); +} + +static struct dentry *hfsplus_fh_to_parent(struct super_block *sb, struct fid *fid, + int fh_len, int fh_type) + +{ + return generic_fh_to_parent(sb, fid, fh_len, fh_type, + hfsplus_export_get_inode); +} + +const struct export_operations hfsplus_export_ops = { + .get_parent = hfsplus_get_parent, + .fh_to_dentry = hfsplus_fh_to_dentry, + .fh_to_parent = hfsplus_fh_to_parent, +}; diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h index f027a90..7c78525 100644 --- a/fs/hfsplus/hfsplus_fs.h +++ b/fs/hfsplus/hfsplus_fs.h @@ -371,6 +371,9 @@ int hfsplus_read_wrapper(struct super_block *); int hfs_part_find(struct super_block *, sector_t *, sector_t *); +/* export.c */ +extern const struct export_operations hfsplus_export_ops; + /* access macros */ /* static inline struct hfsplus_sb_info *HFSPLUS_SB(struct super_block *sb) diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index eb74531..b5d1153 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -345,6 +345,7 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) /* Set up operations so we can load metadata */ sb->s_op = &hfsplus_sops; + sb->s_export_op = &hfsplus_export_ops; sb->s_maxbytes = MAX_LFS_FILESIZE; if (!(vhdr->attributes & cpu_to_be32(HFSPLUS_VOL_UNMNT))) { -- 1.6.0.6 [-- Attachment #1.3: 0002-Swap-the-constant-when-comparing-values-read-from-di.patch --] [-- Type: text/x-patch, Size: 1623 bytes --] From 3b47da5b18b4463d7d146534182c40b95b6ca6d4 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Diego=20E.=20'Flameeyes'=20Petten=C3=B2?= <flameeyes@gmail.com> Date: Wed, 7 Jan 2009 01:02:37 +0100 Subject: [PATCH] Swap the constant when comparing values read from disk. This way the swap can be done at build-time without doing it on the running system. Upon comment by Harvey Harrison. --- fs/hfsplus/dir.c | 2 +- fs/hfsplus/super.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/hfsplus/dir.c b/fs/hfsplus/dir.c index 5f40236..16f825b 100644 --- a/fs/hfsplus/dir.c +++ b/fs/hfsplus/dir.c @@ -139,7 +139,7 @@ static int hfsplus_readdir(struct file *filp, void *dirent, filldir_t filldir) /* fall through */ case 1: hfs_bnode_read(fd.bnode, &entry, fd.entryoffset, fd.entrylength); - if (be16_to_cpu(entry.type) != HFSPLUS_FOLDER_THREAD) { + if (entry.type != cpu_to_be16(HFSPLUS_FOLDER_THREAD)) { printk(KERN_ERR "hfs: bad catalog folder thread\n"); err = -EIO; goto out; diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index b5d1153..7ef993b 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -182,7 +182,7 @@ static void hfsplus_write_super(struct super_block *sb) bh = sb_bread(sb, block); if (bh) { vhdr = (struct hfsplus_vh *)(bh->b_data + offset); - if (be16_to_cpu(vhdr->signature) == HFSPLUS_VOLHEAD_SIG) { + if (vhdr->signature == cpu_to_be16(HFSPLUS_VOLHEAD_SIG)) { memcpy(vhdr, HFSPLUS_SB(sb).s_vhdr, sizeof(*vhdr)); mark_buffer_dirty(bh); brelse(bh); -- 1.6.0.6 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 0:09 ` Diego E. 'Flameeyes' Pettenò @ 2009-01-07 0:16 ` Harvey Harrison 0 siblings, 0 replies; 94+ messages in thread From: Harvey Harrison @ 2009-01-07 0:16 UTC (permalink / raw) To: Diego E. 'Flameeyes' Pettenò Cc: Christoph Hellwig, Andrew Morton, linux-kernel, Warren Turkal, Roman Zippel 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:27 ` Diego E. 'Flameeyes' Pettenò 2009-01-06 23:31 ` Christoph Hellwig @ 2009-01-12 4:21 ` Roman Zippel 1 sibling, 0 replies; 94+ messages in thread From: Roman Zippel @ 2009-01-12 4:21 UTC (permalink / raw) To: Diego E. 'Flameeyes' Pettenò Cc: Christoph Hellwig, Andrew Morton, linux-kernel, Warren Turkal [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: TEXT/PLAIN; CHARSET=UTF-8, Size: 1347 bytes --] 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:57 ` Christoph Hellwig ` (5 preceding siblings ...) 2009-01-06 23:17 ` Andrew Morton @ 2009-01-06 23:19 ` Andrew Morton 2009-01-08 19:11 ` Rodolfo Giometti 2009-01-12 20:22 ` Christoph Hellwig 2009-01-06 23:21 ` Andrew Morton 2009-01-06 23:28 ` Andrew Morton 8 siblings, 2 replies; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:19 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel, Rodolfo Giometti, Alan Cox (cc's added) On Tue, 6 Jan 2009 17:57:44 -0500 Christoph Hellwig <hch@infradead.org> 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? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:19 ` Andrew Morton @ 2009-01-08 19:11 ` Rodolfo Giometti 2009-01-12 20:23 ` Christoph Hellwig 2009-01-12 20:22 ` Christoph Hellwig 1 sibling, 1 reply; 94+ messages in thread From: Rodolfo Giometti @ 2009-01-08 19:11 UTC (permalink / raw) To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel, Alan Cox 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 <hch@infradead.org> 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: giometti@enneenne.com Linux Device Driver giometti@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-08 19:11 ` Rodolfo Giometti @ 2009-01-12 20:23 ` Christoph Hellwig 2009-01-13 9:49 ` Rodolfo Giometti 0 siblings, 1 reply; 94+ messages in thread From: Christoph Hellwig @ 2009-01-12 20:23 UTC (permalink / raw) To: Rodolfo Giometti; +Cc: Andrew Morton, Christoph Hellwig, linux-kernel, Alan Cox 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-12 20:23 ` Christoph Hellwig @ 2009-01-13 9:49 ` Rodolfo Giometti 0 siblings, 0 replies; 94+ messages in thread From: Rodolfo Giometti @ 2009-01-13 9:49 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Andrew Morton, linux-kernel, Alan Cox 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: giometti@enneenne.com Linux Device Driver giometti@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:19 ` Andrew Morton 2009-01-08 19:11 ` Rodolfo Giometti @ 2009-01-12 20:22 ` Christoph Hellwig 2009-01-13 9:47 ` Rodolfo Giometti 1 sibling, 1 reply; 94+ messages in thread From: Christoph Hellwig @ 2009-01-12 20:22 UTC (permalink / raw) To: Andrew Morton; +Cc: Christoph Hellwig, linux-kernel, Rodolfo Giometti, Alan Cox 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-12 20:22 ` Christoph Hellwig @ 2009-01-13 9:47 ` Rodolfo Giometti 0 siblings, 0 replies; 94+ messages in thread From: Rodolfo Giometti @ 2009-01-13 9:47 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Andrew Morton, linux-kernel, Alan Cox 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: giometti@enneenne.com Linux Device Driver giometti@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:57 ` Christoph Hellwig ` (6 preceding siblings ...) 2009-01-06 23:19 ` Andrew Morton @ 2009-01-06 23:21 ` Andrew Morton 2009-01-06 23:28 ` Andrew Morton 8 siblings, 0 replies; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:21 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel, Wu Fengguang (cc added) On Tue, 6 Jan 2009 17:57:44 -0500 Christoph Hellwig <hch@infradead.org> 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()! ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 22:57 ` Christoph Hellwig ` (7 preceding siblings ...) 2009-01-06 23:21 ` Andrew Morton @ 2009-01-06 23:28 ` Andrew Morton 2009-01-07 2:21 ` Nick Piggin 8 siblings, 1 reply; 94+ messages in thread From: Andrew Morton @ 2009-01-06 23:28 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-kernel, Ryusuke Konishi (cc added) On Tue, 6 Jan 2009 17:57:44 -0500 Christoph Hellwig <hch@infradead.org> 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) ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-06 23:28 ` Andrew Morton @ 2009-01-07 2:21 ` Nick Piggin 2009-01-08 8:39 ` Miklos Szeredi 0 siblings, 1 reply; 94+ messages in thread From: Nick Piggin @ 2009-01-07 2:21 UTC (permalink / raw) To: Andrew Morton, linux-fsdevel Cc: Christoph Hellwig, linux-kernel, Ryusuke Konishi On Wednesday 07 January 2009 10:28:29 Andrew Morton wrote: > Christoph Hellwig <hch@infradead.org> 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). ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-07 2:21 ` Nick Piggin @ 2009-01-08 8:39 ` Miklos Szeredi 2009-01-15 6:45 ` Nick Piggin 0 siblings, 1 reply; 94+ messages in thread From: Miklos Szeredi @ 2009-01-08 8:39 UTC (permalink / raw) To: nickpiggin; +Cc: akpm, linux-fsdevel, hch, linux-kernel, konishi.ryusuke 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-08 8:39 ` Miklos Szeredi @ 2009-01-15 6:45 ` Nick Piggin 0 siblings, 0 replies; 94+ messages in thread From: Nick Piggin @ 2009-01-15 6:45 UTC (permalink / raw) To: Miklos Szeredi; +Cc: akpm, linux-fsdevel, hch, linux-kernel, konishi.ryusuke 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. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.29 -mm merge plans 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton ` (8 preceding siblings ...) 2009-01-06 22:57 ` Christoph Hellwig @ 2009-01-07 0:01 ` Dan Williams 9 siblings, 0 replies; 94+ messages in thread From: Dan Williams @ 2009-01-07 0:01 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Ralf Baechle, Atsushi Nemoto On Mon, Jan 5, 2009 at 1:43 AM, Andrew Morton <akpm@linux-foundation.org> 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
end of thread, other threads:[~2009-01-15 6:45 UTC | newest] Thread overview: 94+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-01-05 8:43 2.6.29 -mm merge plans Andrew Morton 2009-01-05 9:00 ` KOSAKI Motohiro 2009-01-05 9:07 ` Andrew Morton 2009-01-05 22:31 ` Ying Han 2009-01-05 22:34 ` Valdis.Kletnieks 2009-01-08 4:18 ` Ying Han 2009-01-08 4:41 ` KOSAKI Motohiro 2009-01-08 7:57 ` Ying Han 2009-01-08 8:31 ` KOSAKI Motohiro 2009-01-11 4:18 ` Valdis.Kletnieks 2009-01-12 4:18 ` Ying Han 2009-01-06 5:27 ` Valdis.Kletnieks 2009-01-06 5:41 ` Nick Piggin 2009-01-05 9:02 ` Sam Ravnborg 2009-01-05 9:12 ` Andrew Morton 2009-01-05 9:17 ` David Miller 2009-01-05 9:21 ` Ingo Molnar 2009-01-05 9:39 ` Sam Ravnborg 2009-01-05 10:10 ` Ingo Molnar 2009-01-05 10:36 ` David Miller 2009-01-05 12:32 ` Ingo Molnar 2009-01-05 10:11 ` Ingo Molnar 2009-01-05 10:37 ` David Miller 2009-01-05 9:40 ` Ryusuke Konishi 2009-01-06 13:30 ` Pekka Enberg 2009-01-07 3:26 ` Ryusuke Konishi 2009-01-07 7:58 ` Pekka Enberg 2009-01-07 14:17 ` Chris Mason 2009-01-05 11:34 ` Al Viro 2009-01-05 11:40 ` Stephen Rothwell 2008-10-06 6:14 ` Greg Ungerer 2009-01-05 12:17 ` Ingo Molnar 2009-01-05 17:38 ` KOSAKI Motohiro 2009-01-05 12:28 ` Nick Piggin 2009-01-12 22:06 ` Andrew Morton 2009-01-15 6:37 ` Nick Piggin 2009-01-06 9:46 ` Pavel Machek 2009-01-06 22:33 ` Folkert van Heusden 2009-01-06 22:38 ` Alan Cox 2009-01-06 22:57 ` Christoph Hellwig 2009-01-06 23:08 ` Andrew Morton 2009-01-07 1:05 ` Nick Piggin 2009-01-06 23:08 ` Andrew Morton 2009-01-06 23:22 ` Christoph Hellwig 2009-01-07 2:16 ` Dave Chinner 2009-01-08 15:50 ` Dmitri Monakhov 2009-01-06 23:11 ` Andrew Morton 2009-01-06 23:24 ` Christoph Hellwig 2009-01-07 1:14 ` Nick Piggin 2009-01-07 1:38 ` Andi Kleen 2009-01-07 1:49 ` Nick Piggin 2009-01-07 2:57 ` Andi Kleen 2009-01-07 3:28 ` Nick Piggin 2009-01-08 13:24 ` Pavel Machek 2009-01-10 15:07 ` Andi Kleen 2009-01-10 21:32 ` sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans] Pavel Machek 2009-01-10 22:12 ` Andi Kleen 2009-01-10 22:26 ` Pavel Machek 2009-01-08 13:22 ` 2.6.29 -mm merge plans Pavel Machek 2009-01-06 23:13 ` Andrew Morton 2009-01-06 23:24 ` Christoph Hellwig 2009-01-06 23:38 ` Andrew Morton 2009-01-07 2:06 ` Nick Piggin 2009-01-07 2:16 ` Andrew Morton 2009-01-07 3:05 ` Nick Piggin 2009-01-07 4:16 ` Andrew Morton 2009-01-06 23:15 ` Andrew Morton 2009-01-06 23:25 ` Christoph Hellwig 2009-01-07 7:54 ` Christoph Hellwig 2009-01-07 7:59 ` Andrew Morton 2009-01-07 8:10 ` Christoph Hellwig 2009-01-06 23:17 ` Andrew Morton 2009-01-06 23:19 ` Christoph Hellwig 2009-01-06 23:26 ` Warren Turkal 2009-01-06 23:26 ` Warren Turkal 2009-01-12 3:19 ` Roman Zippel 2009-01-06 23:27 ` Diego E. 'Flameeyes' Pettenò 2009-01-06 23:31 ` Christoph Hellwig 2009-01-06 23:49 ` Harvey Harrison 2009-01-07 0:09 ` Diego E. 'Flameeyes' Pettenò 2009-01-07 0:16 ` Harvey Harrison 2009-01-12 4:21 ` Roman Zippel 2009-01-06 23:19 ` Andrew Morton 2009-01-08 19:11 ` Rodolfo Giometti 2009-01-12 20:23 ` Christoph Hellwig 2009-01-13 9:49 ` Rodolfo Giometti 2009-01-12 20:22 ` Christoph Hellwig 2009-01-13 9:47 ` Rodolfo Giometti 2009-01-06 23:21 ` Andrew Morton 2009-01-06 23:28 ` Andrew Morton 2009-01-07 2:21 ` Nick Piggin 2009-01-08 8:39 ` Miklos Szeredi 2009-01-15 6:45 ` Nick Piggin 2009-01-07 0:01 ` Dan Williams
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).