All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Ying <ying.huang@intel.com>
To: Pavel Machek <pavel@suse.cz>
Cc: nigel@nigel.suspend2.net,
	Kexec Mailing List <kexec@lists.infradead.org>,
	linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-pm@lists.linux-foundation.org,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH -mm 1/2] kexec jump -v12: kexec jump
Date: Tue, 08 Jul 2008 17:10:09 +0800	[thread overview]
Message-ID: <1215508209.29894.8.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <20080707125010.GA21254@elf.ucw.cz>

Hi, Pavel,

On Mon, 2008-07-07 at 20:50 +0800, Pavel Machek wrote:
> Hi!
> 
> The patch looks mostly ok to me. (Perhaps there's time to split it
> into smaller chunks?)
> 
> You can add Acked-by: Pavel Machek <pavel@suse.cz> to it, I guess.

Thank you very much!

[...]
> > @@ -98,16 +101,24 @@ int machine_kexec_prepare(struct kimage
> >   */
> >  void machine_kexec_cleanup(struct kimage *image)
> >  {
> > +     if (nx_enabled)
> > +             set_pages_nx(image->control_code_page, 1);
> >  }
> 
> , 0 ? (setup and cleanup were same, which is strange).

Oh, Yes. That should be 0, I will change it.
> 
> > @@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
> >  }
> > 
> >  module_init(crash_save_vmcoreinfo_init)
> > +
> > +/**
> > + *   kernel_kexec - reboot the system

> Really?

I will change the comments to reflect the changes to kernel_kexec.

> > + *   Move into place and start executing a preloaded standalone
> > + *   executable.  If nothing was preloaded return an error.
> > + */
> > +int kernel_kexec(void)
> > +{
> > +     int error = 0;
> > +
> > +     if (xchg(&kexec_lock, 1))
> > +             return -EBUSY;
> 
> That's quite a strange way to provide a lock. mutex_trylock?

I think this is because kexec_lock is used by crash_kexec() too, which
may be called in some extreme environment, such as during panic().

> > +     if (!kexec_image) {
> > +             error = -EINVAL;
> > +             goto Unlock;
> > +     }
> > +
> > +     if (kexec_image->preserve_context) {
> > +#ifdef CONFIG_KEXEC_JUMP
> > +             local_irq_disable();
> > +             save_processor_state();
> 
> #else
>         BUG()
> 
> ...because otherwise you silently do nothing?
> 
> > +#endif
> 
> Pavel

If CONFIG_KEXEC_JUMP is defined, kexec_image->preserve_context will
always be 0. So current code is safe. Here, #ifdef is used to resolve
the dependency issue. For example, save_processor_state() may be
undefined if CONFIG_KEXEC_JUMP is not defined.

Best Regards,
Huang Ying



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Huang Ying <ying.huang@intel.com>
To: Pavel Machek <pavel@suse.cz>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	nigel@nigel.suspend2.net, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vivek Goyal <vgoyal@redhat.com>,
	linux-kernel@vger.kernel.org,
	linux-pm@lists.linux-foundation.org,
	Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: [PATCH -mm 1/2] kexec jump -v12: kexec jump
Date: Tue, 08 Jul 2008 17:10:09 +0800	[thread overview]
Message-ID: <1215508209.29894.8.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <20080707125010.GA21254@elf.ucw.cz>

Hi, Pavel,

On Mon, 2008-07-07 at 20:50 +0800, Pavel Machek wrote:
> Hi!
> 
> The patch looks mostly ok to me. (Perhaps there's time to split it
> into smaller chunks?)
> 
> You can add Acked-by: Pavel Machek <pavel@suse.cz> to it, I guess.

Thank you very much!

[...]
> > @@ -98,16 +101,24 @@ int machine_kexec_prepare(struct kimage
> >   */
> >  void machine_kexec_cleanup(struct kimage *image)
> >  {
> > +     if (nx_enabled)
> > +             set_pages_nx(image->control_code_page, 1);
> >  }
> 
> , 0 ? (setup and cleanup were same, which is strange).

Oh, Yes. That should be 0, I will change it.
> 
> > @@ -1411,3 +1421,50 @@ static int __init crash_save_vmcoreinfo_
> >  }
> > 
> >  module_init(crash_save_vmcoreinfo_init)
> > +
> > +/**
> > + *   kernel_kexec - reboot the system

> Really?

I will change the comments to reflect the changes to kernel_kexec.

> > + *   Move into place and start executing a preloaded standalone
> > + *   executable.  If nothing was preloaded return an error.
> > + */
> > +int kernel_kexec(void)
> > +{
> > +     int error = 0;
> > +
> > +     if (xchg(&kexec_lock, 1))
> > +             return -EBUSY;
> 
> That's quite a strange way to provide a lock. mutex_trylock?

I think this is because kexec_lock is used by crash_kexec() too, which
may be called in some extreme environment, such as during panic().

> > +     if (!kexec_image) {
> > +             error = -EINVAL;
> > +             goto Unlock;
> > +     }
> > +
> > +     if (kexec_image->preserve_context) {
> > +#ifdef CONFIG_KEXEC_JUMP
> > +             local_irq_disable();
> > +             save_processor_state();
> 
> #else
>         BUG()
> 
> ...because otherwise you silently do nothing?
> 
> > +#endif
> 
> Pavel

If CONFIG_KEXEC_JUMP is defined, kexec_image->preserve_context will
always be 0. So current code is safe. Here, #ifdef is used to resolve
the dependency issue. For example, save_processor_state() may be
undefined if CONFIG_KEXEC_JUMP is not defined.

Best Regards,
Huang Ying



  parent reply	other threads:[~2008-07-08  9:05 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-07  3:25 [PATCH -mm 1/2] kexec jump -v12: kexec jump Huang Ying
2008-07-07  3:25 ` Huang Ying
2008-07-07 12:50 ` Pavel Machek
2008-07-07 12:50   ` Pavel Machek
2008-07-08  9:10   ` Huang Ying
2008-07-08  9:10   ` Huang Ying [this message]
2008-07-08  9:10     ` Huang Ying
2008-07-08 10:40     ` Pavel Machek
2008-07-08 10:40     ` Pavel Machek
2008-07-08 10:40       ` Pavel Machek
2008-07-09  1:12       ` Huang Ying
2008-07-09  1:12       ` Huang Ying
2008-07-09  1:12         ` Huang Ying
2008-07-07 12:50 ` Pavel Machek
2008-07-08 14:50 ` Vivek Goyal
2008-07-08 14:50 ` Vivek Goyal
2008-07-08 14:50   ` Vivek Goyal
2008-07-09  1:09   ` Huang Ying
2008-07-09  1:09   ` Huang Ying
2008-07-09  1:09     ` Huang Ying
2008-07-11 19:21   ` Andrew Morton
2008-07-11 19:21     ` Andrew Morton
2008-07-11 20:11     ` Vivek Goyal
2008-07-11 20:11     ` Vivek Goyal
2008-07-11 20:11       ` Vivek Goyal
2008-07-12  1:02       ` Nigel Cunningham
2008-07-12  1:02         ` Nigel Cunningham
2008-07-14  5:46         ` Pavel Machek
2008-07-14  5:46         ` Pavel Machek
2008-07-14  5:46           ` Pavel Machek
2008-07-14 13:32           ` Vivek Goyal
2008-07-14 13:32           ` Vivek Goyal
2008-07-14 13:32             ` Vivek Goyal
2008-08-04 11:01             ` Pavel Machek
2008-08-04 11:01               ` Pavel Machek
2008-08-04 11:01             ` Pavel Machek
2008-07-14 13:09         ` Vivek Goyal
2008-07-14 13:09           ` Vivek Goyal
2008-07-14 13:09         ` Vivek Goyal
2008-07-12  1:02       ` Nigel Cunningham
2008-07-11 20:24     ` Pavel Machek
2008-07-11 20:24     ` Pavel Machek
2008-07-11 20:24       ` Pavel Machek
2008-07-11 20:40       ` Rafael J. Wysocki
2008-07-11 20:40         ` Rafael J. Wysocki
2008-07-12  2:23         ` Eric W. Biederman
2008-07-12  2:23         ` Eric W. Biederman
2008-07-12  2:23           ` Eric W. Biederman
2008-07-12  3:04           ` [linux-pm] " Alan Stern
2008-07-12  3:04             ` Alan Stern
2008-07-12  3:50             ` Eric W. Biederman
2008-07-12  3:50             ` [linux-pm] " Eric W. Biederman
2008-07-12  3:50               ` Eric W. Biederman
2008-07-12 18:52               ` Rafael J. Wysocki
2008-07-12 18:52               ` [linux-pm] " Rafael J. Wysocki
2008-07-12 18:52                 ` Rafael J. Wysocki
2008-07-12 19:55               ` Alan Stern
2008-07-12 19:55                 ` Alan Stern
2008-07-12 19:55               ` Alan Stern
2008-07-12  3:04           ` Alan Stern
2008-07-11 20:40       ` Rafael J. Wysocki
2008-07-14 13:30     ` huang ying
2008-07-14 13:30     ` huang ying
2008-07-14 13:30     ` huang ying
2008-07-14 13:30       ` huang ying
2008-07-11 19:21   ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2008-07-07  3:25 Huang Ying

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=1215508209.29894.8.camel@caritas-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=nigel@nigel.suspend2.net \
    --cc=pavel@suse.cz \
    --cc=rjw@sisk.pl \
    --cc=vgoyal@redhat.com \
    /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 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.