All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: kexec@lists.infradead.org,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Jan Willeke <willeke@de.ibm.com>,
	linux-kernel@vger.kernel.org,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v6 3/5] vmcore: Introduce remap_oldmem_pfn_range()
Date: Mon, 8 Jul 2013 10:28:26 -0400	[thread overview]
Message-ID: <20130708142826.GA9094@redhat.com> (raw)
In-Reply-To: <20130708112839.498ccfc6@holzheu>

On Mon, Jul 08, 2013 at 11:28:39AM +0200, Michael Holzheu wrote:
> On Mon, 08 Jul 2013 14:32:09 +0900
> HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> 
> > (2013/07/02 4:32), Michael Holzheu wrote:
> > > For zfcpdump we can't map the HSA storage because it is only available
> > > via a read interface. Therefore, for the new vmcore mmap feature we have
> > > introduce a new mechanism to create mappings on demand.
> > >
> > > This patch introduces a new architecture function remap_oldmem_pfn_range()
> > > that should be used to create mappings with remap_pfn_range() for oldmem
> > > areas that can be directly mapped. For zfcpdump this is everything besides
> > > of the HSA memory. For the areas that are not mapped by remap_oldmem_pfn_range()
> > > a generic vmcore a new generic vmcore fault handler mmap_vmcore_fault()
> > > is called.
> > >
> > 
> > This fault handler is only for s390 specific issue. Other architectures don't need
> > this for the time being.
> > 
> > Also, from the same reason, I'm doing this review based on source code only.
> > I cannot run the fault handler on meaningful system, which is currently s390 only.
> 
> You can test the code on other architectures if you do not map anything in advance.
> For example you could just "return 0" in remap_oldmem_pfn_range():
> 
> /*
>  * Architectures may override this function to map oldmem
>  */
> int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
>                                   unsigned long from, unsigned long pfn,
>                                   unsigned long size, pgprot_t prot)
> {
>         return 0;
> }
> 
> In that case for all pages the new mechanism would be used.
> 
> > 
> > I'm also concerned about the fault handler covers a full range of vmcore, which
> > could hide some kind of mmap() bug that results in page fault.
> > 
> > So, the fault handler should be enclosed by ifdef CONFIG_S390 for the time being.
> 
> I personally do not like that, but if Vivek and you prefer this, of course we
> can do that.
> 
> What about something like:
> 
> #ifdef CONFIG_S390
> static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> {
> ...
> }
> #else
> static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> {
> 	BUG();
> }
> #endif

I personally perfer not to special case it for s390 only and let the
handler be generic. 

If there is a bug in remap_old_pfn_range(), only side affect is that
we will fault in the page when it is accessed and that will be slow. BUG()
sounds excessive. At max it could be WARN_ONCE().

In regular cases for x86, this path should not even hit. So special casing
it to detect issues with remap_old_pfn_range() does not sound very good
to me. I would rather leave it as it is and if there are bugs and mmap()
slows down, then somebody needs to debug it.

Thanks
Vivek

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

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	kexec@lists.infradead.org,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Jan Willeke <willeke@de.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 3/5] vmcore: Introduce remap_oldmem_pfn_range()
Date: Mon, 8 Jul 2013 10:28:26 -0400	[thread overview]
Message-ID: <20130708142826.GA9094@redhat.com> (raw)
In-Reply-To: <20130708112839.498ccfc6@holzheu>

On Mon, Jul 08, 2013 at 11:28:39AM +0200, Michael Holzheu wrote:
> On Mon, 08 Jul 2013 14:32:09 +0900
> HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> 
> > (2013/07/02 4:32), Michael Holzheu wrote:
> > > For zfcpdump we can't map the HSA storage because it is only available
> > > via a read interface. Therefore, for the new vmcore mmap feature we have
> > > introduce a new mechanism to create mappings on demand.
> > >
> > > This patch introduces a new architecture function remap_oldmem_pfn_range()
> > > that should be used to create mappings with remap_pfn_range() for oldmem
> > > areas that can be directly mapped. For zfcpdump this is everything besides
> > > of the HSA memory. For the areas that are not mapped by remap_oldmem_pfn_range()
> > > a generic vmcore a new generic vmcore fault handler mmap_vmcore_fault()
> > > is called.
> > >
> > 
> > This fault handler is only for s390 specific issue. Other architectures don't need
> > this for the time being.
> > 
> > Also, from the same reason, I'm doing this review based on source code only.
> > I cannot run the fault handler on meaningful system, which is currently s390 only.
> 
> You can test the code on other architectures if you do not map anything in advance.
> For example you could just "return 0" in remap_oldmem_pfn_range():
> 
> /*
>  * Architectures may override this function to map oldmem
>  */
> int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
>                                   unsigned long from, unsigned long pfn,
>                                   unsigned long size, pgprot_t prot)
> {
>         return 0;
> }
> 
> In that case for all pages the new mechanism would be used.
> 
> > 
> > I'm also concerned about the fault handler covers a full range of vmcore, which
> > could hide some kind of mmap() bug that results in page fault.
> > 
> > So, the fault handler should be enclosed by ifdef CONFIG_S390 for the time being.
> 
> I personally do not like that, but if Vivek and you prefer this, of course we
> can do that.
> 
> What about something like:
> 
> #ifdef CONFIG_S390
> static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> {
> ...
> }
> #else
> static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> {
> 	BUG();
> }
> #endif

I personally perfer not to special case it for s390 only and let the
handler be generic. 

If there is a bug in remap_old_pfn_range(), only side affect is that
we will fault in the page when it is accessed and that will be slow. BUG()
sounds excessive. At max it could be WARN_ONCE().

In regular cases for x86, this path should not even hit. So special casing
it to detect issues with remap_old_pfn_range() does not sound very good
to me. I would rather leave it as it is and if there are bugs and mmap()
slows down, then somebody needs to debug it.

Thanks
Vivek

  reply	other threads:[~2013-07-08 14:29 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-01 19:32 [PATCH v6 0/5] kdump: Allow ELF header creation in new kernel Michael Holzheu
2013-07-01 19:32 ` Michael Holzheu
2013-07-01 19:32 ` [PATCH v6 1/5] vmcore: Introduce ELF header in new memory feature Michael Holzheu
2013-07-01 19:32   ` Michael Holzheu
2013-07-02 15:27   ` Vivek Goyal
2013-07-02 15:27     ` Vivek Goyal
2013-07-01 19:32 ` [PATCH v6 2/5] s390/vmcore: Use " Michael Holzheu
2013-07-01 19:32   ` Michael Holzheu
2013-07-02 16:23   ` Vivek Goyal
2013-07-02 16:23     ` Vivek Goyal
2013-07-03  7:59     ` Michael Holzheu
2013-07-03  7:59       ` Michael Holzheu
2013-07-03 14:15       ` Vivek Goyal
2013-07-03 14:15         ` Vivek Goyal
2013-07-03 14:39         ` Michael Holzheu
2013-07-03 14:39           ` Michael Holzheu
2013-07-03 14:50           ` Vivek Goyal
2013-07-03 14:50             ` Vivek Goyal
2013-07-01 19:32 ` [PATCH v6 3/5] vmcore: Introduce remap_oldmem_pfn_range() Michael Holzheu
2013-07-01 19:32   ` Michael Holzheu
2013-07-02 15:42   ` Vivek Goyal
2013-07-02 15:42     ` Vivek Goyal
2013-07-03 13:59     ` Michael Holzheu
2013-07-03 13:59       ` Michael Holzheu
2013-07-03 14:16       ` Vivek Goyal
2013-07-03 14:16         ` Vivek Goyal
2013-07-15 13:44     ` Michael Holzheu
2013-07-15 13:44       ` Michael Holzheu
2013-07-15 14:27       ` Vivek Goyal
2013-07-15 14:27         ` Vivek Goyal
2013-07-16  9:25         ` Michael Holzheu
2013-07-16  9:25           ` Michael Holzheu
2013-07-16 14:04           ` Vivek Goyal
2013-07-16 14:04             ` Vivek Goyal
2013-07-16 15:37             ` Michael Holzheu
2013-07-16 15:37               ` Michael Holzheu
2013-07-16 15:55               ` Vivek Goyal
2013-07-16 15:55                 ` Vivek Goyal
2013-07-08  5:32   ` HATAYAMA Daisuke
2013-07-08  5:32     ` HATAYAMA Daisuke
2013-07-08  9:28     ` Michael Holzheu
2013-07-08  9:28       ` Michael Holzheu
2013-07-08 14:28       ` Vivek Goyal [this message]
2013-07-08 14:28         ` Vivek Goyal
2013-07-09  5:49         ` HATAYAMA Daisuke
2013-07-09  5:49           ` HATAYAMA Daisuke
2013-07-10  8:42           ` Michael Holzheu
2013-07-10  8:42             ` Michael Holzheu
2013-07-10  9:50             ` HATAYAMA Daisuke
2013-07-10  9:50               ` HATAYAMA Daisuke
2013-07-10 11:00               ` Michael Holzheu
2013-07-10 11:00                 ` Michael Holzheu
2013-07-12 16:02                 ` HATAYAMA Daisuke
2013-07-12 16:02                   ` HATAYAMA Daisuke
2013-07-15  9:21                   ` Martin Schwidefsky
2013-07-15  9:21                     ` Martin Schwidefsky
2013-07-16  0:51                     ` HATAYAMA Daisuke
2013-07-16  0:51                       ` HATAYAMA Daisuke
2013-07-10 14:33               ` Vivek Goyal
2013-07-10 14:33                 ` Vivek Goyal
2013-07-12 11:05                 ` HATAYAMA Daisuke
2013-07-12 11:05                   ` HATAYAMA Daisuke
2013-07-15 14:20                   ` Vivek Goyal
2013-07-15 14:20                     ` Vivek Goyal
2013-07-16  0:27                     ` HATAYAMA Daisuke
2013-07-16  0:27                       ` HATAYAMA Daisuke
2013-07-16  9:40                       ` HATAYAMA Daisuke
2013-07-16  9:40                         ` HATAYAMA Daisuke
2013-07-09  5:31       ` HATAYAMA Daisuke
2013-07-09  5:31         ` HATAYAMA Daisuke
2013-07-01 19:32 ` [PATCH v6 4/5] s390/vmcore: Implement remap_oldmem_pfn_range for s390 Michael Holzheu
2013-07-01 19:32   ` Michael Holzheu
2013-07-01 19:32 ` [PATCH v6 5/5] s390/vmcore: Use vmcore for zfcpdump Michael Holzheu
2013-07-01 19:32   ` Michael Holzheu

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=20130708142826.GA9094@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=holzheu@linux.vnet.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=willeke@de.ibm.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.