* Re: [PATCH -v2] treewide: Rename "unencrypted" to "decrypted"
From: Thomas Gleixner @ 2020-03-19 23:53 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-s390, Dave Hansen, Vasily Gorbik, linuxppc-dev,
Peter Zijlstra, x86, Heiko Carstens, lkml, Christian Borntraeger,
iommu, Ingo Molnar, Paul Mackerras, Andy Lutomirski, Tom Lendacky,
Robin Murphy, Christoph Hellwig, Marek Szyprowski
In-Reply-To: <20200319174254.GE13073@zn.tnic>
Borislav Petkov <bp@alien8.de> writes:
> On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote:
>> TBH, I don't see how
>>
>> if (force_dma_decrypted(dev))
>> set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
>>
>> makes more sense than the above. It's both non-sensical unless there is
>
> 9087c37584fb ("dma-direct: Force unencrypted DMA under SME for certain DMA masks")
Reading the changelog again...
I have to say that force_dma_unencrypted() makes way more sense in that
context than force_dma_decrypted(). It still wants a comment.
Linguistical semantics and correctness matters a lot. Consistency is
required as well, but not for the price of ambiguous wording.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 0/3] KVM: PPC: Fix host kernel crash with PR KVM
From: Paul Mackerras @ 2020-03-19 23:34 UTC (permalink / raw)
To: Greg Kurz; +Cc: kvm-ppc, Sean Christopherson, Paolo Bonzini, linuxppc-dev
In-Reply-To: <158455340419.178873.11399595021669446372.stgit@bahia.lan>
On Wed, Mar 18, 2020 at 06:43:24PM +0100, Greg Kurz wrote:
> Recent cleanup from Sean Christopherson introduced a use-after-free
> condition that crashes the kernel when shutting down the VM with
> PR KVM. It went unnoticed so far because PR isn't tested/used much
> these days (mostly used for nested on POWER8, not supported on POWER9
> where HV should be used for nested), and other KVM implementations for
> ppc are unaffected.
>
> This all boils down to the fact that the path that frees the per-vCPU
> MMU data goes through a complex set of indirections. This obfuscates
> the code to the point that we didn't realize that the MMU data was
> now being freed too early. And worse, most of the indirection isn't
> needed because only PR KVM has some MMU data to free when the vCPU is
> destroyed.
>
> Fix the issue (patch 1) and simplify the code (patch 2 and 3).
I have put this series in my kvm-ppc-next branch, and I believe
Michael Ellerman is putting patch 1 in his fixes branch so it gets
into 5.6.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Use RADIX_PTE_INDEX_SIZE in Radix MMU code
From: Paul Mackerras @ 2020-03-19 23:31 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20200218043650.24410-1-mpe@ellerman.id.au>
On Tue, Feb 18, 2020 at 03:36:50PM +1100, Michael Ellerman wrote:
> In kvmppc_unmap_free_pte() in book3s_64_mmu_radix.c, we use the
> non-constant value PTE_INDEX_SIZE to clear a PTE page.
>
> We can instead use the constant RADIX_PTE_INDEX_SIZE, because we know
> this code will only be running when the Radix MMU is active.
>
> Note that we already use RADIX_PTE_INDEX_SIZE for the allocation of
> kvm_pte_cache.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Thanks, applied to my kvm-ppc-next branch.
Paul.
^ permalink raw reply
* Re: [PATCH -next 016/491] KERNEL VIRTUAL MACHINE FOR POWERPC (KVM/powerpc): Use fallthrough;
From: Paul Mackerras @ 2020-03-19 23:33 UTC (permalink / raw)
To: Joe Perches; +Cc: linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <7584d7937f4bb929beb0b9f5e80523653297676d.camel@perches.com>
On Wed, Mar 18, 2020 at 06:22:29PM -0700, Joe Perches wrote:
> On Thu, 2020-03-19 at 12:18 +1100, Paul Mackerras wrote:
> > On Tue, Mar 10, 2020 at 09:51:30PM -0700, Joe Perches wrote:
> > > Convert the various uses of fallthrough comments to fallthrough;
> > >
> > > Done via script
> > > Link: https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
> > >
> > > Signed-off-by: Joe Perches <joe@perches.com>
> >
> > The subject line should look like "KVM: PPC: Use fallthrough".
>
> There's no way to generate a subject line like that via a script
> so far as I can tell.
>
> > Apart from that,
> >
> > Acked-by: Paul Mackerras <paulus@ozlabs.org>
> >
> > How are these patches going upstream? Do you want me to take this via
> > my tree?
>
> If you want.
>
> Ideally, these changes would go in treewide via a script run
> by Linus at an -rc1, but if the change is OK with you, it'd
> be fine to have you apply it now.
I have taken this patch in my kvm-ppc-next branch.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Fix H_CEDE return code for nested guests
From: Paul Mackerras @ 2020-03-19 23:32 UTC (permalink / raw)
To: Michael Roth; +Cc: linuxppc-dev, kvm-ppc, David Gibson
In-Reply-To: <20200310211128.17672-1-mdroth@linux.vnet.ibm.com>
On Tue, Mar 10, 2020 at 04:11:28PM -0500, Michael Roth wrote:
> The h_cede_tm kvm-unit-test currently fails when run inside an L1 guest
> via the guest/nested hypervisor.
>
> ./run-tests.sh -v
> ...
> TESTNAME=h_cede_tm TIMEOUT=90s ACCEL= ./powerpc/run powerpc/tm.elf -smp 2,threads=2 -machine cap-htm=on -append "h_cede_tm"
> FAIL h_cede_tm (2 tests, 1 unexpected failures)
>
> While the test relates to transactional memory instructions, the actual
> failure is due to the return code of the H_CEDE hypercall, which is
> reported as 224 instead of 0. This happens even when no TM instructions
> are issued.
>
> 224 is the value placed in r3 to execute a hypercall for H_CEDE, and r3
> is where the caller expects the return code to be placed upon return.
>
> In the case of guest running under a nested hypervisor, issuing H_CEDE
> causes a return from H_ENTER_NESTED. In this case H_CEDE is
> specially-handled immediately rather than later in
> kvmppc_pseries_do_hcall() as with most other hcalls, but we forget to
> set the return code for the caller, hence why kvm-unit-test sees the
> 224 return code and reports an error.
>
> Guest kernels generally don't check the return value of H_CEDE, so
> that likely explains why this hasn't caused issues outside of
> kvm-unit-tests so far.
>
> Fix this by setting r3 to 0 after we finish processing the H_CEDE.
>
> RHBZ: 1778556
>
> Fixes: 4bad77799fed ("KVM: PPC: Book3S HV: Handle hypercalls correctly when nested")
> Cc: linuxppc-dev@ozlabs.org
> Cc: David Gibson <david@gibson.dropbear.id.au>
> Cc: Paul Mackerras <paulus@ozlabs.org>
> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Thanks, applied to my kvm-ppc-next branch.
Paul.
^ permalink raw reply
* Re: [PATCH v3] KVM: PPC: Book3S HV: Treat TM-related invalid form instructions on P9 like the valid ones
From: Paul Mackerras @ 2020-03-19 23:32 UTC (permalink / raw)
To: Gustavo Romero; +Cc: leonardo, mikey, linuxppc-dev, kvm-ppc
In-Reply-To: <20200221162950.132860-1-gromero@linux.ibm.com>
On Fri, Feb 21, 2020 at 11:29:50AM -0500, Gustavo Romero wrote:
> On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
> KVM. This is handled at first by the hardware raising a softpatch interrupt
> when certain TM instructions that need KVM assistance are executed in the
> guest. Althought some TM instructions per Power ISA are invalid forms they
> can raise a softpatch interrupt too. For instance, 'tresume.' instruction
> as defined in the ISA must have bit 31 set (1), but an instruction that
> matches 'tresume.' PO and XO opcode fields but has bit 31 not set (0), like
> 0x7cfe9ddc, also raises a softpatch interrupt. Similarly for 'treclaim.'
> and 'trechkpt.' instructions with bit 31 = 0, i.e. 0x7c00075c and
> 0x7c0007dc, respectively. Hence, if a code like the following is executed
> in the guest it will raise a softpatch interrupt just like a 'tresume.'
> when the TM facility is enabled ('tabort. 0' in the example is used only
> to enable the TM facility):
>
> int main() { asm("tabort. 0; .long 0x7cfe9ddc;"); }
>
> Currently in such a case KVM throws a complete trace like:
>
> [345523.705984] WARNING: CPU: 24 PID: 64413 at arch/powerpc/kvm/book3s_hv_tm.c:211 kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
> [345523.705985] Modules linked in: kvm_hv(E) xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat
> iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ebtable_filter ebtables ip6table_filter
> ip6_tables iptable_filter bridge stp llc sch_fq_codel ipmi_powernv at24 vmx_crypto ipmi_devintf ipmi_msghandler
> ibmpowernv uio_pdrv_genirq kvm opal_prd uio leds_powernv ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp
> libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456
> async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear tg3
> crct10dif_vpmsum crc32c_vpmsum ipr [last unloaded: kvm_hv]
> [345523.706030] CPU: 24 PID: 64413 Comm: CPU 0/KVM Tainted: G W E 5.5.0+ #1
> [345523.706031] NIP: c0080000072cb9c0 LR: c0080000072b5e80 CTR: c0080000085c7850
> [345523.706034] REGS: c000000399467680 TRAP: 0700 Tainted: G W E (5.5.0+)
> [345523.706034] MSR: 900000010282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 24022428 XER: 00000000
> [345523.706042] CFAR: c0080000072b5e7c IRQMASK: 0
> GPR00: c0080000072b5e80 c000000399467910 c0080000072db500 c000000375ccc720
> GPR04: c000000375ccc720 00000003fbec0000 0000a10395dda5a6 0000000000000000
> GPR08: 000000007cfe9ddc 7cfe9ddc000005dc 7cfe9ddc7c0005dc c0080000072cd530
> GPR12: c0080000085c7850 c0000003fffeb800 0000000000000001 00007dfb737f0000
> GPR16: c0002001edcca558 0000000000000000 0000000000000000 0000000000000001
> GPR20: c000000001b21258 c0002001edcca558 0000000000000018 0000000000000000
> GPR24: 0000000001000000 ffffffffffffffff 0000000000000001 0000000000001500
> GPR28: c0002001edcc4278 c00000037dd80000 800000050280f033 c000000375ccc720
> [345523.706062] NIP [c0080000072cb9c0] kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
> [345523.706065] LR [c0080000072b5e80] kvmppc_handle_exit_hv.isra.53+0x3e8/0x798 [kvm_hv]
> [345523.706066] Call Trace:
> [345523.706069] [c000000399467910] [c000000399467940] 0xc000000399467940 (unreliable)
> [345523.706071] [c000000399467950] [c000000399467980] 0xc000000399467980
> [345523.706075] [c0000003994679f0] [c0080000072bd1c4] kvmhv_run_single_vcpu+0xa1c/0xb80 [kvm_hv]
> [345523.706079] [c000000399467ac0] [c0080000072bd8e0] kvmppc_vcpu_run_hv+0x5b8/0xb00 [kvm_hv]
> [345523.706087] [c000000399467b90] [c0080000085c93cc] kvmppc_vcpu_run+0x34/0x48 [kvm]
> [345523.706095] [c000000399467bb0] [c0080000085c582c] kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm]
> [345523.706101] [c000000399467c40] [c0080000085b7498] kvm_vcpu_ioctl+0x3d0/0x7b0 [kvm]
> [345523.706105] [c000000399467db0] [c0000000004adf9c] ksys_ioctl+0x13c/0x170
> [345523.706107] [c000000399467e00] [c0000000004adff8] sys_ioctl+0x28/0x80
> [345523.706111] [c000000399467e20] [c00000000000b278] system_call+0x5c/0x68
> [345523.706112] Instruction dump:
> [345523.706114] 419e0390 7f8a4840 409d0048 6d497c00 2f89075d 419e021c 6d497c00 2f8907dd
> [345523.706119] 419e01c0 6d497c00 2f8905dd 419e00a4 <0fe00000> 38210040 38600000 ebc1fff0
>
> and then treats the executed instruction as a 'nop'.
>
> However the POWER9 User's Manual, in section "4.6.10 Book II Invalid
> Forms", informs that for TM instructions bit 31 is in fact ignored, thus
> for the TM-related invalid forms ignoring bit 31 and handling them like the
> valid forms is an acceptable way to handle them. POWER8 behaves the same
> way too.
>
> This commit changes the handling of the cases here described by treating
> the TM-related invalid forms that can generate a softpatch interrupt
> just like their valid forms (w/ bit 31 = 1) instead of as a 'nop' and by
> gently reporting any other unrecognized case to the host and treating it as
> illegal instruction instead of throwing a trace and treating it as a 'nop'.
>
> Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
> Acked-By: Michael Neuling <mikey@neuling.org>
> Reviewed-by: Leonardo Bras <leonardo@linux.ibm.com>
Thanks, applied to my kvm-ppc-next branch.
Paul.
^ permalink raw reply
* Re: [patch V2 11/15] completion: Use simple wait queues
From: Julian Calaby @ 2020-03-19 23:25 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Paul E . McKenney,
Logan Gunthorpe, Arnd Bergmann, linuxppc-dev, Steven Rostedt,
Bjorn Helgaas, Kurt Schwemmer, Kalle Valo, Felipe Balbi,
Greg Kroah-Hartman, linux-usb, linux-wireless, LKML, netdev,
Linus Torvalds, David S. Miller
In-Reply-To: <20200318204408.521507446@linutronix.de>
Hi Thomas,
On Thu, Mar 19, 2020 at 7:48 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> From: Thomas Gleixner <tglx@linutronix.de>
>
> completion uses a wait_queue_head_t to enqueue waiters.
>
> wait_queue_head_t contains a spinlock_t to protect the list of waiters
> which excludes it from being used in truly atomic context on a PREEMPT_RT
> enabled kernel.
>
> The spinlock in the wait queue head cannot be replaced by a raw_spinlock
> because:
>
> - wait queues can have custom wakeup callbacks, which acquire other
> spinlock_t locks and have potentially long execution times
>
> - wake_up() walks an unbounded number of list entries during the wake up
> and may wake an unbounded number of waiters.
>
> For simplicity and performance reasons complete() should be usable on
> PREEMPT_RT enabled kernels.
>
> completions do not use custom wakeup callbacks and are usually single
> waiter, except for a few corner cases.
>
> Replace the wait queue in the completion with a simple wait queue (swait),
> which uses a raw_spinlock_t for protecting the waiter list and therefore is
> safe to use inside truly atomic regions on PREEMPT_RT.
>
> There is no semantical or functional change:
>
> - completions use the exclusive wait mode which is what swait provides
>
> - complete() wakes one exclusive waiter
>
> - complete_all() wakes all waiters while holding the lock which protects
> the wait queue against newly incoming waiters. The conversion to swait
> preserves this behaviour.
>
> complete_all() might cause unbound latencies with a large number of waiters
> being woken at once, but most complete_all() usage sites are either in
> testing or initialization code or have only a really small number of
> concurrent waiters which for now does not cause a latency problem. Keep it
> simple for now.
>
> The fixup of the warning check in the USB gadget driver is just a straight
> forward conversion of the lockless waiter check from one waitqueue type to
> the other.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> ---
> V2: Split out the orinoco and usb gadget parts and amended change log
> ---
> drivers/usb/gadget/function/f_fs.c | 2 +-
> include/linux/completion.h | 8 ++++----
> kernel/sched/completion.c | 36 +++++++++++++++++++-----------------
> 3 files changed, 24 insertions(+), 22 deletions(-)
>
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -1703,7 +1703,7 @@ static void ffs_data_put(struct ffs_data
> pr_info("%s(): freeing\n", __func__);
> ffs_data_clear(ffs);
> BUG_ON(waitqueue_active(&ffs->ev.waitq) ||
> - waitqueue_active(&ffs->ep0req_completion.wait) ||
> + swait_active(&ffs->ep0req_completion.wait) ||
This looks like some code is reaching deep into the dirty dark corners
of the completion implementation, should there be some wrapper around
this to hide that?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [PATCH] KVM: PPC: Book3S HV: Skip kvmppc_uvmem_free if Ultravisor is not supported
From: Fabiano Rosas @ 2020-03-19 22:55 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, groug, bharata
kvmppc_uvmem_init checks for Ultravisor support and returns early if
it is not present. Calling kvmppc_uvmem_free at module exit will cause
an Oops:
$ modprobe -r kvm-hv
Oops: Kernel access of bad area, sig: 11 [#1]
<snip>
NIP: c000000000789e90 LR: c000000000789e8c CTR: c000000000401030
REGS: c000003fa7bab9a0 TRAP: 0300 Not tainted (5.6.0-rc6-00033-g6c90b86a745a-dirty)
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002282 XER: 00000000
CFAR: c000000000dae880 DAR: 0000000000000008 DSISR: 40000000 IRQMASK: 1
GPR00: c000000000789e8c c000003fa7babc30 c0000000016fe500 0000000000000000
GPR04: 0000000000000000 0000000000000006 0000000000000000 c000003faf205c00
GPR08: 0000000000000000 0000000000000001 000000008000002d c00800000ddde140
GPR12: c000000000401030 c000003ffffd9080 0000000000000001 0000000000000000
GPR16: 0000000000000000 0000000000000000 000000013aad0074 000000013aaac978
GPR20: 000000013aad0070 0000000000000000 00007fffd1b37158 0000000000000000
GPR24: 000000014fef0d58 0000000000000000 000000014fef0cf0 0000000000000001
GPR28: 0000000000000000 0000000000000000 c0000000018b2a60 0000000000000000
NIP [c000000000789e90] percpu_ref_kill_and_confirm+0x40/0x170
LR [c000000000789e8c] percpu_ref_kill_and_confirm+0x3c/0x170
Call Trace:
[c000003fa7babc30] [c000003faf2064d4] 0xc000003faf2064d4 (unreliable)
[c000003fa7babcb0] [c000000000400e8c] dev_pagemap_kill+0x6c/0x80
[c000003fa7babcd0] [c000000000401064] memunmap_pages+0x34/0x2f0
[c000003fa7babd50] [c00800000dddd548] kvmppc_uvmem_free+0x30/0x80 [kvm_hv]
[c000003fa7babd80] [c00800000ddcef18] kvmppc_book3s_exit_hv+0x20/0x78 [kvm_hv]
[c000003fa7babda0] [c0000000002084d0] sys_delete_module+0x1d0/0x2c0
[c000003fa7babe20] [c00000000000b9d0] system_call+0x5c/0x68
Instruction dump:
3fc2001b fb81ffe0 fba1ffe8 fbe1fff8 7c7f1b78 7c9c2378 3bde4560 7fc3f378
f8010010 f821ff81 486249a1 60000000 <e93f0008> 7c7d1b78 712a0002 40820084
---[ end trace 5774ef4dc2c98279 ]---
So this patch checks if kvmppc_uvmem_init actually allocated anything
before running kvmppc_uvmem_free.
Fixes: ca9f4942670c ("KVM: PPC: Book3S HV: Support for running secure guests")
Reported-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 79b1202b1c62..9d26614b2a77 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -806,6 +806,9 @@ int kvmppc_uvmem_init(void)
void kvmppc_uvmem_free(void)
{
+ if (!kvmppc_uvmem_bitmap)
+ return;
+
memunmap_pages(&kvmppc_uvmem_pgmap);
release_mem_region(kvmppc_uvmem_pgmap.res.start,
resource_size(&kvmppc_uvmem_pgmap.res));
--
2.23.0
^ permalink raw reply related
* Re: [PATCH -v2] treewide: Rename "unencrypted" to "decrypted"
From: Michal Suchánek @ 2020-03-19 21:59 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Tom Lendacky, x86, Vasily Gorbik, linux-s390, Peter Zijlstra,
linuxppc-dev, Dave Hansen, Heiko Carstens, lkml,
Christian Borntraeger, iommu, Ingo Molnar, Borislav Petkov,
Andy Lutomirski, Paul Mackerras, Robin Murphy, Christoph Hellwig,
Marek Szyprowski
In-Reply-To: <878sjw5k9u.fsf@nanos.tec.linutronix.de>
On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote:
> Borislav Petkov <bp@alien8.de> writes:
>
> > On Thu, Mar 19, 2020 at 11:06:15AM +0000, Robin Murphy wrote:
> >> Let me add another vote from a native English speaker that "unencrypted" is
> >> the appropriate term to imply the *absence* of encryption, whereas
> >> "decrypted" implies the *reversal* of applied encryption.
Even as a non-native speaker I can clearly see the distinction.
> >>
> >> Naming things is famously hard, for good reason - names are *important* for
> >> understanding. Just because a decision was already made one way doesn't mean
> >> that that decision was necessarily right. Churning one area to be
> >> consistently inaccurate just because it's less work than churning another
> >> area to be consistently accurate isn't really the best excuse.
> >
> > Well, the reason we chose "decrypted" vs something else is so to be as
> > different from "encrypted" as possible. If we called it "unencrypted"
> > you'd have stuff like:
> >
> > if (force_dma_unencrypted(dev))
> > set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
If you want something with high edit distance from 'encrypted' meaning
the opposite there is already 'cleartext' which was designed for this
exact purpose.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH] tpm2: Export tpm2_get_cc_attrs_tbl for ibmvtpm driver as module
From: Jarkko Sakkinen @ 2020-03-19 21:16 UTC (permalink / raw)
To: Stefan Berger
Cc: sachinp, Stefan Berger, linux-kernel, linux-next, linux-integrity,
linuxppc-dev
In-Reply-To: <17b5d98c-76b2-63c0-798a-920d91fec618@linux.ibm.com>
On Thu, Mar 19, 2020 at 11:56:11AM -0400, Stefan Berger wrote:
> On 3/19/20 10:27 AM, Jarkko Sakkinen wrote:
> > On Wed, Mar 18, 2020 at 03:53:54PM -0400, Stefan Berger wrote:
> > > On 3/18/20 3:42 PM, Jarkko Sakkinen wrote:
> > > > On Tue, Mar 17, 2020 at 09:08:19AM -0400, Stefan Berger wrote:
> > > > > From: Stefan Berger <stefanb@linux.ibm.com>
> > > > >
> > > > > This patch fixes the following problem when the ibmvtpm driver
> > > > > is built as a module:
> > > > >
> > > > > ERROR: modpost: "tpm2_get_cc_attrs_tbl" [drivers/char/tpm/tpm_ibmvtpm.ko] undefined!
> > > > > make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
> > > > > make: *** [Makefile:1298: modules] Error 2
> > > > >
> > > > > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> > > > Hi, wrong tag (we use "tpm:"), missing fixes tag and please cc stable.
> > > > Thanks.
> > > I did not add the fixes tag because I do not know the final commit hash, or
> > > is it the final commit hash once it is in linux-next? I doubt it with all
> > > the merging that can occur.
> > Can you send me a new version after rc1 is out?
>
> Michael Ellerman (cc'ed) told me that the fixes tag should 'work' once the
> bad patch is in linux-next. So I reposted yesterday (with a stray 'q' in the
> title :-( ):
OK, cool, I'll correct it and apply thanks.
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
^ permalink raw reply
* Re: [PATCH v3 8/8] mm/memory_hotplug: allow to specify a default online_type
From: Pankaj Gupta @ 2020-03-19 17:26 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-hyperv, Michal Hocko, Baoquan He, Rafael J. Wysocki,
Greg Kroah-Hartman, linux-kernel, Wei Yang, linux-mm,
Andrew Morton, Michal Hocko, linuxppc-dev, Oscar Salvador
In-Reply-To: <20200319131221.14044-9-david@redhat.com>
> For now, distributions implement advanced udev rules to essentially
> - Don't online any hotplugged memory (s390x)
> - Online all memory to ZONE_NORMAL (e.g., most virt environments like
> hyperv)
> - Online all memory to ZONE_MOVABLE in case the zone imbalance is taken
> care of (e.g., bare metal, special virt environments)
>
> In summary: All memory is usually onlined the same way, however, the
> kernel always has to ask user space to come up with the same answer.
> E.g., Hyper-V always waits for a memory block to get onlined before
> continuing, otherwise it might end up adding memory faster than
> onlining it, which can result in strange OOM situations. This waiting
> slows down adding of a bigger amount of memory.
>
> Let's allow to specify a default online_type, not just "online" and
> "offline". This allows distributions to configure the default online_type
> when booting up and be done with it.
>
> We can now specify "offline", "online", "online_movable" and
> "online_kernel" via
> - "memhp_default_state=" on the kernel cmdline
> - /sys/devices/system/memory/auto_online_blocks
> just like we are able to specify for a single memory block via
> /sys/devices/system/memory/memoryX/state
>
> Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/base/memory.c | 11 +++++------
> include/linux/memory_hotplug.h | 2 ++
> mm/memory_hotplug.c | 8 ++++----
> 3 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 8d3e16dab69f..2b09b68b9f78 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -35,7 +35,7 @@ static const char *const online_type_to_str[] = {
> [MMOP_ONLINE_MOVABLE] = "online_movable",
> };
>
> -static int memhp_online_type_from_str(const char *str)
> +int memhp_online_type_from_str(const char *str)
> {
> int i;
>
> @@ -394,13 +394,12 @@ static ssize_t auto_online_blocks_store(struct device *dev,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> - if (sysfs_streq(buf, "online"))
> - memhp_default_online_type = MMOP_ONLINE;
> - else if (sysfs_streq(buf, "offline"))
> - memhp_default_online_type = MMOP_OFFLINE;
> - else
> + const int online_type = memhp_online_type_from_str(buf);
> +
> + if (online_type < 0)
> return -EINVAL;
>
> + memhp_default_online_type = online_type;
> return count;
> }
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 6d6f85bb66e9..93d9ada74ddd 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -118,6 +118,8 @@ extern int arch_add_memory(int nid, u64 start, u64 size,
> struct mhp_params *params);
> extern u64 max_mem_size;
>
> +extern int memhp_online_type_from_str(const char *str);
> +
> /* Default online_type (MMOP_*) when new memory blocks are added. */
> extern int memhp_default_online_type;
> /* If movable_node boot option specified */
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 4efcf8cb9ac5..89197163d138 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -74,10 +74,10 @@ int memhp_default_online_type = MMOP_ONLINE;
>
> static int __init setup_memhp_default_state(char *str)
> {
> - if (!strcmp(str, "online"))
> - memhp_default_online_type = MMOP_ONLINE;
> - else if (!strcmp(str, "offline"))
> - memhp_default_online_type = MMOP_OFFLINE;
> + const int online_type = memhp_online_type_from_str(str);
> +
> + if (online_type >= 0)
> + memhp_default_online_type = online_type;
>
> return 1;
> }
> --
Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> 2.24.1
>
>
^ permalink raw reply
* Re: [PATCH v3 7/8] mm/memory_hotplug: convert memhp_auto_online to store an online_type
From: Pankaj Gupta @ 2020-03-19 17:19 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-hyperv, Michal Hocko, Baoquan He, Rafael J. Wysocki,
Greg Kroah-Hartman, linux-kernel, Wei Yang, linux-mm,
Andrew Morton, Michal Hocko, linuxppc-dev, Oscar Salvador
In-Reply-To: <20200319131221.14044-8-david@redhat.com>
> ... and rename it to memhp_default_online_type. This is a preparation
> for more detailed default online behavior.
>
> Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/base/memory.c | 10 ++++------
> include/linux/memory_hotplug.h | 3 ++-
> mm/memory_hotplug.c | 11 ++++++-----
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 8a7f29c0bf97..8d3e16dab69f 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -386,10 +386,8 @@ static DEVICE_ATTR_RO(block_size_bytes);
> static ssize_t auto_online_blocks_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> - if (memhp_auto_online)
> - return sprintf(buf, "online\n");
> - else
> - return sprintf(buf, "offline\n");
> + return sprintf(buf, "%s\n",
> + online_type_to_str[memhp_default_online_type]);
> }
>
> static ssize_t auto_online_blocks_store(struct device *dev,
> @@ -397,9 +395,9 @@ static ssize_t auto_online_blocks_store(struct device *dev,
> const char *buf, size_t count)
> {
> if (sysfs_streq(buf, "online"))
> - memhp_auto_online = true;
> + memhp_default_online_type = MMOP_ONLINE;
> else if (sysfs_streq(buf, "offline"))
> - memhp_auto_online = false;
> + memhp_default_online_type = MMOP_OFFLINE;
> else
> return -EINVAL;
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 76f3c617a8ab..6d6f85bb66e9 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -118,7 +118,8 @@ extern int arch_add_memory(int nid, u64 start, u64 size,
> struct mhp_params *params);
> extern u64 max_mem_size;
>
> -extern bool memhp_auto_online;
> +/* Default online_type (MMOP_*) when new memory blocks are added. */
> +extern int memhp_default_online_type;
> /* If movable_node boot option specified */
> extern bool movable_node_enabled;
> static inline bool movable_node_is_enabled(void)
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index e21a7d53ade5..4efcf8cb9ac5 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -67,17 +67,17 @@ void put_online_mems(void)
> bool movable_node_enabled = false;
>
> #ifndef CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
> -bool memhp_auto_online;
> +int memhp_default_online_type = MMOP_OFFLINE;
> #else
> -bool memhp_auto_online = true;
> +int memhp_default_online_type = MMOP_ONLINE;
> #endif
>
> static int __init setup_memhp_default_state(char *str)
> {
> if (!strcmp(str, "online"))
> - memhp_auto_online = true;
> + memhp_default_online_type = MMOP_ONLINE;
> else if (!strcmp(str, "offline"))
> - memhp_auto_online = false;
> + memhp_default_online_type = MMOP_OFFLINE;
>
> return 1;
> }
> @@ -993,6 +993,7 @@ static int check_hotplug_memory_range(u64 start, u64 size)
>
> static int online_memory_block(struct memory_block *mem, void *arg)
> {
> + mem->online_type = memhp_default_online_type;
> return device_online(&mem->dev);
> }
>
> @@ -1065,7 +1066,7 @@ int __ref add_memory_resource(int nid, struct resource *res)
> mem_hotplug_done();
>
> /* online pages if requested */
> - if (memhp_auto_online)
> + if (memhp_default_online_type != MMOP_OFFLINE)
> walk_memory_blocks(start, size, NULL, online_memory_block);
>
> return ret;
> --
Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> 2.24.1
>
>
^ permalink raw reply
* Re: [PATCH v3 6/8] mm/memory_hotplug: unexport memhp_auto_online
From: Pankaj Gupta @ 2020-03-19 16:52 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-hyperv, Michal Hocko, Baoquan He, Rafael J. Wysocki,
linux-kernel, Wei Yang, linux-mm, Andrew Morton, Michal Hocko,
linuxppc-dev, Oscar Salvador
In-Reply-To: <20200319131221.14044-7-david@redhat.com>
> All in-tree users except the mm-core are gone. Let's drop the export.
>
> Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> mm/memory_hotplug.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index da6aab272c9b..e21a7d53ade5 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -71,7 +71,6 @@ bool memhp_auto_online;
> #else
> bool memhp_auto_online = true;
> #endif
> -EXPORT_SYMBOL_GPL(memhp_auto_online);
>
> static int __init setup_memhp_default_state(char *str)
> {
> --
> 2.24.1
Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
>
>
^ permalink raw reply
* Re: [PATCH v3 3/8] drivers/base/memory: store mapping between MMOP_* and string in an array
From: Pankaj Gupta @ 2020-03-19 16:33 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-hyperv, Michal Hocko, Baoquan He, Rafael J. Wysocki,
Greg Kroah-Hartman, linux-kernel, Wei Yang, linux-mm,
Andrew Morton, Michal Hocko, linuxppc-dev, Oscar Salvador
In-Reply-To: <20200319131221.14044-4-david@redhat.com>
> Let's use a simple array which we can reuse soon. While at it, move the
> string->mmop conversion out of the device hotplug lock.
>
> Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/base/memory.c | 38 +++++++++++++++++++++++---------------
> 1 file changed, 23 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index e7e77cafef80..8a7f29c0bf97 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -28,6 +28,24 @@
>
> #define MEMORY_CLASS_NAME "memory"
>
> +static const char *const online_type_to_str[] = {
> + [MMOP_OFFLINE] = "offline",
> + [MMOP_ONLINE] = "online",
> + [MMOP_ONLINE_KERNEL] = "online_kernel",
> + [MMOP_ONLINE_MOVABLE] = "online_movable",
> +};
> +
> +static int memhp_online_type_from_str(const char *str)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(online_type_to_str); i++) {
> + if (sysfs_streq(str, online_type_to_str[i]))
> + return i;
> + }
> + return -EINVAL;
> +}
> +
> #define to_memory_block(dev) container_of(dev, struct memory_block, dev)
>
> static int sections_per_block;
> @@ -236,26 +254,17 @@ static int memory_subsys_offline(struct device *dev)
> static ssize_t state_store(struct device *dev, struct device_attribute *attr,
> const char *buf, size_t count)
> {
> + const int online_type = memhp_online_type_from_str(buf);
> struct memory_block *mem = to_memory_block(dev);
> - int ret, online_type;
> + int ret;
> +
> + if (online_type < 0)
> + return -EINVAL;
>
> ret = lock_device_hotplug_sysfs();
> if (ret)
> return ret;
>
> - if (sysfs_streq(buf, "online_kernel"))
> - online_type = MMOP_ONLINE_KERNEL;
> - else if (sysfs_streq(buf, "online_movable"))
> - online_type = MMOP_ONLINE_MOVABLE;
> - else if (sysfs_streq(buf, "online"))
> - online_type = MMOP_ONLINE;
> - else if (sysfs_streq(buf, "offline"))
> - online_type = MMOP_OFFLINE;
> - else {
> - ret = -EINVAL;
> - goto err;
> - }
> -
> switch (online_type) {
> case MMOP_ONLINE_KERNEL:
> case MMOP_ONLINE_MOVABLE:
> @@ -271,7 +280,6 @@ static ssize_t state_store(struct device *dev, struct device_attribute *attr,
> ret = -EINVAL; /* should never happen */
> }
>
> -err:
> unlock_device_hotplug();
>
> if (ret < 0)
> --
Nice cleanup patch.
Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> 2.24.1
>
>
^ permalink raw reply
* Re: [PATCH v3 2/8] drivers/base/memory: map MMOP_OFFLINE to 0
From: Pankaj Gupta @ 2020-03-19 16:29 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-hyperv, Michal Hocko, Baoquan He, Rafael J. Wysocki,
Greg Kroah-Hartman, linux-kernel, Wei Yang, linux-mm,
Andrew Morton, Michal Hocko, linuxppc-dev, Oscar Salvador
In-Reply-To: <20200319131221.14044-3-david@redhat.com>
> Historically, we used the value -1. Just treat 0 as the special
> case now. Clarify a comment (which was wrong, when we come via
> device_online() the first time, the online_type would have been 0 /
> MEM_ONLINE). The default is now always MMOP_OFFLINE. This removes the
> last user of the manual "-1", which didn't use the enum value.
>
> This is a preparation to use the online_type as an array index.
>
> Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/base/memory.c | 11 ++++-------
> include/linux/memory_hotplug.h | 2 +-
> 2 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 8c5ce42c0fc3..e7e77cafef80 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -211,17 +211,14 @@ static int memory_subsys_online(struct device *dev)
> return 0;
>
> /*
> - * If we are called from state_store(), online_type will be
> - * set >= 0 Otherwise we were called from the device online
> - * attribute and need to set the online_type.
> + * When called via device_online() without configuring the online_type,
> + * we want to default to MMOP_ONLINE.
> */
> - if (mem->online_type < 0)
> + if (mem->online_type == MMOP_OFFLINE)
> mem->online_type = MMOP_ONLINE;
>
> ret = memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE);
> -
> - /* clear online_type */
> - mem->online_type = -1;
> + mem->online_type = MMOP_OFFLINE;
>
> return ret;
> }
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 3aaf00db224c..76f3c617a8ab 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -48,7 +48,7 @@ enum {
> /* Types for control the zone type of onlined and offlined memory */
> enum {
> /* Offline the memory. */
> - MMOP_OFFLINE = -1,
> + MMOP_OFFLINE = 0,
> /* Online the memory. Zone depends, see default_zone_for_pfn(). */
> MMOP_ONLINE,
> /* Online the memory to ZONE_NORMAL. */
> --
> 2.24.1
Looks good to me.
Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
>
>
^ permalink raw reply
* Re: [PATCH v3 1/8] drivers/base/memory: rename MMOP_ONLINE_KEEP to MMOP_ONLINE
From: Pankaj Gupta @ 2020-03-19 16:28 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-hyperv, Baoquan He, Rafael J. Wysocki, Greg Kroah-Hartman,
linux-kernel, Wei Yang, linux-mm, Andrew Morton, Michal Hocko,
linuxppc-dev, Oscar Salvador
In-Reply-To: <20200319131221.14044-2-david@redhat.com>
> The name is misleading and it's not really clear what is "kept". Let's just
> name it like the online_type name we expose to user space ("online").
>
> Add some documentation to the types.
>
> Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/base/memory.c | 9 +++++----
> include/linux/memory_hotplug.h | 6 +++++-
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 6448c9ece2cb..8c5ce42c0fc3 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -216,7 +216,7 @@ static int memory_subsys_online(struct device *dev)
> * attribute and need to set the online_type.
> */
> if (mem->online_type < 0)
> - mem->online_type = MMOP_ONLINE_KEEP;
> + mem->online_type = MMOP_ONLINE;
>
> ret = memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE);
>
> @@ -251,7 +251,7 @@ static ssize_t state_store(struct device *dev, struct device_attribute *attr,
> else if (sysfs_streq(buf, "online_movable"))
> online_type = MMOP_ONLINE_MOVABLE;
> else if (sysfs_streq(buf, "online"))
> - online_type = MMOP_ONLINE_KEEP;
> + online_type = MMOP_ONLINE;
> else if (sysfs_streq(buf, "offline"))
> online_type = MMOP_OFFLINE;
> else {
> @@ -262,7 +262,7 @@ static ssize_t state_store(struct device *dev, struct device_attribute *attr,
> switch (online_type) {
> case MMOP_ONLINE_KERNEL:
> case MMOP_ONLINE_MOVABLE:
> - case MMOP_ONLINE_KEEP:
> + case MMOP_ONLINE:
> /* mem->online_type is protected by device_hotplug_lock */
> mem->online_type = online_type;
> ret = device_online(&mem->dev);
> @@ -342,7 +342,8 @@ static ssize_t valid_zones_show(struct device *dev,
> }
>
> nid = mem->nid;
> - default_zone = zone_for_pfn_range(MMOP_ONLINE_KEEP, nid, start_pfn, nr_pages);
> + default_zone = zone_for_pfn_range(MMOP_ONLINE, nid, start_pfn,
> + nr_pages);
> strcat(buf, default_zone->name);
>
> print_allowed_zone(buf, nid, start_pfn, nr_pages, MMOP_ONLINE_KERNEL,
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 3195d11876ea..3aaf00db224c 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -47,9 +47,13 @@ enum {
>
> /* Types for control the zone type of onlined and offlined memory */
> enum {
> + /* Offline the memory. */
> MMOP_OFFLINE = -1,
> - MMOP_ONLINE_KEEP,
> + /* Online the memory. Zone depends, see default_zone_for_pfn(). */
> + MMOP_ONLINE,
> + /* Online the memory to ZONE_NORMAL. */
> MMOP_ONLINE_KERNEL,
> + /* Online the memory to ZONE_MOVABLE. */
> MMOP_ONLINE_MOVABLE,
> };
>
> --
Looks good to me.
Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> 2.24.1
>
>
^ permalink raw reply
* [Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load
From: bugzilla-daemon @ 2020-03-19 20:22 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-206669-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=206669
--- Comment #13 from John Paul Adrian Glaubitz (glaubitz@physik.fu-berlin.de) ---
watson login: [30887.552539] KVM: CPU 4 seems to be stuck
[30900.094713] watchdog: CPU 8 detected hard LOCKUP on other CPUs 0
[30900.094730] watchdog: CPU 8 TB:15863742878763, last SMP heartbeat
TB:15855546563837 (16008ms ago)
[30908.222926] watchdog: BUG: soft lockup - CPU#80 stuck for 22s! [CPU
4/KVM:2698]
[30908.374929] watchdog: BUG: soft lockup - CPU#112 stuck for 22s! [CPU
23/KVM:2717]
[30908.426934] watchdog: BUG: soft lockup - CPU#120 stuck for 22s! [CPU
16/KVM:2710]
[30909.570962] rcu: INFO: rcu_sched self-detected stall on CPU
[30909.570970] rcu: 120-....: (5059 ticks this GP)
idle=7d2/1/0x4000000000000002 softirq=421758/421758 fqs=2378
[30912.095025] watchdog: BUG: soft lockup - CPU#8 stuck for 23s! [CPU
18/KVM:2712]
[30912.127027] watchdog: BUG: soft lockup - CPU#40 stuck for 23s! [CPU
22/KVM:2716]
[30912.155026] watchdog: BUG: soft lockup - CPU#56 stuck for 23s! [CPU
27/KVM:2721]
[30912.175028] watchdog: BUG: soft lockup - CPU#64 stuck for 23s! [CPU
26/KVM:2720]
[30912.195028] watchdog: BUG: soft lockup - CPU#72 stuck for 23s! [CPU
19/KVM:2713]
[30912.547038] watchdog: BUG: soft lockup - CPU#136 stuck for 22s! [CPU
8/KVM:2702]
[30912.619040] watchdog: BUG: soft lockup - CPU#144 stuck for 22s! [CPU
5/KVM:2699]
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v2] qtpm2: Export tpm2_get_cc_attrs_tbl for ibmvtpm driver as module
From: Jarkko Sakkinen @ 2020-03-19 19:57 UTC (permalink / raw)
To: Stefan Berger
Cc: sachinp, linux-kernel, linux-next, linux-integrity, linuxppc-dev,
Stefan Berger
In-Reply-To: <20200319010017.738677-1-stefanb@linux.vnet.ibm.com>
On Wed, Mar 18, 2020 at 09:00:17PM -0400, Stefan Berger wrote:
> From: Stefan Berger <stefanb@linux.ibm.com>
>
> This patch fixes the following problem when the ibmvtpm driver
> is built as a module:
>
> ERROR: modpost: "tpm2_get_cc_attrs_tbl" [drivers/char/tpm/tpm_ibmvtpm.ko] undefined!
> make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
> make: *** [Makefile:1298: modules] Error 2
>
> Fixes: 18b3670d79ae ("tpm: ibmvtpm: Add support for TPM2")
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Should have "tpm:" tag in the short summary.
/Jarkko
^ permalink raw reply
* Re: [PATCH 1/4] hugetlbfs: add arch_hugetlb_valid_size
From: Mike Kravetz @ 2020-03-19 18:17 UTC (permalink / raw)
To: Christophe Leroy, linux-mm, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-riscv, linux-s390, sparclinux, linux-doc
Cc: Albert Ou, Vasily Gorbik, Jonathan Corbet, Catalin Marinas,
Dave Hansen, Heiko Carstens, David S.Miller,
Christian Borntraeger, Ingo Molnar, Palmer Dabbelt, Paul Walmsley,
Paul Mackerras, Andrew Morton, Longpeng, Will Deacon,
Thomas Gleixner
In-Reply-To: <c3071359-c5d3-4247-7f16-6f61b2fa0756@c-s.fr>
On 3/19/20 12:00 AM, Christophe Leroy wrote:
>
> Le 18/03/2020 à 23:06, Mike Kravetz a écrit :
>> The architecture independent routine hugetlb_default_setup sets up
>> the default huge pages size. It has no way to verify if the passed
>> value is valid, so it accepts it and attempts to validate at a later
>> time. This requires undocumented cooperation between the arch specific
>> and arch independent code.
>>
>> For architectures that support more than one huge page size, provide
>> a routine arch_hugetlb_valid_size to validate a huge page size.
>> hugetlb_default_setup can use this to validate passed values.
>>
>> arch_hugetlb_valid_size will also be used in a subsequent patch to
>> move processing of the "hugepagesz=" in arch specific code to a common
>> routine in arch independent code.
>>
>> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
>> ---
>> arch/arm64/include/asm/hugetlb.h | 2 ++
>> arch/arm64/mm/hugetlbpage.c | 19 ++++++++++++++-----
>> arch/powerpc/include/asm/hugetlb.h | 3 +++
>> arch/powerpc/mm/hugetlbpage.c | 20 +++++++++++++-------
>> arch/riscv/include/asm/hugetlb.h | 3 +++
>> arch/riscv/mm/hugetlbpage.c | 28 ++++++++++++++++++----------
>> arch/s390/include/asm/hugetlb.h | 3 +++
>> arch/s390/mm/hugetlbpage.c | 18 +++++++++++++-----
>> arch/sparc/include/asm/hugetlb.h | 3 +++
>> arch/sparc/mm/init_64.c | 23 ++++++++++++++++-------
>> arch/x86/include/asm/hugetlb.h | 3 +++
>> arch/x86/mm/hugetlbpage.c | 21 +++++++++++++++------
>> include/linux/hugetlb.h | 7 +++++++
>> mm/hugetlb.c | 16 +++++++++++++---
>> 14 files changed, 126 insertions(+), 43 deletions(-)
>>
>
> [snip]
>
>> diff --git a/arch/powerpc/include/asm/hugetlb.h b/arch/powerpc/include/asm/hugetlb.h
>> index bd6504c28c2f..3b5939016955 100644
>> --- a/arch/powerpc/include/asm/hugetlb.h
>> +++ b/arch/powerpc/include/asm/hugetlb.h
>> @@ -64,6 +64,9 @@ static inline void arch_clear_hugepage_flags(struct page *page)
>> {
>> }
>> +#define arch_hugetlb_valid_size arch_hugetlb_valid_size
>> +extern bool __init arch_hugetlb_valid_size(unsigned long long size);
>
> Don't add 'extern' keyword, it is irrelevant for a function declaration.
>
Will do. One of the other arch's did this and I got into a bad habit.
> checkpatch --strict doesn't like it either (https://openpower.xyz/job/snowpatch/job/snowpatch-linux-checkpatch/12318//artifact/linux/checkpatch.log)
>
>> +
>> #include <asm-generic/hugetlb.h>
>> #else /* ! CONFIG_HUGETLB_PAGE */
>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
>> index 33b3461d91e8..b78f660252f3 100644
>> --- a/arch/powerpc/mm/hugetlbpage.c
>> +++ b/arch/powerpc/mm/hugetlbpage.c
>> @@ -558,7 +558,7 @@ unsigned long vma_mmu_pagesize(struct vm_area_struct *vma)
>> return vma_kernel_pagesize(vma);
>> }
>> -static int __init add_huge_page_size(unsigned long long size)
>> +bool __init arch_hugetlb_valid_size(unsigned long long size)
>> {
>> int shift = __ffs(size);
>> int mmu_psize;
>> @@ -566,20 +566,26 @@ static int __init add_huge_page_size(unsigned long long size)
>> /* Check that it is a page size supported by the hardware and
>> * that it fits within pagetable and slice limits. */
>> if (size <= PAGE_SIZE || !is_power_of_2(size))
>> - return -EINVAL;
>> + return false;
>> mmu_psize = check_and_get_huge_psize(shift);
>> if (mmu_psize < 0)
>> - return -EINVAL;
>> + return false;
>> BUG_ON(mmu_psize_defs[mmu_psize].shift != shift);
>> - /* Return if huge page size has already been setup */
>> - if (size_to_hstate(size))
>> - return 0;
>> + return true;
>> +}
>> - hugetlb_add_hstate(shift - PAGE_SHIFT);
>> +static int __init add_huge_page_size(unsigned long long size)
>> +{
>> + int shift = __ffs(size);
>> +
>> + if (!arch_hugetlb_valid_size(size))
>> + return -EINVAL;
>> + if (!size_to_hstate(size))
>> + hugetlb_add_hstate(shift - PAGE_SHIFT);
>> return 0;
>> }
>>
>
> [snip]
>
>> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
>> index 5bfd5aef5378..51e6208fdeec 100644
>> --- a/arch/x86/mm/hugetlbpage.c
>> +++ b/arch/x86/mm/hugetlbpage.c
>> @@ -181,16 +181,25 @@ hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
>> #endif /* CONFIG_HUGETLB_PAGE */
>> #ifdef CONFIG_X86_64
>> +bool __init arch_hugetlb_valid_size(unsigned long long size)
>> +{
>> + if (size == PMD_SIZE)
>> + return true;
>> + else if (size == PUD_SIZE && boot_cpu_has(X86_FEATURE_GBPAGES))
>> + return true;
>> + else
>> + return false;
>> +}
>> +
>> static __init int setup_hugepagesz(char *opt)
>> {
>> - unsigned long ps = memparse(opt, &opt);
>> - if (ps == PMD_SIZE) {
>> - hugetlb_add_hstate(PMD_SHIFT - PAGE_SHIFT);
>> - } else if (ps == PUD_SIZE && boot_cpu_has(X86_FEATURE_GBPAGES)) {
>> - hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>> + unsigned long long ps = memparse(opt, &opt);
>> +
>> + if (arch_hugetlb_valid_size(ps)) {
>> + hugetlb_add_hstate(ilog2(ps) - PAGE_SHIFT);
>> } else {
>> hugetlb_bad_size();
>> - printk(KERN_ERR "hugepagesz: Unsupported page size %lu M\n",
>> + printk(KERN_ERR "hugepagesz: Unsupported page size %llu M\n",
>> ps >> 20);
>
> Nowadays we use pr_err() instead of printk.
>
> It would also likely allow you to have everything fit on a single line.
I may just leave this 'as is' as it will be removed in a later patch.
>> return 0;
>> }
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index b831e9fa1a26..33343eb980d0 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -678,6 +678,13 @@ static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
>> return &mm->page_table_lock;
>> }
>> +#ifndef arch_hugetlb_valid_size
>> +static inline bool arch_hugetlb_valid_size(unsigned long long size)
>> +{
>> + return (size == HPAGE_SIZE);
>
> Not sure the ( ) are necessary.
Likely not. I will look at removing.
>
>> +}
>> +#endif
>> +
>> #ifndef hugepages_supported
>> /*
>> * Some platform decide whether they support huge pages at boot
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index d8ebd876871d..2f99359b93af 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -3224,12 +3224,22 @@ static int __init hugetlb_nrpages_setup(char *s)
>> }
>> __setup("hugepages=", hugetlb_nrpages_setup);
>> -static int __init hugetlb_default_setup(char *s)
>> +static int __init default_hugepagesz_setup(char *s)
>> {
>> - default_hstate_size = memparse(s, &s);
>> + unsigned long long size;
>
> Why unsigned long long ?
>
> default_hstate_size is long.
Only because memparse is defined as unsigned long long. I actually took
this from the existing powerpc hugetlb setup code. There are no compiler
warnings/issues assigning unsigned long long to long on 64 bit builds.
Thought there would be on 32 bit platformes.
That was also the reason for making the argument to arch_hugetlb_valid_size
be unsigned long long. So that it would match the type from memparse.
I suppose making these unsigned long and casting would be OK based on the
expected sizes.
>
> I can't imagine 32 bits platforms having a hugepage with a 64 bits size.
>
>> + char *saved_s = s;
>> +
>> + size = memparse(s, &s);
>
> The updated s is not reused after that so you can pass NULL instead of &s and then you don't need the saved_s.
>
Thanks for this and all the comments. I will incorporate in v2.
--
Mike Kravetz
^ permalink raw reply
* Re: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation
From: Thomas Gleixner @ 2020-03-19 18:04 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Logan Gunthorpe, Paul E . McKenney, linuxppc-dev, Steven Rostedt,
Bjorn Helgaas, Kurt Schwemmer, Kalle Valo, Felipe Balbi,
Greg Kroah-Hartman, linux-usb, linux-wireless, LKML, netdev,
Linus Torvalds, David S. Miller
In-Reply-To: <20200319090426.512510cb@lwn.net>
Jonathan Corbet <corbet@lwn.net> writes:
> On Wed, 18 Mar 2020 21:43:10 +0100
> Thomas Gleixner <tglx@linutronix.de> wrote:
>> Add initial documentation.
>
> ...time to add a a couple of nits...:)
...time
Is that valid RST?
>> +++ b/Documentation/locking/locktypes.rst
>> @@ -0,0 +1,298 @@
>> +.. _kernel_hacking_locktypes:
>> +
>
> So ... I vaguely remember that some Thomas guy added a document saying we
> should be putting SPDX tags on our files? :)
Never met him or heard about that.
>> +
>> +The preferred solution is to use :c:func:`spin_lock_irq()` or
>> +:c:func:`spin_lock_irqsave()` and their unlock counterparts.
>
> We don't need (and shouldn't use) :c:func: anymore; just saying
> spin_lock_irq() will cause the Right Things to happen.
Good to know. Will fix.
Thanks,
tglx
^ permalink raw reply
* Re: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation
From: Thomas Gleixner @ 2020-03-19 18:02 UTC (permalink / raw)
To: paulmck
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Logan Gunthorpe,
Arnd Bergmann, linuxppc-dev, Steven Rostedt, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Greg Kroah-Hartman,
linux-usb, linux-wireless, LKML, netdev, Linus Torvalds,
David S. Miller
In-Reply-To: <20200318223137.GW3199@paulmck-ThinkPad-P72>
Paul,
"Paul E. McKenney" <paulmck@kernel.org> writes:
> On Wed, Mar 18, 2020 at 09:43:10PM +0100, Thomas Gleixner wrote:
>
> Mostly native-English-speaker services below, so please feel free to
> ignore. The one place I made a substantive change, I marked it "@@@".
> I only did about half of this document, but should this prove useful,
> I will do the other half later.
Native speaker services are always useful and appreciated.
>> +The kernel provides a variety of locking primitives which can be divided
>> +into two categories:
>> +
>> + - Sleeping locks
>> + - Spinning locks
>> +
>> +This document describes the lock types at least at the conceptual level and
>> +provides rules for nesting of lock types also under the aspect of PREEMPT_RT.
>
> I suggest something like this:
>
> This document conceptually describes these lock types and provides rules
> for their nesting, including the rules for use under PREEMPT_RT.
Way better :)
>> +Sleeping locks can only be acquired in preemptible task context.
>> +
>> +Some of the implementations allow try_lock() attempts from other contexts,
>> +but that has to be really evaluated carefully including the question
>> +whether the unlock can be done from that context safely as well.
>> +
>> +Note that some lock types change their implementation details when
>> +debugging is enabled, so this should be really only considered if there is
>> +no other option.
>
> How about something like this?
>
> Although implementations allow try_lock() from other contexts, it is
> necessary to carefully evaluate the safety of unlock() as well as of
> try_lock(). Furthermore, it is also necessary to evaluate the debugging
> versions of these primitives. In short, don't acquire sleeping locks
> from other contexts unless there is no other option.
Yup.
>> +Sleeping lock types:
>> +
>> + - mutex
>> + - rt_mutex
>> + - semaphore
>> + - rw_semaphore
>> + - ww_mutex
>> + - percpu_rw_semaphore
>> +
>> +On a PREEMPT_RT enabled kernel the following lock types are converted to
>> +sleeping locks:
>
> On PREEMPT_RT kernels, these lock types are converted to sleeping
> locks:
Ok.
>> + - spinlock_t
>> + - rwlock_t
>> +
>> +Spinning locks
>> +--------------
>> +
>> + - raw_spinlock_t
>> + - bit spinlocks
>> +
>> +On a non PREEMPT_RT enabled kernel the following lock types are spinning
>> +locks as well:
>
> On non-PREEMPT_RT kernels, these lock types are also spinning locks:
Ok.
>> + - spinlock_t
>> + - rwlock_t
>> +
>> +Spinning locks implicitly disable preemption and the lock / unlock functions
>> +can have suffixes which apply further protections:
>> +
>> + =================== ====================================================
>> + _bh() Disable / enable bottom halves (soft interrupts)
>> + _irq() Disable / enable interrupts
>> + _irqsave/restore() Save and disable / restore interrupt disabled state
>> + =================== ====================================================
>> +
>> +
>> +rtmutex
>> +=======
>> +
>> +RT-mutexes are mutexes with support for priority inheritance (PI).
>> +
>> +PI has limitations on non PREEMPT_RT enabled kernels due to preemption and
>> +interrupt disabled sections.
>> +
>> +On a PREEMPT_RT enabled kernel most of these sections are fully
>> +preemptible. This is possible because PREEMPT_RT forces most executions
>> +into task context, especially interrupt handlers and soft interrupts, which
>> +allows to substitute spinlock_t and rwlock_t with RT-mutex based
>> +implementations.
>
> PI clearly cannot preempt preemption-disabled or interrupt-disabled
> regions of code, even on PREEMPT_RT kernels. Instead, PREEMPT_RT kernels
> execute most such regions of code in preemptible task context, especially
> interrupt handlers and soft interrupts. This conversion allows spinlock_t
> and rwlock_t to be implemented via RT-mutexes.
Nice.
>> +
>> +raw_spinlock_t and spinlock_t
>> +=============================
>> +
>> +raw_spinlock_t
>> +--------------
>> +
>> +raw_spinlock_t is a strict spinning lock implementation regardless of the
>> +kernel configuration including PREEMPT_RT enabled kernels.
>> +
>> +raw_spinlock_t is to be used only in real critical core code, low level
>> +interrupt handling and places where protecting (hardware) state is required
>> +to be safe against preemption and eventually interrupts.
>> +
>> +Another reason to use raw_spinlock_t is when the critical section is tiny
>> +to avoid the overhead of spinlock_t on a PREEMPT_RT enabled kernel in the
>> +contended case.
>
> raw_spinlock_t is a strict spinning lock implementation in all kernels,
> including PREEMPT_RT kernels. Use raw_spinlock_t only in real critical
> core code, low level interrupt handling and places where disabling
> preemption or interrupts is required, for example, to safely access
> hardware state. raw_spinlock_t can sometimes also be used when the
> critical section is tiny and the lock is lightly contended, thus avoiding
> RT-mutex overhead.
>
> @@@ I added the point about the lock being lightly contended.
Hmm, not sure. The point is that if the critical section is small the
overhead of cross CPU boosting along with the resulting IPIs is going to
be at least an order of magnitude larger. And on contention this is just
pushing the raw_spinlock contention off to the raw_spinlock in the rt
mutex plus the owning tasks pi_lock which makes things even worse.
>> + - The hard interrupt related suffixes for spin_lock / spin_unlock
>> + operations (_irq, _irqsave / _irqrestore) do not affect the CPUs
> CPU's
Si senor!
>> + interrupt disabled state
>> +
>> + - The soft interrupt related suffix (_bh()) is still disabling the
>> + execution of soft interrupts, but contrary to a non PREEMPT_RT enabled
>> + kernel, which utilizes the preemption count, this is achieved by a per
>> + CPU bottom half locking mechanism.
>
> - The soft interrupt related suffix (_bh()) still disables softirq
> handlers. However, unlike non-PREEMPT_RT kernels (which disable
> preemption to get this effect), PREEMPT_RT kernels use a per-CPU
> per-bottom-half locking mechanism.
it's not per-bottom-half anymore. That turned out to be dangerous due to
dependencies between BH types, e.g. network and timers.
I hope I was able to encourage you to comment on the other half as well :)
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH -v2] treewide: Rename "unencrypted" to "decrypted"
From: Borislav Petkov @ 2020-03-19 17:42 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-s390, Dave Hansen, Vasily Gorbik, linuxppc-dev,
Peter Zijlstra, x86, Heiko Carstens, lkml, Christian Borntraeger,
iommu, Ingo Molnar, Paul Mackerras, Andy Lutomirski, Tom Lendacky,
Robin Murphy, Christoph Hellwig, Marek Szyprowski
In-Reply-To: <878sjw5k9u.fsf@nanos.tec.linutronix.de>
On Thu, Mar 19, 2020 at 06:25:49PM +0100, Thomas Gleixner wrote:
> TBH, I don't see how
>
> if (force_dma_decrypted(dev))
> set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
>
> makes more sense than the above. It's both non-sensical unless there is
9087c37584fb ("dma-direct: Force unencrypted DMA under SME for certain DMA masks")
> a big fat comment explaining what this is about.
ACK to that.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH -v2] treewide: Rename "unencrypted" to "decrypted"
From: Thomas Gleixner @ 2020-03-19 17:25 UTC (permalink / raw)
To: Borislav Petkov, Robin Murphy
Cc: linux-s390, Dave Hansen, Vasily Gorbik, Tom Lendacky,
Peter Zijlstra, x86, Heiko Carstens, lkml, Christian Borntraeger,
iommu, Ingo Molnar, Paul Mackerras, Andy Lutomirski, linuxppc-dev,
Christoph Hellwig, Marek Szyprowski
In-Reply-To: <20200319112054.GD13073@zn.tnic>
Borislav Petkov <bp@alien8.de> writes:
> On Thu, Mar 19, 2020 at 11:06:15AM +0000, Robin Murphy wrote:
>> Let me add another vote from a native English speaker that "unencrypted" is
>> the appropriate term to imply the *absence* of encryption, whereas
>> "decrypted" implies the *reversal* of applied encryption.
>>
>> Naming things is famously hard, for good reason - names are *important* for
>> understanding. Just because a decision was already made one way doesn't mean
>> that that decision was necessarily right. Churning one area to be
>> consistently inaccurate just because it's less work than churning another
>> area to be consistently accurate isn't really the best excuse.
>
> Well, the reason we chose "decrypted" vs something else is so to be as
> different from "encrypted" as possible. If we called it "unencrypted"
> you'd have stuff like:
>
> if (force_dma_unencrypted(dev))
> set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
TBH, I don't see how
if (force_dma_decrypted(dev))
set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
makes more sense than the above. It's both non-sensical unless there is
a big fat comment explaining what this is about.
Thanks,
tglx
^ permalink raw reply
* Re: [patch V2 11/15] completion: Use simple wait queues
From: Linus Torvalds @ 2020-03-19 17:12 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Paul E . McKenney,
Arnd Bergmann, linuxppc-dev, Steven Rostedt, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Greg Kroah-Hartman,
linux-usb, linux-wireless, LKML, Netdev, Logan Gunthorpe,
David S. Miller
In-Reply-To: <20200318204408.521507446@linutronix.de>
On Wed, Mar 18, 2020 at 1:47 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> There is no semantical or functional change:
Ack, with just the explanation, I'm no longer objecting to this.
Plus you fixed and cleaned up the odd usb gadget code separately
(well, most of it).
Linus
^ permalink raw reply
* Re: [PATCH 2/4] hugetlbfs: move hugepagesz= parsing to arch independent code
From: Mike Kravetz @ 2020-03-19 17:00 UTC (permalink / raw)
To: Christophe Leroy, linux-mm, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-riscv, linux-s390, sparclinux, linux-doc
Cc: Albert Ou, Vasily Gorbik, Jonathan Corbet, Catalin Marinas,
Dave Hansen, Heiko Carstens, David S.Miller,
Christian Borntraeger, Ingo Molnar, Palmer Dabbelt, Paul Walmsley,
Paul Mackerras, Andrew Morton, Longpeng, Will Deacon,
Thomas Gleixner
In-Reply-To: <2ca058dc-47e6-1d08-154b-77d2cbe98e34@c-s.fr>
On 3/19/20 12:04 AM, Christophe Leroy wrote:
>
>
> Le 18/03/2020 à 23:06, Mike Kravetz a écrit :
>> Now that architectures provide arch_hugetlb_valid_size(), parsing
>> of "hugepagesz=" can be done in architecture independent code.
>> Create a single routine to handle hugepagesz= parsing and remove
>> all arch specific routines. We can also remove the interface
>> hugetlb_bad_size() as this is no longer used outside arch independent
>> code.
>>
>> This also provides consistent behavior of hugetlbfs command line
>> options. The hugepagesz= option should only be specified once for
>> a specific size, but some architectures allow multiple instances.
>> This appears to be more of an oversight when code was added by some
>> architectures to set up ALL huge pages sizes.
>>
>> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
>> ---
>> arch/arm64/mm/hugetlbpage.c | 15 ---------------
>> arch/powerpc/mm/hugetlbpage.c | 15 ---------------
>> arch/riscv/mm/hugetlbpage.c | 16 ----------------
>> arch/s390/mm/hugetlbpage.c | 18 ------------------
>> arch/sparc/mm/init_64.c | 22 ----------------------
>> arch/x86/mm/hugetlbpage.c | 16 ----------------
>> include/linux/hugetlb.h | 1 -
>> mm/hugetlb.c | 24 ++++++++++++++++++------
>> 8 files changed, 18 insertions(+), 109 deletions(-)
>>
>
> [snip]
>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 2f99359b93af..cd4ec07080fb 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -3149,12 +3149,6 @@ static int __init hugetlb_init(void)
>> }
>> subsys_initcall(hugetlb_init);
>> -/* Should be called on processing a hugepagesz=... option */
>> -void __init hugetlb_bad_size(void)
>> -{
>> - parsed_valid_hugepagesz = false;
>> -}
>> -
>> void __init hugetlb_add_hstate(unsigned int order)
>> {
>> struct hstate *h;
>> @@ -3224,6 +3218,24 @@ static int __init hugetlb_nrpages_setup(char *s)
>> }
>> __setup("hugepages=", hugetlb_nrpages_setup);
>> +static int __init hugepagesz_setup(char *s)
>> +{
>> + unsigned long long size;
>> + char *saved_s = s;
>> +
>> + size = memparse(s, &s);
>
> You don't use s after that, so you can pass NULL instead of &s and avoid the saved_s
Thanks!
I'll incorporate in v2.
--
Mike Kravetz
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox