All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Price <gourry@gourry.net>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, bhelgaas@google.com,
	ilpo.jarvinen@linux.intel.com, mika.westerberg@linux.intel.com,
	ying.huang@intel.com, bhe@redhat.com, tglx@linutronix.de,
	takahiro.akashi@linaro.org, stable@vger.kernel.org
Subject: Re: [PATCH] resource,kexec: walk_system_ram_res_rev must retain resource flags
Date: Fri, 18 Oct 2024 09:38:37 -0400	[thread overview]
Message-ID: <ZxJk3RYDTpYkELCa@PC2K9PVX.TheFacebook.com> (raw)
In-Reply-To: <ZxJbOinZ0E4Ppmak@smile.fi.intel.com>

On Fri, Oct 18, 2024 at 03:57:30PM +0300, Andy Shevchenko wrote:
> On Thu, Oct 17, 2024 at 03:03:47PM -0400, Gregory Price wrote:
> > walk_system_ram_res_rev() erroneously discards resource flags when
> > passing the information to the callback.
> > 
> > This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to
> > have these resources selected during kexec to store kexec buffers
> > if that memory happens to be at placed above normal system ram.
> > 
> > This leads to undefined behavior after reboot. If the kexec buffer
> > is never touched, nothing happens. If the kexec buffer is touched,
> > it could lead to a crash (like below) or undefined behavior.
> > 
> > Tested on a system with CXL memory expanders with driver managed
> > memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's
> > showed the flags were being discarded and as a result the check
> > for IORESOURCE_SYSRAM_DRIVER_MANAGED passes.
> > 
> > find_next_iomem_res: name(System RAM (kmem))
> > 		     start(10000000000)
> > 		     end(1034fffffff)
> > 		     flags(83000200)
> > 
> > locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0)
> > 
> > [.] BUG: unable to handle page fault for address: ffff89834ffff000
> 
> Please, cut this down to only important ~3-5 lines as suggested in
> the Submitting Patches documentation.
> 
> Yeah, I see that Andrew applied it to hist testing branch, if it's not going to
> be updated there, consider above as a hint for the future contributions with
> backtraces.
>

noted, thank you!
 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

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

WARNING: multiple messages have this Message-ID (diff)
From: Gregory Price <gourry@gourry.net>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, bhelgaas@google.com,
	ilpo.jarvinen@linux.intel.com, mika.westerberg@linux.intel.com,
	ying.huang@intel.com, bhe@redhat.com, tglx@linutronix.de,
	takahiro.akashi@linaro.org, stable@vger.kernel.org
Subject: Re: [PATCH] resource,kexec: walk_system_ram_res_rev must retain resource flags
Date: Fri, 18 Oct 2024 09:38:37 -0400	[thread overview]
Message-ID: <ZxJk3RYDTpYkELCa@PC2K9PVX.TheFacebook.com> (raw)
In-Reply-To: <ZxJbOinZ0E4Ppmak@smile.fi.intel.com>

On Fri, Oct 18, 2024 at 03:57:30PM +0300, Andy Shevchenko wrote:
> On Thu, Oct 17, 2024 at 03:03:47PM -0400, Gregory Price wrote:
> > walk_system_ram_res_rev() erroneously discards resource flags when
> > passing the information to the callback.
> > 
> > This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to
> > have these resources selected during kexec to store kexec buffers
> > if that memory happens to be at placed above normal system ram.
> > 
> > This leads to undefined behavior after reboot. If the kexec buffer
> > is never touched, nothing happens. If the kexec buffer is touched,
> > it could lead to a crash (like below) or undefined behavior.
> > 
> > Tested on a system with CXL memory expanders with driver managed
> > memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's
> > showed the flags were being discarded and as a result the check
> > for IORESOURCE_SYSRAM_DRIVER_MANAGED passes.
> > 
> > find_next_iomem_res: name(System RAM (kmem))
> > 		     start(10000000000)
> > 		     end(1034fffffff)
> > 		     flags(83000200)
> > 
> > locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0)
> > 
> > [.] BUG: unable to handle page fault for address: ffff89834ffff000
> 
> Please, cut this down to only important ~3-5 lines as suggested in
> the Submitting Patches documentation.
> 
> Yeah, I see that Andrew applied it to hist testing branch, if it's not going to
> be updated there, consider above as a hint for the future contributions with
> backtraces.
>

noted, thank you!
 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

  reply	other threads:[~2024-10-18 13:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-17 19:03 [PATCH] resource,kexec: walk_system_ram_res_rev must retain resource flags Gregory Price
2024-10-17 19:03 ` Gregory Price
2024-10-17 20:52 ` Dan Williams
2024-10-17 20:52   ` Dan Williams
2024-10-18  2:18 ` Baoquan He
2024-10-18  2:18   ` Baoquan He
2024-10-18 12:22   ` Andy Shevchenko
2024-10-18 12:22     ` Andy Shevchenko
2024-10-18 13:52     ` Baoquan He
2024-10-18 13:52       ` Baoquan He
2024-10-18 14:51       ` Andy Shevchenko
2024-10-18 14:51         ` Andy Shevchenko
2024-10-18 14:52         ` Andy Shevchenko
2024-10-18 14:52           ` Andy Shevchenko
2024-10-18 15:39           ` Baoquan He
2024-10-18 15:39             ` Baoquan He
2024-10-18 15:57             ` Andy Shevchenko
2024-10-18 15:57               ` Andy Shevchenko
2024-10-18 12:57 ` Andy Shevchenko
2024-10-18 12:57   ` Andy Shevchenko
2024-10-18 13:38   ` Gregory Price [this message]
2024-10-18 13:38     ` Gregory Price

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=ZxJk3RYDTpYkELCa@PC2K9PVX.TheFacebook.com \
    --to=gourry@gourry.net \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bhe@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=stable@vger.kernel.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=ying.huang@intel.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.