All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Edgecombe <rick.p.edgecombe@intel.com>
To: linux-kernel@vger.kernel.org, peterz@infradead.org,
	sparclinux@vger.kernel.org, linux-mm@kvack.org,
	netdev@vger.kernel.org, luto@amacapital.net
Cc: dave.hansen@intel.com, namit@vmware.com, davem@davemloft.net,
	Rick Edgecombe <rick.p.edgecombe@intel.com>
Subject: [PATCH v2 0/2] Fix issues with vmalloc flush flag
Date: Mon, 20 May 2019 16:38:39 -0700	[thread overview]
Message-ID: <20190520233841.17194-1-rick.p.edgecombe@intel.com> (raw)

These two patches address issues with the recently added
VM_FLUSH_RESET_PERMS vmalloc flag. It is now split into two patches, which
made sense to me, but can split it further if desired.

Patch 1 is the most critical and addresses an issue that could cause a
crash on x86.

Patch 2 is to try to reduce the work done in the free operation to push
it to allocation time where it would be more expected. This shouldn't be
a big issue most of the time, but I thought it was slightly better.

v2->v3:
 - Split into two patches

v1->v2:
 - Update commit message with more detail
 - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case

Rick Edgecombe (2):
  vmalloc: Fix calculation of direct map addr range
  vmalloc: Remove work as from vfree path

 mm/vmalloc.c | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

-- 
2.20.1


WARNING: multiple messages have this Message-ID (diff)
From: Rick Edgecombe <rick.p.edgecombe@intel.com>
To: linux-kernel@vger.kernel.org, peterz@infradead.org,
	sparclinux@vger.kernel.org, linux-mm@kvack.org,
	netdev@vger.kernel.org, luto@amacapital.net
Cc: dave.hansen@intel.com, namit@vmware.com, davem@davemloft.net,
	Rick Edgecombe <rick.p.edgecombe@intel.com>
Subject: [PATCH v2 0/2] Fix issues with vmalloc flush flag
Date: Mon, 20 May 2019 23:38:39 +0000	[thread overview]
Message-ID: <20190520233841.17194-1-rick.p.edgecombe@intel.com> (raw)

These two patches address issues with the recently added
VM_FLUSH_RESET_PERMS vmalloc flag. It is now split into two patches, which
made sense to me, but can split it further if desired.

Patch 1 is the most critical and addresses an issue that could cause a
crash on x86.

Patch 2 is to try to reduce the work done in the free operation to push
it to allocation time where it would be more expected. This shouldn't be
a big issue most of the time, but I thought it was slightly better.

v2->v3:
 - Split into two patches

v1->v2:
 - Update commit message with more detail
 - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case

Rick Edgecombe (2):
  vmalloc: Fix calculation of direct map addr range
  vmalloc: Remove work as from vfree path

 mm/vmalloc.c | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

-- 
2.20.1

             reply	other threads:[~2019-05-20 23:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-20 23:38 Rick Edgecombe [this message]
2019-05-20 23:38 ` [PATCH v2 0/2] Fix issues with vmalloc flush flag Rick Edgecombe
2019-05-20 23:38 ` [PATCH v2 1/2] vmalloc: Fix calculation of direct map addr range Rick Edgecombe
2019-05-20 23:38   ` Rick Edgecombe
2019-05-20 23:38 ` [PATCH v2 2/2] vmalloc: Remove work as from vfree path Rick Edgecombe
2019-05-20 23:38   ` Rick Edgecombe
2019-05-21 16:17   ` Andy Lutomirski
2019-05-21 16:17     ` Andy Lutomirski
2019-05-21 16:17     ` Andy Lutomirski
2019-05-21 16:51     ` Edgecombe, Rick P
2019-05-21 16:51       ` Edgecombe, Rick P
2019-05-21 17:00       ` Andy Lutomirski
2019-05-21 17:00         ` Andy Lutomirski
2019-05-21 17:00         ` Andy Lutomirski
2019-05-21 19:47         ` Edgecombe, Rick P
2019-05-21 19:47           ` Edgecombe, Rick P
2019-05-20 23:46 ` [PATCH v2 0/2] Fix issues with vmalloc flush flag Edgecombe, Rick P
2019-05-20 23:46   ` Edgecombe, Rick P

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=20190520233841.17194-1-rick.p.edgecombe@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=namit@vmware.com \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=sparclinux@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 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.