* recvmsg sleeping from invalid context @ 2012-01-13 18:24 Dave Jones 2012-01-13 18:27 ` David Miller 2012-01-22 7:54 ` Maciej Rutecki 0 siblings, 2 replies; 15+ messages in thread From: Dave Jones @ 2012-01-13 18:24 UTC (permalink / raw) To: netdev; +Cc: Linux Kernel getting a ton of these on the latest head (099469502f62fbe0d7e4f0b83a2f22538367f734) BUG: sleeping function called from invalid context at mm/memory.c:3905 in_atomic(): 0, irqs_disabled(): 0, pid: 1067, name: NetworkManager INFO: lockdep is turned off. Pid: 1067, comm: NetworkManager Not tainted 3.2.0+ #22 Call Trace: [<ffffffff81099415>] __might_sleep+0x145/0x200 [<ffffffff811752a4>] might_fault+0x34/0xb0 [<ffffffff81551555>] ? sock_def_readable+0x25/0x1a0 [<ffffffff8155c387>] put_cmsg+0x77/0x120 [<ffffffff8159379c>] netlink_recvmsg+0x35c/0x480 [<ffffffff8155201a>] ? sock_update_classid+0x9a/0x260 [<ffffffff81552052>] ? sock_update_classid+0xd2/0x260 [<ffffffff81549fbd>] sock_recvmsg+0x11d/0x140 [<ffffffff811752c3>] ? might_fault+0x53/0xb0 [<ffffffff8117530c>] ? might_fault+0x9c/0xb0 [<ffffffff811752c3>] ? might_fault+0x53/0xb0 [<ffffffff8154b1b3>] __sys_recvmsg+0x153/0x2d0 [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 [<ffffffff8109fd11>] ? get_parent_ip+0x11/0x50 [<ffffffff816ac23d>] ? sub_preempt_count+0x9d/0xd0 [<ffffffff811bc43b>] ? fget_light+0xfb/0x470 [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 [<ffffffff8154e2e9>] sys_recvmsg+0x49/0x90 [<ffffffff816b00e9>] system_call_fastpath+0x16/0x1b BUG: sleeping function called from invalid context at kernel/mutex.c:271 in_atomic(): 0, irqs_disabled(): 0, pid: 1067, name: NetworkManager INFO: lockdep is turned off. Pid: 1067, comm: NetworkManager Not tainted 3.2.0+ #22 Call Trace: [<ffffffff81099415>] __might_sleep+0x145/0x200 [<ffffffff816a529e>] mutex_lock_nested+0x2e/0x50 [<ffffffff812022d0>] inotify_poll+0x30/0x60 [<ffffffff811d16f0>] do_sys_poll+0x280/0x500 [<ffffffff811d01b0>] ? poll_freewait+0xe0/0xe0 [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 [<ffffffff8109fd11>] ? get_parent_ip+0x11/0x50 [<ffffffff816ac23d>] ? sub_preempt_count+0x9d/0xd0 [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 [<ffffffff8154dc2b>] ? sys_sendto+0x15b/0x190 [<ffffffff810b776d>] ? ktime_get_ts+0xad/0xe0 [<ffffffff811d049a>] ? poll_select_set_timeout+0x7a/0x90 [<ffffffff811d1a56>] sys_poll+0x76/0x110 [<ffffffff816b00e9>] system_call_fastpath+0x16/0x1b ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: recvmsg sleeping from invalid context 2012-01-13 18:24 recvmsg sleeping from invalid context Dave Jones @ 2012-01-13 18:27 ` David Miller 2012-01-14 21:43 ` Dave Jones 2012-01-16 7:21 ` Glauber Costa 2012-01-22 7:54 ` Maciej Rutecki 1 sibling, 2 replies; 15+ messages in thread From: David Miller @ 2012-01-13 18:27 UTC (permalink / raw) To: davej; +Cc: netdev, linux-kernel, glommer From: Dave Jones <davej@redhat.com> Date: Fri, 13 Jan 2012 13:24:01 -0500 > getting a ton of these on the latest head (099469502f62fbe0d7e4f0b83a2f22538367f734) > > BUG: sleeping function called from invalid context at mm/memory.c:3905 > in_atomic(): 0, irqs_disabled(): 0, pid: 1067, name: NetworkManager > INFO: lockdep is turned off. > Pid: 1067, comm: NetworkManager Not tainted 3.2.0+ #22 > Call Trace: > [<ffffffff81099415>] __might_sleep+0x145/0x200 > [<ffffffff811752a4>] might_fault+0x34/0xb0 > [<ffffffff81551555>] ? sock_def_readable+0x25/0x1a0 > [<ffffffff8155c387>] put_cmsg+0x77/0x120 > [<ffffffff8159379c>] netlink_recvmsg+0x35c/0x480 > [<ffffffff8155201a>] ? sock_update_classid+0x9a/0x260 > [<ffffffff81552052>] ? sock_update_classid+0xd2/0x260 > [<ffffffff81549fbd>] sock_recvmsg+0x11d/0x140 > [<ffffffff811752c3>] ? might_fault+0x53/0xb0 > [<ffffffff8117530c>] ? might_fault+0x9c/0xb0 > [<ffffffff811752c3>] ? might_fault+0x53/0xb0 > [<ffffffff8154b1b3>] __sys_recvmsg+0x153/0x2d0 > [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 > [<ffffffff8109fd11>] ? get_parent_ip+0x11/0x50 > [<ffffffff816ac23d>] ? sub_preempt_count+0x9d/0xd0 > [<ffffffff811bc43b>] ? fget_light+0xfb/0x470 > [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 > [<ffffffff8154e2e9>] sys_recvmsg+0x49/0x90 > [<ffffffff816b00e9>] system_call_fastpath+0x16/0x1b Sigh, I suspect the new socket memcg code, which I didn't want to even apply in the first place. :-/ Glauber, please fix this. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: recvmsg sleeping from invalid context 2012-01-13 18:27 ` David Miller @ 2012-01-14 21:43 ` Dave Jones 2012-01-14 22:16 ` Eric Dumazet 2012-01-16 7:21 ` Glauber Costa 1 sibling, 1 reply; 15+ messages in thread From: Dave Jones @ 2012-01-14 21:43 UTC (permalink / raw) To: David Miller; +Cc: netdev, linux-kernel, glommer On Fri, Jan 13, 2012 at 10:27:12AM -0800, David Miller wrote: > From: Dave Jones <davej@redhat.com> > Date: Fri, 13 Jan 2012 13:24:01 -0500 > > > getting a ton of these on the latest head (099469502f62fbe0d7e4f0b83a2f22538367f734) > > > > BUG: sleeping function called from invalid context at mm/memory.c:3905 > > in_atomic(): 0, irqs_disabled(): 0, pid: 1067, name: NetworkManager > > INFO: lockdep is turned off. > > Pid: 1067, comm: NetworkManager Not tainted 3.2.0+ #22 > > Call Trace: > > [<ffffffff81099415>] __might_sleep+0x145/0x200 > > [<ffffffff811752a4>] might_fault+0x34/0xb0 > > [<ffffffff81551555>] ? sock_def_readable+0x25/0x1a0 > > [<ffffffff8155c387>] put_cmsg+0x77/0x120 > > [<ffffffff8159379c>] netlink_recvmsg+0x35c/0x480 > > [<ffffffff8155201a>] ? sock_update_classid+0x9a/0x260 > > [<ffffffff81552052>] ? sock_update_classid+0xd2/0x260 > > [<ffffffff81549fbd>] sock_recvmsg+0x11d/0x140 > > [<ffffffff811752c3>] ? might_fault+0x53/0xb0 > > [<ffffffff8117530c>] ? might_fault+0x9c/0xb0 > > [<ffffffff811752c3>] ? might_fault+0x53/0xb0 > > [<ffffffff8154b1b3>] __sys_recvmsg+0x153/0x2d0 > > [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 > > [<ffffffff8109fd11>] ? get_parent_ip+0x11/0x50 > > [<ffffffff816ac23d>] ? sub_preempt_count+0x9d/0xd0 > > [<ffffffff811bc43b>] ? fget_light+0xfb/0x470 > > [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 > > [<ffffffff8154e2e9>] sys_recvmsg+0x49/0x90 > > [<ffffffff816b00e9>] system_call_fastpath+0x16/0x1b > > Sigh, I suspect the new socket memcg code, which I didn't want to > even apply in the first place. :-/ > > Glauber, please fix this. How new is 'new' ? interestingly, I now started getting these in 3.1.9 where I never noticed them before. BUG: sleeping function called from invalid context at mm/memory.c:3905 in_atomic(): 1, irqs_disabled(): 0, pid: 962, name: NetworkManager 1 lock held by NetworkManager/962: #0: (rcu_read_lock){.+.+..}, at: [<ffffffff815f610d>] inet6_dump_fib+0x3d/0x3d0 Pid: 962, comm: NetworkManager Not tainted 3.1.9-1.fc16.x86_64.debug #1 Call Trace: [<ffffffff8105fbd0>] __might_sleep+0xf0/0x120 [<ffffffff81160f68>] might_fault+0x38/0xb0 [<ffffffff81519070>] ? sock_def_error_report+0x120/0x120 [<ffffffff81523877>] put_cmsg+0x77/0x120 [<ffffffff815587ec>] netlink_recvmsg+0x35c/0x480 [<ffffffff81518d2e>] ? sock_update_classid+0x8e/0x190 [<ffffffff81518d68>] ? sock_update_classid+0xc8/0x190 [<ffffffff815122ad>] sock_recvmsg+0x11d/0x140 [<ffffffff81160f8c>] ? might_fault+0x5c/0xb0 [<ffffffff81160fd5>] ? might_fault+0xa5/0xb0 [<ffffffff81160f8c>] ? might_fault+0x5c/0xb0 [<ffffffff81513373>] __sys_recvmsg+0x153/0x2d0 [<ffffffff810a8f28>] ? sched_clock_cpu+0xa8/0x110 [<ffffffff810b6bfd>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff810a8fff>] ? local_clock+0x6f/0x80 [<ffffffff810b74a5>] ? lock_release_holdtime.part.9+0x15/0x1a0 [<ffffffff811a4bef>] ? fget_light+0xcf/0x3b0 [<ffffffff811a4c07>] ? fget_light+0xe7/0x3b0 [<ffffffff811a4b68>] ? fget_light+0x48/0x3b0 [<ffffffff81516359>] sys_recvmsg+0x49/0x90 [<ffffffff81669dc2>] system_call_fastpath+0x16/0x1b ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: recvmsg sleeping from invalid context 2012-01-14 21:43 ` Dave Jones @ 2012-01-14 22:16 ` Eric Dumazet 0 siblings, 0 replies; 15+ messages in thread From: Eric Dumazet @ 2012-01-14 22:16 UTC (permalink / raw) To: Dave Jones; +Cc: David Miller, netdev, linux-kernel, glommer Le samedi 14 janvier 2012 à 16:43 -0500, Dave Jones a écrit : > On Fri, Jan 13, 2012 at 10:27:12AM -0800, David Miller wrote: > > From: Dave Jones <davej@redhat.com> > > Date: Fri, 13 Jan 2012 13:24:01 -0500 > > > > > getting a ton of these on the latest head (099469502f62fbe0d7e4f0b83a2f22538367f734) > > > > > > BUG: sleeping function called from invalid context at mm/memory.c:3905 > > > in_atomic(): 0, irqs_disabled(): 0, pid: 1067, name: NetworkManager > > > INFO: lockdep is turned off. > > > Pid: 1067, comm: NetworkManager Not tainted 3.2.0+ #22 > > > Call Trace: > > > [<ffffffff81099415>] __might_sleep+0x145/0x200 > > > [<ffffffff811752a4>] might_fault+0x34/0xb0 > > > [<ffffffff81551555>] ? sock_def_readable+0x25/0x1a0 > > > [<ffffffff8155c387>] put_cmsg+0x77/0x120 > > > [<ffffffff8159379c>] netlink_recvmsg+0x35c/0x480 > > > [<ffffffff8155201a>] ? sock_update_classid+0x9a/0x260 > > > [<ffffffff81552052>] ? sock_update_classid+0xd2/0x260 > > > [<ffffffff81549fbd>] sock_recvmsg+0x11d/0x140 > > > [<ffffffff811752c3>] ? might_fault+0x53/0xb0 > > > [<ffffffff8117530c>] ? might_fault+0x9c/0xb0 > > > [<ffffffff811752c3>] ? might_fault+0x53/0xb0 > > > [<ffffffff8154b1b3>] __sys_recvmsg+0x153/0x2d0 > > > [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 > > > [<ffffffff8109fd11>] ? get_parent_ip+0x11/0x50 > > > [<ffffffff816ac23d>] ? sub_preempt_count+0x9d/0xd0 > > > [<ffffffff811bc43b>] ? fget_light+0xfb/0x470 > > > [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 > > > [<ffffffff8154e2e9>] sys_recvmsg+0x49/0x90 > > > [<ffffffff816b00e9>] system_call_fastpath+0x16/0x1b > > > > Sigh, I suspect the new socket memcg code, which I didn't want to > > even apply in the first place. :-/ > > > > Glauber, please fix this. > > How new is 'new' ? > > interestingly, I now started getting these in 3.1.9 where I never noticed them before. > > > BUG: sleeping function called from invalid context at mm/memory.c:3905 > in_atomic(): 1, irqs_disabled(): 0, pid: 962, name: NetworkManager > 1 lock held by NetworkManager/962: > #0: (rcu_read_lock){.+.+..}, at: [<ffffffff815f610d>] inet6_dump_fib+0x3d/0x3d0 > Pid: 962, comm: NetworkManager Not tainted 3.1.9-1.fc16.x86_64.debug #1 > Call Trace: > [<ffffffff8105fbd0>] __might_sleep+0xf0/0x120 > [<ffffffff81160f68>] might_fault+0x38/0xb0 > [<ffffffff81519070>] ? sock_def_error_report+0x120/0x120 > [<ffffffff81523877>] put_cmsg+0x77/0x120 > [<ffffffff815587ec>] netlink_recvmsg+0x35c/0x480 > [<ffffffff81518d2e>] ? sock_update_classid+0x8e/0x190 > [<ffffffff81518d68>] ? sock_update_classid+0xc8/0x190 > [<ffffffff815122ad>] sock_recvmsg+0x11d/0x140 > [<ffffffff81160f8c>] ? might_fault+0x5c/0xb0 > [<ffffffff81160fd5>] ? might_fault+0xa5/0xb0 > [<ffffffff81160f8c>] ? might_fault+0x5c/0xb0 > [<ffffffff81513373>] __sys_recvmsg+0x153/0x2d0 > [<ffffffff810a8f28>] ? sched_clock_cpu+0xa8/0x110 > [<ffffffff810b6bfd>] ? trace_hardirqs_off+0xd/0x10 > [<ffffffff810a8fff>] ? local_clock+0x6f/0x80 > [<ffffffff810b74a5>] ? lock_release_holdtime.part.9+0x15/0x1a0 > [<ffffffff811a4bef>] ? fget_light+0xcf/0x3b0 > [<ffffffff811a4c07>] ? fget_light+0xe7/0x3b0 > [<ffffffff811a4b68>] ? fget_light+0x48/0x3b0 > [<ffffffff81516359>] sys_recvmsg+0x49/0x90 > [<ffffffff81669dc2>] system_call_fastpath+0x16/0x1b > I dont understand this trace. inet6_dump_fib() does indeed an rcu_read_lock(), but pair it by rcu_read_unlock(). fib6_dump_table() is called with rcu_read_lock(), but certainly cannot end calling pu_cmsg(). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: recvmsg sleeping from invalid context 2012-01-13 18:27 ` David Miller 2012-01-14 21:43 ` Dave Jones @ 2012-01-16 7:21 ` Glauber Costa 1 sibling, 0 replies; 15+ messages in thread From: Glauber Costa @ 2012-01-16 7:21 UTC (permalink / raw) To: David Miller; +Cc: davej, netdev, linux-kernel On 01/13/2012 10:27 PM, David Miller wrote: > From: Dave Jones<davej@redhat.com> > Date: Fri, 13 Jan 2012 13:24:01 -0500 > >> getting a ton of these on the latest head (099469502f62fbe0d7e4f0b83a2f22538367f734) >> >> BUG: sleeping function called from invalid context at mm/memory.c:3905 >> in_atomic(): 0, irqs_disabled(): 0, pid: 1067, name: NetworkManager >> INFO: lockdep is turned off. >> Pid: 1067, comm: NetworkManager Not tainted 3.2.0+ #22 >> Call Trace: >> [<ffffffff81099415>] __might_sleep+0x145/0x200 >> [<ffffffff811752a4>] might_fault+0x34/0xb0 >> [<ffffffff81551555>] ? sock_def_readable+0x25/0x1a0 >> [<ffffffff8155c387>] put_cmsg+0x77/0x120 >> [<ffffffff8159379c>] netlink_recvmsg+0x35c/0x480 >> [<ffffffff8155201a>] ? sock_update_classid+0x9a/0x260 >> [<ffffffff81552052>] ? sock_update_classid+0xd2/0x260 >> [<ffffffff81549fbd>] sock_recvmsg+0x11d/0x140 >> [<ffffffff811752c3>] ? might_fault+0x53/0xb0 >> [<ffffffff8117530c>] ? might_fault+0x9c/0xb0 >> [<ffffffff811752c3>] ? might_fault+0x53/0xb0 >> [<ffffffff8154b1b3>] __sys_recvmsg+0x153/0x2d0 >> [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 >> [<ffffffff8109fd11>] ? get_parent_ip+0x11/0x50 >> [<ffffffff816ac23d>] ? sub_preempt_count+0x9d/0xd0 >> [<ffffffff811bc43b>] ? fget_light+0xfb/0x470 >> [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 >> [<ffffffff8154e2e9>] sys_recvmsg+0x49/0x90 >> [<ffffffff816b00e9>] system_call_fastpath+0x16/0x1b > > Sigh, I suspect the new socket memcg code, which I didn't want to > even apply in the first place. :-/ > > Glauber, please fix this. I really don't see how this can be related to sock memcg at all. Nothing in the stack trace points to it. You probably got this impression by "sock_update_classid", which has a naming similar to the ones I used to update some sockets attributes, but are something else entirely. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: recvmsg sleeping from invalid context 2012-01-13 18:24 recvmsg sleeping from invalid context Dave Jones 2012-01-13 18:27 ` David Miller @ 2012-01-22 7:54 ` Maciej Rutecki 2012-01-22 19:10 ` David Miller 1 sibling, 1 reply; 15+ messages in thread From: Maciej Rutecki @ 2012-01-22 7:54 UTC (permalink / raw) To: Dave Jones; +Cc: netdev, Linux Kernel On piątek, 13 stycznia 2012 o 19:24:01 Dave Jones wrote: > getting a ton of these on the latest head > (099469502f62fbe0d7e4f0b83a2f22538367f734) > > BUG: sleeping function called from invalid context at mm/memory.c:3905 > in_atomic(): 0, irqs_disabled(): 0, pid: 1067, name: NetworkManager > INFO: lockdep is turned off. > Pid: 1067, comm: NetworkManager Not tainted 3.2.0+ #22 > Call Trace: > [<ffffffff81099415>] __might_sleep+0x145/0x200 > [<ffffffff811752a4>] might_fault+0x34/0xb0 > [<ffffffff81551555>] ? sock_def_readable+0x25/0x1a0 > [<ffffffff8155c387>] put_cmsg+0x77/0x120 > [<ffffffff8159379c>] netlink_recvmsg+0x35c/0x480 > [<ffffffff8155201a>] ? sock_update_classid+0x9a/0x260 > [<ffffffff81552052>] ? sock_update_classid+0xd2/0x260 > [<ffffffff81549fbd>] sock_recvmsg+0x11d/0x140 > [<ffffffff811752c3>] ? might_fault+0x53/0xb0 > [<ffffffff8117530c>] ? might_fault+0x9c/0xb0 > [<ffffffff811752c3>] ? might_fault+0x53/0xb0 > [<ffffffff8154b1b3>] __sys_recvmsg+0x153/0x2d0 > [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 > [<ffffffff8109fd11>] ? get_parent_ip+0x11/0x50 > [<ffffffff816ac23d>] ? sub_preempt_count+0x9d/0xd0 > [<ffffffff811bc43b>] ? fget_light+0xfb/0x470 > [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 > [<ffffffff8154e2e9>] sys_recvmsg+0x49/0x90 > [<ffffffff816b00e9>] system_call_fastpath+0x16/0x1b > > > BUG: sleeping function called from invalid context at kernel/mutex.c:271 > in_atomic(): 0, irqs_disabled(): 0, pid: 1067, name: NetworkManager > INFO: lockdep is turned off. > Pid: 1067, comm: NetworkManager Not tainted 3.2.0+ #22 > Call Trace: > [<ffffffff81099415>] __might_sleep+0x145/0x200 > [<ffffffff816a529e>] mutex_lock_nested+0x2e/0x50 > [<ffffffff812022d0>] inotify_poll+0x30/0x60 > [<ffffffff811d16f0>] do_sys_poll+0x280/0x500 > [<ffffffff811d01b0>] ? poll_freewait+0xe0/0xe0 > [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 > [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 > [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 > [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 > [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 > [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 > [<ffffffff811d02a0>] ? __pollwait+0xf0/0xf0 > [<ffffffff8109fd11>] ? get_parent_ip+0x11/0x50 > [<ffffffff816ac23d>] ? sub_preempt_count+0x9d/0xd0 > [<ffffffff811bc39a>] ? fget_light+0x5a/0x470 > [<ffffffff8154dc2b>] ? sys_sendto+0x15b/0x190 > [<ffffffff810b776d>] ? ktime_get_ts+0xad/0xe0 > [<ffffffff811d049a>] ? poll_select_set_timeout+0x7a/0x90 > [<ffffffff811d1a56>] sys_poll+0x76/0x110 > [<ffffffff816b00e9>] system_call_fastpath+0x16/0x1b > I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=42629 for your bug report, please add your address to the CC list in there, thanks! -- Maciej Rutecki http://www.mrutecki.pl ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: recvmsg sleeping from invalid context 2012-01-22 7:54 ` Maciej Rutecki @ 2012-01-22 19:10 ` David Miller 2012-01-22 19:31 ` Maciej Rutecki 0 siblings, 1 reply; 15+ messages in thread From: David Miller @ 2012-01-22 19:10 UTC (permalink / raw) To: maciej.rutecki; +Cc: davej, netdev, linux-kernel From: Maciej Rutecki <maciej.rutecki@gmail.com> Date: Sun, 22 Jan 2012 08:54:59 +0100 > I created a Bugzilla entry at > https://bugzilla.kernel.org/show_bug.cgi?id=42629 > for your bug report, please add your address to the CC list in there, thanks! Please don't do this, none of the networking developers use bugzilla, we keep the discussion and analysis going here on netdev. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: recvmsg sleeping from invalid context 2012-01-22 19:10 ` David Miller @ 2012-01-22 19:31 ` Maciej Rutecki 2012-01-22 19:37 ` David Miller 0 siblings, 1 reply; 15+ messages in thread From: Maciej Rutecki @ 2012-01-22 19:31 UTC (permalink / raw) To: David Miller; +Cc: davej, netdev, linux-kernel, Rafael J. Wysocki On niedziela, 22 stycznia 2012 o 20:10:06 David Miller wrote: > From: Maciej Rutecki <maciej.rutecki@gmail.com> > Date: Sun, 22 Jan 2012 08:54:59 +0100 > > > I created a Bugzilla entry at > > https://bugzilla.kernel.org/show_bug.cgi?id=42629 > > for your bug report, please add your address to the CC list in there, > > thanks! > > Please don't do this, none of the networking developers use bugzilla, > we keep the discussion and analysis going here on netdev. These entries are using for tracking regressions, for *all* kernel parts, without any exception. I see no reason to treat someone differently. If netdev provides any interface to tracking regressions, then show me it. But then why you do not use one common tool for all kernel? Regards -- Maciej Rutecki http://www.mrutecki.pl ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: recvmsg sleeping from invalid context 2012-01-22 19:31 ` Maciej Rutecki @ 2012-01-22 19:37 ` David Miller 2012-01-22 19:52 ` Regression tracking [WAS: Re: recvmsg sleeping from invalid context] Maciej Rutecki 0 siblings, 1 reply; 15+ messages in thread From: David Miller @ 2012-01-22 19:37 UTC (permalink / raw) To: maciej.rutecki; +Cc: davej, netdev, linux-kernel, rjw From: Maciej Rutecki <maciej.rutecki@gmail.com> Date: Sun, 22 Jan 2012 20:31:51 +0100 > These entries are using for tracking regressions, for *all* kernel parts, > without any exception. I see no reason to treat someone differently. If netdev > provides any interface to tracking regressions, then show me it. But then why > you do not use one common tool for all kernel? This mailing list is the tracking mechanism. You can create whatever you want, but I can guarentee that the very people who can actually move the bug forward and fix the problem will look at it. It's been like this for ages, Andrew Morton understands how we wish to track bugs, and that we don't want to use bugzilla for that purpose. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Regression tracking [WAS: Re: recvmsg sleeping from invalid context] 2012-01-22 19:37 ` David Miller @ 2012-01-22 19:52 ` Maciej Rutecki 2012-01-22 20:07 ` Regression tracking David Miller 0 siblings, 1 reply; 15+ messages in thread From: Maciej Rutecki @ 2012-01-22 19:52 UTC (permalink / raw) To: David Miller; +Cc: davej, netdev, linux-kernel, rjw On niedziela, 22 stycznia 2012 o 20:37:28 David Miller wrote: > From: Maciej Rutecki <maciej.rutecki@gmail.com> > Date: Sun, 22 Jan 2012 20:31:51 +0100 > > > These entries are using for tracking regressions, for *all* kernel parts, > > without any exception. I see no reason to treat someone differently. If > > netdev provides any interface to tracking regressions, then show me it. > > But then why you do not use one common tool for all kernel? > > This mailing list is the tracking mechanism. > > You can create whatever you want, but I can guarentee that the very > people who can actually move the bug forward and fix the problem will > look at it. > > It's been like this for ages, Andrew Morton understands how we wish > to track bugs, and that we don't want to use bugzilla for that purpose. OK. But tracking regressions in two (or more) places is nonsense. And this puts into question all of my current work, such as how to analyze (automatically) the progress of the whole kernel and its quality per each -rc. Problem to discussion, but if everyone will do as you wish, it will all work went to waste. I do not say that resolving regression in mailinglist is bad. I think that is as good as bug tracker. Bug entry is helps us store information in one places. E.g. "Refernces" tag redirect people to discussion in LKML. But I say again: I think that LKML is not regression tracker, but helps solve regression. Regards -- Maciej Rutecki http://www.mrutecki.pl ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression tracking 2012-01-22 19:52 ` Regression tracking [WAS: Re: recvmsg sleeping from invalid context] Maciej Rutecki @ 2012-01-22 20:07 ` David Miller 2012-01-23 0:52 ` Rafael J. Wysocki 0 siblings, 1 reply; 15+ messages in thread From: David Miller @ 2012-01-22 20:07 UTC (permalink / raw) To: maciej.rutecki; +Cc: davej, netdev, linux-kernel, rjw From: Maciej Rutecki <maciej.rutecki@gmail.com> Date: Sun, 22 Jan 2012 20:52:02 +0100 > OK. But tracking regressions in two (or more) places is nonsense. And this > puts into question all of my current work, such as how to analyze > (automatically) the progress of the whole kernel and its quality per each -rc. > Problem to discussion, but if everyone will do as you wish, it will all work > went to waste. If someone else wants to maintain the state of bugs on some web site and click buttons all day long, that is their perogative. But it's not something I'm going to do. You can't force people to use tools, and frankly that's the end of this conversation as far as I'm concerned. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression tracking 2012-01-22 20:07 ` Regression tracking David Miller @ 2012-01-23 0:52 ` Rafael J. Wysocki 2012-02-23 22:52 ` Florian Mickler 0 siblings, 1 reply; 15+ messages in thread From: Rafael J. Wysocki @ 2012-01-23 0:52 UTC (permalink / raw) To: David Miller; +Cc: maciej.rutecki, davej, netdev, linux-kernel On Sunday, January 22, 2012, David Miller wrote: > From: Maciej Rutecki <maciej.rutecki@gmail.com> > Date: Sun, 22 Jan 2012 20:52:02 +0100 > > > OK. But tracking regressions in two (or more) places is nonsense. And this > > puts into question all of my current work, such as how to analyze > > (automatically) the progress of the whole kernel and its quality per each -rc. > > Problem to discussion, but if everyone will do as you wish, it will all work > > went to waste. > > If someone else wants to maintain the state of bugs on some web > site and click buttons all day long, that is their perogative. > > But it's not something I'm going to do. > > You can't force people to use tools, and frankly that's the end of > this conversation as far as I'm concerned. Well, people who are tracking regressions need to keep the record of what's been reported etc. somewhere and we use the Bugzilla for this purpose (basically, as a database). I, personally, have never been expecting developers to follow the entries put in there by us, unless they want to, but then we'd like the _reporters_ to update the status (resolved/closed) which saves us quite some time (e.g. if someone closes a bug entry created for a regression reported by him, we don't need to dig through the git history and mailing lists archives or ask developers whether or not the given bug has been fixed). I hope that clarifies things. Thanks, Rafael ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression tracking 2012-01-23 0:52 ` Rafael J. Wysocki @ 2012-02-23 22:52 ` Florian Mickler 2012-02-23 23:05 ` Dave Jones 0 siblings, 1 reply; 15+ messages in thread From: Florian Mickler @ 2012-02-23 22:52 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: David Miller, davej, netdev, linux-kernel On Mon, 23 Jan 2012 01:52:25 +0100 "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > On Sunday, January 22, 2012, David Miller wrote: > > From: Maciej Rutecki <maciej.rutecki@gmail.com> > > Date: Sun, 22 Jan 2012 20:52:02 +0100 > > > > > OK. But tracking regressions in two (or more) places is nonsense. And this > > > puts into question all of my current work, such as how to analyze > > > (automatically) the progress of the whole kernel and its quality per each -rc. > > > Problem to discussion, but if everyone will do as you wish, it will all work > > > went to waste. > > > > If someone else wants to maintain the state of bugs on some web > > site and click buttons all day long, that is their perogative. > > > > But it's not something I'm going to do. > > > > You can't force people to use tools, and frankly that's the end of > > this conversation as far as I'm concerned. What I would like to ask from you and other developers in order to make life easier for all users reporting bugs and people tracking regressions is to post a solution for an issue to the mail thread it was first reported in. That way we can just read through that mail thread and see that it is resolved. Also if you are aware, that someone (Maciej!) did open a bug for an issue, please(!) stick that number in the commit changelog. Full Url would be wonderful for automated processing, but "bug [nr]" is sufficient for manual scanning of the commit log. If you don't do that, I fear that I will annoy you from time to time with: "is this issue fixed already?" or "hey, what about that 4 month old regression? Is it already fixed?". (And knowing netdev, it is of course already fixed in 99.9% of the cases. So I just need the pointer to the solution...) [If I have much time at hand, I will even scan the mail chatter of the people involved during the time frame the bug was reported, but that is a tedious task... still I do that sometimes in order to avoid annoying people with this silly stuff] Regards, Flo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression tracking 2012-02-23 22:52 ` Florian Mickler @ 2012-02-23 23:05 ` Dave Jones 2012-02-23 23:22 ` Florian Mickler 0 siblings, 1 reply; 15+ messages in thread From: Dave Jones @ 2012-02-23 23:05 UTC (permalink / raw) To: Florian Mickler; +Cc: Rafael J. Wysocki, David Miller, netdev, linux-kernel On Thu, Feb 23, 2012 at 11:52:13PM +0100, Florian Mickler wrote: > If you don't do that, I fear that I will annoy you from time to time > with: "is this issue fixed already?" or "hey, what about that 4 month > old regression? Is it already fixed?". If you intend to do this, please add me to your "do not mail" list. For people working at distributions acting as middle-man, this isn't helpful at all. And it's just not feasible for me to go dig out every thread I posted to just to reply with "fixed". Dave ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Regression tracking 2012-02-23 23:05 ` Dave Jones @ 2012-02-23 23:22 ` Florian Mickler 0 siblings, 0 replies; 15+ messages in thread From: Florian Mickler @ 2012-02-23 23:22 UTC (permalink / raw) To: Dave Jones; +Cc: Rafael J. Wysocki, David Miller, netdev, linux-kernel On Thu, 23 Feb 2012 18:05:32 -0500 Dave Jones <davej@redhat.com> wrote: > On Thu, Feb 23, 2012 at 11:52:13PM +0100, Florian Mickler wrote: > > > If you don't do that, I fear that I will annoy you from time to time > > with: "is this issue fixed already?" or "hey, what about that 4 month > > old regression? Is it already fixed?". > > If you intend to do this, please add me to your "do not mail" list. > > For people working at distributions acting as middle-man, this isn't > helpful at all. And it's just not feasible for me to go dig out every > thread I posted to just to reply with "fixed". > > Dave > You are not on my go-to-guy list since you do not maintain a kernel subsystem and I don't expect you to keep track of anything. If you post a link to a rh-bugzilla, I will of course check if that one is still open or how it is closed. I'm not stupid, I just need some silver linen threads to find how a regression is solved. I.e. I don't want a "fixed". I want a "commit xyz fixed this" or a "I can't reproduce the bug anymore". Either is fine. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-02-23 23:22 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-01-13 18:24 recvmsg sleeping from invalid context Dave Jones 2012-01-13 18:27 ` David Miller 2012-01-14 21:43 ` Dave Jones 2012-01-14 22:16 ` Eric Dumazet 2012-01-16 7:21 ` Glauber Costa 2012-01-22 7:54 ` Maciej Rutecki 2012-01-22 19:10 ` David Miller 2012-01-22 19:31 ` Maciej Rutecki 2012-01-22 19:37 ` David Miller 2012-01-22 19:52 ` Regression tracking [WAS: Re: recvmsg sleeping from invalid context] Maciej Rutecki 2012-01-22 20:07 ` Regression tracking David Miller 2012-01-23 0:52 ` Rafael J. Wysocki 2012-02-23 22:52 ` Florian Mickler 2012-02-23 23:05 ` Dave Jones 2012-02-23 23:22 ` Florian Mickler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).