From: Baoquan He <bhe@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: mingo@kernel.org, keescook@chromium.org, kirill@shutemov.name,
yamada.masahiro@socionext.com, tglx@linutronix.de, bp@alien8.de,
hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, x86@kernel.org, thgarnie@google.com,
Baoquan He <bhe@redhat.com>
Subject: [PATCH v4 0/6] Several patches to fix code bugs, improve documents and clean up
Date: Thu, 14 Mar 2019 17:46:39 +0800 [thread overview]
Message-ID: <20190314094645.4883-1-bhe@redhat.com> (raw)
This is v4 post. The v3 post can be found here:
http://lkml.kernel.org/r/20190216140008.28671-1-bhe@redhat.com
The v2 post was here:
https://lkml.org/lkml/2018/9/9/56
This patchset includes the original three code bug fix patches in v2,
and two new patches to improve code comments about kaslr_memory_region
and open code unnecessary function get_padding(), meanwhile carry the
known SGI UV bug fix.
This patchset sits on top of another patchset earlier posted:
http://lkml.kernel.org/r/20190308025616.21440-1-bhe@redhat.com
[PATCH v3 0/2] x86/mm/KASLR: Change the granularity of randomization to PUD size in 5-level
[PATCH v3 2/2] x86/mm/KASLR: Change the granularity of randomization to PUD size in 5-level
[PATCH v3 1/2] x86/mm/KASLR: Only build one PUD entry of area for real mode trampoline
Note:
SGI UV bug fix is not tested yet, the idea was approved by SGI UV expert
Mike Travis, and the old post as below was tested and has been merged
into our RHEL distros. This new change doesn't change the way to
calculate the size of the direct mapping section, but only wrap the
calculation code into a new function calc_direct_mapping_size()
according to Ingo's suggestion.
https://lkml.org/lkml/2017/5/18/102
Changelog:
v3->v4:
Update patches according to Kees's reviewing comments:
- Fix typos and move operation comment above
kernel_randomize_memory() for patch 1/6;
- Change 'PAGE_SIZE' to 'PAGE_SIZE/4' in patch 3/6;
- Add code comment about the calculation of vmemmap in patch 5/6;
v2->v3:
Added three patches according to Ingo's suggestions:
- Add code comment about struct kaslr_memory_region;
- Open code get_padding();
- Carry the SGI UV fix;
Baoquan He (6):
x86/mm/KASLR: Improve code comments about struct kaslr_memory_region
x86/mm/KASLR: Open code unnecessary function get_padding
mm: Add build time sanity chcek for struct page size
x86/mm/KASLR: Fix the wrong calculation of memory region initial size
x86/mm/KASLR: Calculate the actual size of vmemmap region
x86/mm/KASLR: Do not adapt the size of the direct mapping region for
SGI UV system
arch/x86/mm/kaslr.c | 134 +++++++++++++++++++++++++++++++++++---------
mm/page_alloc.c | 2 +
2 files changed, 109 insertions(+), 27 deletions(-)
--
2.17.2
next reply other threads:[~2019-03-14 9:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-14 9:46 Baoquan He [this message]
2019-03-14 9:46 ` [PATCH v4 1/6] x86/mm/KASLR: Improve code comments about struct kaslr_memory_region Baoquan He
2019-03-14 9:46 ` [PATCH v4 2/6] x86/mm/KASLR: Open code unnecessary function get_padding Baoquan He
2019-03-14 9:46 ` [PATCH v4 3/6] mm: Add build time sanity check for struct page size Baoquan He
2019-03-14 9:50 ` Baoquan He
2019-03-14 9:57 ` Baoquan He
2019-03-14 9:46 ` [PATCH v4 4/6] x86/mm/KASLR: Fix the wrong calculation of memory region initial size Baoquan He
2019-03-24 20:58 ` Thomas Gleixner
2019-03-25 3:46 ` Baoquan He
2019-03-14 9:46 ` [PATCH v4 5/6] x86/mm/KASLR: Calculate the actual size of vmemmap region Baoquan He
2019-03-14 9:46 ` [PATCH v4 6/6] x86/mm/KASLR: Do not adapt the size of the direct mapping region for SGI UV system Baoquan He
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=20190314094645.4883-1-bhe@redhat.com \
--to=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox