public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger <davidm@napali.hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] Kernel panic on IA-64 Linux with SELinux
Date: Tue, 15 Jun 2004 04:23:38 +0000	[thread overview]
Message-ID: <16590.31178.360206.284780@napali.hpl.hp.com> (raw)
In-Reply-To: <013f01c44ddb$636d4aa0$f97d220a@linux.bs1.fc.nec.co.jp>

Hi Kaigai,

Thanks for looking into this issue.

>>>>> On Tue, 15 Jun 2004 11:28:14 +0900, "Kaigai Kohei" <kaigai@ak.jp.nec.com> said:

  Kaigai> I have applied this patch to 2.6.6 kernel, and system stall
  Kaigai> occurred while booting up. The problem is in
  Kaigai> init_mount_tree().  The init_mount_tree() function uses
  Kaigai> do_each_thread() macro defined as follows:

  Kaigai> #define do_each_thread(g, t) \
  Kaigai>   for (g = t = &init_task ; (g = t = next_task(g)) != &init_task ; ) do

Yeah, that'd do it.

  Kaigai> There are several solutions against this problem.

  Kaigai> (1) Initializing only wait_chldexit as my first patch.

  Kaigai> (2) Moving current of swapper from region 7 to region 5 as
  Kaigai> Miyoshi's second patch.

  Kaigai> (3) Replacing &init_task with task_t *p_init_task which
  Kaigai> refers to init_task in region 7, and refers to init_task
  Kaigai> directly on other archtectures.

  Kaigai> (1) is easy but ad hoc. (3) needs to correct generic code.
  Kaigai> (2) is consistent on &init_task is in region 5 and
  Kaigai> current(r13) for cpu_idle refers to region 5. But the number
  Kaigai> of steps in switch_to() macro will increase.  This overhead
  Kaigai> is not a big problem, I guess.

  Kaigai> For reasons already stated I prefer (2). What do you think?

I agree, (2) seems to best solution so far.  It maintains the
invariant that static data will be in region 5.  The extra
instructions should be pretty much free since it should be possible to
schedule them into existing stalls.

Can you resend the tested patch with proper changelog and "Signed-off-by"
trailer?

Thanks,

	--david

  parent reply	other threads:[~2004-06-15  4:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-09  4:36 [PATCH] Kernel panic on IA-64 Linux with SELinux 
2004-06-09 14:40 ` Kazuto MIYOSHI
2004-06-09 21:55 ` David Mosberger
2004-06-09 22:44 ` Luck, Tony
2004-06-09 23:25 ` David Mosberger
2004-06-09 23:35 ` Luck, Tony
2004-06-10  0:58 ` David Mosberger
2004-06-10  5:19 ` Luck, Tony
2004-06-10  5:23 ` David Mosberger
2004-06-10  5:28 ` Luck, Tony
2004-06-15  2:28 ` Kaigai Kohei
2004-06-15  4:17 ` Luck, Tony
2004-06-15  4:23 ` David Mosberger [this message]
2004-06-15  4:25 ` Luck, Tony
2004-06-15  4:25 ` David Mosberger
2004-06-15  9:37 ` Kaigai Kohei
2004-06-15 12:52 ` Kaigai Kohei
2004-06-17  1:10 ` David Mosberger
     [not found] <Xine.LNX.4.44.0406101657420.8385-100000@thoron.boston.redhat.com>
2004-06-11  1:13 ` Kaigai Kohei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16590.31178.360206.284780@napali.hpl.hp.com \
    --to=davidm@napali.hpl.hp.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox