Re: mmotm 2009-02-17-12-33 uploaded

Re: mmotm 2009-02-17-12-33 uploaded

[Jiri Slaby]

On 17.2.2009 21:33, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2009-02-17-12-33 has been uploaded to

Hi,

I'm getting the page fault below everytime during bootup. This is how 
__task_rq_lock looks like:
         for (;;) {
                 struct rq *rq;
         printk("CPU=%u %p %p %p %s\n", task_cpu(p), p,
                         task_thread_info(p)->task,
                         task_thread_info(p), p->comm);
                 rq = task_rq(p);
                 spin_lock(&rq->lock);
                 if (likely(rq == task_rq(p)))
                         return rq;
                 spin_unlock(&rq->lock);
         }

CPU=2303197184 ffff880012497d90 b8005f57df1d8948 ffffffff80262d0a 
migration/0
BUG: unable to handle kernel paging request at 00000003cabbb780
IP: [<ffffffff802399eb>] __sched_setscheduler+0x17b/0x4a0
PGD 0
Oops: 0000 [#1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.29-rc5-mm1_64 #578
RIP: 0010:[<ffffffff802399eb>]  [<ffffffff802399eb>] 
__sched_setscheduler+0x17b/0x4a0
RSP: 0018:ffff880012497cc0  EFLAGS: 00000086
RAX: 0000000089480000 RBX: ffffffff80262d0a RCX: 00000000ffffffff
RDX: 000000000000d7d7 RSI: 0000000000000046 RDI: ffffffff80835334
RBP: ffff880012497d30 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000010180
R13: 0000000000000000 R14: ffff880012497d90 R15: 0000000000010180
FS:  0000000000000000(0000) GS:ffff880001007000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00000003cabbb780 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
Process swapper (pid: 1, threadinfo ffff880012496000, task ffff880012478000)
Stack:
  0000000000000000 ffff880012497dc0 ffff880012498270 ffffffff12478000
  0000000000000000 ffffffff80262d0a ffff8800124980f0 0000000000000046
  0000000000000246 ffff880012497d50 ffffffff806f1065 0000000000000000
Call Trace:
  [<ffffffff80262d0a>] ? tick_check_broadcast_device+0x3a/0x70
  [<ffffffff80239d1b>] sched_setscheduler_nocheck+0xb/0x10
  [<ffffffff80256ad7>] kthread_create+0xe7/0x120
  [<ffffffff8023b820>] ? migration_thread+0x0/0x230
  [<ffffffff80262d0a>] ? tick_check_broadcast_device+0x3a/0x70
  [<ffffffff80262109>] ? tick_notify+0x369/0x410
  [<ffffffff807d9598>] ? migration_init+0x0/0x5c
  [<ffffffff805de278>] migration_call+0x376/0x4ed
  [<ffffffff807d9598>] ? migration_init+0x0/0x5c
  [<ffffffff807d95be>] migration_init+0x26/0x5c
  [<ffffffff807d9598>] ? migration_init+0x0/0x5c
  [<ffffffff8020904c>] do_one_initcall+0x3c/0x170
  [<ffffffff807d31c4>] ? native_smp_prepare_cpus+0x1c0/0x311
  [<ffffffff807ca559>] kernel_init+0x76/0x1bc
  [<ffffffff8020d8da>] child_rip+0xa/0x20
  [<ffffffff807ca4e3>] ? kernel_init+0x0/0x1bc
  [<ffffffff8020d8d0>] ? child_rip+0x0/0x20
Code: 69 3a 00 49 8b 5e 08 4c 8b 45 08 48 8b 0b ba db 08 00 00 48 c7 c6 
e0 4a 6e 80 48 c7 c7 ce 99 6e 80 31 c0 e8 0b 69 3a 00 8b 43 18 <4c> 03 
24 c5 80 b7 7b 80 4c 89 e7 e8 e5 97 3a 00 49 8b 5e 08 31
RIP  [<ffffffff802399eb>] __sched_setscheduler+0x17b/0x4a0
  RSP <ffff880012497cc0>
CR2: 00000003cabbb780
---[ end trace 4eaa2a86a8e2da22 ]---

Re: mmotm 2009-02-17-12-33 uploaded

[Andrew Morton]

On Wed, 18 Feb 2009 00:21:01 +0100
Jiri Slaby <jirislaby@gmail.com> wrote:

> I'm getting the page fault below everytime during bootup.

It'd be useful to know if bare linux-next does the same thing, please.

Re: mmotm 2009-02-17-12-33 uploaded (nr_pdflush_threads_min sysctl build error)

[Randy Dunlap]

akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2009-02-17-12-33 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/
> 
> and will soon be available at
> 
>    git://git.zen-sources.org/zen/mmotm.git


Is there any CONFIG_ symbol associated with $subject sysctl?

'one' is only available (currently) when:

#if defined(CONFIG_DETECT_HUNG_TASK) || defined(CONFIG_DETECT_SOFTLOCKUP) || defined(CONFIG_HIGHMEM)
static int one = 1;
#endif

so it gives us
kernel/sysctl.c:1067: error: 'one' undeclared here (not in a function)

when one of those is not #defined.

-- 
~Randy

Re: mmotm 2009-02-17-12-33 uploaded (nr_pdflush_threads_min sysctl build error)

[Andrew Morton]

On Tue, 17 Feb 2009 16:52:49 -0800 Randy Dunlap <randy.dunlap@oracle.com> wrote:

> akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2009-02-17-12-33 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> > 
> > and will soon be available at
> > 
> >    git://git.zen-sources.org/zen/mmotm.git
> 
> 
> Is there any CONFIG_ symbol associated with $subject sysctl?

Nope.

> 'one' is only available (currently) when:
> 
> #if defined(CONFIG_DETECT_HUNG_TASK) || defined(CONFIG_DETECT_SOFTLOCKUP) || defined(CONFIG_HIGHMEM)
> static int one = 1;
> #endif
> 
> so it gives us
> kernel/sysctl.c:1067: error: 'one' undeclared here (not in a function)
> 
> when one of those is not #defined.

OK, thanks.

--- a/kernel/sysctl.c~mm-add-proc-controls-for-pdflush-threads-fix-99
+++ a/kernel/sysctl.c
@@ -91,10 +91,7 @@ extern int sysctl_nr_trim_pages;
 extern int rcutorture_runnable;
 #endif /* #ifdef CONFIG_RCU_TORTURE_TEST */
 
-/* Constants used for minimum and  maximum */
-#if defined(CONFIG_DETECT_HUNG_TASK) || defined(CONFIG_DETECT_SOFTLOCKUP) || defined(CONFIG_HIGHMEM)
-static int one = 1;
-#endif
+/* Constants used for minimum and maximum */
 #ifdef CONFIG_DETECT_SOFTLOCKUP
 static int sixty = 60;
 static int neg_one = -1;
@@ -105,6 +102,7 @@ static int two = 2;
 #endif
 
 static int zero;
+static int one = 1;
 static unsigned long one_ul = 1;
 static int one_hundred = 100;
 static int one_thousand = 1000;
diff -puN mm/pdflush.c~mm-add-proc-controls-for-pdflush-threads-fix-99 mm/pdflush.c
_

Re: mmotm 2009-02-17-12-33 uploaded

[Jiri Slaby]

On 18.2.2009 00:31, Andrew Morton wrote:
> On Wed, 18 Feb 2009 00:21:01 +0100
> Jiri Slaby<jirislaby@gmail.com>  wrote:
>
>> I'm getting the page fault below everytime during bootup.
>
> It'd be useful to know if bare linux-next does the same thing, please.

Not present at d6b658c (which is one from the mmotm), so this is pure 
-mm thing. Something between 2009-02-14-00-49 and this one.

Re: mmotm 2009-02-17-12-33 uploaded

[Jiri Slaby]

On 18.2.2009 00:21, Jiri Slaby wrote:
> On 17.2.2009 21:33, akpm@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2009-02-17-12-33 has been uploaded to

This one:
kthreads-move-sched-realeted-initialization-from-kthreadd-context.patch

> Hi,
>
> I'm getting the page fault below everytime during bootup. This is how
> __task_rq_lock looks like:
> for (;;) {
> struct rq *rq;
> printk("CPU=%u %p %p %p %s\n", task_cpu(p), p,
> task_thread_info(p)->task,
> task_thread_info(p), p->comm);
> rq = task_rq(p);
> spin_lock(&rq->lock);
> if (likely(rq == task_rq(p)))
> return rq;
> spin_unlock(&rq->lock);
> }
>
> CPU=2303197184 ffff880012497d90 b8005f57df1d8948 ffffffff80262d0a
> migration/0
> BUG: unable to handle kernel paging request at 00000003cabbb780
> IP: [<ffffffff802399eb>] __sched_setscheduler+0x17b/0x4a0
> PGD 0
> Oops: 0000 [#1] SMP
> last sysfs file:
> CPU 0
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.29-rc5-mm1_64 #578
> RIP: 0010:[<ffffffff802399eb>] [<ffffffff802399eb>]
> __sched_setscheduler+0x17b/0x4a0
> RSP: 0018:ffff880012497cc0 EFLAGS: 00000086
> RAX: 0000000089480000 RBX: ffffffff80262d0a RCX: 00000000ffffffff
> RDX: 000000000000d7d7 RSI: 0000000000000046 RDI: ffffffff80835334
> RBP: ffff880012497d30 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000010180
> R13: 0000000000000000 R14: ffff880012497d90 R15: 0000000000010180
> FS: 0000000000000000(0000) GS:ffff880001007000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 00000003cabbb780 CR3: 0000000000201000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
> Process swapper (pid: 1, threadinfo ffff880012496000, task
> ffff880012478000)
> Stack:
> 0000000000000000 ffff880012497dc0 ffff880012498270 ffffffff12478000
> 0000000000000000 ffffffff80262d0a ffff8800124980f0 0000000000000046
> 0000000000000246 ffff880012497d50 ffffffff806f1065 0000000000000000
> Call Trace:
> [<ffffffff80262d0a>] ? tick_check_broadcast_device+0x3a/0x70
> [<ffffffff80239d1b>] sched_setscheduler_nocheck+0xb/0x10
> [<ffffffff80256ad7>] kthread_create+0xe7/0x120
> [<ffffffff8023b820>] ? migration_thread+0x0/0x230
> [<ffffffff80262d0a>] ? tick_check_broadcast_device+0x3a/0x70
> [<ffffffff80262109>] ? tick_notify+0x369/0x410
> [<ffffffff807d9598>] ? migration_init+0x0/0x5c
> [<ffffffff805de278>] migration_call+0x376/0x4ed
> [<ffffffff807d9598>] ? migration_init+0x0/0x5c
> [<ffffffff807d95be>] migration_init+0x26/0x5c
> [<ffffffff807d9598>] ? migration_init+0x0/0x5c
> [<ffffffff8020904c>] do_one_initcall+0x3c/0x170
> [<ffffffff807d31c4>] ? native_smp_prepare_cpus+0x1c0/0x311
> [<ffffffff807ca559>] kernel_init+0x76/0x1bc
> [<ffffffff8020d8da>] child_rip+0xa/0x20
> [<ffffffff807ca4e3>] ? kernel_init+0x0/0x1bc
> [<ffffffff8020d8d0>] ? child_rip+0x0/0x20
> Code: 69 3a 00 49 8b 5e 08 4c 8b 45 08 48 8b 0b ba db 08 00 00 48 c7 c6
> e0 4a 6e 80 48 c7 c7 ce 99 6e 80 31 c0 e8 0b 69 3a 00 8b 43 18 <4c> 03
> 24 c5 80 b7 7b 80 4c 89 e7 e8 e5 97 3a 00 49 8b 5e 08 31
> RIP [<ffffffff802399eb>] __sched_setscheduler+0x17b/0x4a0
> RSP <ffff880012497cc0>
> CR2: 00000003cabbb780
> ---[ end trace 4eaa2a86a8e2da22 ]---

Re: mmotm 2009-02-17-12-33 uploaded

[Jiri Slaby]

On 18.2.2009 10:19, Jiri Slaby wrote:
> On 18.2.2009 00:21, Jiri Slaby wrote:
>> On 17.2.2009 21:33, akpm@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2009-02-17-12-33 has been uploaded to
>
> This one:
> kthreads-move-sched-realeted-initialization-from-kthreadd-context.patch

This hunk fixes the problem for me. I have no idea if it is correct though.

diff --git a/kernel/kthread.c b/kernel/kthread.c
index c1c3763..caed471 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -73,6 +73,7 @@ static int kthread(void *_create)

         /* OK, tell user we're spawned, wait for stop or wakeup */
         __set_current_state(TASK_UNINTERRUPTIBLE);
+       create->result = current;
         complete(&create->done);
         schedule();

Re: mmotm 2009-02-17-12-33 uploaded

[Andrew Morton]

On Wed, 18 Feb 2009 10:35:23 +0100 Jiri Slaby <jirislaby@gmail.com> wrote:

> On 18.2.2009 10:19, Jiri Slaby wrote:
> > On 18.2.2009 00:21, Jiri Slaby wrote:
> >> On 17.2.2009 21:33, akpm@linux-foundation.org wrote:
> >>> The mm-of-the-moment snapshot 2009-02-17-12-33 has been uploaded to
> >
> > This one:
> > kthreads-move-sched-realeted-initialization-from-kthreadd-context.patch
> 
> This hunk fixes the problem for me. I have no idea if it is correct though.
> 
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index c1c3763..caed471 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -73,6 +73,7 @@ static int kthread(void *_create)
> 
>          /* OK, tell user we're spawned, wait for stop or wakeup */
>          __set_current_state(TASK_UNINTERRUPTIBLE);
> +       create->result = current;
>          complete(&create->done);
>          schedule();

hm, it does seem to forget to initialise ->result on the success path.

Someone else has been mucking with kthread.c in linux-next, and a
couple of days ago that mucking got dropped from linux-next.  Perhaps
this churn broke Oleg's patch.

And if it was Stephen who dropped the offending tree, that mucking
about will come back soon and will re-muck things up.

<checks>

	Undropped tree:
		rr

And what does that do?  yup,

--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -76,6 +76,7 @@ static int kthread(void *_create)
 
 	/* OK, tell user we're spawned, wait for stop or wakeup */
 	__set_current_state(TASK_UNINTERRUPTIBLE);
+	create->result = current;
 	complete(&create->started);
 	schedule();
 

guys, please stop mucking things up?

Re: mmotm 2009-02-17-12-33 uploaded

[Rusty Russell]

On Wednesday 18 February 2009 20:23:56 Andrew Morton wrote:
> Someone else has been mucking with kthread.c in linux-next, and a
> couple of days ago that mucking got dropped from linux-next.  Perhaps
> this churn broke Oleg's patch.

Err, yes.

Oleg and I had an accidentally-offlist chat about these patches.

Last we decided, a more ambitious approach was desired.  Patches RSN.

I've taken kthreads-move-sched-realeted-initialization-from-kthreadd-context.patch
though, thanks!

Cheers,
Rusty.

Re: mmotm 2009-02-17-12-33 uploaded

[Oleg Nesterov]

On 02/18, Rusty Russell wrote:
>
> On Wednesday 18 February 2009 20:23:56 Andrew Morton wrote:
> > Someone else has been mucking with kthread.c in linux-next, and a
> > couple of days ago that mucking got dropped from linux-next.  Perhaps
> > this churn broke Oleg's patch.

"[merged] kthread-dont-looking-for-a-task-in-create_kthread-2.patch"
has "create->result = current;" in kthread(), then this line was
lost somehow,

> Oleg and I had an accidentally-offlist chat about these patches.
>
> Last we decided, a more ambitious approach was desired.  Patches RSN.

Yes, but can't we do this on top of current patches?

We are going to change the API a bit, so that kthread_create() bumps
a reference to task_struct. I think it would be nice to separate the
API changes from the implementation changes.

Oleg.

Re: mmotm 2009-02-17-12-33 uploaded

[Oleg Nesterov]

Rusty, Andrew,

On 02/18, Oleg Nesterov wrote:
>
> On 02/18, Rusty Russell wrote:
> >
> > On Wednesday 18 February 2009 20:23:56 Andrew Morton wrote:
> > > Someone else has been mucking with kthread.c in linux-next, and a
> > > couple of days ago that mucking got dropped from linux-next.  Perhaps
> > > this churn broke Oleg's patch.
>
> "[merged] kthread-dont-looking-for-a-task-in-create_kthread-2.patch"
> has "create->result = current;" in kthread(), then this line was
> lost somehow,
>
> > Oleg and I had an accidentally-offlist chat about these patches.
> >
> > Last we decided, a more ambitious approach was desired.  Patches RSN.
>
> Yes, but can't we do this on top of current patches?
>
> We are going to change the API a bit, so that kthread_create() bumps
> a reference to task_struct. I think it would be nice to separate the
> API changes from the implementation changes.

So, what happened with

	kthreads-simplify-the-startup-synchronization.patch
	http://marc.info/?l=linux-mm-commits&m=123335224710768

	kthreads-rework-kthread_stop.patch
	http://marc.info/?l=linux-mm-commits&m=123335227910835

patches? Can't find them in any tree.

Oleg.

Re: mmotm 2009-02-17-12-33 uploaded

[Andrew Morton]

On Tue, 28 Apr 2009 21:22:19 +0200
Oleg Nesterov <oleg@redhat.com> wrote:

> So, what happened with
> 
> 	kthreads-simplify-the-startup-synchronization.patch
> 	http://marc.info/?l=linux-mm-commits&m=123335224710768
> 
> 	kthreads-rework-kthread_stop.patch
> 	http://marc.info/?l=linux-mm-commits&m=123335227910835
> 
> patches? Can't find them in any tree.

I seem to have had an administrative error.  I think the patches were
temporarily parked because people were madly changing things under my feet,
and they didn't get unparked.

I've just restored

kthreads-simplify-the-startup-synchronization.patch
kthreads-rework-kthread_stop.patch
kthreads-simplify-migration_thread-exit-path.patch

and I'll send them out again.

I hope nothing else got lost.  They're the only *kthread* patches which
I can see here.

Re: mmotm 2009-02-17-12-33 uploaded

[Oleg Nesterov]

On 04/28, Andrew Morton wrote:
>
> kthreads-simplify-the-startup-synchronization.patch
> kthreads-rework-kthread_stop.patch
> kthreads-simplify-migration_thread-exit-path.patch
>
> and I'll send them out again.

Thanks!

> I hope nothing else got lost.  They're the only *kthread* patches which
> I can see here.

Yes, there was nothing else kthread-related.

Oleg.