* [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-05 21:58 bugzilla-daemon
2009-05-05 23:16 ` [Bug 13232] " bugzilla-daemon
` (15 more replies)
0 siblings, 16 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-05 21:58 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Summary: ext3/4 with synchronous writes gets wedged by Postfix
Product: File System
Version: 2.5
Kernel Version: 2.6.29.2
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext3
AssignedTo: fs_ext3@kernel-bugs.osdl.org
ReportedBy: kernel-nospam@dbwatson.ukfsn.org
Regression: Yes
Latest working kernel version: 2.6.28.9
Earliest failing kernel version: 2.6.29
Distribution: Ubuntu 8.04 LTS
Hardware Environment: Intel 875p chipset (ICH5), P4 with HT
Software Environment: Postfix 2.5.1-2ubuntu1.2
Problem Description:
With its queue directory on an ext3 or journalled ext4 file
system, mounted with the 'sync' option (or with the 'S' attribute
on the individual queue directories, which is a config option for
the Ubuntu package), sending more than a few messages in quick
succession through Postfix causes Postfix and any other process
attempting to modify the file system afterwards (e.g. by updating
the atime when listing a directory) to hang in uninterruptible
sleep. sync(1) will also hang afterwards. If the FS is mounted
noatime, it is still possible to read from it, although trying to
list the affected queue directories still causes ls to hang (the
list of affected directories seems to vary, but may include at
least "active" and "maildrop").
This happens whether the filesystem is on a hard disk or a RAM
disk (/dev/ramX, not tmpfs). Enabling or disabling barriers, or
changing the journalling mode doesn't help.
Ext2 seems to be unaffected, as does non-journalled ext4. XFS,
Reiser and JFS are also fine. The hang doesn't occur if the
queue directories have the 'D' attribute (and a non-sync mount)
instead of 'S'.
Nothing appears in dmesg at the time of the hang, but here's the
output from SysRq-W afterwards (ext3 FS, kernel 2.6.29.2,
non-SMP, PREEMPT_NONE):
SysRq : Show Blocked State
task PC stack pid father
kjournald D c01384df 0 2525 2
cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
[<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c0122a25>] ? del_timer+0x50/0x59
[<c01c0c75>] kjournald+0xad/0x1bb
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c01c0bc8>] ? kjournald+0x0/0x1bb
[<c012b442>] kthread+0x37/0x59
[<c012b40b>] ? kthread+0x0/0x59
[<c0103667>] kernel_thread_helper+0x7/0x10
pickup D c01384df 0 2597 2594
cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c012b8b7>] ? prepare_to_wait+0x42/0x4a
[<c01c0539>] log_wait_commit+0x90/0xf7
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c01bba9d>] journal_stop+0x1c8/0x288
[<c01b4236>] __ext3_journal_stop+0x1c/0x38
[<c01aeb96>] ext3_delete_inode+0x90/0xc2
[<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
[<c017ab82>] generic_delete_inode+0x72/0x100
[<c02c4ee1>] ? _spin_lock+0x3a/0x40
[<c017ad4c>] generic_drop_inode+0x13c/0x1da
[<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
[<c017a4e7>] iput+0x47/0x4e
[<c0173db0>] do_unlinkat+0xc1/0x137
[<c0102f87>] ? sysenter_exit+0xf/0x18
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c0173e36>] sys_unlink+0x10/0x12
[<c0102f55>] sysenter_do_call+0x12/0x35
qmgr D c01384df 0 2598 2594
cfe23e60 00000082 df9fa200 c01384df cfe23e48 c02cb5c0 cfe23e78 de32cf00
cfe23e60 c012b8b7 00000002 de324800 0000014f cfe23e78 cfe23e98 c01c0539
00000000 de3248c8 de324910 de324814 00000000 df9fa200 c012b6ee cfaa9e80
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c012b8b7>] ? prepare_to_wait+0x42/0x4a
[<c01c0539>] log_wait_commit+0x90/0xf7
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c01bba9d>] journal_stop+0x1c8/0x288
[<c01ac11e>] ? ext3_mark_iloc_dirty+0x1d8/0x34b
[<c01b4236>] __ext3_journal_stop+0x1c/0x38
[<c01b309d>] ext3_unlink+0x70/0x157
[<c0172344>] ? vfs_unlink+0x45/0xb0
[<c0172358>] vfs_unlink+0x59/0xb0
[<c0173e17>] do_unlinkat+0x128/0x137
[<c0102f87>] ? sysenter_exit+0xf/0x18
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c0173e36>] sys_unlink+0x10/0x12
[<c0102f55>] sysenter_do_call+0x12/0x35
local D c01384df 0 2654 2594
de369c74 00000096 df9f8880 c01384df de369c5c 00000286 00000000 de183b80
de324814 de324800 de324814 dd037e80 de324800 de324880 de369cc4 c01bc306
c0138489 00000246 00000046 00000001 de324a0c de324814 de324814 df59c060
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c01bc306>] start_this_handle+0x1c2/0x361
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c01bc54a>] journal_start+0xa5/0x100
[<c01b43ac>] ext3_journal_start_sb+0x48/0x4d
[<c01aec4c>] ext3_write_begin+0x84/0x1c6
[<c0139fe2>] ? __lock_acquire+0x32b/0xa21
[<c014749e>] generic_file_buffered_write+0xe1/0x292
[<c0147a94>] __generic_file_aio_write_nolock+0x25c/0x4ab
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c0147f63>] generic_file_aio_write+0x66/0xda
[<c0138f6b>] ? validate_chain+0x3f5/0x1141
[<c01aad03>] ext3_file_write+0x27/0xa8
[<c016a972>] do_sync_write+0xcc/0x102
[<c012b6ee>] ? autoremove_wake_function+0x0/0x38
[<c016b16d>] vfs_write+0x8b/0x11f
[<c0102f87>] ? sysenter_exit+0xf/0x18
[<c016a8a6>] ? do_sync_write+0x0/0x102
[<c016b577>] sys_write+0x3d/0x64
[<c0102f55>] sysenter_do_call+0x12/0x35
postdrop D c01384df 0 2664 2663
cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
Call Trace:
[<c01384df>] ? trace_hardirqs_on+0xb/0xd
[<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
[<c012b726>] ? wake_bit_function+0x0/0x47
[<c017a5b5>] find_inode_fast+0x3f/0x4a
[<c017ba05>] insert_inode_locked+0x50/0xeb
[<c01ab90b>] ext3_new_inode+0x738/0x88f
[<c01bc550>] ? journal_start+0xab/0x100
[<c01b259a>] ext3_create+0x59/0xbf
[<c01722c4>] vfs_create+0x75/0xb0
[<c02c4dda>] ? _spin_unlock+0x1d/0x20
[<c01b2541>] ? ext3_create+0x0/0xbf
[<c0174bc3>] do_filp_open+0x644/0x713
[<c02c4dda>] ? _spin_unlock+0x1d/0x20
[<c01692ce>] do_sys_open+0x45/0xce
[<c0102f87>] ? sysenter_exit+0xf/0x18
[<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
[<c01693a3>] sys_open+0x23/0x2b
[<c0102f55>] sysenter_do_call+0x12/0x35
Sched Debug Version: v0.08, 2.6.29.2-test #1
now at 166155.025991 msecs
.sysctl_sched_latency : 20.000000
.sysctl_sched_min_granularity : 4.000000
.sysctl_sched_wakeup_granularity : 5.000000
.sysctl_sched_child_runs_first : 0.000001
.sysctl_sched_features : 24191
cpu#0, 2798.181 MHz
.nr_running : 2
.load : 2048
.nr_switches : 284843
.nr_load_updates : 6497
.nr_uninterruptible : 5
.jiffies : 4294953911
.next_balance : 0.000000
.curr->pid : 2466
.clock : 166154.370058
.cpu_load[0] : 0
.cpu_load[1] : 4
.cpu_load[2] : 76
.cpu_load[3] : 160
.cpu_load[4] : 196
cfs_rq[0]:
.exec_clock : 0.000000
.MIN_vruntime : 24407.116340
.min_vruntime : 24407.114218
.max_vruntime : 24407.116340
.spread : 0.000000
.spread0 : 0.000000
.nr_running : 2
.load : 2048
.nr_spread_over : 0
rt_rq[0]:
.rt_nr_running : 0
.rt_throttled : 0
.rt_time : 0.000000
.rt_runtime : 950.000000
runnable tasks:
task PID tree-key switches prio exec-runtime
sum-exec sum-sleep
----------------------------------------------------------------------------------------------------------
Xorg 2163 24407.116340 28791 120 0
0 0.000000 0.000000 0.000000
R bash 2466 24387.418829 274 120 0
0 0.000000 0.000000 0.000000
Steps to reproduce:
# mount -o remount,sync /var
(or wherever queue_directory points to in the Postfix config)
# while true; do sendmail testaddr@localhost </dev/null; done
--- Comment #1 from Andrew Morton <akpm@linux-foundation.org> 2009-05-05 21:58:17 ---
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sun, 3 May 2009 19:48:21 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13232
>
> Summary: ext3/4 with synchronous writes gets wedged by Postfix
> Product: File System
> Version: 2.5
> Kernel Version: 2.6.29.2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: ext3
> AssignedTo: fs_ext3@kernel-bugs.osdl.org
> ReportedBy: kernel-nospam@dbwatson.ukfsn.org
> Regression: Yes
>
>
> Latest working kernel version: 2.6.28.9
> Earliest failing kernel version: 2.6.29
A very very bad regression.
> Distribution: Ubuntu 8.04 LTS
> Hardware Environment: Intel 875p chipset (ICH5), P4 with HT
> Software Environment: Postfix 2.5.1-2ubuntu1.2
>
> Problem Description:
>
> With its queue directory on an ext3 or journalled ext4 file
> system, mounted with the 'sync' option (or with the 'S' attribute
> on the individual queue directories, which is a config option for
> the Ubuntu package), sending more than a few messages in quick
> succession through Postfix causes Postfix and any other process
> attempting to modify the file system afterwards (e.g. by updating
> the atime when listing a directory) to hang in uninterruptible
> sleep. sync(1) will also hang afterwards. If the FS is mounted
> noatime, it is still possible to read from it, although trying to
> list the affected queue directories still causes ls to hang (the
> list of affected directories seems to vary, but may include at
> least "active" and "maildrop").
>
> This happens whether the filesystem is on a hard disk or a RAM
> disk (/dev/ramX, not tmpfs). Enabling or disabling barriers, or
> changing the journalling mode doesn't help.
>
> Ext2 seems to be unaffected, as does non-journalled ext4. XFS,
> Reiser and JFS are also fine. The hang doesn't occur if the
> queue directories have the 'D' attribute (and a non-sync mount)
> instead of 'S'.
>
> Nothing appears in dmesg at the time of the hang, but here's the
> output from SysRq-W afterwards (ext3 FS, kernel 2.6.29.2,
> non-SMP, PREEMPT_NONE):
>
> SysRq : Show Blocked State
> task PC stack pid father
> kjournald D c01384df 0 2525 2
> cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> 00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c0122a25>] ? del_timer+0x50/0x59
> [<c01c0c75>] kjournald+0xad/0x1bb
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c01c0bc8>] ? kjournald+0x0/0x1bb
> [<c012b442>] kthread+0x37/0x59
> [<c012b40b>] ? kthread+0x0/0x59
> [<c0103667>] kernel_thread_helper+0x7/0x10
I assume this is
while (commit_transaction->t_updates) {
DEFINE_WAIT(wait);
prepare_to_wait(&journal->j_wait_updates, &wait,
TASK_UNINTERRUPTIBLE);
if (commit_transaction->t_updates) {
spin_unlock(&commit_transaction->t_handle_lock);
spin_unlock(&journal->j_state_lock);
schedule();
I'm wondering about
: commit e219cca082f52e7dfea41f3be264b7b5eb204227
: Author: Theodore Ts'o <tytso@mit.edu>
: AuthorDate: Thu Nov 6 22:37:59 2008 -0500
: Commit: Theodore Ts'o <tytso@mit.edu>
: CommitDate: Thu Nov 6 22:37:59 2008 -0500
:
: jbd: don't give up looking for space so easily in __log_wait_for_space
but that patch was present in 2.6.28.
> pickup D c01384df 0 2597 2594
> cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> 00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> [<c01c0539>] log_wait_commit+0x90/0xf7
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c01bba9d>] journal_stop+0x1c8/0x288
> [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> [<c017ab82>] generic_delete_inode+0x72/0x100
> [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> [<c017a4e7>] iput+0x47/0x4e
> [<c0173db0>] do_unlinkat+0xc1/0x137
> [<c0102f87>] ? sysenter_exit+0xf/0x18
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c0173e36>] sys_unlink+0x10/0x12
> [<c0102f55>] sysenter_do_call+0x12/0x35
> qmgr D c01384df 0 2598 2594
> cfe23e60 00000082 df9fa200 c01384df cfe23e48 c02cb5c0 cfe23e78 de32cf00
> cfe23e60 c012b8b7 00000002 de324800 0000014f cfe23e78 cfe23e98 c01c0539
> 00000000 de3248c8 de324910 de324814 00000000 df9fa200 c012b6ee cfaa9e80
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> [<c01c0539>] log_wait_commit+0x90/0xf7
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c01bba9d>] journal_stop+0x1c8/0x288
> [<c01ac11e>] ? ext3_mark_iloc_dirty+0x1d8/0x34b
> [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> [<c01b309d>] ext3_unlink+0x70/0x157
> [<c0172344>] ? vfs_unlink+0x45/0xb0
> [<c0172358>] vfs_unlink+0x59/0xb0
> [<c0173e17>] do_unlinkat+0x128/0x137
> [<c0102f87>] ? sysenter_exit+0xf/0x18
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c0173e36>] sys_unlink+0x10/0x12
> [<c0102f55>] sysenter_do_call+0x12/0x35
> local D c01384df 0 2654 2594
> de369c74 00000096 df9f8880 c01384df de369c5c 00000286 00000000 de183b80
> de324814 de324800 de324814 dd037e80 de324800 de324880 de369cc4 c01bc306
> c0138489 00000246 00000046 00000001 de324a0c de324814 de324814 df59c060
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c01bc306>] start_this_handle+0x1c2/0x361
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c01bc54a>] journal_start+0xa5/0x100
> [<c01b43ac>] ext3_journal_start_sb+0x48/0x4d
> [<c01aec4c>] ext3_write_begin+0x84/0x1c6
> [<c0139fe2>] ? __lock_acquire+0x32b/0xa21
> [<c014749e>] generic_file_buffered_write+0xe1/0x292
> [<c0147a94>] __generic_file_aio_write_nolock+0x25c/0x4ab
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c0147f63>] generic_file_aio_write+0x66/0xda
> [<c0138f6b>] ? validate_chain+0x3f5/0x1141
> [<c01aad03>] ext3_file_write+0x27/0xa8
> [<c016a972>] do_sync_write+0xcc/0x102
> [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> [<c016b16d>] vfs_write+0x8b/0x11f
> [<c0102f87>] ? sysenter_exit+0xf/0x18
> [<c016a8a6>] ? do_sync_write+0x0/0x102
> [<c016b577>] sys_write+0x3d/0x64
> [<c0102f55>] sysenter_do_call+0x12/0x35
> postdrop D c01384df 0 2664 2663
> cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> Call Trace:
> [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> [<c012b726>] ? wake_bit_function+0x0/0x47
> [<c017a5b5>] find_inode_fast+0x3f/0x4a
> [<c017ba05>] insert_inode_locked+0x50/0xeb
> [<c01ab90b>] ext3_new_inode+0x738/0x88f
> [<c01bc550>] ? journal_start+0xab/0x100
> [<c01b259a>] ext3_create+0x59/0xbf
> [<c01722c4>] vfs_create+0x75/0xb0
> [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> [<c01b2541>] ? ext3_create+0x0/0xbf
> [<c0174bc3>] do_filp_open+0x644/0x713
> [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> [<c01692ce>] do_sys_open+0x45/0xce
> [<c0102f87>] ? sysenter_exit+0xf/0x18
> [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> [<c01693a3>] sys_open+0x23/0x2b
> [<c0102f55>] sysenter_do_call+0x12/0x35
> Sched Debug Version: v0.08, 2.6.29.2-test #1
> now at 166155.025991 msecs
> .sysctl_sched_latency : 20.000000
> .sysctl_sched_min_granularity : 4.000000
> .sysctl_sched_wakeup_granularity : 5.000000
> .sysctl_sched_child_runs_first : 0.000001
> .sysctl_sched_features : 24191
>
> cpu#0, 2798.181 MHz
> .nr_running : 2
> .load : 2048
> .nr_switches : 284843
> .nr_load_updates : 6497
> .nr_uninterruptible : 5
> .jiffies : 4294953911
> .next_balance : 0.000000
> .curr->pid : 2466
> .clock : 166154.370058
> .cpu_load[0] : 0
> .cpu_load[1] : 4
> .cpu_load[2] : 76
> .cpu_load[3] : 160
> .cpu_load[4] : 196
>
> cfs_rq[0]:
> .exec_clock : 0.000000
> .MIN_vruntime : 24407.116340
> .min_vruntime : 24407.114218
> .max_vruntime : 24407.116340
> .spread : 0.000000
> .spread0 : 0.000000
> .nr_running : 2
> .load : 2048
> .nr_spread_over : 0
>
> rt_rq[0]:
> .rt_nr_running : 0
> .rt_throttled : 0
> .rt_time : 0.000000
> .rt_runtime : 950.000000
>
> runnable tasks:
> task PID tree-key switches prio exec-runtime
> sum-exec sum-sleep
> ----------------------------------------------------------------------------------------------------------
> Xorg 2163 24407.116340 28791 120 0
> 0 0.000000 0.000000 0.000000
> R bash 2466 24387.418829 274 120 0
> 0 0.000000 0.000000 0.000000
>
>
> Steps to reproduce:
>
> # mount -o remount,sync /var
> (or wherever queue_directory points to in the Postfix config)
>
> # while true; do sendmail testaddr@localhost </dev/null; done
>
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
@ 2009-05-05 23:16 ` bugzilla-daemon
2009-05-12 16:56 ` bugzilla-daemon
` (14 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-05 23:16 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Rafael J. Wysocki <rjw@sisk.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rjw@sisk.pl
Blocks| |12398
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
2009-05-05 23:16 ` [Bug 13232] " bugzilla-daemon
@ 2009-05-12 16:56 ` bugzilla-daemon
2009-05-13 13:48 ` Jan Kara
2009-05-13 13:48 ` bugzilla-daemon
` (13 subsequent siblings)
15 siblings, 1 reply; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-12 16:56 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #2 from Jan Kara <jack@suse.cz> 2009-05-12 16:56:04 ---
Hi,
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> > SysRq : Show Blocked State
> > task PC stack pid father
> > kjournald D c01384df 0 2525 2
> > cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> > de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> > 00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> > Call Trace:
> > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> > [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > [<c0122a25>] ? del_timer+0x50/0x59
> > [<c01c0c75>] kjournald+0xad/0x1bb
> > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > [<c01c0bc8>] ? kjournald+0x0/0x1bb
> > [<c012b442>] kthread+0x37/0x59
> > [<c012b40b>] ? kthread+0x0/0x59
> > [<c0103667>] kernel_thread_helper+0x7/0x10
>
> I assume this is
>
> while (commit_transaction->t_updates) {
> DEFINE_WAIT(wait);
>
> prepare_to_wait(&journal->j_wait_updates, &wait,
> TASK_UNINTERRUPTIBLE);
> if (commit_transaction->t_updates) {
> spin_unlock(&commit_transaction->t_handle_lock);
> spin_unlock(&journal->j_state_lock);
> schedule();
Yes.
> I'm wondering about
>
> : commit e219cca082f52e7dfea41f3be264b7b5eb204227
> : Author: Theodore Ts'o <tytso@mit.edu>
> : AuthorDate: Thu Nov 6 22:37:59 2008 -0500
> : Commit: Theodore Ts'o <tytso@mit.edu>
> : CommitDate: Thu Nov 6 22:37:59 2008 -0500
> :
> : jbd: don't give up looking for space so easily in __log_wait_for_space
>
> but that patch was present in 2.6.28.
Hmm, I don't see what made this deadlock happening - as far as I can
see it's there for quite some time. See below...
> > pickup D c01384df 0 2597 2594
> > cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> > cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> > 00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> > Call Trace:
> > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> > [<c01c0539>] log_wait_commit+0x90/0xf7
> > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > [<c01bba9d>] journal_stop+0x1c8/0x288
> > [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> > [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> > [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> > [<c017ab82>] generic_delete_inode+0x72/0x100
> > [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> > [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> > [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> > [<c017a4e7>] iput+0x47/0x4e
> > [<c0173db0>] do_unlinkat+0xc1/0x137
> > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > [<c0173e36>] sys_unlink+0x10/0x12
> > [<c0102f55>] sysenter_do_call+0x12/0x35
In generic_delete_inode() we mark inode as I_FREEING. Then
ext3_delete_inode() is called and because of O_SYNC it starts a
transaction commit and waits for it.
> > postdrop D c01384df 0 2664 2663
> > cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> > c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> > dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> > Call Trace:
> > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> > [<c012b726>] ? wake_bit_function+0x0/0x47
> > [<c017a5b5>] find_inode_fast+0x3f/0x4a
> > [<c017ba05>] insert_inode_locked+0x50/0xeb
> > [<c01ab90b>] ext3_new_inode+0x738/0x88f
> > [<c01bc550>] ? journal_start+0xab/0x100
> > [<c01b259a>] ext3_create+0x59/0xbf
> > [<c01722c4>] vfs_create+0x75/0xb0
> > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > [<c01b2541>] ? ext3_create+0x0/0xbf
> > [<c0174bc3>] do_filp_open+0x644/0x713
> > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > [<c01692ce>] do_sys_open+0x45/0xce
> > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > [<c01693a3>] sys_open+0x23/0x2b
> > [<c0102f55>] sysenter_do_call+0x12/0x35
Here, we have started a transaction in ext3_create() and then wait in
find_inode_fast() for I_FREEING to be cleared (obviously we have
reallocated the inode and squeezed the allocation before journal_stop()
from the delete was called).
Nasty deadlock and I don't see how to fix it now - have to go home for
today... Tomorrow I'll have a look what we can do about it.
Honza
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-12 16:56 ` bugzilla-daemon
@ 2009-05-13 13:48 ` Jan Kara
2009-05-13 16:07 ` Theodore Tso
2009-05-13 16:52 ` Al Viro
0 siblings, 2 replies; 50+ messages in thread
From: Jan Kara @ 2009-05-13 13:48 UTC (permalink / raw)
To: bugzilla-daemon; +Cc: linux-ext4, Al Viro
> http://bugzilla.kernel.org/show_bug.cgi?id=13232
>
> --- Comment #2 from Jan Kara <jack@suse.cz> 2009-05-12 16:56:04 ---
> Hi,
>
> > (switched to email. Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
>
> > > SysRq : Show Blocked State
> > > task PC stack pid father
> > > kjournald D c01384df 0 2525 2
> > > cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> > > de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> > > 00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> > > [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c0122a25>] ? del_timer+0x50/0x59
> > > [<c01c0c75>] kjournald+0xad/0x1bb
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c01c0bc8>] ? kjournald+0x0/0x1bb
> > > [<c012b442>] kthread+0x37/0x59
> > > [<c012b40b>] ? kthread+0x0/0x59
> > > [<c0103667>] kernel_thread_helper+0x7/0x10
> >
> > I assume this is
> >
> > while (commit_transaction->t_updates) {
> > DEFINE_WAIT(wait);
> >
> > prepare_to_wait(&journal->j_wait_updates, &wait,
> > TASK_UNINTERRUPTIBLE);
> > if (commit_transaction->t_updates) {
> > spin_unlock(&commit_transaction->t_handle_lock);
> > spin_unlock(&journal->j_state_lock);
> > schedule();
> Yes.
>
> > I'm wondering about
> >
> > : commit e219cca082f52e7dfea41f3be264b7b5eb204227
> > : Author: Theodore Ts'o <tytso@mit.edu>
> > : AuthorDate: Thu Nov 6 22:37:59 2008 -0500
> > : Commit: Theodore Ts'o <tytso@mit.edu>
> > : CommitDate: Thu Nov 6 22:37:59 2008 -0500
> > :
> > : jbd: don't give up looking for space so easily in __log_wait_for_space
> >
> > but that patch was present in 2.6.28.
> Hmm, I don't see what made this deadlock happening - as far as I can
> see it's there for quite some time. See below...
>
> > > pickup D c01384df 0 2597 2594
> > > cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> > > cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> > > 00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> > > [<c01c0539>] log_wait_commit+0x90/0xf7
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c01bba9d>] journal_stop+0x1c8/0x288
> > > [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> > > [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> > > [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> > > [<c017ab82>] generic_delete_inode+0x72/0x100
> > > [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> > > [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> > > [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> > > [<c017a4e7>] iput+0x47/0x4e
> > > [<c0173db0>] do_unlinkat+0xc1/0x137
> > > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c0173e36>] sys_unlink+0x10/0x12
> > > [<c0102f55>] sysenter_do_call+0x12/0x35
> In generic_delete_inode() we mark inode as I_FREEING. Then
> ext3_delete_inode() is called and because of O_SYNC it starts a
> transaction commit and waits for it.
>
> > > postdrop D c01384df 0 2664 2663
> > > cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> > > c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> > > dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> > > [<c012b726>] ? wake_bit_function+0x0/0x47
> > > [<c017a5b5>] find_inode_fast+0x3f/0x4a
> > > [<c017ba05>] insert_inode_locked+0x50/0xeb
> > > [<c01ab90b>] ext3_new_inode+0x738/0x88f
> > > [<c01bc550>] ? journal_start+0xab/0x100
> > > [<c01b259a>] ext3_create+0x59/0xbf
> > > [<c01722c4>] vfs_create+0x75/0xb0
> > > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > > [<c01b2541>] ? ext3_create+0x0/0xbf
> > > [<c0174bc3>] do_filp_open+0x644/0x713
> > > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > > [<c01692ce>] do_sys_open+0x45/0xce
> > > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c01693a3>] sys_open+0x23/0x2b
> > > [<c0102f55>] sysenter_do_call+0x12/0x35
> Here, we have started a transaction in ext3_create() and then wait in
> find_inode_fast() for I_FREEING to be cleared (obviously we have
> reallocated the inode and squeezed the allocation before journal_stop()
> from the delete was called).
> Nasty deadlock and I don't see how to fix it now - have to go home for
> today... Tomorrow I'll have a look what we can do about it.
OK, the deadlock has been introduced by ext3 variant of
261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
is really tough to avoid - we have to first allocate inode on disk so
that we know the inode number. For this we need transaction open but we
cannot afford waiting for old inode with same INO to be freed when we have
transaction open because of the above deadlock. So we'd have to wait for
inode release only after everything is done and we closed the transaction. But
that would mean reordering a lot of code in ext3/namei.c so that all the
dcache handling is done after all the IO is done.
Hmm, maybe we could change the delete side of the deadlock but that's
going to be tricky as well :(.
Al, any idea if we could somehow get away without waiting on
I_FREEING?
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 13:48 ` Jan Kara
@ 2009-05-13 16:07 ` Theodore Tso
2009-05-18 12:45 ` Jan Kara
2009-05-13 16:52 ` Al Viro
1 sibling, 1 reply; 50+ messages in thread
From: Theodore Tso @ 2009-05-13 16:07 UTC (permalink / raw)
To: Jan Kara; +Cc: bugzilla-daemon, linux-ext4, Al Viro
On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
What do you mean by this?
I'm puzzled why we haven't hit this before. This looks like
long-standing issue; what unmasked it now?
> The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number.
Well, the simple thing to do is to have a way of quickly determining
that a particular inode number is in the I_FREEING state, and simply
try to avoid using that inode number. If there are no inodes
available, it can simply close the handle (since nothing else has
changed at that point), wait for the current transaction to close, and
then try again. That should fix the problem, I think.
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 16:07 ` Theodore Tso
@ 2009-05-18 12:45 ` Jan Kara
0 siblings, 0 replies; 50+ messages in thread
From: Jan Kara @ 2009-05-18 12:45 UTC (permalink / raw)
To: Theodore Tso; +Cc: bugzilla-daemon, linux-ext4, Al Viro
On Wed 13-05-09 12:07:24, Theodore Tso wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
>
> What do you mean by this?
>
> I'm puzzled why we haven't hit this before. This looks like
> long-standing issue; what unmasked it now?
Unless you mount the fs with 'sync' option, hitting this is much harder
(the window is quite small in nosync case). I think that is the main reason
why we didn't see this earlier.
> > The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number.
>
> Well, the simple thing to do is to have a way of quickly determining
> that a particular inode number is in the I_FREEING state, and simply
> try to avoid using that inode number. If there are no inodes
> available, it can simply close the handle (since nothing else has
> changed at that point), wait for the current transaction to close, and
> then try again. That should fix the problem, I think.
Yes, we could work-around it like that but other filesystems might need
similar things and generally it would be nicer if we could avoid using this
vfs-internal information in the filesystems. Al seems to have found some
other solution without changing filesystems so that would be easier for us...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 13:48 ` Jan Kara
2009-05-13 16:07 ` Theodore Tso
@ 2009-05-13 16:52 ` Al Viro
2009-05-13 18:13 ` Al Viro
2009-05-18 12:53 ` Jan Kara
1 sibling, 2 replies; 50+ messages in thread
From: Al Viro @ 2009-05-13 16:52 UTC (permalink / raw)
To: Jan Kara; +Cc: bugzilla-daemon, linux-ext4
On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > Here, we have started a transaction in ext3_create() and then wait in
> > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > reallocated the inode and squeezed the allocation before journal_stop()
> > from the delete was called).
> > Nasty deadlock and I don't see how to fix it now - have to go home for
> > today... Tomorrow I'll have a look what we can do about it.
> OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number. For this we need transaction open but we
> cannot afford waiting for old inode with same INO to be freed when we have
> transaction open because of the above deadlock. So we'd have to wait for
> inode release only after everything is done and we closed the transaction. But
> that would mean reordering a lot of code in ext3/namei.c so that all the
> dcache handling is done after all the IO is done.
> Hmm, maybe we could change the delete side of the deadlock but that's
> going to be tricky as well :(.
> Al, any idea if we could somehow get away without waiting on
> I_FREEING?
At which point do we actually run into deadlock on delete side? We could,
in principle, skip everything like that in insert_inode_locked(), but
I would rather avoid the "two inodes in icache at the same time, with the
same inumber" situations completely. We might get away with that, since
everything else *will* wait, so we can afford a bunch of inodes past the
point in foo_delete_inode() that has cleared it in bitmap + new locked
one, but if it's at all possible to avoid, I'd rather avoid it.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 16:52 ` Al Viro
@ 2009-05-13 18:13 ` Al Viro
2009-05-18 13:15 ` Theodore Tso
2009-05-18 14:10 ` Jan Kara
2009-05-18 12:53 ` Jan Kara
1 sibling, 2 replies; 50+ messages in thread
From: Al Viro @ 2009-05-13 18:13 UTC (permalink / raw)
To: Jan Kara; +Cc: bugzilla-daemon, linux-ext4, linux-fsdevel
On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> > Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> > Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
>
> At which point do we actually run into deadlock on delete side? We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely. We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
OK, that's probably the easiest way to do that, as much as I don't like it...
Since iget() et.al. will not accept I_FREEING (will wait to go away
and restart), and since we'd better have serialization between new/free
on fs data structures anyway, we can afford simply skipping I_FREEING
et.al. in insert_inode_locked().
We do that from new_inode, so it won't race with free_inode in any interesting
ways and it won't race with iget (of any origin; nfsd or in case of fs
corruption a lookup) since both still will wait for I_LOCK.
Tentative patch follow; folks, I would very much like review on that one,
since I'm far too low on caffeine and the area is nasty.
diff --git a/fs/inode.c b/fs/inode.c
index 9d26490..4406952 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
struct super_block *sb = inode->i_sb;
ino_t ino = inode->i_ino;
struct hlist_head *head = inode_hashtable + hash(sb, ino);
- struct inode *old;
inode->i_state |= I_LOCK|I_NEW;
while (1) {
+ struct hlist_node *node;
+ struct inode *old = NULL;
spin_lock(&inode_lock);
- old = find_inode_fast(sb, head, ino);
- if (likely(!old)) {
+ hlist_for_each_entry(old, node, head, i_hash) {
+ if (old->i_ino != ino)
+ continue;
+ if (old->i_sb != sb)
+ continue;
+ if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+ continue;
+ break;
+ }
+ if (likely(!node)) {
hlist_add_head(&inode->i_hash, head);
spin_unlock(&inode_lock);
return 0;
@@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
{
struct super_block *sb = inode->i_sb;
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
- struct inode *old;
inode->i_state |= I_LOCK|I_NEW;
while (1) {
+ struct hlist_node *node;
+ struct inode *old = NULL;
+
spin_lock(&inode_lock);
- old = find_inode(sb, head, test, data);
- if (likely(!old)) {
+ hlist_for_each_entry(old, node, head, i_hash) {
+ if (old->i_sb != sb)
+ continue;
+ if (!test(old, data))
+ continue;
+ if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+ continue;
+ break;
+ }
+ if (likely(!node)) {
hlist_add_head(&inode->i_hash, head);
spin_unlock(&inode_lock);
return 0;
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 18:13 ` Al Viro
@ 2009-05-18 13:15 ` Theodore Tso
2009-05-18 14:10 ` Jan Kara
1 sibling, 0 replies; 50+ messages in thread
From: Theodore Tso @ 2009-05-18 13:15 UTC (permalink / raw)
To: Al Viro; +Cc: Jan Kara, bugzilla-daemon, linux-ext4, linux-fsdevel
On Wed, May 13, 2009 at 07:13:40PM +0100, Al Viro wrote:
>
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
>
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
>
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
Sorry for not having time to review this until now. This looks good
to me.
Reviewed-by: "Theodore Ts'o" <tytso@mit.edu>
So Bug #13232 is currently marked as a 2.6.28 regression; do we feel
confident enough to push this to Linus for 2.6.30?
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 18:13 ` Al Viro
2009-05-18 13:15 ` Theodore Tso
@ 2009-05-18 14:10 ` Jan Kara
1 sibling, 0 replies; 50+ messages in thread
From: Jan Kara @ 2009-05-18 14:10 UTC (permalink / raw)
To: Al Viro; +Cc: bugzilla-daemon, linux-ext4, linux-fsdevel
On Wed 13-05-09 19:13:40, Al Viro wrote:
> On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> > On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > > Here, we have started a transaction in ext3_create() and then wait in
> > > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > > reallocated the inode and squeezed the allocation before journal_stop()
> > > > from the delete was called).
> > > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > > today... Tomorrow I'll have a look what we can do about it.
> > > OK, the deadlock has been introduced by ext3 variant of
> > > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > > is really tough to avoid - we have to first allocate inode on disk so
> > > that we know the inode number. For this we need transaction open but we
> > > cannot afford waiting for old inode with same INO to be freed when we have
> > > transaction open because of the above deadlock. So we'd have to wait for
> > > inode release only after everything is done and we closed the transaction. But
> > > that would mean reordering a lot of code in ext3/namei.c so that all the
> > > dcache handling is done after all the IO is done.
> > > Hmm, maybe we could change the delete side of the deadlock but that's
> > > going to be tricky as well :(.
> > > Al, any idea if we could somehow get away without waiting on
> > > I_FREEING?
> >
> > At which point do we actually run into deadlock on delete side? We could,
> > in principle, skip everything like that in insert_inode_locked(), but
> > I would rather avoid the "two inodes in icache at the same time, with the
> > same inumber" situations completely. We might get away with that, since
> > everything else *will* wait, so we can afford a bunch of inodes past the
> > point in foo_delete_inode() that has cleared it in bitmap + new locked
> > one, but if it's at all possible to avoid, I'd rather avoid it.
>
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
>
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
>
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
The patch looks fine. Everyone else will either get new inode and wait
for I_LOCK or get old inode and wait for I_FREEING so everything should be
fine... You can add.
Acked-by: Jan Kara <jack@suse.cz>
Honza
>
> diff --git a/fs/inode.c b/fs/inode.c
> index 9d26490..4406952 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
> struct super_block *sb = inode->i_sb;
> ino_t ino = inode->i_ino;
> struct hlist_head *head = inode_hashtable + hash(sb, ino);
> - struct inode *old;
>
> inode->i_state |= I_LOCK|I_NEW;
> while (1) {
> + struct hlist_node *node;
> + struct inode *old = NULL;
> spin_lock(&inode_lock);
> - old = find_inode_fast(sb, head, ino);
> - if (likely(!old)) {
> + hlist_for_each_entry(old, node, head, i_hash) {
> + if (old->i_ino != ino)
> + continue;
> + if (old->i_sb != sb)
> + continue;
> + if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> + continue;
> + break;
> + }
> + if (likely(!node)) {
> hlist_add_head(&inode->i_hash, head);
> spin_unlock(&inode_lock);
> return 0;
> @@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
> {
> struct super_block *sb = inode->i_sb;
> struct hlist_head *head = inode_hashtable + hash(sb, hashval);
> - struct inode *old;
>
> inode->i_state |= I_LOCK|I_NEW;
>
> while (1) {
> + struct hlist_node *node;
> + struct inode *old = NULL;
> +
> spin_lock(&inode_lock);
> - old = find_inode(sb, head, test, data);
> - if (likely(!old)) {
> + hlist_for_each_entry(old, node, head, i_hash) {
> + if (old->i_sb != sb)
> + continue;
> + if (!test(old, data))
> + continue;
> + if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> + continue;
> + break;
> + }
> + if (likely(!node)) {
> hlist_add_head(&inode->i_hash, head);
> spin_unlock(&inode_lock);
> return 0;
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-13 16:52 ` Al Viro
2009-05-13 18:13 ` Al Viro
@ 2009-05-18 12:53 ` Jan Kara
1 sibling, 0 replies; 50+ messages in thread
From: Jan Kara @ 2009-05-18 12:53 UTC (permalink / raw)
To: Al Viro; +Cc: bugzilla-daemon, linux-ext4
On Wed 13-05-09 17:52:54, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> > Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> > Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
>
> At which point do we actually run into deadlock on delete side? We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely. We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
The ordering we see on delete when the filesystem is mounted with 'sync'
option is:
DELETE CREATE
generic_delete_inode()
set I_FREEING
ext3_delete_inode
get transaction handle
do work
get transaction handle
ext3_new_inode()
reallocate inode
insert_inode_locked()
stop transaction, wait for it to commit
(waiting for CREATE process to drop its
transaction reference)
Now similar race can happen even without 'sync' mount option but it's
much harder to hit:
DELETE CREATE
generic_delete_inode()
set I_FREEING
ext3_delete_inode
get transaction handle
ext3_new_inode()
reallocate inode
insert_inode_locked()
try to get transaction handle -
- transaction is too big so we send
current transaction to commit which
again waits for CREATE to drop its
reference.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
2009-05-05 23:16 ` [Bug 13232] " bugzilla-daemon
2009-05-12 16:56 ` bugzilla-daemon
@ 2009-05-13 13:48 ` bugzilla-daemon
2009-05-13 16:07 ` bugzilla-daemon
` (12 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-13 13:48 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #3 from Jan Kara <jack@suse.cz> 2009-05-13 13:48:04 ---
> http://bugzilla.kernel.org/show_bug.cgi?id=13232
>
> --- Comment #2 from Jan Kara <jack@suse.cz> 2009-05-12 16:56:04 ---
> Hi,
>
> > (switched to email. Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
>
> > > SysRq : Show Blocked State
> > > task PC stack pid father
> > > kjournald D c01384df 0 2525 2
> > > cfcb5f0c 00000082 de27d500 c01384df cfcb5ef4 c02cb5c0 00000001 de32ca00
> > > de324814 dd037ebc de324814 de324934 dd037ebc cfcb5f5c cfcb5f90 c01bd4bb
> > > 00000046 c0424110 de324a0c de324814 de324800 00000000 00000002 dd037e80
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c01bd4bb>] journal_commit_transaction+0xea/0xeaf
> > > [<c02c534a>] ? _spin_unlock_irqrestore+0x38/0x3f
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c0122a25>] ? del_timer+0x50/0x59
> > > [<c01c0c75>] kjournald+0xad/0x1bb
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c01c0bc8>] ? kjournald+0x0/0x1bb
> > > [<c012b442>] kthread+0x37/0x59
> > > [<c012b40b>] ? kthread+0x0/0x59
> > > [<c0103667>] kernel_thread_helper+0x7/0x10
> >
> > I assume this is
> >
> > while (commit_transaction->t_updates) {
> > DEFINE_WAIT(wait);
> >
> > prepare_to_wait(&journal->j_wait_updates, &wait,
> > TASK_UNINTERRUPTIBLE);
> > if (commit_transaction->t_updates) {
> > spin_unlock(&commit_transaction->t_handle_lock);
> > spin_unlock(&journal->j_state_lock);
> > schedule();
> Yes.
>
> > I'm wondering about
> >
> > : commit e219cca082f52e7dfea41f3be264b7b5eb204227
> > : Author: Theodore Ts'o <tytso@mit.edu>
> > : AuthorDate: Thu Nov 6 22:37:59 2008 -0500
> > : Commit: Theodore Ts'o <tytso@mit.edu>
> > : CommitDate: Thu Nov 6 22:37:59 2008 -0500
> > :
> > : jbd: don't give up looking for space so easily in __log_wait_for_space
> >
> > but that patch was present in 2.6.28.
> Hmm, I don't see what made this deadlock happening - as far as I can
> see it's there for quite some time. See below...
>
> > > pickup D c01384df 0 2597 2594
> > > cfaa9e5c 00000086 df9faa80 c01384df cfaa9e44 00000282 cfaa9e74 de32ca00
> > > cfaa9e5c c012b8b7 00000002 de324800 0000014f cfaa9e74 cfaa9e94 c01c0539
> > > 00000000 de3248c8 de324910 de324814 00000000 df9faa80 c012b6ee de3248e4
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c012b8b7>] ? prepare_to_wait+0x42/0x4a
> > > [<c01c0539>] log_wait_commit+0x90/0xf7
> > > [<c012b6ee>] ? autoremove_wake_function+0x0/0x38
> > > [<c01bba9d>] journal_stop+0x1c8/0x288
> > > [<c01b4236>] __ext3_journal_stop+0x1c/0x38
> > > [<c01aeb96>] ext3_delete_inode+0x90/0xc2
> > > [<c01aeb06>] ? ext3_delete_inode+0x0/0xc2
> > > [<c017ab82>] generic_delete_inode+0x72/0x100
> > > [<c02c4ee1>] ? _spin_lock+0x3a/0x40
> > > [<c017ad4c>] generic_drop_inode+0x13c/0x1da
> > > [<c01d4068>] ? _atomic_dec_and_lock+0x10/0x38
> > > [<c017a4e7>] iput+0x47/0x4e
> > > [<c0173db0>] do_unlinkat+0xc1/0x137
> > > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c0173e36>] sys_unlink+0x10/0x12
> > > [<c0102f55>] sysenter_do_call+0x12/0x35
> In generic_delete_inode() we mark inode as I_FREEING. Then
> ext3_delete_inode() is called and because of O_SYNC it starts a
> transaction commit and waits for it.
>
> > > postdrop D c01384df 0 2664 2663
> > > cfcbfd6c 00000086 dd13f700 c01384df cfcbfd54 c02cb5c0 00000001 deedc780
> > > c03a1690 c1402348 c03a1690 cfcbfd7c c1402348 cfcbfd90 cfcbfd9c c017a55b
> > > dd758c48 00000007 00000000 dd13f700 c012b726 c1402364 c1402364 00152b13
> > > Call Trace:
> > > [<c01384df>] ? trace_hardirqs_on+0xb/0xd
> > > [<c017a55b>] __wait_on_freeing_inode+0x6d/0x88
> > > [<c012b726>] ? wake_bit_function+0x0/0x47
> > > [<c017a5b5>] find_inode_fast+0x3f/0x4a
> > > [<c017ba05>] insert_inode_locked+0x50/0xeb
> > > [<c01ab90b>] ext3_new_inode+0x738/0x88f
> > > [<c01bc550>] ? journal_start+0xab/0x100
> > > [<c01b259a>] ext3_create+0x59/0xbf
> > > [<c01722c4>] vfs_create+0x75/0xb0
> > > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > > [<c01b2541>] ? ext3_create+0x0/0xbf
> > > [<c0174bc3>] do_filp_open+0x644/0x713
> > > [<c02c4dda>] ? _spin_unlock+0x1d/0x20
> > > [<c01692ce>] do_sys_open+0x45/0xce
> > > [<c0102f87>] ? sysenter_exit+0xf/0x18
> > > [<c0138489>] ? trace_hardirqs_on_caller+0x145/0x190
> > > [<c01693a3>] sys_open+0x23/0x2b
> > > [<c0102f55>] sysenter_do_call+0x12/0x35
> Here, we have started a transaction in ext3_create() and then wait in
> find_inode_fast() for I_FREEING to be cleared (obviously we have
> reallocated the inode and squeezed the allocation before journal_stop()
> from the delete was called).
> Nasty deadlock and I don't see how to fix it now - have to go home for
> today... Tomorrow I'll have a look what we can do about it.
OK, the deadlock has been introduced by ext3 variant of
261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
is really tough to avoid - we have to first allocate inode on disk so
that we know the inode number. For this we need transaction open but we
cannot afford waiting for old inode with same INO to be freed when we have
transaction open because of the above deadlock. So we'd have to wait for
inode release only after everything is done and we closed the transaction. But
that would mean reordering a lot of code in ext3/namei.c so that all the
dcache handling is done after all the IO is done.
Hmm, maybe we could change the delete side of the deadlock but that's
going to be tricky as well :(.
Al, any idea if we could somehow get away without waiting on
I_FREEING?
Honza
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (2 preceding siblings ...)
2009-05-13 13:48 ` bugzilla-daemon
@ 2009-05-13 16:07 ` bugzilla-daemon
2009-05-13 16:18 ` bugzilla-daemon
` (11 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-13 16:07 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #4 from Theodore Tso <tytso@mit.edu> 2009-05-13 16:07:33 ---
On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
What do you mean by this?
I'm puzzled why we haven't hit this before. This looks like
long-standing issue; what unmasked it now?
> The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number.
Well, the simple thing to do is to have a way of quickly determining
that a particular inode number is in the I_FREEING state, and simply
try to avoid using that inode number. If there are no inodes
available, it can simply close the handle (since nothing else has
changed at that point), wait for the current transaction to close, and
then try again. That should fix the problem, I think.
- Ted
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (3 preceding siblings ...)
2009-05-13 16:07 ` bugzilla-daemon
@ 2009-05-13 16:18 ` bugzilla-daemon
2009-05-13 16:52 ` bugzilla-daemon
` (10 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-13 16:18 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Vincent Li <mchun.li@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mchun.li@gmail.com
--- Comment #5 from Vincent Li <mchun.li@gmail.com> 2009-05-13 16:18:57 ---
I tried to run Postfix on ubuntu 9.04 server version and followed the reporduce
command, had the same problem.
kernel version: 2.6.30-rc4
Distribution: Ubuntu 9.04
Software Environment: Postfix 2.5.1-2ubuntu1.2
also have following message poping up on control terminal:
[844,700070] INFO: task kjournald: 628 blocked for more than 120 seconds,
[844,700148] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
meassage.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (4 preceding siblings ...)
2009-05-13 16:18 ` bugzilla-daemon
@ 2009-05-13 16:52 ` bugzilla-daemon
2009-05-13 18:13 ` bugzilla-daemon
` (9 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-13 16:52 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #6 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org> 2009-05-13 16:52:56 ---
Reply-To: viro@ZenIV.linux.org.uk
On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > Here, we have started a transaction in ext3_create() and then wait in
> > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > reallocated the inode and squeezed the allocation before journal_stop()
> > from the delete was called).
> > Nasty deadlock and I don't see how to fix it now - have to go home for
> > today... Tomorrow I'll have a look what we can do about it.
> OK, the deadlock has been introduced by ext3 variant of
> 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> is really tough to avoid - we have to first allocate inode on disk so
> that we know the inode number. For this we need transaction open but we
> cannot afford waiting for old inode with same INO to be freed when we have
> transaction open because of the above deadlock. So we'd have to wait for
> inode release only after everything is done and we closed the transaction. But
> that would mean reordering a lot of code in ext3/namei.c so that all the
> dcache handling is done after all the IO is done.
> Hmm, maybe we could change the delete side of the deadlock but that's
> going to be tricky as well :(.
> Al, any idea if we could somehow get away without waiting on
> I_FREEING?
At which point do we actually run into deadlock on delete side? We could,
in principle, skip everything like that in insert_inode_locked(), but
I would rather avoid the "two inodes in icache at the same time, with the
same inumber" situations completely. We might get away with that, since
everything else *will* wait, so we can afford a bunch of inodes past the
point in foo_delete_inode() that has cleared it in bitmap + new locked
one, but if it's at all possible to avoid, I'd rather avoid it.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (5 preceding siblings ...)
2009-05-13 16:52 ` bugzilla-daemon
@ 2009-05-13 18:13 ` bugzilla-daemon
2009-05-18 12:45 ` bugzilla-daemon
` (8 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-13 18:13 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #7 from Anonymous Emailer <anonymous@kernel-bugs.osdl.org> 2009-05-13 18:13:42 ---
Reply-To: viro@ZenIV.linux.org.uk
On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> > Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> > Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
>
> At which point do we actually run into deadlock on delete side? We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely. We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
OK, that's probably the easiest way to do that, as much as I don't like it...
Since iget() et.al. will not accept I_FREEING (will wait to go away
and restart), and since we'd better have serialization between new/free
on fs data structures anyway, we can afford simply skipping I_FREEING
et.al. in insert_inode_locked().
We do that from new_inode, so it won't race with free_inode in any interesting
ways and it won't race with iget (of any origin; nfsd or in case of fs
corruption a lookup) since both still will wait for I_LOCK.
Tentative patch follow; folks, I would very much like review on that one,
since I'm far too low on caffeine and the area is nasty.
diff --git a/fs/inode.c b/fs/inode.c
index 9d26490..4406952 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
struct super_block *sb = inode->i_sb;
ino_t ino = inode->i_ino;
struct hlist_head *head = inode_hashtable + hash(sb, ino);
- struct inode *old;
inode->i_state |= I_LOCK|I_NEW;
while (1) {
+ struct hlist_node *node;
+ struct inode *old = NULL;
spin_lock(&inode_lock);
- old = find_inode_fast(sb, head, ino);
- if (likely(!old)) {
+ hlist_for_each_entry(old, node, head, i_hash) {
+ if (old->i_ino != ino)
+ continue;
+ if (old->i_sb != sb)
+ continue;
+ if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+ continue;
+ break;
+ }
+ if (likely(!node)) {
hlist_add_head(&inode->i_hash, head);
spin_unlock(&inode_lock);
return 0;
@@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned
long hashval,
{
struct super_block *sb = inode->i_sb;
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
- struct inode *old;
inode->i_state |= I_LOCK|I_NEW;
while (1) {
+ struct hlist_node *node;
+ struct inode *old = NULL;
+
spin_lock(&inode_lock);
- old = find_inode(sb, head, test, data);
- if (likely(!old)) {
+ hlist_for_each_entry(old, node, head, i_hash) {
+ if (old->i_sb != sb)
+ continue;
+ if (!test(old, data))
+ continue;
+ if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+ continue;
+ break;
+ }
+ if (likely(!node)) {
hlist_add_head(&inode->i_hash, head);
spin_unlock(&inode_lock);
return 0;
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply related [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (6 preceding siblings ...)
2009-05-13 18:13 ` bugzilla-daemon
@ 2009-05-18 12:45 ` bugzilla-daemon
2009-05-18 12:54 ` bugzilla-daemon
` (7 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-18 12:45 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #8 from Jan Kara <jack@suse.cz> 2009-05-18 12:45:23 ---
On Wed 13-05-09 12:07:24, Theodore Tso wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC).
>
> What do you mean by this?
>
> I'm puzzled why we haven't hit this before. This looks like
> long-standing issue; what unmasked it now?
Unless you mount the fs with 'sync' option, hitting this is much harder
(the window is quite small in nosync case). I think that is the main reason
why we didn't see this earlier.
> > The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number.
>
> Well, the simple thing to do is to have a way of quickly determining
> that a particular inode number is in the I_FREEING state, and simply
> try to avoid using that inode number. If there are no inodes
> available, it can simply close the handle (since nothing else has
> changed at that point), wait for the current transaction to close, and
> then try again. That should fix the problem, I think.
Yes, we could work-around it like that but other filesystems might need
similar things and generally it would be nicer if we could avoid using this
vfs-internal information in the filesystems. Al seems to have found some
other solution without changing filesystems so that would be easier for us...
Honza
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (7 preceding siblings ...)
2009-05-18 12:45 ` bugzilla-daemon
@ 2009-05-18 12:54 ` bugzilla-daemon
2009-05-18 13:16 ` bugzilla-daemon
` (6 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-18 12:54 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #9 from Jan Kara <jack@suse.cz> 2009-05-18 12:54:00 ---
On Wed 13-05-09 17:52:54, Al Viro wrote:
> On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > Here, we have started a transaction in ext3_create() and then wait in
> > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > reallocated the inode and squeezed the allocation before journal_stop()
> > > from the delete was called).
> > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > today... Tomorrow I'll have a look what we can do about it.
> > OK, the deadlock has been introduced by ext3 variant of
> > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > is really tough to avoid - we have to first allocate inode on disk so
> > that we know the inode number. For this we need transaction open but we
> > cannot afford waiting for old inode with same INO to be freed when we have
> > transaction open because of the above deadlock. So we'd have to wait for
> > inode release only after everything is done and we closed the transaction. But
> > that would mean reordering a lot of code in ext3/namei.c so that all the
> > dcache handling is done after all the IO is done.
> > Hmm, maybe we could change the delete side of the deadlock but that's
> > going to be tricky as well :(.
> > Al, any idea if we could somehow get away without waiting on
> > I_FREEING?
>
> At which point do we actually run into deadlock on delete side? We could,
> in principle, skip everything like that in insert_inode_locked(), but
> I would rather avoid the "two inodes in icache at the same time, with the
> same inumber" situations completely. We might get away with that, since
> everything else *will* wait, so we can afford a bunch of inodes past the
> point in foo_delete_inode() that has cleared it in bitmap + new locked
> one, but if it's at all possible to avoid, I'd rather avoid it.
The ordering we see on delete when the filesystem is mounted with 'sync'
option is:
DELETE CREATE
generic_delete_inode()
set I_FREEING
ext3_delete_inode
get transaction handle
do work
get transaction handle
ext3_new_inode()
reallocate inode
insert_inode_locked()
stop transaction, wait for it to commit
(waiting for CREATE process to drop its
transaction reference)
Now similar race can happen even without 'sync' mount option but it's
much harder to hit:
DELETE CREATE
generic_delete_inode()
set I_FREEING
ext3_delete_inode
get transaction handle
ext3_new_inode()
reallocate inode
insert_inode_locked()
try to get transaction handle -
- transaction is too big so we send
current transaction to commit which
again waits for CREATE to drop its
reference.
Honza
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (8 preceding siblings ...)
2009-05-18 12:54 ` bugzilla-daemon
@ 2009-05-18 13:16 ` bugzilla-daemon
2009-05-18 14:10 ` bugzilla-daemon
` (5 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-18 13:16 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #10 from Theodore Tso <tytso@mit.edu> 2009-05-18 13:16:04 ---
On Wed, May 13, 2009 at 07:13:40PM +0100, Al Viro wrote:
>
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
>
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
>
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
Sorry for not having time to review this until now. This looks good
to me.
Reviewed-by: "Theodore Ts'o" <tytso@mit.edu>
So Bug #13232 is currently marked as a 2.6.28 regression; do we feel
confident enough to push this to Linus for 2.6.30?
- Ted
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (9 preceding siblings ...)
2009-05-18 13:16 ` bugzilla-daemon
@ 2009-05-18 14:10 ` bugzilla-daemon
2009-05-19 20:38 ` bugzilla-daemon
` (4 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-18 14:10 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #11 from Jan Kara <jack@suse.cz> 2009-05-18 14:10:15 ---
On Wed 13-05-09 19:13:40, Al Viro wrote:
> On Wed, May 13, 2009 at 05:52:54PM +0100, Al Viro wrote:
> > On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote:
> > > > Here, we have started a transaction in ext3_create() and then wait in
> > > > find_inode_fast() for I_FREEING to be cleared (obviously we have
> > > > reallocated the inode and squeezed the allocation before journal_stop()
> > > > from the delete was called).
> > > > Nasty deadlock and I don't see how to fix it now - have to go home for
> > > > today... Tomorrow I'll have a look what we can do about it.
> > > OK, the deadlock has been introduced by ext3 variant of
> > > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). The deadlock
> > > is really tough to avoid - we have to first allocate inode on disk so
> > > that we know the inode number. For this we need transaction open but we
> > > cannot afford waiting for old inode with same INO to be freed when we have
> > > transaction open because of the above deadlock. So we'd have to wait for
> > > inode release only after everything is done and we closed the transaction. But
> > > that would mean reordering a lot of code in ext3/namei.c so that all the
> > > dcache handling is done after all the IO is done.
> > > Hmm, maybe we could change the delete side of the deadlock but that's
> > > going to be tricky as well :(.
> > > Al, any idea if we could somehow get away without waiting on
> > > I_FREEING?
> >
> > At which point do we actually run into deadlock on delete side? We could,
> > in principle, skip everything like that in insert_inode_locked(), but
> > I would rather avoid the "two inodes in icache at the same time, with the
> > same inumber" situations completely. We might get away with that, since
> > everything else *will* wait, so we can afford a bunch of inodes past the
> > point in foo_delete_inode() that has cleared it in bitmap + new locked
> > one, but if it's at all possible to avoid, I'd rather avoid it.
>
> OK, that's probably the easiest way to do that, as much as I don't like it...
> Since iget() et.al. will not accept I_FREEING (will wait to go away
> and restart), and since we'd better have serialization between new/free
> on fs data structures anyway, we can afford simply skipping I_FREEING
> et.al. in insert_inode_locked().
>
> We do that from new_inode, so it won't race with free_inode in any interesting
> ways and it won't race with iget (of any origin; nfsd or in case of fs
> corruption a lookup) since both still will wait for I_LOCK.
>
> Tentative patch follow; folks, I would very much like review on that one,
> since I'm far too low on caffeine and the area is nasty.
The patch looks fine. Everyone else will either get new inode and wait
for I_LOCK or get old inode and wait for I_FREEING so everything should be
fine... You can add.
Acked-by: Jan Kara <jack@suse.cz>
Honza
>
> diff --git a/fs/inode.c b/fs/inode.c
> index 9d26490..4406952 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1053,13 +1053,22 @@ int insert_inode_locked(struct inode *inode)
> struct super_block *sb = inode->i_sb;
> ino_t ino = inode->i_ino;
> struct hlist_head *head = inode_hashtable + hash(sb, ino);
> - struct inode *old;
>
> inode->i_state |= I_LOCK|I_NEW;
> while (1) {
> + struct hlist_node *node;
> + struct inode *old = NULL;
> spin_lock(&inode_lock);
> - old = find_inode_fast(sb, head, ino);
> - if (likely(!old)) {
> + hlist_for_each_entry(old, node, head, i_hash) {
> + if (old->i_ino != ino)
> + continue;
> + if (old->i_sb != sb)
> + continue;
> + if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> + continue;
> + break;
> + }
> + if (likely(!node)) {
> hlist_add_head(&inode->i_hash, head);
> spin_unlock(&inode_lock);
> return 0;
> @@ -1081,14 +1090,24 @@ int insert_inode_locked4(struct inode *inode, unsigned long hashval,
> {
> struct super_block *sb = inode->i_sb;
> struct hlist_head *head = inode_hashtable + hash(sb, hashval);
> - struct inode *old;
>
> inode->i_state |= I_LOCK|I_NEW;
>
> while (1) {
> + struct hlist_node *node;
> + struct inode *old = NULL;
> +
> spin_lock(&inode_lock);
> - old = find_inode(sb, head, test, data);
> - if (likely(!old)) {
> + hlist_for_each_entry(old, node, head, i_hash) {
> + if (old->i_sb != sb)
> + continue;
> + if (!test(old, data))
> + continue;
> + if (old->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
> + continue;
> + break;
> + }
> + if (likely(!node)) {
> hlist_add_head(&inode->i_hash, head);
> spin_unlock(&inode_lock);
> return 0;
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (10 preceding siblings ...)
2009-05-18 14:10 ` bugzilla-daemon
@ 2009-05-19 20:38 ` bugzilla-daemon
2009-05-19 20:39 ` bugzilla-daemon
` (3 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-19 20:38 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
--- Comment #12 from Theodore Tso <tytso@mit.edu> 2009-05-19 20:38:32 ---
Created an attachment (id=21436)
--> (http://bugzilla.kernel.org/attachment.cgi?id=21436)
Proposed patch from Al Viro
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (11 preceding siblings ...)
2009-05-19 20:38 ` bugzilla-daemon
@ 2009-05-19 20:39 ` bugzilla-daemon
2009-06-07 19:56 ` bugzilla-daemon
` (2 subsequent siblings)
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-05-19 20:39 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Theodore Tso <tytso@mit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #21436|application/octet-stream |text/plain
mime type| |
Attachment #21436|0 |1
is patch| |
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (12 preceding siblings ...)
2009-05-19 20:39 ` bugzilla-daemon
@ 2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 20:44 ` bugzilla-daemon
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-06-07 19:56 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Theodore Tso <tytso@mit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tytso@mit.edu
--- Comment #13 from Theodore Tso <tytso@mit.edu> 2009-06-07 19:56:04 ---
This patch is now in the upstream kernel, so it will be in 2.6.30.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (13 preceding siblings ...)
2009-06-07 19:56 ` bugzilla-daemon
@ 2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 20:44 ` bugzilla-daemon
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-06-07 19:56 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Theodore Tso <tytso@mit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |CODE_FIX
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread* [Bug 13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
` (14 preceding siblings ...)
2009-06-07 19:56 ` bugzilla-daemon
@ 2009-06-07 20:44 ` bugzilla-daemon
15 siblings, 0 replies; 50+ messages in thread
From: bugzilla-daemon @ 2009-06-07 20:44 UTC (permalink / raw)
To: linux-ext4
http://bugzilla.kernel.org/show_bug.cgi?id=13232
Rafael J. Wysocki <rjw@sisk.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 50+ messages in thread
* 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29
@ 2009-05-16 19:58 Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 19:58 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.28 and
2.6.29, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.28
and 2.6.29, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-05-17 162 27 25
2009-04-26 160 29 27
2009-04-06 142 37 31
2009-03-21 128 29 26
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13271
Subject : ath9k stop working since 2.6.29
Submitter : lyman <lymanrb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-05-10 01:58 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric-x1Cn44Nr1HaZIoH1IeqzKA@public.gmane.org>
Date : 2009-05-08 08:48 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date : 2009-05-03 19:46 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem-VInPYn6yXxRWk0Htik3J/w@public.gmane.org>
Date : 2009-05-02 21:41 (15 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13183
Subject : forcedeth: no link during initialization
Submitter : Harald Dunkel <harald.dunkel-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
Date : 2009-04-23 13:02 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124049180309233&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
Date : 2009-04-24 12:45 (23 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13175
Subject : sata_nv incompatible with async scsi scan
Submitter : Benny Halevy <bhalevy-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
Date : 2009-04-21 7:03 (26 days old)
References : http://marc.info/?l=linux-kernel&m=124029746431777&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13172
Subject : Spontaneous reboots since 2.6.29-rc*
Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-17 17:03 (30 days old)
References : http://marc.info/?l=linux-kernel&m=123998788921733&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights-97jfqw80gc6171pxa8y+qA@public.gmane.org>
Date : 2009-04-21 17:03 (26 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-06 23:52 (41 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias-fd97jBR+K/6SGgWmA85PRw@public.gmane.org>
Date : 2009-04-12 14:10 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt-Mmb7MZpHnFY@public.gmane.org>
Date : 2009-04-12 07:00 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-06 19:47 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark-pwcEARUeV57PDbFq/vQRIQ@public.gmane.org>
Date : 2009-04-06 19:12 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-04-03 09:30 (44 days old)
References : http://lkml.org/lkml/2009/4/28/133
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus-sJr3legBufCzQB+pC5nmwQ@public.gmane.org>
Date : 2009-03-31 08:58 (47 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-03-29 18:02 (49 days old)
Handled-By : Matt Carlson <mcarlson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject : r128: system hangs when X is started with DRI enabled
Submitter : Jos van der Ende <seraph-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Date : 2009-03-26 16:14 (52 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org>
Date : 2009-03-16 10:25 (62 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann-opNxpl+3fjRBDgjK7y7TUQ@public.gmane.org>
Date : 2009-03-20 07:13 (58 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12861
Subject : Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter : Emil Karlson <jkarlson-kf+aQKke1yb1KXRcyAk9cg@public.gmane.org>
Date : 2009-03-12 12:06 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab657db12d7020629f26f30d287558a8d0e32b41
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
Date : 2009-02-13 9:33 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj-5URONGGNgjI@public.gmane.org>
Date : 2009-02-09 13:01 (97 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy-l3A5Bk7waGM@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-13 18:34 (124 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Handled-By : Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-12 7:38 (125 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me-aXfl/3sk2vNUbtYUoyoikg@public.gmane.org>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
Subject : cpufreq timer teardown problem
Submitter : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Date : 2009-04-23 14:00 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/19754/
http://patchwork.kernel.org/patch/19753/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date : 2009-02-21 15:38 (85 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/20197/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.28 and 2.6.29, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-16 19:58 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 2.6.29. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date : 2009-05-03 19:46 (14 days old)
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-16 20:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2009-05-16 20:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 2.6.29. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (14 days old)
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-16 20:06 ` Rafael J. Wysocki
@ 2009-05-18 13:25 ` Theodore Tso
-1 siblings, 0 replies; 50+ messages in thread
From: Theodore Tso @ 2009-05-18 13:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Watson
On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject : ext3/4 with synchronous writes gets wedged by Postfix
> Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> Date : 2009-05-03 19:46 (14 days old)
This turned out to be caused by change in the VFS, as documented in
the bug report. Al Viro has a patch, which I've reviewed.
David, would you be able to try testing Al's proposed patch, since you
have an easy reproduction case? Thanks,
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-18 13:25 ` Theodore Tso
0 siblings, 0 replies; 50+ messages in thread
From: Theodore Tso @ 2009-05-18 13:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Watson
On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject : ext3/4 with synchronous writes gets wedged by Postfix
> Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> Date : 2009-05-03 19:46 (14 days old)
This turned out to be caused by change in the VFS, as documented in
the bug report. Al Viro has a patch, which I've reviewed.
David, would you be able to try testing Al's proposed patch, since you
have an easy reproduction case? Thanks,
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
[parent not found: <20090518132517.GL32019-3s7WtUTddSA@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-18 13:25 ` Theodore Tso
@ 2009-05-19 17:17 ` David Watson
-1 siblings, 0 replies; 50+ messages in thread
From: David Watson @ 2009-05-19 17:17 UTC (permalink / raw)
To: Theodore Tso, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
On Mon 18 May 2009, Theodore Tso wrote:
> On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > Date : 2009-05-03 19:46 (14 days old)
>
> This turned out to be caused by change in the VFS, as documented in
> the bug report. Al Viro has a patch, which I've reviewed.
>
> David, would you be able to try testing Al's proposed patch, since you
> have an easy reproduction case? Thanks,
Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-19 17:17 ` David Watson
0 siblings, 0 replies; 50+ messages in thread
From: David Watson @ 2009-05-19 17:17 UTC (permalink / raw)
To: Theodore Tso, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
On Mon 18 May 2009, Theodore Tso wrote:
> On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > Date : 2009-05-03 19:46 (14 days old)
>
> This turned out to be caused by change in the VFS, as documented in
> the bug report. Al Viro has a patch, which I've reviewed.
>
> David, would you be able to try testing Al's proposed patch, since you
> have an easy reproduction case? Thanks,
Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
^ permalink raw reply [flat|nested] 50+ messages in thread
[parent not found: <20090519171713.GA3354-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-19 17:17 ` David Watson
@ 2009-05-19 17:53 ` Theodore Tso
-1 siblings, 0 replies; 50+ messages in thread
From: Theodore Tso @ 2009-05-19 17:53 UTC (permalink / raw)
To: David Watson, Al Viro
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Tue, May 19, 2009 at 06:17:13PM +0100, David Watson wrote:
> On Mon 18 May 2009, Theodore Tso wrote:
> > On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > > Date : 2009-05-03 19:46 (14 days old)
> >
> > This turned out to be caused by change in the VFS, as documented in
> > the bug report. Al Viro has a patch, which I've reviewed.
> >
> > David, would you be able to try testing Al's proposed patch, since you
> > have an easy reproduction case? Thanks,
>
> Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
Thanks, David.
Al, Jan Kara and I have reviewed your patch, and we can add a
Tested-by: from David Watson (assuming David, you don't mind your name
or e-mail address showing up in the Kernel commit logs --- if you want
us to suppress one or both, please let us know). Given this is a
2.6.28 regression, and this can certainly affect real-life users, I
think we should push your patch to Linus for 2.6.30. Do you agree?
Regards,
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-05-19 17:53 ` Theodore Tso
0 siblings, 0 replies; 50+ messages in thread
From: Theodore Tso @ 2009-05-19 17:53 UTC (permalink / raw)
To: David Watson, Al Viro
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Tue, May 19, 2009 at 06:17:13PM +0100, David Watson wrote:
> On Mon 18 May 2009, Theodore Tso wrote:
> > On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > > Date : 2009-05-03 19:46 (14 days old)
> >
> > This turned out to be caused by change in the VFS, as documented in
> > the bug report. Al Viro has a patch, which I've reviewed.
> >
> > David, would you be able to try testing Al's proposed patch, since you
> > have an easy reproduction case? Thanks,
>
> Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
Thanks, David.
Al, Jan Kara and I have reviewed your patch, and we can add a
Tested-by: from David Watson (assuming David, you don't mind your name
or e-mail address showing up in the Kernel commit logs --- if you want
us to suppress one or both, please let us know). Given this is a
2.6.28 regression, and this can certainly affect real-life users, I
think we should push your patch to Linus for 2.6.30. Do you agree?
Regards,
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-05-19 17:53 ` Theodore Tso
(?)
@ 2009-05-19 18:27 ` John Stoffel
[not found] ` <18962.64002.324970.49512-HgN6juyGXH5AfugRpC6u6w@public.gmane.org>
-1 siblings, 1 reply; 50+ messages in thread
From: John Stoffel @ 2009-05-19 18:27 UTC (permalink / raw)
To: Theodore Tso
Cc: David Watson, Al Viro, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
>>>>> "Theodore" == Theodore Tso <tytso@mit.edu> writes:
Theodore> On Tue, May 19, 2009 at 06:17:13PM +0100, David Watson wrote:
>> On Mon 18 May 2009, Theodore Tso wrote:
>> > On Sat, May 16, 2009 at 10:06:04PM +0200, Rafael J. Wysocki wrote:
>> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
>> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
>> > > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
>> > > Date : 2009-05-03 19:46 (14 days old)
>> >
>> > This turned out to be caused by change in the VFS, as documented in
>> > the bug report. Al Viro has a patch, which I've reviewed.
>> >
>> > David, would you be able to try testing Al's proposed patch, since you
>> > have an easy reproduction case? Thanks,
>>
>> Yes, it fixes the problem for me on 2.6.30-rc6-git3 and 2.6.29.4-rc1.
Theodore> Al, Jan Kara and I have reviewed your patch, and we can add
Theodore> a Tested-by: from David Watson (assuming David, you don't
Theodore> mind your name or e-mail address showing up in the Kernel
Theodore> commit logs --- if you want us to suppress one or both,
Theodore> please let us know). Given this is a 2.6.28 regression, and
Theodore> this can certainly affect real-life users, I think we should
Theodore> push your patch to Linus for 2.6.30. Do you agree?
I wonder if this is the reason my main file server has been locking up
solid under 2.6.29 or newer kernels lately, but 2.6.28 is rock solid.
Since it's my main file server at home, and with my home dir NFS
mounted from it onto another system, it's been hard to catch. I spent
some time fiddling around getting netconsole setup, but then I ran out
of time.
My system is a Debian, pretty upto date, PIII, 550Mhz Dual CPU, 3Gb
RAM, lots of SCSI, SATA and IDE busses, with various types of devices
on all the busses, from DLT tape drive and library, to a mix of disks.
I'm also running ext4 on a mirrored pair disks I use for spooling
backups to tape from. Ext3 on the rest of my mirrored filesystems as
well.
If someone could send me the patch, I'll apply it and see how well
2.6.29.[34] works, and whether or not 2.6.30-rcN works as well.
Reproducing the problem was pretty easy for me.
Thanks,
John
^ permalink raw reply [flat|nested] 50+ messages in thread
* 2.6.30-rc7: Reported regressions 2.6.28 -> 2.6.29
@ 2009-05-24 19:27 Rafael J. Wysocki
2009-05-24 19:31 ` Rafael J. Wysocki
0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2009-05-24 19:27 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.28 and
2.6.29, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.28
and 2.6.29, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-05-25 165 27 25
2009-05-17 162 27 25
2009-04-26 160 29 27
2009-04-06 142 37 31
2009-03-21 128 29 26
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject : Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter : Alex Samad <alex@samad.com.au>
Date : 2009-05-20 0:37 (5 days old)
References : http://marc.info/?l=linux-kernel&m=124278675503699&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject : s2disk hangs with kernel 2.6.29 and later, SATA, Gigabyte EG45M-DS2H
Submitter : Richard Atterer <richard@2009.atterer.net>
Date : 2009-05-16 22:51 (9 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=295f00042aaf6b553b5f37348f89bab463d4a469
References : http://marc.info/?l=linux-kernel&m=124251446428166&w=4
Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject : i915: drm: xorg leaks drm objects massively
Submitter : Sergei Trofimovich <slyich@gmail.com>
Date : 2009-05-10 19:56 (15 days old)
References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13271
Subject : ath9k stop working since 2.6.29
Submitter : lyman <lymanrb@gmail.com>
Date : 2009-05-10 01:58 (15 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric@belbone.be>
Date : 2009-05-08 08:48 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2009-05-02 21:41 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13183
Subject : forcedeth: no link during initialization
Submitter : Harald Dunkel <harald.dunkel@t-online.de>
Date : 2009-04-23 13:02 (32 days old)
References : http://marc.info/?l=linux-kernel&m=124049180309233&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap@knobisoft.de>
Date : 2009-04-24 12:45 (31 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13175
Subject : sata_nv incompatible with async scsi scan
Submitter : Benny Halevy <bhalevy@panasas.com>
Date : 2009-04-21 7:03 (34 days old)
References : http://marc.info/?l=linux-kernel&m=124029746431777&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights@fastmail.fm>
Date : 2009-04-21 17:03 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Date : 2009-04-06 23:52 (49 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias@archlinux-br.org>
Date : 2009-04-12 14:10 (43 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt@gmx.de>
Date : 2009-04-12 07:00 (43 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov@gmail.com>
Date : 2009-04-06 19:47 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark@hell.ne.jp>
Date : 2009-04-06 19:12 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd@gmail.com>
Date : 2009-04-03 09:30 (52 days old)
References : http://lkml.org/lkml/2009/4/28/133
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus@better.se>
Date : 2009-03-31 08:58 (55 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666@gmail.com>
Date : 2009-03-29 18:02 (57 days old)
Handled-By : Matt Carlson <mcarlson@broadcom.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject : r128: system hangs when X is started with DRI enabled
Submitter : Jos van der Ende <seraph@xs4all.nl>
Date : 2009-03-26 16:14 (60 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat@zip.com.au>
Date : 2009-03-16 10:25 (70 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann@secunet.com>
Date : 2009-03-20 07:13 (66 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213@schottelius.org>
Date : 2009-02-13 9:33 (101 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric@anholt.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj@bk.ru>
Date : 2009-02-09 13:01 (105 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (133 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me@bobcopeland.com>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
Subject : cpufreq timer teardown problem
Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date : 2009-04-23 14:00 (32 days old)
References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Patch : http://patchwork.kernel.org/patch/19754/
http://patchwork.kernel.org/patch/19753/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
Date : 2009-02-21 15:38 (93 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://patchwork.kernel.org/patch/20197/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.28 and 2.6.29, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 50+ messages in thread
* 2.6.30-rc7-git4: Reported regressions 2.6.28 -> 2.6.29
@ 2009-05-30 19:50 Rafael J. Wysocki
2009-05-30 19:55 ` Rafael J. Wysocki
0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2009-05-30 19:50 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List,
Natalie Protasevich, Linux ACPI, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List
This message contains a list of some regressions introduced between 2.6.28 and
2.6.29, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.28
and 2.6.29, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-05-31 167 27 26
2009-05-25 165 27 25
2009-05-17 162 27 25
2009-04-26 160 29 27
2009-04-06 142 37 31
2009-03-21 128 29 26
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject : Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter : Alex Samad <alex@samad.com.au>
Date : 2009-05-20 0:37 (11 days old)
References : http://marc.info/?l=linux-kernel&m=124278675503699&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject : s2disk hangs with kernel 2.6.29 and later, SATA, Gigabyte EG45M-DS2H
Submitter : Richard Atterer <richard@2009.atterer.net>
Date : 2009-05-16 22:51 (15 days old)
References : http://marc.info/?l=linux-kernel&m=124251446428166&w=4
http://lkml.org/lkml/2009/5/25/253
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject : rtable leak in ipv4/route.c
Submitter : Alexander V. Lukyanov <lav@yar.ru>
Date : 2009-05-18 14:10 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject : i915: drm: xorg leaks drm objects massively
Submitter : Sergei Trofimovich <slyich@gmail.com>
Date : 2009-05-10 19:56 (21 days old)
References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric@belbone.be>
Date : 2009-05-08 08:48 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2009-05-02 21:41 (29 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap@knobisoft.de>
Date : 2009-04-24 12:45 (37 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13175
Subject : initrd fails to find /dev/sda* (sata_nv)
Submitter : Benny Halevy <bhalevy@panasas.com>
Date : 2009-04-21 7:03 (40 days old)
References : http://marc.info/?l=linux-kernel&m=124029746431777&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13148
Subject : resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
Submitter : fanderay <fanderay4@googlemail.com>
Date : 2009-04-22 14:39 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights@fastmail.fm>
Date : 2009-04-21 17:03 (40 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Date : 2009-04-06 23:52 (55 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias@archlinux-br.org>
Date : 2009-04-12 14:10 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt@gmx.de>
Date : 2009-04-12 07:00 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov@gmail.com>
Date : 2009-04-06 19:47 (55 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark@hell.ne.jp>
Date : 2009-04-06 19:12 (55 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13017
Subject : ATA bus errors on resume
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-03-25 5:19 (67 days old)
References : http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By : Tejun Heo <htejun@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd@gmail.com>
Date : 2009-04-03 09:30 (58 days old)
References : http://lkml.org/lkml/2009/4/28/133
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus@better.se>
Date : 2009-03-31 08:58 (61 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666@gmail.com>
Date : 2009-03-29 18:02 (63 days old)
Handled-By : Matt Carlson <mcarlson@broadcom.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject : r128: system hangs when X is started with DRI enabled
Submitter : Jos van der Ende <seraph@xs4all.nl>
Date : 2009-03-26 16:14 (66 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat@zip.com.au>
Date : 2009-03-16 10:25 (76 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann@secunet.com>
Date : 2009-03-20 07:13 (72 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213@schottelius.org>
Date : 2009-02-13 9:33 (107 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric@anholt.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj@bk.ru>
Date : 2009-02-09 13:01 (111 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (139 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me@bobcopeland.com>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
Date : 2009-02-21 15:38 (99 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://patchwork.kernel.org/patch/20197/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.28 and 2.6.29, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 50+ messages in thread
* 2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29
@ 2009-06-07 10:02 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
0 siblings, 1 reply; 50+ messages in thread
From: Rafael J. Wysocki @ 2009-06-07 10:02 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List,
Natalie Protasevich, Linux ACPI, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List
This message contains a list of some regressions introduced between 2.6.28 and
2.6.29, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.28
and 2.6.29, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-06-07 169 27 25
2009-05-31 167 27 26
2009-05-25 165 27 25
2009-05-17 162 27 25
2009-04-26 160 29 27
2009-04-06 142 37 31
2009-03-21 128 29 26
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13463
Subject : Poor SSD performance
Submitter : Jake <ellowitz@uchicago.edu>
Date : 2009-06-05 17:37 (3 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13411
Subject : Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28
Submitter : Guido <bugzilla.kernel.org@starbase12.cjb.net>
Date : 2009-05-31 12:21 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13375
Subject : Kernel crash with 2.6.29 + nfs + xfs (radix-tree)
Submitter : Alex Samad <alex@samad.com.au>
Date : 2009-05-20 0:37 (19 days old)
References : http://marc.info/?l=linux-kernel&m=124278675503699&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13371
Subject : s2disk hangs with e100, kernel 2.6.29 and later
Submitter : Richard Atterer <richard@2009.atterer.net>
Date : 2009-05-16 22:51 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=Unknown
References : http://marc.info/?l=linux-kernel&m=124251446428166&w=4
http://lkml.org/lkml/2009/5/25/253
Handled-By : Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13339
Subject : rtable leak in ipv4/route.c
Submitter : Alexander V. Lukyanov <lav@yar.ru>
Date : 2009-05-18 14:10 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13294
Subject : i915: drm: xorg leaks drm objects massively
Submitter : Sergei Trofimovich <slyich@gmail.com>
Date : 2009-05-10 19:56 (29 days old)
References : http://marc.info/?l=linux-kernel&m=124198547027903&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13269
Subject : WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming
Submitter : cedric <cedric@belbone.be>
Date : 2009-05-08 08:48 (31 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13225
Subject : [2.6.29 regression] Software suspend no longer works
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2009-05-02 21:41 (37 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13178
Subject : Booting very slow
Submitter : Martin Knoblauch <spamtrap@knobisoft.de>
Date : 2009-04-24 12:45 (45 days old)
References : http://marc.info/?l=linux-kernel&m=124057716231773&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13148
Subject : resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present
Submitter : fanderay <fanderay4@googlemail.com>
Date : 2009-04-22 14:39 (47 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13144
Subject : resume from suspend fails using video card i915
Submitter : C Sights <csights@fastmail.fm>
Date : 2009-04-21 17:03 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13100
Subject : can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Date : 2009-04-06 23:52 (63 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0d4922da2e4ccb0973095d8d29f36f6b1b5f703
References : http://marc.info/?l=linux-kernel&m=123906202829074&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13074
Subject : gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840)
Submitter : Paulo Matias <matias@archlinux-br.org>
Date : 2009-04-12 14:10 (57 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13072
Subject : forcedeth seems to switch off eth on shutdown
Submitter : Daniel Bierstedt <daniel.bierstedt@gmx.de>
Date : 2009-04-12 07:00 (57 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13025
Subject : After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error
Submitter : Yaroslav Isakov <yaroslav.isakov@gmail.com>
Date : 2009-04-06 19:47 (63 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13024
Subject : nozomi: pppd fails on kernel 2.6.29
Submitter : Mark Karpeles <mark@hell.ne.jp>
Date : 2009-04-06 19:12 (63 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13017
Subject : ATA bus errors on resume
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-03-25 5:19 (75 days old)
References : http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By : Tejun Heo <htejun@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject : PCI-DMA: Out of IOMMU space
Submitter : <optimusgd@gmail.com>
Date : 2009-04-03 09:30 (66 days old)
References : http://lkml.org/lkml/2009/4/28/133
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject : lockup in X.org
Submitter : Marcus Better <marcus@better.se>
Date : 2009-03-31 08:58 (69 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject : "tg3 transmit timed out" when transmitting at high bitrate
Submitter : Nikolay <dobrev666@gmail.com>
Date : 2009-03-29 18:02 (71 days old)
Handled-By : Matt Carlson <mcarlson@broadcom.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject : boot/kernel init duration regression from 2.6.28
Submitter : CaT <cat@zip.com.au>
Date : 2009-03-16 10:25 (84 days old)
References : http://marc.info/?l=linux-kernel&m=123720083515950&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject : Crash in i915.ko: i915_driver_irq_handler
Submitter : Helge Bahmann <helge.bahmann@secunet.com>
Date : 2009-03-20 07:13 (80 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <nico-linux-20090213@schottelius.org>
Date : 2009-02-13 9:33 (115 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Eric Anholt <eric@anholt.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <smpuj@bk.ru>
Date : 2009-02-09 13:01 (119 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <sitsofe@yahoo.com>
Date : 2009-02-21 15:38 (107 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
http://lkml.org/lkml/2009/4/27/317
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://patchwork.kernel.org/patch/20197/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (147 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
http://lkml.org/lkml/2009/4/6/527
Handled-By : Bob Copeland <me@bobcopeland.com>
Patch : http://patchwork.kernel.org/patch/28210/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.28 and 2.6.29, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-06-07 10:02 2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
@ 2009-06-07 10:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson,
Jan Kara
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 2.6.29. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
Date : 2009-05-03 19:46 (36 days old)
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 10:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 50+ messages in thread
From: Rafael J. Wysocki @ 2009-06-07 10:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Author: Theodore Ts'o, David Watson,
Jan Kara
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.28 and 2.6.29.
The following bug entry is on the current list of known regressions
introduced between 2.6.28 and 2.6.29. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
Subject : ext3/4 with synchronous writes gets wedged by Postfix
Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
Date : 2009-05-03 19:46 (36 days old)
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-06-07 10:06 ` Rafael J. Wysocki
@ 2009-06-07 17:14 ` Theodore Tso
-1 siblings, 0 replies; 50+ messages in thread
From: Theodore Tso @ 2009-06-07 17:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Watson,
Jan Kara, bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject : ext3/4 with synchronous writes gets wedged by Postfix
> Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> Date : 2009-05-03 19:46 (36 days old)
Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
wedged by Postfix". I pinged Al previously about pushing this as a
regression fix for 2.6.30, but never got a response. At this point we
might as well wait for it to go into the 2.6.31 merge window, and then
we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 17:14 ` Theodore Tso
0 siblings, 0 replies; 50+ messages in thread
From: Theodore Tso @ 2009-06-07 17:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Watson,
Jan Kara, bugzilla-daemon
On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> Subject : ext3/4 with synchronous writes gets wedged by Postfix
> Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> Date : 2009-05-03 19:46 (36 days old)
Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
wedged by Postfix". I pinged Al previously about pushing this as a
regression fix for 2.6.30, but never got a response. At this point we
might as well wait for it to go into the 2.6.31 merge window, and then
we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread[parent not found: <20090607171418.GA22756-3s7WtUTddSA@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-06-07 17:14 ` Theodore Tso
@ 2009-06-07 17:17 ` Al Viro
-1 siblings, 0 replies; 50+ messages in thread
From: Al Viro @ 2009-06-07 17:17 UTC (permalink / raw)
To: Theodore Tso, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, David
On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > Date : 2009-05-03 19:46 (36 days old)
>
> Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> wedged by Postfix". I pinged Al previously about pushing this as a
> regression fix for 2.6.30, but never got a response. At this point we
> might as well wait for it to go into the 2.6.31 merge window, and then
> we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
It's in mainline now, actually. But yes, we need it in -stable as well.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 17:17 ` Al Viro
0 siblings, 0 replies; 50+ messages in thread
From: Al Viro @ 2009-06-07 17:17 UTC (permalink / raw)
To: Theodore Tso, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, David Watson, Jan Kara, bugzilla-daemon
On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.28 and 2.6.29.
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > Date : 2009-05-03 19:46 (36 days old)
>
> Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> wedged by Postfix". I pinged Al previously about pushing this as a
> regression fix for 2.6.30, but never got a response. At this point we
> might as well wait for it to go into the 2.6.31 merge window, and then
> we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
It's in mainline now, actually. But yes, we need it in -stable as well.
^ permalink raw reply [flat|nested] 50+ messages in thread
[parent not found: <20090607171739.GI8633-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>]
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
2009-06-07 17:17 ` Al Viro
@ 2009-06-07 20:10 ` Theodore Tso
-1 siblings, 0 replies; 50+ messages in thread
From: Theodore Tso @ 2009-06-07 20:10 UTC (permalink / raw)
To: Al Viro
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
David Watson, Jan Kara,
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
On Sun, Jun 07, 2009 at 06:17:39PM +0100, Al Viro wrote:
> On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> > On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.28 and 2.6.29.
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter : David Watson <kernel-nospam-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
> > > Date : 2009-05-03 19:46 (36 days old)
> >
> > Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> > tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> > wedged by Postfix". I pinged Al previously about pushing this as a
> > regression fix for 2.6.30, but never got a response. At this point we
> > might as well wait for it to go into the 2.6.31 merge window, and then
> > we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
>
> It's in mainline now, actually. But yes, we need it in -stable as well.
Great, thanks; sorry, I didn't realize it had been queued for mainline
submisison, and it wasn't there when I looked last week. I've closed
the bugzilla entry since it is now in mainline. Would you like to
send the patch to stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, or shall I?
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix
@ 2009-06-07 20:10 ` Theodore Tso
0 siblings, 0 replies; 50+ messages in thread
From: Theodore Tso @ 2009-06-07 20:10 UTC (permalink / raw)
To: Al Viro
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
David Watson, Jan Kara, bugzilla-daemon
On Sun, Jun 07, 2009 at 06:17:39PM +0100, Al Viro wrote:
> On Sun, Jun 07, 2009 at 01:14:18PM -0400, Theodore Tso wrote:
> > On Sun, Jun 07, 2009 at 12:06:22PM +0200, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.28 and 2.6.29.
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13232
> > > Subject : ext3/4 with synchronous writes gets wedged by Postfix
> > > Submitter : David Watson <kernel-nospam@dbwatson.ukfsn.org>
> > > Date : 2009-05-03 19:46 (36 days old)
> >
> > Al Viro has the fix for this in the for-next branch of his vfs-2.6 git
> > tree, as commit ID 72a43d63: "ext3/4 with synchronous writes gets
> > wedged by Postfix". I pinged Al previously about pushing this as a
> > regression fix for 2.6.30, but never got a response. At this point we
> > might as well wait for it to go into the 2.6.31 merge window, and then
> > we can ask for it to go into the 2.6.30.y and 2.6.29.y stable trees.
>
> It's in mainline now, actually. But yes, we need it in -stable as well.
Great, thanks; sorry, I didn't realize it had been queued for mainline
submisison, and it wasn't there when I looked last week. I've closed
the bugzilla entry since it is now in mainline. Would you like to
send the patch to stable@kernel.org, or shall I?
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2009-06-07 20:44 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-05 21:58 [Bug 13232] New: ext3/4 with synchronous writes gets wedged by Postfix bugzilla-daemon
2009-05-05 23:16 ` [Bug 13232] " bugzilla-daemon
2009-05-12 16:56 ` bugzilla-daemon
2009-05-13 13:48 ` Jan Kara
2009-05-13 16:07 ` Theodore Tso
2009-05-18 12:45 ` Jan Kara
2009-05-13 16:52 ` Al Viro
2009-05-13 18:13 ` Al Viro
2009-05-18 13:15 ` Theodore Tso
2009-05-18 14:10 ` Jan Kara
2009-05-18 12:53 ` Jan Kara
2009-05-13 13:48 ` bugzilla-daemon
2009-05-13 16:07 ` bugzilla-daemon
2009-05-13 16:18 ` bugzilla-daemon
2009-05-13 16:52 ` bugzilla-daemon
2009-05-13 18:13 ` bugzilla-daemon
2009-05-18 12:45 ` bugzilla-daemon
2009-05-18 12:54 ` bugzilla-daemon
2009-05-18 13:16 ` bugzilla-daemon
2009-05-18 14:10 ` bugzilla-daemon
2009-05-19 20:38 ` bugzilla-daemon
2009-05-19 20:39 ` bugzilla-daemon
2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 19:56 ` bugzilla-daemon
2009-06-07 20:44 ` bugzilla-daemon
-- strict thread matches above, loose matches on Subject: below --
2009-05-16 19:58 2.6.30-rc6: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
2009-05-16 20:06 ` [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix Rafael J. Wysocki
2009-05-16 20:06 ` Rafael J. Wysocki
2009-05-18 13:25 ` Theodore Tso
2009-05-18 13:25 ` Theodore Tso
[not found] ` <20090518132517.GL32019-3s7WtUTddSA@public.gmane.org>
2009-05-19 17:17 ` David Watson
2009-05-19 17:17 ` David Watson
[not found] ` <20090519171713.GA3354-yvBcC19sZ6P0OyVTGvYuXB2eb7JE58TQ@public.gmane.org>
2009-05-19 17:53 ` Theodore Tso
2009-05-19 17:53 ` Theodore Tso
2009-05-19 18:27 ` John Stoffel
[not found] ` <18962.64002.324970.49512-HgN6juyGXH5AfugRpC6u6w@public.gmane.org>
2009-05-19 20:41 ` Theodore Tso
2009-05-19 20:41 ` Theodore Tso
[not found] ` <20090519204152.GE9053-3s7WtUTddSA@public.gmane.org>
2009-05-20 16:53 ` John Stoffel
2009-05-20 16:53 ` John Stoffel
2009-05-24 19:27 2.6.30-rc7: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
2009-05-24 19:31 ` [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix Rafael J. Wysocki
2009-05-24 19:31 ` Rafael J. Wysocki
2009-05-30 19:50 2.6.30-rc7-git4: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
2009-05-30 19:55 ` [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix Rafael J. Wysocki
2009-05-30 19:55 ` Rafael J. Wysocki
2009-06-07 10:02 2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 17:14 ` Theodore Tso
2009-06-07 17:14 ` Theodore Tso
[not found] ` <20090607171418.GA22756-3s7WtUTddSA@public.gmane.org>
2009-06-07 17:17 ` Al Viro
2009-06-07 17:17 ` Al Viro
[not found] ` <20090607171739.GI8633-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2009-06-07 20:10 ` Theodore Tso
2009-06-07 20:10 ` Theodore Tso
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.