[PATCH v2 0/2] mmc: sdhci-iproc: fixes for HS50 data hold time

This patch series fixes data hold timing issues for various sdhci-iproc ip blocks that do not meet the HS50 data hold time. NO_HISPD bit is set in quirks. Changes from v1: - Change fixes tag to Cc: sta...@vger.kernel.org to specify version to backport to Trac Hoang (2): mmc: sdhci-iproc:

Re: [PATCH] fs,xfs: fix missed wakeup on l_flush_wait

On 7 May 2019, at 17:22, Dave Chinner wrote: > On Tue, May 07, 2019 at 01:05:28PM -0400, Rik van Riel wrote: >> The code in xlog_wait uses the spinlock to make adding the task to >> the wait queue, and setting the task state to UNINTERRUPTIBLE atomic >> with respect to the waker. >> >> Doing the

Re: [PATCH 1/2] coresight: Do not call smp_processor_id() from preemptible

Hi Suzuki, On Fri, 3 May 2019 at 10:04, Suzuki K Poulose wrote: > > Instead of using smp_processor_id() to figure out the node, > use the numa_node_id() for the current CPU node to avoid > splats like : > > BUG: using smp_processor_id() in preemptible [] code: perf/1743 > caller is

Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions

On Tue, 7 May 2019 21:50:52 -0700 Linus Torvalds wrote: > > It's been a bane of mine for some time. > > Guys, I have basically a one-liner patch for your hangups. > > It's called "rename 'sp' to 'user_sp' on x86-32". > > Then we make the 'sp' field on x86-64 be a union, so that you can call

Re: [PATCH 1/8] soundwire: intel: filter SoundWire controller device search

On 08-05-19, 11:20, Pierre-Louis Bossart wrote: > > > > > > + /* > > > > > + * On some Intel platforms, multiple children of the HDAS > > > > > + * device can be found, but only one of them is the SoundWire > > > > > + * controller. The SNDW device is always exposed with > > >

Re: [PATCH] watchdog: sama5d4: fix WDD value to be always set to max

On Wed, May 08, 2019 at 02:15:03PM +, eugen.hris...@microchip.com wrote: > From: Eugen Hristev > > WDD value must be always set to max (0xFFF) otherwise the hardware > block will reset the board on the first ping of the watchdog. > Not sure why setting WDD to the same value as WDV would do

[PATCH] selftests: fix install target to use default install path

Install target fails when INSTALL_PATH is undefined. Fix install target to use "output_dir/install as the default install location. "output_dir" is either the root of selftests directory under kernel source tree or output directory specified by O= or KBUILD_OUTPUT. e.g: make -C

Re: [PATCH 1/8] soundwire: intel: filter SoundWire controller device search

+ /* +* On some Intel platforms, multiple children of the HDAS +* device can be found, but only one of them is the SoundWire +* controller. The SNDW device is always exposed with +* Name(_ADR, 0x4000) so filter accordingly +*/ + if (adr

Re: [PATCH v2] Documentation/trace: Add clarification how histogram onmatch works

On Wed, 8 May 2019 12:18:54 -0400 Steven Rostedt wrote: > Jon, > > Can you take this patch in your tree? Will do. jon

Re: [PATCH v2 1/1] usb: typec: tcpci: Clear the fault status register

On Wed, May 08, 2019 at 07:48:43AM -0600, Angus Ainslie wrote: > Hi Guenter > > On 2019-05-07 23:18, Guenter Roeck wrote: > >On 5/7/19 7:49 PM, Angus Ainslie wrote: > >>On 2019-05-07 20:03, Guenter Roeck wrote: > >>>On 5/7/19 5:27 PM, Angus Ainslie (Purism) wrote: > If the fault status

Re: [PATCH v2] Documentation/trace: Add clarification how histogram onmatch works

Jon, Can you take this patch in your tree? Tom, Thanks for the review! -- Steve On Wed, 08 May 2019 08:15:26 -0500 Tom Zanussi wrote: > Hi Steve, > > On Tue, 2019-05-07 at 20:11 -0400, Steven Rostedt wrote: > > Tom, > > > > Can you review this patch. > > > > Sure. > > > Jon, > >

Re: [PATCH] arm64: add support for rng-seed

On Wed, May 8, 2019 at 10:06 AM Hsin-Yi Wang wrote: > > On Wed, May 8, 2019 at 10:04 PM Rob Herring wrote: > > > > On Tue, May 7, 2019 at 11:08 PM Hsin-Yi Wang wrote: > > > > > > On Wed, May 8, 2019 at 3:47 AM Rob Herring wrote: > > > > > > > > +boot-architecture list as there was some

[PATCH] vfio: add myself as reviewer

I'm trying to look at vfio patches, and it's easier if I'm cc:ed. Signed-off-by: Cornelia Huck --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 920a0a1545b7..9c0cd7a49309 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16454,6 +16454,7 @@ F:

Re: [PATCH v8 1/4] s390: ap: kvm: add PQAP interception for AQIC

On 08/05/2019 17:48, Tony Krowiak wrote: On 5/2/19 1:34 PM, Pierre Morel wrote: We prepare the interception of the PQAP/AQIC instruction for the case the AQIC facility is enabled in the guest. First of all we do not want to change existing behavior when intercepting AP instructions without the

Re: [PATCH 0/3] x86_64/ftrace: Emulate calls from int3 when patching functions

On Wed, 8 May 2019 13:30:22 +0900 Masami Hiramatsu wrote: > > To solve this, an int3_emulate_call() is created for x86_64 to allow > > ftrace on x86_64 to emulate the call to ftrace_regs_caller() which will > > make sure all the registered handlers to that function are still called. > > And this

Re: [PATCH v2 6/7] nvme-pci: add device coredump support

2019年5月8日(水) 9:25 Minwoo Im : > > > This is a bit of a mine field. The shutdown_lock is held when reclaiming > > requests that didn't see a response. If you're holding it here and your > > telemetry log page times out, we're going to deadlock. And since the > > controller is probably in a buggered

Re: [PATCH v2 6/7] nvme-pci: add device coredump support

2019年5月8日(水) 6:28 Keith Busch : > > On Tue, May 07, 2019 at 02:31:41PM -0600, Heitke, Kenneth wrote: > > On 5/7/2019 10:58 AM, Akinobu Mita wrote: > > > + > > > +static int nvme_get_telemetry_log_blocks(struct nvme_ctrl *ctrl, void > > > *buf, > > > +size_t

[PATCH v2] pstore/ram: Improve backward compatibility with older Chromebooks

When you try to run an upstream kernel on an old ARM-based Chromebook you'll find that console-ramoops doesn't work. Old ARM-based Chromebooks, before ("ramoops: support upstream {console,pmsg,ftrace}-size properties") used to create a "ramoops" node at the top level

Re: [PATCH v8 1/4] s390: ap: kvm: add PQAP interception for AQIC

On 5/2/19 1:34 PM, Pierre Morel wrote: We prepare the interception of the PQAP/AQIC instruction for the case the AQIC facility is enabled in the guest. First of all we do not want to change existing behavior when intercepting AP instructions without the SIE allowing the guest to use AP

Re: [PATCH] packet: Fix error path in packet_init

On Wed, May 8, 2019 at 8:33 AM YueHaibing wrote: > > kernel BUG at lib/list_debug.c:47! > invalid opcode: [#1 > CPU: 0 PID: 11195 Comm: rmmod Tainted: GW 5.1.0+ #33 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >

Re: [PATCH v2 4/7] nvme.h: add telemetry log page definisions

2019年5月8日(水) 2:53 Heitke, Kenneth : > > > > On 5/7/2019 10:58 AM, Akinobu Mita wrote: > > Copy telemetry log page definisions from nvme-cli. > > > > Cc: Johannes Berg > > Cc: Keith Busch > > Cc: Jens Axboe > > Cc: Christoph Hellwig > > Cc: Sagi Grimberg > > Cc: Minwoo Im > > Signed-off-by:

Re: [RESEND PATCH] gnss: get serial speed from subdrivers

On Wed, May 08, 2019 at 03:39:48PM +0200, Loys Ollivier wrote: > The default serial speed was hardcoded in the code. > Rename current-speed to default-speed. > Add a function parameter that lets the subdrivers specify their > default speed. > If not specified fallback to the device-tree

Re: [PATCH 3/3] reset: Add reset controller support for BM1880 SoC

Hi Philipp, On Fri, May 03, 2019 at 04:55:21PM +0200, Philipp Zabel wrote: > Hi Manivannan, > > thank you for the patch. A few issues below: > > On Thu, 2019-04-25 at 18:25 +0530, Manivannan Sadhasivam wrote: > > Add reset controller support for Bitmain BM1880 SoC reusing the > > reset-simple

Re: [PATCH] of: Add dummy for of_node_is_root if not CONFIG_OF

Hi, On Tue, May 7, 2019 at 3:17 PM Frank Rowand wrote: > > On 5/7/19 10:59 AM, Doug Anderson wrote: > > Hi, > > > > > > On Tue, May 7, 2019 at 10:52 AM Frank Rowand wrote: > >> > >> On 5/6/19 9:48 PM, Douglas Anderson wrote: > >>> We'll add a dummy to just return false. > >> > >> A more

Re: [RFC PATCH v2 11/17] sched: Basic tracking of matching tasks

On Fri, May 3, 2019 at 8:06 AM Tim Chen wrote: > > On 5/1/19 4:27 PM, Tim Chen wrote: > > On 4/28/19 11:15 PM, Aaron Lu wrote: > >> On Tue, Apr 23, 2019 at 04:18:16PM +, Vineeth Remanan Pillai wrote: > >>> +/* > >>> + * Find left-most (aka, highest priority) task matching @cookie. > >>> + */

Re: [PATCH v2 4/7] nvme.h: add telemetry log page definisions

2019年5月8日(水) 2:28 Heitke, Kenneth : > > > > On 5/7/2019 10:58 AM, Akinobu Mita wrote: > > Copy telemetry log page definisions from nvme-cli. > > > > Cc: Johannes Berg > > Cc: Keith Busch > > Cc: Jens Axboe > > Cc: Christoph Hellwig > > Cc: Sagi Grimberg > > Cc: Minwoo Im > > Signed-off-by:

Re: [PATCH 2/4] x86/kprobes: Fix frame pointer annotations

On Wed, May 08, 2019 at 07:42:48AM -0500, Josh Poimboeuf wrote: > On Wed, May 08, 2019 at 02:04:16PM +0200, Peter Zijlstra wrote: > > Do the x86_64 variants also want some ORC annotation? > > Maybe so. Though it looks like regs->ip isn't saved. The saved > registers might need to be tweaked.

Re: [PATCH v2 3/7] devcoredump: allow to create several coredump files in one device

2019年5月8日(水) 2:35 Heitke, Kenneth : > > > > On 5/7/2019 10:58 AM, Akinobu Mita wrote: > > @@ -292,6 +309,12 @@ void dev_coredumpm(struct device *dev, struct module > > *owner, > > if (device_add(>devcd_dev)) > > goto put_device; > > > > + for (i = 0; i < devcd->num_files;

Re: [PATCH v2] netfilter: xt_owner: Add supplementary groups option

On 5/8/19 11:25 AM, Lukasz Pawelczyk wrote: > On Wed, 2019-05-08 at 07:58 -0700, Eric Dumazet wrote: >> >> On 5/8/19 10:12 AM, Lukasz Pawelczyk wrote: >>> The XT_SUPPL_GROUPS flag causes GIDs specified with XT_OWNER_GID to >>> be also checked in the supplementary groups of a process. >>> >>>

Re: [PATCH 4/4] checkpatch: replace magic value for TAB size

On Wed, May 8, 2019 at 4:52 PM Joe Perches wrote: ... > > In these cases the script will be probably modified and adapted, > > so there is no need (at least for the moment) to expose this > > setting on the script's command line. > > Disagree. Probably getter to add a --tabsize= option now. Ok,

[PATCH v4 22/27] Documentation: x86: convert x86_64/uefi.txt to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab --- Documentation/x86/x86_64/index.rst| 1 + .../x86/x86_64/{uefi.txt => uefi.rst}

[PATCH v4 18/27] Documentation: x86: convert orc-unwinder.txt to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab --- Documentation/x86/index.rst | 1 + .../{orc-unwinder.txt => orc-unwinder.rst}

[PATCH v4 16/27] Documentation: x86: convert microcode.txt to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab --- Documentation/x86/index.rst | 1 + .../x86/{microcode.txt => microcode.rst}

[PATCH v4 26/27] Documentation: x86: convert x86_64/cpu-hotplug-spec to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab --- .../x86/x86_64/{cpu-hotplug-spec => cpu-hotplug-spec.rst}| 5 -

[PATCH v4 21/27] Documentation: x86: convert x86_64/boot-options.txt to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab --- Documentation/x86/index.rst | 1 + Documentation/x86/x86_64/boot-options.rst | 335

Re: ptrace warning due to "cgroup: get rid of cgroup_freezer_frozen_exit()"

On 05/07, Roman Gushchin wrote: > > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -2484,9 +2484,6 @@ bool get_signal(struct ksignal *ksig) > sigdelset(>pending.signal, SIGKILL); > recalc_sigpending(); > current->jobctl &= ~JOBCTL_TRAP_FREEZE;

[PATCH v1 2/2] fsopen: use square brackets around "fscontext"

Make the name of the anon inode fd "[fscontext]" instead of "fscontext". This is minor but most core-kernel anon inode fds carry square brackets around their name (cf. [1]). For the sake of consistency lets do the same for the mount api: [eventfd] [eventpoll] [fanotify] [fscontext] [io_uring]

Re: [PATCH v2] netfilter: xt_owner: Add supplementary groups option

On Wed, 2019-05-08 at 07:58 -0700, Eric Dumazet wrote: > > On 5/8/19 10:12 AM, Lukasz Pawelczyk wrote: > > The XT_SUPPL_GROUPS flag causes GIDs specified with XT_OWNER_GID to > > be also checked in the supplementary groups of a process. > > > > Signed-off-by: Lukasz Pawelczyk > > --- > >

Re: [RFC PATCH v6 4/6] tracing/probe: Support user-space dereference

On Wed, 8 May 2019 13:11:43 +0900 Masami Hiramatsu wrote: > On Mon, 6 May 2019 11:52:26 -0400 > Steven Rostedt wrote: > > > On Mon, 18 Mar 2019 15:43:52 +0900 > > Masami Hiramatsu wrote: > > > > > +.. _user_mem_access: > > > +User Memory Access > > > +-- > > > +Kprobe

[PATCH v4 27/27] Documentation: x86: convert x86_64/machinecheck to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab --- Documentation/x86/x86_64/index.rst | 1 + .../x86/x86_64/{machinecheck =>

[PATCH v4 11/27] Documentation: x86: convert pat.txt to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Cc: Mauro Carvalho Chehab --- Documentation/x86/index.rst | 1 + Documentation/x86/pat.rst | 242

[PATCH v4 17/27] Documentation: x86: convert resctrl_ui.txt to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab --- Documentation/x86/index.rst | 1 + .../x86/{resctrl_ui.txt => resctrl_ui.rst}

[PATCH v4 04/27] Documentation: x86: convert exception-tables.txt to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab --- ...eption-tables.txt => exception-tables.rst} | 247 ++

[PATCH v1 1/2] fs: make all new mount api fds cloexec by default

This makes all file descriptors returned from new syscalls of the new mount api cloexec by default. >From a userspace perspective it is rarely the case that fds are supposed to be inherited across exec. In fact, most of the time userspace either needs to remember to pass the _CLOEXEC flag along

Re: [PATCH v2] usb: core: verify devicetree nodes for disabled interfaces

Marek Szyprowski writes: > Hi > > On 2019-05-08 13:46, Måns Rullgård wrote: >> Marek Szyprowski writes: >>> Commit 01fdf179f4b0 ("usb: core: skip interfaces disabled in devicetree") >>> add support for disabling given USB device interface by adding nodes to >>> the USB host controller device.

[PATCH v4 12/27] Documentation: x86: convert protection-keys.txt to reST

This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab --- Documentation/x86/index.rst | 1 + ...rotection-keys.txt =>

Re: [PATCH 1/4] checkpatch: fix multiple const * types

On Wed, May 8, 2019 at 4:51 PM Joe Perches wrote: ... > It might be better to use a max match like {0,4} instead of * > > perl is pretty memory intensive at multiple unrestricted matches > of somewhat complex patterns. Agree! Will send a V2! Thanks for the review! Antonio

Re: [PATCH 2/8] soc: tegra: fuse: Change to the correct __dma_request_channel() prototype

07.05.2019 9:09, Baolin Wang пишет: > Since we've introduced one device node parameter for __dma_request_channel(), > thus change to the correct function prototype. > > Signed-off-by: Baolin Wang > --- > drivers/soc/tegra/fuse/fuse-tegra20.c |2 +- > 1 file changed, 1 insertion(+), 1

[PATCH] ACPICA: acpica: Fix possible NULL pointer dereference in acpi_ut_remove_reference

BUG: kernel NULL pointer dereference, address: #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1 CPU: 0 PID: 7393 Comm: modprobe Not tainted 5.1.0+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS

Re: [PATCH] ftrace: enable trampoline when rec count decrement to one

Hi, Steven On 2019/5/6 3:34, Steven Rostedt wrote: Thanks for the patch. There was some race condition that prevented me from doing this in the first place, but unfortunately, I don't remember what that was :-/ I'll have to think about this before applying this patch. Maybe there isn't a

Re: [PATCH] arm64: dts: qcom: qcs404: Add PSCI cpuidle support

On Wed, May 08, 2019 at 02:48:19AM +0530, Amit Kucheria wrote: > On Tue, May 7, 2019 at 1:01 AM Niklas Cassel wrote: > > > > Add device bindings for CPUs to suspend using PSCI as the enable-method. > > > > Signed-off-by: Niklas Cassel > > --- > > arch/arm64/boot/dts/qcom/qcs404.dtsi | 15

Re: [PATCH 2/6] x86: hv: hv_init.c: Replace alloc_page() with kmem_cache_alloc()

Maya Nakamura writes: > On Fri, Apr 12, 2019 at 09:52:47AM +0200, Vitaly Kuznetsov wrote: >> Maya Nakamura writes: >> >> > On Fri, Apr 05, 2019 at 01:31:02PM +0200, Vitaly Kuznetsov wrote: >> >> Maya Nakamura writes: >> >> >> >> > @@ -98,18 +99,20 @@ EXPORT_SYMBOL_GPL(hyperv_pcpu_input_arg);

[PATCH, RFC 02/62] mm: Add helpers to setup zero page mappings

When kernel setups an encrypted page mapping, encryption KeyID is derived from a VMA. KeyID is going to be part of vma->vm_page_prot and it will be propagated transparently to page table entry on mk_pte(). But there is an exception: zero page is never encrypted and its mapping must use KeyID-0,

[PATCH, RFC 01/62] mm: Do no merge VMAs with different encryption KeyIDs

VMAs with different KeyID do not mix together. Only VMAs with the same KeyID are compatible. Signed-off-by: Kirill A. Shutemov --- fs/userfaultfd.c | 7 --- include/linux/mm.h | 9 - mm/madvise.c | 2 +- mm/mempolicy.c | 3 ++- mm/mlock.c | 2 +- mm/mmap.c

Re: [PATCH 4/4] checkpatch: replace magic value for TAB size

On Wed, 2019-05-08 at 14:27 +0200, Antonio Borneo wrote: > The size of 8 characters used for both TAB and indentation is > embedded as magic value allover the checkpatch script, and this > makes the script less readable. > > Replace the magic value 8 with the perl variable "$tabsize". > From the

[PATCH, RFC 14/62] x86/mm: Map zero pages into encrypted mappings correctly

Zero pages are never encrypted. Keep KeyID-0 for them. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/pgtable.h | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 50b3e2d963c9..59c3dd50b8d5

[PATCH, RFC 03/62] mm/ksm: Do not merge pages with different KeyIDs

KeyID indicates what key to use to encrypt and decrypt page's content. Depending on the implementation a cipher text may be tied to physical address of the page. It means that pages with an identical plain text would appear different if KSM would look at a cipher text. It effectively disables KSM

[PATCH, RFC 04/62] mm/page_alloc: Unify alloc_hugepage_vma()

We don't need to have separate implementations of alloc_hugepage_vma() for NUMA and non-NUMA. Using variant based on alloc_pages_vma() we would cover both cases. This is preparation patch for allocation encrypted pages. alloc_pages_vma() will handle allocation of encrypted pages. With this

Re: [PATCH] nvme-pci: mark expected switch fall-through

On 5/8/19 2:18 AM, Christoph Hellwig wrote: > Thanks, > > applied to nvme-5.2. > Great. :) Thanks, Christoph. -- Gustavo

[PATCH, RFC 05/62] mm/page_alloc: Handle allocation for encrypted memory

For encrypted memory, we need to allocate pages for a specific encryption KeyID. There are two cases when we need to allocate a page for encryption: - Allocation for an encrypted VMA; - Allocation for migration of encrypted page; The first case can be covered within alloc_page_vma(). We know

Re: [PATCH 1/4] checkpatch: fix multiple const * types

On Wed, 2019-05-08 at 14:27 +0200, Antonio Borneo wrote: > Commit 1574a29f8e76 ("checkpatch: allow multiple const * types") > claims to support repetition of pattern "const *", but it actually > allows only one extra instance. > Check the following lines > int a(char const * const x[]); >

[PATCH, RFC 10/62] x86/mm: Detect MKTME early

We need to know the number of KeyIDs before page_ext is initialized. We are going to use page_ext to store KeyID and it would be handly to avoid page_ext allocation if there's no MKMTE in the system. page_ext initialization happens before full CPU initizliation is complete. Move detect_tme() call

[PATCH, RFC 11/62] x86/mm: Add a helper to retrieve KeyID for a page

page_ext allows to store additional per-page information without growing main struct page. The additional space can be requested at boot time. Store KeyID in bits 31:16 of extended page flags. These bits are unused. page_keyid() returns zero until page_ext is ready. page_ext initializer enables

[PATCH, RFC 08/62] x86/mm: Introduce variables to store number, shift and mask of KeyIDs

mktme_nr_keyids holds the number of KeyIDs available for MKTME, excluding KeyID zero which used by TME. MKTME KeyIDs start from 1. mktme_keyid_shift holds the shift of KeyID within physical address. mktme_keyid_mask holds the mask to extract KeyID from physical address. Signed-off-by: Kirill A.

[PATCH, RFC 06/62] mm/khugepaged: Handle encrypted pages

For !NUMA khugepaged allocates page in advance, before we found a VMA for collapse. We don't yet know which KeyID to use for the allocation. The page is allocated with KeyID-0. Once we know that the VMA is suitable for collapsing, we prepare the page for KeyID we need, based on vma_keyid().

[PATCH, RFC 20/62] mm/page_ext: Export lookup_page_ext() symbol

page_keyid() is inline funcation that uses lookup_page_ext(). KVM is going to use page_keyid() and since KVM can be built as a module lookup_page_ext() has to be exported. Signed-off-by: Kirill A. Shutemov --- mm/page_ext.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/page_ext.c

[PATCH, RFC 15/62] x86/mm: Rename CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING

Rename the option to CONFIG_MEMORY_PHYSICAL_PADDING. It will be used not only for KASLR. Signed-off-by: Kirill A. Shutemov --- arch/x86/Kconfig| 2 +- arch/x86/mm/kaslr.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index

[PATCH, RFC 16/62] x86/mm: Allow to disable MKTME after enumeration

The new helper mktme_disable() allows to disable MKTME even if it's enumerated successfully. MKTME initialization may fail and this functionality allows system to boot regardless of the failure. MKTME needs per-KeyID direct mapping. It requires a lot more virtual address space which may be a

[PATCH, RFC 27/62] keys/mktme: Strengthen the entropy of CPU generated MKTME keys

From: Alison Schofield If users request CPU generated keys, mix additional entropy bits from the kernel into the key programming fields used by the hardware. This additional entropy may compensate for weak user supplied, or CPU generated, entropy. Signed-off-by: Alison Schofield Signed-off-by:

[PATCH, RFC 25/62] keys/mktme: Instantiate and destroy MKTME keys

From: Alison Schofield Instantiating and destroying are two Kernel Key Service methods that are invoked by the kernel key service when a key is added (add_key, request_key) or removed (invalidate, revoke, timeout). During instantiation, MKTME needs to allocate an available hardware KeyID and

[PATCH, RFC 19/62] x86/mm: Handle encrypted memory in page_to_virt() and __pa()

Per-KeyID direct mappings require changes into how we find the right virtual address for a page and virt-to-phys address translations. page_to_virt() definition overwrites default macros provided by . Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/page.h| 3 +++

[PATCH, RFC 26/62] keys/mktme: Move the MKTME payload into a cache aligned structure

From: Alison Schofield In preparation for programming the key into the hardware, move the key payload into a cache aligned structure. This alignment is a requirement of the MKTME hardware. Use the slab allocator to have this structure readily available. Signed-off-by: Alison Schofield

[PATCH, RFC 47/62] mm: Restrict MKTME memory encryption to anonymous VMAs

From: Alison Schofield Memory encryption is only supported for mappings that are ANONYMOUS. Test the VMA's in an encrypt_mprotect() request to make sure they all meet that requirement before encrypting any. The encrypt_mprotect syscall will return -EINVAL and will not encrypt any VMA's if this

[PATCH, RFC 17/62] x86/mm: Calculate direct mapping size

The kernel needs to have a way to access encrypted memory. We have two option on how approach it: - Create temporary mappings every time kernel needs access to encrypted memory. That's basically brings highmem and its overhead back. - Create multiple direct mappings, one per-KeyID. In this

[PATCH, RFC 18/62] x86/mm: Implement syncing per-KeyID direct mappings

For MKTME we use per-KeyID direct mappings. This allows kernel to have access to encrypted memory. sync_direct_mapping() sync per-KeyID direct mappings with a canonical one -- KeyID-0. The function tracks changes in the canonical mapping: - creating or removing chunks of the translation tree;

[PATCH, RFC 31/62] keys/mktme: Require CAP_SYS_RESOURCE capability for MKTME keys

From: Alison Schofield The MKTME key type uses capabilities to restrict the allocation of keys to privileged users. CAP_SYS_RESOURCE is required, but the broader capability of CAP_SYS_ADMIN is accepted. Signed-off-by: Alison Schofield Signed-off-by: Kirill A. Shutemov ---

[PATCH, RFC 32/62] keys/mktme: Store MKTME payloads if cmdline parameter allows

From: Alison Schofield MKTME (Multi-Key Total Memory Encryption) key payloads may include data encryption keys, tweak keys, and additional entropy bits. These are used to program the MKTME encryption hardware. By default, the kernel destroys this payload data once the hardware is programmed.

[PATCH, RFC 30/62] keys/mktme: Set up a percpu_ref_count for MKTME keys

From: Alison Schofield The MKTME key service needs to keep usage counts on the encryption keys in order to know when it is safe to free a key for reuse. percpu_ref_count applies well here because the key service will take the initial reference and typically hold that reference while the

[PATCH, RFC 33/62] acpi: Remove __init from acpi table parsing functions

From: Alison Schofield ACPI table parsing functions are useful outside of init time. For example, the MKTME (Multi-Key Total Memory Encryption) key service will evaluate the ACPI HMAT table when the first key creation request occurs. This will happen after init time. Additionally, the table

[PATCH, RFC 09/62] x86/mm: Preserve KeyID on pte_modify() and pgprot_modify()

An encrypted VMA will have KeyID stored in vma->vm_page_prot. This way we don't need to do anything special to setup encrypted page table entries and don't need to reserve space for KeyID in a VMA. This patch changes _PAGE_CHG_MASK to include KeyID bits. Otherwise they are going to be stripped

[PATCH, RFC 37/62] keys/mktme: Do not allow key creation in unsafe topologies

From: Alison Schofield MKTME feature depends upon at least one online CPU capable of programming each memory controller in the platform. An unsafe topology for MKTME is a memory only package or a package with no online CPUs. Key creation with unsafe topologies will fail with EINVAL and a

[PATCH, RFC 35/62] keys/mktme: Require ACPI HMAT to register the MKTME Key Service

From: Alison Schofield The ACPI HMAT will be used by the MKTME key service to identify topologies that support the safe programming of encryption keys. Those decisions will happen at key creation time and during hotplug events. To enable this, we at least need to have the ACPI HMAT present at

[PATCH, RFC 38/62] keys/mktme: Support CPU hotplug for MKTME key service

From: Alison Schofield The MKTME encryption hardware resides on each physical package. The encryption hardware includes 'Key Tables' that must be programmed identically across all physical packages in the platform. Although every CPU in a package can program its key table, the kernel uses one

[GIT PULL] Kbuild updates for v5.2

Hi Linus, Please pull Kbuild updates for v5.2 Thanks. The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6: Linux 5.1-rc3 (2019-03-31 14:39:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git

[PATCH, RFC 41/62] keys/mktme: Support memory hotplug for MKTME keys

From: Alison Schofield Newly added memory may mean that there is a newly added physical package. Intel platforms supporting MKTME need to know about the new physical packages that may appear during MEM_GOING_ONLINE events. Add a memory notifier for MEM_GOING_ONLINE events where MKTME can

[PATCH, RFC 43/62] syscall/x86: Wire up a system call for MKTME encryption keys

From: Alison Schofield encrypt_mprotect() is a new system call to support memory encryption. It takes the same parameters as legacy mprotect, plus an additional key serial number that is mapped to an encryption keyid. Signed-off-by: Alison Schofield Signed-off-by: Kirill A. Shutemov ---

[PATCH, RFC 42/62] mm: Generalize the mprotect implementation to support extensions

From: Alison Schofield Today mprotect is implemented to support legacy mprotect behavior plus an extension for memory protection keys. Make it more generic so that it can support additional extensions in the future. This is done is preparation for adding a new system call for memory encyption

[PATCH, RFC 51/62] iommu/vt-d: Support MKTME in DMA remapping

From: Jacob Pan When MKTME is enabled, keyid is stored in the high order bits of physical address. For DMA transactions targeting encrypted physical memory, keyid must be included in the IOVA to physical address translation. This patch appends page keyid when setting up the IOMMU PTEs. On the

[PATCH, RFC 49/62] mm, x86: export several MKTME variables

From: Kai Huang KVM needs those variables to get/set memory encryption mask. Signed-off-by: Kai Huang Signed-off-by: Kirill A. Shutemov --- arch/x86/mm/mktme.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c index df70651816a1..12f4266cf7ea

[PATCH, RFC 46/62] x86/mm: Keep reference counts on encrypted VMAs for MKTME

From: Alison Schofield The MKTME (Multi-Key Total Memory Encryption) Key Service needs a reference count on encrypted VMAs. This reference count is used to determine when a hardware encryption KeyID is no longer in use and can be freed and reassigned to another Userspace Key. The MKTME Key

[PATCH, RFC 36/62] acpi/hmat: Evaluate topology presented in ACPI HMAT for MKTME

From: Alison Schofield MKTME, Multi-Key Total Memory Encryption, is a feature on Intel platforms. The ACPI HMAT table can be used to verify that the platform topology is safe for the usage of MKTME. The kernel must be capable of programming every memory controller on the platform. This means

[PATCH, RFC 52/62] x86/mm: introduce common code for mem encryption

From: Jacob Pan Both Intel MKTME and AMD SME have needs to support DMA address translation with encryption related bits. Common functions are introduced in this patch to keep DMA generic code abstracted. Signed-off-by: Jacob Pan Signed-off-by: Kirill A. Shutemov --- arch/x86/Kconfig

[PATCH, RFC 07/62] x86/mm: Mask out KeyID bits from page table entry pfn

MKTME claims several upper bits of the physical address in a page table entry to encode KeyID. It effectively shrinks number of bits for physical address. We should exclude KeyID bits from physical addresses. For instance, if CPU enumerates 52 physical address bits and number of bits claimed for

[PATCH, RFC 50/62] kvm, x86, mmu: setup MKTME keyID to spte for given PFN

From: Kai Huang Setup keyID to SPTE, which will be eventually programmed to shadow MMU or EPT table, according to page's associated keyID, so that guest is able to use correct keyID to access guest memory. Note current shadow_me_mask doesn't suit MKTME's needs, since for MKTME there's no fixed

[PATCH, RFC 48/62] selftests/x86/mktme: Test the MKTME APIs

From: Alison Schofield This is a draft for poweron testing. I'm assuming it needs to be in Intel-next to be available for poweron. It is not in the selftest Makefiles. COMPILE w keyutils library ==> cc -o mktest mktme_test.c -lkeyutils Usage: mktme_test [options]... -a

[PATCH, RFC 54/62] x86/mm: Disable MKTME on incompatible platform configurations

Icelake Server requires additional check to make sure that MKTME usage is safe on Linux. Kernel needs a way to access encrypted memory. There can be different approaches to this: create a temporary mapping to access the page (using kmap() interface), modify kernel's direct mapping on allocation

[PATCH, RFC 60/62] x86/mktme: Document the MKTME Key Service API

From: Alison Schofield Signed-off-by: Alison Schofield Signed-off-by: Kirill A. Shutemov --- Documentation/x86/mktme/index.rst | 1 + Documentation/x86/mktme/mktme_keys.rst | 96 ++ 2 files changed, 97 insertions(+) create mode 100644

[PATCH, RFC 13/62] x86/mm: Add hooks to allocate and free encrypted pages

Hook up into page allocator to allocate and free encrypted page properly. The hardware/CPU does not enforce coherency between mappings of the same physical page with different KeyIDs or encryption keys. We are responsible for cache management. Flush cache on allocating encrypted page and on

[PATCH, RFC 58/62] x86/mktme: Document the MKTME provided security mitigations

From: Alison Schofield Describe the security benefits of Multi-Key Total Memory Encryption (MKTME) over Total Memory Encryption (TME) alone. Signed-off-by: Alison Schofield Signed-off-by: Kirill A. Shutemov --- Documentation/x86/mktme/index.rst | 1 +

[PATCH, RFC 55/62] x86/mm: Disable MKTME if not all system memory supports encryption

UEFI memory attribute EFI_MEMORY_CPU_CRYPTO indicates whether the memory region supports encryption. Kernel doesn't handle situation when only part of the system memory supports encryption. Disable MKTME if not all system memory supports encryption. Signed-off-by: Kirill A. Shutemov ---

<    1   2   3   4   5   6   7   8   9   >