public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC 08/14] s390/mm: Make gmap_read_table EDAT1 compatible
Date: Tue, 16 Oct 2018 08:57:29 +0000	[thread overview]
Message-ID: <cd5a4668-b5ec-beec-c6cb-60f6fbc9ec78@redhat.com> (raw)
In-Reply-To: <979ea4cc-8a85-479c-a03d-9f8b9a9b3487@linux.ibm.com>

>>>  	while (1) {
>>>  		rc = -EAGAIN;
>>> -		ptep = gmap_pte_op_walk(gmap, gaddr, &ptl);
>>> -		if (ptep) {
>>> -			pte = *ptep;
>>> -			if (pte_present(pte) && (pte_val(pte) & _PAGE_READ)) {
>>> -				address = pte_val(pte) & PAGE_MASK;
>>> -				address += gaddr & ~PAGE_MASK;
>>> +		vmaddr = __gmap_translate(gmap, gaddr);
>>> +		if (IS_ERR_VALUE(vmaddr))
>>> +			return vmaddr;
>>> +		pmdp = gmap_pmd_op_walk(gmap, gaddr, vmaddr, &ptl_pmd);
>>> +		if (pmdp && !(pmd_val(*pmdp) & _SEGMENT_ENTRY_INVALID)) {
>>> +			if (!pmd_large(*pmdp)) {
>>> +				ptep = gmap_pte_from_pmd(gmap, pmdp, vmaddr, &ptl_pte);
>>> +				if (ptep) {
>>> +					pte = *ptep;
>>> +					if (pte_present(pte) && (pte_val(pte) & _PAGE_READ)) {
>>> +						address = pte_val(pte) & PAGE_MASK;
>>> +						address += gaddr & ~PAGE_MASK;
>>> +						*val = *(unsigned long *) address;
>>> +						pte_val(*ptep) |= _PAGE_YOUNG;
>>> +						/* Do *NOT* clear the _PAGE_INVALID bit! */
>>> +						rc = 0;
>>> +					}
>>> +				}
>>> +				gmap_pte_op_end(ptl_pte);
>>
>> I'm confused that we have a gmap_pte_op_end() followed by a
>> gmap_pmd_op_end() although we never started a gmap_pte_op_walk() ... I
>> assume this is due to gmap_pte_from_pmd() ? We should find better names
>> for these functions otherwise this is pure magic.
>>
>> e.g. gmap_pte_op_walk_pmd() instead of gmap_pte_from_pmd()
> 
> Hrm, in my opinion pte_from_pmd is very specific, although it lacks the
> op part. How about gmap_pte_op_map, that would be closer to the
> pte_alloc/offset_map from the kernel side?

Yes, as long as there is "op" in there one can see in the code how it
all plays together.

> 
>>
>> ... and shouldn't "gmap_pte_op_end(ptl_pte)" be inside of the "if(ptep)" ?
> 
> It doesn't matter as we check the ptl for NULL in op_end functions.
> I have that scheme everywhere where it's nicer to read, like in the gmap
> protection functions.
> 
> I'll have a look if I can make that consistent either way.

Yes, as long as it's consistent it's fine for me.


-- 

Thanks,

David / dhildenb

       reply	other threads:[~2018-10-16  8:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <979ea4cc-8a85-479c-a03d-9f8b9a9b3487@linux.ibm.com>
2018-10-16  8:57 ` David Hildenbrand [this message]
2018-09-19  8:47 [RFC 08/14] s390/mm: Make gmap_read_table EDAT1 compatible Janosch Frank

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=cd5a4668-b5ec-beec-c6cb-60f6fbc9ec78@redhat.com \
    --to=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@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