* 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ 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; 19+ 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] 19+ messages in thread
* Re: Regression tracking
2012-02-23 23:05 ` Dave Jones
@ 2012-02-23 23:22 ` Florian Mickler
0 siblings, 0 replies; 19+ 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] 19+ messages in thread
* regression tracking
@ 2011-10-26 17:23 Bjorn Helgaas
2011-10-26 18:13 ` Maciej Rutecki
0 siblings, 1 reply; 19+ messages in thread
From: Bjorn Helgaas @ 2011-10-26 17:23 UTC (permalink / raw)
To: Rafael J. Wysocki, Maciej Rutecki, Florian Mickler; +Cc: linux-kernel
The regression tracking that you folks used to do before the demise of
bugzilla.kernel.org was incredibly valuable.
I'm very concerned about the fact that we don't have a systematic way
to do this any more. Some things do get reported on LKML, of course,
but without the legwork you guys did, I'm afraid we're just dropping
things on the floor because there's no summary of what the issues are,
how many people are seeing them, who's responsible, etc.
Consider this as (1) kudos for performing an essential community
service, and (2) a plea for the resurrection or replacement of
bugzilla.kernel.org or some other mechanism for reviving regression
tracking.
Bjorn
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: regression tracking
2011-10-26 17:23 regression tracking Bjorn Helgaas
@ 2011-10-26 18:13 ` Maciej Rutecki
2011-10-27 20:35 ` Rafael J. Wysocki
0 siblings, 1 reply; 19+ messages in thread
From: Maciej Rutecki @ 2011-10-26 18:13 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Rafael J. Wysocki, Florian Mickler, linux-kernel
Hi
On środa, 26 października 2011 o 19:23:11 Bjorn Helgaas wrote:
> The regression tracking that you folks used to do before the demise of
> bugzilla.kernel.org was incredibly valuable.
>
> I'm very concerned about the fact that we don't have a systematic way
> to do this any more. Some things do get reported on LKML, of course,
> but without the legwork you guys did, I'm afraid we're just dropping
> things on the floor because there's no summary of what the issues are,
> how many people are seeing them, who's responsible, etc.
>
> Consider this as (1) kudos for performing an essential community
> service, and (2) a plea for the resurrection or replacement of
> bugzilla.kernel.org or some other mechanism for reviving regression
> tracking.
Because bugzilla is still down, I yesterday started send regressions (found in
LKML) report directly to Rafael, to create summary report (etc.) of them.
Until bugzilla comes back, we plan to collect regression in this way, but any
proposal for a better solution is welcome.
Regards
--
Maciej Rutecki
http://www.mrutecki.pl
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: regression tracking
2011-10-26 18:13 ` Maciej Rutecki
@ 2011-10-27 20:35 ` Rafael J. Wysocki
2011-10-28 17:44 ` Bjorn Helgaas
0 siblings, 1 reply; 19+ messages in thread
From: Rafael J. Wysocki @ 2011-10-27 20:35 UTC (permalink / raw)
To: maciej.rutecki; +Cc: Bjorn Helgaas, Florian Mickler, linux-kernel
On Wednesday, October 26, 2011, Maciej Rutecki wrote:
> Hi
>
> On środa, 26 października 2011 o 19:23:11 Bjorn Helgaas wrote:
> > The regression tracking that you folks used to do before the demise of
> > bugzilla.kernel.org was incredibly valuable.
> >
> > I'm very concerned about the fact that we don't have a systematic way
> > to do this any more. Some things do get reported on LKML, of course,
> > but without the legwork you guys did, I'm afraid we're just dropping
> > things on the floor because there's no summary of what the issues are,
> > how many people are seeing them, who's responsible, etc.
> >
> > Consider this as (1) kudos for performing an essential community
> > service, and (2) a plea for the resurrection or replacement of
> > bugzilla.kernel.org or some other mechanism for reviving regression
> > tracking.
>
> Because bugzilla is still down, I yesterday started send regressions (found in
> LKML) report directly to Rafael, to create summary report (etc.) of them.
> Until bugzilla comes back, we plan to collect regression in this way, but any
> proposal for a better solution is welcome.
Seconded.
Especially if there's a password-protected Wiki service somewhere that we
could use to store data temporarily until the BZ is back, it would be much
appreciated.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: regression tracking
2011-10-27 20:35 ` Rafael J. Wysocki
@ 2011-10-28 17:44 ` Bjorn Helgaas
0 siblings, 0 replies; 19+ messages in thread
From: Bjorn Helgaas @ 2011-10-28 17:44 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: maciej.rutecki, Florian Mickler, linux-kernel
On Thu, Oct 27, 2011 at 2:35 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Wednesday, October 26, 2011, Maciej Rutecki wrote:
>> Hi
>>
>> On środa, 26 października 2011 o 19:23:11 Bjorn Helgaas wrote:
>> > The regression tracking that you folks used to do before the demise of
>> > bugzilla.kernel.org was incredibly valuable.
>> >
>> > I'm very concerned about the fact that we don't have a systematic way
>> > to do this any more. Some things do get reported on LKML, of course,
>> > but without the legwork you guys did, I'm afraid we're just dropping
>> > things on the floor because there's no summary of what the issues are,
>> > how many people are seeing them, who's responsible, etc.
>> >
>> > Consider this as (1) kudos for performing an essential community
>> > service, and (2) a plea for the resurrection or replacement of
>> > bugzilla.kernel.org or some other mechanism for reviving regression
>> > tracking.
>>
>> Because bugzilla is still down, I yesterday started send regressions (found in
>> LKML) report directly to Rafael, to create summary report (etc.) of them.
>> Until bugzilla comes back, we plan to collect regression in this way, but any
>> proposal for a better solution is welcome.
>
> Seconded.
>
> Especially if there's a password-protected Wiki service somewhere that we
> could use to store data temporarily until the BZ is back, it would be much
> appreciated.
I don't know exactly what you would like to do with a wiki, but Google
Docs might be a possibility.
Disclaimer: I work for Google but this is not any sort of official
offer of help or support beyond the standard functionality that's
available to everybody.
Bjorn
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2012-02-23 23:22 UTC | newest]
Thread overview: 19+ 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
-- strict thread matches above, loose matches on Subject: below --
2011-10-26 17:23 regression tracking Bjorn Helgaas
2011-10-26 18:13 ` Maciej Rutecki
2011-10-27 20:35 ` Rafael J. Wysocki
2011-10-28 17:44 ` Bjorn Helgaas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox