All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chintan Pandya <cpandya@codeaurora.org>
To: "Kani, Toshi" <toshi.kani@hpe.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"arnd@arndb.de" <arnd@arndb.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"takahiro.akashi@linaro.org" <takahiro.akashi@linaro.org>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"kristina.martsenko@arm.com" <kristina.martsenko@arm.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"marc.zyngier@arm.com" <marc.zyngier@arm.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
Subject: Re: [PATCH v1 0/4] Fix issues with huge mapping in ioremap
Date: Thu, 15 Mar 2018 12:47:25 +0530	[thread overview]
Message-ID: <9954bd28-0457-b80e-8af7-6259b63533f2@codeaurora.org> (raw)
In-Reply-To: <1521038277.2693.131.camel@hpe.com>



On 3/14/2018 8:08 PM, Kani, Toshi wrote:
> On Wed, 2018-03-14 at 14:18 +0530, Chintan Pandya wrote:
>> Note: I was working on these patches for quite sometime
>> and realized that Toshi Kani has shared some patches
>> addressing the same isssue with subject
>> "[PATCH 0/2] fix memory leak / panic in ioremap huge pages".
>> I've taken slightly different approach here, so sending
>> to the list, finally.
> 
> Hi Chintan,
Hi Toshi
> 
> Do you have any issue in my patchset?  If so, can you please comment on
Not functional issues. But I didn't see issues you mentioned in your
commit text being solved for ARM64 in your patches. It is just being
masked which they were already by Will's patch. In my approach, end
goal was to get benefits of huge mapping back for ARM64.

> them?  It complicates the thing when you send a different approach
> without telling why a different approach is needed.  Your approach
See my reply above. I just had my original patches and I sent it.

> purges TLB after updating pmd/pud, which I think is broken.  Can you
Yes, they are broken. I understood the issues after Mark and Marc's
review comments.

> work on top of my patchset and properly implement pXd_free_pte_page()
I have realized that if I address Mark's comments, my new patch will
look similar to what you have done. So, I will work on top of your
patches.

> for arm64?  I will send out my v2 today.
>    
> Thanks,
> -Toshi
> 

Chintan
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: cpandya@codeaurora.org (Chintan Pandya)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 0/4] Fix issues with huge mapping in ioremap
Date: Thu, 15 Mar 2018 12:47:25 +0530	[thread overview]
Message-ID: <9954bd28-0457-b80e-8af7-6259b63533f2@codeaurora.org> (raw)
In-Reply-To: <1521038277.2693.131.camel@hpe.com>



On 3/14/2018 8:08 PM, Kani, Toshi wrote:
> On Wed, 2018-03-14 at 14:18 +0530, Chintan Pandya wrote:
>> Note: I was working on these patches for quite sometime
>> and realized that Toshi Kani has shared some patches
>> addressing the same isssue with subject
>> "[PATCH 0/2] fix memory leak / panic in ioremap huge pages".
>> I've taken slightly different approach here, so sending
>> to the list, finally.
> 
> Hi Chintan,
Hi Toshi
> 
> Do you have any issue in my patchset?  If so, can you please comment on
Not functional issues. But I didn't see issues you mentioned in your
commit text being solved for ARM64 in your patches. It is just being
masked which they were already by Will's patch. In my approach, end
goal was to get benefits of huge mapping back for ARM64.

> them?  It complicates the thing when you send a different approach
> without telling why a different approach is needed.  Your approach
See my reply above. I just had my original patches and I sent it.

> purges TLB after updating pmd/pud, which I think is broken.  Can you
Yes, they are broken. I understood the issues after Mark and Marc's
review comments.

> work on top of my patchset and properly implement pXd_free_pte_page()
I have realized that if I address Mark's comments, my new patch will
look similar to what you have done. So, I will work on top of your
patches.

> for arm64?  I will send out my v2 today.
>    
> Thanks,
> -Toshi
> 

Chintan
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

  reply	other threads:[~2018-03-15  7:17 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-14  8:48 [PATCH v1 0/4] Fix issues with huge mapping in ioremap Chintan Pandya
2018-03-14  8:48 ` Chintan Pandya
2018-03-14  8:48 ` [PATCH v1 1/4] asm/tlbflush: Add flush_tlb_pgtable() for ARM64 Chintan Pandya
2018-03-14  8:48   ` Chintan Pandya
2018-03-16  8:26   ` kbuild test robot
2018-03-16  8:26     ` kbuild test robot
2018-03-16  8:26     ` kbuild test robot
2018-03-16  8:26     ` kbuild test robot
2018-03-14  8:48 ` [PATCH v1 2/4] ioremap: Invalidate TLB after huge mappings Chintan Pandya
2018-03-14  8:48   ` Chintan Pandya
2018-03-14 10:48   ` Mark Rutland
2018-03-14 10:48     ` Mark Rutland
2018-03-14 11:20     ` Chintan Pandya
2018-03-14 11:20       ` Chintan Pandya
2018-03-14 11:48       ` Mark Rutland
2018-03-14 11:48         ` Mark Rutland
2018-03-14  8:48 ` [PATCH v1 3/4] arm64: Fix the page leak in pud/pmd_set_huge Chintan Pandya
2018-03-14  8:48   ` Chintan Pandya
2018-03-14 10:35   ` Marc Zyngier
2018-03-14 10:35     ` Marc Zyngier
2018-03-14 10:53   ` Mark Rutland
2018-03-14 10:53     ` Mark Rutland
2018-03-14 11:27     ` Chintan Pandya
2018-03-14 11:27       ` Chintan Pandya
2018-03-14 11:50       ` Mark Rutland
2018-03-14 11:50         ` Mark Rutland
2018-03-16 14:50   ` kbuild test robot
2018-03-16 14:50     ` kbuild test robot
2018-03-16 14:50     ` kbuild test robot
2018-03-16 14:50     ` kbuild test robot
2018-03-14  8:48 ` [PATCH v1 4/4] Revert "arm64: Enforce BBM for huge IO/VMAP mappings" Chintan Pandya
2018-03-14  8:48   ` Chintan Pandya
2018-03-14 10:46   ` Marc Zyngier
2018-03-14 10:46     ` Marc Zyngier
2018-03-14 11:32     ` Chintan Pandya
2018-03-14 11:32       ` Chintan Pandya
2018-03-14 14:38 ` [PATCH v1 0/4] Fix issues with huge mapping in ioremap Kani, Toshi
2018-03-14 14:38   ` Kani, Toshi
2018-03-15  7:17   ` Chintan Pandya [this message]
2018-03-15  7:17     ` Chintan Pandya
2018-03-15 14:38     ` Kani, Toshi
2018-03-15 14:38       ` Kani, Toshi

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=9954bd28-0457-b80e-8af7-6259b63533f2@codeaurora.org \
    --to=cpandya@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.morse@arm.com \
    --cc=kristina.martsenko@arm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hpe.com \
    --cc=will.deacon@arm.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.