Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
On Tue, Oct 27, 2020 at 4:04 PM Daniel Borkmann wrote:
>
> On 10/27/20 9:57 PM, Ard Biesheuvel wrote:
> > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a
> > function scope __attribute__((optimize("-fno-gcse"))), to disable a
> > GCC specific optimization that was causing trouble on x86 builds, and
> > was not expected to have any positive effect in the first place.
> >
> > However, as the GCC manual documents, __attribute__((optimize))
> > is not for production use, and results in all other optimization
> > options to be forgotten for the function in question. This can
> > cause all kinds of trouble, but in one particular reported case,
>
> Looks like there are couple more as well aside from __no_fgcse, are you
> also planning to fix them?
>
>arch/powerpc/kernel/setup.h:14:#define __nostackprotector
> __attribute__((__optimize__("no-stack-protector")))
GCC literally just landed support for
__attribute__((no_stack_protector)) a few days ago. I was planning on
sending a patch adding it to compiler_attributes.h, but we won't be
able to rely on it for a while. Now I see I'll have to clean up ppc a
bit. Surely they've had bugs related to optimize attribute
unexpectedly dropping flags.
>tools/include/linux/compiler-gcc.h:37:#define __no_tail_call
> __attribute__((optimize("no-optimize-sibling-calls")))
Only used in perf?
tools/perf/tests/dwarf-unwind.c
>
> > it causes -fno-asynchronous-unwind-tables to be disregarded,
> > resulting in .eh_frame info to be emitted for the function
> > inadvertently.
>
> Would have been useful to add a pointer to the original discussion with
> Link tag.
>
> Link:
> https://lore.kernel.org/lkml/CAMuHMdUg0WJHEcq6to0-eODpXPOywLot6UD2=gfhpzoj_hc...@mail.gmail.com/
>
> > This reverts commit 3193c0836f203, and instead, it disables the -fgcse
> > optimization for the entire source file, but only when building for
> > X86.
> >
> > Cc: Nick Desaulniers
> > Cc: Arvind Sankar
> > Cc: Randy Dunlap
> > Cc: Josh Poimboeuf
> > Cc: Thomas Gleixner
> > Cc: Alexei Starovoitov
> > Cc: Daniel Borkmann
> > Cc: Peter Zijlstra (Intel)
> > Cc: Geert Uytterhoeven
> > Cc: Kees Cook
> > Fixes: 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> > ___bpf_prog_run()")
> > Signed-off-by: Ard Biesheuvel
> [...]
> > diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
> > index bdc8cd1b6767..02b58f44c479 100644
> > --- a/kernel/bpf/Makefile
> > +++ b/kernel/bpf/Makefile
> > @@ -1,6 +1,8 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-y := core.o
> > -CFLAGS_core.o += $(call cc-disable-warning, override-init)
> > +# ___bpf_prog_run() needs GCSE disabled on x86; see 3193c0836f203 for
> > details
> > +cflags-core-$(CONFIG_X86) := -fno-gcse
> > +CFLAGS_core.o += $(call cc-disable-warning, override-init) $(cflags-core-y)
>
> Also, this needs to be guarded behind !CONFIG_RETPOLINE and
> !CONFIG_BPF_JIT_ALWAYS_ON
> in particular the latter since only in this case interpreter is compiled in
> ... most
> distros have the CONFIG_BPF_JIT_ALWAYS_ON set these days for x86.
>
> Do you have an analysis for the commit log on what else this penalizes in
> core.c if
> it's now for the entire translation unit?
>
> > obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o
> > tnum.o bpf_iter.o map_iter.o task_iter.o prog_iter.o
> > obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o
> > bpf_lru_list.o lpm_trie.o map_in_map.o
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index 9268d77898b7..55454d2278b1 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
> > @@ -1369,7 +1369,7 @@ u64 __weak bpf_probe_read_kernel(void *dst, u32 size,
> > const void *unsafe_ptr)
> >*
> >* Decode and execute eBPF instructions.
> >*/
> > -static u64 __no_fgcse ___bpf_prog_run(u64 *regs, const struct bpf_insn
> > *insn, u64 *stack)
> > +static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64
> > *stack)
> > {
> > #define BPF_INSN_2_LBL(x, y)[BPF_##x | BPF_##y] = &##_##y
> > #define BPF_INSN_3_LBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] =
> > &##_##y##_##z
> >
>
--
Thanks,
~Nick Desaulniers
Re: [PATCH 00/13] selftests fixes
On 10/8/20 6:26 AM, Tommi Rantala wrote: Hi, small fixes to issues I hit with selftests. Tommi Rantala (13): selftests: filter kselftest headers from command in lib.mk selftests: pidfd: fix compilation errors due to wait.h selftests: add vmaccess to .gitignore selftests/harness: prettify SKIP message whitespace again selftests: pidfd: use ksft_test_result_skip() when skipping test selftests: pidfd: skip test on kcmp() ENOSYS selftests: pidfd: add CONFIG_CHECKPOINT_RESTORE=y to config selftests: pidfd: drop needless linux/kcmp.h inclusion in pidfd_setns_test.c selftests: android: fix multiple definition of sock_name selftests: proc: fix warning: _GNU_SOURCE redefined selftests: core: use SKIP instead of XFAIL in close_range_test.c selftests: clone3: use SKIP instead of XFAIL selftests: binderfs: use SKIP instead of XFAIL tools/testing/selftests/android/ion/ipcsocket.c | 1 + tools/testing/selftests/android/ion/ipcsocket.h | 2 -- .../selftests/clone3/clone3_cap_checkpoint_restore.c | 2 +- tools/testing/selftests/core/close_range_test.c | 8 .../selftests/filesystems/binderfs/binderfs_test.c| 8 tools/testing/selftests/kselftest_harness.h | 2 +- tools/testing/selftests/lib.mk| 2 +- tools/testing/selftests/pidfd/config | 1 + tools/testing/selftests/pidfd/pidfd_getfd_test.c | 5 - tools/testing/selftests/pidfd/pidfd_open_test.c | 1 - tools/testing/selftests/pidfd/pidfd_poll_test.c | 1 - tools/testing/selftests/pidfd/pidfd_setns_test.c | 1 - tools/testing/selftests/pidfd/pidfd_test.c| 2 +- tools/testing/selftests/proc/proc-loadavg-001.c | 1 - tools/testing/selftests/proc/proc-self-syscall.c | 1 - tools/testing/selftests/proc/proc-uptime-002.c| 1 - tools/testing/selftests/ptrace/.gitignore | 1 + 17 files changed, 19 insertions(+), 21 deletions(-) Thanks for fixing these. Applied all except 03/13 which is already fixed. thanks, -- Shuah
Re: [tip: x86/seves] x86/kvm: Add KVM-specific VMMCALL handling under SEV-ES
[resending in plain/text, sorry for double sending]
It seems to me that the kvm_sev_es_hcall_prepare is leaking more
information than it is needed. Is this an expected behavior?
-Erdem
>
> On Thu, Sep 10, 2020 at 2:39 AM tip-bot2 for Tom Lendacky
> wrote:
>>
>> The following commit has been merged into the x86/seves branch of tip:
>>
>> Commit-ID: 99419b251e5427b89dbfae103d8a2f469efaa4b2
>> Gitweb:
>> https://git.kernel.org/tip/99419b251e5427b89dbfae103d8a2f469efaa4b2
>> Author:Tom Lendacky
>> AuthorDate:Mon, 07 Sep 2020 15:16:04 +02:00
>> Committer: Borislav Petkov
>> CommitterDate: Wed, 09 Sep 2020 11:33:20 +02:00
>>
>> x86/kvm: Add KVM-specific VMMCALL handling under SEV-ES
>>
>> Implement the callbacks to copy the processor state required by KVM to
>> the GHCB.
>>
>> Signed-off-by: Tom Lendacky
>> [ jroe...@suse.de: - Split out of a larger patch
>>- Adapt to different callback functions ]
>> Co-developed-by: Joerg Roedel
>> Signed-off-by: Joerg Roedel
>> Signed-off-by: Borislav Petkov
>> Link: https://lkml.kernel.org/r/20200907131613.12703-64-j...@8bytes.org
>> ---
>> arch/x86/kernel/kvm.c | 35 +--
>> 1 file changed, 29 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>> index 08320b0..0f95972 100644
>> --- a/arch/x86/kernel/kvm.c
>> +++ b/arch/x86/kernel/kvm.c
>> @@ -36,6 +36,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> DEFINE_STATIC_KEY_FALSE(kvm_async_pf_enabled);
>>
>> @@ -746,13 +748,34 @@ static void __init kvm_init_platform(void)
>> x86_platform.apic_post_init = kvm_apic_init;
>> }
>>
>> +#if defined(CONFIG_AMD_MEM_ENCRYPT)
>> +static void kvm_sev_es_hcall_prepare(struct ghcb *ghcb, struct pt_regs
>> *regs)
>> +{
>> + /* RAX and CPL are already in the GHCB */
>> + ghcb_set_rbx(ghcb, regs->bx);
>> + ghcb_set_rcx(ghcb, regs->cx);
>> + ghcb_set_rdx(ghcb, regs->dx);
>> + ghcb_set_rsi(ghcb, regs->si);
>> +}
>> +
>> +static bool kvm_sev_es_hcall_finish(struct ghcb *ghcb, struct pt_regs *regs)
>> +{
>> + /* No checking of the return state needed */
>> + return true;
>> +}
>> +#endif
>> +
>> const __initconst struct hypervisor_x86 x86_hyper_kvm = {
>> - .name = "KVM",
>> - .detect = kvm_detect,
>> - .type = X86_HYPER_KVM,
>> - .init.guest_late_init = kvm_guest_init,
>> - .init.x2apic_available = kvm_para_available,
>> - .init.init_platform = kvm_init_platform,
>> + .name = "KVM",
>> + .detect = kvm_detect,
>> + .type = X86_HYPER_KVM,
>> + .init.guest_late_init = kvm_guest_init,
>> + .init.x2apic_available = kvm_para_available,
>> + .init.init_platform = kvm_init_platform,
>> +#if defined(CONFIG_AMD_MEM_ENCRYPT)
>> + .runtime.sev_es_hcall_prepare = kvm_sev_es_hcall_prepare,
>> + .runtime.sev_es_hcall_finish= kvm_sev_es_hcall_finish,
>> +#endif
>> };
>>
>> static __init int activate_jump_labels(void)
Re: [PATCH] arm64: NUMA: Kconfig: Increase max number of nodes
On Thu, Oct 22, 2020 at 12:21:27PM +0100, Robin Murphy wrote: On 2020-10-22 02:07, Vanshi Konda wrote: On Thu, Oct 22, 2020 at 12:44:15AM +0100, Robin Murphy wrote: On 2020-10-21 12:02, Jonathan Cameron wrote: On Wed, 21 Oct 2020 09:43:21 +0530 Anshuman Khandual wrote: On 10/20/2020 11:39 PM, Valentin Schneider wrote: Hi, Nit on the subject: this only increases the default, the max is still 2?. Agreed. On 20/10/20 18:34, Vanshidhar Konda wrote: The current arm64 max NUMA nodes default to 4. Today's arm64 systems can reach or exceed 16. Increase the number to 64 (matching x86_64). Signed-off-by: Vanshidhar Konda --- ??arch/arm64/Kconfig | 2 +- ??1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 893130ce1626..3e69d3c981be 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -980,7 +980,7 @@ config NUMA ??config NODES_SHIFT ?? int "Maximum NUMA Nodes (as a power of 2)" ?? range 1 10 -?? default "2" +?? default "6" This leads to more statically allocated memory for things like node to CPU maps (see uses of MAX_NUMNODES), but that shouldn't be too much of an issue. The smaller systems should not be required to waste those memory in a default case, unless there is a real and available larger system with those increased nodes. AIUI this also directly correlates to how many more page->flags bits are required: are we sure the max 10 works on any aarch64 platform? I'm We will have to test that. Besides 256 (2 ^ 8) is the first threshold to be crossed here. genuinely asking here, given that I'm mostly a stranger to the mm world. The default should be something we're somewhat confident works everywhere. Agreed. Do we really need to match X86 right now ? Do we really have systems that has 64 nodes ? We should not increase the default node value and then try to solve some new problems, when there might not be any system which could even use that. I would suggest increase NODES_SHIFT value upto as required by a real and available system. I'm not going to give precise numbers on near future systems but it is public that we ship 8 NUMA node ARM64 systems today.?? Things will get more interesting as CXL and CCIX enter the market on ARM systems, given chances are every CXL device will look like another NUMA node (CXL spec says they should be presented as such) and you may be able to rack up lots of them. So I'd argue minimum that makes sense today is 16 nodes, but looking forward even a little and 64 is not a great stretch. I'd make the jump to 64 so we can forget about this again for a year or two. People will want to run today's distros on these new machines and we'd rather not have to go around all the distros asking them to carry a patch increasing this count (I assume they are already carrying such a patch due to those 8 node systems) To echo Jonathan's statement above we are looking at systems that will need approximately 64 NUMA nodes over the next 5-6 years - the time for which an LTS kernel would be maintained. Some of the reason's for increasing NUMA nodes during this time period include CXL, CCIX and NVDIMM (like Jonathan pointed out). The main argument against increasing the NODES_SHIFT seems to be a concern that it negatively impacts other ARM64 systems. Could anyone share what kind of systems we are talking about? For a system that has NEED_MULTIPLE_NODES set, would the impact be noticeable? Systems like the ESPRESSObin - sure, sane people aren't trying to run desktops or development environments in 1GB of RAM, but it's not uncommon for them to use a minimal headless install of their favourite generic arm64 distro rather than something more "embedded" like OpenWrt or Armbian. Increasing a generic kernel's memory footprint (and perhaps more importantly, cache footprint) more than necessary is going to have *some* impact. Ampere???s platforms support multiple NUMA configuration options to meet different customer requirements. Multiple configurations have more than 4 (currrent default) NUMA nodes. These fail to initialize NUMA with the following errors in dmesg: [ 0.00] ACPI: SRAT: Too many proximity domains. [ 0.00] ACPI: SRAT: SRAT not used. [ 0.00] SRAT: Invalid NUMA node -1 in ITS affinity [ 0.00] SRAT: Invalid NUMA node -1 in ITS affinity If we look at the forecast for the next LTS kernel lifetime, the number of NUMA nodes will increase significantly due to SOCs with significantly higher core counts, increased number of memory channels, and new devices such as CCIX attached memory, etc. Supporting these platforms with a default kernel config will require a minimum NODES_SHIFT value = 6. Vanshi Robin. Vanshi Nit: I doubt any sane distro is going to carry a patch to adjust the *default* value of a Kconfig option. They might tune the actual value in their config, but, well, isn't that the whole point of configs? ;) Robin.
Re: [PATCH 3/3] kvm/eventfd: Drain events from eventfd in irqfd_wakeup()
Hi David,
I love your patch! Yet something to improve:
[auto build test ERROR on vfio/next]
[also build test ERROR on vhost/linux-next linus/master kvm/linux-next
v5.10-rc1 next-20201027]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/David-Woodhouse/Allow-in-kernel-consumers-to-drain-events-from-eventfd/20201027-215658
base: https://github.com/awilliam/linux-vfio.git next
config: x86_64-randconfig-a004-20201026 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
f2c25c70791de95d2466e09b5b58fc37f6ccd7a4)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/dc45dd9af28fede8f8dd29b705b90f78cf87538c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
David-Woodhouse/Allow-in-kernel-consumers-to-drain-events-from-eventfd/20201027-215658
git checkout dc45dd9af28fede8f8dd29b705b90f78cf87538c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> arch/x86/kvm/../../../virt/kvm/eventfd.c:197:23: error: incompatible pointer
>> types passing 'struct eventfd_ctx **' to parameter of type 'struct
>> eventfd_ctx *'; remove & [-Werror,-Wincompatible-pointer-types]
eventfd_ctx_do_read(>eventfd, );
^~~
include/linux/eventfd.h:44:46: note: passing argument to parameter 'ctx' here
void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt);
^
1 error generated.
vim +197 arch/x86/kvm/../../../virt/kvm/eventfd.c
180
181 /*
182 * Called with wqh->lock held and interrupts disabled
183 */
184 static int
185 irqfd_wakeup(wait_queue_entry_t *wait, unsigned mode, int sync, void
*key)
186 {
187 struct kvm_kernel_irqfd *irqfd =
188 container_of(wait, struct kvm_kernel_irqfd, wait);
189 __poll_t flags = key_to_poll(key);
190 struct kvm_kernel_irq_routing_entry irq;
191 struct kvm *kvm = irqfd->kvm;
192 unsigned seq;
193 int idx;
194
195 if (flags & EPOLLIN) {
196 u64 cnt;
> 197 eventfd_ctx_do_read(>eventfd, );
198
199 idx = srcu_read_lock(>irq_srcu);
200 do {
201 seq = read_seqcount_begin(>irq_entry_sc);
202 irq = irqfd->irq_entry;
203 } while (read_seqcount_retry(>irq_entry_sc,
seq));
204 /* An event has been signaled, inject an interrupt */
205 if (kvm_arch_set_irq_inatomic(, kvm,
206
KVM_USERSPACE_IRQ_SOURCE_ID, 1,
207false) == -EWOULDBLOCK)
208 schedule_work(>inject);
209 srcu_read_unlock(>irq_srcu, idx);
210 }
211
212 if (flags & EPOLLHUP) {
213 /* The eventfd is closing, detach from KVM */
214 unsigned long iflags;
215
216 spin_lock_irqsave(>irqfds.lock, iflags);
217
218 /*
219 * We must check if someone deactivated the irqfd before
220 * we could acquire the irqfds.lock since the item is
221 * deactivated from the KVM side before it is unhooked
from
222 * the wait-queue. If it is already deactivated, we can
223 * simply return knowing the other side will cleanup
for us.
224 * We cannot race against the irqfd going away since the
225 * other side is required to acquire wqh->lock, which
we hold
226 */
227 if (irqfd_is_active(irqfd))
228 irqfd_deactivate(irqfd);
229
230 spin_unlock_irqrestore(>irqfds.lock, iflags);
231 }
232
233 return 0;
234 }
235
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH 4/5] dt-bindings: memory: tegra: Add missing swgroups
On Tue, Oct 27, 2020 at 01:55:06PM +0100, Thierry Reding wrote: > This does indeed look correct, based on what registers exist for these. > It'd be good to know how Nicolin expects these to be used, since these > are currently not listed in device tree. There's certainly some like Judging from our downstream code, I don't actually expect all of them will be used, except some being used yet not got upstream. > TSEC or NVDEC that we don't support (yet) upstream, but things like DC1 > and HC1 already have equivalents that we use, so I'm not sure how we'll > integrate these new ones. Downstream code groups those equivalents swgroups, so I think we can do similarly using tegra_smmu_group_soc like the existing one for display, if any of them gets upstream someday.
Re: [PATCH 5/5] memory: tegra: Complete tegra210_swgroups
On Tue, Oct 27, 2020 at 02:01:11PM +0100, Thierry Reding wrote:
> On Wed, Oct 07, 2020 at 05:37:46PM -0700, Nicolin Chen wrote:
> > According to Tegra X1 TRM, there are missing swgroups in the
> > tegra210_swgroups list. So this patch adds them to the list.
> >
> > Note that the TEGRA_SWGROUP_GPU (in list) should be actually
> > TEGRA_SWGROUP_GPUB (in TRM), yet TEGRA_SWGROUP_GPU (in TRM)
> > is not being used -- only TEGRA_SWGROUP_GPUB (in TRM) is. So
> > this patch does not add TEGRA_SWGROUP_GPU (in TRM) and keeps
> > TEGRA_SWGROUP_GPU (in list) as it is.
> >
> > Signed-off-by: Nicolin Chen
> > ---
> > drivers/memory/tegra/tegra210.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/memory/tegra/tegra210.c
> > b/drivers/memory/tegra/tegra210.c
> > index b400802c9f14..b3bbc5a05ba1 100644
> > --- a/drivers/memory/tegra/tegra210.c
> > +++ b/drivers/memory/tegra/tegra210.c
> > @@ -1028,6 +1028,8 @@ static const struct tegra_smmu_swgroup
> > tegra210_swgroups[] = {
> > { .name = "hda", .swgroup = TEGRA_SWGROUP_HDA, .reg = 0x254
> > },
> > { .name = "isp2", .swgroup = TEGRA_SWGROUP_ISP2, .reg = 0x258
> > },
> > { .name = "nvenc", .swgroup = TEGRA_SWGROUP_NVENC, .reg = 0x264
> > },
> > + { .name = "nv",.swgroup = TEGRA_SWGROUP_NV,.reg = 0x268
> > },
> > + { .name = "nv2", .swgroup = TEGRA_SWGROUP_NV2, .reg = 0x26c
> > },
>
> Oddly enough I can see these in the TRM, but they are not in the
> internal reference manuals that are supposed to be the canonical
> reference for the TRM. Perhaps the TRM is out of date?
Hmm..I actually have been using the TRM from official site all
the time. These two aren't being used downstream either; I put
them in the patch merely because they exist in the TRM. So we
may drop them if you feel that's better.
Re: [tip: x86/seves] x86/vmware: Add VMware-specific handling for VMMCALL under SEV-ES
Looking at the VMWARE_VMCALL(cmd, eax, ebx, ecx, edx) definition, it
seems to me only 4 registers are required to be shared with
hypervisor. I don't know much about vmware but is not
vmware_sev_es_hcall_prepare expose more registers than needed and also
vmware_sev_es_hcall_finish might let the hypvervisor to modify
additional registers which are not used?
Just checking if this is intentional and what I am missing here.
Thanks
-Erdem
On Thu, Sep 10, 2020 at 2:23 AM tip-bot2 for Doug Covelli
wrote:
>
> The following commit has been merged into the x86/seves branch of tip:
>
> Commit-ID: 1a222de8dcfb903d039810b0823570ee0be4e6c6
> Gitweb:
> https://git.kernel.org/tip/1a222de8dcfb903d039810b0823570ee0be4e6c6
> Author:Doug Covelli
> AuthorDate:Mon, 07 Sep 2020 15:16:05 +02:00
> Committer: Borislav Petkov
> CommitterDate: Wed, 09 Sep 2020 11:33:20 +02:00
>
> x86/vmware: Add VMware-specific handling for VMMCALL under SEV-ES
>
> Add VMware-specific handling for #VC faults caused by VMMCALL
> instructions.
>
> Signed-off-by: Doug Covelli
> Signed-off-by: Tom Lendacky
> [ jroe...@suse.de: - Adapt to different paravirt interface ]
> Co-developed-by: Joerg Roedel
> Signed-off-by: Joerg Roedel
> Signed-off-by: Borislav Petkov
> Link: https://lkml.kernel.org/r/20200907131613.12703-65-j...@8bytes.org
> ---
> arch/x86/kernel/cpu/vmware.c | 50 +++
> 1 file changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
> index 9b6fafa..924571f 100644
> --- a/arch/x86/kernel/cpu/vmware.c
> +++ b/arch/x86/kernel/cpu/vmware.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> #undef pr_fmt
> #define pr_fmt(fmt)"vmware: " fmt
> @@ -476,10 +477,49 @@ static bool __init vmware_legacy_x2apic_available(void)
>(eax & (1 << VMWARE_CMD_LEGACY_X2APIC)) != 0;
> }
>
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
> +static void vmware_sev_es_hcall_prepare(struct ghcb *ghcb,
> + struct pt_regs *regs)
> +{
> + /* Copy VMWARE specific Hypercall parameters to the GHCB */
> + ghcb_set_rip(ghcb, regs->ip);
> + ghcb_set_rbx(ghcb, regs->bx);
> + ghcb_set_rcx(ghcb, regs->cx);
> + ghcb_set_rdx(ghcb, regs->dx);
> + ghcb_set_rsi(ghcb, regs->si);
> + ghcb_set_rdi(ghcb, regs->di);
> + ghcb_set_rbp(ghcb, regs->bp);
> +}
> +
> +static bool vmware_sev_es_hcall_finish(struct ghcb *ghcb, struct pt_regs
> *regs)
> +{
> + if (!(ghcb_rbx_is_valid(ghcb) &&
> + ghcb_rcx_is_valid(ghcb) &&
> + ghcb_rdx_is_valid(ghcb) &&
> + ghcb_rsi_is_valid(ghcb) &&
> + ghcb_rdi_is_valid(ghcb) &&
> + ghcb_rbp_is_valid(ghcb)))
> + return false;
> +
> + regs->bx = ghcb->save.rbx;
> + regs->cx = ghcb->save.rcx;
> + regs->dx = ghcb->save.rdx;
> + regs->si = ghcb->save.rsi;
> + regs->di = ghcb->save.rdi;
> + regs->bp = ghcb->save.rbp;
> +
> + return true;
> +}
> +#endif
> +
> const __initconst struct hypervisor_x86 x86_hyper_vmware = {
> - .name = "VMware",
> - .detect = vmware_platform,
> - .type = X86_HYPER_VMWARE,
> - .init.init_platform = vmware_platform_setup,
> - .init.x2apic_available = vmware_legacy_x2apic_available,
> + .name = "VMware",
> + .detect = vmware_platform,
> + .type = X86_HYPER_VMWARE,
> + .init.init_platform = vmware_platform_setup,
> + .init.x2apic_available = vmware_legacy_x2apic_available,
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
> + .runtime.sev_es_hcall_prepare = vmware_sev_es_hcall_prepare,
> + .runtime.sev_es_hcall_finish= vmware_sev_es_hcall_finish,
> +#endif
> };
Re: [PATCH v2 seccomp 1/6] seccomp: Move config option SECCOMP to arch/Kconfig
On Tue, Oct 27, 2020 at 10:52:39AM +0100, Geert Uytterhoeven wrote:
> Hi Yifei,
>
> On Thu, Sep 24, 2020 at 2:48 PM YiFei Zhu wrote:
> > From: YiFei Zhu
> >
> > In order to make adding configurable features into seccomp
> > easier, it's better to have the options at one single location,
> > considering easpecially that the bulk of seccomp code is
> > arch-independent. An quick look also show that many SECCOMP
> > descriptions are outdated; they talk about /proc rather than
> > prctl.
> >
> > As a result of moving the config option and keeping it default
> > on, architectures arm, arm64, csky, riscv, sh, and xtensa
> > did not have SECCOMP on by default prior to this and SECCOMP will
> > be default in this change.
> >
> > Architectures microblaze, mips, powerpc, s390, sh, and sparc
> > have an outdated depend on PROC_FS and this dependency is removed
> > in this change.
> >
> > Suggested-by: Jann Horn
> > Link:
> > https://lore.kernel.org/lkml/cag48ez1ywz9cnp08uzgeieyrhhdqh-ch7anwc4jrbngyrmg...@mail.gmail.com/
> > Signed-off-by: YiFei Zhu
>
> Thanks for your patch. which is now commit 282a181b1a0d66de ("seccomp:
> Move config option SECCOMP to arch/Kconfig") in v5.10-rc1.
>
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -458,6 +462,23 @@ config HAVE_ARCH_SECCOMP_FILTER
> > results in the system call being skipped immediately.
> > - seccomp syscall wired up
> >
> > +config SECCOMP
> > + def_bool y
> > + depends on HAVE_ARCH_SECCOMP
> > + prompt "Enable seccomp to safely compute untrusted bytecode"
> > + help
> > + This kernel feature is useful for number crunching applications
> > + that may need to compute untrusted bytecode during their
> > + execution. By using pipes or other transports made available to
> > + the process as file descriptors supporting the read/write
> > + syscalls, it's possible to isolate those applications in
> > + their own address space using seccomp. Once seccomp is
> > + enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
> > + and the task is only allowed to execute a few safe syscalls
> > + defined by each seccomp mode.
> > +
> > + If unsure, say Y. Only embedded should say N here.
> > +
>
> Please tell me why SECCOMP is special, and deserves to default to be
> enabled. Is it really that critical, given only 13.5 (half of sparc
> ;-) out of 24
> architectures implement support for it?
That's an excellent point; I missed this in my review as I saw several
Kconfig already marked "def_bool y" but failed to note it wasn't _all_
of them. Okay, checking before this patch, these had them effectively
enabled:
via Kconfig:
parisc
s390
um
x86
via defconfig, roughly speaking:
arm
arm64
sh
How about making the default depend on HAVE_ARCH_SECCOMP_FILTER?
These have SECCOMP_FILTER support:
arch/arm/Kconfig: select HAVE_ARCH_SECCOMP_FILTER if AEABI && !OABI_COMPAT
arch/arm64/Kconfig: select HAVE_ARCH_SECCOMP_FILTER
arch/csky/Kconfig: select HAVE_ARCH_SECCOMP_FILTER
arch/mips/Kconfig: select HAVE_ARCH_SECCOMP_FILTER
arch/parisc/Kconfig:select HAVE_ARCH_SECCOMP_FILTER
arch/powerpc/Kconfig: select HAVE_ARCH_SECCOMP_FILTER
arch/riscv/Kconfig: select HAVE_ARCH_SECCOMP_FILTER
arch/s390/Kconfig: select HAVE_ARCH_SECCOMP_FILTER
arch/sh/Kconfig:select HAVE_ARCH_SECCOMP_FILTER
arch/um/Kconfig:select HAVE_ARCH_SECCOMP_FILTER
arch/x86/Kconfig: select HAVE_ARCH_SECCOMP_FILTER
arch/xtensa/Kconfig:select HAVE_ARCH_SECCOMP_FILTER
So the "new" promotions would be:
csky
mips
powerpc
riscv
xtensa
Which would leave only these two:
arch/microblaze/Kconfig:select HAVE_ARCH_SECCOMP
arch/sparc/Kconfig: select HAVE_ARCH_SECCOMP if SPARC64
At this point, given the ubiquity of seccomp usage (e.g. systemd), I
guess it's not unreasonable to make it def_bool y?
I'm open to suggestions!
--
Kees Cook
[PATCH v5 1/3] net: phy: Add 5GBASER interface mode
Add new mode supported by MV88E6393 family.
Signed-off-by: Pavana Sharma
---
include/linux/phy.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3a09d2bf69ea..9de7c57cfd38 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -107,6 +107,7 @@ typedef enum {
PHY_INTERFACE_MODE_2500BASEX,
PHY_INTERFACE_MODE_RXAUI,
PHY_INTERFACE_MODE_XAUI,
+ PHY_INTERFACE_MODE_5GBASER,
/* 10GBASE-R, XFI, SFI - single lane 10G Serdes */
PHY_INTERFACE_MODE_10GBASER,
PHY_INTERFACE_MODE_USXGMII,
@@ -187,6 +188,8 @@ static inline const char *phy_modes(phy_interface_t
interface)
return "rxaui";
case PHY_INTERFACE_MODE_XAUI:
return "xaui";
+ case PHY_INTERFACE_MODE_5GBASER:
+ return "5gbase-r";
case PHY_INTERFACE_MODE_10GBASER:
return "10gbase-r";
case PHY_INTERFACE_MODE_USXGMII:
--
2.17.1
[PATCH v5 3/3] net: dsa: mv88e6xxx: Add support for mv88e6393x family of Marvell
The Marvell 88E6393X device is a single-chip integration of a 11-port
Ethernet switch with eight integrated Gigabit Ethernet (GbE) transceivers
and three 10-Gigabit interfaces.
This patch adds functionalities specific to mv88e6393x family (88E6393X,
88E6193X and 88E6191X)
Signed-off-by: Pavana Sharma
---
Changes in v2:
- Fix a warning (Reported-by: kernel test robot )
Changes in v3:
- Fix 'unused function' warning
Changes in v4, v5:
- Incorporated feedback from maintainers.
---
drivers/net/dsa/mv88e6xxx/chip.c| 119 +--
drivers/net/dsa/mv88e6xxx/chip.h| 20 +-
drivers/net/dsa/mv88e6xxx/global1.h | 2 +
drivers/net/dsa/mv88e6xxx/global2.h | 8 +
drivers/net/dsa/mv88e6xxx/port.c| 240 +-
drivers/net/dsa/mv88e6xxx/port.h| 40 +++-
drivers/net/dsa/mv88e6xxx/serdes.c | 296
drivers/net/dsa/mv88e6xxx/serdes.h | 89 ++---
8 files changed, 727 insertions(+), 87 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f0dbc05e30a4..6e76c1c37700 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -484,12 +484,12 @@ static int mv88e6xxx_serdes_pcs_get_state(struct
dsa_switch *ds, int port,
struct phylink_link_state *state)
{
struct mv88e6xxx_chip *chip = ds->priv;
- u8 lane;
+ int lane;
int err;
mv88e6xxx_reg_lock(chip);
lane = mv88e6xxx_serdes_get_lane(chip, port);
- if (lane && chip->info->ops->serdes_pcs_get_state)
+ if ((lane != -ENODEV) && chip->info->ops->serdes_pcs_get_state)
err = chip->info->ops->serdes_pcs_get_state(chip, port, lane,
state);
else
@@ -505,11 +505,11 @@ static int mv88e6xxx_serdes_pcs_config(struct
mv88e6xxx_chip *chip, int port,
const unsigned long *advertise)
{
const struct mv88e6xxx_ops *ops = chip->info->ops;
- u8 lane;
+ int lane;
if (ops->serdes_pcs_config) {
lane = mv88e6xxx_serdes_get_lane(chip, port);
- if (lane)
+ if (lane != -ENODEV)
return ops->serdes_pcs_config(chip, port, lane, mode,
interface, advertise);
}
@@ -522,14 +522,14 @@ static void mv88e6xxx_serdes_pcs_an_restart(struct
dsa_switch *ds, int port)
struct mv88e6xxx_chip *chip = ds->priv;
const struct mv88e6xxx_ops *ops;
int err = 0;
- u8 lane;
+ int lane;
ops = chip->info->ops;
if (ops->serdes_pcs_an_restart) {
mv88e6xxx_reg_lock(chip);
lane = mv88e6xxx_serdes_get_lane(chip, port);
- if (lane)
+ if (lane != -ENODEV)
err = ops->serdes_pcs_an_restart(chip, port, lane);
mv88e6xxx_reg_unlock(chip);
@@ -543,11 +543,11 @@ static int mv88e6xxx_serdes_pcs_link_up(struct
mv88e6xxx_chip *chip, int port,
int speed, int duplex)
{
const struct mv88e6xxx_ops *ops = chip->info->ops;
- u8 lane;
+ int lane;
if (!phylink_autoneg_inband(mode) && ops->serdes_pcs_link_up) {
lane = mv88e6xxx_serdes_get_lane(chip, port);
- if (lane)
+ if (lane != -ENODEV)
return ops->serdes_pcs_link_up(chip, port, lane,
speed, duplex);
}
@@ -634,6 +634,24 @@ static void mv88e6390x_phylink_validate(struct
mv88e6xxx_chip *chip, int port,
mv88e6390_phylink_validate(chip, port, mask, state);
}
+static void mv88e6393x_phylink_validate(struct mv88e6xxx_chip *chip, int port,
+ unsigned long *mask,
+ struct phylink_link_state *state)
+{
+ if (port == 0 || port == 9 || port == 10) {
+ phylink_set(mask, 1baseT_Full);
+ phylink_set(mask, 1baseKR_Full);
+ phylink_set(mask, 5000baseT_Full);
+ phylink_set(mask, 2500baseX_Full);
+ phylink_set(mask, 2500baseT_Full);
+ }
+
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
+
+ mv88e6065_phylink_validate(chip, port, mask, state);
+}
+
static void mv88e6xxx_validate(struct dsa_switch *ds, int port,
unsigned long *supported,
struct phylink_link_state *state)
@@ -2424,11 +2442,11 @@ static irqreturn_t mv88e6xxx_serdes_irq_thread_fn(int
irq, void *dev_id)
struct mv88e6xxx_chip *chip = mvp->chip;
irqreturn_t ret = IRQ_NONE;
int port = mvp->port;
- u8 lane;
+ int lane;
mv88e6xxx_reg_lock(chip);
[PATCH v5 2/3] dt-bindings: net: Add 5GBASER phy interface mode
Add 5GBASE-R phy interface mode supported by mv88e6393 family. Signed-off-by: Pavana Sharma --- Documentation/devicetree/bindings/net/ethernet-controller.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index fa2baca8c726..068c16fd27dc 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -92,6 +92,8 @@ properties: - rxaui - xaui + # 5GBASE-R + - 5gbase-r # 10GBASE-KR, XFI, SFI - 10gbase-kr - usxgmii -- 2.17.1
[PATCH v5 0/3] Add support for mv88e6393x family of Marvell
Updated patchset. Pavana Sharma (3): net: phy: Add 5GBASER interface mode dt-bindings: net: Add 5GBASER phy interface mode net: dsa: mv88e6xxx: Add support for mv88e6393x family of Marvell .../bindings/net/ethernet-controller.yaml | 2 + drivers/net/dsa/mv88e6xxx/chip.c | 119 ++- drivers/net/dsa/mv88e6xxx/chip.h | 20 +- drivers/net/dsa/mv88e6xxx/global1.h | 2 + drivers/net/dsa/mv88e6xxx/global2.h | 8 + drivers/net/dsa/mv88e6xxx/port.c | 240 +- drivers/net/dsa/mv88e6xxx/port.h | 40 ++- drivers/net/dsa/mv88e6xxx/serdes.c| 296 +++--- drivers/net/dsa/mv88e6xxx/serdes.h| 89 -- include/linux/phy.h | 3 + 10 files changed, 732 insertions(+), 87 deletions(-) -- 2.17.1
Re: [PATCH net 5/5] net: ipa: avoid going past end of resource group array
On Tue, Oct 27, 2020 at 12:38 PM Alex Elder wrote:
>
> The minimum and maximum limits for resources assigned to a given
> resource group are programmed in pairs, with the limits for two
> groups set in a single register.
>
> If the number of supported resource groups is odd, only half of the
> register that defines these limits is valid for the last group; that
> group has no second group in the pair.
>
> Currently we ignore this constraint, and it turns out to be harmless,
If nothing currently calls it with an odd number of registers, is this
a bugfix or a new feature (anticipating future expansion, I guess)?
> but it is not guaranteed to be. This patch addresses that, and adds
> support for programming the 5th resource group's limits.
>
> Rework how the resource group limit registers are programmed by
> having a single function program all group pairs rather than having
> one function program each pair. Add the programming of the 4-5
> resource group pair limits to this function. If a resource group is
> not supported, pass a null pointer to ipa_resource_config_common()
> for that group and have that function write zeroes in that case.
>
> Fixes: cdf2e9419dd91 ("soc: qcom: ipa: main code")
> Signed-off-by: Alex Elder
> ---
> drivers/net/ipa/ipa_main.c | 89 +++---
> 1 file changed, 53 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
> index 74b1e15ebd6b2..09c8a16d216df 100644
> --- a/drivers/net/ipa/ipa_main.c
> +++ b/drivers/net/ipa/ipa_main.c
> @@ -370,8 +370,11 @@ static bool ipa_resource_limits_valid(struct ipa *ipa,
> u32 i;
> u32 j;
>
> + /* We program at most 6 source or destination resource group limits */
> + BUILD_BUG_ON(IPA_RESOURCE_GROUP_SRC_MAX > 6);
> +
> group_count = ipa_resource_group_src_count(ipa->version);
> - if (!group_count)
> + if (!group_count || group_count >= IPA_RESOURCE_GROUP_SRC_MAX)
> return false;
Perhaps more a comment to the previous patch, but _MAX usually denotes
the end of an inclusive range, here 5. The previous name COUNT better
reflects the number of elements in range [0, 5], which is 6.
> /* Return an error if a non-zero resource limit is specified
> @@ -387,7 +390,7 @@ static bool ipa_resource_limits_valid(struct ipa *ipa,
> }
>
> group_count = ipa_resource_group_dst_count(ipa->version);
> - if (!group_count)
> + if (!group_count || group_count >= IPA_RESOURCE_GROUP_DST_MAX)
> return false;
>
> for (i = 0; i < data->resource_dst_count; i++) {
> @@ -421,46 +424,64 @@ ipa_resource_config_common(struct ipa *ipa, u32 offset,
>
> val = u32_encode_bits(xlimits->min, X_MIN_LIM_FMASK);
> val |= u32_encode_bits(xlimits->max, X_MAX_LIM_FMASK);
> - val |= u32_encode_bits(ylimits->min, Y_MIN_LIM_FMASK);
> - val |= u32_encode_bits(ylimits->max, Y_MAX_LIM_FMASK);
> + if (ylimits) {
> + val |= u32_encode_bits(ylimits->min, Y_MIN_LIM_FMASK);
> + val |= u32_encode_bits(ylimits->max, Y_MAX_LIM_FMASK);
> + }
>
> iowrite32(val, ipa->reg_virt + offset);
> }
>
> -static void ipa_resource_config_src_01(struct ipa *ipa,
> - const struct ipa_resource_src
> *resource)
> +static void ipa_resource_config_src(struct ipa *ipa,
> + const struct ipa_resource_src *resource)
> {
> - u32 offset =
> IPA_REG_SRC_RSRC_GRP_01_RSRC_TYPE_N_OFFSET(resource->type);
> + u32 group_count = ipa_resource_group_src_count(ipa->version);
> + const struct ipa_resource_limits *ylimits;
> + u32 offset;
>
> - ipa_resource_config_common(ipa, offset,
> - >limits[0],
> >limits[1]);
> -}
> + offset = IPA_REG_SRC_RSRC_GRP_01_RSRC_TYPE_N_OFFSET(resource->type);
> + ylimits = group_count == 1 ? NULL : >limits[1];
> + ipa_resource_config_common(ipa, offset, >limits[0],
> ylimits);
>
> -static void ipa_resource_config_src_23(struct ipa *ipa,
> - const struct ipa_resource_src
> *resource)
> -{
> - u32 offset =
> IPA_REG_SRC_RSRC_GRP_23_RSRC_TYPE_N_OFFSET(resource->type);
> + if (group_count < 2)
> + return;
>
> - ipa_resource_config_common(ipa, offset,
> - >limits[2],
> >limits[3]);
> -}
> + offset = IPA_REG_SRC_RSRC_GRP_23_RSRC_TYPE_N_OFFSET(resource->type);
> + ylimits = group_count == 3 ? NULL : >limits[3];
> + ipa_resource_config_common(ipa, offset, >limits[2],
> ylimits);
>
> -static void ipa_resource_config_dst_01(struct ipa *ipa,
> - const struct ipa_resource_dst
> *resource)
> -{
> - u32 offset =
> IPA_REG_DST_RSRC_GRP_01_RSRC_TYPE_N_OFFSET(resource->type);
> + if (group_count < 4)
> +
Re: [PATCH net v2] ravb: Fix bit fields checking in ravb_hwtstamp_get()
On Mon, 26 Oct 2020 05:21:30 -0500 Andrew Gabbasov wrote:
> In the function ravb_hwtstamp_get() in ravb_main.c with the existing
> values for RAVB_RXTSTAMP_TYPE_V2_L2_EVENT (0x2) and RAVB_RXTSTAMP_TYPE_ALL
> (0x6)
>
> if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_V2_L2_EVENT)
> config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L2_EVENT;
> else if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_ALL)
> config.rx_filter = HWTSTAMP_FILTER_ALL;
>
> if the test on RAVB_RXTSTAMP_TYPE_ALL should be true,
> it will never be reached.
>
> This issue can be verified with 'hwtstamp_config' testing program
> (tools/testing/selftests/net/hwtstamp_config.c). Setting filter type
> to ALL and subsequent retrieving it gives incorrect value:
>
> $ hwtstamp_config eth0 OFF ALL
> flags = 0
> tx_type = OFF
> rx_filter = ALL
> $ hwtstamp_config eth0
> flags = 0
> tx_type = OFF
> rx_filter = PTP_V2_L2_EVENT
>
> Correct this by converting if-else's to switch.
>
> Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
> Reported-by: Julia Lawall
> Signed-off-by: Andrew Gabbasov
> Reviewed-by: Sergei Shtylyov
Applied, thank you!
Re: [PATCH v2 3/4] dm: add support for passing through inline crypto support
On Tue, Oct 27, 2020 at 11:58:47PM +, Satya Tangirala wrote:
> > > +/**
> > > + * blk_ksm_update_capabilities() - Update the restrictions of a KSM to
> > > those of
> > > + * another KSM
> > > + * @target_ksm: The KSM whose restrictions to update.
> > > + * @reference_ksm: The KSM to whose restrictions this function will
> > > update
> > > + * @target_ksm's restrictions to,
> > > + */
> > > +void blk_ksm_update_capabilities(struct blk_keyslot_manager *target_ksm,
> > > + struct blk_keyslot_manager *reference_ksm)
> > > +{
> > > + memcpy(target_ksm->crypto_modes_supported,
> > > +reference_ksm->crypto_modes_supported,
> > > +sizeof(target_ksm->crypto_modes_supported));
> > > +
> > > + target_ksm->max_dun_bytes_supported =
> > > + reference_ksm->max_dun_bytes_supported;
> > > +}
> > > +EXPORT_SYMBOL_GPL(blk_ksm_update_capabilities);
> >
> > Wouldn't it be easier to replace the original blk_keyslot_manager, rather
> > than
> > modify it? Then blk_ksm_update_capabilities() wouldn't be needed.
> >
> I didn't want to replace the original blk_keyslot_manager because it's
> possible that e.g. fscrypt is checking for crypto capabilities support
> via blk_ksm_crypto_cfg_supported() when DM wants to replace the
> blk_keyslot_manager. DM would have to free the memory used by the
> blk_keyslot_manager, but blk_ksm_crypto_cfg_supported() might still
> be trying to access that memory. I did it this way to avoid having to
> add refcounts or something else to the blk_keyslot_manager...(And I
> didn't bother adding any synchronization code since the capabilities
> only ever expand, and never contract).
Are you sure that's possible? That would imply that there is no synchronization
between limits/capabilities in the request_queue being changed and the
request_queue being used. That's already buggy. Maybe it's the sort of thing
that is gotten away with in practice, in which case avoiding a free() would
indeed be a good idea, but it's worth explicitly clarifying whether all this
code is indeed racy by design...
> > > diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
> > > index cd0478d44058..2b3efa9f9fae 100644
> > > --- a/drivers/md/dm-ioctl.c
> > > +++ b/drivers/md/dm-ioctl.c
> > > @@ -1358,6 +1358,10 @@ static int table_load(struct file *filp, struct
> > > dm_ioctl *param, size_t param_si
> > > goto err_unlock_md_type;
> > > }
> > >
> > > + r = dm_verify_inline_encryption(md, t);
> > > + if (r)
> > > + goto err_unlock_md_type;
> > > +
> > > if (dm_get_md_type(md) == DM_TYPE_NONE) {
> > > /* Initial table load: acquire type of table. */
> > > dm_set_md_type(md, dm_table_get_type(t));
> > > @@ -2114,6 +2118,10 @@ int __init dm_early_create(struct dm_ioctl *dmi,
> > > if (r)
> > > goto err_destroy_table;
> > >
> > > + r = dm_verify_inline_encryption(md, t);
> > > + if (r)
> > > + goto err_destroy_table;
> > > +
> > > md->type = dm_table_get_type(t);
> > > /* setup md->queue to reflect md's type (may block) */
> > > r = dm_setup_md_queue(md, t);
> >
> > Both table_load() and dm_early_create() call dm_setup_md_queue(). Wouldn't
> > it
> > be simpler to handle inline encryption in dm_setup_md_queue(), instead of
> > doing
> > it in both table_load() and dm_early_create()?
> >
> table_load() only calls dm_setup_md_queue() on initial table load (when
> the md_type is DM_TYPE_NONE), so I can't call
> dm_verify_inline_encryption() in only dm_setup_md_queue(), because
> dm_verify_inline_encryption() needs to run on every table load.
Where do all the other limitations and capabilities of the request_queue get
updated on non-initial table loads, then?
> > > +/**
> > > + * dm_verify_inline_encryption() - Verifies that the current keyslot
> > > manager of
> > > + * the mapped_device can be replaced by
> > > the
> > > + * keyslot manager of a given dm_table.
> > > + * @md: The mapped_device
> > > + * @t: The dm_table
> > > + *
> > > + * In particular, this function checks that the keyslot manager that
> > > will be
> > > + * constructed for the dm_table will support a superset of the
> > > capabilities that
> > > + * the current keyslot manager of the mapped_device supports.
> > > + *
> > > + * Return: 0 if the table's keyslot_manager can replace the current
> > > keyslot
> > > + * manager of the mapped_device. Negative value otherwise.
> > > + */
> > > +int dm_verify_inline_encryption(struct mapped_device *md, struct
> > > dm_table *t)
> > > +{
> > > + struct blk_keyslot_manager *ksm = dm_init_inline_encryption(md, t);
> > > +
> > > + if (IS_ERR(ksm))
> > > + return PTR_ERR(ksm);
> > > + blk_ksm_destroy(ksm);
> > > +
> > > + return 0;
> > > +}
> >
> > This function seems redundant with dm_init_inline_encryption(). Wouldn't
> > it be
[PATCH 3/5] KVM: selftests: Simplify demand_paging_test with timespec_diff_now
Add a helper function to get the current time and return the time since
a given start time. Use that function to simplify the timekeeping in the
demand paging test.
This series was tested by running the following invocations on an Intel
Skylake machine:
dirty_log_perf_test -b 20m -i 100 -v 64
dirty_log_perf_test -b 20g -i 5 -v 4
dirty_log_perf_test -b 4g -i 5 -v 32
demand_paging_test -b 20m -v 64
demand_paging_test -b 20g -v 4
demand_paging_test -b 4g -v 32
All behaved as expected.
Signed-off-by: Ben Gardon
---
.../selftests/kvm/demand_paging_test.c| 26 +--
.../testing/selftests/kvm/include/test_util.h | 1 +
tools/testing/selftests/kvm/lib/test_util.c | 15 +--
3 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/tools/testing/selftests/kvm/demand_paging_test.c
b/tools/testing/selftests/kvm/demand_paging_test.c
index 4251e98ceb69f..7de6feb000760 100644
--- a/tools/testing/selftests/kvm/demand_paging_test.c
+++ b/tools/testing/selftests/kvm/demand_paging_test.c
@@ -50,7 +50,8 @@ static void *vcpu_worker(void *data)
int vcpu_id = vcpu_args->vcpu_id;
struct kvm_vm *vm = perf_test_args.vm;
struct kvm_run *run;
- struct timespec start, end, ts_diff;
+ struct timespec start;
+ struct timespec ts_diff;
vcpu_args_set(vm, vcpu_id, 1, vcpu_id);
run = vcpu_state(vm, vcpu_id);
@@ -66,8 +67,7 @@ static void *vcpu_worker(void *data)
exit_reason_str(run->exit_reason));
}
- clock_gettime(CLOCK_MONOTONIC, );
- ts_diff = timespec_sub(end, start);
+ ts_diff = timespec_diff_now(start);
PER_VCPU_DEBUG("vCPU %d execution time: %ld.%.9lds\n", vcpu_id,
ts_diff.tv_sec, ts_diff.tv_nsec);
@@ -78,7 +78,7 @@ static int handle_uffd_page_request(int uffd, uint64_t addr)
{
pid_t tid;
struct timespec start;
- struct timespec end;
+ struct timespec ts_diff;
struct uffdio_copy copy;
int r;
@@ -98,10 +98,10 @@ static int handle_uffd_page_request(int uffd, uint64_t addr)
return r;
}
- clock_gettime(CLOCK_MONOTONIC, );
+ ts_diff = timespec_diff_now(start);
PER_PAGE_DEBUG("UFFDIO_COPY %d \t%ld ns\n", tid,
- timespec_to_ns(timespec_sub(end, start)));
+ timespec_to_ns(ts_diff));
PER_PAGE_DEBUG("Paged in %ld bytes at 0x%lx from thread %d\n",
perf_test_args.host_page_size, addr, tid);
@@ -123,7 +123,8 @@ static void *uffd_handler_thread_fn(void *arg)
int pipefd = uffd_args->pipefd;
useconds_t delay = uffd_args->delay;
int64_t pages = 0;
- struct timespec start, end, ts_diff;
+ struct timespec start;
+ struct timespec ts_diff;
clock_gettime(CLOCK_MONOTONIC, );
while (!quit_uffd_thread) {
@@ -192,8 +193,7 @@ static void *uffd_handler_thread_fn(void *arg)
pages++;
}
- clock_gettime(CLOCK_MONOTONIC, );
- ts_diff = timespec_sub(end, start);
+ ts_diff = timespec_diff_now(start);
PER_VCPU_DEBUG("userfaulted %ld pages over %ld.%.9lds. (%f/sec)\n",
pages, ts_diff.tv_sec, ts_diff.tv_nsec,
pages / ((double)ts_diff.tv_sec +
(double)ts_diff.tv_nsec / 1.0));
@@ -257,7 +257,8 @@ static void run_test(enum vm_guest_mode mode, bool use_uffd,
pthread_t *vcpu_threads;
pthread_t *uffd_handler_threads = NULL;
struct uffd_handler_args *uffd_args = NULL;
- struct timespec start, end, ts_diff;
+ struct timespec start;
+ struct timespec ts_diff;
int *pipefds = NULL;
struct kvm_vm *vm;
int vcpu_id;
@@ -335,9 +336,9 @@ static void run_test(enum vm_guest_mode mode, bool use_uffd,
PER_VCPU_DEBUG("Joined thread for vCPU %d\n", vcpu_id);
}
- pr_info("All vCPU threads joined\n");
+ ts_diff = timespec_diff_now(start);
- clock_gettime(CLOCK_MONOTONIC, );
+ pr_info("All vCPU threads joined\n");
if (use_uffd) {
char c;
@@ -351,7 +352,6 @@ static void run_test(enum vm_guest_mode mode, bool use_uffd,
}
}
- ts_diff = timespec_sub(end, start);
pr_info("Total guest execution time: %ld.%.9lds\n",
ts_diff.tv_sec, ts_diff.tv_nsec);
pr_info("Overall demand paging rate: %f pgs/sec\n",
diff --git a/tools/testing/selftests/kvm/include/test_util.h
b/tools/testing/selftests/kvm/include/test_util.h
index 5eb01bf51b86f..1cc036ddb0c5e 100644
--- a/tools/testing/selftests/kvm/include/test_util.h
+++ b/tools/testing/selftests/kvm/include/test_util.h
@@ -64,5 +64,6 @@ int64_t timespec_to_ns(struct timespec ts);
struct timespec timespec_add_ns(struct timespec ts, int64_t ns);
struct timespec timespec_add(struct timespec ts1, struct timespec ts2);
struct timespec
[PATCH 5/5] KVM: selftests: Introduce the dirty log perf test
The dirty log perf test will time verious dirty logging operations
(enabling dirty logging, dirtying memory, getting the dirty log,
clearing the dirty log, and disabling dirty logging) in order to
quantify dirty logging performance. This test can be used to inform
future performance improvements to KVM's dirty logging infrastructure.
This series was tested by running the following invocations on an Intel
Skylake machine:
dirty_log_perf_test -b 20m -i 100 -v 64
dirty_log_perf_test -b 20g -i 5 -v 4
dirty_log_perf_test -b 4g -i 5 -v 32
demand_paging_test -b 20m -v 64
demand_paging_test -b 20g -v 4
demand_paging_test -b 4g -v 32
All behaved as expected.
Signed-off-by: Ben Gardon
---
tools/testing/selftests/kvm/.gitignore| 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/dirty_log_perf_test.c | 382 ++
.../selftests/kvm/include/perf_test_util.h| 18 +-
.../testing/selftests/kvm/include/test_util.h | 1 +
tools/testing/selftests/kvm/lib/test_util.c | 7 +
6 files changed, 402 insertions(+), 8 deletions(-)
create mode 100644 tools/testing/selftests/kvm/dirty_log_perf_test.c
diff --git a/tools/testing/selftests/kvm/.gitignore
b/tools/testing/selftests/kvm/.gitignore
index 307ceaadbbb99..d5dac5810d7ab 100644
--- a/tools/testing/selftests/kvm/.gitignore
+++ b/tools/testing/selftests/kvm/.gitignore
@@ -23,6 +23,7 @@
/clear_dirty_log_test
/demand_paging_test
/dirty_log_test
+/dirty_log_perf_test
/kvm_create_max_vcpus
/set_memory_region_test
/steal_time
diff --git a/tools/testing/selftests/kvm/Makefile
b/tools/testing/selftests/kvm/Makefile
index 7ebe71fbca534..6889cf5b3e72c 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -60,6 +60,7 @@ TEST_GEN_PROGS_x86_64 += x86_64/user_msr_test
TEST_GEN_PROGS_x86_64 += clear_dirty_log_test
TEST_GEN_PROGS_x86_64 += demand_paging_test
TEST_GEN_PROGS_x86_64 += dirty_log_test
+TEST_GEN_PROGS_x86_64 += dirty_log_perf_test
TEST_GEN_PROGS_x86_64 += kvm_create_max_vcpus
TEST_GEN_PROGS_x86_64 += set_memory_region_test
TEST_GEN_PROGS_x86_64 += steal_time
diff --git a/tools/testing/selftests/kvm/dirty_log_perf_test.c
b/tools/testing/selftests/kvm/dirty_log_perf_test.c
new file mode 100644
index 0..04604a26e5aea
--- /dev/null
+++ b/tools/testing/selftests/kvm/dirty_log_perf_test.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KVM dirty page logging performance test
+ *
+ * Based on dirty_log_test.c
+ *
+ * Copyright (C) 2018, Red Hat, Inc.
+ * Copyright (C) 2020, Google, Inc.
+ */
+
+#define _GNU_SOURCE /* for program_invocation_name */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kvm_util.h"
+#include "perf_test_util.h"
+#include "processor.h"
+#include "test_util.h"
+
+/* How many host loops to run by default (one KVM_GET_DIRTY_LOG for each
loop)*/
+#define TEST_HOST_LOOP_N 2UL
+
+#define DEFAULT_VCPU_MEMORY_BYTES (1UL << 30) /* 1G */
+
+/* Host variables */
+static bool host_quit;
+static uint64_t iteration;
+static uint64_t vcpu_last_completed_iteration[MAX_VCPUS];
+
+static void *vcpu_worker(void *data)
+{
+ int ret;
+ struct kvm_vm *vm = perf_test_args.vm;
+ uint64_t pages_count = 0;
+ struct kvm_run *run;
+ struct timespec start;
+ struct timespec ts_diff;
+ struct timespec total = (struct timespec){0};
+ struct timespec avg;
+ struct vcpu_args *vcpu_args = (struct vcpu_args *)data;
+ int vcpu_id = vcpu_args->vcpu_id;
+
+ vcpu_args_set(vm, vcpu_id, 1, vcpu_id);
+ run = vcpu_state(vm, vcpu_id);
+
+ while (!READ_ONCE(host_quit)) {
+ uint64_t current_iteration = READ_ONCE(iteration);
+
+ clock_gettime(CLOCK_MONOTONIC, );
+ ret = _vcpu_run(vm, vcpu_id);
+ ts_diff = timespec_diff_now(start);
+
+ TEST_ASSERT(ret == 0, "vcpu_run failed: %d\n", ret);
+ TEST_ASSERT(get_ucall(vm, vcpu_id, NULL) == UCALL_SYNC,
+ "Invalid guest sync status: exit_reason=%s\n",
+ exit_reason_str(run->exit_reason));
+
+ pr_debug("Got sync event from vCPU %d\n", vcpu_id);
+ vcpu_last_completed_iteration[vcpu_id] = current_iteration;
+ pr_debug("vCPU %d updated last completed iteration to %lu\n",
+vcpu_id, vcpu_last_completed_iteration[vcpu_id]);
+
+ if (current_iteration) {
+ pages_count += vcpu_args->pages;
+ total = timespec_add(total, ts_diff);
+ pr_debug("vCPU %d iteration %lu dirty memory time:
%ld.%.9lds\n",
+ vcpu_id, current_iteration, ts_diff.tv_sec,
+ ts_diff.tv_nsec);
+ } else {
+ pr_debug("vCPU %d iteration %lu populate memory
Re: [PATCH v2 3/4] dm: add support for passing through inline crypto support
On Tue, Oct 27, 2020 at 02:31:51PM -0700, Eric Biggers wrote:
> On Thu, Oct 15, 2020 at 09:46:31PM +, Satya Tangirala wrote:
> > Update the device-mapper core to support exposing the inline crypto
> > support of the underlying device(s) through the device-mapper device.
> >
> > This works by creating a "passthrough keyslot manager" for the dm
> > device, which declares support for encryption settings which all
> > underlying devices support. When a supported setting is used, the bio
> > cloning code handles cloning the crypto context to the bios for all the
> > underlying devices. When an unsupported setting is used, the blk-crypto
> > fallback is used as usual.
> >
> > Crypto support on each underlying device is ignored unless the
> > corresponding dm target opts into exposing it. This is needed because
> > for inline crypto to semantically operate on the original bio, the data
> > must not be transformed by the dm target. Thus, targets like dm-linear
> > can expose crypto support of the underlying device, but targets like
> > dm-crypt can't. (dm-crypt could use inline crypto itself, though.)
> >
> > When a key is evicted from the dm device, it is evicted from all
> > underlying devices.
> >
> > A DM device's table can only be changed if the "new" inline encryption
> > capabilities are a superset of the "old" inline encryption capabilities.
> > Attempts to make changes to the table that result in some inline encryption
> > capability becoming no longer supported will be rejected.
> >
> > Co-developed-by: Eric Biggers
> > Signed-off-by: Eric Biggers
> > Signed-off-by: Satya Tangirala
> > ---
> > block/blk-crypto.c | 1 +
> > block/keyslot-manager.c | 89 +
> > drivers/md/dm-ioctl.c | 8 ++
> > drivers/md/dm.c | 217 +++-
> > drivers/md/dm.h | 19 +++
> > include/linux/device-mapper.h | 6 +
> > include/linux/keyslot-manager.h | 17 +++
> > 7 files changed, 356 insertions(+), 1 deletion(-)
>
> I'm having a hard time understanding what's going on in this patch now.
> Besides
> the simplifications I'm suggesting in other comments below, you should
> consider
> splitting this into more than one patch. The block layer changes could be a
> separate patch, as could the key eviction support.
>
Sure - I'll also add more details on the patch in the commit message.
> >
> > diff --git a/block/blk-crypto.c b/block/blk-crypto.c
> > index 5da43f0973b4..c2be8f15006c 100644
> > --- a/block/blk-crypto.c
> > +++ b/block/blk-crypto.c
> > @@ -409,3 +409,4 @@ int blk_crypto_evict_key(struct request_queue *q,
> > */
> > return blk_crypto_fallback_evict_key(key);
> > }
> > +EXPORT_SYMBOL_GPL(blk_crypto_evict_key);
> > diff --git a/block/keyslot-manager.c b/block/keyslot-manager.c
> > index 5ad476dafeab..e16e4a074765 100644
> > --- a/block/keyslot-manager.c
> > +++ b/block/keyslot-manager.c
> > @@ -416,6 +416,95 @@ void blk_ksm_unregister(struct request_queue *q)
> > {
> > q->ksm = NULL;
> > }
> > +EXPORT_SYMBOL_GPL(blk_ksm_unregister);
>
> blk_ksm_unregister() doesn't seem to be necessary, since it just sets a
> pointer
> to NULL, which the callers could easily do themselves.
>
> > +/**
> > + * blk_ksm_intersect_modes() - restrict supported modes by child device
> > + * @parent: The keyslot manager for parent device
> > + * @child: The keyslot manager for child device, or NULL
> > + *
> > + * Clear any crypto mode support bits in @parent that aren't set in @child.
> > + * If @child is NULL, then all parent bits are cleared.
> > + *
> > + * Only use this when setting up the keyslot manager for a layered device,
> > + * before it's been exposed yet.
> > + */
> > +void blk_ksm_intersect_modes(struct blk_keyslot_manager *parent,
> > +const struct blk_keyslot_manager *child)
> > +{
> > + if (child) {
> > + unsigned int i;
> > +
> > + parent->max_dun_bytes_supported =
> > + min(parent->max_dun_bytes_supported,
> > + child->max_dun_bytes_supported);
> > + for (i = 0; i < ARRAY_SIZE(child->crypto_modes_supported);
> > +i++) {
> > + parent->crypto_modes_supported[i] &=
> > + child->crypto_modes_supported[i];
> > + }
> > + } else {
> > + parent->max_dun_bytes_supported = 0;
> > + memset(parent->crypto_modes_supported, 0,
> > + sizeof(parent->crypto_modes_supported));
> > + }
> > +}
> > +EXPORT_SYMBOL_GPL(blk_ksm_intersect_modes);
> > +
> > +/**
> > + * blk_ksm_is_superset() - Check if a KSM supports a superset of crypto
> > modes
> > + *and DUN bytes that another KSM supports.
> > + * @ksm_superset: The KSM that we want to verify is a superset
> > + * @ksm_subset: The KSM that we want to verify is a subset
> > + *
> > + * Return: True if @ksm_superset supports
Re: [PATCH 1/3] powerpc/uaccess: Switch __put_user_size_allowed() to __put_user_asm_goto()
On Okt 28 2020, Andreas Schwab wrote: > On Sep 04 2020, Christophe Leroy wrote: > >> __put_user_asm_goto() provides more flexibility to GCC and avoids using >> a local variable to tell if the write succeeded or not. >> GCC can then avoid implementing a cmp in the fast path. > > That breaks CLONE_CHILD_SETTID. I'm getting an assertion failure in > __libc_fork (THREAD_GETMEM (self, tid) != ppid). This is what schedule_tail now looks like. As you can see, put_user has become a nop: 455c <.schedule_tail>: 455c: 7c 08 02 a6 mflrr0 4560: f8 01 00 10 std r0,16(r1) 4564: f8 21 ff 91 stdur1,-112(r1) 4568: 4b ff cd 4d bl 12b4 <.finish_task_switch> 456c: 4b ff c0 99 bl 604 <.balance_callback> 4570: e8 6d 01 88 ld r3,392(r13) 4574: e9 23 06 b0 ld r9,1712(r3) 4578: 2f a9 00 00 cmpdi cr7,r9,0 457c: 41 9e 00 14 beq cr7,4590 <.schedule_tail+0x34> 4580: 38 80 00 00 li r4,0 4584: 38 a0 00 00 li r5,0 4588: 48 00 00 01 bl 4588 <.schedule_tail+0x2c> 4588: R_PPC64_REL24 .__task_pid_nr_ns 458c: 60 00 00 00 nop 4590: 48 00 00 01 bl 4590 <.schedule_tail+0x34> 4590: R_PPC64_REL24 .calculate_sigpending 4594: 60 00 00 00 nop 4598: 38 21 00 70 addir1,r1,112 459c: e8 01 00 10 ld r0,16(r1) 45a0: 7c 08 03 a6 mtlrr0 45a4: 4e 80 00 20 blr This is schedule_tail in 5.9: 455c <.schedule_tail>: 455c: 7c 08 02 a6 mflrr0 4560: fb c1 ff f0 std r30,-16(r1) 4564: fb e1 ff f8 std r31,-8(r1) 4568: f8 01 00 10 std r0,16(r1) 456c: f8 21 ff 81 stdur1,-128(r1) 4570: 4b ff cd 45 bl 12b4 <.finish_task_switch> 4574: 4b ff c0 91 bl 604 <.balance_callback> 4578: eb cd 01 88 ld r30,392(r13) 457c: eb fe 06 b0 ld r31,1712(r30) 4580: 2f bf 00 00 cmpdi cr7,r31,0 4584: 41 9e 00 2c beq cr7,45b0 <.schedule_tail+0x54> 4588: 7f c3 f3 78 mr r3,r30 458c: 38 80 00 00 li r4,0 4590: 38 a0 00 00 li r5,0 4594: 48 00 00 01 bl 4594 <.schedule_tail+0x38> 4594: R_PPC64_REL24 .__task_pid_nr_ns 4598: 60 00 00 00 nop 459c: e9 3e 0a b8 ld r9,2744(r30) 45a0: 7f bf 48 40 cmpld cr7,r31,r9 45a4: 41 9d 00 0c bgt cr7,45b0 <.schedule_tail+0x54> 45a8: 2b a9 00 03 cmpldi cr7,r9,3 45ac: 41 9d 00 14 bgt cr7,45c0 <.schedule_tail+0x64> 45b0: 48 00 00 01 bl 45b0 <.schedule_tail+0x54> 45b0: R_PPC64_REL24 .calculate_sigpending 45b4: 60 00 00 00 nop 45b8: 38 21 00 80 addir1,r1,128 45bc: 48 00 00 00 b 45bc <.schedule_tail+0x60> 45bc: R_PPC64_REL24 _restgpr0_30 45c0: 39 20 00 00 li r9,0 45c4: 90 7f 00 00 stw r3,0(r31) 45c8: 4b ff ff e8 b 45b0 <.schedule_tail+0x54> Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[PATCH 0/5] Add a dirty logging performance test
Currently KVM lacks a simple, userspace agnostic, performance benchmark for dirty logging. Such a benchmark will be beneficial for ensuring that dirty logging performance does not regress, and to give a common baseline for validating performance improvements. The dirty log perf test introduced in this series builds on aspects of the existing demand paging perf test and provides time-based performance metrics for enabling and disabling dirty logging, getting the dirty log, and dirtying memory. While the test currently only has a build target for x86, I expect it will work on, or be easily modified to support other architectures. Ben Gardon (5): KVM: selftests: Factor code out of demand_paging_test KVM: selftests: Remove address rounding in guest code KVM: selftests: Simplify demand_paging_test with timespec_diff_now KVM: selftests: Add wrfract to common guest code KVM: selftests: Introduce the dirty log perf test tools/testing/selftests/kvm/.gitignore| 1 + tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/demand_paging_test.c| 230 ++- .../selftests/kvm/dirty_log_perf_test.c | 382 ++ .../selftests/kvm/include/perf_test_util.h| 192 + .../testing/selftests/kvm/include/test_util.h | 2 + tools/testing/selftests/kvm/lib/test_util.c | 22 +- 7 files changed, 635 insertions(+), 195 deletions(-) create mode 100644 tools/testing/selftests/kvm/dirty_log_perf_test.c create mode 100644 tools/testing/selftests/kvm/include/perf_test_util.h -- 2.29.0.rc2.309.g374f81d7ae-goog
[PATCH 1/5] KVM: selftests: Factor code out of demand_paging_test
Much of the code in demand_paging_test can be reused by other, similar
multi-vCPU-memory-touching-perfromance-tests. Factor that common code
out for reuse.
No functional change expected.
This series was tested by running the following invocations on an Intel
Skylake machine:
dirty_log_perf_test -b 20m -i 100 -v 64
dirty_log_perf_test -b 20g -i 5 -v 4
dirty_log_perf_test -b 4g -i 5 -v 32
demand_paging_test -b 20m -v 64
demand_paging_test -b 20g -v 4
demand_paging_test -b 4g -v 32
All behaved as expected.
Signed-off-by: Ben Gardon
---
.../selftests/kvm/demand_paging_test.c| 204 ++
.../selftests/kvm/include/perf_test_util.h| 187
2 files changed, 210 insertions(+), 181 deletions(-)
create mode 100644 tools/testing/selftests/kvm/include/perf_test_util.h
diff --git a/tools/testing/selftests/kvm/demand_paging_test.c
b/tools/testing/selftests/kvm/demand_paging_test.c
index 360cd3ea4cd67..4251e98ceb69f 100644
--- a/tools/testing/selftests/kvm/demand_paging_test.c
+++ b/tools/testing/selftests/kvm/demand_paging_test.c
@@ -21,18 +21,12 @@
#include
#include
-#include "test_util.h"
-#include "kvm_util.h"
+#include "perf_test_util.h"
#include "processor.h"
+#include "test_util.h"
#ifdef __NR_userfaultfd
-/* The memory slot index demand page */
-#define TEST_MEM_SLOT_INDEX1
-
-/* Default guest test virtual memory offset */
-#define DEFAULT_GUEST_TEST_MEM 0xc000
-
#define DEFAULT_GUEST_TEST_MEM_SIZE (1 << 30) /* 1G */
#ifdef PRINT_PER_PAGE_UPDATES
@@ -47,75 +41,14 @@
#define PER_VCPU_DEBUG(...) _no_printf(__VA_ARGS__)
#endif
-#define MAX_VCPUS 512
-
-/*
- * Guest/Host shared variables. Ensure addr_gva2hva() and/or
- * sync_global_to/from_guest() are used when accessing from
- * the host. READ/WRITE_ONCE() should also be used with anything
- * that may change.
- */
-static uint64_t host_page_size;
-static uint64_t guest_page_size;
-
static char *guest_data_prototype;
-/*
- * Guest physical memory offset of the testing memory slot.
- * This will be set to the topmost valid physical address minus
- * the test memory size.
- */
-static uint64_t guest_test_phys_mem;
-
-/*
- * Guest virtual memory offset of the testing memory slot.
- * Must not conflict with identity mapped test code.
- */
-static uint64_t guest_test_virt_mem = DEFAULT_GUEST_TEST_MEM;
-
-struct vcpu_args {
- uint64_t gva;
- uint64_t pages;
-
- /* Only used by the host userspace part of the vCPU thread */
- int vcpu_id;
- struct kvm_vm *vm;
-};
-
-static struct vcpu_args vcpu_args[MAX_VCPUS];
-
-/*
- * Continuously write to the first 8 bytes of each page in the demand paging
- * memory region.
- */
-static void guest_code(uint32_t vcpu_id)
-{
- uint64_t gva;
- uint64_t pages;
- int i;
-
- /* Make sure vCPU args data structure is not corrupt. */
- GUEST_ASSERT(vcpu_args[vcpu_id].vcpu_id == vcpu_id);
-
- gva = vcpu_args[vcpu_id].gva;
- pages = vcpu_args[vcpu_id].pages;
-
- for (i = 0; i < pages; i++) {
- uint64_t addr = gva + (i * guest_page_size);
-
- addr &= ~(host_page_size - 1);
- *(uint64_t *)addr = 0x0123456789ABCDEF;
- }
-
- GUEST_SYNC(1);
-}
-
static void *vcpu_worker(void *data)
{
int ret;
- struct vcpu_args *args = (struct vcpu_args *)data;
- struct kvm_vm *vm = args->vm;
- int vcpu_id = args->vcpu_id;
+ struct vcpu_args *vcpu_args = (struct vcpu_args *)data;
+ int vcpu_id = vcpu_args->vcpu_id;
+ struct kvm_vm *vm = perf_test_args.vm;
struct kvm_run *run;
struct timespec start, end, ts_diff;
@@ -141,39 +74,6 @@ static void *vcpu_worker(void *data)
return NULL;
}
-#define PAGE_SHIFT_4K 12
-#define PTES_PER_4K_PT 512
-
-static struct kvm_vm *create_vm(enum vm_guest_mode mode, int vcpus,
- uint64_t vcpu_memory_bytes)
-{
- struct kvm_vm *vm;
- uint64_t pages = DEFAULT_GUEST_PHY_PAGES;
-
- /* Account for a few pages per-vCPU for stacks */
- pages += DEFAULT_STACK_PGS * vcpus;
-
- /*
-* Reserve twice the ammount of memory needed to map the test region and
-* the page table / stacks region, at 4k, for page tables. Do the
-* calculation with 4K page size: the smallest of all archs. (e.g., 64K
-* page size guest will need even less memory for page tables).
-*/
- pages += (2 * pages) / PTES_PER_4K_PT;
- pages += ((2 * vcpus * vcpu_memory_bytes) >> PAGE_SHIFT_4K) /
-PTES_PER_4K_PT;
- pages = vm_adjust_num_guest_pages(mode, pages);
-
- pr_info("Testing guest mode: %s\n", vm_guest_mode_string(mode));
-
- vm = _vm_create(mode, pages, O_RDWR);
- kvm_vm_elf_load(vm, program_invocation_name, 0, 0);
-#ifdef __x86_64__
- vm_create_irqchip(vm);
-#endif
- return vm;
-}
-
static int
[PATCH 4/5] KVM: selftests: Add wrfract to common guest code
Wrfract will be used by the dirty logging perf test introduced later in
this series to dirty memory sparsely.
This series was tested by running the following invocations on an Intel
Skylake machine:
dirty_log_perf_test -b 20m -i 100 -v 64
dirty_log_perf_test -b 20g -i 5 -v 4
dirty_log_perf_test -b 4g -i 5 -v 32
demand_paging_test -b 20m -v 64
demand_paging_test -b 20g -v 4
demand_paging_test -b 4g -v 32
All behaved as expected.
Signed-off-by: Ben Gardon
---
tools/testing/selftests/kvm/demand_paging_test.c | 2 ++
tools/testing/selftests/kvm/include/perf_test_util.h | 6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/demand_paging_test.c
b/tools/testing/selftests/kvm/demand_paging_test.c
index 7de6feb000760..47defc65aedac 100644
--- a/tools/testing/selftests/kvm/demand_paging_test.c
+++ b/tools/testing/selftests/kvm/demand_paging_test.c
@@ -266,6 +266,8 @@ static void run_test(enum vm_guest_mode mode, bool use_uffd,
vm = create_vm(mode, vcpus, vcpu_memory_bytes);
+ perf_test_args.wr_fract = 1;
+
guest_data_prototype = malloc(perf_test_args.host_page_size);
TEST_ASSERT(guest_data_prototype,
"Failed to allocate buffer for guest data pattern");
diff --git a/tools/testing/selftests/kvm/include/perf_test_util.h
b/tools/testing/selftests/kvm/include/perf_test_util.h
index 838f946700f0c..1716300469c04 100644
--- a/tools/testing/selftests/kvm/include/perf_test_util.h
+++ b/tools/testing/selftests/kvm/include/perf_test_util.h
@@ -46,6 +46,7 @@ struct perf_test_args {
struct kvm_vm *vm;
uint64_t host_page_size;
uint64_t guest_page_size;
+ int wr_fract;
struct vcpu_args vcpu_args[MAX_VCPUS];
};
@@ -72,7 +73,10 @@ static void guest_code(uint32_t vcpu_id)
for (i = 0; i < pages; i++) {
uint64_t addr = gva + (i * perf_test_args.guest_page_size);
- *(uint64_t *)addr = 0x0123456789ABCDEF;
+ if (i % perf_test_args.wr_fract == 0)
+ *(uint64_t *)addr = 0x0123456789ABCDEF;
+ else
+ READ_ONCE(*(uint64_t *)addr);
}
GUEST_SYNC(1);
--
2.29.0.rc2.309.g374f81d7ae-goog
Re: [PATCH 1/2] dt-bindings: mediatek: mmsys: add mt1867 binding
Hi, Fabien: Fabien Parent 於 2020年10月28日 週三 上午12:07寫道： > > Add binding documentation for MT8167 SoC. > Reviewed-by: Chun-Kuang Hu > Signed-off-by: Fabien Parent > --- > .../devicetree/bindings/arm/mediatek/mediatek,mmsys.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt > index d8c9108c3b4a..78c50733985c 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt > @@ -13,6 +13,7 @@ Required Properties: > - "mediatek,mt6779-mmsys", "syscon" > - "mediatek,mt6797-mmsys", "syscon" > - "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon" > + - "mediatek,mt8167-mmsys", "syscon" > - "mediatek,mt8173-mmsys", "syscon" > - "mediatek,mt8183-mmsys", "syscon" > - #clock-cells: Must be 1 > -- > 2.28.0 > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 1/3] sched: better handling for busy polling loops
On Fri, Oct 23, 2020 at 12:19 AM Peter Zijlstra wrote:
>
> On Thu, Oct 22, 2020 at 08:29:42PM -0700, Josh Don wrote:
> > Busy polling loops in the kernel such as network socket poll and kvm
> > halt polling have performance problems related to process scheduler load
> > accounting.
>
> AFAICT you're not actually fixing the load accounting issue at all.
Halt polling is an ephemeral state, and the goal is not to adjust the
accounting, but rather to allow wake up balance to identify polling
cpus.
> > This change also disables preemption for the duration of the busy
> > polling loop. This is important, as it ensures that if a polling thread
> > decides to end its poll to relinquish cpu to another thread, the polling
> > thread will actually exit the busy loop and potentially block. When it
> > later becomes runnable, it will have the opportunity to find an idle cpu
> > via wakeup cpu selection.
>
> At the cost of inducing a sleep+wake cycle; which is mucho expensive. So
> this could go either way. No data presented.
I can take a look at getting some data on that. What I do have is data
that reflects an overall improvement in machine efficiency. On heavily
loaded hosts, we were able to recoup ~2% of cycles.
> > +void prepare_to_busy_poll(void)
> > +{
> > + struct rq __maybe_unused *rq = this_rq();
> > + unsigned long __maybe_unused flags;
> > +
> > + /* Preemption will be reenabled by end_busy_poll() */
> > + preempt_disable();
> > +
> > +#ifdef CONFIG_SMP
> > + raw_spin_lock_irqsave(>lock, flags);
> > + /* preemption disabled; only one thread can poll at a time */
> > + WARN_ON_ONCE(rq->busy_polling);
> > + rq->busy_polling++;
> > + raw_spin_unlock_irqrestore(>lock, flags);
> > +#endif
>
> Explain to me the purpose of that rq->lock usage.
This was required in a previous iteration, but failed to drop after a refactor.
> > +int continue_busy_poll(void)
> > +{
> > + if (!single_task_running())
> > + return 0;
>
> Why? If there's more, we'll end up in the below condition anyway.
>
Migrating a task over won't necessarily set need_resched. Though it
does make sense to allow check_preempt_curr to set it directly in this
case.
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index 28709f6b0975..45de468d0ffb 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -1003,6 +1003,8 @@ struct rq {
> >
> > /* This is used to determine avg_idle's max value */
> > u64 max_idle_balance_cost;
> > +
> > + unsigned intbusy_polling;
>
> This is a good location, cache-wise, because?
>
> > #endif /* CONFIG_SMP */
> >
> > #ifdef CONFIG_IRQ_TIME_ACCOUNTING
Good call out, I didn't consider that.
Re: [PATCH v4 2/2] fs: ext4: Modify inode-test.c to use KUnit parameterized testing feature
Hi Arpitha, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on ext4/dev] [also build test WARNING on linus/master v5.10-rc1 next-20201027] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Arpitha-Raghunandan/kunit-Support-for-Parameterized-Testing/20201028-015018 base: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev config: mips-randconfig-r016-20201027 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/2de1e52708cd83d1dc4c718876683f6809045a98 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Arpitha-Raghunandan/kunit-Support-for-Parameterized-Testing/20201028-015018 git checkout 2de1e52708cd83d1dc4c718876683f6809045a98 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from fs/ext4/inode-test.c:7: fs/ext4/inode-test.c: In function 'ext4_inode_gen_params': >> include/kunit/test.h:1735:58: warning: return discards 'const' qualifier >> from pointer target type [-Wdiscarded-qualifiers] 1735 | return __next - (array) < ARRAY_SIZE((array)) ? __next : NULL; \ fs/ext4/inode-test.c:214:1: note: in expansion of macro 'KUNIT_ARRAY_PARAM' 214 | KUNIT_ARRAY_PARAM(ext4_inode, test_data); | ^ vim +/const +1735 include/kunit/test.h 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1154 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1155 #define KUNIT_PTR_NOT_ERR_OR_NULL_ASSERTION(test, assert_type, ptr) \ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1156 KUNIT_PTR_NOT_ERR_OR_NULL_MSG_ASSERTION(test, \ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1157 assert_type, \ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1158 ptr, \ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1159 NULL) 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1160 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1161 /** 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1162 * KUNIT_EXPECT_TRUE() - Causes a test failure when the expression is not true. 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1163 * @test: The test context object. 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1164 * @condition: an arbitrary boolean expression. The test fails when this does 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1165 * not evaluate to true. 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1166 * 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1167 * This and expectations of the form `KUNIT_EXPECT_*` will cause the test case 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1168 * to fail when the specified condition is not met; however, it will not prevent 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1169 * the test case from continuing to run; this is otherwise known as an 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1170 * *expectation failure*. 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1171 */ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1172 #define KUNIT_EXPECT_TRUE(test, condition) \ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1173 KUNIT_TRUE_ASSERTION(test, KUNIT_EXPECTATION, condition) 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1174 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1175 #define KUNIT_EXPECT_TRUE_MSG(test, condition, fmt, ...) \ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1176 KUNIT_TRUE_MSG_ASSERTION(test, \ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1177 KUNIT_EXPECTATION,\ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1178 condition,\ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1179 fmt, \ 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1180 ##__VA_ARGS__) 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1181 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1182 /** 73cda7bb8bfb1d Brendan Higgins 2019-09-23 1183
[PATCH 2/5] KVM: selftests: Remove address rounding in guest code
Rounding the address the guest writes to a host page boundary
will only have an effect if the host page size is larger than the guest
page size, but in that case the guest write would still go to the same
host page. There's no reason to round the address down, so remove the
rounding to simplify the demand paging test.
This series was tested by running the following invocations on an Intel
Skylake machine:
dirty_log_perf_test -b 20m -i 100 -v 64
dirty_log_perf_test -b 20g -i 5 -v 4
dirty_log_perf_test -b 4g -i 5 -v 32
demand_paging_test -b 20m -v 64
demand_paging_test -b 20g -v 4
demand_paging_test -b 4g -v 32
All behaved as expected.
Signed-off-by: Ben Gardon
---
tools/testing/selftests/kvm/include/perf_test_util.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/include/perf_test_util.h
b/tools/testing/selftests/kvm/include/perf_test_util.h
index f71f0858a1f29..838f946700f0c 100644
--- a/tools/testing/selftests/kvm/include/perf_test_util.h
+++ b/tools/testing/selftests/kvm/include/perf_test_util.h
@@ -72,7 +72,6 @@ static void guest_code(uint32_t vcpu_id)
for (i = 0; i < pages; i++) {
uint64_t addr = gva + (i * perf_test_args.guest_page_size);
- addr &= ~(perf_test_args.host_page_size - 1);
*(uint64_t *)addr = 0x0123456789ABCDEF;
}
--
2.29.0.rc2.309.g374f81d7ae-goog
Re: [PATCH 1/3] powerpc/uaccess: Switch __put_user_size_allowed() to __put_user_asm_goto()
On Sep 04 2020, Christophe Leroy wrote: > __put_user_asm_goto() provides more flexibility to GCC and avoids using > a local variable to tell if the write succeeded or not. > GCC can then avoid implementing a cmp in the fast path. That breaks CLONE_CHILD_SETTID. I'm getting an assertion failure in __libc_fork (THREAD_GETMEM (self, tid) != ppid). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH/RFC net-next v3] net: dec: tulip: de2104x: Add shutdown handler to stop NIC
On Fri, 23 Oct 2020 13:28:34 -0700 Moritz Fischer wrote:
> diff --git a/drivers/net/ethernet/dec/tulip/de2104x.c
> b/drivers/net/ethernet/dec/tulip/de2104x.c
> index d9f6c19940ef..ea7442cc8e75 100644
> --- a/drivers/net/ethernet/dec/tulip/de2104x.c
> +++ b/drivers/net/ethernet/dec/tulip/de2104x.c
> @@ -2175,11 +2175,19 @@ static int __maybe_unused de_resume(struct device
> *dev_d)
>
> static SIMPLE_DEV_PM_OPS(de_pm_ops, de_suspend, de_resume);
>
> +static void de_shutdown(struct pci_dev *pdev)
> +{
> + struct net_device *dev = pci_get_drvdata(pdev);
> +
> + de_close(dev);
Apparently I get all the best ideas when I'm about to apply something..
I don't think you can just call de_close() like that, because
(a) it may expect rtnl_lock() to be held, and (b) it may not be open.
Perhaps call unregister_netdev(dev) - that'll close the device.
Or rtnl_lock(); dev_close(dev); rtnl_unlock();
> +}
> +
> static struct pci_driver de_driver = {
> .name = DRV_NAME,
> .id_table = de_pci_tbl,
> .probe = de_init_one,
> .remove = de_remove_one,
> + .shutdown = de_shutdown,
> .driver.pm = _pm_ops,
> };
>
Re: [PATCH] seqlock: avoid -Wshadow warnings
On Mon, Oct 26, 2020 at 5:58 PM Peter Zijlstra wrote:
>
> On Mon, Oct 26, 2020 at 05:50:38PM +0100, Arnd Bergmann wrote:
>
> > - unsigned seq; \
> > + unsigned __seq; \
>
> > - unsigned seq = __read_seqcount_begin(s);\
> > + unsigned _seq = __read_seqcount_begin(s); \
>
> > - unsigned seq = __seqcount_sequence(s); \
> > + unsigned __seq = __seqcount_sequence(s);\
>
> Can we have a consistent number of leading '_' ?
Not really ;-)
The warning comes from raw_read_seqcount_begin() calling
__read_seqcount_begin() and both using the same variable
name. I could rename one of them and use double-underscores
for both, but I haven't come up with a good alternative name
that wouldn't make it less consistent in the process.
> Also, I suppose you're going to find the explicit shadow in
> ___wait_event(), that one's not going to be trivial to fix.
I have this patch in my tree at the moment but did not send that yet
because that caused a regression on powerpc:
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 57ccf26d3b96..5d00a6fb7154 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -265,7 +265,11 @@ extern void init_wait_entry(struct
wait_queue_entry *wq_entry, int flags);
({
\
__label__ __out;
\
struct wait_queue_entry __wq_entry;
\
- long __ret = ret; /* explicit shadow */
\
+ __diag_push()
\
+ __diag_ignore(GCC, 8, "-Wshadow", "explicit shadow")
\
+ __diag_ignore(CLANG, 9, "-Wshadow", "explicit shadow")
\
+ long __ret = ret;
\
+ __diag_pop();
\
\
init_wait_entry(&__wq_entry, exclusive ? WQ_FLAG_EXCLUSIVE :
0);\
for (;;) {
\
Still looking at alternative approaches.
Arnd
[PATCH 1/2] tools, bpftool: Avoid array index warnings.
The bpf_caps array is shorter without CAP_BPF, avoid out of bounds reads
if this isn't defined. Working around this avoids -Wno-array-bounds with
clang.
Signed-off-by: Ian Rogers
---
tools/bpf/bpftool/feature.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
index a43a6f10b564..359960a8f1de 100644
--- a/tools/bpf/bpftool/feature.c
+++ b/tools/bpf/bpftool/feature.c
@@ -843,9 +843,14 @@ static int handle_perms(void)
else
p_err("missing %s%s%s%s%s%s%s%srequired for full
feature probing; run as root or use 'unprivileged'",
capability_msg(bpf_caps, 0),
+#ifdef CAP_BPF
capability_msg(bpf_caps, 1),
capability_msg(bpf_caps, 2),
- capability_msg(bpf_caps, 3));
+ capability_msg(bpf_caps, 3)
+#else
+ "", "", "", "", "", ""
+#endif /* CAP_BPF */
+ );
goto exit_free;
}
--
2.29.0.rc2.309.g374f81d7ae-goog
[PATCH 2/2] tools, bpftool: Remove two unused variables.
Avoid an unused variable warning.
Signed-off-by: Ian Rogers
---
tools/bpf/bpftool/skeleton/profiler.bpf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/bpf/bpftool/skeleton/profiler.bpf.c
b/tools/bpf/bpftool/skeleton/profiler.bpf.c
index 4e3512f700c0..ce5b65e07ab1 100644
--- a/tools/bpf/bpftool/skeleton/profiler.bpf.c
+++ b/tools/bpf/bpftool/skeleton/profiler.bpf.c
@@ -70,7 +70,7 @@ int BPF_PROG(fentry_XXX)
static inline void
fexit_update_maps(u32 id, struct bpf_perf_event_value *after)
{
- struct bpf_perf_event_value *before, diff, *accum;
+ struct bpf_perf_event_value *before, diff;
before = bpf_map_lookup_elem(_readings, );
/* only account samples with a valid fentry_reading */
@@ -95,7 +95,7 @@ int BPF_PROG(fexit_XXX)
{
struct bpf_perf_event_value readings[MAX_NUM_MATRICS];
u32 cpu = bpf_get_smp_processor_id();
- u32 i, one = 1, zero = 0;
+ u32 i, zero = 0;
int err;
u64 *count;
--
2.29.0.rc2.309.g374f81d7ae-goog
Re: [PATCH] net: microchip: Remove unneeded variable ret
On Fri, 23 Oct 2020 09:21:07 + Xu Wang wrote: > Remove unneeded variable ret used to store return value. > > Signed-off-by: Xu Wang Applied.
Re: [PATCH] vxge: remove unnecessary cast in kfree()
On Fri, 23 Oct 2020 16:55:33 +0800 Xu Wang wrote: > Remove unnecessary cast in the argument to kfree. > > Signed-off-by: Xu Wang Applied.
[PATCH v5 1/1] mmap_lock: add tracepoints around lock acquisition
The goal of these tracepoints is to be able to debug lock contention
issues. This lock is acquired on most (all?) mmap / munmap / page fault
operations, so a multi-threaded process which does a lot of these can
experience significant contention.
We trace just before we start acquisition, when the acquisition returns
(whether it succeeded or not), and when the lock is released (or
downgraded). The events are broken out by lock type (read / write).
The events are also broken out by memcg path. For container-based
workloads, users often think of several processes in a memcg as a single
logical "task", so collecting statistics at this level is useful.
The end goal is to get latency information. This isn't directly included
in the trace events. Instead, users are expected to compute the time
between "start locking" and "acquire returned", using e.g. synthetic
events or BPF. The benefit we get from this is simpler code.
Because we use tracepoint_enabled() to decide whether or not to trace,
this patch has effectively no overhead unless tracepoints are enabled at
runtime. If tracepoints are enabled, there is a performance impact, but
how much depends on exactly what e.g. the BPF program does.
[ rost...@goodmis.org: in-depth examples of tracepoint_enabled() usage,
and per-cpu-per-context buffer design ]
Signed-off-by: Axel Rasmussen
---
include/linux/mmap_lock.h| 95 +++-
include/trace/events/mmap_lock.h | 107 ++
mm/Makefile | 2 +-
mm/mmap_lock.c | 187 +++
4 files changed, 385 insertions(+), 6 deletions(-)
create mode 100644 include/trace/events/mmap_lock.h
create mode 100644 mm/mmap_lock.c
diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
index e1afb420fc94..3d13f998477e 100644
--- a/include/linux/mmap_lock.h
+++ b/include/linux/mmap_lock.h
@@ -1,11 +1,65 @@
#ifndef _LINUX_MMAP_LOCK_H
#define _LINUX_MMAP_LOCK_H
+#include
+#include
#include
+#include
+#include
+#include
#define MMAP_LOCK_INITIALIZER(name) \
.mmap_lock = __RWSEM_INITIALIZER((name).mmap_lock),
+DECLARE_TRACEPOINT(mmap_lock_start_locking);
+DECLARE_TRACEPOINT(mmap_lock_acquire_returned);
+DECLARE_TRACEPOINT(mmap_lock_released);
+
+#ifdef CONFIG_TRACING
+
+void __mmap_lock_do_trace_start_locking(struct mm_struct *mm, bool write);
+void __mmap_lock_do_trace_acquire_returned(struct mm_struct *mm, bool write,
+ bool success);
+void __mmap_lock_do_trace_released(struct mm_struct *mm, bool write);
+
+static inline void __mmap_lock_trace_start_locking(struct mm_struct *mm,
+ bool write)
+{
+ if (tracepoint_enabled(mmap_lock_start_locking))
+ __mmap_lock_do_trace_start_locking(mm, write);
+}
+
+static inline void __mmap_lock_trace_acquire_returned(struct mm_struct *mm,
+ bool write, bool success)
+{
+ if (tracepoint_enabled(mmap_lock_acquire_returned))
+ __mmap_lock_do_trace_acquire_returned(mm, write, success);
+}
+
+static inline void __mmap_lock_trace_released(struct mm_struct *mm, bool write)
+{
+ if (tracepoint_enabled(mmap_lock_released))
+ __mmap_lock_do_trace_released(mm, write);
+}
+
+#else /* !CONFIG_TRACING */
+
+static inline void __mmap_lock_trace_start_locking(struct mm_struct *mm,
+ bool write)
+{
+}
+
+static inline void __mmap_lock_trace_acquire_returned(struct mm_struct *mm,
+ bool write, bool success)
+{
+}
+
+static inline void __mmap_lock_trace_released(struct mm_struct *mm, bool write)
+{
+}
+
+#endif /* CONFIG_TRACING */
+
static inline void mmap_init_lock(struct mm_struct *mm)
{
init_rwsem(>mmap_lock);
@@ -13,58 +67,88 @@ static inline void mmap_init_lock(struct mm_struct *mm)
static inline void mmap_write_lock(struct mm_struct *mm)
{
+ __mmap_lock_trace_start_locking(mm, true);
down_write(>mmap_lock);
+ __mmap_lock_trace_acquire_returned(mm, true, true);
}
static inline void mmap_write_lock_nested(struct mm_struct *mm, int subclass)
{
+ __mmap_lock_trace_start_locking(mm, true);
down_write_nested(>mmap_lock, subclass);
+ __mmap_lock_trace_acquire_returned(mm, true, true);
}
static inline int mmap_write_lock_killable(struct mm_struct *mm)
{
- return down_write_killable(>mmap_lock);
+ int ret;
+
+ __mmap_lock_trace_start_locking(mm, true);
+ ret = down_write_killable(>mmap_lock);
+ __mmap_lock_trace_acquire_returned(mm, true, ret == 0);
+ return ret;
}
static inline bool mmap_write_trylock(struct mm_struct *mm)
{
- return down_write_trylock(>mmap_lock) != 0;
+ bool ret;
+
+ __mmap_lock_trace_start_locking(mm, true);
+ ret =
[PATCH v5 0/1] mmap_lock: add tracepoints around lock acquisition
This patchset adds tracepoints around mmap_lock acquisition. This is useful so
we can measure the latency of lock acquisition, in order to detect contention.
This version is based upon linux-next (since it depends on some recently-merged
patches [1] [2]).
I removed the existing {Reviewed,Acked}-by: lines from v4, since I think the
patch has changed significantly enough to warrant another look (and I figure
it's better to err in this direction in any case :) ).
Changes since v4:
- Redesigned buffer allocation to deal with the fact that a trace event might be
interrupted by e.g. an IRQ, for which a per-cpu buffer is insufficient. Now we
allocate one buffer per CPU * one buffer per context we might be called in
(currently 4: normal, irq, softirq, NMI). We have three trace events which can
potentially all be enabled, and all of which need a buffer; to avoid further
multiplying the number of buffers by 3, they share the same set of buffers,
which requires a spinlock + counter setup so we only allocate the buffers
once, and then free them only when *all* of the trace events are _unreg()-ed.
Changes since v3:
- Switched EXPORT_SYMBOL to EXPORT_TRACEPOINT_SYMBOL, removed comment.
- Removed redundant trace_..._enabled() check.
- Defined the three TRACE_EVENTs separately, instead of sharing an event class.
The tradeoff is 524 more bytes in .text, but the start_locking and released
events no longer have a vestigial "success" field, so they're simpler +
faster.
Changes since v2:
- Refactored tracing helper functions so the helpers are simper, but the locking
functinos are slightly more verbose. Overall, this decreased the delta to
mmap_lock.h slightly.
- Fixed a typo in a comment. :)
Changes since v1:
- Functions renamed to reserve the "trace_" prefix for actual tracepoints.
- We no longer measure the duration directly. Instead, users are expected to
construct a synthetic event which computes the interval between "start
locking" and "acquire returned".
- The new helper for checking if tracepoints are enabled in a header is used to
avoid un-inlining any of the lock wrappers. This yields ~zero overhead if the
tracepoints aren't enabled, and therefore obviates the need for a Kconfig for
this change.
[1] https://lore.kernel.org/patchwork/patch/1316922/
[2] https://lore.kernel.org/patchwork/patch/1311996/
Axel Rasmussen (1):
mmap_lock: add tracepoints around lock acquisition
include/linux/mmap_lock.h| 95 +++-
include/trace/events/mmap_lock.h | 107 ++
mm/Makefile | 2 +-
mm/mmap_lock.c | 187 +++
4 files changed, 385 insertions(+), 6 deletions(-)
create mode 100644 include/trace/events/mmap_lock.h
create mode 100644 mm/mmap_lock.c
--
2.29.0.rc2.309.g374f81d7ae-goog
[PATCH] x86/mm/ident_map: Check for errors from ident_pud_init()
Commit
ea3b5e60ce80 ("x86/mm/ident_map: Add 5-level paging support")
added ident_p4d_init() to support 5-level paging, but this function
doesn't check and return errors from ident_pud_init().
For example, the decompressor stub uses this code to create an identity
mapping. If it runs out of pages while trying to allocate a PMD
pagetable, the error will be currently ignored.
Fix this to propagate errors.
Signed-off-by: Arvind Sankar
Fixes: ea3b5e60ce80 ("x86/mm/ident_map: Add 5-level paging support")
---
arch/x86/mm/ident_map.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/ident_map.c b/arch/x86/mm/ident_map.c
index fe7a12599d8e..5ecb0883cc88 100644
--- a/arch/x86/mm/ident_map.c
+++ b/arch/x86/mm/ident_map.c
@@ -62,6 +62,7 @@ static int ident_p4d_init(struct x86_mapping_info *info,
p4d_t *p4d_page,
unsigned long addr, unsigned long end)
{
unsigned long next;
+ int result;
for (; addr < end; addr = next) {
p4d_t *p4d = p4d_page + p4d_index(addr);
@@ -73,13 +74,17 @@ static int ident_p4d_init(struct x86_mapping_info *info,
p4d_t *p4d_page,
if (p4d_present(*p4d)) {
pud = pud_offset(p4d, 0);
- ident_pud_init(info, pud, addr, next);
+ result = ident_pud_init(info, pud, addr, next);
+ if (result)
+ return result;
continue;
}
pud = (pud_t *)info->alloc_pgt_page(info->context);
if (!pud)
return -ENOMEM;
- ident_pud_init(info, pud, addr, next);
+ result = ident_pud_init(info, pud, addr, next);
+ if (result)
+ return result;
set_p4d(p4d, __p4d(__pa(pud) | info->kernpg_flag));
}
--
2.26.2
Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
On 10/27/20 9:57 PM, Ard Biesheuvel wrote:
Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
___bpf_prog_run()") introduced a __no_fgcse macro that expands to a
function scope __attribute__((optimize("-fno-gcse"))), to disable a
GCC specific optimization that was causing trouble on x86 builds, and
was not expected to have any positive effect in the first place.
However, as the GCC manual documents, __attribute__((optimize))
is not for production use, and results in all other optimization
options to be forgotten for the function in question. This can
cause all kinds of trouble, but in one particular reported case,
Looks like there are couple more as well aside from __no_fgcse, are you
also planning to fix them?
arch/powerpc/kernel/setup.h:14:#define __nostackprotector
__attribute__((__optimize__("no-stack-protector")))
tools/include/linux/compiler-gcc.h:37:#define __no_tail_call
__attribute__((optimize("no-optimize-sibling-calls")))
it causes -fno-asynchronous-unwind-tables to be disregarded,
resulting in .eh_frame info to be emitted for the function
inadvertently.
Would have been useful to add a pointer to the original discussion with
Link tag.
Link:
https://lore.kernel.org/lkml/CAMuHMdUg0WJHEcq6to0-eODpXPOywLot6UD2=gfhpzoj_hc...@mail.gmail.com/
This reverts commit 3193c0836f203, and instead, it disables the -fgcse
optimization for the entire source file, but only when building for
X86.
Cc: Nick Desaulniers
Cc: Arvind Sankar
Cc: Randy Dunlap
Cc: Josh Poimboeuf
Cc: Thomas Gleixner
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Peter Zijlstra (Intel)
Cc: Geert Uytterhoeven
Cc: Kees Cook
Fixes: 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
___bpf_prog_run()")
Signed-off-by: Ard Biesheuvel
[...]
diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
index bdc8cd1b6767..02b58f44c479 100644
--- a/kernel/bpf/Makefile
+++ b/kernel/bpf/Makefile
@@ -1,6 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
obj-y := core.o
-CFLAGS_core.o += $(call cc-disable-warning, override-init)
+# ___bpf_prog_run() needs GCSE disabled on x86; see 3193c0836f203 for details
+cflags-core-$(CONFIG_X86) := -fno-gcse
+CFLAGS_core.o += $(call cc-disable-warning, override-init) $(cflags-core-y)
Also, this needs to be guarded behind !CONFIG_RETPOLINE and
!CONFIG_BPF_JIT_ALWAYS_ON
in particular the latter since only in this case interpreter is compiled in ...
most
distros have the CONFIG_BPF_JIT_ALWAYS_ON set these days for x86.
Do you have an analysis for the commit log on what else this penalizes in
core.c if
it's now for the entire translation unit?
obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o
bpf_iter.o map_iter.o task_iter.o prog_iter.o
obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o
bpf_lru_list.o lpm_trie.o map_in_map.o
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 9268d77898b7..55454d2278b1 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1369,7 +1369,7 @@ u64 __weak bpf_probe_read_kernel(void *dst, u32 size,
const void *unsafe_ptr)
*
* Decode and execute eBPF instructions.
*/
-static u64 __no_fgcse ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn,
u64 *stack)
+static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack)
{
#define BPF_INSN_2_LBL(x, y)[BPF_##x | BPF_##y] = &##_##y
#define BPF_INSN_3_LBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] =
&##_##y##_##z
drivers/spi/spi-rspi.c:1128:29: warning: unused variable 'rspi_rz_ops'
Hi Geert,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4d09c1d952679411da2772f199643e08c46c31cd
commit: 851c902fd2d09b2ed85181e74b43477b7a3882be spi: rspi: Remove obsolete
platform_device_id entries
date: 11 months ago
config: x86_64-randconfig-a003-20201028 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
f2c25c70791de95d2466e09b5b58fc37f6ccd7a4)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=851c902fd2d09b2ed85181e74b43477b7a3882be
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 851c902fd2d09b2ed85181e74b43477b7a3882be
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/spi/spi-rspi.c:1128:29: warning: unused variable 'rspi_rz_ops'
>> [-Wunused-const-variable]
static const struct spi_ops rspi_rz_ops = {
^
>> drivers/spi/spi-rspi.c:1136:29: warning: unused variable 'qspi_ops'
>> [-Wunused-const-variable]
static const struct spi_ops qspi_ops = {
^
2 warnings generated.
vim +/rspi_rz_ops +1128 drivers/spi/spi-rspi.c
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 1127
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 @1128 static const struct
spi_ops rspi_rz_ops = {
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 1129 .set_config_register =
rspi_rz_set_config_register,
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 1130 .transfer_one =
rspi_rz_transfer_one,
880c6d114fd79a6 Geert Uytterhoeven 2014-01-30 1131 .mode_bits =
SPI_CPHA | SPI_CPOL | SPI_LOOP,
9428a073eb703de Geert Uytterhoeven 2019-02-08 1132 .flags =
SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX,
2f777ec91aa0623 Geert Uytterhoeven 2014-06-02 1133 .fifo_size =
8, /* 8 for TX, 32 for RX */
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 1134 };
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 1135
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 @1136 static const struct
spi_ops qspi_ops = {
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 1137 .set_config_register =
qspi_set_config_register,
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 1138 .transfer_one =
qspi_transfer_one,
880c6d114fd79a6 Geert Uytterhoeven 2014-01-30 1139 .mode_bits =
SPI_CPHA | SPI_CPOL | SPI_LOOP |
880c6d114fd79a6 Geert Uytterhoeven 2014-01-30 1140
SPI_TX_DUAL | SPI_TX_QUAD |
880c6d114fd79a6 Geert Uytterhoeven 2014-01-30 1141
SPI_RX_DUAL | SPI_RX_QUAD,
9428a073eb703de Geert Uytterhoeven 2019-02-08 1142 .flags =
SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX,
2f777ec91aa0623 Geert Uytterhoeven 2014-06-02 1143 .fifo_size =
32,
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 1144 };
426ef76dd8a394a Geert Uytterhoeven 2014-01-28 1145
:: The code at line 1128 was first introduced by commit
:: 426ef76dd8a394a0e04d096941cd9acb49539a3e spi: rspi: Add DT support
:: TO: Geert Uytterhoeven
:: CC: Mark Brown
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [MPTCP] Re: [selftests] f2ff7f11f9: WARNING:suspicious_RCU_usage
On Tue, Oct 27, 2020 at 04:07:28PM +0100, Matthieu Baerts wrote:
> Hi all,
>
> On 27/10/2020 14:16, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: f2ff7f11f9a74842245db52d685bf9bc7ac2c4b1 ("selftests: mptcp: add
> > ADD_ADDR IPv6 test cases")
> > https://github.com/multipath-tcp/mptcp_net-next.git export
>
> Thanks for the maintainer of the kernel test robot at Intel for this bug
> report!
thanks, you are welcome!
>
> FYI, this was already reported earlier:
>
> https://github.com/multipath-tcp/mptcp_net-next/issues/102
Thanks for the info, we didn't notice this. We will take a look
of reported issues in future to avoid duplicated report.
>
> And Geliang is working on a fix (a v2 is available).
>
> Cheers,
> Matt
> --
> Tessares | Belgium | Hybrid Access Solutions
> www.tessares.net
> ___
> mptcp mailing list -- mp...@lists.01.org
> To unsubscribe send an email to mptcp-le...@lists.01.org
Re: [PATCH v3 2/2] i2c: i2c-mux-gpio: Enable this driver in ACPI land
On Mon, Oct 19, 2020 at 9:53 AM Evan Green wrote: > > On Sun, Oct 18, 2020 at 11:58 AM Andy Shevchenko > wrote: > > > > On Sat, Oct 17, 2020 at 8:30 AM Evan Green wrote: > > > > > > Enable i2c-mux-gpio devices to be defined via ACPI. The idle-state > > > property translates directly to a fwnode_property_*() call. The child > > > reg property translates naturally into _ADR in ACPI. > > > > > > The i2c-parent binding is a relic from the days when the bindings > > > dictated that all direct children of an I2C controller had to be I2C > > > devices. These days that's no longer required. The i2c-mux can sit as a > > > direct child of its parent controller, which is where it makes the most > > > sense from a hardware description perspective. For the ACPI > > > implementation we'll assume that's always how the i2c-mux-gpio is > > > instantiated. > > > > Can you tell me if the following is relevant to what you are looking for? > > https://elixir.bootlin.com/linux/latest/source/drivers/i2c/i2c-mux.c#L393 > > I don't think so, but let me know if I'm reading between the lines > incorrectly. > > The code you pointed to links the newly-minted fake i2c controller > back together with its ACPI node. This is important, since I think > that's how child I2C devices underneath the fake busses get populated > in ACPI land. But the paragraph above is discussing how to identify > the parent adapter (ie the real hardware) for an i2c-mux-gpio device. > > In DT-land, the i2c-mux-gpio floats at the top of the tree directly > under /, and then uses a phandle to point to where transactions should > be forwarded. I'm told the reason for this is historical limitations > with the DT bindings. Rather than trying to translate the phandle over > 1:1 into ACPI-land, I'm asserting that the mux device should live > underneath the adapter it wants to forward traffic to. Andy or Peter, Any other thoughts on this series? -Evan
Re: [PATCH] bus: mhi: core: Add support MHI EE FP for download firmware
Hi Jeff,
On 10/27/20 8:11 AM, Jeffrey Hugo wrote:
On 10/27/2020 3:43 AM, carl@quectel.com wrote:
From: "carl.yin"
MHI wwan modems support download firmware to nand or emmc
by firehose protocol, process as next:
1. wwan modem normal bootup and enter EE AMSS, create mhi DIAG chan
device
2. send EDL cmd via DIAG chan, then modem enter EE EDL
3. boot.c download 'firehose/prog_firehose_sdx55.mbn' via BHI interface
4. modem enter EE FP, and create mhi EDL chan device
5. user space tool download FW to modem via EDL chan by firehose protocol
Signed-off-by: carl.yin
---
drivers/bus/mhi/core/boot.c | 4 +++-
drivers/bus/mhi/core/init.c | 2 ++
drivers/bus/mhi/core/internal.h | 1 +
drivers/bus/mhi/core/main.c | 3 +++
drivers/bus/mhi/core/pm.c | 16 +++-
include/linux/mhi.h | 4 +++-
6 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index 24422f5..ab39ad6 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -460,8 +460,10 @@ void mhi_fw_load_handler(struct mhi_controller
*mhi_cntrl)
return;
}
- if (mhi_cntrl->ee == MHI_EE_EDL)
+ if (mhi_cntrl->ee == MHI_EE_EDL) {
+ mhi_ready_state_transition(mhi_cntrl);
return;
+ }
write_lock_irq(_cntrl->pm_lock);
mhi_cntrl->dev_state = MHI_STATE_RESET;
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index ac4aa5c..9c2c2f3 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -26,6 +26,7 @@ const char * const mhi_ee_str[MHI_EE_MAX] = {
[MHI_EE_WFW] = "WFW",
[MHI_EE_PTHRU] = "PASS THRU",
[MHI_EE_EDL] = "EDL",
+ [MHI_EE_FP] = "FP",
[MHI_EE_DISABLE_TRANSITION] = "DISABLE",
[MHI_EE_NOT_SUPPORTED] = "NOT SUPPORTED",
};
@@ -35,6 +36,7 @@ const char * const
dev_state_tran_str[DEV_ST_TRANSITION_MAX] = {
[DEV_ST_TRANSITION_READY] = "READY",
[DEV_ST_TRANSITION_SBL] = "SBL",
[DEV_ST_TRANSITION_MISSION_MODE] = "MISSION_MODE",
+ [DEV_ST_TRANSITION_FP] = "FP",
[DEV_ST_TRANSITION_SYS_ERR] = "SYS_ERR",
[DEV_ST_TRANSITION_DISABLE] = "DISABLE",
};
diff --git a/drivers/bus/mhi/core/internal.h
b/drivers/bus/mhi/core/internal.h
index 4abf0cf..6ae897a 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -386,6 +386,7 @@ enum dev_st_transition {
DEV_ST_TRANSITION_READY,
DEV_ST_TRANSITION_SBL,
DEV_ST_TRANSITION_MISSION_MODE,
+ DEV_ST_TRANSITION_FP,
DEV_ST_TRANSITION_SYS_ERR,
DEV_ST_TRANSITION_DISABLE,
DEV_ST_TRANSITION_MAX,
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 3950792..e307b58 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -782,6 +782,9 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller
*mhi_cntrl,
case MHI_EE_SBL:
st = DEV_ST_TRANSITION_SBL;
break;
+ case MHI_EE_FP:
+ st = DEV_ST_TRANSITION_FP;
+ break;
case MHI_EE_WFW:
case MHI_EE_AMSS:
st = DEV_ST_TRANSITION_MISSION_MODE;
diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
index 3de7b16..3c95a5d 100644
--- a/drivers/bus/mhi/core/pm.c
+++ b/drivers/bus/mhi/core/pm.c
@@ -563,7 +563,15 @@ static void mhi_pm_disable_transition(struct
mhi_controller *mhi_cntrl,
}
if (cur_state == MHI_PM_SYS_ERR_PROCESS) {
- mhi_ready_state_transition(mhi_cntrl);
+ if (mhi_get_exec_env(mhi_cntrl) == MHI_EE_EDL
+ && mhi_get_mhi_state(mhi_cntrl) == MHI_STATE_RESET) {
+ write_lock_irq(_cntrl->pm_lock);
+ cur_state = mhi_tryset_pm_state(mhi_cntrl, MHI_PM_POR);
+ write_unlock_irq(_cntrl->pm_lock);
+ mhi_queue_state_transition(mhi_cntrl,
DEV_ST_TRANSITION_PBL);
+ } else {
+ mhi_ready_state_transition(mhi_cntrl);
+ }
} else {
/* Move to disable state */
write_lock_irq(_cntrl->pm_lock);
@@ -658,6 +666,12 @@ void mhi_pm_st_worker(struct work_struct *work)
case DEV_ST_TRANSITION_MISSION_MODE:
mhi_pm_mission_mode_transition(mhi_cntrl);
break;
+ case DEV_ST_TRANSITION_FP:
+ write_lock_irq(_cntrl->pm_lock);
+ mhi_cntrl->ee = MHI_EE_FP;
+ write_unlock_irq(_cntrl->pm_lock);
+ mhi_create_devices(mhi_cntrl);
+ break;
case DEV_ST_TRANSITION_READY:
mhi_ready_state_transition(mhi_cntrl);
break;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index 6e1122c..4620af8 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -120,6 +120,7 @@ struct mhi_link_info {
* @MHI_EE_WFW: WLAN firmware mode
* @MHI_EE_PTHRU: Passthrough
* @MHI_EE_EDL: Embedded downloader
+ * @MHI_EE_FP,
Re: [PATCH v2] ctype.h: remove duplicate isdigit() helper
On Tue, Oct 27, 2020 at 11:37 PM Arnd Bergmann wrote: > > Sounds good, I'll take that. Are the clang and icc version numbers > the actual ones we should list here, or is this just an example? Actual ones -- well, the best approximation I could get from the available versions in Compiler Explorer :-) Cheers, Miguel
Re: [PATCH] arm64: NUMA: Kconfig: Increase max number of nodes
On 10/22/20 11:25 AM, Vanshi Konda wrote: > On Thu, Oct 22, 2020 at 12:21:27PM +0100, Robin Murphy wrote: >> On 2020-10-22 02:07, Vanshi Konda wrote: >>> On Thu, Oct 22, 2020 at 12:44:15AM +0100, Robin Murphy wrote: On 2020-10-21 12:02, Jonathan Cameron wrote: > On Wed, 21 Oct 2020 09:43:21 +0530 > Anshuman Khandual wrote: > >> On 10/20/2020 11:39 PM, Valentin Schneider wrote: >>> >>> Hi, >>> >>> Nit on the subject: this only increases the default, the max is >>> still 2?. >> >> Agreed. >> >>> >>> On 20/10/20 18:34, Vanshidhar Konda wrote: The current arm64 max NUMA nodes default to 4. Today's arm64 systems can reach or exceed 16. Increase the number to 64 (matching x86_64). Signed-off-by: Vanshidhar Konda --- ??arch/arm64/Kconfig | 2 +- ??1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 893130ce1626..3e69d3c981be 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -980,7 +980,7 @@ config NUMA ??config NODES_SHIFT ?? int "Maximum NUMA Nodes (as a power of 2)" ?? range 1 10 -?? default "2" +?? default "6" >>> >>> This leads to more statically allocated memory for things like >>> node to CPU >>> maps (see uses of MAX_NUMNODES), but that shouldn't be too much >>> of an >>> issue. >> >> The smaller systems should not be required to waste those memory in >> a default case, unless there is a real and available larger system >> with those increased nodes. >> >>> >>> AIUI this also directly correlates to how many more page->flags >>> bits are >>> required: are we sure the max 10 works on any aarch64 platform? I'm >> >> We will have to test that. Besides 256 (2 ^ 8) is the first threshold >> to be crossed here. >> >>> genuinely asking here, given that I'm mostly a stranger to the mm >>> world. The default should be something we're somewhat confident >>> works >>> everywhere. >> >> Agreed. Do we really need to match X86 right now ? Do we really have >> systems that has 64 nodes ? We should not increase the default node >> value and then try to solve some new problems, when there might not >> be any system which could even use that. I would suggest increase >> NODES_SHIFT value upto as required by a real and available system. > > I'm not going to give precise numbers on near future systems but it > is public > that we ship 8 NUMA node ARM64 systems today.?? Things will get more > interesting as CXL and CCIX enter the market on ARM systems, > given chances are every CXL device will look like another NUMA > node (CXL spec says they should be presented as such) and you > may be able to rack up lots of them. > > So I'd argue minimum that makes sense today is 16 nodes, but > looking forward > even a little and 64 is not a great stretch. > I'd make the jump to 64 so we can forget about this again for a > year or two. > People will want to run today's distros on these new machines and we'd > rather not have to go around all the distros asking them to carry a > patch > increasing this count (I assume they are already carrying such a patch > due to those 8 node systems) >>> >>> To echo Jonathan's statement above we are looking at systems that will >>> need approximately 64 NUMA nodes over the next 5-6 years - the time for >>> which an LTS kernel would be maintained. Some of the reason's for >>> increasing NUMA nodes during this time period include CXL, CCIX and >>> NVDIMM (like Jonathan pointed out). This is a very good point. It won't be long until systems will be pushing the number of NUMA nodes and increasing NODES_SHIFT only slightly now will result in the default configuration not recognizing all the nodes. CONFIG_NODES_SHIFT=6 seems a reasonable step up for a generic kernel that should run well on small to very large systems for a few years to come. >>> The main argument against increasing the NODES_SHIFT seems to be a >>> concern that it negatively impacts other ARM64 systems. Could anyone >>> share what kind of systems we are talking about? For a system that has >>> NEED_MULTIPLE_NODES set, would the impact be noticeable? >> >> Systems like the ESPRESSObin - sure, sane people aren't trying to run >> desktops or development environments in 1GB of RAM, but it's not >> uncommon for them to use a minimal headless install of their favourite >> generic arm64 distro rather than something more "embedded" like > > If someone is running a generic arm64 distro, at least some of them are > already paying the extra cost. NODES_SHIFT for Ubuntu and SuSE kernels > is already 6. CentOS/Redhat and Oracle Linux set
Re: [PATCH 1/3] KVM: x86/mmu: Add helper macro for computing hugepage GFN mask
On Tue, Oct 27, 2020 at 03:17:40PM -0700, Ben Gardon wrote:
> On Tue, Oct 27, 2020 at 2:43 PM Sean Christopherson
> wrote:
> >
> > Add a helper to compute the GFN mask given a hugepage level, KVM is
> > accumulating quite a few users with the addition of the TDP MMU.
> >
> > Note, gcc is clever enough to use a single NEG instruction instead of
> > SUB+NOT, i.e. use the more common "~(level -1)" pattern instead of
> > round_gfn_for_level()'s direct two's complement trickery.
>
> As far as I can tell this patch has no functional changes intended.
> Please correct me if that's not correct.
Correct. :-)
> >
> > Signed-off-by: Sean Christopherson
>
> Reviewed-by: Ben Gardon
>
> > ---
> > arch/x86/include/asm/kvm_host.h | 1 +
> > arch/x86/kvm/mmu/mmu.c | 2 +-
> > arch/x86/kvm/mmu/paging_tmpl.h | 4 ++--
> > arch/x86/kvm/mmu/tdp_iter.c | 2 +-
> > 4 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_host.h
> > index d44858b69353..6ea046415f29 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -119,6 +119,7 @@
> > #define KVM_HPAGE_SIZE(x) (1UL << KVM_HPAGE_SHIFT(x))
> > #define KVM_HPAGE_MASK(x) (~(KVM_HPAGE_SIZE(x) - 1))
> > #define KVM_PAGES_PER_HPAGE(x) (KVM_HPAGE_SIZE(x) / PAGE_SIZE)
> > +#define KVM_HPAGE_GFN_MASK(x) (~(KVM_PAGES_PER_HPAGE(x) - 1))
>
> NIT: I know x follows the convention on adjacent macros, but this
> would be clearer to me if x was changed to level. (Probably for all
> the macros in this block)
Agreed. I'll spin a v2 and opportunistically change them all to "level"
in this patch. I'll also add "No function change intended™." to patches
1 and 3.
> > static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t base_gfn, int level)
> > {
Re: [PATCH V2 1/2] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER
Trying again through different e-mail provider. My previous e-mail got stuck in spam filters. Apologies if this is received multiple times. On Mon, Aug 24, 2020 at 02:39:32PM +0530, Viresh Kumar wrote: > From: Stephan Gerhold > [ ... ] > > opp_table = dev_pm_opp_get_opp_table(dev); > - if (!opp_table) > - return ERR_PTR(-ENOMEM); > + if (!IS_ERR(opp_table)) > + return opp_table; This should have been if (IS_ERR(opp_table)) return opp_table; Guenter
[PATCH -next] checkpatch: Update __attribute__((section("name"))) quote removal
commit 33def8498fdd ("treewide: Convert macro and uses of
__section(foo) to __section("foo")") removed the stringification of the
section name and now requires quotes around the named section.
Update checkpatch to not remove any quotes when suggesting conversion
of __attribute__((section("name"))) to __section("name")
Miscellanea:
o Add section to the hash with __section replacement
o Remove separate test for __attribute__((section
o Remove the limitation on converting attributes containing only
known, possible conversions. Any unknown attribute types are now
left as-is and known types are converted and moved before
__attribute__ and removed from within the __attribute__((list...)).
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 46 --
1 file changed, 16 insertions(+), 30 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7800a090e8fe..a97f2ab11568 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6216,51 +6216,37 @@ sub process {
"noreturn" => "__noreturn",
"packed"=> "__packed",
"pure" => "__pure",
+ "section" => "__section",
"used" => "__used"
);
- my @conv_array = ();
- my $conv_possible = 1;
-
while ($attr =~ /\s*(\w+)\s*(${balanced_parens})?/g) {
- my $curr_attr = $1;
+ my $orig_attr = $1;
my $params = '';
$params = $2 if defined($2);
+ my $curr_attr = $orig_attr;
$curr_attr =~ s/^[\s_]+|[\s_]+$//g;
-
if (exists($attr_list{$curr_attr})) {
+ my $new = $attr_list{$curr_attr};
if ($curr_attr eq "format" && $params) {
$params =~
/^\s*\(\s*(\w+)\s*,\s*(.*)/;
- push(@conv_array, "__$1\($2");
+ $new = "__$1\($2";
} else {
- my $new =
$attr_list{$curr_attr};
- push(@conv_array,
"$new$params");
+ $new = "$new$params";
+ }
+ if
(WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
+"Prefer $new over
__attribute__(($orig_attr$params))\n" . $herecurr) &&
+ $fix) {
+ my $remove = "\Q$orig_attr\E" .
'\s*' . "\Q$params\E" . '(?:\s*,\s*)?';
+ $fixed[$fixlinenr] =~
s/$remove//;
+ $fixed[$fixlinenr] =~
s/\b__attribute__/$new __attribute__/;
+ $fixed[$fixlinenr] =~
s/\}\Q$new\E/} $new/;
}
- } else {
- $conv_possible = 0;
- last;
- }
- }
-
- if (scalar @conv_array > 0 && $conv_possible == 1) {
- my $replace = join(' ', @conv_array);
- if (WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
-"$replace is preferred over
__attribute__(($attr))\n" . $herecurr) &&
- $fix) {
- $fixed[$fixlinenr] =~
s/\b__attribute__\s*\(\s*\(\s*\Q$attr\E\s*\)\s*\)/$replace/;
- $fixed[$fixlinenr] =~
s/\}\Q$replace\E/} $replace/;
}
}
- # Check for __attribute__ section, prefer __section
- if ($attr =~ /^_*section_*\s*\(\s*("[^"]*")/) {
- my $old = substr($attr, $-[1], $+[1] - $-[1]);
- my $new = substr($old, 1, -1);
- if (WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
-"__section($new) is preferred over
__attribute__((section($old)))\n" . $herecurr) &&
- $fix) {
- $fixed[$fixlinenr] =~
Re: [PATCH 2/4] PM: hibernate: improve robustness of mapping pages in the direct map
On Tue, 2020-10-27 at 10:49 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 06:57:32PM +, Edgecombe, Rick P wrote:
> > On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> > > On Mon, Oct 26, 2020 at 12:38:32AM +, Edgecombe, Rick P
> > > wrote:
> > > > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > > > > From: Mike Rapoport
> > > > >
> > > > > When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a
> > > > > page
> > > > > may
> > > > > be
> > > > > not present in the direct map and has to be explicitly mapped
> > > > > before
> > > > > it
> > > > > could be copied.
> > > > >
> > > > > On arm64 it is possible that a page would be removed from the
> > > > > direct
> > > > > map
> > > > > using set_direct_map_invalid_noflush() but
> > > > > __kernel_map_pages()
> > > > > will
> > > > > refuse
> > > > > to map this page back if DEBUG_PAGEALLOC is disabled.
> > > >
> > > > It looks to me that arm64 __kernel_map_pages() will still
> > > > attempt
> > > > to
> > > > map it if rodata_full is true, how does this happen?
> > >
> > > Unless I misread the code, arm64 requires both rodata_full and
> > > debug_pagealloc_enabled() to be true for __kernel_map_pages() to
> > > do
> > > anything.
> > > But rodata_full condition applies to set_direct_map_*_noflush()
> > > as
> > > well,
> > > so with !rodata_full the linear map won't be ever changed.
> >
> > Hmm, looks to me that __kernel_map_pages() will only skip it if
> > both
> > debug pagealloc and rodata_full are false.
> >
> > But now I'm wondering if maybe we could simplify things by just
> > moving
> > the hibernate unmapped page logic off of the direct map. On x86,
> > text_poke() used to use this reserved fixmap pte thing that it
> > could
> > rely on to remap memory with. If hibernate had some separate pte
> > for
> > remapping like that, then we could not have any direct map
> > restrictions
> > caused by it/kernel_map_pages(), and it wouldn't have to worry
> > about
> > relying on anything else.
>
> Well, there is map_kernel_range() that can be used by hibernation as
> there is no requirement for particular virtual address, but that
> would
> be quite costly if done for every page.
>
> Maybe we can do somthing like
>
> if (kernel_page_present(s_page)) {
> do_copy_page(dst, page_address(s_page));
> } else {
> map_kernel_range_noflush(page_address(page), PAGE_SIZE,
>PROT_READ, );
> do_copy_page(dst, page_address(s_page));
> unmap_kernel_range_noflush(page_address(page),
> PAGE_SIZE);
> }
>
> But it seems that a prerequisite for changing the way a page is
> mapped
> in safe_copy_page() would be to teach hibernation that a mapping here
> may fail.
>
Yea that is what I meant, the direct map could still be used for mapped
pages.
But for the unmapped case it could have a pre-setup 4k pte for some non
direct map address. Then just change the pte to point to any unmapped
direct map page that was encountered. The point would be to give
hibernate some 4k pte of its own to manipulate so that it can't fail.
Yet another option would be have hibernate_map_page() just map large
pages if it finds them.
So we could teach hibernate to handle mapping failures, OR we could
change it so it doesn't rely on direct map page sizes in order to
succeed. The latter seems better to me since there isn't a reason why
it should have to fail and the resulting logic might be simpler. Both
seem like improvements in robustness though.
Re: [PATCH] bus: mhi: core: Introduce sysfs ul chan id for mhi chan device
Hi Carl,
On 10/27/20 8:06 AM, Jeffrey Hugo wrote:
On 10/27/2020 3:43 AM, carl@quectel.com wrote:
From: "carl.yin"
User space software like ModemManager can identify the function
of the mhi chan device by ul_chan_id.
Signed-off-by: carl.yin
---
Documentation/ABI/stable/sysfs-bus-mhi | 10 ++
drivers/bus/mhi/core/init.c | 15 +++
2 files changed, 25 insertions(+)
diff --git a/Documentation/ABI/stable/sysfs-bus-mhi
b/Documentation/ABI/stable/sysfs-bus-mhi
index ecfe766..6d52768 100644
--- a/Documentation/ABI/stable/sysfs-bus-mhi
+++ b/Documentation/ABI/stable/sysfs-bus-mhi
@@ -19,3 +19,13 @@ Description: The file holds the OEM PK Hash
value of the endpoint device
read without having the device power on at least once, the file
will read all 0's.
Users: Any userspace application or clients interested in
device info.
+
+What: /sys/bus/mhi/devices/.../ul_chan_id
+Date: November 2020
+KernelVersion: 5.10
+Contact: Carl Yin
+Description: The file holds the uplink chan id of the mhi chan
device.
+ User space software like ModemManager can identify the
function of
+ the mhi chan device. If the mhi device is not a chan device,
+ eg mhi controller device, the file read -1.
+Users: Any userspace application or clients interested in
device info.
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index c6b43e9..ac4aa5c 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -105,9 +105,24 @@ static ssize_t oem_pk_hash_show(struct device *dev,
}
static DEVICE_ATTR_RO(oem_pk_hash);
+static ssize_t ul_chan_id_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct mhi_device *mhi_dev = to_mhi_device(dev);
+ int ul_chan_id = -1;
+
+ if (mhi_dev->ul_chan)
+ ul_chan_id = mhi_dev->ul_chan_id;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", ul_chan_id);
+}
+static DEVICE_ATTR_RO(ul_chan_id);
+
static struct attribute *mhi_dev_attrs[] = {
_attr_serial_number.attr,
_attr_oem_pk_hash.attr,
+ _attr_ul_chan_id.attr,
NULL,
};
ATTRIBUTE_GROUPS(mhi_dev);
NACK
Channel ID is a device specific detail. Userspace should be basing
decisions on the channel name.
I agree with Jeff, why do you need to know the channel id, if you need
to poll for any device node to get created you can try to open the
device node from user space and wait until the device gets opened.
Are you trying to wait for EDL channels to get started using UCI ?
Thanks,
Hemant
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 1/2] sched/wait: Add add_wait_queue_priority()
On Tue, 2020-10-27 at 21:30 +0100, Peter Zijlstra wrote: > On Tue, Oct 27, 2020 at 07:27:59PM +, David Woodhouse wrote: > > > > While looking at this I found that weird __add_wait_queue_exclusive() > > > which is used by fs/eventpoll.c and does something similar, except it > > > doesn't keep the FIFO order. > > > > It does, doesn't it? Except those so-called "exclusive" entries end up > > in FIFO order amongst themselves at the *tail* of the queue, to be > > woken up only after all the other entries before them *haven't* been > > excluded. > > __add_wait_queue_exclusive() uses __add_wait_queue() which does > list_add(). It does _not_ add at the tail like normal exclusive users, > and there is exactly _1_ user in tree that does this. > > I'm not exactly sure how this happened, but: > > add_wait_queue_exclusive() > > and > > __add_wait_queue_exclusive() > > are not related :-( I think that goes all the way back to here: https://lkml.org/lkml/2007/5/4/530 It was rounded up in commit d47de16c72and subsequently "cleaned up" into an inline in wait.h, but I don't think there was ever a reason for it to be added to the head of the list instead of the tail. So I think we can reasonably make __add_wait_queue_exclusive() do precisely the same thing as add_wait_queue_exclusive() does (modulo locking). And then potentially rename them both to something that isn't quite such a lie. And give me the one I want that *does* actually exclude other waiters :) smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
On Tue, Oct 27, 2020 at 3:23 PM Ard Biesheuvel wrote:
>
> On Tue, 27 Oct 2020 at 23:03, Nick Desaulniers
> wrote:
> >
> > On Tue, Oct 27, 2020 at 2:50 PM Ard Biesheuvel wrote:
> > >
> > > On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers
> > > wrote:
> > > >
> > > > On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote:
> > > > >
> > > > > diff --git a/include/linux/compiler_types.h
> > > > > b/include/linux/compiler_types.h
> > > > > index 6e390d58a9f8..ac3fa37a84f9 100644
> > > > > --- a/include/linux/compiler_types.h
> > > > > +++ b/include/linux/compiler_types.h
> > > > > @@ -247,10 +247,6 @@ struct ftrace_likely_data {
> > > > > #define asm_inline asm
> > > > > #endif
> > > > >
> > > > > -#ifndef __no_fgcse
> > > > > -# define __no_fgcse
> > > > > -#endif
> > > > > -
> > > > Finally, this is going to disable GCSE for the whole translation unit,
> > > > which may be overkill. Previously it was isolated to one function
> > > > definition. You could lower the definition of the preprocessor define
> > > > into kernel/bpf/core.c to keep its use isolated as far as possible.
> > > >
> > >
> > > Which preprocessor define?
> >
> > __no_fgcse
> >
>
> But we can't use that, that is the whole point of this patch.
Ah, right because the attribute drops other command line flags...ok,
then -fno-gcse the whole translation unit it is then.
Still need to avoid new warnings with clang though.
--
Thanks,
~Nick Desaulniers
Re: [PATCH v2] ctype.h: remove duplicate isdigit() helper
On Tue, Oct 27, 2020 at 10:47 AM Miguel Ojeda wrote: > > On Tue, Oct 27, 2020 at 12:57 AM Arnd Bergmann wrote: > > > > +#ifdef __has_builtin > > +#define has_builtin(x) __has_builtin(x) > > +#else > > +#define has_builtin(x) (0) > > +#endif > > Could this be > > #ifndef __has_builtin > # define __has_builtin(x) 0 > #endif > > ? i.e. mimicking what we do for `__has_attribute`. Ah, I didn't know about that > It would also be a nice idea to put a reminder comment like: > > /* > * __has_builtin is supported on gcc >= 10, clang >= 3 and icc >= 21. > * In the meantime, to support gcc < 10, we implement __has_builtin > * by hand. > */ Sounds good, I'll take that. Are the clang and icc version numbers the actual ones we should list here, or is this just an example? Arnd
[PATCH v18 3/4] dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU
Every Qcom Adreno GPU has an embedded SMMU for its own use. These devices depend on unique features such as split pagetables, different stall/halt requirements and other settings. Identify them with a compatible string so that they can be identified in the arm-smmu implementation specific code. Signed-off-by: Jordan Crouse Reviewed-by: Rob Herring Signed-off-by: Rob Clark Reviewed-by: Bjorn Andersson --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 503160a7b9a0..3b63f2ae24db 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -28,8 +28,6 @@ properties: - enum: - qcom,msm8996-smmu-v2 - qcom,msm8998-smmu-v2 - - qcom,sc7180-smmu-v2 - - qcom,sdm845-smmu-v2 - const: qcom,smmu-v2 - description: Qcom SoCs implementing "arm,mmu-500" @@ -40,6 +38,13 @@ properties: - qcom,sm8150-smmu-500 - qcom,sm8250-smmu-500 - const: arm,mmu-500 + - description: Qcom Adreno GPUs implementing "arm,smmu-v2" +items: + - enum: + - qcom,sc7180-smmu-v2 + - qcom,sdm845-smmu-v2 + - const: qcom,adreno-smmu + - const: qcom,smmu-v2 - description: Marvell SoCs implementing "arm,mmu-500" items: - const: marvell,ap806-smmu-500 -- 2.25.1
[PATCH v18 2/4] iommu/arm-smmu: Add a way for implementations to influence SCTLR
From: Rob Clark
For the Adreno GPU's SMMU, we want SCTLR.HUPCF set to ensure that
pending translations are not terminated on iova fault. Otherwise
a terminated CP read could hang the GPU by returning invalid
command-stream data.
Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 6 ++
drivers/iommu/arm/arm-smmu/arm-smmu.c | 3 +++
drivers/iommu/arm/arm-smmu/arm-smmu.h | 3 +++
3 files changed, 12 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 1e942eed2dfc..0663d7d26908 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -129,6 +129,12 @@ static int qcom_adreno_smmu_init_context(struct
arm_smmu_domain *smmu_domain,
(smmu_domain->cfg.fmt == ARM_SMMU_CTX_FMT_AARCH64))
pgtbl_cfg->quirks |= IO_PGTABLE_QUIRK_ARM_TTBR1;
+ /*
+* On the GPU device we want to process subsequent transactions after a
+* fault to keep the GPU from hanging
+*/
+ smmu_domain->cfg.sctlr_set |= ARM_SMMU_SCTLR_HUPCF;
+
/*
* Initialize private interface with GPU:
*/
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index dad7fa86fbd4..1f06ab219819 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -617,6 +617,9 @@ void arm_smmu_write_context_bank(struct arm_smmu_device
*smmu, int idx)
if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
reg |= ARM_SMMU_SCTLR_E;
+ reg |= cfg->sctlr_set;
+ reg &= ~cfg->sctlr_clr;
+
arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, reg);
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 6c5ffeae..ddf2ca4c923d 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -144,6 +144,7 @@ enum arm_smmu_cbar_type {
#define ARM_SMMU_CB_SCTLR 0x0
#define ARM_SMMU_SCTLR_S1_ASIDPNE BIT(12)
#define ARM_SMMU_SCTLR_CFCFG BIT(7)
+#define ARM_SMMU_SCTLR_HUPCF BIT(8)
#define ARM_SMMU_SCTLR_CFIEBIT(6)
#define ARM_SMMU_SCTLR_CFREBIT(5)
#define ARM_SMMU_SCTLR_E BIT(4)
@@ -341,6 +342,8 @@ struct arm_smmu_cfg {
u16 asid;
u16 vmid;
};
+ u32 sctlr_set;/* extra bits to set in
SCTLR */
+ u32 sctlr_clr;/* bits to mask in SCTLR
*/
enum arm_smmu_cbar_type cbar;
enum arm_smmu_context_fmt fmt;
};
--
2.25.1
[PATCH v18 1/4] iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU
Add a special implementation for the SMMU attached to most Adreno GPU
target triggered from the qcom,adreno-smmu compatible string.
The new Adreno SMMU implementation will enable split pagetables
(TTBR1) for the domain attached to the GPU device (SID 0) and
hard code it context bank 0 so the GPU hardware can implement
per-instance pagetables.
Co-developed-by: Rob Clark
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 +
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 151 -
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
3 files changed, 153 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 88f17cc33023..d199b4bff15d 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -223,6 +223,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
return qcom_smmu_impl_init(smmu);
+ if (of_device_is_compatible(smmu->dev->of_node, "qcom,adreno-smmu"))
+ return qcom_adreno_smmu_impl_init(smmu);
+
if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = _mmu500_impl;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index be4318044f96..1e942eed2dfc 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -3,6 +3,7 @@
* Copyright (c) 2019, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include
@@ -12,6 +13,134 @@ struct qcom_smmu {
struct arm_smmu_device smmu;
};
+#define QCOM_ADRENO_SMMU_GPU_SID 0
+
+static bool qcom_adreno_smmu_is_gpu_device(struct device *dev)
+{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ int i;
+
+ /*
+* The GPU will always use SID 0 so that is a handy way to uniquely
+* identify it and configure it for per-instance pagetables
+*/
+ for (i = 0; i < fwspec->num_ids; i++) {
+ u16 sid = FIELD_GET(ARM_SMMU_SMR_ID, fwspec->ids[i]);
+
+ if (sid == QCOM_ADRENO_SMMU_GPU_SID)
+ return true;
+ }
+
+ return false;
+}
+
+static const struct io_pgtable_cfg *qcom_adreno_smmu_get_ttbr1_cfg(
+ const void *cookie)
+{
+ struct arm_smmu_domain *smmu_domain = (void *)cookie;
+ struct io_pgtable *pgtable =
+ io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
+ return >cfg;
+}
+
+/*
+ * Local implementation to configure TTBR0 with the specified pagetable config.
+ * The GPU driver will call this to enable TTBR0 when per-instance pagetables
+ * are active
+ */
+
+static int qcom_adreno_smmu_set_ttbr0_cfg(const void *cookie,
+ const struct io_pgtable_cfg *pgtbl_cfg)
+{
+ struct arm_smmu_domain *smmu_domain = (void *)cookie;
+ struct io_pgtable *pgtable =
io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
+ struct arm_smmu_cfg *cfg = _domain->cfg;
+ struct arm_smmu_cb *cb = _domain->smmu->cbs[cfg->cbndx];
+
+ /* The domain must have split pagetables already enabled */
+ if (cb->tcr[0] & ARM_SMMU_TCR_EPD1)
+ return -EINVAL;
+
+ /* If the pagetable config is NULL, disable TTBR0 */
+ if (!pgtbl_cfg) {
+ /* Do nothing if it is already disabled */
+ if ((cb->tcr[0] & ARM_SMMU_TCR_EPD0))
+ return -EINVAL;
+
+ /* Set TCR to the original configuration */
+ cb->tcr[0] = arm_smmu_lpae_tcr(>cfg);
+ cb->ttbr[0] = FIELD_PREP(ARM_SMMU_TTBRn_ASID, cb->cfg->asid);
+ } else {
+ u32 tcr = cb->tcr[0];
+
+ /* Don't call this again if TTBR0 is already enabled */
+ if (!(cb->tcr[0] & ARM_SMMU_TCR_EPD0))
+ return -EINVAL;
+
+ tcr |= arm_smmu_lpae_tcr(pgtbl_cfg);
+ tcr &= ~(ARM_SMMU_TCR_EPD0 | ARM_SMMU_TCR_EPD1);
+
+ cb->tcr[0] = tcr;
+ cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
+ cb->ttbr[0] |= FIELD_PREP(ARM_SMMU_TTBRn_ASID, cb->cfg->asid);
+ }
+
+ arm_smmu_write_context_bank(smmu_domain->smmu, cb->cfg->cbndx);
+
+ return 0;
+}
+
+static int qcom_adreno_smmu_alloc_context_bank(struct arm_smmu_domain
*smmu_domain,
+ struct arm_smmu_device *smmu,
+ struct device *dev, int start)
+{
+ int count;
+
+ /*
+* Assign context bank 0 to the GPU device so the GPU hardware can
+* switch pagetables
+*/
+ if (qcom_adreno_smmu_is_gpu_device(dev)) {
+ start =
[PATCH v18 4/4] arm: dts: qcom: sm845: Set the compatible string for the GPU SMMU
Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
split pagetables and per-instance pagetables for drm/msm.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 9 +
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 64fc1bfd66fa..39f23cdcbd02 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -633,6 +633,15 @@ _mdp {
status = "okay";
};
+/*
+ * Cheza fw does not properly program the GPU aperture to allow the
+ * GPU to update the SMMU pagetables for context switches. Work
+ * around this by dropping the "qcom,adreno-smmu" compat string.
+ */
+_smmu {
+ compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
+};
+
_pil {
iommus = <_smmu 0x781 0x0>,
<_smmu 0x724 0x3>;
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 40e8c11f23ab..0508e86140bd 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4103,7 +4103,7 @@ opp-25700 {
};
adreno_smmu: iommu@504 {
- compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
+ compatible = "qcom,sdm845-smmu-v2", "qcom,adreno-smmu",
"qcom,smmu-v2";
reg = <0 0x504 0 0x1>;
#iommu-cells = <1>;
#global-interrupts = <2>;
--
2.25.1
[PATCH v18 0/4] iommu/arm-smmu: Add adreno-smmu implementation and bindings
This short series adds support for the adreno-smmu implementation of the arm-smmu driver and the device-tree bindings to turn on the implementation for the sm845 and sc7180 GPUs. These changes are the last ones needed to enable per-instance pagetables in the drm/msm driver. No deltas in this patchset since the last go-around for 5.10 [1]. [1] https://patchwork.freedesktop.org/series/81393/ Jordan Crouse (3): iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU arm: dts: qcom: sm845: Set the compatible string for the GPU SMMU Rob Clark (1): iommu/arm-smmu: Add a way for implementations to influence SCTLR .../devicetree/bindings/iommu/arm,smmu.yaml | 9 +- arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi| 9 + arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +- drivers/iommu/arm/arm-smmu/arm-smmu-impl.c| 3 + drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c| 157 +- drivers/iommu/arm/arm-smmu/arm-smmu.c | 3 + drivers/iommu/arm/arm-smmu/arm-smmu.h | 4 + 7 files changed, 182 insertions(+), 5 deletions(-) -- 2.25.1
[PATCH] ARC: stack unwinding: avoid indefinite looping
Currently stack unwinder is a while(1) loop which relies on the dwarf
unwinder to signal termination, which in turn relies on dwarf info to do
so. This in theory could cause an infinite loop if the dwarf info was
somehow messed up or the register contents were etc.
This fix thus detects the excessive looping and breaks the loop.
Signed-off-by: Vineet Gupta
---
arch/arc/kernel/stacktrace.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index bf40e06f3fb8..0fed32b95923 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -115,7 +115,7 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs
*regs,
int (*consumer_fn) (unsigned int, void *), void *arg)
{
#ifdef CONFIG_ARC_DW2_UNWIND
- int ret = 0;
+ int ret = 0, cnt = 0;
unsigned int address;
struct unwind_frame_info frame_info;
@@ -135,6 +135,11 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs
*regs,
break;
frame_info.regs.r63 = frame_info.regs.r31;
+
+ if (cnt++ > 128) {
+ printk("unwinder looping too long, aborting !\n");
+ return 0;
+ }
}
return address; /* return the last address it saw */
--
2.25.1
Re: [PATCH] openat2: reject RESOLVE_BENEATH|RESOLVE_IN_ROOT
On 10/7/20 4:36 AM, Aleksa Sarai wrote:
This was an oversight in the original implementation, as it makes no
sense to specify both scoping flags to the same openat2(2) invocation
(before this patch, the result of such an invocation was equivalent to
RESOLVE_IN_ROOT being ignored).
This is a userspace-visible ABI change, but the only user of openat2(2)
at the moment is LXC which doesn't specify both flags and so no
userspace programs will break as a result.
Cc: # v5.6+
Fixes: fddb5d430ad9 ("open: introduce openat2(2) syscall")
Acked-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
fs/open.c | 4 +++
tools/testing/selftests/openat2/openat2_test.c | 8 +++-
You are combining fs change with selftest change.
Is there a reason why these two changes are combined?
2 separate patches is better.
thanks,
-- Shuah
Re: [PATCH v5 0/3] mtd: spi-nor: keep lock bits if they are non-volatile
Am 2020-10-03 17:32, schrieb Michael Walle: I bundled this as a series, because otherwise there will be conflicts because the "remove global protection flag" patches modify the same lines as the main patch. See invdividual patches for the version history. any news here? -michael
Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
On Tue, 27 Oct 2020 at 23:03, Nick Desaulniers wrote:
>
> On Tue, Oct 27, 2020 at 2:50 PM Ard Biesheuvel wrote:
> >
> > On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers
> > wrote:
> > >
> > > On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote:
> > > >
> > > > diff --git a/include/linux/compiler_types.h
> > > > b/include/linux/compiler_types.h
> > > > index 6e390d58a9f8..ac3fa37a84f9 100644
> > > > --- a/include/linux/compiler_types.h
> > > > +++ b/include/linux/compiler_types.h
> > > > @@ -247,10 +247,6 @@ struct ftrace_likely_data {
> > > > #define asm_inline asm
> > > > #endif
> > > >
> > > > -#ifndef __no_fgcse
> > > > -# define __no_fgcse
> > > > -#endif
> > > > -
> > > Finally, this is going to disable GCSE for the whole translation unit,
> > > which may be overkill. Previously it was isolated to one function
> > > definition. You could lower the definition of the preprocessor define
> > > into kernel/bpf/core.c to keep its use isolated as far as possible.
> > >
> >
> > Which preprocessor define?
>
> __no_fgcse
>
But we can't use that, that is the whole point of this patch.
[PATCH v3] seq_file: fix clang warning for NULL pointer arithmetic
From: Arnd Bergmann
Clang points out that adding something to NULL is notallowed
in standard C:
fs/kernfs/file.c:127:15: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
return NULL + !*ppos;
^
fs/seq_file.c:529:14: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
return NULL + (*pos == 0);
Rephrase the code to be extra explicit about the valid, giving
them named SEQ_OPEN_EOF and SEQ_OPEN_SINGLE definitions.
The instance in kernfs was copied from single_start, so fix both
at once.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: c2b19daf6760 ("sysfs, kernfs: prepare read path for kernfs")
Signed-off-by: Arnd Bergmann
---
v2: add the named macros after Christoph Hellwig pointed out
that my original logic was too ugly.
Suggestions for better names welcome
v3: don't overload the NULL return, avoid ?: operator
---
fs/kernfs/file.c | 9 ++---
fs/seq_file.c| 5 -
include/linux/seq_file.h | 2 ++
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index f277d023ebcd..5a5adb03c6df 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -121,10 +121,13 @@ static void *kernfs_seq_start(struct seq_file *sf, loff_t
*ppos)
return next;
} else {
/*
-* The same behavior and code as single_open(). Returns
-* !NULL if pos is at the beginning; otherwise, NULL.
+* The same behavior and code as single_open(). Continues
+* if pos is at the beginning; otherwise, NULL.
*/
- return NULL + !*ppos;
+ if (*ppos)
+ return NULL;
+
+ return SEQ_OPEN_SINGLE;
}
}
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 31219c1db17d..6b467d769501 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -526,7 +526,10 @@ EXPORT_SYMBOL(seq_dentry);
static void *single_start(struct seq_file *p, loff_t *pos)
{
- return NULL + (*pos == 0);
+ if (*pos)
+ return NULL;
+
+ return SEQ_OPEN_SINGLE;
}
static void *single_next(struct seq_file *p, void *v, loff_t *pos)
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index 813614d4b71f..eb38d4da 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -37,6 +37,8 @@ struct seq_operations {
#define SEQ_SKIP 1
+#define SEQ_OPEN_SINGLE(void *)1
+
/**
* seq_has_overflowed - check if the buffer has overflowed
* @m: the seq_file handle
--
2.27.0
[tip: x86/urgent] x86/debug: Fix DR_STEP vs ptrace_get_debugreg(6)
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: cb05143bdf428f280a5d519c82abf196d7871c11
Gitweb:
https://git.kernel.org/tip/cb05143bdf428f280a5d519c82abf196d7871c11
Author:Peter Zijlstra
AuthorDate:Tue, 27 Oct 2020 19:33:30 +01:00
Committer: Thomas Gleixner
CommitterDate: Tue, 27 Oct 2020 23:15:24 +01:00
x86/debug: Fix DR_STEP vs ptrace_get_debugreg(6)
Commit d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to
thread.virtual_dr6") changed the semantics of the variable from random
collection of bits, to exactly only those bits that ptrace() needs.
Unfortunately this lost DR_STEP for PTRACE_{BLOCK,SINGLE}STEP.
Furthermore, it turns out that userspace expects DR_STEP to be
unconditionally available, even for manual TF usage outside of
PTRACE_{BLOCK,SINGLE}_STEP.
Fixes: d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6")
Reported-by: Kyle Huey
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Thomas Gleixner
Tested-by: Kyle Huey
Link:
https://lore.kernel.org/r/20201027183330.gm2...@hirez.programming.kicks-ass.net
---
arch/x86/kernel/traps.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 32b2d39..e19df6c 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -937,10 +937,13 @@ static __always_inline void exc_debug_user(struct pt_regs
*regs,
instrumentation_begin();
/*
-* Clear the virtual DR6 value, ptrace() routines will set bits here
-* for things it wants signals for.
+* Start the virtual/ptrace DR6 value with just the DR_STEP mask
+* of the real DR6. ptrace_triggered() will set the DR_TRAPn bits.
+*
+* Userspace expects DR_STEP to be visible in ptrace_get_debugreg(6)
+* even if it is not the result of PTRACE_SINGLESTEP.
*/
- current->thread.virtual_dr6 = 0;
+ current->thread.virtual_dr6 = (dr6 & DR_STEP);
/*
* The SDM says "The processor clears the BTF flag when it
[tip: x86/urgent] x86/debug: Only clear/set ->virtual_dr6 for userspace #DB
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: a195f3d4528a2f88d6f986f6b1101775ad4891cf
Gitweb:
https://git.kernel.org/tip/a195f3d4528a2f88d6f986f6b1101775ad4891cf
Author:Peter Zijlstra
AuthorDate:Tue, 27 Oct 2020 10:15:06 +01:00
Committer: Thomas Gleixner
CommitterDate: Tue, 27 Oct 2020 23:15:23 +01:00
x86/debug: Only clear/set ->virtual_dr6 for userspace #DB
The ->virtual_dr6 is the value used by ptrace_{get,set}_debugreg(6). A
kernel #DB clearing it could mean spurious malfunction of ptrace()
expectations.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Thomas Gleixner
Tested-by: Kyle Huey
Link: https://lore.kernel.org/r/20201027093608.028952...@infradead.org
---
arch/x86/kernel/traps.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index b5208aa..32b2d39 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -793,12 +793,6 @@ static __always_inline unsigned long
debug_read_clear_dr6(void)
set_debugreg(DR6_RESERVED, 6);
dr6 ^= DR6_RESERVED; /* Flip to positive polarity */
- /*
-* Clear the virtual DR6 value, ptrace routines will set bits here for
-* things we want signals for.
-*/
- current->thread.virtual_dr6 = 0;
-
return dr6;
}
@@ -943,6 +937,12 @@ static __always_inline void exc_debug_user(struct pt_regs
*regs,
instrumentation_begin();
/*
+* Clear the virtual DR6 value, ptrace() routines will set bits here
+* for things it wants signals for.
+*/
+ current->thread.virtual_dr6 = 0;
+
+ /*
* The SDM says "The processor clears the BTF flag when it
* generates a debug exception." Clear TIF_BLOCKSTEP to keep
* TIF_BLOCKSTEP in sync with the hardware BTF flag.
[tip: x86/urgent] x86/debug: Fix BTF handling
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 2a9baf5ad4884108b3c6d56a50e8105ccf8a4ee7
Gitweb:
https://git.kernel.org/tip/2a9baf5ad4884108b3c6d56a50e8105ccf8a4ee7
Author:Peter Zijlstra
AuthorDate:Tue, 27 Oct 2020 10:15:05 +01:00
Committer: Thomas Gleixner
CommitterDate: Tue, 27 Oct 2020 23:15:23 +01:00
x86/debug: Fix BTF handling
The SDM states that #DB clears DEBUGCTLMSR_BTF, this means that when the
bit is set for userspace (TIF_BLOCKSTEP) and a kernel #DB happens first,
the BTF bit meant for userspace execution is lost.
Have the kernel #DB handler restore the BTF bit when it was requested
for userspace.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Thomas Gleixner
Tested-by: Kyle Huey
Link: https://lore.kernel.org/r/20201027093607.956147...@infradead.org
---
arch/x86/kernel/traps.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 3c70fb3..b5208aa 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -799,13 +799,6 @@ static __always_inline unsigned long
debug_read_clear_dr6(void)
*/
current->thread.virtual_dr6 = 0;
- /*
-* The SDM says "The processor clears the BTF flag when it
-* generates a debug exception." Clear TIF_BLOCKSTEP to keep
-* TIF_BLOCKSTEP in sync with the hardware BTF flag.
-*/
- clear_thread_flag(TIF_BLOCKSTEP);
-
return dr6;
}
@@ -873,6 +866,20 @@ static __always_inline void exc_debug_kernel(struct
pt_regs *regs,
*/
WARN_ON_ONCE(user_mode(regs));
+ if (test_thread_flag(TIF_BLOCKSTEP)) {
+ /*
+* The SDM says "The processor clears the BTF flag when it
+* generates a debug exception." but PTRACE_BLOCKSTEP requested
+* it for userspace, but we just took a kernel #DB, so re-set
+* BTF.
+*/
+ unsigned long debugctl;
+
+ rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
+ debugctl |= DEBUGCTLMSR_BTF;
+ wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
+ }
+
/*
* Catch SYSENTER with TF set and clear DR_STEP. If this hit a
* watchpoint at the same time then that will still be handled.
@@ -936,6 +943,13 @@ static __always_inline void exc_debug_user(struct pt_regs
*regs,
instrumentation_begin();
/*
+* The SDM says "The processor clears the BTF flag when it
+* generates a debug exception." Clear TIF_BLOCKSTEP to keep
+* TIF_BLOCKSTEP in sync with the hardware BTF flag.
+*/
+ clear_thread_flag(TIF_BLOCKSTEP);
+
+ /*
* If dr6 has no reason to give us about the origin of this trap,
* then it's very likely the result of an icebp/int01 trap.
* User wants a sigtrap for that.
Re: [PATCH] module: use hidden visibility for weak symbol references
One nit about ".got" in the message:
Reviewed-by: Fangrui Song
On 2020-10-27, Nick Desaulniers wrote:
+ Fangrui
On Tue, Oct 27, 2020 at 8:11 AM Ard Biesheuvel wrote:
Geert reports that commit be2881824ae9eb92 ("arm64/build: Assert for
unwanted sections") results in build errors on arm64 for configurations
that have CONFIG_MODULES disabled.
The commit in question added ASSERT()s to the arm64 linker script to
ensure that linker generated sections such as .got, .plt etc are empty,
.got -> .got.plt
be2881824ae9eb92 does not ASSERT on .got (it can).
Strangely *(.got) is placed in .text in arch/arm64/kernel/vmlinux.lds.S
I think that line can be removed. On x86, aarch64 and many other archs,
the start of .got.plt is the GOT base. .got is not needed (ppc/arm/riscv
use .got instead of .got.plt as the GOT base anchor).
but as it turns out, there are corner cases where the linker does emit
content into those sections. More specifically, weak references to
function symbols (which can remain unsatisfied, and can therefore not
be emitted as relative references) will be emitted as GOT and PLT
entries when linking the kernel in PIE mode (which is the case when
CONFIG_RELOCATABLE is enabled, which is on by default).
Confirmed.
What happens is that code such as
struct device *(*fn)(struct device *dev);
struct device *iommu_device;
fn = symbol_get(mdev_get_iommu_device);
if (fn) {
iommu_device = fn(dev);
essentially gets converted into the following when CONFIG_MODULES is off:
struct device *iommu_device;
if (_get_iommu_device) {
iommu_device = mdev_get_iommu_device(dev);
where mdev_get_iommu_device is emitted as a weak symbol reference into
the object file. The first reference is decorated with an ordinary
ABS64 data relocation (which yields 0x0 if the reference remains
unsatisfied). However, the indirect call is turned into a direct call
covered by a R_AARCH64_CALL26 relocation, which is converted into a
call via a PLT entry taking the target address from the associated
GOT entry.
Yes, the R_AARCH64_CALL26 relocation referencing an undefined weak
symbol causes one .plt entry and one .got.plt entry.
Given that such GOT and PLT entries are unnecessary for fully linked
binaries such as the kernel, let's give these weak symbol references
hidden visibility, so that the linker knows that the weak reference
via R_AARCH64_CALL26 can simply remain unsatisfied.
Cc: Jessica Yu
Cc: Kees Cook
Cc: Geert Uytterhoeven
Cc: Nick Desaulniers
Signed-off-by: Ard Biesheuvel
---
include/linux/module.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 7ccdf87f376f..6264617bab4d 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -740,7 +740,7 @@ static inline bool within_module(unsigned long addr, const
struct module *mod)
}
/* Get/put a kernel symbol (calls should be symmetric) */
-#define symbol_get(x) ({ extern typeof(x) x __attribute__((weak)); &(x); })
+#define symbol_get(x) ({ extern typeof(x) x
__attribute__((weak,visibility("hidden"))); &(x); })
#define symbol_put(x) do { } while (0)
#define symbol_put_addr(x) do { } while (0)
--
2.17.1
--
Thanks,
~Nick Desaulniers
Re: [PATCH 1/3] KVM: x86/mmu: Add helper macro for computing hugepage GFN mask
On Tue, Oct 27, 2020 at 2:43 PM Sean Christopherson
wrote:
>
> Add a helper to compute the GFN mask given a hugepage level, KVM is
> accumulating quite a few users with the addition of the TDP MMU.
>
> Note, gcc is clever enough to use a single NEG instruction instead of
> SUB+NOT, i.e. use the more common "~(level -1)" pattern instead of
> round_gfn_for_level()'s direct two's complement trickery.
As far as I can tell this patch has no functional changes intended.
Please correct me if that's not correct.
>
> Signed-off-by: Sean Christopherson
Reviewed-by: Ben Gardon
> ---
> arch/x86/include/asm/kvm_host.h | 1 +
> arch/x86/kvm/mmu/mmu.c | 2 +-
> arch/x86/kvm/mmu/paging_tmpl.h | 4 ++--
> arch/x86/kvm/mmu/tdp_iter.c | 2 +-
> 4 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index d44858b69353..6ea046415f29 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -119,6 +119,7 @@
> #define KVM_HPAGE_SIZE(x) (1UL << KVM_HPAGE_SHIFT(x))
> #define KVM_HPAGE_MASK(x) (~(KVM_HPAGE_SIZE(x) - 1))
> #define KVM_PAGES_PER_HPAGE(x) (KVM_HPAGE_SIZE(x) / PAGE_SIZE)
> +#define KVM_HPAGE_GFN_MASK(x) (~(KVM_PAGES_PER_HPAGE(x) - 1))
NIT: I know x follows the convention on adjacent macros, but this
would be clearer to me if x was changed to level. (Probably for all
the macros in this block)
>
> static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t base_gfn, int level)
> {
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 17587f496ec7..3bfc7ee44e51 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -2886,7 +2886,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t
> gpa, u32 error_code,
> disallowed_hugepage_adjust(*it.sptep, gfn, it.level,
>, );
>
> - base_gfn = gfn & ~(KVM_PAGES_PER_HPAGE(it.level) - 1);
> + base_gfn = gfn & KVM_HPAGE_GFN_MASK(it.level);
> if (it.level == level)
> break;
>
> diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
> index 50e268eb8e1a..76ee36f2afd2 100644
> --- a/arch/x86/kvm/mmu/paging_tmpl.h
> +++ b/arch/x86/kvm/mmu/paging_tmpl.h
> @@ -698,7 +698,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
> disallowed_hugepage_adjust(*it.sptep, gw->gfn,
> it.level,
>, );
>
> - base_gfn = gw->gfn & ~(KVM_PAGES_PER_HPAGE(it.level) - 1);
> + base_gfn = gw->gfn & KVM_HPAGE_GFN_MASK(it.level);
> if (it.level == level)
> break;
>
> @@ -751,7 +751,7 @@ FNAME(is_self_change_mapping)(struct kvm_vcpu *vcpu,
> bool *write_fault_to_shadow_pgtable)
> {
> int level;
> - gfn_t mask = ~(KVM_PAGES_PER_HPAGE(walker->level) - 1);
> + gfn_t mask = KVM_HPAGE_GFN_MASK(walker->level);
> bool self_changed = false;
>
> if (!(walker->pte_access & ACC_WRITE_MASK ||
> diff --git a/arch/x86/kvm/mmu/tdp_iter.c b/arch/x86/kvm/mmu/tdp_iter.c
> index 87b7e16911db..c6e914c96641 100644
> --- a/arch/x86/kvm/mmu/tdp_iter.c
> +++ b/arch/x86/kvm/mmu/tdp_iter.c
> @@ -17,7 +17,7 @@ static void tdp_iter_refresh_sptep(struct tdp_iter *iter)
>
> static gfn_t round_gfn_for_level(gfn_t gfn, int level)
> {
> - return gfn & -KVM_PAGES_PER_HPAGE(level);
> + return gfn & KVM_HPAGE_GFN_MASK(level);
> }
>
> /*
> --
> 2.28.0
>
Re: [PATCH 3/3] KVM: x86/mmu: Use hugepage GFN mask to compute GFN offset mask
On Tue, Oct 27, 2020 at 03:09:11PM -0700, Ben Gardon wrote: > On Tue, Oct 27, 2020 at 2:43 PM Sean Christopherson > wrote: > > > > Use the logical NOT of KVM_HPAGE_GFN_MASK() to compute the GFN offset > > mask instead of open coding the equivalent in a variety of locations. > > I don't see a "no functional change expected" note on this patch as > was on the previous one, but I don't think this represents any > functional change. Ah, yeah, I meant to call out in the cover letter than nothing in this series generates a functional difference, e.g. objdump of kvm/kvm-intel is identical from start to finish.
Re: [PATCH 2/3] KVM: x86/mmu: Open code GFN "rounding" in TDP MMU
On Tue, Oct 27, 2020 at 2:43 PM Sean Christopherson
wrote:
>
> Drop round_gfn_for_level() and directly use the recently introdocued
> KVM_HPAGE_GFN_MASK() macro. Hiding the masking in a "rounding" function
> adds an extra "what does this do?" lookup, whereas the concept and usage
> of PFN/GFN masks is common enough that it's easy to read the open coded
> version without thinking too hard.
>
> No functional change intended.
>
> Cc: Ben Gardon
> Signed-off-by: Sean Christopherson
Reviewed-by: Ben Gardon
> ---
> arch/x86/kvm/mmu/tdp_iter.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu/tdp_iter.c b/arch/x86/kvm/mmu/tdp_iter.c
> index c6e914c96641..4175947dc401 100644
> --- a/arch/x86/kvm/mmu/tdp_iter.c
> +++ b/arch/x86/kvm/mmu/tdp_iter.c
> @@ -15,11 +15,6 @@ static void tdp_iter_refresh_sptep(struct tdp_iter *iter)
> iter->old_spte = READ_ONCE(*iter->sptep);
> }
>
> -static gfn_t round_gfn_for_level(gfn_t gfn, int level)
> -{
> - return gfn & KVM_HPAGE_GFN_MASK(level);
> -}
> -
> /*
> * Sets a TDP iterator to walk a pre-order traversal of the paging structure
> * rooted at root_pt, starting with the walk to translate goal_gfn.
> @@ -36,7 +31,7 @@ void tdp_iter_start(struct tdp_iter *iter, u64 *root_pt,
> int root_level,
> iter->level = root_level;
> iter->pt_path[iter->level - 1] = root_pt;
>
> - iter->gfn = round_gfn_for_level(iter->goal_gfn, iter->level);
> + iter->gfn = iter->goal_gfn & KVM_HPAGE_GFN_MASK(iter->level);
> tdp_iter_refresh_sptep(iter);
>
> iter->valid = true;
> @@ -82,7 +77,7 @@ static bool try_step_down(struct tdp_iter *iter)
>
> iter->level--;
> iter->pt_path[iter->level - 1] = child_pt;
> - iter->gfn = round_gfn_for_level(iter->goal_gfn, iter->level);
> + iter->gfn = iter->goal_gfn & KVM_HPAGE_GFN_MASK(iter->level);
> tdp_iter_refresh_sptep(iter);
>
> return true;
> @@ -124,7 +119,7 @@ static bool try_step_up(struct tdp_iter *iter)
> return false;
>
> iter->level++;
> - iter->gfn = round_gfn_for_level(iter->gfn, iter->level);
> + iter->gfn &= KVM_HPAGE_GFN_MASK(iter->level);
> tdp_iter_refresh_sptep(iter);
>
> return true;
> --
> 2.28.0
>
[PATCH] i2c: exynos5: fix platform_get_irq error handling
platform_get_irq already prints an error message if the requested irq
was not found. Don't print another message in the driver.
If platform_get_irq returns an error, relay this error to the caller of the
probe function. Don't change all errors to -EINVAL. This breaks the case
where platform_get_irq returns -EPROBE_DEFER.
platform_get_irq never returns 0. Don't check for this. Make it clear that
the error path always returns a negative error code.
Signed-off-by: Martin Kaiser
---
drivers/i2c/busses/i2c-exynos5.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 6ce3ec03b595..20a9881a0d6c 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -778,11 +778,8 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
init_completion(>msg_complete);
i2c->irq = ret = platform_get_irq(pdev, 0);
- if (ret <= 0) {
- dev_err(>dev, "cannot find HS-I2C IRQ\n");
- ret = -EINVAL;
+ if (ret < 0)
goto err_clk;
- }
ret = devm_request_irq(>dev, i2c->irq, exynos5_i2c_irq,
IRQF_NO_SUSPEND, dev_name(>dev), i2c);
--
2.20.1
Re: [PATCH 3/3] KVM: x86/mmu: Use hugepage GFN mask to compute GFN offset mask
On Tue, Oct 27, 2020 at 2:43 PM Sean Christopherson
wrote:
>
> Use the logical NOT of KVM_HPAGE_GFN_MASK() to compute the GFN offset
> mask instead of open coding the equivalent in a variety of locations.
I don't see a "no functional change expected" note on this patch as
was on the previous one, but I don't think this represents any
functional change.
>
> Signed-off-by: Sean Christopherson
Reviewed-by: Ben Gardon
> ---
> arch/x86/kvm/mmu/mmu.c | 2 +-
> arch/x86/kvm/mmu/mmutrace.h | 2 +-
> arch/x86/kvm/mmu/tdp_mmu.c | 2 +-
> arch/x86/kvm/x86.c | 6 +++---
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 3bfc7ee44e51..9fb50c666ec5 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -2827,7 +2827,7 @@ int kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu,
> gfn_t gfn,
> * mmu_notifier_retry() was successful and mmu_lock is held, so
> * the pmd can't be split from under us.
> */
> - mask = KVM_PAGES_PER_HPAGE(level) - 1;
> + mask = ~KVM_HPAGE_GFN_MASK(level);
> VM_BUG_ON((gfn & mask) != (pfn & mask));
> *pfnp = pfn & ~mask;
>
> diff --git a/arch/x86/kvm/mmu/mmutrace.h b/arch/x86/kvm/mmu/mmutrace.h
> index 213699b27b44..4432ca3c7e4e 100644
> --- a/arch/x86/kvm/mmu/mmutrace.h
> +++ b/arch/x86/kvm/mmu/mmutrace.h
> @@ -372,7 +372,7 @@ TRACE_EVENT(
>
> TP_fast_assign(
> __entry->gfn = addr >> PAGE_SHIFT;
> - __entry->pfn = pfn | (__entry->gfn &
> (KVM_PAGES_PER_HPAGE(level) - 1));
> + __entry->pfn = pfn | (__entry->gfn &
> ~KVM_HPAGE_GFN_MASK(level));
> __entry->level = level;
> ),
>
> diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> index 27e381c9da6c..681686608c0b 100644
> --- a/arch/x86/kvm/mmu/tdp_mmu.c
> +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> @@ -209,7 +209,7 @@ static void __handle_changed_spte(struct kvm *kvm, int
> as_id, gfn_t gfn,
>
> WARN_ON(level > PT64_ROOT_MAX_LEVEL);
> WARN_ON(level < PG_LEVEL_4K);
> - WARN_ON(gfn & (KVM_PAGES_PER_HPAGE(level) - 1));
> + WARN_ON(gfn & ~KVM_HPAGE_GFN_MASK(level));
>
> /*
> * If this warning were to trigger it would indicate that there was a
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 397f599b20e5..faf4c4ddde94 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10451,16 +10451,16 @@ static int kvm_alloc_memslot_metadata(struct
> kvm_memory_slot *slot,
>
> slot->arch.lpage_info[i - 1] = linfo;
>
> - if (slot->base_gfn & (KVM_PAGES_PER_HPAGE(level) - 1))
> + if (slot->base_gfn & ~KVM_HPAGE_GFN_MASK(level))
> linfo[0].disallow_lpage = 1;
> - if ((slot->base_gfn + npages) & (KVM_PAGES_PER_HPAGE(level) -
> 1))
> + if ((slot->base_gfn + npages) & ~KVM_HPAGE_GFN_MASK(level))
> linfo[lpages - 1].disallow_lpage = 1;
> ugfn = slot->userspace_addr >> PAGE_SHIFT;
> /*
> * If the gfn and userspace address are not aligned wrt each
> * other, disable large page support for this slot.
> */
> - if ((slot->base_gfn ^ ugfn) & (KVM_PAGES_PER_HPAGE(level) -
> 1)) {
> + if ((slot->base_gfn ^ ugfn) & ~KVM_HPAGE_GFN_MASK(level)) {
> unsigned long j;
>
> for (j = 0; j < lpages; ++j)
> --
> 2.28.0
>
Re: [PATCH v2 04/19] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate
On 10/26/20 7:50 AM, Muchun Song wrote: > If the size of hugetlb page is 2MB, we need 512 struct page structures > (8 pages) to be associated with it. As far as I know, we only use the > first 4 struct page structures. Use of first 4 struct page structures comes from HUGETLB_CGROUP_MIN_ORDER. You could point that out here. I thought about creating a HUGETLB_MIN_ORDER definition that could be used to calculate RESERVE_VMEMMAP_NR. However, I think a hard coded value of 2U as in the patch is OK. > For tail pages, the value of compound_dtor is the same. So we can reuse > first page of tail page structs. We map the virtual addresses of the > remaining 6 pages of tail page structs to the first tail page struct, > and then free these 6 pages. Therefore, we need to reserve at least 2 > pages as vmemmap areas. > > So we introduce a new nr_free_vmemmap_pages field in the hstate to > indicate how many vmemmap pages associated with a hugetlb page that we > can free to buddy system. > > Signed-off-by: Muchun Song > --- > include/linux/hugetlb.h | 3 +++ > mm/hugetlb.c| 35 +++ > 2 files changed, 38 insertions(+) Patch looks fine with updated commit message. Acked-by: Mike Kravetz -- Mike Kravetz
[PATCH v3 03/11] KVM: VMX: Stash kvm_vmx in a local variable for Hyper-V paravirt TLB flush
Capture kvm_vmx in a local variable instead of polluting
hv_remote_flush_tlb_with_range() with to_kvm_vmx(kvm).
No functional change intended.
Reviewed-by: Vitaly Kuznetsov
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/vmx.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index ebc87df4da4d..a6442a861ffc 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -520,26 +520,27 @@ static inline int hv_remote_flush_eptp(u64 eptp, struct
kvm_tlb_range *range)
static int hv_remote_flush_tlb_with_range(struct kvm *kvm,
struct kvm_tlb_range *range)
{
+ struct kvm_vmx *kvm_vmx = to_kvm_vmx(kvm);
struct kvm_vcpu *vcpu;
int ret = 0, i;
- spin_lock(_kvm_vmx(kvm)->ept_pointer_lock);
+ spin_lock(_vmx->ept_pointer_lock);
- if (to_kvm_vmx(kvm)->ept_pointers_match == EPT_POINTERS_CHECK)
+ if (kvm_vmx->ept_pointers_match == EPT_POINTERS_CHECK)
check_ept_pointer_match(kvm);
- if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
+ if (kvm_vmx->ept_pointers_match != EPT_POINTERS_MATCH) {
kvm_for_each_vcpu(i, vcpu, kvm) {
/* If ept_pointer is invalid pointer, bypass flush
request. */
if (VALID_PAGE(to_vmx(vcpu)->ept_pointer))
ret |=
hv_remote_flush_eptp(to_vmx(vcpu)->ept_pointer,
range);
}
- } else if (VALID_PAGE(to_kvm_vmx(kvm)->hv_tlb_eptp)) {
- ret = hv_remote_flush_eptp(to_kvm_vmx(kvm)->hv_tlb_eptp, range);
+ } else if (VALID_PAGE(kvm_vmx->hv_tlb_eptp)) {
+ ret = hv_remote_flush_eptp(kvm_vmx->hv_tlb_eptp, range);
}
- spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
+ spin_unlock(_vmx->ept_pointer_lock);
return ret;
}
static int hv_remote_flush_tlb(struct kvm *kvm)
--
2.28.0
Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
On Tue, Oct 27, 2020 at 2:50 PM Ard Biesheuvel wrote:
>
> On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers
> wrote:
> >
> > On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote:
> > >
> > > diff --git a/include/linux/compiler_types.h
> > > b/include/linux/compiler_types.h
> > > index 6e390d58a9f8..ac3fa37a84f9 100644
> > > --- a/include/linux/compiler_types.h
> > > +++ b/include/linux/compiler_types.h
> > > @@ -247,10 +247,6 @@ struct ftrace_likely_data {
> > > #define asm_inline asm
> > > #endif
> > >
> > > -#ifndef __no_fgcse
> > > -# define __no_fgcse
> > > -#endif
> > > -
> > Finally, this is going to disable GCSE for the whole translation unit,
> > which may be overkill. Previously it was isolated to one function
> > definition. You could lower the definition of the preprocessor define
> > into kernel/bpf/core.c to keep its use isolated as far as possible.
> >
>
> Which preprocessor define?
__no_fgcse
>
> > I'm fine with either approach, but we should avoid new warnings for
> > clang. Thanks for the patch!
--
Thanks,
~Nick Desaulniers
Re: [PATCH 4/4] net: dsa: mv88e6xxx: Support serdes ports on MV88E6123/6131
On Tue, Oct 27, 2020 at 08:56:09PM +, Chris Packham wrote:
>
> On 24/10/20 11:42 am, Andrew Lunn wrote:
> >> +int mv88e6123_serdes_get_regs_len(struct mv88e6xxx_chip *chip, int port)
> >> +{
> >> + if (mv88e6xxx_serdes_get_lane(chip, port) == 0)
> >> + return 0;
> >> +
> >> + return 26 * sizeof(u16);
> >> +}
> > Hi Chris
> >
> > Where did 26 come from?
> In the 88E6123 Serdes Register Description the highest register address
> was 26 so that's what I used.
> Technically there are 32 possible
> addresses in that space so I could go up to 32. Equally registers 9-14,
> 20, 22-23 are "reserved" so I could remove them from the total and have
> mv88e6123_serdes_get_regs() skip over them. I'm guessing skipping some
> (27-32) and not others is probably less than ideal.
Hi Chris
I would dump all 32 and let userspace figure out if they mean
anything. The current register dump for the 6390 SEDES is horrible,
and i missed a register, and it is not easy to put in its correct
place because of ABI reasons. If you can do KISS, all the better.
Andrew
Re: [PATCH] selftests/ftrace: remove _do_fork() leftovers
On 10/23/20 9:51 AM, Steven Rostedt wrote:
On Fri, 23 Oct 2020 11:49:48 -0400
Steven Rostedt wrote:
On Fri, 23 Oct 2020 17:12:44 +0200
Alexander Gordeev wrote:
Perhaps we should have:
# older kernels have do_fork, but newer kernels have kernel_clone
echo kernel_clone >> set_ftrace_filter || echo *do_fork >>
set_ftrace_filter
Would you suggest to do the same with all occurences in
eea11285dab3 ("tracing: switch to kernel_clone()")?
Otherwise it does not really make sense to just fix couple
of tests out of dozens.
Yes. I haven't pulled in the updated tests, so I haven't hit the errors yet
(nor have I merged my work with the switch to the new name yet). So those
will most definitely break my tests.
But because it's a more generic issue, we should have a way to find what to
use. Perhaps add to the test.d/functions, something like:
FUNCTION_FORK=`(if grep '\bkernel_clone\b' /proc/kallsyms > /dev/null; then
echo kernel_clone; else echo '_do_fork'; fi)`
and use $FUNCTION_FORK everywhere that references it.
Let me pull in the latest changes, and whip up a patch that works on both
the older kernels as well as the newer ones.
-- Steve
Assume this is handled by
selftests/ftrace: Use $FUNCTION_FORK to reference kernel fork function
https://patchwork.kernel.org/project/linux-kselftest/patch/20201026162032.124c7...@gandalf.local.home/
Just making sure.
thanks,
-- Shuah
Re: [PATCH] fix swiotlb panic on Xen
On Tue, 27 Oct 2020, Konrad Rzeszutek Wilk wrote:
> > As the person who first found this and then confirmed this fixes a bug:
> >
> > Tested-by: Elliott Mitchell
>
> Thank you!!
>
> I changed the title and added the various tags and will put it in
> linux-next later this week.
Looks fine, thank you
> >From a1eb2768bf5954d25aa0f0136b38f0aa5d92d984 Mon Sep 17 00:00:00 2001
> From: Stefano Stabellini
> Date: Mon, 26 Oct 2020 17:02:14 -0700
> Subject: [PATCH] swiotlb: fix "x86: Don't panic if can not alloc buffer for
> swiotlb"
>
> kernel/dma/swiotlb.c:swiotlb_init gets called first and tries to
> allocate a buffer for the swiotlb. It does so by calling
>
> memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
>
> If the allocation must fail, no_iotlb_memory is set.
>
> Later during initialization swiotlb-xen comes in
> (drivers/xen/swiotlb-xen.c:xen_swiotlb_init) and given that io_tlb_start
> is != 0, it thinks the memory is ready to use when actually it is not.
>
> When the swiotlb is actually needed, swiotlb_tbl_map_single gets called
> and since no_iotlb_memory is set the kernel panics.
>
> Instead, if swiotlb-xen.c:xen_swiotlb_init knew the swiotlb hadn't been
> initialized, it would do the initialization itself, which might still
> succeed.
>
> Fix the panic by setting io_tlb_start to 0 on swiotlb initialization
> failure, and also by setting no_iotlb_memory to false on swiotlb
> initialization success.
>
> Fixes: ac2cbab21f31 ("x86: Don't panic if can not alloc buffer for swiotlb")
>
> Reported-by: Elliott Mitchell
> Tested-by: Elliott Mitchell
> Signed-off-by: Stefano Stabellini
> Reviewed-by: Christoph Hellwig
> CC: sta...@vger.kernel.org
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> kernel/dma/swiotlb.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 465a567678d9..e08cac39c0ba 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -229,6 +229,7 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long
> nslabs, int verbose)
> io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
> }
> io_tlb_index = 0;
> + no_iotlb_memory = false;
>
> if (verbose)
> swiotlb_print_info();
> @@ -260,9 +261,11 @@ swiotlb_init(int verbose)
> if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose))
> return;
>
> - if (io_tlb_start)
> + if (io_tlb_start) {
> memblock_free_early(io_tlb_start,
> PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
> + io_tlb_start = 0;
> + }
> pr_warn("Cannot allocate buffer");
> no_iotlb_memory = true;
> }
> @@ -360,6 +363,7 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long
> nslabs)
> io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
> }
> io_tlb_index = 0;
> + no_iotlb_memory = false;
>
> swiotlb_print_info();
>
> --
> 2.13.6
>
Re: [PATCH] ibmvfc: add new fields for version 2 of several MADs
On 10/26/20 6:56 PM, Martin K. Petersen wrote: > > Tyrel, > >> Introduce a targetWWPN field to several MADs. Its possible that a scsi >> ID of a target can change due to some fabric changes. The WWPN of the >> scsi target provides a better way to identify the target. Also, add >> flags for receiving MAD versioning information and advertising client >> support for targetWWPN with the VIOS. This latter capability flag will >> be required for future clients capable of requesting multiple hardware >> queues from the host adapter. > > Applied to 5.11/scsi-staging, thanks! > Hi Martin, I'm going to have to ask that this patch be unstaged. After some clarification from our VIOS folks I made the assumption that the MAD size was staying the same and new fields just used up existing reserved padding. Turns out they chose to keep the same amount of padding increasing the size of those structures. So, this patch needs to be reworked. Sorry about that, -Tyrel
Re: [PATCH v3 0/3] implement I2C retries for mXT1368
21.10.2020 04:14, Wang, Jiada пишет: > Hello Dmitry and all > > Kind reminder on this patch-set Hello Jiada, Thinking a bit more about these patches, I'm coming back to the variant with the atmel,wakeup-method property. There are three possible wake-up variants for mXT1368: - NONE - GPIO - I2C-SCL and this series covers only the I2C-SCL. I was also skimming through datasheets of other maxtouch touchscreens and noticed that the retries aren't unique to mXT1368. For example mXT3432 controller also needs exactly the same retrying logic. Hence I think it should be better if we could generalize the wakeup-method in the device-tree. What do you think?
Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE
On Tue, 27 Oct 2020 at 22:20, Nick Desaulniers wrote:
>
> On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote:
> >
> > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a
> > function scope __attribute__((optimize("-fno-gcse"))), to disable a
> > GCC specific optimization that was causing trouble on x86 builds, and
> > was not expected to have any positive effect in the first place.
> >
> > However, as the GCC manual documents, __attribute__((optimize))
> > is not for production use, and results in all other optimization
> > options to be forgotten for the function in question. This can
> > cause all kinds of trouble, but in one particular reported case,
> > it causes -fno-asynchronous-unwind-tables to be disregarded,
> > resulting in .eh_frame info to be emitted for the function
> > inadvertently.
> >
> > This reverts commit 3193c0836f203, and instead, it disables the -fgcse
> > optimization for the entire source file, but only when building for
> > X86.
> >
> > Cc: Nick Desaulniers
> > Cc: Arvind Sankar
> > Cc: Randy Dunlap
> > Cc: Josh Poimboeuf
> > Cc: Thomas Gleixner
> > Cc: Alexei Starovoitov
> > Cc: Daniel Borkmann
> > Cc: Peter Zijlstra (Intel)
> > Cc: Geert Uytterhoeven
> > Cc: Kees Cook
> > Fixes: 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> > ___bpf_prog_run()")
> > Signed-off-by: Ard Biesheuvel
> > ---
> > include/linux/compiler-gcc.h | 2 --
> > include/linux/compiler_types.h | 4
> > kernel/bpf/Makefile| 4 +++-
> > kernel/bpf/core.c | 2 +-
> > 4 files changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> > index d1e3c6896b71..5deb37024574 100644
> > --- a/include/linux/compiler-gcc.h
> > +++ b/include/linux/compiler-gcc.h
> > @@ -175,5 +175,3 @@
> > #else
> > #define __diag_GCC_8(s)
> > #endif
> > -
> > -#define __no_fgcse __attribute__((optimize("-fno-gcse")))
> > diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> > index 6e390d58a9f8..ac3fa37a84f9 100644
> > --- a/include/linux/compiler_types.h
> > +++ b/include/linux/compiler_types.h
> > @@ -247,10 +247,6 @@ struct ftrace_likely_data {
> > #define asm_inline asm
> > #endif
> >
> > -#ifndef __no_fgcse
> > -# define __no_fgcse
> > -#endif
> > -
> > /* Are two types/vars the same type (ignoring qualifiers)? */
> > #define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
> > typeof(b))
> >
> > diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
> > index bdc8cd1b6767..02b58f44c479 100644
> > --- a/kernel/bpf/Makefile
> > +++ b/kernel/bpf/Makefile
> > @@ -1,6 +1,8 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-y := core.o
> > -CFLAGS_core.o += $(call cc-disable-warning, override-init)
> > +# ___bpf_prog_run() needs GCSE disabled on x86; see 3193c0836f203 for
> > details
> > +cflags-core-$(CONFIG_X86) := -fno-gcse
>
> -fno-gcse is not recognized by clang and will produce
> -Wignored-optimization-argument. It should at least be wrapped in
> cc-option, though since it's unlikely to ever not be compiler
> specific, I think it might be ok to guard with `ifdef
> CONFIG_CC_IS_GCC`. Also, might we want to only do this for `ifndef
> CONFIG_RETPOLINE`, based on 3193c0836f203?
>
> Finally, this is going to disable GCSE for the whole translation unit,
> which may be overkill. Previously it was isolated to one function
> definition. You could lower the definition of the preprocessor define
> into kernel/bpf/core.c to keep its use isolated as far as possible.
>
Which preprocessor define?
> I'm fine with either approach, but we should avoid new warnings for
> clang. Thanks for the patch!
>
> > +CFLAGS_core.o += $(call cc-disable-warning, override-init) $(cflags-core-y)
> >
> > obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o
> > bpf_iter.o map_iter.o task_iter.o prog_iter.o
> > obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o
> > bpf_lru_list.o lpm_trie.o map_in_map.o
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index 9268d77898b7..55454d2278b1 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
> > @@ -1369,7 +1369,7 @@ u64 __weak bpf_probe_read_kernel(void *dst, u32 size,
> > const void *unsafe_ptr)
> > *
> > * Decode and execute eBPF instructions.
> > */
> > -static u64 __no_fgcse ___bpf_prog_run(u64 *regs, const struct bpf_insn
> > *insn, u64 *stack)
> > +static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64
> > *stack)
> > {
> > #define BPF_INSN_2_LBL(x, y)[BPF_##x | BPF_##y] = &##_##y
> > #define BPF_INSN_3_LBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] =
> > &##_##y##_##z
> > --
> > 2.17.1
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
Re: [GIT pull] x86/urgent for 5.10-rc2
The pull request you sent on Tue, 27 Oct 2020 20:14:59 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > x86-urgent-2020-10-27 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ed8780e3f2ecc82645342d070c6b4e530532e680 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH net-next 01/11] atm: horizon: shut up clang null pointer arithmetic warning
On Tue, Oct 27, 2020 at 6:24 AM Arnd Bergmann wrote:
>
> Ah, of course. I had looked up the types but mixed up the memmap
> and HDW definitions, but then got confused trying to understand the
> logic in wr_mem() that operates on bytes but expands them into
> multiples of 4.
I think wr_mem() doesn't try to expand the address into multiples of
4. The address is multiplied by "sizeof(HDW)", which is 1. So the
address is not expanded.
I think this driver uses 0-based pointers not as byte-addresses to
access the host memory, but as (32-bit) word-addresses to access the
special hardware address space.
So using pointers in this case is confusing because it makes people
incorrectly consider they are used to access the host memory. It'd be
better that we just use integers.
> I've modified it as below now, will resend along with the other patches
> if you think this makes sense.
>
> Arnd
>
> --- a/drivers/atm/horizon.c
> +++ b/drivers/atm/horizon.c
> @@ -1815,7 +1815,7 @@ static int hrz_init(hrz_dev *dev)
>
>int buff_count;
>
> - HDW * mem;
> + uintptr_t offset;
>
>cell_buf * tx_desc;
>cell_buf * rx_desc;
> @@ -1841,8 +1841,8 @@ static int hrz_init(hrz_dev *dev)
>
>printk (" clearing memory");
>
> - for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
> -wr_mem (dev, mem, 0);
> + for (offset = 0; offset < sizeof(struct MEMMAP); offset++)
> +wr_mem (dev, (HDW *)offset, 0);
>
>printk (" tx channels");
This looks good to me. Thanks!
[PATCH] x86: Drop RDPID macro to discourage use of RDPID in the kernel
Drop the GAS-compatible RDPID macro as RDPID shouldn't be used in the
kernel, excepting the vDSO, which handcodes RDPID in inline asm. RDPID
is unsafe in the kernel because KVM loads guest's TSC_AUX on VM-entry
and may not restore the host's value until the CPU returns to userspace.
See commit 6a3ea3e68b8a ("x86/entry/64: Do not use RDPID in paranoid
entry to accomodate KVM") for details.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/inst.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/x86/include/asm/inst.h b/arch/x86/include/asm/inst.h
index bd7f02480ca1..438ccd4f3cc4 100644
--- a/arch/x86/include/asm/inst.h
+++ b/arch/x86/include/asm/inst.h
@@ -143,21 +143,6 @@
.macro MODRM mod opd1 opd2
.byte \mod | (\opd1 & 7) | ((\opd2 & 7) << 3)
.endm
-
-.macro RDPID opd
- REG_TYPE rdpid_opd_type \opd
- .if rdpid_opd_type == REG_TYPE_R64
- R64_NUM rdpid_opd \opd
- .else
- R32_NUM rdpid_opd \opd
- .endif
- .byte 0xf3
- .if rdpid_opd > 7
- PFX_REX rdpid_opd 0
- .endif
- .byte 0x0f, 0xc7
- MODRM 0xc0 rdpid_opd 0x7
-.endm
#endif
#endif
--
2.28.0
Re: [PATCH 3/3] kvm/eventfd: Drain events from eventfd in irqfd_wakeup()
Hi David, I love your patch! Yet something to improve: [auto build test ERROR on vfio/next] [also build test ERROR on vhost/linux-next linus/master kvm/linux-next v5.10-rc1 next-20201027] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/David-Woodhouse/Allow-in-kernel-consumers-to-drain-events-from-eventfd/20201027-215658 base: https://github.com/awilliam/linux-vfio.git next config: s390-randconfig-r023-20201027 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project f2c25c70791de95d2466e09b5b58fc37f6ccd7a4) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu # https://github.com/0day-ci/linux/commit/dc45dd9af28fede8f8dd29b705b90f78cf87538c git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review David-Woodhouse/Allow-in-kernel-consumers-to-drain-events-from-eventfd/20201027-215658 git checkout dc45dd9af28fede8f8dd29b705b90f78cf87538c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from arch/s390/include/asm/kvm_para.h:25: In file included from arch/s390/include/asm/diag.h:12: In file included from include/linux/if_ether.h:19: In file included from include/linux/skbuff.h:31: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/s390/include/asm/io.h:72: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:21:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0x00ffUL) >> 8) |\ ^ In file included from arch/s390/kvm/../../../virt/kvm/eventfd.c:12: In file included from include/linux/kvm_host.h:32: In file included from include/linux/kvm_para.h:5: In file included from include/uapi/linux/kvm_para.h:36: In file included from arch/s390/include/asm/kvm_para.h:25: In file included from arch/s390/include/asm/diag.h:12: In file included from include/linux/if_ether.h:19: In file included from include/linux/skbuff.h:31: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included from arch/s390/include/asm/io.h:72: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:22:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0xff00UL) >> 24))) ^ In file included from arch/s390/kvm/../../../virt/kvm/eventfd.c:12: In file included from include/linux/kvm_host.h:32: In file included from include/linux/kvm_para.h:5: In file included from include/uapi/linux/kvm_para.h:36: In file included from arch/s390/include/asm/kvm_para.h:25: In file included from arch/s390/include/asm/diag.h:12: In file included from include/linux/if_ether.h:19: In file included from include/linux/skbuff.h:31: In file included from include/linux/dma-mapping.h:11: In file included from include/linux/scatterlist.h:9: In file included
Re: [PATCH v9 01/14] ASoC: sun4i-i2s: Change set_chan_cfg() params
Hi Pierre-Louis,
On Tue, 27 Oct 2020 at 19:59, Pierre-Louis Bossart
wrote:
>
>
> > @@ -452,11 +454,11 @@ static int sun8i_i2s_set_chan_cfg(const struct
> > sun4i_i2s *i2s,
> > case SND_SOC_DAIFMT_DSP_B:
> > case SND_SOC_DAIFMT_LEFT_J:
> > case SND_SOC_DAIFMT_RIGHT_J:
> > - lrck_period = params_physical_width(params) * slots;
> > + lrck_period = slot_width * slots;
> > break;
> >
> > case SND_SOC_DAIFMT_I2S:
> > - lrck_period = params_physical_width(params);
> > + lrck_period = slot_width;
> > break;
>
> Aren't I2S, LEFT_J and RIGHT_J pretty much the same in terms of lrclk
> rate/period? the only thing that can change is the polarity, no?
>
> Not sure why it's handled differently here?
I just had a look at the User Manual for H3 and H6 and I didn't find
any reason why LEFT_J and RIGHT_J should be computed in a different
way as I2S.
Also the commit introducing this doesn't mention it.
7ae7834ec446 ("ASoC: sun4i-i2s: Add support for DSP formats")
I can't test it with my board but if nobody complains about it, I will
introduce a fix for this in the next version and change this also for
H6.
Thanks for your review,
Clement
[PATCH 3/3] KVM: x86/mmu: Use hugepage GFN mask to compute GFN offset mask
Use the logical NOT of KVM_HPAGE_GFN_MASK() to compute the GFN offset
mask instead of open coding the equivalent in a variety of locations.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 2 +-
arch/x86/kvm/mmu/mmutrace.h | 2 +-
arch/x86/kvm/mmu/tdp_mmu.c | 2 +-
arch/x86/kvm/x86.c | 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 3bfc7ee44e51..9fb50c666ec5 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2827,7 +2827,7 @@ int kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, gfn_t
gfn,
* mmu_notifier_retry() was successful and mmu_lock is held, so
* the pmd can't be split from under us.
*/
- mask = KVM_PAGES_PER_HPAGE(level) - 1;
+ mask = ~KVM_HPAGE_GFN_MASK(level);
VM_BUG_ON((gfn & mask) != (pfn & mask));
*pfnp = pfn & ~mask;
diff --git a/arch/x86/kvm/mmu/mmutrace.h b/arch/x86/kvm/mmu/mmutrace.h
index 213699b27b44..4432ca3c7e4e 100644
--- a/arch/x86/kvm/mmu/mmutrace.h
+++ b/arch/x86/kvm/mmu/mmutrace.h
@@ -372,7 +372,7 @@ TRACE_EVENT(
TP_fast_assign(
__entry->gfn = addr >> PAGE_SHIFT;
- __entry->pfn = pfn | (__entry->gfn &
(KVM_PAGES_PER_HPAGE(level) - 1));
+ __entry->pfn = pfn | (__entry->gfn &
~KVM_HPAGE_GFN_MASK(level));
__entry->level = level;
),
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index 27e381c9da6c..681686608c0b 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -209,7 +209,7 @@ static void __handle_changed_spte(struct kvm *kvm, int
as_id, gfn_t gfn,
WARN_ON(level > PT64_ROOT_MAX_LEVEL);
WARN_ON(level < PG_LEVEL_4K);
- WARN_ON(gfn & (KVM_PAGES_PER_HPAGE(level) - 1));
+ WARN_ON(gfn & ~KVM_HPAGE_GFN_MASK(level));
/*
* If this warning were to trigger it would indicate that there was a
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 397f599b20e5..faf4c4ddde94 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -10451,16 +10451,16 @@ static int kvm_alloc_memslot_metadata(struct
kvm_memory_slot *slot,
slot->arch.lpage_info[i - 1] = linfo;
- if (slot->base_gfn & (KVM_PAGES_PER_HPAGE(level) - 1))
+ if (slot->base_gfn & ~KVM_HPAGE_GFN_MASK(level))
linfo[0].disallow_lpage = 1;
- if ((slot->base_gfn + npages) & (KVM_PAGES_PER_HPAGE(level) -
1))
+ if ((slot->base_gfn + npages) & ~KVM_HPAGE_GFN_MASK(level))
linfo[lpages - 1].disallow_lpage = 1;
ugfn = slot->userspace_addr >> PAGE_SHIFT;
/*
* If the gfn and userspace address are not aligned wrt each
* other, disable large page support for this slot.
*/
- if ((slot->base_gfn ^ ugfn) & (KVM_PAGES_PER_HPAGE(level) - 1))
{
+ if ((slot->base_gfn ^ ugfn) & ~KVM_HPAGE_GFN_MASK(level)) {
unsigned long j;
for (j = 0; j < lpages; ++j)
--
2.28.0
[PATCH 1/3] KVM: x86/mmu: Add helper macro for computing hugepage GFN mask
Add a helper to compute the GFN mask given a hugepage level, KVM is
accumulating quite a few users with the addition of the TDP MMU.
Note, gcc is clever enough to use a single NEG instruction instead of
SUB+NOT, i.e. use the more common "~(level -1)" pattern instead of
round_gfn_for_level()'s direct two's complement trickery.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/mmu/mmu.c | 2 +-
arch/x86/kvm/mmu/paging_tmpl.h | 4 ++--
arch/x86/kvm/mmu/tdp_iter.c | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index d44858b69353..6ea046415f29 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -119,6 +119,7 @@
#define KVM_HPAGE_SIZE(x) (1UL << KVM_HPAGE_SHIFT(x))
#define KVM_HPAGE_MASK(x) (~(KVM_HPAGE_SIZE(x) - 1))
#define KVM_PAGES_PER_HPAGE(x) (KVM_HPAGE_SIZE(x) / PAGE_SIZE)
+#define KVM_HPAGE_GFN_MASK(x) (~(KVM_PAGES_PER_HPAGE(x) - 1))
static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t base_gfn, int level)
{
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 17587f496ec7..3bfc7ee44e51 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2886,7 +2886,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa,
u32 error_code,
disallowed_hugepage_adjust(*it.sptep, gfn, it.level,
, );
- base_gfn = gfn & ~(KVM_PAGES_PER_HPAGE(it.level) - 1);
+ base_gfn = gfn & KVM_HPAGE_GFN_MASK(it.level);
if (it.level == level)
break;
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index 50e268eb8e1a..76ee36f2afd2 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -698,7 +698,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
disallowed_hugepage_adjust(*it.sptep, gw->gfn, it.level,
, );
- base_gfn = gw->gfn & ~(KVM_PAGES_PER_HPAGE(it.level) - 1);
+ base_gfn = gw->gfn & KVM_HPAGE_GFN_MASK(it.level);
if (it.level == level)
break;
@@ -751,7 +751,7 @@ FNAME(is_self_change_mapping)(struct kvm_vcpu *vcpu,
bool *write_fault_to_shadow_pgtable)
{
int level;
- gfn_t mask = ~(KVM_PAGES_PER_HPAGE(walker->level) - 1);
+ gfn_t mask = KVM_HPAGE_GFN_MASK(walker->level);
bool self_changed = false;
if (!(walker->pte_access & ACC_WRITE_MASK ||
diff --git a/arch/x86/kvm/mmu/tdp_iter.c b/arch/x86/kvm/mmu/tdp_iter.c
index 87b7e16911db..c6e914c96641 100644
--- a/arch/x86/kvm/mmu/tdp_iter.c
+++ b/arch/x86/kvm/mmu/tdp_iter.c
@@ -17,7 +17,7 @@ static void tdp_iter_refresh_sptep(struct tdp_iter *iter)
static gfn_t round_gfn_for_level(gfn_t gfn, int level)
{
- return gfn & -KVM_PAGES_PER_HPAGE(level);
+ return gfn & KVM_HPAGE_GFN_MASK(level);
}
/*
--
2.28.0
[PATCH 2/3] KVM: x86/mmu: Open code GFN "rounding" in TDP MMU
Drop round_gfn_for_level() and directly use the recently introdocued
KVM_HPAGE_GFN_MASK() macro. Hiding the masking in a "rounding" function
adds an extra "what does this do?" lookup, whereas the concept and usage
of PFN/GFN masks is common enough that it's easy to read the open coded
version without thinking too hard.
No functional change intended.
Cc: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/tdp_iter.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu/tdp_iter.c b/arch/x86/kvm/mmu/tdp_iter.c
index c6e914c96641..4175947dc401 100644
--- a/arch/x86/kvm/mmu/tdp_iter.c
+++ b/arch/x86/kvm/mmu/tdp_iter.c
@@ -15,11 +15,6 @@ static void tdp_iter_refresh_sptep(struct tdp_iter *iter)
iter->old_spte = READ_ONCE(*iter->sptep);
}
-static gfn_t round_gfn_for_level(gfn_t gfn, int level)
-{
- return gfn & KVM_HPAGE_GFN_MASK(level);
-}
-
/*
* Sets a TDP iterator to walk a pre-order traversal of the paging structure
* rooted at root_pt, starting with the walk to translate goal_gfn.
@@ -36,7 +31,7 @@ void tdp_iter_start(struct tdp_iter *iter, u64 *root_pt, int
root_level,
iter->level = root_level;
iter->pt_path[iter->level - 1] = root_pt;
- iter->gfn = round_gfn_for_level(iter->goal_gfn, iter->level);
+ iter->gfn = iter->goal_gfn & KVM_HPAGE_GFN_MASK(iter->level);
tdp_iter_refresh_sptep(iter);
iter->valid = true;
@@ -82,7 +77,7 @@ static bool try_step_down(struct tdp_iter *iter)
iter->level--;
iter->pt_path[iter->level - 1] = child_pt;
- iter->gfn = round_gfn_for_level(iter->goal_gfn, iter->level);
+ iter->gfn = iter->goal_gfn & KVM_HPAGE_GFN_MASK(iter->level);
tdp_iter_refresh_sptep(iter);
return true;
@@ -124,7 +119,7 @@ static bool try_step_up(struct tdp_iter *iter)
return false;
iter->level++;
- iter->gfn = round_gfn_for_level(iter->gfn, iter->level);
+ iter->gfn &= KVM_HPAGE_GFN_MASK(iter->level);
tdp_iter_refresh_sptep(iter);
return true;
--
2.28.0
[PATCH 0/3] KVM: x86/mmu: Add macro for hugepage GFN mask
Add a macro, which is probably long overdue, to replace open coded variants of "~(KVM_PAGES_PER_HPAGE(level) - 1)". The straw that broke the camel's back is the TDP MMU's round_gfn_for_level(), which goes straight for the optimized approach of using NEG instead of SUB+NOT (gcc uses NEG for both). The use of '-(...)' made me do a double take (more like a quadrupal take) when reading the TDP MMU code as my eyes/brain have been heavily trained to look for the more common '~(... - 1)'. Sean Christopherson (3): KVM: x86/mmu: Add helper macro for computing hugepage GFN mask KVM: x86/mmu: Open code GFN "rounding" in TDP MMU KVM: x86/mmu: Use hugepage GFN mask to compute GFN offset mask arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/mmu/mmu.c | 4 ++-- arch/x86/kvm/mmu/mmutrace.h | 2 +- arch/x86/kvm/mmu/paging_tmpl.h | 4 ++-- arch/x86/kvm/mmu/tdp_iter.c | 11 +++ arch/x86/kvm/mmu/tdp_mmu.c | 2 +- arch/x86/kvm/x86.c | 6 +++--- 7 files changed, 13 insertions(+), 17 deletions(-) -- 2.28.0
[RFC] wimax: move out to staging
From: Arnd Bergmann
There are no known users of this driver as of October 2020, and it will
be removed unless someone turns out to still need it in future releases.
According to https://en.wikipedia.org/wiki/List_of_WiMAX_networks, there
have been many public wimax networks, but it appears that these entries
are all stale, after everyone has migrated to LTE or discontinued their
service altogether.
NetworkManager appears to have dropped userspace support in 2015
https://bugzilla.gnome.org/show_bug.cgi?id=747846, the
www.linuxwimax.org
site had already shut down earlier.
WiMax is apparently still being deployed on airport campus networks
("AeroMACS"), but in a frequency band that was not supported by the old
Intel 2400m (used in Sandy Bridge laptops and earlier), which is the
only driver using the kernel's wimax stack.
Move all files into drivers/staging/wimax, including the uapi header
files and documentation, to make it easier to remove it when it gets
to that. Only minimal changes are made to the source files, in order
to make it possible to port patches across the move.
Also remove the MAINTAINERS entry that refers to a broken mailing
list and website.
Suggested-by: Inaky Perez-Gonzalez
Signed-off-by: Arnd Bergmann
---
Documentation/admin-guide/index.rst | 1 -
Documentation/networking/kapi.rst | 21 --
.../translations/zh_CN/admin-guide/index.rst | 1 -
MAINTAINERS | 22 ---
drivers/net/Kconfig | 2 --
drivers/net/wimax/Kconfig | 18 ---
drivers/net/wimax/Makefile| 2 --
drivers/staging/Kconfig | 2 ++
drivers/staging/Makefile | 1 +
.../staging/wimax/Documentation}/i2400m.rst | 0
.../staging/wimax/Documentation}/index.rst| 0
.../staging/wimax/Documentation}/wimax.rst| 0
{net => drivers/staging}/wimax/Kconfig| 6 +
{net => drivers/staging}/wimax/Makefile | 2 ++
drivers/staging/wimax/TODO| 16 ++
{net => drivers/staging}/wimax/debug-levels.h | 2 +-
{net => drivers/staging}/wimax/debugfs.c | 2 +-
drivers/{net => staging}/wimax/i2400m/Kconfig | 0
.../{net => staging}/wimax/i2400m/Makefile| 0
.../{net => staging}/wimax/i2400m/control.c | 2 +-
.../wimax/i2400m/debug-levels.h | 2 +-
.../{net => staging}/wimax/i2400m/debugfs.c | 0
.../{net => staging}/wimax/i2400m/driver.c| 2 +-
drivers/{net => staging}/wimax/i2400m/fw.c| 0
.../wimax/i2400m/i2400m-usb.h | 0
.../{net => staging}/wimax/i2400m/i2400m.h| 4 ++--
.../staging/wimax/i2400m/linux-wimax-i2400m.h | 0
.../{net => staging}/wimax/i2400m/netdev.c| 0
.../{net => staging}/wimax/i2400m/op-rfkill.c | 2 +-
drivers/{net => staging}/wimax/i2400m/rx.c| 0
drivers/{net => staging}/wimax/i2400m/sysfs.c | 0
drivers/{net => staging}/wimax/i2400m/tx.c| 0
.../wimax/i2400m/usb-debug-levels.h | 2 +-
.../{net => staging}/wimax/i2400m/usb-fw.c| 0
.../{net => staging}/wimax/i2400m/usb-notif.c | 0
.../{net => staging}/wimax/i2400m/usb-rx.c| 0
.../{net => staging}/wimax/i2400m/usb-tx.c| 0
drivers/{net => staging}/wimax/i2400m/usb.c | 2 +-
{net => drivers/staging}/wimax/id-table.c | 2 +-
.../staging/wimax/linux-wimax-debug.h | 2 +-
.../staging/wimax/linux-wimax.h | 0
.../staging/wimax/net-wimax.h | 2 +-
{net => drivers/staging}/wimax/op-msg.c | 2 +-
{net => drivers/staging}/wimax/op-reset.c | 4 ++--
{net => drivers/staging}/wimax/op-rfkill.c| 4 ++--
{net => drivers/staging}/wimax/op-state-get.c | 4 ++--
{net => drivers/staging}/wimax/stack.c| 2 +-
.../staging}/wimax/wimax-internal.h | 2 +-
net/Kconfig | 2 --
net/Makefile | 1 -
50 files changed, 49 insertions(+), 92 deletions(-)
delete mode 100644 drivers/net/wimax/Kconfig
delete mode 100644 drivers/net/wimax/Makefile
rename {Documentation/admin-guide/wimax =>
drivers/staging/wimax/Documentation}/i2400m.rst (100%)
rename {Documentation/admin-guide/wimax =>
drivers/staging/wimax/Documentation}/index.rst (100%)
rename {Documentation/admin-guide/wimax =>
drivers/staging/wimax/Documentation}/wimax.rst (100%)
rename {net => drivers/staging}/wimax/Kconfig (94%)
rename {net => drivers/staging}/wimax/Makefile (83%)
create mode 100644 drivers/staging/wimax/TODO
rename {net => drivers/staging}/wimax/debug-levels.h (96%)
rename {net => drivers/staging}/wimax/debugfs.c (97%)
rename drivers/{net => staging}/wimax/i2400m/Kconfig (100%)
rename drivers/{net => staging}/wimax/i2400m/Makefile (100%)
rename drivers/{net => staging}/wimax/i2400m/control.c (99%)
rename drivers/{net => staging}/wimax/i2400m/debug-levels.h (96%)
rename drivers/{net
Re: [PATCH v3] KVM: arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
Quoting Will Deacon (2020-10-26 06:25:33) > On Fri, Oct 23, 2020 at 08:47:50AM -0700, Stephen Boyd wrote: > > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h > > index 15c706fb0a37..0e50ba3e88d7 100644 > > --- a/include/linux/arm-smccc.h > > +++ b/include/linux/arm-smccc.h > > @@ -86,6 +86,8 @@ > > ARM_SMCCC_SMC_32,\ > > 0, 0x7fff) > > > > +#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED 1 > > I thought we'd stick this in asm/spectre.h, but here is also good: > > Acked-by: Will Deacon > Ah sorry I glossed over that one. I suppose it can be moved during patch application if desired.
Re: [PATCH v2 3/4] dm: add support for passing through inline crypto support
On Thu, Oct 15, 2020 at 09:46:31PM +, Satya Tangirala wrote:
> Update the device-mapper core to support exposing the inline crypto
> support of the underlying device(s) through the device-mapper device.
>
> This works by creating a "passthrough keyslot manager" for the dm
> device, which declares support for encryption settings which all
> underlying devices support. When a supported setting is used, the bio
> cloning code handles cloning the crypto context to the bios for all the
> underlying devices. When an unsupported setting is used, the blk-crypto
> fallback is used as usual.
>
> Crypto support on each underlying device is ignored unless the
> corresponding dm target opts into exposing it. This is needed because
> for inline crypto to semantically operate on the original bio, the data
> must not be transformed by the dm target. Thus, targets like dm-linear
> can expose crypto support of the underlying device, but targets like
> dm-crypt can't. (dm-crypt could use inline crypto itself, though.)
>
> When a key is evicted from the dm device, it is evicted from all
> underlying devices.
>
> A DM device's table can only be changed if the "new" inline encryption
> capabilities are a superset of the "old" inline encryption capabilities.
> Attempts to make changes to the table that result in some inline encryption
> capability becoming no longer supported will be rejected.
>
> Co-developed-by: Eric Biggers
> Signed-off-by: Eric Biggers
> Signed-off-by: Satya Tangirala
> ---
> block/blk-crypto.c | 1 +
> block/keyslot-manager.c | 89 +
> drivers/md/dm-ioctl.c | 8 ++
> drivers/md/dm.c | 217 +++-
> drivers/md/dm.h | 19 +++
> include/linux/device-mapper.h | 6 +
> include/linux/keyslot-manager.h | 17 +++
> 7 files changed, 356 insertions(+), 1 deletion(-)
I'm having a hard time understanding what's going on in this patch now. Besides
the simplifications I'm suggesting in other comments below, you should consider
splitting this into more than one patch. The block layer changes could be a
separate patch, as could the key eviction support.
>
> diff --git a/block/blk-crypto.c b/block/blk-crypto.c
> index 5da43f0973b4..c2be8f15006c 100644
> --- a/block/blk-crypto.c
> +++ b/block/blk-crypto.c
> @@ -409,3 +409,4 @@ int blk_crypto_evict_key(struct request_queue *q,
>*/
> return blk_crypto_fallback_evict_key(key);
> }
> +EXPORT_SYMBOL_GPL(blk_crypto_evict_key);
> diff --git a/block/keyslot-manager.c b/block/keyslot-manager.c
> index 5ad476dafeab..e16e4a074765 100644
> --- a/block/keyslot-manager.c
> +++ b/block/keyslot-manager.c
> @@ -416,6 +416,95 @@ void blk_ksm_unregister(struct request_queue *q)
> {
> q->ksm = NULL;
> }
> +EXPORT_SYMBOL_GPL(blk_ksm_unregister);
blk_ksm_unregister() doesn't seem to be necessary, since it just sets a pointer
to NULL, which the callers could easily do themselves.
> +/**
> + * blk_ksm_intersect_modes() - restrict supported modes by child device
> + * @parent: The keyslot manager for parent device
> + * @child: The keyslot manager for child device, or NULL
> + *
> + * Clear any crypto mode support bits in @parent that aren't set in @child.
> + * If @child is NULL, then all parent bits are cleared.
> + *
> + * Only use this when setting up the keyslot manager for a layered device,
> + * before it's been exposed yet.
> + */
> +void blk_ksm_intersect_modes(struct blk_keyslot_manager *parent,
> + const struct blk_keyslot_manager *child)
> +{
> + if (child) {
> + unsigned int i;
> +
> + parent->max_dun_bytes_supported =
> + min(parent->max_dun_bytes_supported,
> + child->max_dun_bytes_supported);
> + for (i = 0; i < ARRAY_SIZE(child->crypto_modes_supported);
> + i++) {
> + parent->crypto_modes_supported[i] &=
> + child->crypto_modes_supported[i];
> + }
> + } else {
> + parent->max_dun_bytes_supported = 0;
> + memset(parent->crypto_modes_supported, 0,
> +sizeof(parent->crypto_modes_supported));
> + }
> +}
> +EXPORT_SYMBOL_GPL(blk_ksm_intersect_modes);
> +
> +/**
> + * blk_ksm_is_superset() - Check if a KSM supports a superset of crypto modes
> + * and DUN bytes that another KSM supports.
> + * @ksm_superset: The KSM that we want to verify is a superset
> + * @ksm_subset: The KSM that we want to verify is a subset
> + *
> + * Return: True if @ksm_superset supports a superset of the crypto modes and
> DUN
> + * bytes that @ksm_subset supports.
> + */
> +bool blk_ksm_is_superset(struct blk_keyslot_manager *ksm_superset,
> + struct blk_keyslot_manager *ksm_subset)
blk_ksm_is_superset() is confusing because it actually does "superset or the
same", not
Re: [GIT PULL] orphan-handling fixes for v5.10-rc2
The pull request you sent on Tue, 27 Oct 2020 11:52:30 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git > tags/orphan-handling-v5.10-rc2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8c2ab803e565f994b897573f6f2f6520eef41159 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt
> -Original Message- > From: Biwen Li > Sent: Tuesday, October 27, 2020 2:48 AM > To: Rasmus Villemoes ; Biwen Li (OSS) > ; shawn...@kernel.org; robh...@kernel.org; > mark.rutl...@arm.com; Leo Li ; Z.q. Hou > ; t...@linutronix.de; ja...@lakedaemon.net; > m...@kernel.org > Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiafei Pan > ; Xiaobo Xie ; linux-arm- > ker...@lists.infradead.org > Subject: RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A > external interrupt > > > > > Caution: EXT Email > > > > On 27/10/2020 05.46, Biwen Li wrote: > > > From: Hou Zhiqiang > > > > > > Add an new IRQ chip declaration for LS1043A and LS1088A > > > - compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A. SCFG_INTPCR[31:0] > > > of these SoCs is stored/read as SCFG_INTPCR[0:31] defaultly(bit > > > reverse) > > > > s/defaultly/by default/ I suppose. But what does that mean? Is it > > still configurable, just now through some undocumented register? If > > that register still exists, does it now have a reset value of all-ones > > as opposed to the ls1021 case? If it's not configurable, then > > describing the situation as "by default" is confusing and wrong, it > > should just say "On LS1043A, LS1046A, SCFG_INTPCR is stored/read bit- > reversed." > Okay, got it. Will update it in v3. Thanks. Hi Biwen, Where did you get this information that the register on LS1043 and LS1046 is bit reversed? I cannot find such information in the RM. And does this mean all other SCFG registers are also bit reversed? If this is some information that is not covered by the RM, we probably should clarify it in the code and the commit message. Regards, Leo > > > > > > > - compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA > > > > > > Signed-off-by: Hou Zhiqiang > > > Signed-off-by: Biwen Li > > > --- > > > Change in v2: > > > - add despcription of bit reverse > > > - update copyright > > > > > > drivers/irqchip/irq-ls-extirq.c | 10 +- > > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/irqchip/irq-ls-extirq.c > > > b/drivers/irqchip/irq-ls-extirq.c index 4d1179fed77c..9587bc2607fc > > > 100644 > > > --- a/drivers/irqchip/irq-ls-extirq.c > > > +++ b/drivers/irqchip/irq-ls-extirq.c > > > @@ -1,5 +1,8 @@ > > > // SPDX-License-Identifier: GPL-2.0 > > > - > > > +/* > > > + * Author: Rasmus Villemoes > > > > If I wanted my name splattered all over the files I touch or add, I'd > > add it myself, TYVM. The git history is plenty fine for recording > > authorship as far as I'm concerned, and I absolutely abhor having to > > skip over any kind of legalese boilerplate when opening a file. > Okay, got it. Will drop it in v3. Thanks. > > > > Rasmus
Re: Subject: [RFC] clang tooling cleanups
On Tue, 2020-10-27 at 14:09 -0700, Tom Rix wrote: > On 10/27/20 12:51 PM, Joe Perches wrote: [] > > I hope a scripted patches mechanism will be established. > > I would be interested in this as well. > I already have a repo tracking next. > I can code up a script to do the commits. > Then we can poke at it with sticks and see if hooking it into next is > worthwhile. I presume it will be worthwhile. I hope the robot will run compilation and integration tests against this -next plus additional scripted patches repo. I also hope the time required before integration it into -next itself is short as running the robot for all arches seems relatively expensive.
Re: [PATCH v3 23/32] jbd2: fix a kernel-doc markup
On Tue, Oct 27, 2020 at 10:51:27AM +0100, Mauro Carvalho Chehab wrote:
> The kernel-doc markup that documents _fc_replay_callback is
> missing an asterisk, causing this warning:
>
> ../include/linux/jbd2.h:1271: warning: Function parameter or member
> 'j_fc_replay_callback' not described in 'journal_s'
>
> When building the docs.
>
> Fixes: 609f928af48f ("jbd2: fast commit recovery path")
> Signed-off-by: Mauro Carvalho Chehab
Thanks, I'm accomulating some bug fix patches to push to Linus, so
I'll grab this for the ext4 git tree.
- Ted
[PATCH v3 05/11] KVM: VMX: Do Hyper-V TLB flush iff vCPU's EPTP hasn't been flushed
Combine the for-loops for Hyper-V TLB EPTP checking and flushing, and in
doing so skip flushes for vCPUs whose EPTP matches the target EPTP.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/vmx.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index f5e9e2f61e10..17b228c4ba19 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -505,33 +505,26 @@ static int hv_remote_flush_tlb_with_range(struct kvm *kvm,
spin_lock(_vmx->ept_pointer_lock);
- if (kvm_vmx->ept_pointers_match == EPT_POINTERS_CHECK) {
+ if (kvm_vmx->ept_pointers_match != EPT_POINTERS_MATCH) {
kvm_vmx->ept_pointers_match = EPT_POINTERS_MATCH;
kvm_vmx->hv_tlb_eptp = INVALID_PAGE;
kvm_for_each_vcpu(i, vcpu, kvm) {
tmp_eptp = to_vmx(vcpu)->ept_pointer;
- if (!VALID_PAGE(tmp_eptp))
+ if (!VALID_PAGE(tmp_eptp) ||
+ tmp_eptp == kvm_vmx->hv_tlb_eptp)
continue;
- if (!VALID_PAGE(kvm_vmx->hv_tlb_eptp)) {
+ if (!VALID_PAGE(kvm_vmx->hv_tlb_eptp))
kvm_vmx->hv_tlb_eptp = tmp_eptp;
- } else if (kvm_vmx->hv_tlb_eptp != tmp_eptp) {
- kvm_vmx->hv_tlb_eptp = INVALID_PAGE;
+ else
kvm_vmx->ept_pointers_match
= EPT_POINTERS_MISMATCH;
- break;
- }
- }
- }
- if (kvm_vmx->ept_pointers_match != EPT_POINTERS_MATCH) {
- kvm_for_each_vcpu(i, vcpu, kvm) {
- /* If ept_pointer is invalid pointer, bypass flush
request. */
- if (VALID_PAGE(to_vmx(vcpu)->ept_pointer))
- ret |=
hv_remote_flush_eptp(to_vmx(vcpu)->ept_pointer,
- range);
+ ret |= hv_remote_flush_eptp(tmp_eptp, range);
}
+ if (kvm_vmx->ept_pointers_match == EPT_POINTERS_MISMATCH)
+ kvm_vmx->hv_tlb_eptp = INVALID_PAGE;
} else if (VALID_PAGE(kvm_vmx->hv_tlb_eptp)) {
ret = hv_remote_flush_eptp(kvm_vmx->hv_tlb_eptp, range);
}
--
2.28.0
Re: [PATCH] drm/vc4: hdmi: Avoid sleeping in atomic context
On Tue, Oct 27, 2020 at 11:15:58AM +0100, Maxime Ripard wrote:
> When running the trigger hook, ALSA by default will take a spinlock, and
> thus will run the trigger hook in atomic context.
>
> However, our HDMI driver will send the infoframes as part of the trigger
> hook, and part of that process is to wait for a bit to be cleared for up to
> 100ms. To be nicer to the system, that wait has some usleep_range that
> interact poorly with the atomic context.
>
> There's several ways we can fix this, but the more obvious one is to make
> ALSA take a mutex instead by setting the nonatomic flag on the DAI link.
> That doesn't work though, since now the cyclic callback installed by the
> dmaengine helpers in ALSA will take a mutex, while that callback is run by
> dmaengine's virt-chan code in a tasklet where sleeping is not allowed
> either.
>
> Given the delay we need to poll the bit for, changing the usleep_range for
> a udelay and keep running it from a context where interrupts are disabled
> is not really a good option either.
>
> However, we can move the infoframe setup code in the hw_params hook, like
> is usually done in other HDMI controllers, that isn't protected by a
> spinlock and thus where we can sleep. Infoframes will be sent on a regular
> basis anyway, and since hw_params is where the audio parameters that end up
> in the infoframes are setup, this also makes a bit more sense.
>
> Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support")
> Suggested-by: Mark Brown
> Signed-off-by: Maxime Ripard
Applied to drm-misc-fixes
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v3 05/21] selftests/resctrl: Return if resctrl file system is not supported
On 10/20/20 5:51 PM, Fenghua Yu wrote:
check_resctrlfs_support() checks if the platform supports resctrl file
system or not by looking for resctrl in /proc/filesystems and returns a
boolean value. The main function of resctrl test suite calls
check_resctrlfs_support() but forgets to check for it's return value. This
means that resctrl test suite will attempt to run resctrl tests (like CMT,
CAT, MBM and MBA) even if the platform doesn't support resctrl file system.
Fix this by checking for the return value of check_resctrlfs_support() in
the main function. If resctrl file system isn't supported on the platform
then exit the test suite gracefully without attempting to run any of
resctrl unit tests.
Fixes: ecdbb911f22d ("selftests/resctrl: Add MBM test")
Signed-off-by: Fenghua Yu
---
tools/testing/selftests/resctrl/resctrl_tests.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/resctrl/resctrl_tests.c
b/tools/testing/selftests/resctrl/resctrl_tests.c
index b2a560c0c5dc..d24de546d4ef 100644
--- a/tools/testing/selftests/resctrl/resctrl_tests.c
+++ b/tools/testing/selftests/resctrl/resctrl_tests.c
@@ -155,7 +155,11 @@ int main(int argc, char **argv)
sprintf(bw_report, "reads");
sprintf(bm_type, "fill_buf");
- check_resctrlfs_support();
+ if (!check_resctrlfs_support()) {
+ printf("Bail out! resctrl FS does not exist\n");
+ goto out;
+ }
+
Adding config file makes sense to specify dependencies.
filter_dmesg();
if (!is_amd && mbm_test) {
@@ -196,6 +200,7 @@ int main(int argc, char **argv)
cat_test_cleanup();
}
+out:
printf("1..%d\n", tests_run);
return 0;
thanks,
-- Shuah
linux-next: Signed-off-by missing for commit in the mmc tree
Hi all,
Commit
4a890911ffdb ("mmc: sdhci-of-esdhc: make sure delay chain locked for HS400")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpsBTRr9TU3c.pgp
Description: OpenPGP digital signature
