All of lore.kernel.org
 help / color / mirror / Atom feed
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.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: Tue, 09 Jul 2013 14:31:21 +0900	[thread overview]
Message-ID: <51DBA029.3060009@jp.fujitsu.com> (raw)
In-Reply-To: <20130708112839.498ccfc6@holzheu>

(2013/07/08 18:28), 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 meant without modifying source code at all. You say I need to define some function.

<cut>
>>
>>> +static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>>> +{
>>> +	struct address_space *mapping = vma->vm_file->f_mapping;
>>> +	pgoff_t index = vmf->pgoff;
>>> +	struct page *page;
>>> +	loff_t src;
>>> +	char *buf;
>>> +	int rc;
>>> +
>>
>> You should check where faulting address points to valid range.
>> If the fault happens on invalid range, return VM_FAULT_SIGBUS.
>>
>> On s390 case, I think the range except for HSA should be thought of as invalid.
>>
>
> Hmmm, this would require another architecture backend interface. If we get a fault
> for a page outside of the HSA this would be a programming error in our code. Not
> sure if we should introduce new architecture interfaces just for sanity checks.
>

I think you need to introduce the backend interface since it's bug if it happens.
The current implementation hides such erroneous path due to generic implementation.

I also don't think it's big change from this version since you have already been
about to introduce several backend interfaces.

>>> +	page = find_or_create_page(mapping, index, GFP_KERNEL);
>>> +	if (!page)
>>> +		return VM_FAULT_OOM;
>>> +	if (!PageUptodate(page)) {
>>> +		src = index << PAGE_CACHE_SHIFT;
>>
>> src = (loff_t)index << PAGE_CACHE_SHIFT;
>>
>> loff_t has long long while index has unsigned long.
>
> Ok.
>
>> On s390 both might have the same byte length.
>
> On s390x both are 64 bit. On our 32 bit s390 archtecture long long is 64 bit
> and unsigned long 32 bit.
>
>> Also I prefer offset to src, but this is minor suggestion.
>
> Yes, I agree.
>
>>
>>> +		buf = (void *) (page_to_pfn(page) << PAGE_SHIFT);
>>
>> I found page_to_virt() macro.
>
> Looks like page_to_virt() is not usable on most architectures and probably
> pfn_to_kaddr(pfn) would be the correct thing here. Unfortunately is also not
> defined on s390.
>
> But when I discussed your comment with Martin, we found out that the current
>
> buf = (void *) (page_to_pfn(page) << PAGE_SHIFT);
>
> is not correct on x86. It should be:
>
> buf = __va((page_to_pfn(page) << PAGE_SHIFT));
>

It seems OK for this.

-- 
Thanks.
HATAYAMA, Daisuke


WARNING: multiple messages have this Message-ID (diff)
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.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,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH v6 3/5] vmcore: Introduce remap_oldmem_pfn_range()
Date: Tue, 09 Jul 2013 14:31:21 +0900	[thread overview]
Message-ID: <51DBA029.3060009@jp.fujitsu.com> (raw)
In-Reply-To: <20130708112839.498ccfc6@holzheu>

(2013/07/08 18:28), 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 meant without modifying source code at all. You say I need to define some function.

<cut>
>>
>>> +static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>>> +{
>>> +	struct address_space *mapping = vma->vm_file->f_mapping;
>>> +	pgoff_t index = vmf->pgoff;
>>> +	struct page *page;
>>> +	loff_t src;
>>> +	char *buf;
>>> +	int rc;
>>> +
>>
>> You should check where faulting address points to valid range.
>> If the fault happens on invalid range, return VM_FAULT_SIGBUS.
>>
>> On s390 case, I think the range except for HSA should be thought of as invalid.
>>
>
> Hmmm, this would require another architecture backend interface. If we get a fault
> for a page outside of the HSA this would be a programming error in our code. Not
> sure if we should introduce new architecture interfaces just for sanity checks.
>

I think you need to introduce the backend interface since it's bug if it happens.
The current implementation hides such erroneous path due to generic implementation.

I also don't think it's big change from this version since you have already been
about to introduce several backend interfaces.

>>> +	page = find_or_create_page(mapping, index, GFP_KERNEL);
>>> +	if (!page)
>>> +		return VM_FAULT_OOM;
>>> +	if (!PageUptodate(page)) {
>>> +		src = index << PAGE_CACHE_SHIFT;
>>
>> src = (loff_t)index << PAGE_CACHE_SHIFT;
>>
>> loff_t has long long while index has unsigned long.
>
> Ok.
>
>> On s390 both might have the same byte length.
>
> On s390x both are 64 bit. On our 32 bit s390 archtecture long long is 64 bit
> and unsigned long 32 bit.
>
>> Also I prefer offset to src, but this is minor suggestion.
>
> Yes, I agree.
>
>>
>>> +		buf = (void *) (page_to_pfn(page) << PAGE_SHIFT);
>>
>> I found page_to_virt() macro.
>
> Looks like page_to_virt() is not usable on most architectures and probably
> pfn_to_kaddr(pfn) would be the correct thing here. Unfortunately is also not
> defined on s390.
>
> But when I discussed your comment with Martin, we found out that the current
>
> buf = (void *) (page_to_pfn(page) << PAGE_SHIFT);
>
> is not correct on x86. It should be:
>
> buf = __va((page_to_pfn(page) << PAGE_SHIFT));
>

It seems OK for this.

-- 
Thanks.
HATAYAMA, Daisuke


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

  parent reply	other threads:[~2013-07-09  5:32 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
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 [this message]
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=51DBA029.3060009@jp.fujitsu.com \
    --to=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=vgoyal@redhat.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.