public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* mmotm 2011-06-22-13-05 uploaded
@ 2011-06-22 20:05 akpm
  2011-06-23  0:45 ` Stephen Rothwell
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: akpm @ 2011-06-22 20:05 UTC (permalink / raw)
  To: mm-commits, linux-kernel, linux-mm, linux-fsdevel

The mm-of-the-moment snapshot 2011-06-22-13-05 has been uploaded to

   http://userweb.kernel.org/~akpm/mmotm/

and will soon be available at
   git://zen-kernel.org/kernel/mmotm.git
or
   git://git.cmpxchg.org/linux-mmotm.git

It contains the following patches against 3.0-rc4:

origin.patch
memcg-fix-node_start-end_pfn-definition-for-mm-page_cgroupc.patch
mm-move-vmtruncate_range-to-truncatec.patch
mm-move-shmem-prototypes-to-shmem_fsh.patch
tmpfs-take-control-of-its-truncate_range.patch
tmpfs-add-shmem_read_mapping_page_gfp.patch
drivers-rtc-rtc-ds1307c-add-support-for-rtc-device-pt7c4338.patch
um-add-asm-percpuh.patch
romfs-fix-romfs_get_unmapped_area-param-check.patch
include-linux-compath-declare-compat_sys_sendmmsg.patch
drivers-misc-lkdtmc-fix-race-when-crashpoint-is-hit-multiple-times-before-checking-count.patch
mm-memory-failurec-fix-spinlock-vs-mutex-order.patch
mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback.patch
taskstats-dont-allow-duplicate-entries-in-listener-mode.patch
drm-ttm-use-shmem_read_mapping_page.patch
drm-i915-use-shmem_read_mapping_page.patch
drm-i915-use-shmem_truncate_range.patch
drm-i915-more-struct_mutex-locking.patch
drm-i915-more-struct_mutex-locking-fix.patch
mm-cleanup-descriptions-of-filler-arg.patch
mm-truncate-functions-are-in-truncatec.patch
mm-tidy-vmtruncate_range-and-related-functions.patch
mm-consistent-truncate-and-invalidate-loops.patch
mm-pincer-in-truncate_inode_pages_range.patch
tmpfs-no-need-to-use-i_lock.patch
mm-nommuc-fix-remap_pfn_range.patch
linux-next.patch
linux-next-git-rejects.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
drivers-misc-pch_phubc-dont-oops-if-dmi_get_system_info-returns-null.patch
bdi_min_ratio-never-shrinks-ultimately-preventing-valid-setting-of-min_ratio.patch
cris-fix-a-build-error-in-kernel-forkc.patch
cris-fix-a-build-error-in-kernel-forkc-checkpatch-fixes.patch
cris-fix-a-build-error-in-sync_serial_open.patch
cris-fix-the-prototype-of-sync_serial_ioctl.patch
cris-add-missing-declaration-of-kgdb_init-and-breakpoint.patch
hfsplus-add-missing-call-to-bio_put.patch
drivers-scsi-pmcraid-reject-negative-request-size.patch
drivers-scsi-iprc-reorder-error-handling-code-to-include-iounmap.patch
thermal-hide-config_thermal_hwmon.patch
thermal-split-hwmon-lookup-to-a-separate-function.patch
thermal-make-thermal_hwmon-implementation-fully-internal.patch
acerhdf-add-support-for-aspire-1410-bios-v13314.patch
arch-x86-include-asm-delayh-fix-udelay-and-ndelay-for-8-bit-args.patch
x86-fix-mmap-random-address-range.patch
leds-new-pcengines-alix-system-driver-enables-leds-via-gpio-interface.patch
arch-arm-mach-ux500-mbox-db5500c-world-writable-sysfs-fifo-file.patch
arm-exec-remove-redundant-set_fsuser_ds.patch
audit-always-follow-va_copy-with-va_end.patch
btrfs-dont-dereference-extent_mapping-if-null.patch
drivers-block-drbd-drbd_nlc-use-bitmap_parse-instead-of-__bitmap_parse.patch
ppc-exec-remove-redundant-set_fsuser_ds.patch
fb-fix-potential-deadlock-between-lock_fb_info-and-console_lock.patch
cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch
genirq-fix-missing-parenthesises-in-generic-chip.patch
ia64-exec-remove-redundant-set_fsuser_ds.patch
drivers-ata-pata_marvellc-add-support-for-88se91a0-88se91a4.patch
microblaze-exec-remove-redundant-set_fsuser_ds.patch
mips-exec-remove-redundant-addr_limit-assignment.patch
unicore32-exec-remove-redundant-set_fsuser_ds.patch
i915-add-native-backlight-control.patch
btusb-patch-add_apple_macbookpro62.patch
parisc-exec-remove-redundant-set_fsuser_ds.patch
pci-dmar-update-dmar-units-devices-list-during-hotplug.patch
drivers-firmware-dmi_scanc-make-dmi_name_in_vendors-more-focused.patch
pci-enumerate-the-pci-device-only-removed-out-pci-hierarchy-of-os-when-re-scanning-pci.patch
pci-enumerate-the-pci-device-only-removed-out-pci-hierarchy-of-os-when-re-scanning-pci-fix.patch
pci-make-the-struct-pci_dev-argument-of-pci_fixup_irqs-const.patch
s390-exec-remove-redundant-set_fsuser_ds.patch
scsi-fix-a-header-to-include-linux-typesh.patch
drivers-scsi-megaraidc-fix-sparse-warnings.patch
drivers-block-brdc-make-brd_make_request-return-error-code.patch
block-genhdc-remove-useless-cast-in-diskstats_show.patch
sparc-exec-remove-redundant-addr_limit-assignment.patch
staging-iio-make-iio-depend-on-generic_hardirqs.patch
drivers-staging-speakup-devsynthc-fix-buffer-size-is-not-provably-correct-error.patch
drivers-staging-gma500-psb_intel_displayc-fix-build.patch
drivers-staging-dt3155v4l-dt3155v4lc-needs-slabh.patch
drivers-staging-solo6x10-corec-needs-slabh.patch
drivers-staging-solo6x10-p2mc-needs-slabh.patch
staging-more-missing-slabh-inclusions.patch
slab-use-numa_no_node.patch
mm.patch
mm-extend-memory-hotplug-api-to-allow-memory-hotplug-in-virtual-machines.patch
mm-extend-memory-hotplug-api-to-allow-memory-hotplug-in-virtual-machines-fix.patch
xen-balloon-memory-hotplug-support-for-xen-balloon-driver.patch
mm-swap-token-fix-dead-link.patch
mm-swap-token-makes-global-variables-to-function-local.patch
mm-swap-token-add-a-comment-for-priority-aging.patch
pagewalk-fix-walk_page_range-dont-check-find_vma-result-properly.patch
pagewalk-dont-look-up-vma-if-walk-hugetlb_entry-is-unused.patch
pagewalk-add-locking-rule-comments.patch
pagewalk-add-locking-rule-comments-fix.patch
pagewalk-fix-code-comment-for-thp.patch
mm-remove-the-leftovers-of-noswapaccount.patch
mm-page_cgroupc-simplify-code-by-using-section_align_up-and-section_align_down-macros.patch
mm-thp-minor-lock-simplification-in-__khugepaged_exit.patch
mm-hugetlb-fix-coding-style-issues.patch
tmpfs-clone-shmem_file_splice_read.patch
tmpfs-refine-shmem_file_splice_read.patch
tmpfs-pass-gfp-to-shmem_getpage_gfp.patch
tmpfs-remove_shmem_readpage.patch
tmpfs-simplify-prealloc_page.patch
tmpfs-simplify-filepage-swappage.patch
tmpfs-simplify-unuse-and-writepage.patch
radix_tree-exceptional-entries-and-indices.patch
mm-let-swap-use-exceptional-entries.patch
tmpfs-demolish-old-swap-vector-support.patch
tmpfs-miscellaneous-trivial-cleanups.patch
tmpfs-copy-truncate_inode_pages_range.patch
tmpfs-convert-shmem_truncate_range-to-radix-swap.patch
tmpfs-convert-shmem_unuse_inode-to-radix-swap.patch
tmpfs-convert-shmem_getpage_gfp-to-radix-swap.patch
tmpfs-convert-mem_cgroup-shmem-to-radix-swap.patch
tmpfs-convert-shmem_writepage-and-enable-swap.patch
tmpfs-use-kmemdup-for-short-symlinks.patch
mm-a-few-small-updates-for-radix-swap.patch
mm-a-few-small-updates-for-radix-swap-fix.patch
tmpfs-expand-help-to-explain-value-of-tmpfs_posix_acl.patch
tmpfs-expand-help-to-explain-value-of-tmpfs_posix_acl-v3.patch
frv-hook-up-gpiolib-support.patch
frv-exec-remove-redundant-set_fsuser_ds.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
h8300-exec-remove-redundant-set_fsuser_ds.patch
hpet-factor-timer-allocate-from-open.patch
alpha-exec-remove-redundant-set_fsuser_ds.patch
m32r-exec-remove-redundant-set_fsuser_ds.patch
m68k-exec-remove-redundant-set_fsuser_ds.patch
mn10300-exec-remove-redundant-set_fsuser_ds.patch
intel_idle-fix-api-misuse.patch
intel_idle-disable-auto_demotion-for-hotplugged-cpus.patch
cris-fix-some-build-warnings-in-pinmuxc.patch
cris-exec-remove-redundant-set_fsuser_ds.patch
um-clean-up-vm-flagsh.patch
um-exec-remove-redundant-set_fsuser_ds.patch
um-clean-up-delay-functions-v2.patch
drivers-use-kzalloc-kcalloc-instead-of-kmallocmemset-where-possible.patch
asm-generic-systemh-drop-useless-__kernel__.patch
lpfc-silence-debug_strict_user_copy_checks=y-warning.patch
kprobes-silence-debug_strict_user_copy_checks=y-warning.patch
x86-implement-strict-user-copy-checks-for-x86_64.patch
consolidate-config_debug_strict_user_copy_checks.patch
devres-fix-possible-use-after-free.patch
drivers-misc-pch_phubc-fix-register-miss-setting-issue.patch
fcntlf_setfl-allow-setting-of-o_sync.patch
get_maintainerspl-improve-mailmap-parsing.patch
maintainers-update-high-resolution-timers-patterns.patch
maintainers-remove-section-usb-se401-driver.patch
leds-lp5521-provide-section-tagging.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
lib-lcmc-quiet-sparse-noise.patch
checkpatch-suggest-using-min_t-or-max_t-v2.patch
checkpatch-add-__rcu-as-a-sparse-modifier.patch
checkpatch-validate-signature-styles-and-to-and-cc-lines.patch
checkpatch-add-a-prefer-__aligned-check.patch
misc-eeprom-add-driver-for-microwire-93xx46-eeproms.patch
misc-eeprom-add-eeprom-access-driver-for-digsy_mtc-board.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
init-skip-calibration-delay-if-previously-done.patch
init-skip-calibration-delay-if-previously-done-fix.patch
init-skip-calibration-delay-if-previously-done-fix-fix.patch
init-skip-calibration-delay-if-previously-done-fix-fix-fix.patch
init-calibratec-calibrate_delay-tidy-up-the-pr_info-messages.patch
drivers-rtc-rtc-mpc5121c-add-support-for-rtc-on-mpc5200.patch
drivers-rtc-rtc-s3cc-support-clock-gating.patch
drivers-rtc-add-support-for-qualcomm-pmic8xxx-rtc.patch
drivers-rtc-add-support-for-qualcomm-pmic8xxx-rtc-fix.patch
drivers-rtc-add-support-for-qualcomm-pmic8xxx-rtc-do-not-use-mfd_get_data.patch
memcg-do-not-expose-uninitialized-mem_cgroup_per_node-to-world.patch
cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node.patch
cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-fix-2.patch
cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-cpusets-initialize-spread-rotor-lazily.patch
cpusets-randomize-node-rotor-used-in-cpuset_mem_spread_node-cpusets-initialize-spread-rotor-lazily-fix.patch
ptrace-unify-show_regs-prototype.patch
ptrace-unify-show_regs-prototype-fix.patch
h8300-m68k-xtensa-__fd_isset-should-return-0-1.patch
proc-pid-fdinfo-add-cloexec-information.patch
proc-pid-fdinfo-add-cloexec-information-fix.patch
kernel-forkc-fix-a-few-coding-style-issues.patch
fs-execc-use-build_bug_on-for-vm_stack_flags-vm_stack_incomplete_setup.patch
cpumask-convert-for_each_cpumask-with-for_each_cpu.patch
cpumask-alloc_cpumask_var-use-numa_no_node.patch
cpumask-add-cpumask_var_t-documentation.patch
ipc-mqueue-refactor-failure-handling.patch
ipc-mqueue-fix-mq_open-return-value.patch
sysctl-add-proc_dointvec_bool-handler.patch
sysctl-use-proc_dointvec_bool-where-appropriate.patch
sysctl-add-proc_dointvec_unsigned-handler.patch
sysctl-add-proc_dointvec_unsigned-handler-update.patch
sysctl-use-proc_dointvec_unsigned-where-appropriate.patch
include-linux-dma-mappingh-remove-dma_xxbit_mask-macros.patch
scatterlist-new-helper-functions.patch
scatterlist-new-helper-functions-update.patch
scatterlist-new-helper-functions-update-fix.patch
memstick-add-support-for-legacy-memorysticks.patch
memstick-add-support-for-legacy-memorysticks-update-2.patch
kexec-remove-kmsg_dump_kexec.patch
ramoops-use-module-parameters-instead-of-platform-data-if-not-available.patch
ramoops-use-module-parameters-instead-of-platform-data-if-not-available-checkpatch-fixes.patch
ramoops-add-new-line-to-each-print.patch
asm-generic-add-another-generic-ext2-atomic-bitops.patch
atomic-use-linux-atomich.patch
atomic-move-atomic_add_unless-to-generic-code.patch
atomic-cleanup-asm-generic-atomich-inclusion.patch
atomic-update-comments-in-atomich.patch
asm-generic-atomich-simplify-inc-dec-test-helpers.patch
asm-generic-atomich-fix-type-used-in-atomic_clear_mask.patch
asm-generic-atomich-add-atomic_set_mask-helper.patch
asm-generic-atomich-allow-smp-peeps-to-leverage-this.patch
make-sure-nobodys-leaking-resources.patch
journal_add_journal_head-debug.patch
releasing-resources-with-children.patch
make-frame_pointer-default=y.patch
mutex-subsystem-synchro-test-module.patch
mutex-subsystem-synchro-test-module-fix.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
add-debugging-aid-for-memory-initialisation-problems.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
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mmotm 2011-06-22-13-05 uploaded
  2011-06-22 20:05 mmotm 2011-06-22-13-05 uploaded akpm
@ 2011-06-23  0:45 ` Stephen Rothwell
  2011-06-23  1:59 ` mmotm 2011-06-22 - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage Valdis.Kletnieks
  2011-06-27  2:49 ` mmotm 2011-06-22-13-05 uploaded KAMEZAWA Hiroyuki
  2 siblings, 0 replies; 8+ messages in thread
From: Stephen Rothwell @ 2011-06-23  0:45 UTC (permalink / raw)
  To: akpm; +Cc: linux-kernel, linux-mm, linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

Hi Andrew,

On Wed, 22 Jun 2011 13:05:19 -0700 akpm@linux-foundation.org wrote:
>
> The mm-of-the-moment snapshot 2011-06-22-13-05 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/
> It contains the following patches against 3.0-rc4:
> 
> memcg-fix-node_start-end_pfn-definition-for-mm-page_cgroupc.patch
> mm-move-vmtruncate_range-to-truncatec.patch
> mm-move-shmem-prototypes-to-shmem_fsh.patch
> tmpfs-take-control-of-its-truncate_range.patch
> tmpfs-add-shmem_read_mapping_page_gfp.patch
> drivers-rtc-rtc-ds1307c-add-support-for-rtc-device-pt7c4338.patch
> um-add-asm-percpuh.patch
> romfs-fix-romfs_get_unmapped_area-param-check.patch
> include-linux-compath-declare-compat_sys_sendmmsg.patch
> drivers-misc-lkdtmc-fix-race-when-crashpoint-is-hit-multiple-times-before-checking-count.patch
> mm-memory-failurec-fix-spinlock-vs-mutex-order.patch
> mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback.patch
> taskstats-dont-allow-duplicate-entries-in-listener-mode.patch
> drm-ttm-use-shmem_read_mapping_page.patch
> drm-i915-use-shmem_read_mapping_page.patch
> drm-i915-use-shmem_truncate_range.patch
> drm-i915-more-struct_mutex-locking.patch
> drm-i915-more-struct_mutex-locking-fix.patch
> mm-cleanup-descriptions-of-filler-arg.patch
> mm-truncate-functions-are-in-truncatec.patch
> mm-tidy-vmtruncate_range-and-related-functions.patch
> mm-consistent-truncate-and-invalidate-loops.patch
> mm-pincer-in-truncate_inode_pages_range.patch
> tmpfs-no-need-to-use-i_lock.patch
> mm-nommuc-fix-remap_pfn_range.patch

As an experiment, I have applied all the above patches (everything
between origin.patch and linux-next.patch exclusive) to my "fixes" tree
so that they will be in linux-next immediately after Linus' tree and
before anything else.   I am assuming that these patches are going to be
sent to Linus shortly (if you haven't already).   I will point the
akpm-start branch of linux-next to be just after the above patches (so
akpm-start..akpm-end will contain everything else in linux-next).

If this is a problem, let me know and I will drop them again.  Otherwise,
they will disappear from my tree when Linus' takes tham from you.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* mmotm 2011-06-22 - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
  2011-06-22 20:05 mmotm 2011-06-22-13-05 uploaded akpm
  2011-06-23  0:45 ` Stephen Rothwell
@ 2011-06-23  1:59 ` Valdis.Kletnieks
  2011-06-23 15:38   ` Peter Zijlstra
  2011-06-27  2:49 ` mmotm 2011-06-22-13-05 uploaded KAMEZAWA Hiroyuki
  2 siblings, 1 reply; 8+ messages in thread
From: Valdis.Kletnieks @ 2011-06-23  1:59 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Jeff Garzik, Peter Zijlstra,
	IngIngo Molnar
  Cc: linux-kernel, linux-ide

[-- Attachment #1: Type: text/plain, Size: 7934 bytes --]

On Wed, 22 Jun 2011 13:05:19 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2011-06-22-13-05 has been uploaded to

Nothing obvious to cause it, and I didn't see it in -rc3-mmotm0615, so I'll toss this at
Andrew and everybody mentioned in MAINTAINERS for SATA, IRQs, and Lockdep and
see if anybody has a brilliant idea.

Quite probably relevant - kernel was booted with 'threadirqs', but that's been in
there since 39-rc7 and I haven't seen this before.

Threw an amazing traceback on boot while trying to fsck the / filesystem on a
LUKS-encrypted LVM partition:

[    3.828296] dracut: luksOpen /dev/sda2 luks-715ceabf-6f58-4251-9373-ed29e8629a7c
[   18.127342] dracut: Scanning devices dm-0  for LVM volume groups 
[   18.164842] dracut: Reading all physical volumes. This may take a while...
[   18.164995] dracut: Found volume group "vg_blackice" using metadata type lvm2
[   18.557728] blkid used greatest stack depth: 3904 bytes left
[   20.095210] dracut: 12 logical volume(s) in volume group "vg_blackice" now active
[   20.174640] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: (null)
[   20.233169] dracut: Checking filesystems
[   20.233210] dracut: fsck -T -t noopts=_netdev -A -a
[   20.253331] 
[   20.253500] =================================
[   20.253803] [ INFO: inconsistent lock state ]
[   20.254107] 3.0.0-rc4-mmotm0622 #1
[   20.254275] ---------------------------------
[   20.254275] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[   20.254275] irq/45-ahci/47 [HC0[0]:SC1[1]:HE0:SE0] takes:
[   20.254275]  (&(&mapping->tree_lock)->rlock){+.?...}, at: [<ffffffff810c031a>] test_clear_page_writeback+0x39/0xd3
[   20.254275] {SOFTIRQ-ON-W} state was registered at:
[   20.254275]   [<ffffffff8106973b>] mark_irqflags+0xf2/0x13e
[   20.254275]   [<ffffffff810699b2>] __lock_acquire+0x22b/0x3e2
[   20.254275]   [<ffffffff8106a09f>] lock_acquire+0x103/0x153
[   20.254275]   [<ffffffff8157bb01>] _raw_spin_lock+0x36/0x45
[   20.254275]   [<ffffffff8110ddf8>] end_writeback+0x33/0x103
[   20.254275]   [<ffffffff81125425>] bdev_evict_inode+0x3e/0xbe
[   20.254275]   [<ffffffff8110df78>] evict+0xb0/0x173
[   20.254275]   [<ffffffff8110e1ea>] iput_final+0x171/0x17a
[   20.254275]   [<ffffffff8110e241>] iput+0x4e/0x53
[   20.254275]   [<ffffffff81125cad>] __blkdev_put+0x1c0/0x1eb
[   20.254275]   [<ffffffff81125ebe>] blkdev_put+0x1e6/0x1f5
[   20.254275]   [<ffffffff8121d143>] register_disk+0xea/0x13c
[   20.254275]   [<ffffffff8121d2c4>] add_disk+0x12f/0x1a4
[   20.254275]   [<ffffffff812ef339>] sd_probe_async+0x115/0x1b5
[   20.254275]   [<ffffffff8105ce2f>] async_run_entry_fn+0x99/0x12a
[   20.254275]   [<ffffffff810505e8>] process_one_work+0x25d/0x467
[   20.254275]   [<ffffffff81051ddb>] worker_thread+0x152/0x206
[   20.254275]   [<ffffffff810561fa>] kthread+0x7f/0x87
[   20.254275]   [<ffffffff815835d4>] kernel_thread_helper+0x4/0x10
[   20.254275] irq event stamp: 115999
[   20.254275] hardirqs last  enabled at (115998): [<ffffffff81562e60>] end_buffer_async_write.part.14+0x117/0x154
[   20.254275] hardirqs last disabled at (115999): [<ffffffff8157bbd0>] _raw_spin_lock_irqsave+0x1a/0x57
[   20.254275] softirqs last  enabled at (115966): [<ffffffff8108d689>] irq_forced_thread_fn+0x35/0x40
[   20.254275] softirqs last disabled at (115967): [<ffffffff815836cc>] call_softirq+0x1c/0x30
[   20.254275] 
[   20.254275] other info that might help us debug this:
[   20.254275]  Possible unsafe locking scenario:
[   20.254275] 
[   20.254275]        CPU0
[   20.254275]        ----
[   20.254275]   lock(&(&mapping->tree_lock)->rlock);
[   20.254275]   <Interrupt>
[   20.254275]     lock(&(&mapping->tree_lock)->rlock);
[   20.254275] 
[   20.254275]  *** DEADLOCK ***
[   20.254275] 
[   20.254275] no locks held by irq/45-ahci/47.
[   20.254275] 
[   20.254275] stack backtrace:
[   20.254275] Pid: 47, comm: irq/45-ahci Not tainted 3.0.0-rc4-mmotm0622 #1
[   20.254275] Call Trace:
[   20.254275]  <IRQ>  [<ffffffff8155c50e>] print_usage_bug+0x1f5/0x206
[   20.254275]  [<ffffffff81068837>] ? print_irq_inversion_bug.part.15+0x1ae/0x1ae
[   20.254275]  [<ffffffff8155c58e>] mark_lock_irq+0x6f/0x120
[   20.254275]  [<ffffffff810695d6>] mark_lock+0xaf/0x122
[   20.254275]  [<ffffffff810696cb>] mark_irqflags+0x82/0x13e
[   20.254275]  [<ffffffff810699b2>] __lock_acquire+0x22b/0x3e2
[   20.254275]  [<ffffffff810c031a>] ? test_clear_page_writeback+0x39/0xd3
[   20.254275]  [<ffffffff8106a09f>] lock_acquire+0x103/0x153
[   20.254275]  [<ffffffff810c031a>] ? test_clear_page_writeback+0x39/0xd3
[   20.254275]  [<ffffffff8157bbfa>] _raw_spin_lock_irqsave+0x44/0x57
[   20.254275]  [<ffffffff810c031a>] ? test_clear_page_writeback+0x39/0xd3
[   20.254275]  [<ffffffff81027b66>] ? __wake_up+0x1d/0x48
[   20.254275]  [<ffffffff810c031a>] test_clear_page_writeback+0x39/0xd3
[   20.254275]  [<ffffffff810b7ae1>] end_page_writeback+0x2a/0x4c
[   20.254275]  [<ffffffff81562e6b>] end_buffer_async_write.part.14+0x122/0x154
[   20.254275]  [<ffffffff8106a55d>] ? trace_hardirqs_on_caller+0xfd/0x13b
[   20.254275]  [<ffffffff811209c4>] end_buffer_async_write+0x3e/0x47
[   20.254275]  [<ffffffff8111f595>] end_bio_bh_io_sync+0x53/0x63
[   20.254275]  [<ffffffff8111f542>] ? invalidate_inode_buffers+0x5c/0x5c
[   20.254275]  [<ffffffff81122d87>] bio_endio+0x28/0x2a
[   20.254275]  [<ffffffff8139e56c>] dec_pending+0x190/0x1b2
[   20.254275]  [<ffffffff8139e631>] clone_endio+0xa3/0xb0
[   20.254275]  [<ffffffff81122d87>] bio_endio+0x28/0x2a
[   20.254275]  [<ffffffff8139e56c>] dec_pending+0x190/0x1b2
[   20.254275]  [<ffffffff8139e631>] clone_endio+0xa3/0xb0
[   20.254275]  [<ffffffff81122d87>] bio_endio+0x28/0x2a
[   20.254275]  [<ffffffff813a6163>] crypt_dec_pending+0x75/0xa1
[   20.254275]  [<ffffffff813a705f>] crypt_endio+0xba/0xc9
[   20.254275]  [<ffffffff8121263a>] ? rcu_read_lock+0x35/0x35
[   20.254275]  [<ffffffff81122d87>] bio_endio+0x28/0x2a
[   20.254275]  [<ffffffff8121281e>] req_bio_endio+0xc1/0xcd
[   20.254275]  [<ffffffff8121461a>] blk_update_request+0x15e/0x389
[   20.254275]  [<ffffffff81214865>] blk_update_bidi_request+0x20/0x90
[   20.254275]  [<ffffffff81214a39>] blk_end_bidi_request+0x1a/0x58
[   20.254275]  [<ffffffff81214af3>] blk_end_request+0xb/0xd
[   20.254275]  [<ffffffff812e644a>] scsi_io_completion+0x1cc/0x4c7
[   20.254275]  [<ffffffff812df07e>] scsi_finish_command+0xab/0xb4
[   20.254275]  [<ffffffff812e61d6>] scsi_softirq_done+0xed/0xf6
[   20.254275]  [<ffffffff81219c34>] blk_done_softirq+0x6c/0x80
[   20.254275]  [<ffffffff8103e699>] __do_softirq+0x110/0x278
[   20.254275]  [<ffffffff8108d654>] ? irq_thread_fn+0x37/0x37
[   20.254275]  [<ffffffff815836cc>] call_softirq+0x1c/0x30
[   20.254275]  <EOI>  [<ffffffff810031eb>] ? do_softirq+0x44/0xf1
[   20.254275]  [<ffffffff8103e25a>] _local_bh_enable_ip+0x12a/0x178
[   20.254275]  [<ffffffff8103e2c0>] local_bh_enable+0xd/0xf
[   20.254275]  [<ffffffff8108d689>] irq_forced_thread_fn+0x35/0x40
[   20.254275]  [<ffffffff8108d54a>] irq_thread+0xf6/0x1c9
[   20.254275]  [<ffffffff8108d454>] ? irq_finalize_oneshot+0xc9/0xc9
[   20.254275]  [<ffffffff810561fa>] kthread+0x7f/0x87
[   20.254275]  [<ffffffff815835d4>] kernel_thread_helper+0x4/0x10
[   20.254275]  [<ffffffff8157c884>] ? retint_restore_args+0xe/0xe
[   20.254275]  [<ffffffff8105617b>] ? __init_kthread_worker+0x55/0x55
[   20.254275]  [<ffffffff815835d0>] ? gs_change+0xb/0xb
[   20.820457] dracut: /dev/mapper/vg_blackice-root: clean, 18016/65536 files, 181204/262144 blocks
[   20.862866] dracut: Remounting /dev/mapper/vg_blackice-root with -o ro,quota,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0
[   20.886535] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: quota,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0
[   20.927228] dracut: Mounted root filesystem /dev/mapper/vg_blackice-root
[   21.147364] dracut: Switching root


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mmotm 2011-06-22 - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
  2011-06-23  1:59 ` mmotm 2011-06-22 - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage Valdis.Kletnieks
@ 2011-06-23 15:38   ` Peter Zijlstra
  2011-06-23 16:02     ` Valdis.Kletnieks
  0 siblings, 1 reply; 8+ messages in thread
From: Peter Zijlstra @ 2011-06-23 15:38 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Andrew Morton, Thomas Gleixner, Jeff Garzik, IngIngo Molnar,
	linux-kernel, linux-ide

On Wed, 2011-06-22 at 21:59 -0400, Valdis.Kletnieks@vt.edu wrote:
> [   20.254275] {SOFTIRQ-ON-W} state was registered at:
> [   20.254275]   [<ffffffff8106973b>] mark_irqflags+0xf2/0x13e
> [   20.254275]   [<ffffffff810699b2>] __lock_acquire+0x22b/0x3e2
> [   20.254275]   [<ffffffff8106a09f>] lock_acquire+0x103/0x153
> [   20.254275]   [<ffffffff8157bb01>] _raw_spin_lock+0x36/0x45
> [   20.254275]   [<ffffffff8110ddf8>] end_writeback+0x33/0x103
> [   20.254275]   [<ffffffff81125425>] bdev_evict_inode+0x3e/0xbe
> [   20.254275]   [<ffffffff8110df78>] evict+0xb0/0x173
> [   20.254275]   [<ffffffff8110e1ea>] iput_final+0x171/0x17a
> [   20.254275]   [<ffffffff8110e241>] iput+0x4e/0x53
> [   20.254275]   [<ffffffff81125cad>] __blkdev_put+0x1c0/0x1eb
> [   20.254275]   [<ffffffff81125ebe>] blkdev_put+0x1e6/0x1f5
> [   20.254275]   [<ffffffff8121d143>] register_disk+0xea/0x13c
> [   20.254275]   [<ffffffff8121d2c4>] add_disk+0x12f/0x1a4
> [   20.254275]   [<ffffffff812ef339>] sd_probe_async+0x115/0x1b5
> [   20.254275]   [<ffffffff8105ce2f>] async_run_entry_fn+0x99/0x12a
> [   20.254275]   [<ffffffff810505e8>] process_one_work+0x25d/0x467
> [   20.254275]   [<ffffffff81051ddb>] worker_thread+0x152/0x206
> [   20.254275]   [<ffffffff810561fa>] kthread+0x7f/0x87
> [   20.254275]   [<ffffffff815835d4>] kernel_thread_helper+0x4/0x10 

That looks broken. Not having -mm, is there a git tree some place?, I
cannot quite see how end_writeback() is taking mapping->tree_lock as my
version looks like:

void end_writeback(struct inode *inode)
{
	might_sleep();
	BUG_ON(inode->i_data.nrpages);
	BUG_ON(!list_empty(&inode->i_data.private_list));
	BUG_ON(!(inode->i_state & I_FREEING));
	BUG_ON(inode->i_state & I_CLEAR);
	inode_sync_wait(inode);
	/* don't need i_lock here, no concurrent mods to i_state */
	inode->i_state = I_FREEING | I_CLEAR;
}

and I couldn't find tree_lock used in inode_sync_wait() either.

Anyway, mapping->tree_lock is supposed to be an IRQ-safe lock, look at
all the spin_lock_irq(&mapping->tree_lock) usage in mm/filemap.c.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mmotm 2011-06-22 - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
  2011-06-23 15:38   ` Peter Zijlstra
@ 2011-06-23 16:02     ` Valdis.Kletnieks
  2011-06-23 16:08       ` Peter Zijlstra
  0 siblings, 1 reply; 8+ messages in thread
From: Valdis.Kletnieks @ 2011-06-23 16:02 UTC (permalink / raw)
  To: Peter Zijlstra, Jan Kara, stable
  Cc: Andrew Morton, Thomas Gleixner, Jeff Garzik, IngIngo Molnar,
	linux-kernel, linux-ide

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

On Thu, 23 Jun 2011 17:38:36 +0200, Peter Zijlstra said:
> On Wed, 2011-06-22 at 21:59 -0400, Valdis.Kletnieks@vt.edu wrote:
> > [   20.254275] {SOFTIRQ-ON-W} state was registered at:
> > [   20.254275]   [<ffffffff8106973b>] mark_irqflags+0xf2/0x13e
> > [   20.254275]   [<ffffffff810699b2>] __lock_acquire+0x22b/0x3e2
> > [   20.254275]   [<ffffffff8106a09f>] lock_acquire+0x103/0x153
> > [   20.254275]   [<ffffffff8157bb01>] _raw_spin_lock+0x36/0x45
> > [   20.254275]   [<ffffffff8110ddf8>] end_writeback+0x33/0x103
> > [   20.254275]   [<ffffffff81125425>] bdev_evict_inode+0x3e/0xbe
> > [   20.254275]   [<ffffffff8110df78>] evict+0xb0/0x173
> > [   20.254275]   [<ffffffff8110e1ea>] iput_final+0x171/0x17a
> > [   20.254275]   [<ffffffff8110e241>] iput+0x4e/0x53
> > [   20.254275]   [<ffffffff81125cad>] __blkdev_put+0x1c0/0x1eb
> > [   20.254275]   [<ffffffff81125ebe>] blkdev_put+0x1e6/0x1f5
> > [   20.254275]   [<ffffffff8121d143>] register_disk+0xea/0x13c
> > [   20.254275]   [<ffffffff8121d2c4>] add_disk+0x12f/0x1a4
> > [   20.254275]   [<ffffffff812ef339>] sd_probe_async+0x115/0x1b5
> > [   20.254275]   [<ffffffff8105ce2f>] async_run_entry_fn+0x99/0x12a
> > [   20.254275]   [<ffffffff810505e8>] process_one_work+0x25d/0x467
> > [   20.254275]   [<ffffffff81051ddb>] worker_thread+0x152/0x206
> > [   20.254275]   [<ffffffff810561fa>] kthread+0x7f/0x87
> > [   20.254275]   [<ffffffff815835d4>] kernel_thread_helper+0x4/0x10=20
> 
> That looks broken. Not having -mm, is there a git tree some place?, I
> cannot quite see how end_writeback() is taking mapping->tree_lock as my
> version looks like:
> 
> void end_writeback(struct inode *inode)
> {
> 	might_sleep();
> 	BUG_ON(inode->i_data.nrpages);
> 	BUG_ON(!list_empty(&inode->i_data.private_list));

mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback.patch does this:

diff -puN fs/inode.c~mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback fs/inode.c
--- a/fs/inode.c~mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback
+++ a/fs/inode.c
@@ -423,7 +423,14 @@ EXPORT_SYMBOL(remove_inode_hash);
 void end_writeback(struct inode *inode)
 {
        might_sleep();
+       /*
+        * We have to cycle tree_lock here because reclaim can be still in the
+        * process of removing the last page (in __delete_from_page_cache())
+        * and we must not free mapping under it.
+        */
+       spin_lock(&inode->i_data.tree_lock);
        BUG_ON(inode->i_data.nrpages);
+       spin_unlock(&inode->i_data.tree_lock);
        BUG_ON(!list_empty(&inode->i_data.private_list));
        BUG_ON(!(inode->i_state & I_FREEING));
        BUG_ON(inode->i_state & I_CLEAR);

Adding Jan Kara to the list, and stable@kernel.org because the patch was cc'ed to there...


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mmotm 2011-06-22 - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
  2011-06-23 16:02     ` Valdis.Kletnieks
@ 2011-06-23 16:08       ` Peter Zijlstra
  2011-06-23 19:59         ` Jan Kara
  0 siblings, 1 reply; 8+ messages in thread
From: Peter Zijlstra @ 2011-06-23 16:08 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Jan Kara, stable, Andrew Morton, Thomas Gleixner, Jeff Garzik,
	IngIngo Molnar, linux-kernel, linux-ide

On Thu, 2011-06-23 at 12:02 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 23 Jun 2011 17:38:36 +0200, Peter Zijlstra said:
> > On Wed, 2011-06-22 at 21:59 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > [   20.254275] {SOFTIRQ-ON-W} state was registered at:
> > > [   20.254275]   [<ffffffff8106973b>] mark_irqflags+0xf2/0x13e
> > > [   20.254275]   [<ffffffff810699b2>] __lock_acquire+0x22b/0x3e2
> > > [   20.254275]   [<ffffffff8106a09f>] lock_acquire+0x103/0x153
> > > [   20.254275]   [<ffffffff8157bb01>] _raw_spin_lock+0x36/0x45
> > > [   20.254275]   [<ffffffff8110ddf8>] end_writeback+0x33/0x103
> > > [   20.254275]   [<ffffffff81125425>] bdev_evict_inode+0x3e/0xbe
> > > [   20.254275]   [<ffffffff8110df78>] evict+0xb0/0x173
> > > [   20.254275]   [<ffffffff8110e1ea>] iput_final+0x171/0x17a
> > > [   20.254275]   [<ffffffff8110e241>] iput+0x4e/0x53
> > > [   20.254275]   [<ffffffff81125cad>] __blkdev_put+0x1c0/0x1eb
> > > [   20.254275]   [<ffffffff81125ebe>] blkdev_put+0x1e6/0x1f5
> > > [   20.254275]   [<ffffffff8121d143>] register_disk+0xea/0x13c
> > > [   20.254275]   [<ffffffff8121d2c4>] add_disk+0x12f/0x1a4
> > > [   20.254275]   [<ffffffff812ef339>] sd_probe_async+0x115/0x1b5
> > > [   20.254275]   [<ffffffff8105ce2f>] async_run_entry_fn+0x99/0x12a
> > > [   20.254275]   [<ffffffff810505e8>] process_one_work+0x25d/0x467
> > > [   20.254275]   [<ffffffff81051ddb>] worker_thread+0x152/0x206
> > > [   20.254275]   [<ffffffff810561fa>] kthread+0x7f/0x87
> > > [   20.254275]   [<ffffffff815835d4>] kernel_thread_helper+0x4/0x10=20
> > 
> > That looks broken. Not having -mm, is there a git tree some place?, I
> > cannot quite see how end_writeback() is taking mapping->tree_lock as my
> > version looks like:
> > 
> > void end_writeback(struct inode *inode)
> > {
> > 	might_sleep();
> > 	BUG_ON(inode->i_data.nrpages);
> > 	BUG_ON(!list_empty(&inode->i_data.private_list));
> 
> mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback.patch does this:
> 
> diff -puN fs/inode.c~mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback fs/inode.c
> --- a/fs/inode.c~mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback
> +++ a/fs/inode.c
> @@ -423,7 +423,14 @@ EXPORT_SYMBOL(remove_inode_hash);
>  void end_writeback(struct inode *inode)
>  {
>         might_sleep();
> +       /*
> +        * We have to cycle tree_lock here because reclaim can be still in the
> +        * process of removing the last page (in __delete_from_page_cache())
> +        * and we must not free mapping under it.
> +        */
> +       spin_lock(&inode->i_data.tree_lock);
>         BUG_ON(inode->i_data.nrpages);
> +       spin_unlock(&inode->i_data.tree_lock);
>         BUG_ON(!list_empty(&inode->i_data.private_list));
>         BUG_ON(!(inode->i_state & I_FREEING));
>         BUG_ON(inode->i_state & I_CLEAR);
> 
> Adding Jan Kara to the list, and stable@kernel.org because the patch was cc'ed to there...

Yep, that very much wants to be spin_{un,}lock_irq().

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mmotm 2011-06-22 - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
  2011-06-23 16:08       ` Peter Zijlstra
@ 2011-06-23 19:59         ` Jan Kara
  0 siblings, 0 replies; 8+ messages in thread
From: Jan Kara @ 2011-06-23 19:59 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Valdis.Kletnieks, Jan Kara, stable, Andrew Morton,
	Thomas Gleixner, Jeff Garzik, IngIngo Molnar, linux-kernel,
	linux-ide

On Thu 23-06-11 18:08:05, Peter Zijlstra wrote:
> On Thu, 2011-06-23 at 12:02 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Thu, 23 Jun 2011 17:38:36 +0200, Peter Zijlstra said:
> > > On Wed, 2011-06-22 at 21:59 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > > [   20.254275] {SOFTIRQ-ON-W} state was registered at:
> > > > [   20.254275]   [<ffffffff8106973b>] mark_irqflags+0xf2/0x13e
> > > > [   20.254275]   [<ffffffff810699b2>] __lock_acquire+0x22b/0x3e2
> > > > [   20.254275]   [<ffffffff8106a09f>] lock_acquire+0x103/0x153
> > > > [   20.254275]   [<ffffffff8157bb01>] _raw_spin_lock+0x36/0x45
> > > > [   20.254275]   [<ffffffff8110ddf8>] end_writeback+0x33/0x103
> > > > [   20.254275]   [<ffffffff81125425>] bdev_evict_inode+0x3e/0xbe
> > > > [   20.254275]   [<ffffffff8110df78>] evict+0xb0/0x173
> > > > [   20.254275]   [<ffffffff8110e1ea>] iput_final+0x171/0x17a
> > > > [   20.254275]   [<ffffffff8110e241>] iput+0x4e/0x53
> > > > [   20.254275]   [<ffffffff81125cad>] __blkdev_put+0x1c0/0x1eb
> > > > [   20.254275]   [<ffffffff81125ebe>] blkdev_put+0x1e6/0x1f5
> > > > [   20.254275]   [<ffffffff8121d143>] register_disk+0xea/0x13c
> > > > [   20.254275]   [<ffffffff8121d2c4>] add_disk+0x12f/0x1a4
> > > > [   20.254275]   [<ffffffff812ef339>] sd_probe_async+0x115/0x1b5
> > > > [   20.254275]   [<ffffffff8105ce2f>] async_run_entry_fn+0x99/0x12a
> > > > [   20.254275]   [<ffffffff810505e8>] process_one_work+0x25d/0x467
> > > > [   20.254275]   [<ffffffff81051ddb>] worker_thread+0x152/0x206
> > > > [   20.254275]   [<ffffffff810561fa>] kthread+0x7f/0x87
> > > > [   20.254275]   [<ffffffff815835d4>] kernel_thread_helper+0x4/0x10=20
> > > 
> > > That looks broken. Not having -mm, is there a git tree some place?, I
> > > cannot quite see how end_writeback() is taking mapping->tree_lock as my
> > > version looks like:
> > > 
> > > void end_writeback(struct inode *inode)
> > > {
> > > 	might_sleep();
> > > 	BUG_ON(inode->i_data.nrpages);
> > > 	BUG_ON(!list_empty(&inode->i_data.private_list));
> > 
> > mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback.patch does this:
> > 
> > diff -puN fs/inode.c~mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback fs/inode.c
> > --- a/fs/inode.c~mm-fix-assertion-mapping-nrpages-==-0-in-end_writeback
> > +++ a/fs/inode.c
> > @@ -423,7 +423,14 @@ EXPORT_SYMBOL(remove_inode_hash);
> >  void end_writeback(struct inode *inode)
> >  {
> >         might_sleep();
> > +       /*
> > +        * We have to cycle tree_lock here because reclaim can be still in the
> > +        * process of removing the last page (in __delete_from_page_cache())
> > +        * and we must not free mapping under it.
> > +        */
> > +       spin_lock(&inode->i_data.tree_lock);
> >         BUG_ON(inode->i_data.nrpages);
> > +       spin_unlock(&inode->i_data.tree_lock);
> >         BUG_ON(!list_empty(&inode->i_data.private_list));
> >         BUG_ON(!(inode->i_state & I_FREEING));
> >         BUG_ON(inode->i_state & I_CLEAR);
> > 
> > Adding Jan Kara to the list, and stable@kernel.org because the patch was cc'ed to there...
> 
> Yep, that very much wants to be spin_{un,}lock_irq().
  Oh, right. Stupid me. I'll fix that. Thanks for debugging this.

								Honza

-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mmotm 2011-06-22-13-05 uploaded
  2011-06-22 20:05 mmotm 2011-06-22-13-05 uploaded akpm
  2011-06-23  0:45 ` Stephen Rothwell
  2011-06-23  1:59 ` mmotm 2011-06-22 - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage Valdis.Kletnieks
@ 2011-06-27  2:49 ` KAMEZAWA Hiroyuki
  2 siblings, 0 replies; 8+ messages in thread
From: KAMEZAWA Hiroyuki @ 2011-06-27  2:49 UTC (permalink / raw)
  To: akpm; +Cc: linux-kernel, linux-mm, linux-fsdevel

On Wed, 22 Jun 2011 13:05:19 -0700
akpm@linux-foundation.org wrote:

> The mm-of-the-moment snapshot 2011-06-22-13-05 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/
> 
> and will soon be available at
>    git://zen-kernel.org/kernel/mmotm.git
> or
>    git://git.cmpxchg.org/linux-mmotm.git
> 
> It contains the following patches against 3.0-rc4:
> 

It may be too late but this was reported on KVM guest.

==
[  490.359961]
[  490.360944] =================================
[  490.360944] [ INFO: inconsistent lock state ]
[  490.360944] 3.0.0-rc4-mm1 #1
[  490.360944] ---------------------------------
[  490.360944] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[  490.360944] kworker/0:0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[  490.360944]  (&(&mapping->tree_lock)->rlock){?.+...}, at: [<ffffffff8110cbea>                  ] test_clear_page_writeback+0x6a/0x160
[  490.360944] {HARDIRQ-ON-W} state was registered at:
[  490.360944]   [<ffffffff81097069>] __lock_acquire+0x609/0x1670
[  490.360944]   [<ffffffff81098754>] lock_acquire+0xa4/0x120
[  490.360944]   [<ffffffff8159e396>] _raw_spin_lock+0x36/0x70
[  490.360944]   [<ffffffff8117d7e6>] end_writeback+0x36/0xd0
[  490.360944]   [<ffffffff8117d982>] evict+0x102/0x180
[  490.360944]   [<ffffffff8117ddda>] iput+0xea/0x1c0
[  490.360944]   [<ffffffff81172d2c>] do_unlinkat+0x16c/0x1d0
[  490.360944]   [<ffffffff81172da6>] sys_unlink+0x16/0x20
[  490.360944]   [<ffffffff815a6fc2>] system_call_fastpath+0x16/0x1b
[  490.360944] irq event stamp: 85616
[  490.360944] hardirqs last  enabled at (85613): [<ffffffff810140a1>] default_i                  dle+0x61/0x190
[  490.360944] hardirqs last disabled at (85614): [<ffffffff8159efea>] save_args                  +0x6a/0x70
[  490.360944] softirqs last  enabled at (85616): [<ffffffff8105fc83>] _local_bh                  _enable+0x13/0x20
[  490.360944] softirqs last disabled at (85615): [<ffffffff8105fd05>] irq_enter                  +0x75/0x90
[  490.360944]
[  490.360944] other info that might help us debug this:
[  490.360944]  Possible unsafe locking scenario:
[  490.360944]
[  490.360944]        CPU0
[  490.360944]        ----
[  490.360944]   lock(&(&mapping->tree_lock)->rlock);
[  490.360944]   <Interrupt>
[  490.360944]     lock(&(&mapping->tree_lock)->rlock);
[  490.360944]
[  490.360944]  *** DEADLOCK ***
[  490.360944]
[  490.360944] 1 lock held by kworker/0:0/0:
[  490.360944]  #0:  (&(&vblk->lock)->rlock){-.-...}, at: [<ffffffffa000f1ab>] blk_done+0x2b/0x120 [virtio_blk]
[  490.360944]
[  490.360944] stack backtrace:
[  490.360944] Pid: 0, comm: kworker/0:0 Not tainted 3.0.0-rc4-mm1 #1
[  490.360944] Call Trace:
[  490.360944]  <IRQ>  [<ffffffff810957f5>] print_usage_bug+0x235/0x280
[  490.360944]  [<ffffffff810962d6>] mark_lock+0x346/0x410
[  490.360944]  [<ffffffff810971f9>] __lock_acquire+0x799/0x1670
[  490.360944]  [<ffffffff81032059>] ? kvm_clock_read+0x19/0x20
[  490.360944]  [<ffffffff81032dc8>] ? pvclock_clocksource_read+0x58/0xd0
[  490.360944]  [<ffffffff81032dc8>] ? pvclock_clocksource_read+0x58/0xd0
[  490.360944]  [<ffffffff81085135>] ? sched_clock_local+0x25/0x90
[  490.360944]  [<ffffffff8110cbea>] ? test_clear_page_writeback+0x6a/0x160
[  490.360944]  [<ffffffff81098754>] lock_acquire+0xa4/0x120
[  490.360944]  [<ffffffff8110cbea>] ? test_clear_page_writeback+0x6a/0x160
[  490.360944]  [<ffffffff81085135>] ? sched_clock_local+0x25/0x90
[  490.360944]  [<ffffffff8159e545>] _raw_spin_lock_irqsave+0x55/0xa0
[  490.360944]  [<ffffffff8110cbea>] ? test_clear_page_writeback+0x6a/0x160
[  490.360944]  [<ffffffff81096cab>] ? __lock_acquire+0x24b/0x1670
[  490.360944]  [<ffffffff8110cbea>] test_clear_page_writeback+0x6a/0x160
[  490.360944]  [<ffffffff811012c4>] end_page_writeback+0x24/0x60
[  490.360944]  [<ffffffff81193dca>] end_buffer_async_write+0x13a/0x220
[  490.360944]  [<ffffffff81085258>] ? sched_clock_cpu+0xb8/0x110
[  490.360944]  [<ffffffff811922c0>] end_bio_bh_io_sync+0x30/0x50
[  490.360944]  [<ffffffff811969ad>] bio_endio+0x1d/0x40
[  490.360944]  [<ffffffff812a73a3>] req_bio_endio+0xa3/0xe0
[  490.360944]  [<ffffffff812a8294>] blk_update_request+0x104/0x4e0
[  490.360944]  [<ffffffff812a84e1>] ? blk_update_request+0x351/0x4e0
[  490.360944]  [<ffffffff8109244d>] ? trace_hardirqs_off+0xd/0x10
[  490.360944]  [<ffffffff812a8697>] blk_update_bidi_request+0x27/0xb0
[  490.360944]  [<ffffffff812a99ee>] __blk_end_request_all+0x2e/0x60
[  490.360944]  [<ffffffffa000f1cb>] blk_done+0x4b/0x120 [virtio_blk]
[  490.360944]  [<ffffffffa00052fc>] vring_interrupt+0x3c/0xb0 [virtio_ring]
[  490.360944]  [<ffffffff810c6f3d>] handle_irq_event_percpu+0x5d/0x210
[  490.360944]  [<ffffffff810c713e>] handle_irq_event+0x4e/0x80
[  490.360944]  [<ffffffff810ca213>] handle_edge_irq+0x83/0x140
[  490.360944]  [<ffffffff8100d40c>] handle_irq+0x4c/0xa0
[  490.360944]  [<ffffffff815a8acd>] do_IRQ+0x5d/0xe0
[  490.360944]  [<ffffffff8159f093>] common_interrupt+0x13/0x13
[  490.360944]  <EOI>  [<ffffffff810320bb>] ? native_safe_halt+0xb/0x10
[  490.360944]  [<ffffffff8109677d>] ? trace_hardirqs_on+0xd/0x10
[  490.360944]  [<ffffffff810140a6>] default_idle+0x66/0x190
[  490.360944]  [<ffffffff8100b0ac>] cpu_idle+0xbc/0x110
[  490.360944]  [<ffffffff815950ca>] start_secondary+0x256/0x258
[  OK  ]


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2011-06-27  2:57 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-22 20:05 mmotm 2011-06-22-13-05 uploaded akpm
2011-06-23  0:45 ` Stephen Rothwell
2011-06-23  1:59 ` mmotm 2011-06-22 - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage Valdis.Kletnieks
2011-06-23 15:38   ` Peter Zijlstra
2011-06-23 16:02     ` Valdis.Kletnieks
2011-06-23 16:08       ` Peter Zijlstra
2011-06-23 19:59         ` Jan Kara
2011-06-27  2:49 ` mmotm 2011-06-22-13-05 uploaded KAMEZAWA Hiroyuki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox