* Re: [PATCH v8 19/40] KVM: SVM: Update the SEV-ES save area mapping
From: Venu Busireddy @ 2022-01-05 18:54 UTC (permalink / raw)
To: Brijesh Singh
Cc: x86, linux-kernel, kvm, linux-efi, platform-driver-x86,
linux-coco, linux-mm, Thomas Gleixner, Ingo Molnar, Joerg Roedel,
Tom Lendacky, H. Peter Anvin, Ard Biesheuvel, Paolo Bonzini,
Sean Christopherson, Vitaly Kuznetsov, Jim Mattson,
Andy Lutomirski, Dave Hansen, Sergio Lopez, Peter Gonda,
Peter Zijlstra, Srinivas Pandruvada, David Rientjes, Dov Murik,
Tobin Feldman-Fitzthum, Borislav Petkov, Michael Roth,
Vlastimil Babka, Kirill A . Shutemov, Andi Kleen,
Dr . David Alan Gilbert, tony.luck, marcorr,
sathyanarayanan.kuppuswamy
In-Reply-To: <20211210154332.11526-20-brijesh.singh@amd.com>
On 2021-12-10 09:43:11 -0600, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> This is the final step in defining the multiple save areas to keep them
> separate and ensuring proper operation amongst the different types of
> guests. Update the SEV-ES/SEV-SNP save area to match the APM. This save
> area will be used for the upcoming SEV-SNP AP Creation NAE event support.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Venu Busireddy <venu.busireddy@oracle.com>
> ---
> arch/x86/include/asm/svm.h | 66 +++++++++++++++++++++++++++++---------
> 1 file changed, 50 insertions(+), 16 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 1/2] lib/raid6: skip benchmark of non-chosen xor_syndrome functions
From: Song Liu @ 2022-01-05 18:55 UTC (permalink / raw)
To: Dirk Müller; +Cc: linux-raid
In-Reply-To: <20220105163847.18592-1-dmueller@suse.de>
On Wed, Jan 5, 2022 at 8:39 AM Dirk Müller <dmueller@suse.de> wrote:
>
> In commit fe5cbc6e06c7 ("md/raid6 algorithms: delta syndrome functions")
> a xor_syndrome() benchmarking was added also to the raid6_choose_gen()
> function. However, the results of that benchmarking were intentionally
> discarded and did not influence the choice. It picked the
> xor_syndrome() variant related to the best performing gen_syndrome().
>
> Reduce runtime of raid6_choose_gen() without modifying its outcome by
> only benchmarking the xor_syndrome() of the best gen_syndrome() variant.
>
> For a HZ=250 x86_64 system with avx2 and without avx512 this removes
> 5 out of 6 xor() benchmarks, saving 340ms of raid6 initialization time.
>
> Signed-off-by: Dirk Müller <dmueller@suse.de>
Applied both patches to md-next.
Thanks,
Song
^ permalink raw reply
* stable/linux-4.14.y build: 196 builds: 3 failed, 193 passed, 2 errors, 32 warnings (v4.14.261)
From: kernelci.org bot @ 2022-01-05 18:56 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable/linux-4.14.y build: 196 builds: 3 failed, 193 passed, 2 errors, 32 warnings (v4.14.261)
Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.14.y/kernel/v4.14.261/
Tree: stable
Branch: linux-4.14.y
Git Describe: v4.14.261
Git Commit: bfdef05c8da46b022172695aa493cff7ac667a4b
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Built: 6 unique architectures
Build Failures Detected:
arm:
rpc_defconfig: (gcc-10) FAIL
mips:
ip27_defconfig: (gcc-10) FAIL
ip28_defconfig: (gcc-10) FAIL
Errors and Warnings Detected:
arc:
arm64:
arm:
mini2440_defconfig (gcc-10): 1 warning
omap1_defconfig (gcc-10): 1 warning
rpc_defconfig (gcc-10): 2 errors
s3c2410_defconfig (gcc-10): 1 warning
i386:
allnoconfig (gcc-10): 3 warnings
i386_defconfig (gcc-10): 3 warnings
tinyconfig (gcc-10): 3 warnings
mips:
malta_qemu_32r6_defconfig (gcc-10): 1 warning
mtx1_defconfig (gcc-10): 3 warnings
x86_64:
allnoconfig (gcc-10): 4 warnings
tinyconfig (gcc-10): 4 warnings
x86_64_defconfig (gcc-10): 4 warnings
x86_64_defconfig+x86-chromebook (gcc-10): 4 warnings
Errors summary:
1 arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
1 arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
Warnings summary:
7 ld: warning: creating DT_TEXTREL in a PIE
4 ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
4 arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
4 Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
3 ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
3 arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
2 sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
2 drivers/tty/serial/samsung.c:1794:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
1 {standard input}:30: Warning: macro instruction expanded into multiple instructions
1 sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
1 drivers/gpio/gpio-omap.c:1152:34: warning: array ‘omap_gpio_match’ assumed to have one element
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
allnoconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ar7_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
assabet_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
at91_dt_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath25_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath79_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
badge4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm2835_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bigsur_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_be_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_stb_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
capcella_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ci20_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cobalt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
collie_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
corgi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
davinci_all_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
db1xxx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
dove_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
e55_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
efm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
em_x270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ep93xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
exynos_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ezx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
footbridge_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gemini_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h5000_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hackkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hisi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hsdk_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
i386_defconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
imote2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
integrator_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop32x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop33x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip22_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jazz_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
keystone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ks8695_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lasat_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1b_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1c_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc18xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpd270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
magician_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mainstone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_qemu_32r6_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
{standard input}:30: Warning: macro instruction expanded into multiple instructions
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_xpa_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mini2440_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/tty/serial/samsung.c:1794:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
moxart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mpc30x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mps2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msp71xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
--------------------------------------------------------------------------------
multi_v4t_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mxs_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
neponset_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netwinder_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nhk8815_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc950_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc960_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omap1_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/gpio/gpio-omap.c:1152:34: warning: array ‘omap_gpio_match’ assumed to have one element
--------------------------------------------------------------------------------
omap2plus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omega2p_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
orion5x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
palmz72_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pcm027_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pic32mzda_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pistachio_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pleb_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa168_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qcom_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rb532_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rm200_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm, gcc-10) — FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
--------------------------------------------------------------------------------
rt305x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/tty/serial/samsung.c:1794:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
--------------------------------------------------------------------------------
s3c6400_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s5pv210_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sama5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shmobile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
simpad_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
socfpga_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear6xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spitz_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
stm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sunxi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tango4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0219_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tegra_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
tinyconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
trizeps4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u8500_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
versatile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vexpress_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
viper_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vocore2_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
workpad_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
x86_64_defconfig+x86-chromebook (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
xcep_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
xilfpga_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* Re: [PATCH v9 02/10] dax: Introduce holder for dax_device
From: Darrick J. Wong @ 2022-01-05 18:56 UTC (permalink / raw)
To: Dan Williams
Cc: Shiyang Ruan, Linux Kernel Mailing List, linux-xfs, Linux NVDIMM,
Linux MM, linux-fsdevel, david, Christoph Hellwig, Jane Chu
In-Reply-To: <CAPcyv4iTaneUgdBPnqcvLr4Y_nAxQp31ZdUNkSRPsQ=9CpMWHg@mail.gmail.com>
On Wed, Jan 05, 2022 at 10:23:08AM -0800, Dan Williams wrote:
> On Wed, Jan 5, 2022 at 10:12 AM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > On Sun, Dec 26, 2021 at 10:34:31PM +0800, Shiyang Ruan wrote:
> > > To easily track filesystem from a pmem device, we introduce a holder for
> > > dax_device structure, and also its operation. This holder is used to
> > > remember who is using this dax_device:
> > > - When it is the backend of a filesystem, the holder will be the
> > > instance of this filesystem.
> > > - When this pmem device is one of the targets in a mapped device, the
> > > holder will be this mapped device. In this case, the mapped device
> > > has its own dax_device and it will follow the first rule. So that we
> > > can finally track to the filesystem we needed.
> > >
> > > The holder and holder_ops will be set when filesystem is being mounted,
> > > or an target device is being activated.
> > >
> > > Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> > > ---
> > > drivers/dax/super.c | 62 +++++++++++++++++++++++++++++++++++++++++++++
> > > include/linux/dax.h | 29 +++++++++++++++++++++
> > > 2 files changed, 91 insertions(+)
> > >
> > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> > > index c46f56e33d40..94c51f2ee133 100644
> > > --- a/drivers/dax/super.c
> > > +++ b/drivers/dax/super.c
> > > @@ -20,15 +20,20 @@
> > > * @inode: core vfs
> > > * @cdev: optional character interface for "device dax"
> > > * @private: dax driver private data
> > > + * @holder_data: holder of a dax_device: could be filesystem or mapped device
> > > * @flags: state and boolean properties
> > > + * @ops: operations for dax_device
> > > + * @holder_ops: operations for the inner holder
> > > */
> > > struct dax_device {
> > > struct inode inode;
> > > struct cdev cdev;
> > > void *private;
> > > struct percpu_rw_semaphore rwsem;
> > > + void *holder_data;
> > > unsigned long flags;
> > > const struct dax_operations *ops;
> > > + const struct dax_holder_operations *holder_ops;
> > > };
> > >
> > > static dev_t dax_devt;
> > > @@ -192,6 +197,29 @@ int dax_zero_page_range(struct dax_device *dax_dev, pgoff_t pgoff,
> > > }
> > > EXPORT_SYMBOL_GPL(dax_zero_page_range);
> > >
> > > +int dax_holder_notify_failure(struct dax_device *dax_dev, u64 off,
> > > + u64 len, int mf_flags)
> > > +{
> > > + int rc;
> > > +
> > > + dax_read_lock(dax_dev);
> > > + if (!dax_alive(dax_dev)) {
> > > + rc = -ENXIO;
> > > + goto out;
> > > + }
> > > +
> > > + if (!dax_dev->holder_ops) {
> > > + rc = -EOPNOTSUPP;
> > > + goto out;
> > > + }
> > > +
> > > + rc = dax_dev->holder_ops->notify_failure(dax_dev, off, len, mf_flags);
> > > +out:
> > > + dax_read_unlock(dax_dev);
> > > + return rc;
> > > +}
> > > +EXPORT_SYMBOL_GPL(dax_holder_notify_failure);
> > > +
> > > #ifdef CONFIG_ARCH_HAS_PMEM_API
> > > void arch_wb_cache_pmem(void *addr, size_t size);
> > > void dax_flush(struct dax_device *dax_dev, void *addr, size_t size)
> > > @@ -254,6 +282,10 @@ void kill_dax(struct dax_device *dax_dev)
> > > return;
> > > dax_write_lock(dax_dev);
> > > clear_bit(DAXDEV_ALIVE, &dax_dev->flags);
> > > +
> > > + /* clear holder data */
> > > + dax_dev->holder_ops = NULL;
> > > + dax_dev->holder_data = NULL;
> > > dax_write_unlock(dax_dev);
> > > }
> > > EXPORT_SYMBOL_GPL(kill_dax);
> > > @@ -401,6 +433,36 @@ void put_dax(struct dax_device *dax_dev)
> > > }
> > > EXPORT_SYMBOL_GPL(put_dax);
> > >
> > > +void dax_register_holder(struct dax_device *dax_dev, void *holder,
> > > + const struct dax_holder_operations *ops)
> > > +{
> > > + if (!dax_alive(dax_dev))
> > > + return;
> > > +
> > > + dax_dev->holder_data = holder;
> > > + dax_dev->holder_ops = ops;
> >
> > Shouldn't this return an error code if the dax device is dead or if
> > someone already registered a holder? I'm pretty sure XFS should not
> > bind to a dax device if someone else already registered for it...
>
> Agree, yes.
>
> >
> > ...unless you want to use a notifier chain for failure events so that
> > there can be multiple consumers of dax failure events?
>
> No, I would hope not. It should be 1:1 holders to dax-devices. Similar
> ownership semantics like bd_prepare_to_claim().
Does each partition on a pmem device still have its own dax_device?
--D
^ permalink raw reply
* Re: [PATCH v2 net-next 2/7] net: dsa: merge all bools of struct dsa_port into a single u8
From: Vladimir Oltean @ 2022-01-05 18:56 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, Jakub Kicinski,
Andrew Lunn, Vivien Didelot
In-Reply-To: <07c9858a-aae1-725e-67e7-fc64f8341f3e@gmail.com>
On Wed, Jan 05, 2022 at 10:46:44AM -0800, Florian Fainelli wrote:
> On 1/5/22 10:39 AM, Vladimir Oltean wrote:
> > Hi Florian,
> >
> > On Wed, Jan 05, 2022 at 10:30:54AM -0800, Florian Fainelli wrote:
> >> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> >
> > Thanks a lot for the review.
> >
> > I'm a bit on the fence on this patch and the other one for dsa_switch.
> > The thing is that bit fields are not atomic in C89, so if we update any
> > of the flags inside dp or ds concurrently (like dp->vlan_filtering),
> > we're in trouble. Right now this isn't a problem, because most of the
> > flags are set either during probe, or during ds->ops->setup, or are
> > serialized by the rtnl_mutex in ways that are there to stay (switchdev
> > notifiers). That's why I didn't say anything about it. But it may be a
> > caveat to watch out for in the future. Do you think we need to do
> > something about it? A lock would not be necessary, strictly speaking.
>
> I would probably start with a comment that describes these pitfalls, I
> wish we had a programmatic way to ensure that these flags would not be
> set dynamically and outside of the probe/setup path but that won't
> happen easily.
A comment is probably good.
> Should we be switching to a bitmask and bitmap helpers to be future proof?
We could have done that, and it would certainly raise the awareness a
bit more, but the reason I went with the bit fields at least in the
first place was to reduce the churn in drivers. Otherwise, sure, if
driver changes are on the table for this, we can even discuss about
adding more arguments to dsa_register_switch(). The amount of poking
that drivers do inside struct dsa_switch has grown, and sometimes it's
not even immediately clear which members of that structure are supposed
to be populated by whom and when. We could definitely just tell them to
provide their desired behavior as arguments (vlan_filtering_is_global,
needs_standalone_vlan_filtering, configure_vlan_while_not_filtering,
untag_bridge_pvid, assisted_learning_on_cpu_port, ageing_time_min,
ageing_time_max, phys_mii_mask, num_tx_queues, num_lag_ids, max_num_bridges)
and only DSA will update struct dsa_switch, and we could then control
races better that way. But the downside is that we'd have 11 extra
arguments to dsa_register_switch()....
^ permalink raw reply
* [PATCH] perf/x86/rapl: fix AMD event handling
From: Stephane Eranian @ 2022-01-05 18:56 UTC (permalink / raw)
To: linux-kernel; +Cc: peterz, kim.phillips, jolsa, namhyung.kim, irogers
The RAPL events exposed under /sys/devices/power/events should only reflect
what the underlying hardware actually support. This is how it works on Intel
RAPL and Intel core/uncore PMUs in general.
But on AMD, this was not the case. All possible RAPL events were advertised.
This is what it showed on an AMD Fam17h:
$ ls /sys/devices/power/events/
energy-cores energy-gpu energy-pkg energy-psys
energy-ram energy-cores.scale energy-gpu.scale energy-pkg.scale
energy-psys.scale energy-ram.scale energy-cores.unit energy-gpu.unit
energy-pkg.unit energy-psys.unit energy-ram.unit
Yet, on AMD Fam17h, only energy-pkg is supported.
This patch fixes the problem. Given the way perf_msr_probe() works, the
amd_rapl_msrs[] table has to have all entries filled out and in particular
the group field, otherwise perf_msr_probe() defaults to making the event
visible.
With the patch applied, the kernel now only shows was is actually supported:
$ ls /sys/devices/power/events/
energy-pkg energy-pkg.scale energy-pkg.unit
The patch also uses the RAPL_MSR_MASK because only the 32-bits LSB of the
RAPL counters are relevant when reading power consumption.
Signed-off-by: Stephane Eranian <eranian@google.com>
---
arch/x86/events/rapl.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
index 85feafacc445..77e3a47af5ad 100644
--- a/arch/x86/events/rapl.c
+++ b/arch/x86/events/rapl.c
@@ -536,11 +536,14 @@ static struct perf_msr intel_rapl_spr_msrs[] = {
* - perf_msr_probe(PERF_RAPL_MAX)
* - want to use same event codes across both architectures
*/
-static struct perf_msr amd_rapl_msrs[PERF_RAPL_MAX] = {
- [PERF_RAPL_PKG] = { MSR_AMD_PKG_ENERGY_STATUS, &rapl_events_pkg_group, test_msr },
+static struct perf_msr amd_rapl_msrs[] = {
+ [PERF_RAPL_PP0] = { 0, &rapl_events_cores_group, 0, false, 0 },
+ [PERF_RAPL_PKG] = { MSR_AMD_PKG_ENERGY_STATUS, &rapl_events_pkg_group, test_msr, false, RAPL_MSR_MASK },
+ [PERF_RAPL_RAM] = { 0, &rapl_events_ram_group, 0, false, 0 },
+ [PERF_RAPL_PP1] = { 0, &rapl_events_gpu_group, 0, false, 0 },
+ [PERF_RAPL_PSYS] = { 0, &rapl_events_psys_group, 0, false, 0 },
};
-
static int rapl_cpu_offline(unsigned int cpu)
{
struct rapl_pmu *pmu = cpu_to_rapl_pmu(cpu);
--
2.34.1.448.ga2b2bfdf31-goog
^ permalink raw reply related
* Re: [PATCH 11/17] pnv_phb4_pec.c: use pnv_pec_get_phb_id() in pnv_pec_dt_xscom()
From: Daniel Henrique Barboza @ 2022-01-05 18:55 UTC (permalink / raw)
To: Cédric Le Goater, qemu-devel; +Cc: qemu-ppc, david
In-Reply-To: <2ee5ae64-3fec-9bf7-7c5d-010f90bdd379@kaod.org>
On 1/3/22 06:08, Cédric Le Goater wrote:
> On 12/28/21 20:38, Daniel Henrique Barboza wrote:
>> Relying on stack->phb to write the xscom DT of the PEC is something that
>> we won't be able to do with user creatable pnv-phb4 devices.
>>
>> Hopefully, this can be done by using pnv_pec_get_phb_id(), which is
>> already used by pnv_pec_realize() to set the phb-id of the stack. Use
>> the same idea in pnv_pec_dt_xscom() to write ibm,phb-index without the
>> need to accessing stack->phb, since stack->phb is not granted to be !=
>> NULL when user creatable phbs are introduced.
>>
>> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>
>
> Couldn't we do that already without the previous change ?
Yes. In fact I'll postpone the previous patch until we actually need it (in this
series it would be patch 15).
Thanks,
Daniel
>
> Thanks,
>
> C.
>
>
>> ---
>> hw/pci-host/pnv_phb4_pec.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/pci-host/pnv_phb4_pec.c b/hw/pci-host/pnv_phb4_pec.c
>> index 4f6db26633..56ffd446ab 100644
>> --- a/hw/pci-host/pnv_phb4_pec.c
>> +++ b/hw/pci-host/pnv_phb4_pec.c
>> @@ -466,8 +466,7 @@ static int pnv_pec_dt_xscom(PnvXScomInterface *dev, void *fdt,
>> pecc->compat_size)));
>> for (i = 0; i < pec->num_stacks; i++) {
>> - PnvPhb4PecStack *stack = &pec->stacks[i];
>> - PnvPHB4 *phb = &stack->phb;
>> + int phb_id = pnv_pec_get_phb_id(pec, i);
>> int stk_offset;
>> name = g_strdup_printf("stack@%x", i);
>> @@ -477,7 +476,7 @@ static int pnv_pec_dt_xscom(PnvXScomInterface *dev, void *fdt,
>> _FDT((fdt_setprop(fdt, stk_offset, "compatible", pecc->stk_compat,
>> pecc->stk_compat_size)));
>> _FDT((fdt_setprop_cell(fdt, stk_offset, "reg", i)));
>> - _FDT((fdt_setprop_cell(fdt, stk_offset, "ibm,phb-index", phb->phb_id)));
>> + _FDT((fdt_setprop_cell(fdt, stk_offset, "ibm,phb-index", phb_id)));
>> }
>> return 0;
>>
>
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] Cleanup to main DSA structures
From: Vladimir Oltean @ 2022-01-05 18:59 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, Jakub Kicinski,
Andrew Lunn, Vivien Didelot
In-Reply-To: <f6d50994-6022-be0f-4df2-1dc3c8199c09@gmail.com>
On Wed, Jan 05, 2022 at 10:39:04AM -0800, Florian Fainelli wrote:
> On 1/5/22 5:21 AM, Vladimir Oltean wrote:
> > This series contains changes that do the following:
> >
> > - struct dsa_port reduced from 576 to 544 bytes, and first cache line a
> > bit better organized
> > - struct dsa_switch from 160 to 136 bytes, and first cache line a bit
> > better organized
> > - struct dsa_switch_tree from 112 to 104 bytes, and first cache line a
> > bit better organized
> >
> > No changes compared to v1, just split into a separate patch set.
>
> This is all looking good to me. I suppose we could possibly swap the
> 'nh' and 'tag_ops' member since dst->tag_ops is used in
> dsa_tag_generic_flow_dissect() which is a fast path, what do you think?
pahole is telling me that dst->tag_ops is in the first cache line on
both arm64 and arm32. Are you saying that it's better for it to take
dst->nh's place?
[/opt/arm64-linux] $ pahole -C dsa_switch_tree net/dsa/slave.o
struct dsa_switch_tree {
struct list_head list; /* 0 16 */
struct list_head ports; /* 16 16 */
struct raw_notifier_head nh; /* 32 8 */
unsigned int index; /* 40 4 */
struct kref refcount; /* 44 4 */
struct net_device * * lags; /* 48 8 */
const struct dsa_device_ops * tag_ops; /* 56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
enum dsa_tag_protocol default_proto; /* 64 4 */
bool setup; /* 68 1 */
/* XXX 3 bytes hole, try to pack */
struct dsa_platform_data * pd; /* 72 8 */
struct list_head rtable; /* 80 16 */
unsigned int lags_len; /* 96 4 */
unsigned int last_switch; /* 100 4 */
/* size: 104, cachelines: 2, members: 13 */
/* sum members: 101, holes: 1, sum holes: 3 */
/* last cacheline: 40 bytes */
};
[/opt/arm-linux] $ pahole -C dsa_switch_tree net/dsa/slave.o
struct dsa_switch_tree {
struct list_head list; /* 0 8 */
struct list_head ports; /* 8 8 */
struct raw_notifier_head nh; /* 16 4 */
unsigned int index; /* 20 4 */
struct kref refcount; /* 24 4 */
struct net_device * * lags; /* 28 4 */
const struct dsa_device_ops * tag_ops; /* 32 4 */
enum dsa_tag_protocol default_proto; /* 36 4 */
bool setup; /* 40 1 */
/* XXX 3 bytes hole, try to pack */
struct dsa_platform_data * pd; /* 44 4 */
struct list_head rtable; /* 48 8 */
unsigned int lags_len; /* 56 4 */
unsigned int last_switch; /* 60 4 */
/* size: 64, cachelines: 1, members: 13 */
/* sum members: 61, holes: 1, sum holes: 3 */
};
^ permalink raw reply
* Re: [PATCH 0/2] md: it panice after reshape from raid1 to raid5
From: Song Liu @ 2022-01-05 18:59 UTC (permalink / raw)
To: Xiao Ni; +Cc: Guoqing Jiang, Nigel Croxon, linux-raid
In-Reply-To: <6bb93ce0-30e0-ff3b-9457-470496f7b1bc@redhat.com>
On Tue, Jan 4, 2022 at 3:30 PM Xiao Ni <xni@redhat.com> wrote:
>
> Hi Song
>
> Ping. Do I still change something else?
I merged the two patches into one, rewrote the commit log, added
Guoqing's Acked-by, and applied it to md-next.
For future patches, please write the commit log according to the
guidance in Documentation/process/submitting-patches.rst.
Thanks,
Song
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t] tests/i915/userptr: fix mapping type
From: Dixit, Ashutosh @ 2022-01-05 19:00 UTC (permalink / raw)
To: Matthew Auld; +Cc: igt-dev, Thomas Hellström, intel-gfx
In-Reply-To: <20220105172106.154217-1-matthew.auld@intel.com>
On Wed, 05 Jan 2022 09:21:06 -0800, Matthew Auld wrote:
>
> We need to use the FIXED mapping type on discrete platforms.
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Priyanka Dandamudi <priyanka.dandamudi@intel.com>
> ---
> tests/i915/gem_userptr_blits.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
> index 3464db66..a4dca4c0 100644
> --- a/tests/i915/gem_userptr_blits.c
> +++ b/tests/i915/gem_userptr_blits.c
> @@ -2185,7 +2185,10 @@ static void test_probe(int fd)
> */
> memset(&mmap_offset, 0, sizeof(mmap_offset));
> mmap_offset.handle = gem_create(fd, PAGE_SIZE);
> - mmap_offset.flags = I915_MMAP_OFFSET_WB;
> + if (gem_has_lmem(fd))
> + mmap_offset.flags = I915_MMAP_OFFSET_FIXED;
> + else
> + mmap_offset.flags = I915_MMAP_OFFSET_WB;
> igt_assert_eq(igt_ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_OFFSET, &mmap_offset), 0);
>
> for (unsigned long pass = 0; pass < 4 * 4 * 4 * 4 * 4; pass++) {
> --
> 2.31.1
>
^ permalink raw reply
* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/i915/userptr: fix mapping type
From: Dixit, Ashutosh @ 2022-01-05 19:00 UTC (permalink / raw)
To: Matthew Auld; +Cc: igt-dev, Thomas Hellström, intel-gfx
In-Reply-To: <20220105172106.154217-1-matthew.auld@intel.com>
On Wed, 05 Jan 2022 09:21:06 -0800, Matthew Auld wrote:
>
> We need to use the FIXED mapping type on discrete platforms.
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Priyanka Dandamudi <priyanka.dandamudi@intel.com>
> ---
> tests/i915/gem_userptr_blits.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
> index 3464db66..a4dca4c0 100644
> --- a/tests/i915/gem_userptr_blits.c
> +++ b/tests/i915/gem_userptr_blits.c
> @@ -2185,7 +2185,10 @@ static void test_probe(int fd)
> */
> memset(&mmap_offset, 0, sizeof(mmap_offset));
> mmap_offset.handle = gem_create(fd, PAGE_SIZE);
> - mmap_offset.flags = I915_MMAP_OFFSET_WB;
> + if (gem_has_lmem(fd))
> + mmap_offset.flags = I915_MMAP_OFFSET_FIXED;
> + else
> + mmap_offset.flags = I915_MMAP_OFFSET_WB;
> igt_assert_eq(igt_ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_OFFSET, &mmap_offset), 0);
>
> for (unsigned long pass = 0; pass < 4 * 4 * 4 * 4 * 4; pass++) {
> --
> 2.31.1
>
^ permalink raw reply
* Re: [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area
From: Borislav Petkov @ 2022-01-05 19:01 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Dov Murik, Brijesh Singh, Tom Lendacky, linux-efi, Ashish Kalra,
Ard Biesheuvel, James Morris, Serge E. Hallyn, Andi Kleen,
Greg KH, Andrew Scull, Dave Hansen, James Bottomley,
Tobin Feldman-Fitzthum, Jim Cadden, Daniele Buono, linux-coco,
linux-security-module, linux-kernel
In-Reply-To: <YdWEXRt7Ixm6/+Dq@work-vm>
On Wed, Jan 05, 2022 at 11:43:25AM +0000, Dr. David Alan Gilbert wrote:
> There's more than one type of dance;
So Brijesh and I talked about this a bit yesterday. There's all kinds of
dances...
> this partially varies depending on the system (SEV/TDX etc)
By "SEV" I guess you mean pre-SNP because SNP attestation is reportedly
much better.
TDX I'm being told is not interested in something like that atm. I guess
they wanna do something different wrt attestation.
So what we're talking about here is pre-SNP attestation, AFAICT.
> and also depends on how you depend to boot your VM (separate kernel
> or VM disk). Also it's important to note that when the dance happens
> varies - in SEV and SEV-ES this happens before the guest executes any
> code. So at the end of the dance, the guest owner hands over that
> secret - but only then does the geust start booting;
Right.
> that secret has to go somewhere to be used by something later. For
> example, something might pull out that key and use it to decrypt a
> disk that then has other secrets on it (e.g. your ssh key).
That is the other example I heard about.
So, to sum up: this looks like part of a pre-SNP attestation flow, i.e.,
for SEV and SEV-ES guests.
Follow-up question: is this going to be used by other cloud vendors too?
Or am I gonna get another implementation of sharing secrets with a guest
which is just a little bit different but sender #2 can't use this one
because raisins?
Because that would not be good.
So, is this what cloud vendors using SEV/-ES guests would like to use
and what they all agree upon?
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg
^ permalink raw reply
* Re: CI for qemu-hexagon
From: Alex Bennée @ 2022-01-05 18:53 UTC (permalink / raw)
To: Alessandro Di Federico; +Cc: Brian Cain, tsimpson, Anton Johansson via
In-Reply-To: <20220105185720.0d4fc159@orange>
Alessandro Di Federico <ale@rev.ng> writes:
> Hi Alex, I hope you enjoyed the holidays!
>
> We're trying to upstream idef-parser (the automatic generator of the
> Hexagon frontend). This introduces new dependencies, specifically flex
> and bison.
>
> Attached you can find our patch for that.
>
> However the CI fails:
>
> https://gitlab.com/carl.cudig/qemu/-/jobs/1939950230
>
> AFAIU the Hexagon docker image is "special" since it's the only one
> that needs the cross-compiler to be built from source and, therefore,
> it's a process that needs to be triggered manually.
It's not that special now - we have the same for microblaze and nios2
(and more are coming). There was a build that moved the hexagon
toolchain to using prebuilts hosted by QC but it ran into problems and
I'm waiting for an update to that/
> Is this correct?
>
> If so, what should we do? Make a pull request despite the failure and
> then it will be taken care of, or should I make a separate (preliminary)
> pull request just for that patch?
Just include the patch to update the docker file in the series that
introduces the feature and mention it in the cover letter. Users can
always build the container locally and we can ensure the binary image is
updated once it's merged.
--
Alex Bennée
^ permalink raw reply
* decompress.c:(.text.FSE_buildDTable_internal+0x2cc): undefined reference to `__clzdi2'
From: kernel test robot @ 2022-01-05 19:02 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: c9e6606c7fe92b50a02ce51dda82586ebdf99b48
commit: e0c1b49f5b674cca7b10549c53b3791d0bbc90a8 lib: zstd: Upgrade to latest upstream zstd version 1.4.10
date: 8 weeks ago
config: mips-randconfig-r025-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060233.mO6P39bM-lkp(a)intel.com/config)
compiler: mips64el-linux-gcc (GCC) 11.2.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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0c1b49f5b674cca7b10549c53b3791d0bbc90a8
git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e0c1b49f5b674cca7b10549c53b3791d0bbc90a8
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=mips SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_buildDTable_internal':
>> decompress.c:(.text.FSE_buildDTable_internal+0x2cc): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `BIT_initDStream':
decompress.c:(.text.BIT_initDStream+0x7c): undefined reference to `__clzdi2'
mips64el-linux-ld: decompress.c:(.text.BIT_initDStream+0x158): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_buildFSETable_body_default.constprop.0':
>> decompress.c:(.text.ZSTD_buildFSETable_body_default.constprop.0+0x2a8): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_readNCount_body_default':
>> decompress.c:(.text.FSE_readNCount_body_default+0x130): undefined reference to `__ctzdi2'
>> mips64el-linux-ld: decompress.c:(.text.FSE_readNCount_body_default+0x1a4): undefined reference to `__ctzdi2'
>> mips64el-linux-ld: decompress.c:(.text.FSE_readNCount_body_default+0x2e4): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `HUF_readStats_body_default':
>> decompress.c:(.text.HUF_readStats_body_default+0x184): undefined reference to `__clzdi2'
>> mips64el-linux-ld: decompress.c:(.text.HUF_readStats_body_default+0x1b4): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_DCtx_getParameter':
>> decompress.c:(.text.ZSTD_DCtx_getParameter+0x60): undefined reference to `__clzdi2'
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH v5 4/4] KVM: mmu: remove over-aggressive warnings
From: Sean Christopherson @ 2022-01-05 19:02 UTC (permalink / raw)
To: David Stevens
Cc: Marc Zyngier, Paolo Bonzini, James Morse, Alexandru Elisei,
Suzuki K Poulose, Will Deacon, Wanpeng Li, Jim Mattson,
Joerg Roedel, linux-arm-kernel, kvmarm, linux-kernel, kvm
In-Reply-To: <CAD=HUj5Q6rW8UyxAXUa3o93T0LBqGQb7ScPj07kvuM3txHMMrQ@mail.gmail.com>
On Wed, Jan 05, 2022, David Stevens wrote:
> On Fri, Dec 31, 2021 at 4:22 AM Sean Christopherson <seanjc@google.com> wrote:
> > > */
> > > - if (!pfn_valid(pfn) || WARN_ON_ONCE(!page_count(pfn_to_page(pfn))))
> > > + if (!pfn_valid(pfn) || !page_count(pfn_to_page(pfn)))
> >
> > Hrm, I know the whole point of this series is to support pages without an elevated
> > refcount, but this WARN was extremely helpful in catching several use-after-free
> > bugs in the TDP MMU. We talked about burying a slow check behind MMU_WARN_ON, but
> > that isn't very helpful because no one runs with MMU_WARN_ON, and this is also a
> > type of check that's most useful if it runs in production.
> >
> > IIUC, this series explicitly disallows using pfns that have a struct page without
> > refcounting, and the issue with the WARN here is that kvm_is_zone_device_pfn() is
> > called by kvm_is_reserved_pfn() before ensure_pfn_ref() rejects problematic pages,
> > i.e. triggers false positive.
> >
> > So, can't we preserve the use-after-free benefits of the check by moving it to
> > where KVM releases the PFN? I.e.
> >
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index fbca2e232e94..675b835525fa 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -2904,15 +2904,19 @@ EXPORT_SYMBOL_GPL(kvm_release_pfn_dirty);
> >
> > void kvm_set_pfn_dirty(kvm_pfn_t pfn)
> > {
> > - if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn))
> > + if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn)) {
> > + WARN_ON_ONCE(!page_count(pfn_to_page(pfn)));
> > SetPageDirty(pfn_to_page(pfn));
> > + }
> > }
> > EXPORT_SYMBOL_GPL(kvm_set_pfn_dirty);
>
> I'm still seeing this warning show up via __handle_changed_spte
> calling kvm_set_pfn_dirty:
>
> [ 113.350473] kvm_set_pfn_dirty+0x26/0x3e
> [ 113.354861] __handle_changed_spte+0x452/0x4f6
> [ 113.359841] __handle_changed_spte+0x452/0x4f6
> [ 113.364819] __handle_changed_spte+0x452/0x4f6
> [ 113.369790] zap_gfn_range+0x1de/0x27a
> [ 113.373992] kvm_tdp_mmu_zap_invalidated_roots+0x64/0xb8
> [ 113.379945] kvm_mmu_zap_all_fast+0x18c/0x1c1
> [ 113.384827] kvm_page_track_flush_slot+0x55/0x87
> [ 113.390000] kvm_set_memslot+0x137/0x455
> [ 113.394394] kvm_delete_memslot+0x5c/0x91
> [ 113.398888] __kvm_set_memory_region+0x3c0/0x5e6
> [ 113.404061] kvm_set_memory_region+0x45/0x74
> [ 113.408844] kvm_vm_ioctl+0x563/0x60c
>
> I wasn't seeing it for my particular test case, but the gfn aging code
> might trigger the warning as well.
Ah, I got royally confused by ensure_pfn_ref()'s comment
* Certain IO or PFNMAP mappings can be backed with valid
* struct pages, but be allocated without refcounting e.g.,
* tail pages of non-compound higher order allocations, which
* would then underflow the refcount when the caller does the
* required put_page. Don't allow those pages here.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that doesn't apply here because kvm_faultin_pfn() uses the low level
__gfn_to_pfn_page_memslot().
and my understanding is that @page will be non-NULL in ensure_pfn_ref() iff the
page has an elevated refcount.
Can you update the changelogs for the x86+arm64 "use gfn_to_pfn_page" patches to
explicitly call out the various ramifications of moving to gfn_to_pfn_page()?
Side topic, s/covert/convert in both changelogs :-)
> I don't know if setting the dirty/accessed bits in non-refcounted
> struct pages is problematic.
Without knowing exactly what lies behind such pages, KVM needs to set dirty bits,
otherwise there's a potential for data lost.
> The only way I can see to avoid it would be to try to map from the spte to
> the vma and then check its flags. If setting the flags is benign, then we'd
> need to do that lookup to differentiate the safe case from the use-after-free
> case. Do you have any advice on how to handle this?
Hrm. I can't think of a clever generic solution. But for x86-64, we can use a
software available bit to mark SPTEs as being refcounted use that flag to assert
the refcount is elevated when marking the backing pfn dirty/accessed. It'd be
64-bit only because we're out of software available bits for PAE paging, but (a)
practically no one cares about 32-bit and (b) odds are slim that a use-after-free
would be unique to 32-bit KVM.
But that can all go in after your series is merged, e.g. I'd prefer to cleanup
make_spte()'s prototype to use @fault adding yet another parameter, and that'll
take a few patches to make happen since FNAME(sync_page) also uses make_spte().
TL;DR: continue as you were, I'll stop whining about this :-)
^ permalink raw reply
* Re: [PATCH v5 4/4] KVM: mmu: remove over-aggressive warnings
From: Sean Christopherson @ 2022-01-05 19:02 UTC (permalink / raw)
To: David Stevens
Cc: Wanpeng Li, kvm, Marc Zyngier, Joerg Roedel, linux-kernel,
Paolo Bonzini, Will Deacon, kvmarm, linux-arm-kernel, Jim Mattson
In-Reply-To: <CAD=HUj5Q6rW8UyxAXUa3o93T0LBqGQb7ScPj07kvuM3txHMMrQ@mail.gmail.com>
On Wed, Jan 05, 2022, David Stevens wrote:
> On Fri, Dec 31, 2021 at 4:22 AM Sean Christopherson <seanjc@google.com> wrote:
> > > */
> > > - if (!pfn_valid(pfn) || WARN_ON_ONCE(!page_count(pfn_to_page(pfn))))
> > > + if (!pfn_valid(pfn) || !page_count(pfn_to_page(pfn)))
> >
> > Hrm, I know the whole point of this series is to support pages without an elevated
> > refcount, but this WARN was extremely helpful in catching several use-after-free
> > bugs in the TDP MMU. We talked about burying a slow check behind MMU_WARN_ON, but
> > that isn't very helpful because no one runs with MMU_WARN_ON, and this is also a
> > type of check that's most useful if it runs in production.
> >
> > IIUC, this series explicitly disallows using pfns that have a struct page without
> > refcounting, and the issue with the WARN here is that kvm_is_zone_device_pfn() is
> > called by kvm_is_reserved_pfn() before ensure_pfn_ref() rejects problematic pages,
> > i.e. triggers false positive.
> >
> > So, can't we preserve the use-after-free benefits of the check by moving it to
> > where KVM releases the PFN? I.e.
> >
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index fbca2e232e94..675b835525fa 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -2904,15 +2904,19 @@ EXPORT_SYMBOL_GPL(kvm_release_pfn_dirty);
> >
> > void kvm_set_pfn_dirty(kvm_pfn_t pfn)
> > {
> > - if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn))
> > + if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn)) {
> > + WARN_ON_ONCE(!page_count(pfn_to_page(pfn)));
> > SetPageDirty(pfn_to_page(pfn));
> > + }
> > }
> > EXPORT_SYMBOL_GPL(kvm_set_pfn_dirty);
>
> I'm still seeing this warning show up via __handle_changed_spte
> calling kvm_set_pfn_dirty:
>
> [ 113.350473] kvm_set_pfn_dirty+0x26/0x3e
> [ 113.354861] __handle_changed_spte+0x452/0x4f6
> [ 113.359841] __handle_changed_spte+0x452/0x4f6
> [ 113.364819] __handle_changed_spte+0x452/0x4f6
> [ 113.369790] zap_gfn_range+0x1de/0x27a
> [ 113.373992] kvm_tdp_mmu_zap_invalidated_roots+0x64/0xb8
> [ 113.379945] kvm_mmu_zap_all_fast+0x18c/0x1c1
> [ 113.384827] kvm_page_track_flush_slot+0x55/0x87
> [ 113.390000] kvm_set_memslot+0x137/0x455
> [ 113.394394] kvm_delete_memslot+0x5c/0x91
> [ 113.398888] __kvm_set_memory_region+0x3c0/0x5e6
> [ 113.404061] kvm_set_memory_region+0x45/0x74
> [ 113.408844] kvm_vm_ioctl+0x563/0x60c
>
> I wasn't seeing it for my particular test case, but the gfn aging code
> might trigger the warning as well.
Ah, I got royally confused by ensure_pfn_ref()'s comment
* Certain IO or PFNMAP mappings can be backed with valid
* struct pages, but be allocated without refcounting e.g.,
* tail pages of non-compound higher order allocations, which
* would then underflow the refcount when the caller does the
* required put_page. Don't allow those pages here.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that doesn't apply here because kvm_faultin_pfn() uses the low level
__gfn_to_pfn_page_memslot().
and my understanding is that @page will be non-NULL in ensure_pfn_ref() iff the
page has an elevated refcount.
Can you update the changelogs for the x86+arm64 "use gfn_to_pfn_page" patches to
explicitly call out the various ramifications of moving to gfn_to_pfn_page()?
Side topic, s/covert/convert in both changelogs :-)
> I don't know if setting the dirty/accessed bits in non-refcounted
> struct pages is problematic.
Without knowing exactly what lies behind such pages, KVM needs to set dirty bits,
otherwise there's a potential for data lost.
> The only way I can see to avoid it would be to try to map from the spte to
> the vma and then check its flags. If setting the flags is benign, then we'd
> need to do that lookup to differentiate the safe case from the use-after-free
> case. Do you have any advice on how to handle this?
Hrm. I can't think of a clever generic solution. But for x86-64, we can use a
software available bit to mark SPTEs as being refcounted use that flag to assert
the refcount is elevated when marking the backing pfn dirty/accessed. It'd be
64-bit only because we're out of software available bits for PAE paging, but (a)
practically no one cares about 32-bit and (b) odds are slim that a use-after-free
would be unique to 32-bit KVM.
But that can all go in after your series is merged, e.g. I'd prefer to cleanup
make_spte()'s prototype to use @fault adding yet another parameter, and that'll
take a few patches to make happen since FNAME(sync_page) also uses make_spte().
TL;DR: continue as you were, I'll stop whining about this :-)
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* decompress.c:(.text.FSE_buildDTable_internal+0x2cc): undefined reference to `__clzdi2'
From: kernel test robot @ 2022-01-05 19:02 UTC (permalink / raw)
To: Nick Terrell; +Cc: kbuild-all, linux-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: c9e6606c7fe92b50a02ce51dda82586ebdf99b48
commit: e0c1b49f5b674cca7b10549c53b3791d0bbc90a8 lib: zstd: Upgrade to latest upstream zstd version 1.4.10
date: 8 weeks ago
config: mips-randconfig-r025-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060233.mO6P39bM-lkp@intel.com/config)
compiler: mips64el-linux-gcc (GCC) 11.2.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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0c1b49f5b674cca7b10549c53b3791d0bbc90a8
git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e0c1b49f5b674cca7b10549c53b3791d0bbc90a8
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=mips SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_buildDTable_internal':
>> decompress.c:(.text.FSE_buildDTable_internal+0x2cc): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `BIT_initDStream':
decompress.c:(.text.BIT_initDStream+0x7c): undefined reference to `__clzdi2'
mips64el-linux-ld: decompress.c:(.text.BIT_initDStream+0x158): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_buildFSETable_body_default.constprop.0':
>> decompress.c:(.text.ZSTD_buildFSETable_body_default.constprop.0+0x2a8): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_readNCount_body_default':
>> decompress.c:(.text.FSE_readNCount_body_default+0x130): undefined reference to `__ctzdi2'
>> mips64el-linux-ld: decompress.c:(.text.FSE_readNCount_body_default+0x1a4): undefined reference to `__ctzdi2'
>> mips64el-linux-ld: decompress.c:(.text.FSE_readNCount_body_default+0x2e4): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `HUF_readStats_body_default':
>> decompress.c:(.text.HUF_readStats_body_default+0x184): undefined reference to `__clzdi2'
>> mips64el-linux-ld: decompress.c:(.text.HUF_readStats_body_default+0x1b4): undefined reference to `__clzdi2'
mips64el-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_DCtx_getParameter':
>> decompress.c:(.text.ZSTD_DCtx_getParameter+0x60): undefined reference to `__clzdi2'
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [RFC PATCH 8/8] media: v4l2-mediabus: Drop V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag
From: Sakari Ailus @ 2022-01-05 19:02 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-media, linux-renesas-soc, Hans Verkuil, Kieran Bingham,
Jacopo Mondi, Niklas Söderlund, Tomi Valkeinen,
Janusz Krzysztofik, Lars-Peter Clausen, Mats Randgaard
In-Reply-To: <20220103162414.27723-9-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent,
On Mon, Jan 03, 2022 at 06:24:14PM +0200, Laurent Pinchart wrote:
> MIPI CSI-2 continuous and non-continuous clock modes are mutually
> exclusive. Drop the V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag and use
> V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK only.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/media/i2c/adv7180.c | 3 +--
> drivers/media/i2c/tc358743.c | 6 +++---
> drivers/media/v4l2-core/v4l2-fwnode.c | 4 +---
> include/media/v4l2-mediabus.h | 3 +--
> 4 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 3ff37a550810..4f5db195e66d 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -785,8 +785,7 @@ static int adv7180_get_mbus_config(struct v4l2_subdev *sd,
> if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
> cfg->type = V4L2_MBUS_CSI2_DPHY;
> cfg->bus.mipi_csi2.num_data_lanes = 1;
> - cfg->bus.mipi_csi2.flags =
> - V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
> + cfg->bus.mipi_csi2.flags = 0;
> } else {
> /*
> * The ADV7180 sensor supports BT.601/656 output modes.
> diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
> index dfbc42675143..e18b8947ad7e 100644
> --- a/drivers/media/i2c/tc358743.c
> +++ b/drivers/media/i2c/tc358743.c
> @@ -717,7 +717,7 @@ static void tc358743_set_csi(struct v4l2_subdev *sd)
> ((lanes > 3) ? MASK_D3M_HSTXVREGEN : 0x0));
>
> i2c_wr32(sd, TXOPTIONCNTRL, (state->bus.flags &
> - V4L2_MBUS_CSI2_CONTINUOUS_CLOCK) ? MASK_CONTCLKMODE : 0);
> + V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK) ? 0 : MASK_CONTCLKMODE);
> i2c_wr32(sd, STARTCNTRL, MASK_START);
> i2c_wr32(sd, CSI_START, MASK_STRT);
>
> @@ -1613,7 +1613,7 @@ static int tc358743_get_mbus_config(struct v4l2_subdev *sd,
> cfg->type = V4L2_MBUS_CSI2_DPHY;
>
> /* Support for non-continuous CSI-2 clock is missing in the driver */
> - cfg->bus.mipi_csi2.flags = V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
> + cfg->bus.mipi_csi2.flags = 0;
> cfg->bus.mipi_csi2.num_data_lanes = state->csi_lanes_in_use;
>
> return 0;
> @@ -2039,7 +2039,7 @@ static int tc358743_probe(struct i2c_client *client)
> /* platform data */
> if (pdata) {
> state->pdata = *pdata;
> - state->bus.flags = V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
> + state->bus.flags = 0;
> } else {
> err = tc358743_probe_of(state);
> if (err == -ENODEV)
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c
> index 9ff3ebb230e7..9aad860cde6c 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -207,13 +207,11 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct fwnode_handle *fwnode,
> if (fwnode_property_present(fwnode, "clock-noncontinuous")) {
> flags |= V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK;
> pr_debug("non-continuous clock\n");
> - } else {
> - flags |= V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
> }
>
> if (bus_type == V4L2_MBUS_CSI2_DPHY ||
> bus_type == V4L2_MBUS_CSI2_CPHY || lanes_used ||
> - have_clk_lane || (flags & ~V4L2_MBUS_CSI2_CONTINUOUS_CLOCK)) {
> + have_clk_lane || (flags & V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK)) {
This should be just plains flags (i.e. without bitwise and) as we're just
figuring out whether any properties related to CSI-2 were found.
> /* Only D-PHY has a clock lane. */
> unsigned int dfl_data_lane_index =
> bus_type == V4L2_MBUS_CSI2_DPHY;
> diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
> index c6626a22b394..e0db3bcff9ed 100644
> --- a/include/media/v4l2-mediabus.h
> +++ b/include/media/v4l2-mediabus.h
> @@ -68,8 +68,7 @@
>
> /* Serial flags */
> /* Clock non-continuous mode support. */
> -#define V4L2_MBUS_CSI2_CONTINUOUS_CLOCK BIT(8)
> -#define V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK BIT(9)
> +#define V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK BIT(0)
>
> #define V4L2_MBUS_CSI2_MAX_DATA_LANES 8
>
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* [Buildroot] Overriding Kconfig Values from external br2
From: Jesse Millwood @ 2022-01-05 19:03 UTC (permalink / raw)
To: buildroot
[-- Attachment #1.1: Type: text/plain, Size: 3846 bytes --]
Hello,
I have an external C/C++ toolchain that I've put together that uses MUSL. I've also built an external Rust toolchain that uses my MUSL toolchain.
My issue is that there is a Rust Kconfig variable that specifies if a specific architecture supports Rust.
The Kconfig variable in question is BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS in package/rustc/Config.in.host.
In my br2 external project I have the following setup:
My issue is that I can't seem to override the BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS, which masks all other Rust packages.
.
├── external.desc
│ |name: MINE
│ |desc: My BR2 External
│ `----
├── external.mk
│ |include $(sort $(wildcard $(BR2_EXTERNAL_MINE_PATH)/package/*/*.mk))
│ |include $(sort $(wildcard $(BR2_EXTERNAL_MINE_PATH)/toolchain/*/*.mk))
│ `----
├── Config.in
│ | source "$BR2_EXTERNAL_MINE_PATH/toolchain/my-external/Config.in.options"
│ | source "$BR2_EXTERNAL_MINE_PATH/package/rpkg/Config.in"
│ `----
├── configs
│ ├── my_gnu_defconfig
│ └── my_musl_defconfig
|
├── package
│ └── rpkg
│ ├── Config.in
│ └── rpkg.mk
├── provides
│ └── toolchains.in
│ | config BR2_TOOLCHAIN_EXTERNAL_MY_MUSL
│ | bool "My PowerPC MUSL Toolchain"
│ | depends on BR2_powerpc
│ |
│ | config BR2_TOOLCHAIN_EXTERNAL_MY_GNU
│ | bool "My PowerPC GNU Toolchain"
│ | depends on BR2_powerpc
│ `----
└── toolchain
└── my-external
└── Config.in.options
| if BR2_TOOLCHAIN_EXTERNAL_MY_MUSL
| config BR2_TOOLCHAIN_EXTERNAL_PREFIX
| default "powerpc-my-linux-musl"
| config BR2_TOOLCHAIN_EXTERNAL_PATH
| default "${WORKSPACE_DIR}/toolchain/powerpc-my-linux-musl"
|
| config BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS
| bool
| default y if BR2_i386
| default y if BR2_x86_64
| default y if BR2_aarch64
| default y if BR2_arm && !BR2_ARM_CPU_ARMV4 && !BR2_ARM_CPU_ARMV5 \
| && !(BR2_ARM_CPU_ARMV7A && BR2_ARM_EABI)
| default y if BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le
| default y if (BR2_mips || BR2_mipsel) && !BR2_MIPS_CPU_MIPS32R6
| default y if (BR2_mips64 || BR2_mips64el) && !BR2_MIPS_CPU_MIPS64R6 \
| && BR2_MIPS_NABI64
| depends on (BR2_TOOLCHAIN_USES_GLIBC || BR2_TOOLCHAIN_USES_MUSL)
| depends on BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS
|
| endif
|
| if BR2_TOOLCHAIN_EXTERNAL_MY_GNU
| config BR2_TOOLCHAIN_EXTERNAL_PREFIX
| default "powerpc-my-linux-gnu"
| config BR2_TOOLCHAIN_EXTERNAL_PATH
| default "${WORKSPACE_DIR}/toolchain/powerpc-my-linux-gnu"
| endif
`----
You may notice that I changed the libc depends line to be or'd with BR2_TOOLCHAIN_USES_MUSL. It seems that this does not get considered when I choose my external musl toolchain option. In the menuconfig when I search for the BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS variable with the "/" key it looks like it is only getting it from the original file. Does buildroot have a mechanism for overwriting this kind of setting and if not, does anyone have an idea of how I would accomplish what I am trying to do (make buildroot honor my external rust toolchain)?
Thanks,
Jesse
[-- Attachment #1.2: Type: text/html, Size: 12130 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply
* Re: [PATCH v5 3/6] PCI: imx6: PCI: imx6: Move imx6_pcie_clk_disable() earlier
From: Bjorn Helgaas @ 2022-01-05 19:04 UTC (permalink / raw)
To: Richard Zhu
Cc: l.stach, bhelgaas, broonie, lorenzo.pieralisi, jingoohan1,
festevam, stable, linux-pci, linux-imx, linux-arm-kernel,
linux-kernel, kernel
In-Reply-To: <1641368602-20401-4-git-send-email-hongxing.zhu@nxp.com>
Remove repeated words from subject line.
On Wed, Jan 05, 2022 at 03:43:19PM +0800, Richard Zhu wrote:
> Just move the imx6_pcie_clk_disable() to an earlier place without function
> changes, since it wouldn't be only used in imx6_pcie_suspend_noirq() later.
^ permalink raw reply
* nvme-tcp: io queue shutdown ordering
From: Jonathan Nicklin @ 2022-01-05 19:03 UTC (permalink / raw)
To: linux-nvme
When disconnecting an nvme-tcp device using nvme cli (i.e., nvme
disconnect), nvme_tcp_teardown_ctrl() destroys I/O queues before
issuing the shutdown notification on the admin queue.
According to the fabrics spec version 1.1a section 1.5.2, an
association is terminated if an NVMe Transport connection is lost
between the host and controller for any I/O Queue when the host or
controller does not support individual I/O Queue deletion.
The initiator in mainline does not advertise support for I/O queue
deletion in the fabrics connect attributes (i.e., bit 3). Therefore,
termination of the association in response to connection loss of an
I/O queue should terminate the admin queue connection. This could
result in an inability to process the shutdown notification, causing a
disconnect request to hang until a timeout occurs.
Is this possibly a bug or my misunderstanding of the spec?
Thanks,
-Jonathan
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] Cleanup to main DSA structures
From: Florian Fainelli @ 2022-01-05 19:04 UTC (permalink / raw)
To: Vladimir Oltean
Cc: netdev@vger.kernel.org, David S. Miller, Jakub Kicinski,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20220105185901.hprorcjw6api4bwc@skbuf>
On 1/5/22 10:59 AM, Vladimir Oltean wrote:
> On Wed, Jan 05, 2022 at 10:39:04AM -0800, Florian Fainelli wrote:
>> On 1/5/22 5:21 AM, Vladimir Oltean wrote:
>>> This series contains changes that do the following:
>>>
>>> - struct dsa_port reduced from 576 to 544 bytes, and first cache line a
>>> bit better organized
>>> - struct dsa_switch from 160 to 136 bytes, and first cache line a bit
>>> better organized
>>> - struct dsa_switch_tree from 112 to 104 bytes, and first cache line a
>>> bit better organized
>>>
>>> No changes compared to v1, just split into a separate patch set.
>>
>> This is all looking good to me. I suppose we could possibly swap the
>> 'nh' and 'tag_ops' member since dst->tag_ops is used in
>> dsa_tag_generic_flow_dissect() which is a fast path, what do you think?
>
> pahole is telling me that dst->tag_ops is in the first cache line on
> both arm64 and arm32. Are you saying that it's better for it to take
> dst->nh's place?
Sorry it stuck in my head somehow based upon patch 7's pahole output
that tag_ops was still in the second cache line when the after clearly
shows that it moved to the first cache line. No need to add additional
changes then, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH v5 4/4] KVM: mmu: remove over-aggressive warnings
From: Sean Christopherson @ 2022-01-05 19:02 UTC (permalink / raw)
To: David Stevens
Cc: Marc Zyngier, Paolo Bonzini, James Morse, Alexandru Elisei,
Suzuki K Poulose, Will Deacon, Wanpeng Li, Jim Mattson,
Joerg Roedel, linux-arm-kernel, kvmarm, linux-kernel, kvm
In-Reply-To: <CAD=HUj5Q6rW8UyxAXUa3o93T0LBqGQb7ScPj07kvuM3txHMMrQ@mail.gmail.com>
On Wed, Jan 05, 2022, David Stevens wrote:
> On Fri, Dec 31, 2021 at 4:22 AM Sean Christopherson <seanjc@google.com> wrote:
> > > */
> > > - if (!pfn_valid(pfn) || WARN_ON_ONCE(!page_count(pfn_to_page(pfn))))
> > > + if (!pfn_valid(pfn) || !page_count(pfn_to_page(pfn)))
> >
> > Hrm, I know the whole point of this series is to support pages without an elevated
> > refcount, but this WARN was extremely helpful in catching several use-after-free
> > bugs in the TDP MMU. We talked about burying a slow check behind MMU_WARN_ON, but
> > that isn't very helpful because no one runs with MMU_WARN_ON, and this is also a
> > type of check that's most useful if it runs in production.
> >
> > IIUC, this series explicitly disallows using pfns that have a struct page without
> > refcounting, and the issue with the WARN here is that kvm_is_zone_device_pfn() is
> > called by kvm_is_reserved_pfn() before ensure_pfn_ref() rejects problematic pages,
> > i.e. triggers false positive.
> >
> > So, can't we preserve the use-after-free benefits of the check by moving it to
> > where KVM releases the PFN? I.e.
> >
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index fbca2e232e94..675b835525fa 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -2904,15 +2904,19 @@ EXPORT_SYMBOL_GPL(kvm_release_pfn_dirty);
> >
> > void kvm_set_pfn_dirty(kvm_pfn_t pfn)
> > {
> > - if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn))
> > + if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn)) {
> > + WARN_ON_ONCE(!page_count(pfn_to_page(pfn)));
> > SetPageDirty(pfn_to_page(pfn));
> > + }
> > }
> > EXPORT_SYMBOL_GPL(kvm_set_pfn_dirty);
>
> I'm still seeing this warning show up via __handle_changed_spte
> calling kvm_set_pfn_dirty:
>
> [ 113.350473] kvm_set_pfn_dirty+0x26/0x3e
> [ 113.354861] __handle_changed_spte+0x452/0x4f6
> [ 113.359841] __handle_changed_spte+0x452/0x4f6
> [ 113.364819] __handle_changed_spte+0x452/0x4f6
> [ 113.369790] zap_gfn_range+0x1de/0x27a
> [ 113.373992] kvm_tdp_mmu_zap_invalidated_roots+0x64/0xb8
> [ 113.379945] kvm_mmu_zap_all_fast+0x18c/0x1c1
> [ 113.384827] kvm_page_track_flush_slot+0x55/0x87
> [ 113.390000] kvm_set_memslot+0x137/0x455
> [ 113.394394] kvm_delete_memslot+0x5c/0x91
> [ 113.398888] __kvm_set_memory_region+0x3c0/0x5e6
> [ 113.404061] kvm_set_memory_region+0x45/0x74
> [ 113.408844] kvm_vm_ioctl+0x563/0x60c
>
> I wasn't seeing it for my particular test case, but the gfn aging code
> might trigger the warning as well.
Ah, I got royally confused by ensure_pfn_ref()'s comment
* Certain IO or PFNMAP mappings can be backed with valid
* struct pages, but be allocated without refcounting e.g.,
* tail pages of non-compound higher order allocations, which
* would then underflow the refcount when the caller does the
* required put_page. Don't allow those pages here.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that doesn't apply here because kvm_faultin_pfn() uses the low level
__gfn_to_pfn_page_memslot().
and my understanding is that @page will be non-NULL in ensure_pfn_ref() iff the
page has an elevated refcount.
Can you update the changelogs for the x86+arm64 "use gfn_to_pfn_page" patches to
explicitly call out the various ramifications of moving to gfn_to_pfn_page()?
Side topic, s/covert/convert in both changelogs :-)
> I don't know if setting the dirty/accessed bits in non-refcounted
> struct pages is problematic.
Without knowing exactly what lies behind such pages, KVM needs to set dirty bits,
otherwise there's a potential for data lost.
> The only way I can see to avoid it would be to try to map from the spte to
> the vma and then check its flags. If setting the flags is benign, then we'd
> need to do that lookup to differentiate the safe case from the use-after-free
> case. Do you have any advice on how to handle this?
Hrm. I can't think of a clever generic solution. But for x86-64, we can use a
software available bit to mark SPTEs as being refcounted use that flag to assert
the refcount is elevated when marking the backing pfn dirty/accessed. It'd be
64-bit only because we're out of software available bits for PAE paging, but (a)
practically no one cares about 32-bit and (b) odds are slim that a use-after-free
would be unique to 32-bit KVM.
But that can all go in after your series is merged, e.g. I'd prefer to cleanup
make_spte()'s prototype to use @fault adding yet another parameter, and that'll
take a few patches to make happen since FNAME(sync_page) also uses make_spte().
TL;DR: continue as you were, I'll stop whining about this :-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 3/6] PCI: imx6: PCI: imx6: Move imx6_pcie_clk_disable() earlier
From: Bjorn Helgaas @ 2022-01-05 19:04 UTC (permalink / raw)
To: Richard Zhu
Cc: l.stach, bhelgaas, broonie, lorenzo.pieralisi, jingoohan1,
festevam, stable, linux-pci, linux-imx, linux-arm-kernel,
linux-kernel, kernel
In-Reply-To: <1641368602-20401-4-git-send-email-hongxing.zhu@nxp.com>
Remove repeated words from subject line.
On Wed, Jan 05, 2022 at 03:43:19PM +0800, Richard Zhu wrote:
> Just move the imx6_pcie_clk_disable() to an earlier place without function
> changes, since it wouldn't be only used in imx6_pcie_suspend_noirq() later.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for tests/i915/userptr: fix mapping type
From: Patchwork @ 2022-01-05 19:05 UTC (permalink / raw)
To: Matthew Auld; +Cc: igt-dev
In-Reply-To: <20220105172106.154217-1-matthew.auld@intel.com>
[-- Attachment #1: Type: text/plain, Size: 8456 bytes --]
== Series Details ==
Series: tests/i915/userptr: fix mapping type
URL : https://patchwork.freedesktop.org/series/98511/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11049 -> IGTPW_6539
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/index.html
Participating hosts (44 -> 37)
------------------------------
Additional (2): fi-kbl-soraka fi-icl-u2
Missing (9): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 fi-pnv-d510 bat-rpls-1 fi-bdw-samus bat-jsl-2 bat-jsl-1
Known issues
------------
Here are the changes found in IGTPW_6539 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@amdgpu/amd_cs_nop@fork-gfx0.html
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271]) +18 similar issues
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-skl-6600u/igt@amdgpu/amd_cs_nop@sync-fork-gfx0.html
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +25 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@gem_exec_fence@basic-busy@bcs0.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html
- fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#2190])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@gem_lmem_swapping@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@gem_lmem_swapping@parallel-random-engines.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick: [PASS][8] -> [INCOMPLETE][9] ([i915#2940])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-bsw-nick/igt@i915_selftest@live@execlists.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-nick/igt@i915_selftest@live@execlists.html
- fi-bsw-kefka: [PASS][10] -> [INCOMPLETE][11] ([i915#2940])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-bsw-kefka/igt@i915_selftest@live@execlists.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-kefka/igt@i915_selftest@live@execlists.html
- fi-bsw-n3050: [PASS][12] -> [INCOMPLETE][13] ([i915#2940])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-bsw-n3050/igt@i915_selftest@live@execlists.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-n3050/igt@i915_selftest@live@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][14] ([i915#1886] / [i915#2291])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][16] ([fdo#111827]) +8 similar issues
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: NOTRUN -> [SKIP][19] ([fdo#109278]) +2 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][20] ([fdo#109285])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@kms_force_connector_basic@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#533])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][22] ([i915#3301])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@prime_vgem@basic-userptr.html
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN -> [FAIL][23] ([fdo#109271] / [i915#1436] / [i915#2722] / [i915#3428] / [i915#4312])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-kefka/igt@runner@aborted.html
- fi-bsw-nick: NOTRUN -> [FAIL][24] ([fdo#109271] / [i915#1436] / [i915#2722] / [i915#3428] / [i915#4312])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-nick/igt@runner@aborted.html
#### Possible fixes ####
* igt@i915_pm_rpm@module-reload:
- {fi-tgl-dsi}: [DMESG-WARN][25] ([i915#1982] / [i915#2411]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-tgl-dsi/igt@i915_pm_rpm@module-reload.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-tgl-dsi/igt@i915_pm_rpm@module-reload.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: [FAIL][27] ([i915#4547]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_6323 -> IGTPW_6539
CI-20190529: 20190529
CI_DRM_11049: 3d3993f1fe1bb5ca43cd787b753db177cd9d48ab @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_6539: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/index.html
IGT_6323: 9dbaa0d5be7a859cda9b7d54c20ba96a596f43bd @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/index.html
[-- Attachment #2: Type: text/html, Size: 10696 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.