stable-rc/linux-3.18.y build: 183 builds: 0 failed, 183 passed, 291 warnings (v3.18.125-89-g968849030780)
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.125-8…
Tree: stable-rc
Branch: linux-3.18.y
Git Describe: v3.18.125-89-g968849030780
Git Commit: 96884903078008c1d796add463633bb1337fed53
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 4 unique architectures
Warnings Detected:
arm64: gcc version 7.3.0 (Debian 7.3.0-28)
allnoconfig: 2 warnings
defconfig: 2 warnings
tinyconfig: 2 warnings
arm: gcc version 7.3.0 (Debian 7.3.0-28)
acs5k_defconfig: 2 warnings
acs5k_tiny_defconfig: 2 warnings
allnoconfig: 2 warnings
am200epdkit_defconfig: 2 warnings
ape6evm_defconfig: 2 warnings
armadillo800eva_defconfig: 2 warnings
assabet_defconfig: 2 warnings
at91_dt_defconfig: 2 warnings
at91rm9200_defconfig: 2 warnings
at91sam9260_9g20_defconfig: 2 warnings
at91sam9261_9g10_defconfig: 2 warnings
at91sam9263_defconfig: 2 warnings
at91sam9g45_defconfig: 2 warnings
at91sam9rl_defconfig: 2 warnings
at91x40_defconfig: 2 warnings
axm55xx_defconfig: 2 warnings
badge4_defconfig: 2 warnings
bcm2835_defconfig: 2 warnings
bcm_defconfig: 2 warnings
bockw_defconfig: 2 warnings
cerfcube_defconfig: 2 warnings
clps711x_defconfig: 2 warnings
cm_x2xx_defconfig: 2 warnings
cm_x300_defconfig: 2 warnings
cns3420vb_defconfig: 2 warnings
colibri_pxa270_defconfig: 2 warnings
colibri_pxa300_defconfig: 2 warnings
collie_defconfig: 2 warnings
corgi_defconfig: 2 warnings
davinci_all_defconfig: 2 warnings
dove_defconfig: 2 warnings
ebsa110_defconfig: 2 warnings
efm32_defconfig: 2 warnings
em_x270_defconfig: 2 warnings
ep93xx_defconfig: 2 warnings
eseries_pxa_defconfig: 2 warnings
exynos_defconfig: 2 warnings
ezx_defconfig: 2 warnings
footbridge_defconfig: 2 warnings
h3600_defconfig: 2 warnings
h5000_defconfig: 2 warnings
hackkit_defconfig: 2 warnings
hisi_defconfig: 2 warnings
imote2_defconfig: 2 warnings
imx_v4_v5_defconfig: 2 warnings
imx_v6_v7_defconfig: 2 warnings
integrator_defconfig: 2 warnings
iop13xx_defconfig: 2 warnings
iop32x_defconfig: 2 warnings
iop33x_defconfig: 2 warnings
ixp4xx_defconfig: 2 warnings
jornada720_defconfig: 2 warnings
keystone_defconfig: 2 warnings
koelsch_defconfig: 2 warnings
ks8695_defconfig: 2 warnings
kzm9g_defconfig: 2 warnings
lager_defconfig: 2 warnings
lart_defconfig: 2 warnings
lpc32xx_defconfig: 2 warnings
lpd270_defconfig: 2 warnings
lubbock_defconfig: 2 warnings
mackerel_defconfig: 2 warnings
magician_defconfig: 2 warnings
mainstone_defconfig: 2 warnings
marzen_defconfig: 2 warnings
mini2440_defconfig: 2 warnings
mmp2_defconfig: 2 warnings
moxart_defconfig: 2 warnings
msm_defconfig: 2 warnings
multi_v5_defconfig: 2 warnings
multi_v7_defconfig: 2 warnings
mv78xx0_defconfig: 2 warnings
mvebu_v5_defconfig: 2 warnings
mvebu_v7_defconfig: 2 warnings
mxs_defconfig: 2 warnings
neponset_defconfig: 2 warnings
netwinder_defconfig: 2 warnings
netx_defconfig: 2 warnings
nhk8815_defconfig: 2 warnings
nuc910_defconfig: 2 warnings
nuc950_defconfig: 2 warnings
nuc960_defconfig: 2 warnings
omap1_defconfig: 2 warnings
omap2plus_defconfig: 2 warnings
orion5x_defconfig: 2 warnings
palmz72_defconfig: 2 warnings
pcm027_defconfig: 2 warnings
pleb_defconfig: 2 warnings
prima2_defconfig: 2 warnings
pxa168_defconfig: 2 warnings
pxa255-idp_defconfig: 2 warnings
pxa3xx_defconfig: 2 warnings
pxa910_defconfig: 2 warnings
qcom_defconfig: 2 warnings
raumfeld_defconfig: 2 warnings
realview-smp_defconfig: 2 warnings
realview_defconfig: 2 warnings
rpc_defconfig: 2 warnings
s3c2410_defconfig: 2 warnings
s3c6400_defconfig: 2 warnings
s5pv210_defconfig: 2 warnings
sama5_defconfig: 2 warnings
shannon_defconfig: 2 warnings
shmobile_defconfig: 2 warnings
simpad_defconfig: 2 warnings
socfpga_defconfig: 2 warnings
spear13xx_defconfig: 2 warnings
spear3xx_defconfig: 2 warnings
spear6xx_defconfig: 2 warnings
spitz_defconfig: 2 warnings
sunxi_defconfig: 2 warnings
tct_hammer_defconfig: 2 warnings
tegra_defconfig: 2 warnings
tinyconfig: 2 warnings
trizeps4_defconfig: 2 warnings
u300_defconfig: 2 warnings
u8500_defconfig: 2 warnings
versatile_defconfig: 2 warnings
vexpress_defconfig: 2 warnings
viper_defconfig: 2 warnings
vt8500_v6_v7_defconfig: 2 warnings
xcep_defconfig: 2 warnings
zeus_defconfig: 2 warnings
x86: gcc version 7.3.0 (Debian 7.3.0-29)
allnoconfig: 3 warnings
i386_defconfig: 3 warnings
tinyconfig: 3 warnings
x86_64_defconfig: 30 warnings
Warnings summary:
126 scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
126 scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
3 arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
2 include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
1 net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
1 lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
1 kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
1 drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
1 block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
1 block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ape6evm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
armadillo800eva_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
assabet_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91_dt_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91rm9200_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9260_9g20_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9261_9g10_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9263_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9g45_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9rl_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91x40_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ath79_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
badge4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm2835_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bigsur_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bockw_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
capcella_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
clps711x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cns3420vb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cobalt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
collie_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
corgi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
davinci_all_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
db1xxx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
dove_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
e55_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
efm32_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
em_x270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ep93xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
exynos_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ezx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
footbridge_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
h5000_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hackkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hisi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
i386_defconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
imote2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
integrator_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop32x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop33x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ip22_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
jazz_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
keystone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
koelsch_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ks8695_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
kzm9g_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lager_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lasat_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lpd270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ls1b_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mackerel_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
magician_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mainstone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
malta_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
marzen_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mini2440_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
moxart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mpc30x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
msp71xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mv78xx0_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mxs_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
neponset_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netwinder_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nhk8815_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc950_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc960_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap1_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap2plus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
orion5x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
palmz72_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pcm027_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pleb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa168_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qcom_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rb532_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview-smp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
realview_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rm200_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rt305x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s3c6400_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s5pv210_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sama5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3micro_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
shmobile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
simpad_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
socfpga_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear6xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spitz_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sunxi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tb0219_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tegra_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
tinyconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
trizeps4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u8500_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
versatile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vexpress_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
viper_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
workpad_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86) — PASS, 0 errors, 30 warnings, 0 section mismatches
Warnings:
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
--------------------------------------------------------------------------------
xcep_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
xway_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
---
For more info write to <info(a)kernelci.org>
CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on some newer F17h
procssors but their revision guide has not been released.
For example,Tesed on AMD "Ryzen 7 2700U with Radeon Vega Mobile Gfx"
and "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx",
their CPUID Fn0000_0001_EAX is 0x00810f10 and should have
CPB feature according AMD product specifications, however
their Fn8000_0007_EDX is 0x00006599, indicating they don't
support CPB feature.
Since whole F17h should support CPB, we set the cap for all of
them.
Cc: stable(a)vger.kernel.org
Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com>
---
arch/x86/kernel/cpu/amd.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index eeea634bee0a..37989fa9e620 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -818,12 +818,13 @@ static void init_amd_bd(struct cpuinfo_x86 *c)
static void init_amd_zn(struct cpuinfo_x86 *c)
{
set_cpu_cap(c, X86_FEATURE_ZEN);
+
/*
* Fix erratum 1076: CPB feature bit not being set in CPUID. It affects
- * all up to and including B1.
+ * a lot of Family 17h processors and some models are undocumented, since
+ * whole F17h should support CPB, we set the cap for all of them.
*/
- if (c->x86_model <= 1 && c->x86_stepping <= 1)
- set_cpu_cap(c, X86_FEATURE_CPB);
+ set_cpu_cap(c, X86_FEATURE_CPB);
}
static void init_amd(struct cpuinfo_x86 *c)
--
2.19.1
Commit 93bba24d4b5ad1e5cd8b43f64e66ff9d6355dd20 upstream.
Function btrfs_trim_fs() doesn't handle errors in a consistent way. If
error happens when trimming existing block groups, it will skip the
remaining blocks and continue to trim unallocated space for each device.
The return value will only reflect the final error from device trimming.
This patch will fix such behavior by:
1) Recording the last error from block group or device trimming
The return value will also reflect the last error during trimming.
Make developer more aware of the problem.
2) Continuing trimming if possible
If we failed to trim one block group or device, we could still try
the next block group or device.
3) Report number of failures during block group and device trimming
It would be less noisy, but still gives user a brief summary of
what's going wrong.
Such behavior can avoid confusion for cases like failure to trim the
first block group and then only unallocated space is trimmed.
Reported-by: Chris Murphy <lists(a)colorremedies.com>
CC: stable(a)vger.kernel.org # 4.9
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ add bg_ret and dev_ret to the messages ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
---
fs/btrfs/extent-tree.c | 40 +++++++++++++++++++++++++++++-----------
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 6661116c47d9..4f28fef9dc7f 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -11124,6 +11124,10 @@ int btrfs_trim_fs(struct btrfs_root *root, struct fstrim_range *range)
u64 end;
u64 trimmed = 0;
u64 total_bytes = btrfs_super_total_bytes(fs_info->super_copy);
+ u64 bg_failed = 0;
+ u64 dev_failed = 0;
+ int bg_ret = 0;
+ int dev_ret = 0;
int ret = 0;
/*
@@ -11134,7 +11138,7 @@ int btrfs_trim_fs(struct btrfs_root *root, struct fstrim_range *range)
else
cache = btrfs_lookup_block_group(fs_info, range->start);
- while (cache) {
+ for (; cache; cache = next_block_group(fs_info->tree_root, cache)) {
if (cache->key.objectid >= (range->start + range->len)) {
btrfs_put_block_group(cache);
break;
@@ -11148,13 +11152,15 @@ int btrfs_trim_fs(struct btrfs_root *root, struct fstrim_range *range)
if (!block_group_cache_done(cache)) {
ret = cache_block_group(cache, 0);
if (ret) {
- btrfs_put_block_group(cache);
- break;
+ bg_failed++;
+ bg_ret = ret;
+ continue;
}
ret = wait_block_group_cache_done(cache);
if (ret) {
- btrfs_put_block_group(cache);
- break;
+ bg_failed++;
+ bg_ret = ret;
+ continue;
}
}
ret = btrfs_trim_block_group(cache,
@@ -11165,28 +11171,40 @@ int btrfs_trim_fs(struct btrfs_root *root, struct fstrim_range *range)
trimmed += group_trimmed;
if (ret) {
- btrfs_put_block_group(cache);
- break;
+ bg_failed++;
+ bg_ret = ret;
+ continue;
}
}
-
- cache = next_block_group(fs_info->tree_root, cache);
}
+ if (bg_failed)
+ btrfs_warn(fs_info,
+ "failed to trim %llu block group(s), last error %d",
+ bg_failed, bg_ret);
mutex_lock(&root->fs_info->fs_devices->device_list_mutex);
devices = &root->fs_info->fs_devices->alloc_list;
list_for_each_entry(device, devices, dev_alloc_list) {
ret = btrfs_trim_free_extents(device, range->minlen,
&group_trimmed);
- if (ret)
+ if (ret) {
+ dev_failed++;
+ dev_ret = ret;
break;
+ }
trimmed += group_trimmed;
}
mutex_unlock(&root->fs_info->fs_devices->device_list_mutex);
+ if (dev_failed)
+ btrfs_warn(fs_info,
+ "failed to trim %llu device(s), last error %d",
+ dev_failed, dev_ret);
range->len = trimmed;
- return ret;
+ if (bg_ret)
+ return bg_ret;
+ return dev_ret;
}
/*
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.
We now have the option to specify the GPIO base manually for davinci,
so add the relevant fields to platform data.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/da850.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4528bbf0c861..e7b78df2bfef 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -719,7 +719,9 @@ int __init da850_register_vpif_capture(struct vpif_capture_config
}
static struct davinci_gpio_platform_data da850_gpio_platform_data = {
- .ngpio = 144,
+ .no_auto_base = true,
+ .base = 0,
+ .ngpio = 144,
};
int __init da850_register_gpio(void)
--
2.19.1
From: Larry Finger <Larry.Finger(a)lwfinger.net>
The cordic routine for calculating sines and cosines that was added in
commit 6f98e62a9f1b ("b43: update cordic code to match current specs")
contains an error whereby a quantity declared u32 can in fact go negative.
This problem was detected by Priit Laes who is switching b43 to use the
routine in the library functions of the kernel.
Fixes: 986504540306 ("b43: make cordic common (LP-PHY and N-PHY need it)")
Reported-by: Priit Laes <plaes(a)plaes.org>
Cc: Rafał Miłecki <zajec5(a)gmail.com>
Cc: Stable <stable(a)vger.kernel.org> # 2.6.34
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Signed-off-by: Priit Laes <plaes(a)plaes.org>
---
drivers/net/wireless/broadcom/b43/phy_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/b43/phy_common.c b/drivers/net/wireless/broadcom/b43/phy_common.c
index 85f2ca9..ef3ffa5 100644
--- a/drivers/net/wireless/broadcom/b43/phy_common.c
+++ b/drivers/net/wireless/broadcom/b43/phy_common.c
@@ -616,7 +616,7 @@ struct b43_c32 b43_cordic(int theta)
u8 i;
s32 tmp;
s8 signx = 1;
- u32 angle = 0;
+ s32 angle = 0;
struct b43_c32 ret = { .i = 39797, .q = 0, };
while (theta > (180 << 16))
--
git-series 0.9.1
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From ceadddde8875bda7af3824244de3d93e386d08c1 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Mon, 8 Oct 2018 12:57:34 +0200
Subject: [PATCH] mach64: detect the dot clock divider correctly on sparc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Sun Ultra 5, it happens that the dot clock is not set up properly for
some videomodes. For example, if we set the videomode "r1024x768x60" in
the firmware, Linux would incorrectly set a videomode with refresh rate
180Hz when booting (suprisingly, my LCD monitor can display it, although
display quality is very low).
The reason is this: Older mach64 cards set the divider in the register
VCLK_POST_DIV. The register has four 2-bit fields (the field that is
actually used is specified in the lowest two bits of the register
CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards,
there's another bit added - the top four bits of PLL_EXT_CNTL extend the
divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12".
The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets
them, so it can work regardless if the card supports them. However, the
sparc64 firmware may set these extended dividers during boot - and the
mach64 driver detects incorrect dot clock in this case.
This patch makes the driver read the additional divider bit from
PLL_EXT_CNTL and calculate the initial refresh rate properly.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Acked-by: David S. Miller <davem(a)davemloft.net>
Reviewed-by: Ville Syrjälä <syrjala(a)sci.fi>
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 8235b285dbb2..d09bab3bf224 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -333,6 +333,8 @@ extern const struct aty_pll_ops aty_pll_ct; /* Integrated */
extern void aty_set_pll_ct(const struct fb_info *info, const union aty_pll *pll);
extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
+extern const u8 aty_postdividers[8];
+
/*
* Hardware cursor support
@@ -359,7 +361,6 @@ static inline void wait_for_idle(struct atyfb_par *par)
extern void aty_reset_engine(const struct atyfb_par *par);
extern void aty_init_engine(struct atyfb_par *par, struct fb_info *info);
-extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
void atyfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);
void atyfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c
index a9a8272f7a6e..05111e90f168 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3087,17 +3087,18 @@ static int atyfb_setup_sparc(struct pci_dev *pdev, struct fb_info *info,
/*
* PLL Reference Divider M:
*/
- M = pll_regs[2];
+ M = pll_regs[PLL_REF_DIV];
/*
* PLL Feedback Divider N (Dependent on CLOCK_CNTL):
*/
- N = pll_regs[7 + (clock_cntl & 3)];
+ N = pll_regs[VCLK0_FB_DIV + (clock_cntl & 3)];
/*
* PLL Post Divider P (Dependent on CLOCK_CNTL):
*/
- P = 1 << (pll_regs[6] >> ((clock_cntl & 3) << 1));
+ P = aty_postdividers[((pll_regs[VCLK_POST_DIV] >> ((clock_cntl & 3) << 1)) & 3) |
+ ((pll_regs[PLL_EXT_CNTL] >> (2 + (clock_cntl & 3))) & 4)];
/*
* PLL Divider Q:
diff --git a/drivers/video/fbdev/aty/mach64_ct.c b/drivers/video/fbdev/aty/mach64_ct.c
index 74a62aa193c0..f87cc81f4fa2 100644
--- a/drivers/video/fbdev/aty/mach64_ct.c
+++ b/drivers/video/fbdev/aty/mach64_ct.c
@@ -115,7 +115,7 @@ static void aty_st_pll_ct(int offset, u8 val, const struct atyfb_par *par)
*/
#define Maximum_DSP_PRECISION 7
-static u8 postdividers[] = {1,2,4,8,3};
+const u8 aty_postdividers[8] = {1,2,4,8,3,5,6,12};
static int aty_dsp_gt(const struct fb_info *info, u32 bpp, struct pll_ct *pll)
{
@@ -222,7 +222,7 @@ static int aty_valid_pll_ct(const struct fb_info *info, u32 vclk_per, struct pll
pll->vclk_post_div += (q < 64*8);
pll->vclk_post_div += (q < 32*8);
}
- pll->vclk_post_div_real = postdividers[pll->vclk_post_div];
+ pll->vclk_post_div_real = aty_postdividers[pll->vclk_post_div];
// pll->vclk_post_div <<= 6;
pll->vclk_fb_div = q * pll->vclk_post_div_real / 8;
pllvclk = (1000000 * 2 * pll->vclk_fb_div) /
@@ -513,7 +513,7 @@ static int aty_init_pll_ct(const struct fb_info *info, union aty_pll *pll)
u8 mclk_fb_div, pll_ext_cntl;
pll->ct.pll_ref_div = aty_ld_pll_ct(PLL_REF_DIV, par);
pll_ext_cntl = aty_ld_pll_ct(PLL_EXT_CNTL, par);
- pll->ct.xclk_post_div_real = postdividers[pll_ext_cntl & 0x07];
+ pll->ct.xclk_post_div_real = aty_postdividers[pll_ext_cntl & 0x07];
mclk_fb_div = aty_ld_pll_ct(MCLK_FB_DIV, par);
if (pll_ext_cntl & PLL_MFB_TIMES_4_2B)
mclk_fb_div <<= 1;
@@ -535,7 +535,7 @@ static int aty_init_pll_ct(const struct fb_info *info, union aty_pll *pll)
xpost_div += (q < 64*8);
xpost_div += (q < 32*8);
}
- pll->ct.xclk_post_div_real = postdividers[xpost_div];
+ pll->ct.xclk_post_div_real = aty_postdividers[xpost_div];
pll->ct.mclk_fb_div = q * pll->ct.xclk_post_div_real / 8;
#ifdef CONFIG_PPC
@@ -584,7 +584,7 @@ static int aty_init_pll_ct(const struct fb_info *info, union aty_pll *pll)
mpost_div += (q < 64*8);
mpost_div += (q < 32*8);
}
- sclk_post_div_real = postdividers[mpost_div];
+ sclk_post_div_real = aty_postdividers[mpost_div];
pll->ct.sclk_fb_div = q * sclk_post_div_real / 8;
pll->ct.spll_cntl2 = mpost_div << 4;
#ifdef DEBUG
commit 10283ea525d30f2e99828978fd04d8427876a7ad upstream.
gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects
attached to the resource group glocks. That function should release the
buffers attached to the gfs2_bitmap objects (bi_bh), but the call to
gfs2_rgrp_brelse for doing that is missing.
When gfs2_releasepage later runs across these buffers which are still
referenced, it refuses to free them. This causes the pages the buffers
are attached to to remain referenced as well. With enough mount/unmount
cycles, the system will eventually run out of memory.
Fix this by adding the missing call to gfs2_rgrp_brelse in
gfs2_clear_rgrpd.
(Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.)
Fixes: 39b0f1e92908 ("GFS2: Don't brelse rgrp buffer_heads every allocation")
Cc: stable(a)vger.kernel.org # v4.4
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
---
fs/gfs2/rgrp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 832824994aae..073126707270 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -715,6 +715,7 @@ void gfs2_clear_rgrpd(struct gfs2_sbd *sdp)
spin_lock(&gl->gl_lockref.lock);
gl->gl_object = NULL;
spin_unlock(&gl->gl_lockref.lock);
+ gfs2_rgrp_brelse(rgd);
gfs2_glock_add_to_lru(gl);
gfs2_glock_put(gl);
}
@@ -1125,7 +1126,7 @@ static u32 count_unlinked(struct gfs2_rgrpd *rgd)
* @rgd: the struct gfs2_rgrpd describing the RG to read in
*
* Read in all of a Resource Group's header and bitmap blocks.
- * Caller must eventually call gfs2_rgrp_relse() to free the bitmaps.
+ * Caller must eventually call gfs2_rgrp_brelse() to free the bitmaps.
*
* Returns: errno
*/
--
2.19.1.546.g028f9c799.dirty
From: Mark Rutland <mark.rutland(a)arm.com>
commit da5a3ce66b8bb51b0ea8a89f42aac153903f90fb upstream.
At boot time, KVM stashes the host MDCR_EL2 value, but only does this
when the kernel is not running in hyp mode (i.e. is non-VHE). In these
cases, the stashed value of MDCR_EL2.HPMN happens to be zero, which can
lead to CONSTRAINED UNPREDICTABLE behaviour.
Since we use this value to derive the MDCR_EL2 value when switching
to/from a guest, after a guest have been run, the performance counters
do not behave as expected. This has been observed to result in accesses
via PMXEVTYPER_EL0 and PMXEVCNTR_EL0 not affecting the relevant
counters, resulting in events not being counted. In these cases, only
the fixed-purpose cycle counter appears to work as expected.
Fix this by always stashing the host MDCR_EL2 value, regardless of VHE.
Cc: Christopher Dall <christoffer.dall(a)arm.com>
Cc: James Morse <james.morse(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: stable(a)vger.kernel.org
Fixes: 1e947bad0b63b351 ("arm64: KVM: Skip HYP setup when already running in HYP")
Tested-by: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
---
arch/arm/kvm/arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 20436972537f..a670c70f4def 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1092,8 +1092,6 @@ static void cpu_init_hyp_mode(void *dummy)
__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
__cpu_init_stage2();
-
- kvm_arm_init_debug();
}
static void cpu_hyp_reinit(void)
@@ -1108,6 +1106,8 @@ static void cpu_hyp_reinit(void)
if (__hyp_get_vectors() == hyp_default_vectors)
cpu_init_hyp_mode(NULL);
}
+
+ kvm_arm_init_debug();
}
static void cpu_hyp_reset(void)
--
2.19.1
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5e1275808630ea3b2c97c776f40e475017535f72 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Wed, 31 Oct 2018 12:15:23 +0100
Subject: [PATCH] ovl: check whiteout in ovl_create_over_whiteout()
Kaixuxia repors that it's possible to crash overlayfs by removing the
whiteout on the upper layer before creating a directory over it. This is a
reproducer:
mkdir lower upper work merge
touch lower/file
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge
rm merge/file
ls -al merge/file
rm upper/file
ls -al merge/
mkdir merge/file
Before commencing with a vfs_rename(..., RENAME_EXCHANGE) verify that the
lookup of "upper" is positive and is a whiteout, and return ESTALE
otherwise.
Reported by: kaixuxia <xiakaixu1987(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: e9be9d5e76e3 ("overlay filesystem")
Cc: <stable(a)vger.kernel.org> # v3.18
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index ce1857fb5434..c6289147c787 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -462,6 +462,10 @@ static int ovl_create_over_whiteout(struct dentry *dentry, struct inode *inode,
if (IS_ERR(upper))
goto out_unlock;
+ err = -ESTALE;
+ if (d_is_negative(upper) || !IS_WHITEOUT(d_inode(upper)))
+ goto out_dput;
+
newdentry = ovl_create_temp(workdir, cattr);
err = PTR_ERR(newdentry);
if (IS_ERR(newdentry))
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5e1275808630ea3b2c97c776f40e475017535f72 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Wed, 31 Oct 2018 12:15:23 +0100
Subject: [PATCH] ovl: check whiteout in ovl_create_over_whiteout()
Kaixuxia repors that it's possible to crash overlayfs by removing the
whiteout on the upper layer before creating a directory over it. This is a
reproducer:
mkdir lower upper work merge
touch lower/file
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge
rm merge/file
ls -al merge/file
rm upper/file
ls -al merge/
mkdir merge/file
Before commencing with a vfs_rename(..., RENAME_EXCHANGE) verify that the
lookup of "upper" is positive and is a whiteout, and return ESTALE
otherwise.
Reported by: kaixuxia <xiakaixu1987(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: e9be9d5e76e3 ("overlay filesystem")
Cc: <stable(a)vger.kernel.org> # v3.18
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index ce1857fb5434..c6289147c787 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -462,6 +462,10 @@ static int ovl_create_over_whiteout(struct dentry *dentry, struct inode *inode,
if (IS_ERR(upper))
goto out_unlock;
+ err = -ESTALE;
+ if (d_is_negative(upper) || !IS_WHITEOUT(d_inode(upper)))
+ goto out_dput;
+
newdentry = ovl_create_temp(workdir, cattr);
err = PTR_ERR(newdentry);
if (IS_ERR(newdentry))
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f9005571701920551bcf54a500973fb61f2e1eda Mon Sep 17 00:00:00 2001
From: Stefano Stabellini <stefanos(a)xilinx.com>
Date: Wed, 31 Oct 2018 16:11:49 -0700
Subject: [PATCH] CONFIG_XEN_PV breaks xen_create_contiguous_region on ARM
xen_create_contiguous_region has now only an implementation if
CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
we do have an implementation of xen_create_contiguous_region which is
required for swiotlb-xen to work correctly (although it just sets
*dma_handle).
Cc: <stable(a)vger.kernel.org> # 4.12
Fixes: 16624390816c ("xen: create xen_create/destroy_contiguous_region() stubs for PVHVM only builds")
Signed-off-by: Stefano Stabellini <stefanos(a)xilinx.com>
Reviewed-by: Juergen Gross <jgross(a)suse.com>
CC: Jeff.Kubascik(a)dornerworks.com
CC: Jarvis.Roach(a)dornerworks.com
CC: Nathan.Studer(a)dornerworks.com
CC: vkuznets(a)redhat.com
CC: boris.ostrovsky(a)oracle.com
CC: jgross(a)suse.com
CC: julien.grall(a)arm.com
Signed-off-by: Juergen Gross <jgross(a)suse.com>
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 18803ff76e27..4969817124a8 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -42,16 +42,12 @@ int xen_setup_shutdown_event(void);
extern unsigned long *xen_contiguous_bitmap;
-#ifdef CONFIG_XEN_PV
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_ARM) || defined(CONFIG_ARM64)
int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
unsigned int address_bits,
dma_addr_t *dma_handle);
void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order);
-
-int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
- xen_pfn_t *pfn, int nr, int *err_ptr, pgprot_t prot,
- unsigned int domid, bool no_translate, struct page **pages);
#else
static inline int xen_create_contiguous_region(phys_addr_t pstart,
unsigned int order,
@@ -63,7 +59,13 @@ static inline int xen_create_contiguous_region(phys_addr_t pstart,
static inline void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order) { }
+#endif
+#if defined(CONFIG_XEN_PV)
+int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
+ xen_pfn_t *pfn, int nr, int *err_ptr, pgprot_t prot,
+ unsigned int domid, bool no_translate, struct page **pages);
+#else
static inline int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
xen_pfn_t *pfn, int nr, int *err_ptr,
pgprot_t prot, unsigned int domid,
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From df5e31c204b34e8d9e5ec33f5b28e960c4f25e14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Thu, 25 Oct 2018 16:05:36 +0300
Subject: [PATCH] drm/i915: Fix ilk+ watermarks when disabling pipes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We're no longer programming any watermarks when we're disabling
a pipe. That means ilk_wm_merge() & co. will keep considering
the any pipe that is getting disabled as still enabled. Thus we
either get no LP1+ watermakrs (ilk-ivb), or we get suboptimal
ones (hsw-bdw).
This seems to have been broken by commit b6b178a77210 ("drm/i915:
Calculate ironlake intermediate watermarks correctly, v2."). Before
that we apparently had some difference between the intermediate
and optimal watermarks and so we would program the optiomal ones.
Now intermediate and optimal are identical for disabled pipes
and so we don't program either.
Fix this by programming the intermediate watermarks even for
disabled pipes. We were already doing that for skl+. We'll
leave out gmch platforms for now since those do the merging
in a different manner and should work as is. We'll want to
unify this eventually, but play it safe for now and just put
in a FIXME.
Cc: stable(a)vger.kernel.org
Cc: Matt Roper <matthew.d.roper(a)intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Fixes: b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025130536.29024-1-ville.…
Reviewed-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> #irc
(cherry picked from commit a748faea3bfd7fd1d1485bc1c426c7d460cc6503)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index b8dfdbc9ca1f..23d8008a93bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12768,17 +12768,12 @@ static void intel_atomic_commit_tail(struct drm_atomic_state *state)
intel_check_cpu_fifo_underruns(dev_priv);
intel_check_pch_fifo_underruns(dev_priv);
- if (!new_crtc_state->active) {
- /*
- * Make sure we don't call initial_watermarks
- * for ILK-style watermark updates.
- *
- * No clue what this is supposed to achieve.
- */
- if (INTEL_GEN(dev_priv) >= 9)
- dev_priv->display.initial_watermarks(intel_state,
- to_intel_crtc_state(new_crtc_state));
- }
+ /* FIXME unify this for all platforms */
+ if (!new_crtc_state->active &&
+ !HAS_GMCH_DISPLAY(dev_priv) &&
+ dev_priv->display.initial_watermarks)
+ dev_priv->display.initial_watermarks(intel_state,
+ to_intel_crtc_state(new_crtc_state));
}
}
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.
Other boards may be broken too, which I haven't tested.
The problem is in the fact that most board files still use the legacy
GPIO API where lines are requested by numbers rather than descriptors.
While this should be fixed eventually, in order to unbreak the board
for now - provide a way to manually specify the GPIO base in platform
data.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
drivers/gpio/gpio-davinci.c | 2 +-
include/linux/platform_data/gpio-davinci.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 5c1564fcc24e..bdb29e51b417 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -258,7 +258,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
chips->chip.set = davinci_gpio_set;
chips->chip.ngpio = ngpio;
- chips->chip.base = -1;
+ chips->chip.base = pdata->no_auto_base ? pdata->base : -1;
#ifdef CONFIG_OF_GPIO
chips->chip.of_gpio_n_cells = 2;
diff --git a/include/linux/platform_data/gpio-davinci.h b/include/linux/platform_data/gpio-davinci.h
index f92a47e18034..a93841bfb9f7 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -17,6 +17,8 @@
#define __DAVINCI_GPIO_PLATFORM_H
struct davinci_gpio_platform_data {
+ bool no_auto_base;
+ u32 base;
u32 ngpio;
u32 gpio_unbanked;
};
--
2.19.1
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 9b27390139dbe0dc10d1899545248862fe826b61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Wed, 3 Oct 2018 17:50:17 +0300
Subject: [PATCH] drm/i915: Use the correct crtc when sanitizing plane mapping
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When we decide that a plane is attached to the wrong pipe we try
to turn off said plane. However we are passing around the crtc we
think that the plane is supposed to be using rather than the crtc
it is currently using. That doesn't work all that well because
we may have to do vblank waits etc. and the other pipe might
not even be enabled here. So let's pass the plane's current crtc to
intel_plane_disable_noatomic() so that it can its job correctly.
To do that semi-cleanly we also have to change the plane readout
to record the plane's visibility into the bitmasks of the crtc
where the plane is currently enabled rather than to the crtc
we want to use for the plane.
One caveat here is that our active_planes bitmask will get confused
if both planes are enabled on the same pipe. Fortunately we can use
plane_mask to reconstruct active_planes sufficiently since
plane_mask still has the same meaning (is the plane visible?)
during readout. We also have to do the same during the initial
plane readout as the second plane could clear the active_planes
bit the first plane had already set.
v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel)
Add Daniel's proposed comment to better document why we do this
Drop the redundant intel_set_plane_visible() call
Cc: stable(a)vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state() return the current pipe
Cc: stable(a)vger.kernel.org
Cc: Dennis <dennis.nezic(a)utoronto.ca>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Tested-by: Dennis <dennis.nezic(a)utoronto.ca>
Tested-by: Peter Nowee <peter.nowee(a)gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181003145017.4527-1-ville.s…
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
(cherry picked from commit 62358aa4ee86481ce044bef04859820e1bc7c1d9)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ce23b0546407..1025d58ea1e8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2764,20 +2764,33 @@ intel_set_plane_visible(struct intel_crtc_state *crtc_state,
plane_state->base.visible = visible;
- /* FIXME pre-g4x don't work like this */
- if (visible) {
+ if (visible)
crtc_state->base.plane_mask |= drm_plane_mask(&plane->base);
- crtc_state->active_planes |= BIT(plane->id);
- } else {
+ else
crtc_state->base.plane_mask &= ~drm_plane_mask(&plane->base);
- crtc_state->active_planes &= ~BIT(plane->id);
- }
DRM_DEBUG_KMS("%s active planes 0x%x\n",
crtc_state->base.crtc->name,
crtc_state->active_planes);
}
+static void fixup_active_planes(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+ struct drm_plane *plane;
+
+ /*
+ * Active_planes aliases if multiple "primary" or cursor planes
+ * have been used on the same (or wrong) pipe. plane_mask uses
+ * unique ids, hence we can use that to reconstruct active_planes.
+ */
+ crtc_state->active_planes = 0;
+
+ drm_for_each_plane_mask(plane, &dev_priv->drm,
+ crtc_state->base.plane_mask)
+ crtc_state->active_planes |= BIT(to_intel_plane(plane)->id);
+}
+
static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
struct intel_plane *plane)
{
@@ -2787,6 +2800,7 @@ static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
to_intel_plane_state(plane->base.state);
intel_set_plane_visible(crtc_state, plane_state, false);
+ fixup_active_planes(crtc_state);
if (plane->id == PLANE_PRIMARY)
intel_pre_disable_primary_noatomic(&crtc->base);
@@ -2805,7 +2819,6 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
struct drm_i915_gem_object *obj;
struct drm_plane *primary = intel_crtc->base.primary;
struct drm_plane_state *plane_state = primary->state;
- struct drm_crtc_state *crtc_state = intel_crtc->base.state;
struct intel_plane *intel_plane = to_intel_plane(primary);
struct intel_plane_state *intel_state =
to_intel_plane_state(plane_state);
@@ -2900,10 +2913,6 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
plane_state->fb = fb;
plane_state->crtc = &intel_crtc->base;
- intel_set_plane_visible(to_intel_crtc_state(crtc_state),
- to_intel_plane_state(plane_state),
- true);
-
atomic_or(to_intel_plane(primary)->frontbuffer_bit,
&obj->frontbuffer_bits);
}
@@ -15450,17 +15459,6 @@ void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
POSTING_READ(DPLL(pipe));
}
-static bool intel_plane_mapping_ok(struct intel_crtc *crtc,
- struct intel_plane *plane)
-{
- enum pipe pipe;
-
- if (!plane->get_hw_state(plane, &pipe))
- return true;
-
- return pipe == crtc->pipe;
-}
-
static void
intel_sanitize_plane_mapping(struct drm_i915_private *dev_priv)
{
@@ -15472,13 +15470,20 @@ intel_sanitize_plane_mapping(struct drm_i915_private *dev_priv)
for_each_intel_crtc(&dev_priv->drm, crtc) {
struct intel_plane *plane =
to_intel_plane(crtc->base.primary);
+ struct intel_crtc *plane_crtc;
+ enum pipe pipe;
- if (intel_plane_mapping_ok(crtc, plane))
+ if (!plane->get_hw_state(plane, &pipe))
+ continue;
+
+ if (pipe == crtc->pipe)
continue;
DRM_DEBUG_KMS("%s attached to the wrong pipe, disabling plane\n",
plane->base.name);
- intel_plane_disable_noatomic(crtc, plane);
+
+ plane_crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ intel_plane_disable_noatomic(plane_crtc, plane);
}
}
@@ -15646,23 +15651,32 @@ void i915_redisable_vga(struct drm_i915_private *dev_priv)
}
/* FIXME read out full plane state for all planes */
-static void readout_plane_state(struct intel_crtc *crtc)
+static void readout_plane_state(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_crtc_state *crtc_state =
- to_intel_crtc_state(crtc->base.state);
struct intel_plane *plane;
+ struct intel_crtc *crtc;
- for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
+ for_each_intel_plane(&dev_priv->drm, plane) {
struct intel_plane_state *plane_state =
to_intel_plane_state(plane->base.state);
- enum pipe pipe;
+ struct intel_crtc_state *crtc_state;
+ enum pipe pipe = PIPE_A;
bool visible;
visible = plane->get_hw_state(plane, &pipe);
+ crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+
intel_set_plane_visible(crtc_state, plane_state, visible);
}
+
+ for_each_intel_crtc(&dev_priv->drm, crtc) {
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
+
+ fixup_active_planes(crtc_state);
+ }
}
static void intel_modeset_readout_hw_state(struct drm_device *dev)
@@ -15694,13 +15708,13 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev)
if (crtc_state->base.active)
dev_priv->active_crtcs |= 1 << crtc->pipe;
- readout_plane_state(crtc);
-
DRM_DEBUG_KMS("[CRTC:%d:%s] hw state readout: %s\n",
crtc->base.base.id, crtc->base.name,
enableddisabled(crtc_state->base.active));
}
+ readout_plane_state(dev_priv);
+
for (i = 0; i < dev_priv->num_shared_dpll; i++) {
struct intel_shared_dpll *pll = &dev_priv->shared_dplls[i];
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 9b27390139dbe0dc10d1899545248862fe826b61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Wed, 3 Oct 2018 17:50:17 +0300
Subject: [PATCH] drm/i915: Use the correct crtc when sanitizing plane mapping
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When we decide that a plane is attached to the wrong pipe we try
to turn off said plane. However we are passing around the crtc we
think that the plane is supposed to be using rather than the crtc
it is currently using. That doesn't work all that well because
we may have to do vblank waits etc. and the other pipe might
not even be enabled here. So let's pass the plane's current crtc to
intel_plane_disable_noatomic() so that it can its job correctly.
To do that semi-cleanly we also have to change the plane readout
to record the plane's visibility into the bitmasks of the crtc
where the plane is currently enabled rather than to the crtc
we want to use for the plane.
One caveat here is that our active_planes bitmask will get confused
if both planes are enabled on the same pipe. Fortunately we can use
plane_mask to reconstruct active_planes sufficiently since
plane_mask still has the same meaning (is the plane visible?)
during readout. We also have to do the same during the initial
plane readout as the second plane could clear the active_planes
bit the first plane had already set.
v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel)
Add Daniel's proposed comment to better document why we do this
Drop the redundant intel_set_plane_visible() call
Cc: stable(a)vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state() return the current pipe
Cc: stable(a)vger.kernel.org
Cc: Dennis <dennis.nezic(a)utoronto.ca>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Tested-by: Dennis <dennis.nezic(a)utoronto.ca>
Tested-by: Peter Nowee <peter.nowee(a)gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181003145017.4527-1-ville.s…
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
(cherry picked from commit 62358aa4ee86481ce044bef04859820e1bc7c1d9)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ce23b0546407..1025d58ea1e8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2764,20 +2764,33 @@ intel_set_plane_visible(struct intel_crtc_state *crtc_state,
plane_state->base.visible = visible;
- /* FIXME pre-g4x don't work like this */
- if (visible) {
+ if (visible)
crtc_state->base.plane_mask |= drm_plane_mask(&plane->base);
- crtc_state->active_planes |= BIT(plane->id);
- } else {
+ else
crtc_state->base.plane_mask &= ~drm_plane_mask(&plane->base);
- crtc_state->active_planes &= ~BIT(plane->id);
- }
DRM_DEBUG_KMS("%s active planes 0x%x\n",
crtc_state->base.crtc->name,
crtc_state->active_planes);
}
+static void fixup_active_planes(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+ struct drm_plane *plane;
+
+ /*
+ * Active_planes aliases if multiple "primary" or cursor planes
+ * have been used on the same (or wrong) pipe. plane_mask uses
+ * unique ids, hence we can use that to reconstruct active_planes.
+ */
+ crtc_state->active_planes = 0;
+
+ drm_for_each_plane_mask(plane, &dev_priv->drm,
+ crtc_state->base.plane_mask)
+ crtc_state->active_planes |= BIT(to_intel_plane(plane)->id);
+}
+
static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
struct intel_plane *plane)
{
@@ -2787,6 +2800,7 @@ static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
to_intel_plane_state(plane->base.state);
intel_set_plane_visible(crtc_state, plane_state, false);
+ fixup_active_planes(crtc_state);
if (plane->id == PLANE_PRIMARY)
intel_pre_disable_primary_noatomic(&crtc->base);
@@ -2805,7 +2819,6 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
struct drm_i915_gem_object *obj;
struct drm_plane *primary = intel_crtc->base.primary;
struct drm_plane_state *plane_state = primary->state;
- struct drm_crtc_state *crtc_state = intel_crtc->base.state;
struct intel_plane *intel_plane = to_intel_plane(primary);
struct intel_plane_state *intel_state =
to_intel_plane_state(plane_state);
@@ -2900,10 +2913,6 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
plane_state->fb = fb;
plane_state->crtc = &intel_crtc->base;
- intel_set_plane_visible(to_intel_crtc_state(crtc_state),
- to_intel_plane_state(plane_state),
- true);
-
atomic_or(to_intel_plane(primary)->frontbuffer_bit,
&obj->frontbuffer_bits);
}
@@ -15450,17 +15459,6 @@ void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
POSTING_READ(DPLL(pipe));
}
-static bool intel_plane_mapping_ok(struct intel_crtc *crtc,
- struct intel_plane *plane)
-{
- enum pipe pipe;
-
- if (!plane->get_hw_state(plane, &pipe))
- return true;
-
- return pipe == crtc->pipe;
-}
-
static void
intel_sanitize_plane_mapping(struct drm_i915_private *dev_priv)
{
@@ -15472,13 +15470,20 @@ intel_sanitize_plane_mapping(struct drm_i915_private *dev_priv)
for_each_intel_crtc(&dev_priv->drm, crtc) {
struct intel_plane *plane =
to_intel_plane(crtc->base.primary);
+ struct intel_crtc *plane_crtc;
+ enum pipe pipe;
- if (intel_plane_mapping_ok(crtc, plane))
+ if (!plane->get_hw_state(plane, &pipe))
+ continue;
+
+ if (pipe == crtc->pipe)
continue;
DRM_DEBUG_KMS("%s attached to the wrong pipe, disabling plane\n",
plane->base.name);
- intel_plane_disable_noatomic(crtc, plane);
+
+ plane_crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ intel_plane_disable_noatomic(plane_crtc, plane);
}
}
@@ -15646,23 +15651,32 @@ void i915_redisable_vga(struct drm_i915_private *dev_priv)
}
/* FIXME read out full plane state for all planes */
-static void readout_plane_state(struct intel_crtc *crtc)
+static void readout_plane_state(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_crtc_state *crtc_state =
- to_intel_crtc_state(crtc->base.state);
struct intel_plane *plane;
+ struct intel_crtc *crtc;
- for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
+ for_each_intel_plane(&dev_priv->drm, plane) {
struct intel_plane_state *plane_state =
to_intel_plane_state(plane->base.state);
- enum pipe pipe;
+ struct intel_crtc_state *crtc_state;
+ enum pipe pipe = PIPE_A;
bool visible;
visible = plane->get_hw_state(plane, &pipe);
+ crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+
intel_set_plane_visible(crtc_state, plane_state, visible);
}
+
+ for_each_intel_crtc(&dev_priv->drm, crtc) {
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
+
+ fixup_active_planes(crtc_state);
+ }
}
static void intel_modeset_readout_hw_state(struct drm_device *dev)
@@ -15694,13 +15708,13 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev)
if (crtc_state->base.active)
dev_priv->active_crtcs |= 1 << crtc->pipe;
- readout_plane_state(crtc);
-
DRM_DEBUG_KMS("[CRTC:%d:%s] hw state readout: %s\n",
crtc->base.base.id, crtc->base.name,
enableddisabled(crtc_state->base.active));
}
+ readout_plane_state(dev_priv);
+
for (i = 0; i < dev_priv->num_shared_dpll; i++) {
struct intel_shared_dpll *pll = &dev_priv->shared_dplls[i];
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 4bbf0d4749e707b6b262d576a9a9ef5c63b52dd4 Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Mon, 8 Oct 2018 19:24:34 -0400
Subject: [PATCH] drm/i915: Fix intel_dp_mst_best_encoder()
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-longer-present MSTB ports by
changing the DPMS state to off and this still requires that we retrieve
an encoder.
So, fix this by always returning a valid encoder regardless of the state
of the MST port.
Changes since v1:
- Remove mst atomic helper, since this got replaced with a much simpler
solution
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: stable(a)vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-6-lyude@r…
(cherry picked from commit a9f9ca33d1fe9325f414914be526c0fc4ba5281c)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 0f14c0d1669c..7f155b4f1a7d 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -404,8 +404,6 @@ static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
- if (!READ_ONCE(connector->registered))
- return NULL;
return &intel_dp->mst_encoders[crtc->pipe]->base.base;
}
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From de9f8eea5a44b0b756d3d6345af7f8e630a3c8c0 Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Tue, 16 Oct 2018 16:39:46 -0400
Subject: [PATCH] drm/atomic_helper: Stop modesets on unregistered connectors
harder
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Unfortunately, it appears our fix in:
commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: stable(a)vger.kernel.org
Cc: David Airlie <airlied(a)linux.ie>
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@r…
(cherry picked from commit 39b50c603878f4f8ae541ac4088a805d588abc79)
Fixes: e96550956fbc ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Fixes: 34ca26a98ad6 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: stable(a)vger.kernel.org
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index e49b22381048..1cc3a045ec2f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -308,6 +308,26 @@ update_connector_routing(struct drm_atomic_state *state,
return 0;
}
+ crtc_state = drm_atomic_get_new_crtc_state(state,
+ new_connector_state->crtc);
+ /*
+ * For compatibility with legacy users, we want to make sure that
+ * we allow DPMS On->Off modesets on unregistered connectors. Modesets
+ * which would result in anything else must be considered invalid, to
+ * avoid turning on new displays on dead connectors.
+ *
+ * Since the connector can be unregistered at any point during an
+ * atomic check or commit, this is racy. But that's OK: all we care
+ * about is ensuring that userspace can't do anything but shut off the
+ * display on a connector that was destroyed after its been notified,
+ * not before.
+ */
+ if (drm_connector_is_unregistered(connector) && crtc_state->active) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
funcs = connector->helper_private;
if (funcs->atomic_best_encoder)
@@ -352,7 +372,6 @@ update_connector_routing(struct drm_atomic_state *state,
set_best_encoder(state, new_connector_state, new_encoder);
- crtc_state = drm_atomic_get_new_crtc_state(state, new_connector_state->crtc);
crtc_state->connectors_changed = true;
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on [CRTC:%d:%s]\n",
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index a22d6f269b07..d5b7f315098c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -299,27 +299,6 @@ drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state,
struct drm_connector *connector = conn_state->connector;
struct drm_crtc_state *crtc_state;
- /*
- * For compatibility with legacy users, we want to make sure that
- * we allow DPMS On<->Off modesets on unregistered connectors, since
- * legacy modesetting users will not be expecting these to fail. We do
- * not however, want to allow legacy users to assign a connector
- * that's been unregistered from sysfs to another CRTC, since doing
- * this with a now non-existent connector could potentially leave us
- * in an invalid state.
- *
- * Since the connector can be unregistered at any point during an
- * atomic check or commit, this is racy. But that's OK: all we care
- * about is ensuring that userspace can't use this connector for new
- * configurations after it's been notified that the connector is no
- * longer present.
- */
- if (!READ_ONCE(connector->registered) && crtc) {
- DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
- connector->base.id, connector->name);
- return -EINVAL;
- }
-
if (conn_state->crtc == crtc)
return 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 1e40e5decbe9..4943cef178be 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -379,7 +379,8 @@ void drm_connector_cleanup(struct drm_connector *connector)
/* The connector should have been removed from userspace long before
* it is finally destroyed.
*/
- if (WARN_ON(connector->registered))
+ if (WARN_ON(connector->registration_state ==
+ DRM_CONNECTOR_REGISTERED))
drm_connector_unregister(connector);
if (connector->tile_group) {
@@ -436,7 +437,7 @@ int drm_connector_register(struct drm_connector *connector)
return 0;
mutex_lock(&connector->mutex);
- if (connector->registered)
+ if (connector->registration_state != DRM_CONNECTOR_INITIALIZING)
goto unlock;
ret = drm_sysfs_connector_add(connector);
@@ -456,7 +457,7 @@ int drm_connector_register(struct drm_connector *connector)
drm_mode_object_register(connector->dev, &connector->base);
- connector->registered = true;
+ connector->registration_state = DRM_CONNECTOR_REGISTERED;
goto unlock;
err_debugfs:
@@ -478,7 +479,7 @@ EXPORT_SYMBOL(drm_connector_register);
void drm_connector_unregister(struct drm_connector *connector)
{
mutex_lock(&connector->mutex);
- if (!connector->registered) {
+ if (connector->registration_state != DRM_CONNECTOR_REGISTERED) {
mutex_unlock(&connector->mutex);
return;
}
@@ -489,7 +490,7 @@ void drm_connector_unregister(struct drm_connector *connector)
drm_sysfs_connector_remove(connector);
drm_debugfs_connector_remove(connector);
- connector->registered = false;
+ connector->registration_state = DRM_CONNECTOR_UNREGISTERED;
mutex_unlock(&connector->mutex);
}
EXPORT_SYMBOL(drm_connector_unregister);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 7f155b4f1a7d..1b00f8ea145b 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -77,7 +77,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
pipe_config->pbn = mst_pbn;
/* Zombie connectors can't have VCPI slots */
- if (READ_ONCE(connector->registered)) {
+ if (!drm_connector_is_unregistered(connector)) {
slots = drm_dp_atomic_find_vcpi_slots(state,
&intel_dp->mst_mgr,
port,
@@ -313,7 +313,7 @@ static int intel_dp_mst_get_ddc_modes(struct drm_connector *connector)
struct edid *edid;
int ret;
- if (!READ_ONCE(connector->registered))
+ if (drm_connector_is_unregistered(connector))
return intel_connector_update_modes(connector, NULL);
edid = drm_dp_mst_get_edid(connector, &intel_dp->mst_mgr, intel_connector->port);
@@ -329,7 +329,7 @@ intel_dp_mst_detect(struct drm_connector *connector, bool force)
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
- if (!READ_ONCE(connector->registered))
+ if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
return drm_dp_mst_detect_port(connector, &intel_dp->mst_mgr,
intel_connector->port);
@@ -372,7 +372,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
int bpp = 24; /* MST uses fixed bpp */
int max_rate, mode_rate, max_lanes, max_link_clock;
- if (!READ_ONCE(connector->registered))
+ if (drm_connector_is_unregistered(connector))
return MODE_ERROR;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 91a877fa00cb..9ccad6b062f2 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -82,6 +82,53 @@ enum drm_connector_status {
connector_status_unknown = 3,
};
+/**
+ * enum drm_connector_registration_status - userspace registration status for
+ * a &drm_connector
+ *
+ * This enum is used to track the status of initializing a connector and
+ * registering it with userspace, so that DRM can prevent bogus modesets on
+ * connectors that no longer exist.
+ */
+enum drm_connector_registration_state {
+ /**
+ * @DRM_CONNECTOR_INITIALIZING: The connector has just been created,
+ * but has yet to be exposed to userspace. There should be no
+ * additional restrictions to how the state of this connector may be
+ * modified.
+ */
+ DRM_CONNECTOR_INITIALIZING = 0,
+
+ /**
+ * @DRM_CONNECTOR_REGISTERED: The connector has been fully initialized
+ * and registered with sysfs, as such it has been exposed to
+ * userspace. There should be no additional restrictions to how the
+ * state of this connector may be modified.
+ */
+ DRM_CONNECTOR_REGISTERED = 1,
+
+ /**
+ * @DRM_CONNECTOR_UNREGISTERED: The connector has either been exposed
+ * to userspace and has since been unregistered and removed from
+ * userspace, or the connector was unregistered before it had a chance
+ * to be exposed to userspace (e.g. still in the
+ * @DRM_CONNECTOR_INITIALIZING state). When a connector is
+ * unregistered, there are additional restrictions to how its state
+ * may be modified:
+ *
+ * - An unregistered connector may only have its DPMS changed from
+ * On->Off. Once DPMS is changed to Off, it may not be switched back
+ * to On.
+ * - Modesets are not allowed on unregistered connectors, unless they
+ * would result in disabling its assigned CRTCs. This means
+ * disabling a CRTC on an unregistered connector is OK, but enabling
+ * one is not.
+ * - Removing a CRTC from an unregistered connector is OK, but new
+ * CRTCs may never be assigned to an unregistered connector.
+ */
+ DRM_CONNECTOR_UNREGISTERED = 2,
+};
+
enum subpixel_order {
SubPixelUnknown = 0,
SubPixelHorizontalRGB,
@@ -853,10 +900,12 @@ struct drm_connector {
bool ycbcr_420_allowed;
/**
- * @registered: Is this connector exposed (registered) with userspace?
+ * @registration_state: Is this connector initializing, exposed
+ * (registered) with userspace, or unregistered?
+ *
* Protected by @mutex.
*/
- bool registered;
+ enum drm_connector_registration_state registration_state;
/**
* @modes:
@@ -1166,6 +1215,24 @@ static inline void drm_connector_unreference(struct drm_connector *connector)
drm_connector_put(connector);
}
+/**
+ * drm_connector_is_unregistered - has the connector been unregistered from
+ * userspace?
+ * @connector: DRM connector
+ *
+ * Checks whether or not @connector has been unregistered from userspace.
+ *
+ * Returns:
+ * True if the connector was unregistered, false if the connector is
+ * registered or has not yet been registered with userspace.
+ */
+static inline bool
+drm_connector_is_unregistered(struct drm_connector *connector)
+{
+ return READ_ONCE(connector->registration_state) ==
+ DRM_CONNECTOR_UNREGISTERED;
+}
+
const char *drm_get_connector_status_name(enum drm_connector_status status);
const char *drm_get_subpixel_order_name(enum subpixel_order order);
const char *drm_get_dpms_name(int val);
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 34ca26a98ad67edd6e4870fe2d4aa047d41a51dd Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Tue, 9 Oct 2018 16:44:24 -0400
Subject: [PATCH] drm/atomic_helper: Allow DPMS On<->Off changes for
unregistered connectors
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It appears when testing my previous fix for some of the legacy
modesetting issues with MST, I misattributed some kernel splats that
started appearing on my machine after a rebase as being from upstream.
But it appears they actually came from my patch series:
[ 2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1]
[ 2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered
[ 2.980516] ------------[ cut here ]------------
[ 2.980519] Could not determine valid watermarks for inherited state
[ 2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915]
[ 2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd
[ 2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O 4.19.0-rc7Lyude-Test+ #1
[ 2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016
[ 2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915]
[ 2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00
[ 2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282
[ 2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006
[ 2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0
[ 2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065
[ 2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000
[ 2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800
[ 2.980630] FS: 00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000
[ 2.980633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0
[ 2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2.980645] Call Trace:
[ 2.980675] i915_driver_load+0xb0e/0xdc0 [i915]
[ 2.980681] ? kernfs_add_one+0xe7/0x130
[ 2.980709] i915_pci_probe+0x46/0x60 [i915]
[ 2.980715] pci_device_probe+0xd4/0x150
[ 2.980719] really_probe+0x243/0x3b0
[ 2.980722] driver_probe_device+0xba/0x100
[ 2.980726] __driver_attach+0xe4/0x110
[ 2.980729] ? driver_probe_device+0x100/0x100
[ 2.980733] bus_for_each_dev+0x74/0xb0
[ 2.980736] driver_attach+0x1e/0x20
[ 2.980739] bus_add_driver+0x159/0x230
[ 2.980743] ? 0xffffffffa0393000
[ 2.980746] driver_register+0x70/0xc0
[ 2.980749] ? 0xffffffffa0393000
[ 2.980753] __pci_register_driver+0x57/0x60
[ 2.980780] i915_init+0x55/0x58 [i915]
[ 2.980785] do_one_initcall+0x4a/0x1c4
[ 2.980789] ? do_init_module+0x27/0x210
[ 2.980793] ? kmem_cache_alloc_trace+0x131/0x190
[ 2.980797] do_init_module+0x60/0x210
[ 2.980800] load_module+0x2063/0x22e0
[ 2.980804] ? vfs_read+0x116/0x140
[ 2.980807] ? vfs_read+0x116/0x140
[ 2.980811] __do_sys_finit_module+0xbd/0x120
[ 2.980814] ? __do_sys_finit_module+0xbd/0x120
[ 2.980818] __x64_sys_finit_module+0x1a/0x20
[ 2.980821] do_syscall_64+0x5a/0x110
[ 2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 2.980826] RIP: 0033:0x7f4754e32879
[ 2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48
[ 2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879
[ 2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018
[ 2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000
[ 2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000
[ 2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000
[ 2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915]
[ 2.980884] ---[ end trace 5eb47a76277d4731 ]---
The cause of this appears to be due to the fact that if there's
pre-existing display state that was set by the BIOS when i915 loads, it
will attempt to perform a modeset before the driver is registered with
userspace. Since this happens before the driver's registered with
userspace, it's connectors are also unregistered and thus-states which
would turn on DPMS on a connector end up getting rejected since the
connector isn't registered.
These bugs managed to get past Intel's CI partially due to the fact it
never ran a full test on my patches for some reason, but also because
all of the tests unload the GPU once before running. Since this bug is
only really triggered when the drivers tries to perform a modeset before
it's been fully registered with userspace when coming from whatever
display configuration the firmware left us with, it likely would never
have been picked up by CI in the first place.
After some discussion with vsyrjala, we decided the best course of
action would be to just move the unregistered connector checks out of
update_connector_routing() and into drm_atomic_set_crtc_for_connector().
The reason for this being that legacy modesetting isn't going to be
expecting failures anywhere (at least this is the case with X), so
ideally we want to ensure that any DPMS changes will still work even on
unregistered connectors. Instead, we now only reject new modesets which
would change the current CRTC assigned to an unregistered connector
unless no new CRTC is being assigned to replace the connector's previous
one.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Reported-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Fixes: 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181009204424.21462-1-lyude@…
(cherry picked from commit b5d29843d8ef86d4cde4742e095b81b7fd41e688)
Fixes: e96550956fbc ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 20bd176138a0..e49b22381048 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -308,26 +308,6 @@ update_connector_routing(struct drm_atomic_state *state,
return 0;
}
- crtc_state = drm_atomic_get_new_crtc_state(state,
- new_connector_state->crtc);
- /*
- * For compatibility with legacy users, we want to make sure that
- * we allow DPMS On->Off modesets on unregistered connectors. Modesets
- * which would result in anything else must be considered invalid, to
- * avoid turning on new displays on dead connectors.
- *
- * Since the connector can be unregistered at any point during an
- * atomic check or commit, this is racy. But that's OK: all we care
- * about is ensuring that userspace can't do anything but shut off the
- * display on a connector that was destroyed after its been notified,
- * not before.
- */
- if (!READ_ONCE(connector->registered) && crtc_state->active) {
- DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
- connector->base.id, connector->name);
- return -EINVAL;
- }
-
funcs = connector->helper_private;
if (funcs->atomic_best_encoder)
@@ -372,6 +352,7 @@ update_connector_routing(struct drm_atomic_state *state,
set_best_encoder(state, new_connector_state, new_encoder);
+ crtc_state = drm_atomic_get_new_crtc_state(state, new_connector_state->crtc);
crtc_state->connectors_changed = true;
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on [CRTC:%d:%s]\n",
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..a22d6f269b07 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -299,6 +299,27 @@ drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state,
struct drm_connector *connector = conn_state->connector;
struct drm_crtc_state *crtc_state;
+ /*
+ * For compatibility with legacy users, we want to make sure that
+ * we allow DPMS On<->Off modesets on unregistered connectors, since
+ * legacy modesetting users will not be expecting these to fail. We do
+ * not however, want to allow legacy users to assign a connector
+ * that's been unregistered from sysfs to another CRTC, since doing
+ * this with a now non-existent connector could potentially leave us
+ * in an invalid state.
+ *
+ * Since the connector can be unregistered at any point during an
+ * atomic check or commit, this is racy. But that's OK: all we care
+ * about is ensuring that userspace can't use this connector for new
+ * configurations after it's been notified that the connector is no
+ * longer present.
+ */
+ if (!READ_ONCE(connector->registered) && crtc) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
if (conn_state->crtc == crtc)
return 0;
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From c1a17777eb45d9f3821f35e9869c0a08cd2e664e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com>
Date: Mon, 12 Nov 2018 18:08:31 +0100
Subject: [PATCH] drm/amdgpu: fix huge page handling on Vega10
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We accidentially set the huge flag on the parent instead of the childs.
This caused some VM faults under memory pressure.
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Acked-by: Alex Deucher <alexander.deucher(a)amd.com>
Tested-by: Samuel Pitoiset <samuel.pitoiset(a)gmail.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 352b30409060..dad0e2342df9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1632,13 +1632,6 @@ static int amdgpu_vm_update_ptes(struct amdgpu_pte_update_params *params,
continue;
}
- /* First check if the entry is already handled */
- if (cursor.pfn < frag_start) {
- cursor.entry->huge = true;
- amdgpu_vm_pt_next(adev, &cursor);
- continue;
- }
-
/* If it isn't already handled it can't be a huge page */
if (cursor.entry->huge) {
/* Add the entry to the relocated list to update it. */
@@ -1701,8 +1694,17 @@ static int amdgpu_vm_update_ptes(struct amdgpu_pte_update_params *params,
}
} while (frag_start < entry_end);
- if (frag >= shift)
+ if (amdgpu_vm_pt_descendant(adev, &cursor)) {
+ /* Mark all child entries as huge */
+ while (cursor.pfn < frag_start) {
+ cursor.entry->huge = true;
+ amdgpu_vm_pt_next(adev, &cursor);
+ }
+
+ } else if (frag >= shift) {
+ /* or just move on to the next on the same level. */
amdgpu_vm_pt_next(adev, &cursor);
+ }
}
return 0;
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 9d064be1e6a195eaaa3762af5c7c6cd3f66aa6cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <ckoenig.leichtzumerken(a)gmail.com>
Date: Wed, 24 Oct 2018 14:59:10 +0200
Subject: [PATCH] drm/amdgpu: revert "enable gfxoff in non-sriov and stutter
mode by default"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is still completely breaking my Raven system.
This reverts commit cdf2f910fa969adca1b0e3ad2b487821233dc038.
Revert until we sort out the sbios and firmware combinations that work
correctly.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=108606
Cc: stable(a)vger.kernel.org # v4.19
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f06d068b8eb5..30bc345d6fdf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1493,8 +1493,6 @@ static int amdgpu_device_ip_early_init(struct amdgpu_device *adev)
}
adev->powerplay.pp_feature = amdgpu_pp_feature_mask;
- if (amdgpu_sriov_vf(adev))
- adev->powerplay.pp_feature &= ~PP_GFXOFF_MASK;
for (i = 0; i < adev->num_ip_blocks; i++) {
if ((amdgpu_ip_block_mask & (1 << i)) == 0) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 28781414d71c..943dbf3c5da1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -114,8 +114,8 @@ uint amdgpu_pg_mask = 0xffffffff;
uint amdgpu_sdma_phase_quantum = 32;
char *amdgpu_disable_cu = NULL;
char *amdgpu_virtual_display = NULL;
-/* OverDrive(bit 14) disabled by default*/
-uint amdgpu_pp_feature_mask = 0xffffbfff;
+/* OverDrive(bit 14),gfxoff(bit 15),stutter mode(bit 17) disabled by default*/
+uint amdgpu_pp_feature_mask = 0xfffd3fff;
int amdgpu_ngg = 0;
int amdgpu_prim_buf_per_se = 0;
int amdgpu_pos_buf_per_se = 0;
From: Eric Biggers <ebiggers(a)google.com>
When a UHID_CREATE command is written to the uhid char device, a
copy_from_user() is done from a user pointer embedded in the command.
When the address limit is KERNEL_DS, e.g. as is the case during
sendfile(), this can read from kernel memory. Therefore, UHID_CREATE
must not be allowed in this case.
For consistency and to make sure all current and future uhid commands
are covered, apply the restriction to uhid_char_write() as a whole
rather than to UHID_CREATE specifically.
Thanks to Dmitry Vyukov for adding uhid definitions to syzkaller and to
Jann Horn for commit 9da3f2b740544 ("x86/fault: BUG() when uaccess
helpers fault on kernel addresses"), allowing this bug to be found.
Reported-by: syzbot+72473edc9bf4eb1c6556(a)syzkaller.appspotmail.com
Fixes: d365c6cfd337 ("HID: uhid: add UHID_CREATE and UHID_DESTROY events")
Cc: <stable(a)vger.kernel.org> # v3.6+
Cc: Jann Horn <jannh(a)google.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
drivers/hid/uhid.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
index 3c55073136064..e94c5e248b56e 100644
--- a/drivers/hid/uhid.c
+++ b/drivers/hid/uhid.c
@@ -705,6 +705,12 @@ static ssize_t uhid_char_write(struct file *file, const char __user *buffer,
int ret;
size_t len;
+ if (uaccess_kernel()) { /* payload may contain a __user pointer */
+ pr_err_once("%s: process %d (%s) called from kernel context, this is not allowed.\n",
+ __func__, task_tgid_vnr(current), current->comm);
+ return -EACCES;
+ }
+
/* we need at least the "type" member of uhid_event */
if (count < sizeof(__u32))
return -EINVAL;
--
2.19.1.930.g4563a0d9d0-goog
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 017b1660df89f5fb4bfe66c34e35f7d2031100c7 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Date: Fri, 5 Oct 2018 15:51:29 -0700
Subject: [PATCH] mm: migration: fix migration of huge PMD shared pages
The page migration code employs try_to_unmap() to try and unmap the source
page. This is accomplished by using rmap_walk to find all vmas where the
page is mapped. This search stops when page mapcount is zero. For shared
PMD huge pages, the page map count is always 1 no matter the number of
mappings. Shared mappings are tracked via the reference count of the PMD
page. Therefore, try_to_unmap stops prematurely and does not completely
unmap all mappings of the source page.
This problem can result is data corruption as writes to the original
source page can happen after contents of the page are copied to the target
page. Hence, data is lost.
This problem was originally seen as DB corruption of shared global areas
after a huge page was soft offlined due to ECC memory errors. DB
developers noticed they could reproduce the issue by (hotplug) offlining
memory used to back huge pages. A simple testcase can reproduce the
problem by creating a shared PMD mapping (note that this must be at least
PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using
migrate_pages() to migrate process pages between nodes while continually
writing to the huge pages being migrated.
To fix, have the try_to_unmap_one routine check for huge PMD sharing by
calling huge_pmd_unshare for hugetlbfs huge pages. If it is a shared
mapping it will be 'unshared' which removes the page table entry and drops
the reference on the PMD page. After this, flush caches and TLB.
mmu notifiers are called before locking page tables, but we can not be
sure of PMD sharing until page tables are locked. Therefore, check for
the possibility of PMD sharing before locking so that notifiers can
prepare for the worst possible case.
Link: http://lkml.kernel.org/r/20180823205917.16297-2-mike.kravetz@oracle.com
[mike.kravetz(a)oracle.com: make _range_in_vma() a static inline]
Link: http://lkml.kernel.org/r/6063f215-a5c8-2f0c-465a-2c515ddc952d@oracle.com
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Jerome Glisse <jglisse(a)redhat.com>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 6b68e345f0ca..087fd5f48c91 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -140,6 +140,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pte_t *huge_pte_offset(struct mm_struct *mm,
unsigned long addr, unsigned long sz);
int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep);
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end);
struct page *follow_huge_addr(struct mm_struct *mm, unsigned long address,
int write);
struct page *follow_huge_pd(struct vm_area_struct *vma,
@@ -170,6 +172,18 @@ static inline unsigned long hugetlb_total_pages(void)
return 0;
}
+static inline int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr,
+ pte_t *ptep)
+{
+ return 0;
+}
+
+static inline void adjust_range_if_pmd_sharing_possible(
+ struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+}
+
#define follow_hugetlb_page(m,v,p,vs,a,b,i,w,n) ({ BUG(); 0; })
#define follow_huge_addr(mm, addr, write) ERR_PTR(-EINVAL)
#define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a61ebe8ad4ca..0416a7204be3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2455,6 +2455,12 @@ static inline struct vm_area_struct *find_exact_vma(struct mm_struct *mm,
return vma;
}
+static inline bool range_in_vma(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ return (vma && vma->vm_start <= start && end <= vma->vm_end);
+}
+
#ifdef CONFIG_MMU
pgprot_t vm_get_page_prot(unsigned long vm_flags);
void vma_set_page_prot(struct vm_area_struct *vma);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3c21775f196b..b903d746e132 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4545,12 +4545,40 @@ static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)
/*
* check on proper vm_flags and page table alignment
*/
- if (vma->vm_flags & VM_MAYSHARE &&
- vma->vm_start <= base && end <= vma->vm_end)
+ if (vma->vm_flags & VM_MAYSHARE && range_in_vma(vma, base, end))
return true;
return false;
}
+/*
+ * Determine if start,end range within vma could be mapped by shared pmd.
+ * If yes, adjust start and end to cover range associated with possible
+ * shared pmd mappings.
+ */
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+ unsigned long check_addr = *start;
+
+ if (!(vma->vm_flags & VM_MAYSHARE))
+ return;
+
+ for (check_addr = *start; check_addr < *end; check_addr += PUD_SIZE) {
+ unsigned long a_start = check_addr & PUD_MASK;
+ unsigned long a_end = a_start + PUD_SIZE;
+
+ /*
+ * If sharing is possible, adjust start/end if necessary.
+ */
+ if (range_in_vma(vma, a_start, a_end)) {
+ if (a_start < *start)
+ *start = a_start;
+ if (a_end > *end)
+ *end = a_end;
+ }
+ }
+}
+
/*
* Search for a shareable pmd page for hugetlb. In any case calls pmd_alloc()
* and returns the corresponding pte. While this is not necessary for the
@@ -4648,6 +4676,11 @@ int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
{
return 0;
}
+
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+}
#define want_pmd_share() (0)
#endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
diff --git a/mm/rmap.c b/mm/rmap.c
index eb477809a5c0..1e79fac3186b 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1362,11 +1362,21 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
}
/*
- * We have to assume the worse case ie pmd for invalidation. Note that
- * the page can not be free in this function as call of try_to_unmap()
- * must hold a reference on the page.
+ * For THP, we have to assume the worse case ie pmd for invalidation.
+ * For hugetlb, it could be much worse if we need to do pud
+ * invalidation in the case of pmd sharing.
+ *
+ * Note that the page can not be free in this function as call of
+ * try_to_unmap() must hold a reference on the page.
*/
end = min(vma->vm_end, start + (PAGE_SIZE << compound_order(page)));
+ if (PageHuge(page)) {
+ /*
+ * If sharing is possible, start and end will be adjusted
+ * accordingly.
+ */
+ adjust_range_if_pmd_sharing_possible(vma, &start, &end);
+ }
mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
while (page_vma_mapped_walk(&pvmw)) {
@@ -1409,6 +1419,32 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
subpage = page - page_to_pfn(page) + pte_pfn(*pvmw.pte);
address = pvmw.address;
+ if (PageHuge(page)) {
+ if (huge_pmd_unshare(mm, &address, pvmw.pte)) {
+ /*
+ * huge_pmd_unshare unmapped an entire PMD
+ * page. There is no way of knowing exactly
+ * which PMDs may be cached for this mm, so
+ * we must flush them all. start/end were
+ * already adjusted above to cover this range.
+ */
+ flush_cache_range(vma, start, end);
+ flush_tlb_range(vma, start, end);
+ mmu_notifier_invalidate_range(mm, start, end);
+
+ /*
+ * The ref count of the PMD page was dropped
+ * which is part of the way map counting
+ * is done for shared PMDs. Return 'true'
+ * here. When there is no other sharing,
+ * huge_pmd_unshare returns false and we will
+ * unmap the actual page and drop map count
+ * to zero.
+ */
+ page_vma_mapped_walk_done(&pvmw);
+ break;
+ }
+ }
if (IS_ENABLED(CONFIG_MIGRATION) &&
(flags & TTU_MIGRATION) &&
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 017b1660df89f5fb4bfe66c34e35f7d2031100c7 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Date: Fri, 5 Oct 2018 15:51:29 -0700
Subject: [PATCH] mm: migration: fix migration of huge PMD shared pages
The page migration code employs try_to_unmap() to try and unmap the source
page. This is accomplished by using rmap_walk to find all vmas where the
page is mapped. This search stops when page mapcount is zero. For shared
PMD huge pages, the page map count is always 1 no matter the number of
mappings. Shared mappings are tracked via the reference count of the PMD
page. Therefore, try_to_unmap stops prematurely and does not completely
unmap all mappings of the source page.
This problem can result is data corruption as writes to the original
source page can happen after contents of the page are copied to the target
page. Hence, data is lost.
This problem was originally seen as DB corruption of shared global areas
after a huge page was soft offlined due to ECC memory errors. DB
developers noticed they could reproduce the issue by (hotplug) offlining
memory used to back huge pages. A simple testcase can reproduce the
problem by creating a shared PMD mapping (note that this must be at least
PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using
migrate_pages() to migrate process pages between nodes while continually
writing to the huge pages being migrated.
To fix, have the try_to_unmap_one routine check for huge PMD sharing by
calling huge_pmd_unshare for hugetlbfs huge pages. If it is a shared
mapping it will be 'unshared' which removes the page table entry and drops
the reference on the PMD page. After this, flush caches and TLB.
mmu notifiers are called before locking page tables, but we can not be
sure of PMD sharing until page tables are locked. Therefore, check for
the possibility of PMD sharing before locking so that notifiers can
prepare for the worst possible case.
Link: http://lkml.kernel.org/r/20180823205917.16297-2-mike.kravetz@oracle.com
[mike.kravetz(a)oracle.com: make _range_in_vma() a static inline]
Link: http://lkml.kernel.org/r/6063f215-a5c8-2f0c-465a-2c515ddc952d@oracle.com
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Jerome Glisse <jglisse(a)redhat.com>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 6b68e345f0ca..087fd5f48c91 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -140,6 +140,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pte_t *huge_pte_offset(struct mm_struct *mm,
unsigned long addr, unsigned long sz);
int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep);
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end);
struct page *follow_huge_addr(struct mm_struct *mm, unsigned long address,
int write);
struct page *follow_huge_pd(struct vm_area_struct *vma,
@@ -170,6 +172,18 @@ static inline unsigned long hugetlb_total_pages(void)
return 0;
}
+static inline int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr,
+ pte_t *ptep)
+{
+ return 0;
+}
+
+static inline void adjust_range_if_pmd_sharing_possible(
+ struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+}
+
#define follow_hugetlb_page(m,v,p,vs,a,b,i,w,n) ({ BUG(); 0; })
#define follow_huge_addr(mm, addr, write) ERR_PTR(-EINVAL)
#define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a61ebe8ad4ca..0416a7204be3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2455,6 +2455,12 @@ static inline struct vm_area_struct *find_exact_vma(struct mm_struct *mm,
return vma;
}
+static inline bool range_in_vma(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ return (vma && vma->vm_start <= start && end <= vma->vm_end);
+}
+
#ifdef CONFIG_MMU
pgprot_t vm_get_page_prot(unsigned long vm_flags);
void vma_set_page_prot(struct vm_area_struct *vma);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3c21775f196b..b903d746e132 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4545,12 +4545,40 @@ static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)
/*
* check on proper vm_flags and page table alignment
*/
- if (vma->vm_flags & VM_MAYSHARE &&
- vma->vm_start <= base && end <= vma->vm_end)
+ if (vma->vm_flags & VM_MAYSHARE && range_in_vma(vma, base, end))
return true;
return false;
}
+/*
+ * Determine if start,end range within vma could be mapped by shared pmd.
+ * If yes, adjust start and end to cover range associated with possible
+ * shared pmd mappings.
+ */
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+ unsigned long check_addr = *start;
+
+ if (!(vma->vm_flags & VM_MAYSHARE))
+ return;
+
+ for (check_addr = *start; check_addr < *end; check_addr += PUD_SIZE) {
+ unsigned long a_start = check_addr & PUD_MASK;
+ unsigned long a_end = a_start + PUD_SIZE;
+
+ /*
+ * If sharing is possible, adjust start/end if necessary.
+ */
+ if (range_in_vma(vma, a_start, a_end)) {
+ if (a_start < *start)
+ *start = a_start;
+ if (a_end > *end)
+ *end = a_end;
+ }
+ }
+}
+
/*
* Search for a shareable pmd page for hugetlb. In any case calls pmd_alloc()
* and returns the corresponding pte. While this is not necessary for the
@@ -4648,6 +4676,11 @@ int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
{
return 0;
}
+
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+}
#define want_pmd_share() (0)
#endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
diff --git a/mm/rmap.c b/mm/rmap.c
index eb477809a5c0..1e79fac3186b 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1362,11 +1362,21 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
}
/*
- * We have to assume the worse case ie pmd for invalidation. Note that
- * the page can not be free in this function as call of try_to_unmap()
- * must hold a reference on the page.
+ * For THP, we have to assume the worse case ie pmd for invalidation.
+ * For hugetlb, it could be much worse if we need to do pud
+ * invalidation in the case of pmd sharing.
+ *
+ * Note that the page can not be free in this function as call of
+ * try_to_unmap() must hold a reference on the page.
*/
end = min(vma->vm_end, start + (PAGE_SIZE << compound_order(page)));
+ if (PageHuge(page)) {
+ /*
+ * If sharing is possible, start and end will be adjusted
+ * accordingly.
+ */
+ adjust_range_if_pmd_sharing_possible(vma, &start, &end);
+ }
mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
while (page_vma_mapped_walk(&pvmw)) {
@@ -1409,6 +1419,32 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
subpage = page - page_to_pfn(page) + pte_pfn(*pvmw.pte);
address = pvmw.address;
+ if (PageHuge(page)) {
+ if (huge_pmd_unshare(mm, &address, pvmw.pte)) {
+ /*
+ * huge_pmd_unshare unmapped an entire PMD
+ * page. There is no way of knowing exactly
+ * which PMDs may be cached for this mm, so
+ * we must flush them all. start/end were
+ * already adjusted above to cover this range.
+ */
+ flush_cache_range(vma, start, end);
+ flush_tlb_range(vma, start, end);
+ mmu_notifier_invalidate_range(mm, start, end);
+
+ /*
+ * The ref count of the PMD page was dropped
+ * which is part of the way map counting
+ * is done for shared PMDs. Return 'true'
+ * here. When there is no other sharing,
+ * huge_pmd_unshare returns false and we will
+ * unmap the actual page and drop map count
+ * to zero.
+ */
+ page_vma_mapped_walk_done(&pvmw);
+ break;
+ }
+ }
if (IS_ENABLED(CONFIG_MIGRATION) &&
(flags & TTU_MIGRATION) &&
Hi all,
Here are fixes that worth to have in the @stable, as they were hit by
different people, including Arista on v4.9 stable.
And for linux-next - adding lockdep asserts for line discipline changing
code, verifying that write ldisc sem will be held forthwith.
Mikulas, can you add your tested-by on this patches set again, please?
I tried to reproduce reboot issue on qemu-hppa and even built
cross-compiler for pa-risc.. but was unlucky in reproducing.
Thanks,
Dima
Changes since v5:
- Better commit tags
- Hopefully fixed issue with reboot on pa-risc with Debian 5
Changes since v4:
- back to lock ldisc with (5*HZ) timeout in tty_reopen()
(LKP report link: lkml.kernel.org/r/<1536940609.3185.29.camel(a)arista.com>)
- reordered 3/7 with 2/7 for LKP robot
Changes since v3:
- Added tested-by Mark Rutland (thanks!)
- Dropped patch with smp_wmb() - wrong idea
- lockdep_assert_held() should be actually lockdep_assert_held_exclusive()
- Described why tty_ldisc_open() can be called without ldisc_sem held
for pty slave end (o_tty).
- Added Peter's patch for dropping self-made lockdep annotations
- Fix for a reader(s) of ldisc semaphore waiting for an active reader(s)
Changes since v2:
- Added reviewed-by tags
- Hopefully, fixed reported by 0-day issue.
- Added optional fix for wait_readers decrement
Changes since v1:
- Added tested-by/reported-by tags
- Dropped 3/4 (locking tty pair for lockdep sake),
Because of that - not adding lockdep_assert_held() in tty_ldisc_open()
- Added 4/4 cleanup to inc tty->count only on success of
tty_ldisc_reinit()
- lock ldisc without (5*HZ) timeout in tty_reopen()
v1 link: lkml.kernel.org/r/<20180829022353.23568-1-dima(a)arista.com>
v2 link: lkml.kernel.org/r/<20180903165257.29227-1-dima(a)arista.com>
v3 link: lkml.kernel.org/r/<20180911014821.26286-1-dima(a)arista.com>
v4 link: lkml.kernel.org/r/<20180912001702.18522-1-dima(a)arista.com>
Cc: Daniel Axtens <dja(a)axtens.net>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Mark Rutland <mark.rutland(a)arm.com>
Cc: Michael Neuling <mikey(a)neuling.org>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: Nathan March <nathan(a)gt.net>
Cc: Pasi Kärkkäinen <pasik(a)iki.fi>
Cc: Peter Hurley <peter(a)hurleysoftware.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: "Rong, Chen" <rong.a.chen(a)intel.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com>
Cc: Tan Xiaojun <tanxiaojun(a)huawei.com>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
(please, ignore if I Cc'ed you mistakenly)
Dmitry Safonov (6):
tty/ldsem: Wake up readers after timed out down_write()
tty: Hold tty_ldisc_lock() during tty_reopen()
tty: Don't block on IO when ldisc change is pending
tty: Simplify tty->count math in tty_reopen()
tty/ldsem: Add lockdep asserts for ldisc_sem
tty/ldsem: Decrement wait_readers on timeouted down_read()
Peter Zijlstra (1):
tty/ldsem: Convert to regular lockdep annotations
drivers/tty/n_hdlc.c | 4 +--
drivers/tty/n_r3964.c | 2 +-
drivers/tty/n_tty.c | 8 +++---
drivers/tty/tty_io.c | 14 ++++++----
drivers/tty/tty_ldisc.c | 16 +++++++++++
drivers/tty/tty_ldsem.c | 62 +++++++++++++++++------------------------
include/linux/tty.h | 7 +++++
7 files changed, 63 insertions(+), 50 deletions(-)
--
2.19.1
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 10283ea525d30f2e99828978fd04d8427876a7ad Mon Sep 17 00:00:00 2001
From: Andreas Gruenbacher <agruenba(a)redhat.com>
Date: Mon, 5 Nov 2018 22:57:24 +0000
Subject: [PATCH] gfs2: Put bitmap buffers in put_super
gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects
attached to the resource group glocks. That function should release the
buffers attached to the gfs2_bitmap objects (bi_bh), but the call to
gfs2_rgrp_brelse for doing that is missing.
When gfs2_releasepage later runs across these buffers which are still
referenced, it refuses to free them. This causes the pages the buffers
are attached to to remain referenced as well. With enough mount/unmount
cycles, the system will eventually run out of memory.
Fix this by adding the missing call to gfs2_rgrp_brelse in
gfs2_clear_rgrpd.
(Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.)
Fixes: 39b0f1e92908 ("GFS2: Don't brelse rgrp buffer_heads every allocation")
Cc: stable(a)vger.kernel.org # v4.2+
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index ffe3032b1043..b08a530433ad 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -733,6 +733,7 @@ void gfs2_clear_rgrpd(struct gfs2_sbd *sdp)
if (gl) {
glock_clear_object(gl, rgd);
+ gfs2_rgrp_brelse(rgd);
gfs2_glock_put(gl);
}
@@ -1174,7 +1175,7 @@ static u32 count_unlinked(struct gfs2_rgrpd *rgd)
* @rgd: the struct gfs2_rgrpd describing the RG to read in
*
* Read in all of a Resource Group's header and bitmap blocks.
- * Caller must eventually call gfs2_rgrp_relse() to free the bitmaps.
+ * Caller must eventually call gfs2_rgrp_brelse() to free the bitmaps.
*
* Returns: errno
*/
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 10283ea525d30f2e99828978fd04d8427876a7ad Mon Sep 17 00:00:00 2001
From: Andreas Gruenbacher <agruenba(a)redhat.com>
Date: Mon, 5 Nov 2018 22:57:24 +0000
Subject: [PATCH] gfs2: Put bitmap buffers in put_super
gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects
attached to the resource group glocks. That function should release the
buffers attached to the gfs2_bitmap objects (bi_bh), but the call to
gfs2_rgrp_brelse for doing that is missing.
When gfs2_releasepage later runs across these buffers which are still
referenced, it refuses to free them. This causes the pages the buffers
are attached to to remain referenced as well. With enough mount/unmount
cycles, the system will eventually run out of memory.
Fix this by adding the missing call to gfs2_rgrp_brelse in
gfs2_clear_rgrpd.
(Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.)
Fixes: 39b0f1e92908 ("GFS2: Don't brelse rgrp buffer_heads every allocation")
Cc: stable(a)vger.kernel.org # v4.2+
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index ffe3032b1043..b08a530433ad 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -733,6 +733,7 @@ void gfs2_clear_rgrpd(struct gfs2_sbd *sdp)
if (gl) {
glock_clear_object(gl, rgd);
+ gfs2_rgrp_brelse(rgd);
gfs2_glock_put(gl);
}
@@ -1174,7 +1175,7 @@ static u32 count_unlinked(struct gfs2_rgrpd *rgd)
* @rgd: the struct gfs2_rgrpd describing the RG to read in
*
* Read in all of a Resource Group's header and bitmap blocks.
- * Caller must eventually call gfs2_rgrp_relse() to free the bitmaps.
+ * Caller must eventually call gfs2_rgrp_brelse() to free the bitmaps.
*
* Returns: errno
*/
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From ebacb81273599555a7a19f7754a1451206a5fc4f Mon Sep 17 00:00:00 2001
From: Lukas Czerner <lczerner(a)redhat.com>
Date: Fri, 9 Nov 2018 14:51:46 +0100
Subject: [PATCH] fuse: fix use-after-free in fuse_direct_IO()
In async IO blocking case the additional reference to the io is taken for
it to survive fuse_aio_complete(). In non blocking case this additional
reference is not needed, however we still reference io to figure out
whether to wait for completion or not. This is wrong and will lead to
use-after-free. Fix it by storing blocking information in separate
variable.
This was spotted by KASAN when running generic/208 fstest.
Signed-off-by: Lukas Czerner <lczerner(a)redhat.com>
Reported-by: Zorro Lang <zlang(a)redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: 744742d692e3 ("fuse: Add reference counting for fuse_io_priv")
Cc: <stable(a)vger.kernel.org> # v4.6
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index cc2121b37bf5..b52f9baaa3e7 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2924,10 +2924,12 @@ fuse_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
}
if (io->async) {
+ bool blocking = io->blocking;
+
fuse_aio_complete(io, ret < 0 ? ret : 0, -1);
/* we have a non-extending, async request, so return */
- if (!io->blocking)
+ if (!blocking)
return -EIOCBQUEUED;
wait_for_completion(&wait);
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 763f191af51f127cf8e69cd361f50bf6180768a5 Mon Sep 17 00:00:00 2001
From: Ulf Hansson <ulf.hansson(a)linaro.org>
Date: Thu, 1 Nov 2018 13:22:38 +0100
Subject: [PATCH] ARM: cpuidle: Don't register the driver when back-end init
returns -ENXIO
There's no point to register the cpuidle driver for the current CPU, when
the initialization of the arch specific back-end data fails by returning
-ENXIO.
Instead, let's re-order the sequence to its original flow, by first trying
to initialize the back-end part and then act accordingly on the returned
error code. Additionally, let's print the error message, no matter of what
error code that was returned.
Fixes: a0d46a3dfdc3 (ARM: cpuidle: Register per cpuidle device)
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Cc: 4.19+ <stable(a)vger.kernel.org> # v4.19+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index 073557f433eb..df564d783216 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -103,13 +103,6 @@ static int __init arm_idle_init_cpu(int cpu)
goto out_kfree_drv;
}
- ret = cpuidle_register_driver(drv);
- if (ret) {
- if (ret != -EBUSY)
- pr_err("Failed to register cpuidle driver\n");
- goto out_kfree_drv;
- }
-
/*
* Call arch CPU operations in order to initialize
* idle states suspend back-end specific data
@@ -117,15 +110,20 @@ static int __init arm_idle_init_cpu(int cpu)
ret = arm_cpuidle_init(cpu);
/*
- * Skip the cpuidle device initialization if the reported
+ * Allow the initialization to continue for other CPUs, if the reported
* failure is a HW misconfiguration/breakage (-ENXIO).
*/
- if (ret == -ENXIO)
- return 0;
-
if (ret) {
pr_err("CPU %d failed to init idle CPU ops\n", cpu);
- goto out_unregister_drv;
+ ret = ret == -ENXIO ? 0 : ret;
+ goto out_kfree_drv;
+ }
+
+ ret = cpuidle_register_driver(drv);
+ if (ret) {
+ if (ret != -EBUSY)
+ pr_err("Failed to register cpuidle driver\n");
+ goto out_kfree_drv;
}
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 763f191af51f127cf8e69cd361f50bf6180768a5 Mon Sep 17 00:00:00 2001
From: Ulf Hansson <ulf.hansson(a)linaro.org>
Date: Thu, 1 Nov 2018 13:22:38 +0100
Subject: [PATCH] ARM: cpuidle: Don't register the driver when back-end init
returns -ENXIO
There's no point to register the cpuidle driver for the current CPU, when
the initialization of the arch specific back-end data fails by returning
-ENXIO.
Instead, let's re-order the sequence to its original flow, by first trying
to initialize the back-end part and then act accordingly on the returned
error code. Additionally, let's print the error message, no matter of what
error code that was returned.
Fixes: a0d46a3dfdc3 (ARM: cpuidle: Register per cpuidle device)
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Cc: 4.19+ <stable(a)vger.kernel.org> # v4.19+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index 073557f433eb..df564d783216 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -103,13 +103,6 @@ static int __init arm_idle_init_cpu(int cpu)
goto out_kfree_drv;
}
- ret = cpuidle_register_driver(drv);
- if (ret) {
- if (ret != -EBUSY)
- pr_err("Failed to register cpuidle driver\n");
- goto out_kfree_drv;
- }
-
/*
* Call arch CPU operations in order to initialize
* idle states suspend back-end specific data
@@ -117,15 +110,20 @@ static int __init arm_idle_init_cpu(int cpu)
ret = arm_cpuidle_init(cpu);
/*
- * Skip the cpuidle device initialization if the reported
+ * Allow the initialization to continue for other CPUs, if the reported
* failure is a HW misconfiguration/breakage (-ENXIO).
*/
- if (ret == -ENXIO)
- return 0;
-
if (ret) {
pr_err("CPU %d failed to init idle CPU ops\n", cpu);
- goto out_unregister_drv;
+ ret = ret == -ENXIO ? 0 : ret;
+ goto out_kfree_drv;
+ }
+
+ ret = cpuidle_register_driver(drv);
+ if (ret) {
+ if (ret != -EBUSY)
+ pr_err("Failed to register cpuidle driver\n");
+ goto out_kfree_drv;
}
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 506481b20e818db40b6198815904ecd2d6daee64 Mon Sep 17 00:00:00 2001
From: Robbie Ko <robbieko(a)synology.com>
Date: Tue, 30 Oct 2018 18:04:04 +0800
Subject: [PATCH] Btrfs: fix cur_offset in the error case for nocow
When the cow_file_range fails, the related resources are unlocked
according to the range [start..end), so the unlock cannot be repeated in
run_delalloc_nocow.
In some cases (e.g. cur_offset <= end && cow_start != -1), cur_offset is
not updated correctly, so move the cur_offset update before
cow_file_range.
kernel BUG at mm/page-writeback.c:2663!
Internal error: Oops - BUG: 0 [#1] SMP
CPU: 3 PID: 31525 Comm: kworker/u8:7 Tainted: P O
Hardware name: Realtek_RTD1296 (DT)
Workqueue: writeback wb_workfn (flush-btrfs-1)
task: ffffffc076db3380 ti: ffffffc02e9ac000 task.ti: ffffffc02e9ac000
PC is at clear_page_dirty_for_io+0x1bc/0x1e8
LR is at clear_page_dirty_for_io+0x14/0x1e8
pc : [<ffffffc00033c91c>] lr : [<ffffffc00033c774>] pstate: 40000145
sp : ffffffc02e9af4f0
Process kworker/u8:7 (pid: 31525, stack limit = 0xffffffc02e9ac020)
Call trace:
[<ffffffc00033c91c>] clear_page_dirty_for_io+0x1bc/0x1e8
[<ffffffbffc514674>] extent_clear_unlock_delalloc+0x1e4/0x210 [btrfs]
[<ffffffbffc4fb168>] run_delalloc_nocow+0x3b8/0x948 [btrfs]
[<ffffffbffc4fb948>] run_delalloc_range+0x250/0x3a8 [btrfs]
[<ffffffbffc514c0c>] writepage_delalloc.isra.21+0xbc/0x1d8 [btrfs]
[<ffffffbffc516048>] __extent_writepage+0xe8/0x248 [btrfs]
[<ffffffbffc51630c>] extent_write_cache_pages.isra.17+0x164/0x378 [btrfs]
[<ffffffbffc5185a8>] extent_writepages+0x48/0x68 [btrfs]
[<ffffffbffc4f5828>] btrfs_writepages+0x20/0x30 [btrfs]
[<ffffffc00033d758>] do_writepages+0x30/0x88
[<ffffffc0003ba0f4>] __writeback_single_inode+0x34/0x198
[<ffffffc0003ba6c4>] writeback_sb_inodes+0x184/0x3c0
[<ffffffc0003ba96c>] __writeback_inodes_wb+0x6c/0xc0
[<ffffffc0003bac20>] wb_writeback+0x1b8/0x1c0
[<ffffffc0003bb0f0>] wb_workfn+0x150/0x250
[<ffffffc0002b0014>] process_one_work+0x1dc/0x388
[<ffffffc0002b02f0>] worker_thread+0x130/0x500
[<ffffffc0002b6344>] kthread+0x10c/0x110
[<ffffffc000284590>] ret_from_fork+0x10/0x40
Code: d503201f a9025bb5 a90363b7 f90023b9 (d4210000)
CC: stable(a)vger.kernel.org # 4.4+
Reviewed-by: Filipe Manana <fdmanana(a)suse.com>
Signed-off-by: Robbie Ko <robbieko(a)synology.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index f4d31fd62eed..55761b1519f5 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1531,12 +1531,11 @@ static noinline int run_delalloc_nocow(struct inode *inode,
}
btrfs_release_path(path);
- if (cur_offset <= end && cow_start == (u64)-1) {
+ if (cur_offset <= end && cow_start == (u64)-1)
cow_start = cur_offset;
- cur_offset = end;
- }
if (cow_start != (u64)-1) {
+ cur_offset = end;
ret = cow_file_range(inode, locked_page, cow_start, end, end,
page_started, nr_written, 1, NULL);
if (ret)
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 81bd415c91eb966118d773dddf254aebf3022411 Mon Sep 17 00:00:00 2001
From: Mathieu Malaterre <malat(a)debian.org>
Date: Wed, 6 Jun 2018 21:42:32 +0200
Subject: [PATCH] watchdog/core: Add missing prototypes for weak functions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The split out of the hard lockup detector exposed two new weak functions,
but no prototypes for them, which triggers the build warning:
kernel/watchdog.c:109:12: warning: no previous prototype for ‘watchdog_nmi_enable’ [-Wmissing-prototypes]
kernel/watchdog.c:115:13: warning: no previous prototype for ‘watchdog_nmi_disable’ [-Wmissing-prototypes]
Add the prototypes.
Fixes: 73ce0511c436 ("kernel/watchdog.c: move hardlockup detector to separate file")
Signed-off-by: Mathieu Malaterre <malat(a)debian.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Babu Moger <babu.moger(a)oracle.com>
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20180606194232.17653-1-malat@debian.org
diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index 08f9247e9827..9003e29cde46 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -119,6 +119,8 @@ static inline int hardlockup_detector_perf_init(void) { return 0; }
void watchdog_nmi_stop(void);
void watchdog_nmi_start(void);
int watchdog_nmi_probe(void);
+int watchdog_nmi_enable(unsigned int cpu);
+void watchdog_nmi_disable(unsigned int cpu);
/**
* touch_nmi_watchdog - restart NMI watchdog timeout.
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From ea53abfab960909d622ca37bcfb8e1c5378d21cc Mon Sep 17 00:00:00 2001
From: Jarod Wilson <jarod(a)redhat.com>
Date: Sun, 4 Nov 2018 14:59:46 -0500
Subject: [PATCH] bonding/802.3ad: fix link_failure_count tracking
Commit 4d2c0cda07448ea6980f00102dc3964eb25e241c set slave->link to
BOND_LINK_DOWN for 802.3ad bonds whenever invalid speed/duplex values
were read, to fix a problem with slaves getting into weird states, but
in the process, broke tracking of link failures, as going straight to
BOND_LINK_DOWN when a link is indeed down (cable pulled, switch rebooted)
means we broke out of bond_miimon_inspect()'s BOND_LINK_DOWN case because
!link_state was already true, we never incremented commit, and never got
a chance to call bond_miimon_commit(), where slave->link_failure_count
would be incremented. I believe the simple fix here is to mark the slave
as BOND_LINK_FAIL, and let bond_miimon_inspect() transition the link from
_FAIL to either _UP or _DOWN, and in the latter case, we now get proper
incrementing of link_failure_count again.
Fixes: 4d2c0cda0744 ("bonding: speed/duplex update at NETDEV_UP event")
CC: Mahesh Bandewar <maheshb(a)google.com>
CC: David S. Miller <davem(a)davemloft.net>
CC: netdev(a)vger.kernel.org
CC: stable(a)vger.kernel.org
Signed-off-by: Jarod Wilson <jarod(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index ffa37adb7681..333387f1f1fe 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3112,13 +3112,13 @@ static int bond_slave_netdev_event(unsigned long event,
case NETDEV_CHANGE:
/* For 802.3ad mode only:
* Getting invalid Speed/Duplex values here will put slave
- * in weird state. So mark it as link-down for the time
+ * in weird state. So mark it as link-fail for the time
* being and let link-monitoring (miimon) set it right when
* correct speeds/duplex are available.
*/
if (bond_update_speed_duplex(slave) &&
BOND_MODE(bond) == BOND_MODE_8023AD)
- slave->link = BOND_LINK_DOWN;
+ slave->link = BOND_LINK_FAIL;
if (BOND_MODE(bond) == BOND_MODE_8023AD)
bond_3ad_adapter_speed_duplex_changed(slave);
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 53c613fe6349994f023245519265999eed75957f Mon Sep 17 00:00:00 2001
From: Jiri Kosina <jkosina(a)suse.cz>
Date: Tue, 25 Sep 2018 14:38:55 +0200
Subject: [PATCH] x86/speculation: Enable cross-hyperthread spectre v2 STIBP
mitigation
STIBP is a feature provided by certain Intel ucodes / CPUs. This feature
(once enabled) prevents cross-hyperthread control of decisions made by
indirect branch predictors.
Enable this feature if
- the CPU is vulnerable to spectre v2
- the CPU supports SMT and has SMT siblings online
- spectre_v2 mitigation autoselection is enabled (default)
After some previous discussion, this leaves STIBP on all the time, as wrmsr
on crossing kernel boundary is a no-no. This could perhaps later be a bit
more optimized (like disabling it in NOHZ, experiment with disabling it in
idle, etc) if needed.
Note that the synchronization of the mask manipulation via newly added
spec_ctrl_mutex is currently not strictly needed, as the only updater is
already being serialized by cpu_add_remove_lock, but let's make this a
little bit more future-proof.
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: "WoodhouseDavid" <dwmw(a)amazon.co.uk>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: "SchauflerCasey" <casey.schaufler(a)intel.com>
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.1809251438240.15880@cbobk.fhfr.pm
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 40bdaea97fe7..53eb14a65610 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -35,12 +35,10 @@ static void __init spectre_v2_select_mitigation(void);
static void __init ssb_select_mitigation(void);
static void __init l1tf_select_mitigation(void);
-/*
- * Our boot-time value of the SPEC_CTRL MSR. We read it once so that any
- * writes to SPEC_CTRL contain whatever reserved bits have been set.
- */
-u64 __ro_after_init x86_spec_ctrl_base;
+/* The base value of the SPEC_CTRL MSR that always has to be preserved. */
+u64 x86_spec_ctrl_base;
EXPORT_SYMBOL_GPL(x86_spec_ctrl_base);
+static DEFINE_MUTEX(spec_ctrl_mutex);
/*
* The vendor and possibly platform specific bits which can be modified in
@@ -325,6 +323,46 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool stibp_needed(void)
+{
+ if (spectre_v2_enabled == SPECTRE_V2_NONE)
+ return false;
+
+ if (!boot_cpu_has(X86_FEATURE_STIBP))
+ return false;
+
+ return true;
+}
+
+static void update_stibp_msr(void *info)
+{
+ wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+}
+
+void arch_smt_update(void)
+{
+ u64 mask;
+
+ if (!stibp_needed())
+ return;
+
+ mutex_lock(&spec_ctrl_mutex);
+ mask = x86_spec_ctrl_base;
+ if (cpu_smt_control == CPU_SMT_ENABLED)
+ mask |= SPEC_CTRL_STIBP;
+ else
+ mask &= ~SPEC_CTRL_STIBP;
+
+ if (mask != x86_spec_ctrl_base) {
+ pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
+ cpu_smt_control == CPU_SMT_ENABLED ?
+ "Enabling" : "Disabling");
+ x86_spec_ctrl_base = mask;
+ on_each_cpu(update_stibp_msr, NULL, 1);
+ }
+ mutex_unlock(&spec_ctrl_mutex);
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -424,6 +462,9 @@ static void __init spectre_v2_select_mitigation(void)
setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
pr_info("Enabling Restricted Speculation for firmware calls\n");
}
+
+ /* Enable STIBP if appropriate */
+ arch_smt_update();
}
#undef pr_fmt
@@ -814,6 +855,8 @@ static ssize_t l1tf_show_state(char *buf)
static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr,
char *buf, unsigned int bug)
{
+ int ret;
+
if (!boot_cpu_has_bug(bug))
return sprintf(buf, "Not affected\n");
@@ -831,10 +874,12 @@ static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr
return sprintf(buf, "Mitigation: __user pointer sanitization\n");
case X86_BUG_SPECTRE_V2:
- return sprintf(buf, "%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled],
+ ret = sprintf(buf, "%s%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled],
boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" : "",
boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "",
+ (x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ", STIBP" : "",
spectre_v2_module_string());
+ return ret;
case X86_BUG_SPEC_STORE_BYPASS:
return sprintf(buf, "%s\n", ssb_strings[ssb_mode]);
diff --git a/kernel/cpu.c b/kernel/cpu.c
index aa7fe85ad62e..2fb49916ea56 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2025,6 +2025,12 @@ static void cpuhp_online_cpu_device(unsigned int cpu)
kobject_uevent(&dev->kobj, KOBJ_ONLINE);
}
+/*
+ * Architectures that need SMT-specific errata handling during SMT hotplug
+ * should override this.
+ */
+void __weak arch_smt_update(void) { };
+
static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
@@ -2051,8 +2057,10 @@ static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
*/
cpuhp_offline_cpu_device(cpu);
}
- if (!ret)
+ if (!ret) {
cpu_smt_control = ctrlval;
+ arch_smt_update();
+ }
cpu_maps_update_done();
return ret;
}
@@ -2063,6 +2071,7 @@ static int cpuhp_smt_enable(void)
cpu_maps_update_begin();
cpu_smt_control = CPU_SMT_ENABLED;
+ arch_smt_update();
for_each_present_cpu(cpu) {
/* Skip online CPUs and CPUs on offline nodes */
if (cpu_online(cpu) || !node_online(cpu_to_node(cpu)))
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 3fa58dcab50a0aa16817f16a8d38aee869eb3fb9 Mon Sep 17 00:00:00 2001
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Thu, 1 Nov 2018 00:30:22 -0700
Subject: [PATCH] acpi, nfit: Fix ARS overflow continuation
When the platform BIOS is unable to report all the media error records
it requires the OS to restart the scrub at a prescribed location. The
driver detects the overflow condition, but then fails to report it to
the ARS state machine after reaping the records. Propagate -ENOSPC
correctly to continue the ARS operation.
Cc: <stable(a)vger.kernel.org>
Fixes: 1cf03c00e7c1 ("nfit: scrub and register regions in a workqueue")
Reported-by: Jacek Zloch <jacek.zloch(a)intel.com>
Reviewed-by: Dave Jiang <dave.jiang(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index f8c638f3c946..5970b8f5f768 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2928,9 +2928,9 @@ static int acpi_nfit_query_poison(struct acpi_nfit_desc *acpi_desc)
return rc;
if (ars_status_process_records(acpi_desc))
- return -ENOMEM;
+ dev_err(acpi_desc->dev, "Failed to process ARS records\n");
- return 0;
+ return rc;
}
static int ars_register(struct acpi_nfit_desc *acpi_desc,
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 3fa58dcab50a0aa16817f16a8d38aee869eb3fb9 Mon Sep 17 00:00:00 2001
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Thu, 1 Nov 2018 00:30:22 -0700
Subject: [PATCH] acpi, nfit: Fix ARS overflow continuation
When the platform BIOS is unable to report all the media error records
it requires the OS to restart the scrub at a prescribed location. The
driver detects the overflow condition, but then fails to report it to
the ARS state machine after reaping the records. Propagate -ENOSPC
correctly to continue the ARS operation.
Cc: <stable(a)vger.kernel.org>
Fixes: 1cf03c00e7c1 ("nfit: scrub and register regions in a workqueue")
Reported-by: Jacek Zloch <jacek.zloch(a)intel.com>
Reviewed-by: Dave Jiang <dave.jiang(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index f8c638f3c946..5970b8f5f768 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2928,9 +2928,9 @@ static int acpi_nfit_query_poison(struct acpi_nfit_desc *acpi_desc)
return rc;
if (ars_status_process_records(acpi_desc))
- return -ENOMEM;
+ dev_err(acpi_desc->dev, "Failed to process ARS records\n");
- return 0;
+ return rc;
}
static int ars_register(struct acpi_nfit_desc *acpi_desc,
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e8a308e5f47e545e0d41d0686c00f5f5217c5f61 Mon Sep 17 00:00:00 2001
From: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Thu, 25 Oct 2018 18:37:29 -0600
Subject: [PATCH] acpi/nfit, x86/mce: Validate a MCE's address before using it
The NFIT machine check handler uses the physical address from the mce
structure, and compares it against information in the ACPI NFIT table
to determine whether that location lies on an NVDIMM. The mce->addr
field however may not always be valid, and this is indicated by the
MCI_STATUS_ADDRV bit in the status field.
Export mce_usable_address() which already performs validation for the
address, and use it in the NFIT handler.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Robert Elliott <elliott(a)hpe.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
CC: Arnd Bergmann <arnd(a)arndb.de>
Cc: Dan Williams <dan.j.williams(a)intel.com>
CC: Dave Jiang <dave.jiang(a)intel.com>
CC: elliott(a)hpe.com
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: Ingo Molnar <mingo(a)redhat.com>
CC: Len Brown <lenb(a)kernel.org>
CC: linux-acpi(a)vger.kernel.org
CC: linux-edac <linux-edac(a)vger.kernel.org>
CC: linux-nvdimm(a)lists.01.org
CC: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
CC: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
CC: Ross Zwisler <zwisler(a)kernel.org>
CC: stable <stable(a)vger.kernel.org>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Tony Luck <tony.luck(a)intel.com>
CC: x86-ml <x86(a)kernel.org>
CC: Yazen Ghannam <yazen.ghannam(a)amd.com>
Link: http://lkml.kernel.org/r/20181026003729.8420-2-vishal.l.verma@intel.com
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index dbd9fe2f6163..c1a812bd5a27 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -222,6 +222,7 @@ static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return mce_am
int mce_available(struct cpuinfo_x86 *c);
bool mce_is_memory_error(struct mce *m);
bool mce_is_correctable(struct mce *m);
+int mce_usable_address(struct mce *m);
DECLARE_PER_CPU(unsigned, mce_exception_count);
DECLARE_PER_CPU(unsigned, mce_poll_count);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 77527b8ea982..36d2696c9563 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -485,7 +485,7 @@ static void mce_report_event(struct pt_regs *regs)
* be somewhat complicated (e.g. segment offset would require an instruction
* parser). So only support physical addresses up to page granuality for now.
*/
-static int mce_usable_address(struct mce *m)
+int mce_usable_address(struct mce *m)
{
if (!(m->status & MCI_STATUS_ADDRV))
return 0;
@@ -505,6 +505,7 @@ static int mce_usable_address(struct mce *m)
return 1;
}
+EXPORT_SYMBOL_GPL(mce_usable_address);
bool mce_is_memory_error(struct mce *m)
{
diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c
index 7a51707f87e9..d6c1b10f6c25 100644
--- a/drivers/acpi/nfit/mce.c
+++ b/drivers/acpi/nfit/mce.c
@@ -29,6 +29,10 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,
if (!mce_is_memory_error(mce) || mce_is_correctable(mce))
return NOTIFY_DONE;
+ /* Verify the address reported in the MCE is valid. */
+ if (!mce_usable_address(mce))
+ return NOTIFY_DONE;
+
/*
* mce->addr contains the physical addr accessed that caused the
* machine check. We need to walk through the list of NFITs, and see
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e8a308e5f47e545e0d41d0686c00f5f5217c5f61 Mon Sep 17 00:00:00 2001
From: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Thu, 25 Oct 2018 18:37:29 -0600
Subject: [PATCH] acpi/nfit, x86/mce: Validate a MCE's address before using it
The NFIT machine check handler uses the physical address from the mce
structure, and compares it against information in the ACPI NFIT table
to determine whether that location lies on an NVDIMM. The mce->addr
field however may not always be valid, and this is indicated by the
MCI_STATUS_ADDRV bit in the status field.
Export mce_usable_address() which already performs validation for the
address, and use it in the NFIT handler.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Robert Elliott <elliott(a)hpe.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
CC: Arnd Bergmann <arnd(a)arndb.de>
Cc: Dan Williams <dan.j.williams(a)intel.com>
CC: Dave Jiang <dave.jiang(a)intel.com>
CC: elliott(a)hpe.com
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: Ingo Molnar <mingo(a)redhat.com>
CC: Len Brown <lenb(a)kernel.org>
CC: linux-acpi(a)vger.kernel.org
CC: linux-edac <linux-edac(a)vger.kernel.org>
CC: linux-nvdimm(a)lists.01.org
CC: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
CC: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
CC: Ross Zwisler <zwisler(a)kernel.org>
CC: stable <stable(a)vger.kernel.org>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Tony Luck <tony.luck(a)intel.com>
CC: x86-ml <x86(a)kernel.org>
CC: Yazen Ghannam <yazen.ghannam(a)amd.com>
Link: http://lkml.kernel.org/r/20181026003729.8420-2-vishal.l.verma@intel.com
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index dbd9fe2f6163..c1a812bd5a27 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -222,6 +222,7 @@ static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return mce_am
int mce_available(struct cpuinfo_x86 *c);
bool mce_is_memory_error(struct mce *m);
bool mce_is_correctable(struct mce *m);
+int mce_usable_address(struct mce *m);
DECLARE_PER_CPU(unsigned, mce_exception_count);
DECLARE_PER_CPU(unsigned, mce_poll_count);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 77527b8ea982..36d2696c9563 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -485,7 +485,7 @@ static void mce_report_event(struct pt_regs *regs)
* be somewhat complicated (e.g. segment offset would require an instruction
* parser). So only support physical addresses up to page granuality for now.
*/
-static int mce_usable_address(struct mce *m)
+int mce_usable_address(struct mce *m)
{
if (!(m->status & MCI_STATUS_ADDRV))
return 0;
@@ -505,6 +505,7 @@ static int mce_usable_address(struct mce *m)
return 1;
}
+EXPORT_SYMBOL_GPL(mce_usable_address);
bool mce_is_memory_error(struct mce *m)
{
diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c
index 7a51707f87e9..d6c1b10f6c25 100644
--- a/drivers/acpi/nfit/mce.c
+++ b/drivers/acpi/nfit/mce.c
@@ -29,6 +29,10 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,
if (!mce_is_memory_error(mce) || mce_is_correctable(mce))
return NOTIFY_DONE;
+ /* Verify the address reported in the MCE is valid. */
+ if (!mce_usable_address(mce))
+ return NOTIFY_DONE;
+
/*
* mce->addr contains the physical addr accessed that caused the
* machine check. We need to walk through the list of NFITs, and see
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5d96c9342c23ee1d084802dcf064caa67ecaa45b Mon Sep 17 00:00:00 2001
From: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Thu, 25 Oct 2018 18:37:28 -0600
Subject: [PATCH] acpi/nfit, x86/mce: Handle only uncorrectable machine checks
The MCE handler for nfit devices is called for memory errors on a
Non-Volatile DIMM and adds the error location to a 'badblocks' list.
This list is used by the various NVDIMM drivers to avoid consuming known
poison locations during IO.
The MCE handler gets called for both corrected and uncorrectable errors.
Until now, both kinds of errors have been added to the badblocks list.
However, corrected memory errors indicate that the problem has already
been fixed by hardware, and the resulting interrupt is merely a
notification to Linux.
As far as future accesses to that location are concerned, it is
perfectly fine to use, and thus doesn't need to be included in the above
badblocks list.
Add a check in the nfit MCE handler to filter out corrected mce events,
and only process uncorrectable errors.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Omar Avelar <omar.avelar(a)intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
CC: Arnd Bergmann <arnd(a)arndb.de>
CC: Dan Williams <dan.j.williams(a)intel.com>
CC: Dave Jiang <dave.jiang(a)intel.com>
CC: elliott(a)hpe.com
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: Ingo Molnar <mingo(a)redhat.com>
CC: Len Brown <lenb(a)kernel.org>
CC: linux-acpi(a)vger.kernel.org
CC: linux-edac <linux-edac(a)vger.kernel.org>
CC: linux-nvdimm(a)lists.01.org
CC: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
CC: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
CC: Ross Zwisler <zwisler(a)kernel.org>
CC: stable <stable(a)vger.kernel.org>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Tony Luck <tony.luck(a)intel.com>
CC: x86-ml <x86(a)kernel.org>
CC: Yazen Ghannam <yazen.ghannam(a)amd.com>
Link: http://lkml.kernel.org/r/20181026003729.8420-1-vishal.l.verma@intel.com
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 4da9b1c58d28..dbd9fe2f6163 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -221,6 +221,7 @@ static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return mce_am
int mce_available(struct cpuinfo_x86 *c);
bool mce_is_memory_error(struct mce *m);
+bool mce_is_correctable(struct mce *m);
DECLARE_PER_CPU(unsigned, mce_exception_count);
DECLARE_PER_CPU(unsigned, mce_poll_count);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 8c66d2fc8f81..77527b8ea982 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -534,7 +534,7 @@ bool mce_is_memory_error(struct mce *m)
}
EXPORT_SYMBOL_GPL(mce_is_memory_error);
-static bool mce_is_correctable(struct mce *m)
+bool mce_is_correctable(struct mce *m)
{
if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED)
return false;
@@ -547,6 +547,7 @@ static bool mce_is_correctable(struct mce *m)
return true;
}
+EXPORT_SYMBOL_GPL(mce_is_correctable);
static bool cec_add_mce(struct mce *m)
{
diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c
index e9626bf6ca29..7a51707f87e9 100644
--- a/drivers/acpi/nfit/mce.c
+++ b/drivers/acpi/nfit/mce.c
@@ -25,8 +25,8 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,
struct acpi_nfit_desc *acpi_desc;
struct nfit_spa *nfit_spa;
- /* We only care about memory errors */
- if (!mce_is_memory_error(mce))
+ /* We only care about uncorrectable memory errors */
+ if (!mce_is_memory_error(mce) || mce_is_correctable(mce))
return NOTIFY_DONE;
/*
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5d96c9342c23ee1d084802dcf064caa67ecaa45b Mon Sep 17 00:00:00 2001
From: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Thu, 25 Oct 2018 18:37:28 -0600
Subject: [PATCH] acpi/nfit, x86/mce: Handle only uncorrectable machine checks
The MCE handler for nfit devices is called for memory errors on a
Non-Volatile DIMM and adds the error location to a 'badblocks' list.
This list is used by the various NVDIMM drivers to avoid consuming known
poison locations during IO.
The MCE handler gets called for both corrected and uncorrectable errors.
Until now, both kinds of errors have been added to the badblocks list.
However, corrected memory errors indicate that the problem has already
been fixed by hardware, and the resulting interrupt is merely a
notification to Linux.
As far as future accesses to that location are concerned, it is
perfectly fine to use, and thus doesn't need to be included in the above
badblocks list.
Add a check in the nfit MCE handler to filter out corrected mce events,
and only process uncorrectable errors.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Omar Avelar <omar.avelar(a)intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
CC: Arnd Bergmann <arnd(a)arndb.de>
CC: Dan Williams <dan.j.williams(a)intel.com>
CC: Dave Jiang <dave.jiang(a)intel.com>
CC: elliott(a)hpe.com
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: Ingo Molnar <mingo(a)redhat.com>
CC: Len Brown <lenb(a)kernel.org>
CC: linux-acpi(a)vger.kernel.org
CC: linux-edac <linux-edac(a)vger.kernel.org>
CC: linux-nvdimm(a)lists.01.org
CC: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
CC: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
CC: Ross Zwisler <zwisler(a)kernel.org>
CC: stable <stable(a)vger.kernel.org>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Tony Luck <tony.luck(a)intel.com>
CC: x86-ml <x86(a)kernel.org>
CC: Yazen Ghannam <yazen.ghannam(a)amd.com>
Link: http://lkml.kernel.org/r/20181026003729.8420-1-vishal.l.verma@intel.com
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 4da9b1c58d28..dbd9fe2f6163 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -221,6 +221,7 @@ static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return mce_am
int mce_available(struct cpuinfo_x86 *c);
bool mce_is_memory_error(struct mce *m);
+bool mce_is_correctable(struct mce *m);
DECLARE_PER_CPU(unsigned, mce_exception_count);
DECLARE_PER_CPU(unsigned, mce_poll_count);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 8c66d2fc8f81..77527b8ea982 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -534,7 +534,7 @@ bool mce_is_memory_error(struct mce *m)
}
EXPORT_SYMBOL_GPL(mce_is_memory_error);
-static bool mce_is_correctable(struct mce *m)
+bool mce_is_correctable(struct mce *m)
{
if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED)
return false;
@@ -547,6 +547,7 @@ static bool mce_is_correctable(struct mce *m)
return true;
}
+EXPORT_SYMBOL_GPL(mce_is_correctable);
static bool cec_add_mce(struct mce *m)
{
diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c
index e9626bf6ca29..7a51707f87e9 100644
--- a/drivers/acpi/nfit/mce.c
+++ b/drivers/acpi/nfit/mce.c
@@ -25,8 +25,8 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,
struct acpi_nfit_desc *acpi_desc;
struct nfit_spa *nfit_spa;
- /* We only care about memory errors */
- if (!mce_is_memory_error(mce))
+ /* We only care about uncorrectable memory errors */
+ if (!mce_is_memory_error(mce) || mce_is_correctable(mce))
return NOTIFY_DONE;
/*
This reverts commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3.
Turns out that commit is wrong. Host controllers are allowed to use
Clear Feature HALT as means to sync data toggle between host and
periperal.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/dwc3/gadget.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 9faad896b3a1..9f92ee03dde7 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1470,9 +1470,6 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
unsigned transfer_in_flight;
unsigned started;
- if (dep->flags & DWC3_EP_STALL)
- return 0;
-
if (dep->number > 1)
trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
else
@@ -1494,8 +1491,6 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
else
dep->flags |= DWC3_EP_STALL;
} else {
- if (!(dep->flags & DWC3_EP_STALL))
- return 0;
ret = dwc3_send_clear_stall_ep_cmd(dep);
if (ret)
--
2.19.1
Hi,
that patch is not 100% correct. You can revert it in your tree. I added
that because of a problem I found when running adb against macOS.
It's actually okay to send Clear Halt at any time, but for some reason
dwc3 was hanging when running adb against macOS.
If you can revert the patch and make sure it works against all 3 major
OSes (linux, windows and mac) I'd be really glad.
liangshengjun <liangshengjun(a)hisilicon.com> writes:
> Hi felipe,
>
> I have met a case about set/clear Halt patch
> Version: linux v4.16,
> Case: usb uvc run with bulk-mode connect to Windows 7 PC. When PC stop camera application , it would send clearHalt request to uvc device to streaming-off video transfer.
> But with v4.16 dwc3 drivers, it would skip handling this clear Halt request , because dep->flags is not DWC3_EP_STALL status, then it causes PC restart camera application , uvc transfer fail.
> And I have confirmed v3.18 dwc3 drivers is OK.
>
> So how to balance for handling clear Halt without first setHalt ??
>
> PS:
> commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3
> Author: Felipe Balbi <felipe.balbi(a)linux.intel.com>
> Date: Thu Jan 19 13:38:42 2017 +0200
>
> usb: dwc3: gadget: skip Set/Clear Halt when invalid
>
> At least macOS seems to be sending
> ClearFeature(ENDPOINT_HALT) to endpoints which
> aren't Halted. This makes DWC3's CLEARSTALL command
> time out which causes several issues for the driver.
>
> Instead, let's just return 0 and bail out early.
>
> Cc: <stable(a)vger.kernel.org>
> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 6faf484..0a664d8 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1379,6 +1379,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
> unsigned transfer_in_flight;
> unsigned started;
>
> + if (dep->flags & DWC3_EP_STALL)
> + return 0;
> +
> if (dep->number > 1)
> trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
> else
> @@ -1400,6 +1403,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
> else
> dep->flags |= DWC3_EP_STALL;
> } else {
> + if (!(dep->flags & DWC3_EP_STALL))
> + return 0;
>
> ret = dwc3_send_clear_stall_ep_cmd(dep);
> if (ret)
>
>
> Liang Shengjun
> [cid:image001.png@01D40971.9265B340]
> HISILICON TECHNOLOGIES CO., LTD.
> New R&D Center, Wuhe Road, Bantian,
> Longgang District, Shenzhen 518129 P.R. China
>
--
balbi
Hi Greg,
I noticed that 3.18.125 added commit bc07ee33284a ('Revert "drm/i915:
Fix mutex->owner inspection race under DEBUG_MUTEXES"'), which states
that the reason it can be applied is:
The core fix was applied in
commit a63b03e2d2477586440741677ecac45bcf28d7b1
Author: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Tue Jan 6 10:29:35 2015 +0000
mutex: Always clear owner field upon mutex_unlock()
(note the absence of stable@ tag)
so we can now revert our band-aid commit 226e5ae9e5f910 for -next.
but that the commit referenced wasn't also pulled in.
Please consider pulling that one too if you're going to do another 3.18
stable release.
Thanks,
Tom
Use the new of_get_compatible_child() helper to lookup the nfc child
node instead of using of_find_compatible_node(), which searches the
entire tree from a given start node and thus can return an unrelated
(i.e. non-child) node.
This also addresses a potential use-after-free (e.g. after probe
deferral) as the tree-wide helper drops a reference to its first
argument (i.e. the node of the device being probed).
While at it, also fix a related nfc-node reference leak.
Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Cc: stable <stable(a)vger.kernel.org> # 4.11
Cc: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: Josh Wu <rainyfeeling(a)outlook.com>
Cc: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index a068b214ebaa..d3dfe63956ac 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -2061,8 +2061,7 @@ atmel_hsmc_nand_controller_legacy_init(struct atmel_hsmc_nand_controller *nc)
int ret;
nand_np = dev->of_node;
- nfc_np = of_find_compatible_node(dev->of_node, NULL,
- "atmel,sama5d3-nfc");
+ nfc_np = of_get_compatible_child(dev->of_node, "atmel,sama5d3-nfc");
nc->clk = of_clk_get(nfc_np, 0);
if (IS_ERR(nc->clk)) {
@@ -2472,15 +2471,19 @@ static int atmel_nand_controller_probe(struct platform_device *pdev)
}
if (caps->legacy_of_bindings) {
+ struct device_node *nfc_node;
u32 ale_offs = 21;
/*
* If we are parsing legacy DT props and the DT contains a
* valid NFC node, forward the request to the sama5 logic.
*/
- if (of_find_compatible_node(pdev->dev.of_node, NULL,
- "atmel,sama5d3-nfc"))
+ nfc_node = of_get_compatible_child(pdev->dev.of_node,
+ "atmel,sama5d3-nfc");
+ if (nfc_node) {
caps = &atmel_sama5_nand_caps;
+ of_node_put(nfc_node);
+ }
/*
* Even if the compatible says we are dealing with an
--
2.18.0
From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Subject: scripts/spdxcheck.py: make python3 compliant
Without this change the following happens when using Python3 (3.6.6):
$ echo "GPL-2.0" | python3 scripts/spdxcheck.py -
FAIL: 'str' object has no attribute 'decode'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 253, in <module>
parser.parse_lines(sys.stdin, args.maxlines, '-')
File "scripts/spdxcheck.py", line 171, in parse_lines
line = line.decode(locale.getpreferredencoding(False), errors='ignore')
AttributeError: 'str' object has no attribute 'decode'
So as the line is already a string, there is no need to decode it and
the line can be dropped.
/usr/bin/python on Arch is Python 3. So this would indeed be worth
going into 4.19.
Link: http://lkml.kernel.org/r/20181023070802.22558-1-u.kleine-koenig@pengutronix…
Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Joe Perches <joe(a)perches.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/scripts/spdxcheck.py~scripts-spdxcheck-make-python3-compliant
+++ a/scripts/spdxcheck.py
@@ -168,7 +168,6 @@ class id_parser(object):
self.curline = 0
try:
for line in fd:
- line = line.decode(locale.getpreferredencoding(False), errors='ignore')
self.curline += 1
if self.curline > maxlines:
break
_
From: Daniel Colascione <dancol(a)google.com>
commit 1ae80cf31938c8f77c37a29bbe29e7f1cd492be8 upstream.
The map-in-map frequently serves as a mechanism for atomic
snapshotting of state that a BPF program might record. The current
implementation is dangerous to use in this way, however, since
userspace has no way of knowing when all programs that might have
retrieved the "old" value of the map may have completed.
This change ensures that map update operations on map-in-map map types
always wait for all references to the old map to drop before returning
to userspace.
Signed-off-by: Daniel Colascione <dancol(a)google.com>
Reviewed-by: Joel Fernandes (Google) <joel(a)joelfernandes.org>
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
[fengc(a)google.com: 4.19 clean cherry-picks, no modification]
Signed-off-by: Chenbo Feng <fengc(a)google.com>
---
kernel/bpf/syscall.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 8339d81cba1d..675eb6d36e47 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -741,6 +741,17 @@ static int map_lookup_elem(union bpf_attr *attr)
return err;
}
+static void maybe_wait_bpf_programs(struct bpf_map *map)
+{
+ /* Wait for any running BPF programs to complete so that
+ * userspace, when we return to it, knows that all programs
+ * that could be running use the new map value.
+ */
+ if (map->map_type == BPF_MAP_TYPE_HASH_OF_MAPS ||
+ map->map_type == BPF_MAP_TYPE_ARRAY_OF_MAPS)
+ synchronize_rcu();
+}
+
#define BPF_MAP_UPDATE_ELEM_LAST_FIELD flags
static int map_update_elem(union bpf_attr *attr)
@@ -831,6 +842,7 @@ static int map_update_elem(union bpf_attr *attr)
}
__this_cpu_dec(bpf_prog_active);
preempt_enable();
+ maybe_wait_bpf_programs(map);
out:
free_value:
kfree(value);
@@ -883,6 +895,7 @@ static int map_delete_elem(union bpf_attr *attr)
rcu_read_unlock();
__this_cpu_dec(bpf_prog_active);
preempt_enable();
+ maybe_wait_bpf_programs(map);
out:
kfree(key);
err_put:
--
2.19.1.930.g4563a0d9d0-goog
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 99a3ae51d557d8e38a7aece65678a31f9db215ee Mon Sep 17 00:00:00 2001
From: Helge Deller <deller(a)gmx.de>
Date: Sun, 14 Oct 2018 21:58:00 +0200
Subject: [PATCH] parisc: Fix exported address of os_hpmc handler
In the C-code we need to put the physical address of the hpmc handler in
the interrupt vector table (IVA) in order to get HPMCs working. Since
on parisc64 function pointers are indirect (in fact they are function
descriptors) we instead export the address as variable and not as
function.
This reverts a small part of commit f39cce654f9a ("parisc: Add
cfi_startproc and cfi_endproc to assembly code").
Signed-off-by: Helge Deller <deller(a)gmx.de>
Cc: <stable(a)vger.kernel.org> [4.9+]
diff --git a/arch/parisc/kernel/hpmc.S b/arch/parisc/kernel/hpmc.S
index 781c3b9a3e46..fde654115564 100644
--- a/arch/parisc/kernel/hpmc.S
+++ b/arch/parisc/kernel/hpmc.S
@@ -85,7 +85,7 @@ END(hpmc_pim_data)
.import intr_save, code
.align 16
-ENTRY_CFI(os_hpmc)
+ENTRY(os_hpmc)
.os_hpmc:
/*
@@ -302,7 +302,6 @@ os_hpmc_6:
b .
nop
.align 16 /* make function length multiple of 16 bytes */
-ENDPROC_CFI(os_hpmc)
.os_hpmc_end:
Hello,
Please picked up this patch for linux 4.4 and 4.9.
Compiled/tested without problem.
Thank.
[ Upstream commit 5983587c8c5ef00d6886477544ad67d495bc5479 ]
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 22 Sep 2017 18:13:48 +0100
Subject: [PATCH] e1000: avoid null pointer dereference on invalid stat type
Currently if the stat type is invalid then data[i] is being set
either by dereferencing a null pointer p, or it is reading from
an incorrect previous location if we had a valid stat type
previously. Fix this by skipping over the read of p on an invalid
stat type.
Detected by CoverityScan, CID#113385 ("Explicit null dereferenced")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Reviewed-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index ec8aa4562cc90..3b3983a1ffbba 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -1824,11 +1824,12 @@ static void e1000_get_ethtool_stats(struct net_device *netdev,
{
struct e1000_adapter *adapter = netdev_priv(netdev);
int i;
- char *p = NULL;
const struct e1000_stats *stat = e1000_gstrings_stats;
e1000_update_stats(adapter);
- for (i = 0; i < E1000_GLOBAL_STATS_LEN; i++) {
+ for (i = 0; i < E1000_GLOBAL_STATS_LEN; i++, stat++) {
+ char *p;
+
switch (stat->type) {
case NETDEV_STATS:
p = (char *)netdev + stat->stat_offset;
@@ -1839,15 +1840,13 @@ static void e1000_get_ethtool_stats(struct net_device *netdev,
default:
WARN_ONCE(1, "Invalid E1000 stat type: %u index %d\n",
stat->type, i);
- break;
+ continue;
}
if (stat->sizeof_stat == sizeof(u64))
data[i] = *(u64 *)p;
else
data[i] = *(u32 *)p;
-
- stat++;
}
/* BUG_ON(i != E1000_STATS_LEN); */
}
Hello,
Please picked up this patch for linux 4.4 and 4.9.
Compiled/tested without problem.
Thank.
[ Upstream commit 44c445c3d1b4eacff23141fa7977c3b2ec3a45c9 ]
From: Vincenzo Maffione <v.maffione(a)gmail.com>
Date: Sat, 16 Sep 2017 18:00:00 +0200
Subject: [PATCH] e1000: fix race condition between e1000_down() and
e1000_watchdog
This patch fixes a race condition that can result into the interface being
up and carrier on, but with transmits disabled in the hardware.
The bug may show up by repeatedly IFF_DOWN+IFF_UP the interface, which
allows e1000_watchdog() interleave with e1000_down().
CPU x CPU y
--------------------------------------------------------------------
e1000_down():
netif_carrier_off()
e1000_watchdog():
if (carrier == off) {
netif_carrier_on();
enable_hw_transmit();
}
disable_hw_transmit();
e1000_watchdog():
/* carrier on, do nothing */
Signed-off-by: Vincenzo Maffione <v.maffione(a)gmail.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 98375e1e1185e..1982f7917a8d5 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -520,8 +520,6 @@ void e1000_down(struct e1000_adapter *adapter)
struct net_device *netdev = adapter->netdev;
u32 rctl, tctl;
- netif_carrier_off(netdev);
-
/* disable receives in the hardware */
rctl = er32(RCTL);
ew32(RCTL, rctl & ~E1000_RCTL_EN);
@@ -537,6 +535,15 @@ void e1000_down(struct e1000_adapter *adapter)
E1000_WRITE_FLUSH();
msleep(10);
+ /* Set the carrier off after transmits have been disabled in the
+ * hardware, to avoid race conditions with e1000_watchdog() (which
+ * may be running concurrently to us, checking for the carrier
+ * bit to decide whether it should enable transmits again). Such
+ * a race condition would result into transmission being disabled
+ * in the hardware until the next IFF_DOWN+IFF_UP cycle.
+ */
+ netif_carrier_off(netdev);
+
napi_disable(&adapter->napi);
e1000_irq_disable(adapter);
Hello,
Please picked up this patch for linux 4.4 and 4.9.
Compiled/tested without problem.
Thank.
[ Upstream commit 4dc69c1c1fff2f587f8e737e70b4a4e7565a5c94 ]
From: Kees Cook <keescook(a)chromium.org>
Date: Fri, 5 May 2017 15:30:23 -0700
Subject: [PATCH] bna: ethtool: Avoid reading past end of buffer
Using memcpy() from a string that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from the kernel
rodata segment. Instead, use strncpy() which will fill the trailing bytes
with zeros.
This was found with the future CONFIG_FORTIFY_SOURCE feature.
Cc: Daniel Micay <danielmicay(a)gmail.com>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
---
drivers/net/ethernet/brocade/bna/bnad_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad_ethtool.c b/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
index 286593922139e..31032de5843b1 100644
--- a/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
+++ b/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
@@ -547,8 +547,8 @@ bnad_get_strings(struct net_device *netdev, u32 stringset, u8 *string)
for (i = 0; i < BNAD_ETHTOOL_STATS_NUM; i++) {
BUG_ON(!(strlen(bnad_net_stats_strings[i]) <
ETH_GSTRING_LEN));
- memcpy(string, bnad_net_stats_strings[i],
- ETH_GSTRING_LEN);
+ strncpy(string, bnad_net_stats_strings[i],
+ ETH_GSTRING_LEN);
string += ETH_GSTRING_LEN;
}
bmap = bna_tx_rid_mask(&bnad->bna);
mstc->port isn't validated here so it could be null or worse when we
access it. And drivers aren't ever supposed to be looking at it's
contents anyway. Plus, we can already get the MST manager from
&mstc->mstm->mgr.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index e6f72ca0b1fa..66c40b56a0cb 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -893,7 +893,8 @@ nv50_mstc_get_modes(struct drm_connector *connector)
struct nv50_mstc *mstc = nv50_mstc(connector);
int ret = 0;
- mstc->edid = drm_dp_mst_get_edid(&mstc->connector, mstc->port->mgr, mstc->port);
+ mstc->edid = drm_dp_mst_get_edid(&mstc->connector,
+ &mstc->mstm->mgr, mstc->port);
drm_connector_update_edid_property(&mstc->connector, mstc->edid);
if (mstc->edid)
ret = drm_add_edid_modes(&mstc->connector, mstc->edid);
--
2.19.1
From: Roman Gushchin <guro(a)fb.com>
Subject: mm: don't reclaim inodes with many attached pages
Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs with
a relatively small number of objects") leads to a regression on his setup:
periodically the majority of the pagecache is evicted without an obvious
reason, while before the change the amount of free memory was balancing
around the watermark.
The reason behind is that the mentioned above change created some minimal
background pressure on the inode cache. The problem is that if an inode
is considered to be reclaimed, all belonging pagecache page are stripped,
no matter how many of them are there. So, if a huge multi-gigabyte file
is cached in the memory, and the goal is to reclaim only few slab objects
(unused inodes), we still can eventually evict all gigabytes of the
pagecache at once.
The workload described by Spock has few large non-mapped files in the
pagecache, so it's especially noticeable.
To solve the problem let's postpone the reclaim of inodes, which have more
than 1 attached page. Let's wait until the pagecache pages will be
evicted naturally by scanning the corresponding LRU lists, and only then
reclaim the inode structure.
Link: http://lkml.kernel.org/r/20181023164302.20436-1-guro@fb.com
Signed-off-by: Roman Gushchin <guro(a)fb.com>
Reported-by: Spock <dairinin(a)gmail.com>
Tested-by: Spock <dairinin(a)gmail.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Rik van Riel <riel(a)surriel.com>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: <stable(a)vger.kernel.org> [4.19.x]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/fs/inode.c~mm-dont-reclaim-inodes-with-many-attached-pages
+++ a/fs/inode.c
@@ -730,8 +730,11 @@ static enum lru_status inode_lru_isolate
return LRU_REMOVED;
}
- /* recently referenced inodes get one more pass */
- if (inode->i_state & I_REFERENCED) {
+ /*
+ * Recently referenced inodes and inodes with many attached pages
+ * get one more pass.
+ */
+ if (inode->i_state & I_REFERENCED || inode->i_data.nrpages > 1) {
inode->i_state &= ~I_REFERENCED;
spin_unlock(&inode->i_lock);
return LRU_ROTATE;
_
From: Arnd Bergmann <arnd(a)arndb.de>
Subject: lib/ubsan.c: don't mark __ubsan_handle_builtin_unreachable as noreturn
gcc-8 complains about the prototype for this function:
lib/ubsan.c:432:1: error: ignoring attribute 'noreturn' in declaration of a built-in function '__ubsan_handle_builtin_unreachable' because it conflicts with attribute 'const' [-Werror=attributes]
This is actually a GCC's bug. In GCC internals
__ubsan_handle_builtin_unreachable() declared with both 'noreturn' and
'const' attributes instead of only 'noreturn':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84210
Workaround this by removing the noreturn attribute.
[aryabinin: add information about GCC bug in changelog]
Link: http://lkml.kernel.org/r/20181107144516.4587-1-aryabinin@virtuozzo.com
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Acked-by: Olof Johansson <olof(a)lixom.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/lib/ubsan.c~ubsan-dont-mark-__ubsan_handle_builtin_unreachable-as-noreturn
+++ a/lib/ubsan.c
@@ -427,8 +427,7 @@ void __ubsan_handle_shift_out_of_bounds(
EXPORT_SYMBOL(__ubsan_handle_shift_out_of_bounds);
-void __noreturn
-__ubsan_handle_builtin_unreachable(struct unreachable_data *data)
+void __ubsan_handle_builtin_unreachable(struct unreachable_data *data)
{
unsigned long flags;
_
From: Wengang Wang <wen.gang.wang(a)oracle.com>
Subject: ocfs2: free up write context when direct IO failed
The write context should also be freed even when direct IO failed.
Otherwise a memory leak is introduced and entries remain in
oi->ip_unwritten_list causing the following BUG later in unlink path:
ERROR: bug expression: !list_empty(&oi->ip_unwritten_list)
ERROR: Clear inode of 215043, inode has unwritten extents
...
Call Trace:
? __set_current_blocked+0x42/0x68
ocfs2_evict_inode+0x91/0x6a0 [ocfs2]
? bit_waitqueue+0x40/0x33
evict+0xdb/0x1af
iput+0x1a2/0x1f7
do_unlinkat+0x194/0x28f
SyS_unlinkat+0x1b/0x2f
do_syscall_64+0x79/0x1ae
entry_SYSCALL_64_after_hwframe+0x151/0x0
This patch also logs, with frequency limit, direct IO failures.
Link: http://lkml.kernel.org/r/20181102170632.25921-1-wen.gang.wang@oracle.com
Signed-off-by: Wengang Wang <wen.gang.wang(a)oracle.com>
Reviewed-by: Junxiao Bi <junxiao.bi(a)oracle.com>
Reviewed-by: Changwei Ge <ge.changwei(a)h3c.com>
Reviewed-by: Joseph Qi <jiangqi903(a)gmail.com>
Cc: Mark Fasheh <mark(a)fasheh.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/fs/ocfs2/aops.c~ocfs2-free-up-write-context-when-direct-io-failed
+++ a/fs/ocfs2/aops.c
@@ -2411,8 +2411,16 @@ static int ocfs2_dio_end_io(struct kiocb
/* this io's submitter should not have unlocked this before we could */
BUG_ON(!ocfs2_iocb_is_rw_locked(iocb));
- if (bytes > 0 && private)
- ret = ocfs2_dio_end_io_write(inode, private, offset, bytes);
+ if (bytes <= 0)
+ mlog_ratelimited(ML_ERROR, "Direct IO failed, bytes = %lld",
+ (long long)bytes);
+ if (private) {
+ if (bytes > 0)
+ ret = ocfs2_dio_end_io_write(inode, private, offset,
+ bytes);
+ else
+ ocfs2_dio_free_write_ctx(inode, private);
+ }
ocfs2_iocb_clear_rw_locked(iocb);
--- a/fs/ocfs2/cluster/masklog.h~ocfs2-free-up-write-context-when-direct-io-failed
+++ a/fs/ocfs2/cluster/masklog.h
@@ -178,6 +178,15 @@ do { \
##__VA_ARGS__); \
} while (0)
+#define mlog_ratelimited(mask, fmt, ...) \
+do { \
+ static DEFINE_RATELIMIT_STATE(_rs, \
+ DEFAULT_RATELIMIT_INTERVAL, \
+ DEFAULT_RATELIMIT_BURST); \
+ if (__ratelimit(&_rs)) \
+ mlog(mask, fmt, ##__VA_ARGS__); \
+} while (0)
+
#define mlog_errno(st) ({ \
int _st = (st); \
if (_st != -ERESTARTSYS && _st != -EINTR && \
_
From: Vasily Averin <vvs(a)virtuozzo.com>
Subject: mm/swapfile.c: use kvzalloc for swap_info_struct allocation
a2468cc9bfdf ("swap: choose swap device according to numa node") changed
'avail_lists' field of 'struct swap_info_struct' to an array. In popular
linux distros it increased size of swap_info_struct up to 40 Kbytes and
now swap_info_struct allocation requires order-4 page. Switch to
kvzmalloc allows to avoid unexpected allocation failures.
Link: http://lkml.kernel.org/r/fc23172d-3c75-21e2-d551-8b1808cbe593@virtuozzo.com
Fixes: a2468cc9bfdf ("swap: choose swap device according to numa node")
Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com>
Acked-by: Aaron Lu <aaron.lu(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Huang Ying <ying.huang(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/swapfile.c~mm-use-kvzalloc-for-swap_info_struct-allocation
+++ a/mm/swapfile.c
@@ -2813,7 +2813,7 @@ static struct swap_info_struct *alloc_sw
unsigned int type;
int i;
- p = kzalloc(sizeof(*p), GFP_KERNEL);
+ p = kvzalloc(sizeof(*p), GFP_KERNEL);
if (!p)
return ERR_PTR(-ENOMEM);
@@ -2824,7 +2824,7 @@ static struct swap_info_struct *alloc_sw
}
if (type >= MAX_SWAPFILES) {
spin_unlock(&swap_lock);
- kfree(p);
+ kvfree(p);
return ERR_PTR(-EPERM);
}
if (type >= nr_swapfiles) {
@@ -2838,7 +2838,7 @@ static struct swap_info_struct *alloc_sw
smp_wmb();
nr_swapfiles++;
} else {
- kfree(p);
+ kvfree(p);
p = swap_info[type];
/*
* Do not memset this entry: a racing procfs swap_next()
_
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: hugetlbfs: fix kernel BUG at fs/hugetlbfs/inode.c:444!
This bug has been experienced several times by Oracle DB team. The BUG is
in remove_inode_hugepages() as follows:
/*
* If page is mapped, it was faulted in after being
* unmapped in caller. Unmap (again) now after taking
* the fault mutex. The mutex will prevent faults
* until we finish removing the page.
*
* This race can only happen in the hole punch case.
* Getting here in a truncate operation is a bug.
*/
if (unlikely(page_mapped(page))) {
BUG_ON(truncate_op);
In this case, the elevated map count is not the result of a race. Rather
it was incorrectly incremented as the result of a bug in the huge pmd
sharing code. Consider the following:
- Process A maps a hugetlbfs file of sufficient size and alignment
(PUD_SIZE) that a pmd page could be shared.
- Process B maps the same hugetlbfs file with the same size and alignment
such that a pmd page is shared.
- Process B then calls mprotect() to change protections for the mapping
with the shared pmd. As a result, the pmd is 'unshared'.
- Process B then calls mprotect() again to chage protections for the
mapping back to their original value. pmd remains unshared.
- Process B then forks and process C is created. During the fork process,
we do dup_mm -> dup_mmap -> copy_page_range to copy page tables. Copying
page tables for hugetlb mappings is done in the routine
copy_hugetlb_page_range.
In copy_hugetlb_page_range(), the destination pte is obtained by:
dst_pte = huge_pte_alloc(dst, addr, sz);
If pmd sharing is possible, the returned pointer will be to a pte in an
existing page table. In the situation above, process C could share with
either process A or process B. Since process A is first in the list, the
returned pte is a pointer to a pte in process A's page table.
However, the following check for pmd sharing is in
copy_hugetlb_page_range.
/* If the pagetables are shared don't copy or take references */
if (dst_pte == src_pte)
continue;
Since process C is sharing with process A instead of process B, the above
test fails. The code in copy_hugetlb_page_range which follows assumes
dst_pte points to a huge_pte_none pte. It copies the pte entry from
src_pte to dst_pte and increments this map count of the associated page.
This is how we end up with an elevated map count.
To solve, check the dst_pte entry for huge_pte_none. If !none, this
implies PMD sharing so do not copy.
Link: http://lkml.kernel.org/r/20181105212315.14125-1-mike.kravetz@oracle.com
Fixes: c5c99429fa57 ("fix hugepages leak due to pagetable page sharing")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Prakash Sangappa <prakash.sangappa(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/hugetlb.c~hugetlbfs-fix-kernel-bug-at-fs-hugetlbfs-inodec-444
+++ a/mm/hugetlb.c
@@ -3233,7 +3233,7 @@ static int is_hugetlb_entry_hwpoisoned(p
int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
struct vm_area_struct *vma)
{
- pte_t *src_pte, *dst_pte, entry;
+ pte_t *src_pte, *dst_pte, entry, dst_entry;
struct page *ptepage;
unsigned long addr;
int cow;
@@ -3261,15 +3261,30 @@ int copy_hugetlb_page_range(struct mm_st
break;
}
- /* If the pagetables are shared don't copy or take references */
- if (dst_pte == src_pte)
+ /*
+ * If the pagetables are shared don't copy or take references.
+ * dst_pte == src_pte is the common case of src/dest sharing.
+ *
+ * However, src could have 'unshared' and dst shares with
+ * another vma. If dst_pte !none, this implies sharing.
+ * Check here before taking page table lock, and once again
+ * after taking the lock below.
+ */
+ dst_entry = huge_ptep_get(dst_pte);
+ if ((dst_pte == src_pte) || !huge_pte_none(dst_entry))
continue;
dst_ptl = huge_pte_lock(h, dst, dst_pte);
src_ptl = huge_pte_lockptr(h, src, src_pte);
spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
entry = huge_ptep_get(src_pte);
- if (huge_pte_none(entry)) { /* skip none entry */
+ dst_entry = huge_ptep_get(dst_pte);
+ if (huge_pte_none(entry) || !huge_pte_none(dst_entry)) {
+ /*
+ * Skip if src entry none. Also, skip in the
+ * unlikely case dst entry !none as this implies
+ * sharing with another vma.
+ */
;
} else if (unlikely(is_hugetlb_entry_migration(entry) ||
is_hugetlb_entry_hwpoisoned(entry))) {
_
From: Kan Liang <kan.liang(a)linux.intel.com>
The client IMC bandwidth events return very huge result.
perf stat -e uncore_imc/data_reads/ -e uncore_imc/data_writes/ -I
10000 -a
10.000117222 34,788.76 MiB uncore_imc/data_reads/
10.000117222 8.26 MiB uncore_imc/data_writes/
20.000374584 34,842.89 MiB uncore_imc/data_reads/
20.000374584 10.45 MiB uncore_imc/data_writes/
30.000633299 37,965.29 MiB uncore_imc/data_reads/
30.000633299 323.62 MiB uncore_imc/data_writes/
40.000891548 41,012.88 MiB uncore_imc/data_reads/
40.000891548 6.98 MiB uncore_imc/data_writes/
50.001142480 1,125,899,906,621,494.75 MiB uncore_imc/data_reads/
50.001142480 6.97 MiB uncore_imc/data_writes/
The client IMC events are freerunning counters. They still use the
old event encoding format (0x1 for data_read and 0x2 for data write).
The counter bit width is calculated by common code, which assume that
the standard encoding format is used for the freerunning counters.
Error bit width information is calculated.
The event->attr.config, which directly from user space, should not be
used by the functions of freerunning counters.
For client IMC events, the attr.config needs to be converted to the
standard encoding format. The modified event config will be stored in
event->hw.config.
For other freerunning counters, the attr.config has the correct format.
Just save it in event->hw.config.
Using event->hw.config to replace event->attr.config for the functions
of freerunning counters.
Fix: commit 9aae1780e7e8 ("perf/x86/intel/uncore: Clean up client IMC
uncore")
Reported-by: Jin Yao <yao.jin(a)linux.intel.com>
Tested-by: Jin Yao <yao.jin(a)linux.intel.com>
Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com>
---
arch/x86/events/intel/uncore.c | 1 +
arch/x86/events/intel/uncore.h | 12 ++++++------
arch/x86/events/intel/uncore_snb.c | 4 +++-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 27a461414b30..2690135bf83f 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -740,6 +740,7 @@ static int uncore_pmu_event_init(struct perf_event *event)
/* fixed counters have event field hardcoded to zero */
hwc->config = 0ULL;
} else if (is_freerunning_event(event)) {
+ hwc->config = event->attr.config;
if (!check_valid_freerunning_event(box, event))
return -EINVAL;
event->hw.idx = UNCORE_PMC_IDX_FREERUNNING;
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index e17ab885b1e9..cc6dd4f78158 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -285,8 +285,8 @@ static inline
unsigned int uncore_freerunning_counter(struct intel_uncore_box *box,
struct perf_event *event)
{
- unsigned int type = uncore_freerunning_type(event->attr.config);
- unsigned int idx = uncore_freerunning_idx(event->attr.config);
+ unsigned int type = uncore_freerunning_type(event->hw.config);
+ unsigned int idx = uncore_freerunning_idx(event->hw.config);
struct intel_uncore_pmu *pmu = box->pmu;
return pmu->type->freerunning[type].counter_base +
@@ -360,7 +360,7 @@ static inline
unsigned int uncore_freerunning_bits(struct intel_uncore_box *box,
struct perf_event *event)
{
- unsigned int type = uncore_freerunning_type(event->attr.config);
+ unsigned int type = uncore_freerunning_type(event->hw.config);
return box->pmu->type->freerunning[type].bits;
}
@@ -368,7 +368,7 @@ unsigned int uncore_freerunning_bits(struct intel_uncore_box *box,
static inline int uncore_num_freerunning(struct intel_uncore_box *box,
struct perf_event *event)
{
- unsigned int type = uncore_freerunning_type(event->attr.config);
+ unsigned int type = uncore_freerunning_type(event->hw.config);
return box->pmu->type->freerunning[type].num_counters;
}
@@ -382,8 +382,8 @@ static inline int uncore_num_freerunning_types(struct intel_uncore_box *box,
static inline bool check_valid_freerunning_event(struct intel_uncore_box *box,
struct perf_event *event)
{
- unsigned int type = uncore_freerunning_type(event->attr.config);
- unsigned int idx = uncore_freerunning_idx(event->attr.config);
+ unsigned int type = uncore_freerunning_type(event->hw.config);
+ unsigned int idx = uncore_freerunning_idx(event->hw.config);
return (type < uncore_num_freerunning_types(box, event)) &&
(idx < uncore_num_freerunning(box, event));
diff --git a/arch/x86/events/intel/uncore_snb.c b/arch/x86/events/intel/uncore_snb.c
index 8527c3e1038b..48d7121f71c7 100644
--- a/arch/x86/events/intel/uncore_snb.c
+++ b/arch/x86/events/intel/uncore_snb.c
@@ -425,9 +425,11 @@ static int snb_uncore_imc_event_init(struct perf_event *event)
/* must be done before validate_group */
event->hw.event_base = base;
- event->hw.config = cfg;
event->hw.idx = idx;
+ /* Convert to standard encoding format for free running counters */
+ event->hw.config = ((cfg - 1) << 8) | 0x10ff;
+
/* no group validation needed, we have free running counters */
return 0;
--
2.14.3
From: Rafał Miłecki <rafal(a)milecki.pl>
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid & complete info about supported bands for
each channel. By default no support for 160 MHz should be assumed unless
firmware reports it for a given channel later.
This fixes info passed to the userspace. Without that change userspace
could try to use invalid channel and fail to start an interface.
Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl>
Cc: stable(a)vger.kernel.org
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 230a378c26fc..7f0a5bade70a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6005,7 +6005,8 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
* for subsequent chanspecs.
*/
channel->flags = IEEE80211_CHAN_NO_HT40 |
- IEEE80211_CHAN_NO_80MHZ;
+ IEEE80211_CHAN_NO_80MHZ |
+ IEEE80211_CHAN_NO_160MHZ;
ch.bw = BRCMU_CHAN_BW_20;
cfg->d11inf.encchspec(&ch);
chaninfo = ch.chspec;
--
2.13.7
Sasha has somehow been convinced into helping me with the stable kernel
maintenance. Codify this slip in good judgement before he realizes what
he really signed up for :)
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Acked-by: Sasha Levin <sashal(a)kernel.org>
diff --git a/MAINTAINERS b/MAINTAINERS
index 0abecc528dac..a46c1aa82398 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14078,6 +14078,7 @@ F: Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
STABLE BRANCH
M: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
+M: Sasha Levin <sashal(a)kernel.org>
L: stable(a)vger.kernel.org
S: Supported
F: Documentation/process/stable-kernel-rules.rst
The patch titled
Subject: mm: cleancache: fix corruption on missed inode invalidation
has been added to the -mm tree. Its filename is
mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-cleancache-fix-corruption-on-mi…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-cleancache-fix-corruption-on-mi…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Subject: mm: cleancache: fix corruption on missed inode invalidation
If all pages are deleted from the mapping by memory reclaim and also
moved to the cleancache:
__delete_from_page_cache
(no shadow case)
unaccount_page_cache_page
cleancache_put_page
page_cache_delete
mapping->nrpages -= nr
(nrpages becomes 0)
We don't clean the cleancache for an inode after final file truncation
(removal).
truncate_inode_pages_final
check (nrpages || nrexceptional) is false
no truncate_inode_pages
no cleancache_invalidate_inode(mapping)
These way when reading the new file created with same inode we may get
these trash leftover pages from cleancache and see wrong data instead of
the contents of the new file.
Fix it by always doing truncate_inode_pages which is already ready for
nrpages == 0 && nrexceptional == 0 case and just invalidates inode.
Link: http://lkml.kernel.org/r/20181112095734.17979-1-ptikhomirov@virtuozzo.com
Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache")
Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Reviewed-by: Vasily Averin <vvs(a)virtuozzo.com>
Reviewed-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/truncate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/truncate.c~mm-cleancache-fix-corruption-on-missed-inode-invalidation
+++ a/mm/truncate.c
@@ -517,9 +517,9 @@ void truncate_inode_pages_final(struct a
*/
xa_lock_irq(&mapping->i_pages);
xa_unlock_irq(&mapping->i_pages);
-
- truncate_inode_pages(mapping, 0);
}
+
+ truncate_inode_pages(mapping, 0);
}
EXPORT_SYMBOL(truncate_inode_pages_final);
_
Patches currently in -mm which might be from ptikhomirov(a)virtuozzo.com are
mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch
Hi Stable team,
Le 08/11/2018 10:31, Jerome Brunet a écrit :
> Similar to gxbb and gxl platforms, axg SCPI Cortex-M co-processor
> uses the fdiv2 and fdiv3 to, among other things, provide the cpu
> clock.
>
> Until clock hand-off mechanism makes its way to CCF and the generic
> SCPI claims platform specific clocks, these clocks must be marked as
> critical to make sure they are never disabled when needed by the
> co-processor.
>
> Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates")
> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Could this fix go into the next 4.18 and 4.19 stable releases since it hit linus master with commit id d6ee1e7e9004d3d246cdfa14196989e0a9466c16 ?
Thanks,
Neil
> ---
>
> Hi Stephen,
>
> If you can put this one in clk-fixes as well, it would be awesome.
> It is basically the same thing as the change you took this Tuesday.
>
> Since then, we had reports the same problem with SCPI was happening
> on the axg, calling for the same fixup.
>
> Cheers
> Jerome
>
> drivers/clk/meson/axg.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> index c981159b02c0..792735d7e46e 100644
> --- a/drivers/clk/meson/axg.c
> +++ b/drivers/clk/meson/axg.c
> @@ -325,6 +325,7 @@ static struct clk_regmap axg_fclk_div2 = {
> .ops = &clk_regmap_gate_ops,
> .parent_names = (const char *[]){ "fclk_div2_div" },
> .num_parents = 1,
> + .flags = CLK_IS_CRITICAL,
> },
> };
>
> @@ -349,6 +350,18 @@ static struct clk_regmap axg_fclk_div3 = {
> .ops = &clk_regmap_gate_ops,
> .parent_names = (const char *[]){ "fclk_div3_div" },
> .num_parents = 1,
> + /*
> + * FIXME:
> + * This clock, as fdiv2, is used by the SCPI FW and is required
> + * by the platform to operate correctly.
> + * Until the following condition are met, we need this clock to
> + * be marked as critical:
> + * a) The SCPI generic driver claims and enable all the clocks
> + * it needs
> + * b) CCF has a clock hand-off mechanism to make the sure the
> + * clock stays on until the proper driver comes along
> + */
> + .flags = CLK_IS_CRITICAL,
> },
> };
>
>
From: Michal Hocko <mhocko(a)suse.com>
commit bb177a732c4369bb58a1fe1df8f552b6f0f7db5f upstream.
syzbot has noticed that a specially crafted library can easily hit
VM_BUG_ON in __mm_populate
kernel BUG at mm/gup.c:1242!
invalid opcode: 0000 [#1] SMP
CPU: 2 PID: 9667 Comm: a.out Not tainted 4.18.0-rc3 #644
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
RIP: 0010:__mm_populate+0x1e2/0x1f0
Code: 55 d0 65 48 33 14 25 28 00 00 00 89 d8 75 21 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 75 18 f1 ff 0f 0b e8 6e 18 f1 ff <0f> 0b 31 db eb c9 e8 93 06 e0 ff 0f 1f 00 55 48 89 e5 53 48 89 fb
Call Trace:
vm_brk_flags+0xc3/0x100
vm_brk+0x1f/0x30
load_elf_library+0x281/0x2e0
__ia32_sys_uselib+0x170/0x1e0
do_fast_syscall_32+0xca/0x420
entry_SYSENTER_compat+0x70/0x7f
The reason is that the length of the new brk is not page aligned when we
try to populate the it. There is no reason to bug on that though.
do_brk_flags already aligns the length properly so the mapping is
expanded as it should. All we need is to tell mm_populate about it.
Besides that there is absolutely no reason to to bug_on in the first
place. The worst thing that could happen is that the last page wouldn't
get populated and that is far from putting system into an inconsistent
state.
Fix the issue by moving the length sanitization code from do_brk_flags
up to vm_brk_flags. The only other caller of do_brk_flags is brk
syscall entry and it makes sure to provide the proper length so t here
is no need for sanitation and so we can use do_brk_flags without it.
Also remove the bogus BUG_ONs.
[osalvador(a)techadventures.net: fix up vm_brk_flags s@request@len@]
Link: http://lkml.kernel.org/r/20180706090217.GI32658@dhcp22.suse.cz
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: syzbot <syzbot+5dcb560fe12aa5091c06(a)syzkaller.appspotmail.com>
Tested-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Reviewed-by: Oscar Salvador <osalvador(a)suse.de>
Cc: Zi Yan <zi.yan(a)cs.rutgers.edu>
Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.vnet.ibm.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Michael S. Tsirkin <mst(a)redhat.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: "Huang, Ying" <ying.huang(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
[bwh: Backported to 4.9:
- There is no do_brk_flags() function; update do_brk()
- Adjust context]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
mm/gup.c | 2 --
mm/mmap.c | 19 ++++++++++---------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index be4ccddac26f..d71da7216c6e 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1122,8 +1122,6 @@ int __mm_populate(unsigned long start, unsigned long len, int ignore_errors)
int locked = 0;
long ret = 0;
- VM_BUG_ON(start & ~PAGE_MASK);
- VM_BUG_ON(len != PAGE_ALIGN(len));
end = start + len;
for (nstart = start; nstart < end; nstart = nend) {
diff --git a/mm/mmap.c b/mm/mmap.c
index aa97074a4a99..283755645d17 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2876,21 +2876,15 @@ static inline void verify_mm_writelocked(struct mm_struct *mm)
* anonymous maps. eventually we may be able to do some
* brk-specific accounting here.
*/
-static int do_brk(unsigned long addr, unsigned long request)
+static int do_brk(unsigned long addr, unsigned long len)
{
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma, *prev;
- unsigned long flags, len;
+ unsigned long flags;
struct rb_node **rb_link, *rb_parent;
pgoff_t pgoff = addr >> PAGE_SHIFT;
int error;
- len = PAGE_ALIGN(request);
- if (len < request)
- return -ENOMEM;
- if (!len)
- return 0;
-
flags = VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags;
error = get_unmapped_area(NULL, addr, len, 0, MAP_FIXED);
@@ -2959,12 +2953,19 @@ static int do_brk(unsigned long addr, unsigned long request)
return 0;
}
-int vm_brk(unsigned long addr, unsigned long len)
+int vm_brk(unsigned long addr, unsigned long request)
{
struct mm_struct *mm = current->mm;
+ unsigned long len;
int ret;
bool populate;
+ len = PAGE_ALIGN(request);
+ if (len < request)
+ return -ENOMEM;
+ if (!len)
+ return 0;
+
if (down_write_killable(&mm->mmap_sem))
return -EINTR;
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
Hi Stable team,
Le 06/11/2018 00:08, Jerome Brunet a écrit :
> From: Christian Hewitt <christianshewitt(a)gmail.com>
>
> On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems
> with reboot; e.g. a ~60 second delay between issuing reboot and the
> board power cycling (and in some OS configurations reboot will fail
> and require manual power cycling).
>
> Similar to 'commit c987ac6f1f088663b6dad39281071aeb31d450a8 ("clk:
> meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL")' the SCPI Cortex-M4
> Co-Processor seems to depend on FCLK_DIV3 being operational.
>
> Until commit 05f814402d6174369b3b29832cbb5eb5ed287059 ("clk:
> meson: add fdiv clock gates"), this clock was modeled and left on by
> the bootloader.
>
> We don't have precise documentation about the SCPI Co-Processor and
> its clock requirement so we are learning things the hard way.
>
> Marking this clock as critical solves the problem but it should not
> be viewed as final solution. Ideally, the SCPI driver should claim
> these clocks. We also depends on some clock hand-off mechanism
> making its way to CCF, to make sure the clock stays on between its
> registration and the SCPI driver probe.
>
> Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates")
> Signed-off-by: Christian Hewitt <christianshewitt(a)gmail.com>
> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Could this patch go into the next 4.18 stable release since it hit linus master with commit id e2576c8bdfd462c34b8a46c0084e7c30b0851bf4 ?
Thanks,
Neil
> ---
> drivers/clk/meson/gxbb.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index 9309cfaaa464..4ada9668fd49 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -506,6 +506,18 @@ static struct clk_regmap gxbb_fclk_div3 = {
> .ops = &clk_regmap_gate_ops,
> .parent_names = (const char *[]){ "fclk_div3_div" },
> .num_parents = 1,
> + /*
> + * FIXME:
> + * This clock, as fdiv2, is used by the SCPI FW and is required
> + * by the platform to operate correctly.
> + * Until the following condition are met, we need this clock to
> + * be marked as critical:
> + * a) The SCPI generic driver claims and enable all the clocks
> + * it needs
> + * b) CCF has a clock hand-off mechanism to make the sure the
> + * clock stays on until the proper driver comes along
> + */
> + .flags = CLK_IS_CRITICAL,
> },
> };
>
>
Please apply the attached fixes to the 4.4-stable branch.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data which belongs to that inode
as soon it faces an inode with link count 0 in the replay list.
Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE
it can lead to data loss upon a power-cut.
Consider a journal with entries like:
0: inode X (nlink = 0) /* O_TMPFILE was created */
1: data for inode X /* Someone writes to the temp file */
2: inode X (nlink = 0) /* inode was changed, xattr, chmod, … */
3: inode X (nlink = 1) /* inode was re-linked via linkat() */
Upon replay of entry #2 UBIFS will drop all data that belongs to inode X,
this will lead to an empty file after mounting.
As solution for this problem, scan the replay list for a re-link entry
before dropping data.
Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE")
Cc: stable(a)vger.kernel.org
Cc: Russell Senior <russell(a)personaltelco.net>
Cc: Rafał Miłecki <zajec5(a)gmail.com>
Reported-by: Russell Senior <russell(a)personaltelco.net>
Reported-by: Rafał Miłecki <zajec5(a)gmail.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
---
fs/ubifs/replay.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
index 75f961c4c044..cb1f23459553 100644
--- a/fs/ubifs/replay.c
+++ b/fs/ubifs/replay.c
@@ -212,6 +212,38 @@ static int trun_remove_range(struct ubifs_info *c, struct replay_entry *r)
return ubifs_tnc_remove_range(c, &min_key, &max_key);
}
+/**
+ * inode_still_linked - check whether inode in question will be re-linked.
+ * @c: UBIFS file-system description object
+ * @rino: replay entry to test
+ *
+ * O_TMPFILE files can be re-linked, this means link count goes from 0 to 1.
+ * This case needs special care, otherwise all references to the inode will
+ * be removed upon the first replay entry of an inode with link count 0
+ * is found.
+ */
+static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino)
+{
+ struct replay_entry *r;
+
+ ubifs_assert(c, rino->deletion);
+ ubifs_assert(c, key_type(c, &rino->key) == UBIFS_INO_KEY);
+
+ /*
+ * Find the most recent entry for the inode behind @rino and check
+ * whether it is a deletion.
+ */
+ list_for_each_entry_reverse(r, &c->replay_list, list) {
+ ubifs_assert(c, r->sqnum >= rino->sqnum);
+ if (key_inum(c, &r->key) == key_inum(c, &rino->key))
+ return r->deletion == 0;
+
+ }
+
+ ubifs_assert(c, 0);
+ return false;
+}
+
/**
* apply_replay_entry - apply a replay entry to the TNC.
* @c: UBIFS file-system description object
@@ -239,6 +271,11 @@ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r)
{
ino_t inum = key_inum(c, &r->key);
+ if (inode_still_linked(c, r)) {
+ err = 0;
+ break;
+ }
+
err = ubifs_tnc_remove_ino(c, inum);
break;
}
--
2.19.1
If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.
Also remove this dma_fence_put() from the 'out' label.
Signed-off-by: Robert Foss <robert.foss(a)collabora.com>
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: stable(a)vger.kernel.org
---
Changes since v2:
- Chris Wilson: Added r-b and stable kernel tag
Changes since v1:
- Chris Wilson: Make sure that dma_fence_put() is always executed
drivers/gpu/drm/msm/msm_gem_submit.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c
index a90aedd6883a..d5e6665a4c8f 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -411,7 +411,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct msm_file_private *ctx = file->driver_priv;
struct msm_gem_submit *submit;
struct msm_gpu *gpu = priv->gpu;
- struct dma_fence *in_fence = NULL;
struct sync_file *sync_file = NULL;
struct msm_gpu_submitqueue *queue;
struct msm_ringbuffer *ring;
@@ -444,6 +443,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
ring = gpu->rb[queue->prio];
if (args->flags & MSM_SUBMIT_FENCE_FD_IN) {
+ struct dma_fence *in_fence;
+
in_fence = sync_file_get_fence(args->fence_fd);
if (!in_fence)
@@ -453,11 +454,13 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
* Wait if the fence is from a foreign context, or if the fence
* array contains any fence from a foreign context.
*/
- if (!dma_fence_match_context(in_fence, ring->fctx->context)) {
+ ret = 0;
+ if (!dma_fence_match_context(in_fence, ring->fctx->context))
ret = dma_fence_wait(in_fence, true);
- if (ret)
- return ret;
- }
+
+ dma_fence_put(in_fence);
+ if (ret)
+ return ret;
}
ret = mutex_lock_interruptible(&dev->struct_mutex);
@@ -583,8 +586,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
}
out:
- if (in_fence)
- dma_fence_put(in_fence);
submit_cleanup(submit);
if (ret)
msm_gem_submit_free(submit);
--
2.17.1
drm_atomic_helper_setup_commit() auto-completes commit->flip_done when
state->legacy_cursor_update is true, but we know for sure that we want
a sync update when we call drm_atomic_helper_setup_commit() from
vc4_atomic_commit().
Explicitly set state->legacy_cursor_update to false to prevent this
auto-completion.
Fixes: 184d3cf4f738 ("drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
---
Changes in v3:
- Add missing Fixes and Cc-stable tags
- Fix a typo in the commit message
Changes in v2:
- Add Eric's R-b
---
drivers/gpu/drm/vc4/vc4_kms.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 127468785f74..1f94b9affe4b 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -214,6 +214,12 @@ static int vc4_atomic_commit(struct drm_device *dev,
return 0;
}
+ /* We know for sure we don't want an async update here. Set
+ * state->legacy_cursor_update to false to prevent
+ * drm_atomic_helper_setup_commit() from auto-completing
+ * commit->flip_done.
+ */
+ state->legacy_cursor_update = false;
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
--
2.17.1
USB3 roothub might autosuspend before a plugged USB3 device is detected,
causing USB3 device enumeration failure.
USB3 devices don't show up as connected and enabled until USB3 link trainig
completes. On a fast booting platform with a slow USB3 link training the
link might reach the connected enabled state just as the bus is suspending.
If this device is discovered first time by the xhci_bus_suspend() routine
it will be put to U3 suspended state like the other ports which failed to
suspend earlier.
The hub thread will notice the connect change and resume the bus,
moving the port back to U0
This U0 -> U3 -> U0 transition right after being connected seems to be
too much for some devices, causing them to first go to SS.Inactive state,
and finally end up stuck in a polling state with reset asserted
Fix this by failing the bus suspend if a port has a connect change or is
in a polling state in xhci_bus_suspend().
Don't do any port changes until all ports are checked, buffer all port
changes and only write them in the end if suspend can proceed
Cc: stable(a)vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci-hub.c | 60 ++++++++++++++++++++++++++++++++++-----------
1 file changed, 46 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index da98a11..94aca1b 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1474,15 +1474,18 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
unsigned long flags;
struct xhci_hub *rhub;
struct xhci_port **ports;
+ u32 portsc_buf[USB_MAXCHILDREN];
+ bool wake_enabled;
rhub = xhci_get_rhub(hcd);
ports = rhub->ports;
max_ports = rhub->num_ports;
bus_state = &xhci->bus_state[hcd_index(hcd)];
+ wake_enabled = hcd->self.root_hub->do_remote_wakeup;
spin_lock_irqsave(&xhci->lock, flags);
- if (hcd->self.root_hub->do_remote_wakeup) {
+ if (wake_enabled) {
if (bus_state->resuming_ports || /* USB2 */
bus_state->port_remote_wakeup) { /* USB3 */
spin_unlock_irqrestore(&xhci->lock, flags);
@@ -1490,26 +1493,36 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
return -EBUSY;
}
}
-
- port_index = max_ports;
+ /*
+ * Prepare ports for suspend, but don't write anything before all ports
+ * are checked and we know bus suspend can proceed
+ */
bus_state->bus_suspended = 0;
+ port_index = max_ports;
while (port_index--) {
- /* suspend the port if the port is not suspended */
u32 t1, t2;
- int slot_id;
t1 = readl(ports[port_index]->addr);
t2 = xhci_port_state_to_neutral(t1);
+ portsc_buf[port_index] = 0;
- if ((t1 & PORT_PE) && !(t1 & PORT_PLS_MASK)) {
- xhci_dbg(xhci, "port %d not suspended\n", port_index);
- slot_id = xhci_find_slot_id_by_port(hcd, xhci,
- port_index + 1);
- if (slot_id) {
+ /* Bail out if a USB3 port has a new device in link training */
+ if ((t1 & PORT_PLS_MASK) == XDEV_POLLING) {
+ bus_state->bus_suspended = 0;
+ spin_unlock_irqrestore(&xhci->lock, flags);
+ xhci_dbg(xhci, "Bus suspend bailout, port in polling\n");
+ return -EBUSY;
+ }
+
+ /* suspend ports in U0, or bail out for new connect changes */
+ if ((t1 & PORT_PE) && (t1 & PORT_PLS_MASK) == XDEV_U0) {
+ if ((t1 & PORT_CSC) && wake_enabled) {
+ bus_state->bus_suspended = 0;
spin_unlock_irqrestore(&xhci->lock, flags);
- xhci_stop_device(xhci, slot_id, 1);
- spin_lock_irqsave(&xhci->lock, flags);
+ xhci_dbg(xhci, "Bus suspend bailout, port connect change\n");
+ return -EBUSY;
}
+ xhci_dbg(xhci, "port %d not suspended\n", port_index);
t2 &= ~PORT_PLS_MASK;
t2 |= PORT_LINK_STROBE | XDEV_U3;
set_bit(port_index, &bus_state->bus_suspended);
@@ -1518,7 +1531,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM
* is enabled, so also enable remote wake here.
*/
- if (hcd->self.root_hub->do_remote_wakeup) {
+ if (wake_enabled) {
if (t1 & PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 &= ~PORT_WKCONN_E;
@@ -1538,7 +1551,26 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
t1 = xhci_port_state_to_neutral(t1);
if (t1 != t2)
- writel(t2, ports[port_index]->addr);
+ portsc_buf[port_index] = t2;
+ }
+
+ /* write port settings, stopping and suspending ports if needed */
+ port_index = max_ports;
+ while (port_index--) {
+ if (!portsc_buf[port_index])
+ continue;
+ if (test_bit(port_index, &bus_state->bus_suspended)) {
+ int slot_id;
+
+ slot_id = xhci_find_slot_id_by_port(hcd, xhci,
+ port_index + 1);
+ if (slot_id) {
+ spin_unlock_irqrestore(&xhci->lock, flags);
+ xhci_stop_device(xhci, slot_id, 1);
+ spin_lock_irqsave(&xhci->lock, flags);
+ }
+ }
+ writel(portsc_buf[port_index], ports[port_index]->addr);
}
hcd->state = HC_STATE_SUSPENDED;
bus_state->next_statechange = jiffies + msecs_to_jiffies(10);
--
2.7.4
KEXEC needs the new kernel's load address to be aligned on a page
boundary (see sanity_check_segment_list()), but on MIPS the default
vmlinuz load address is only explicitly aligned to 16 bytes.
Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
the alignment calculated by calc_vmlinuz_load_addr to 64KB.
Cc: <stable(a)vger.kernel.org> # 2.6.36+
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
---
arch/mips/boot/compressed/calc_vmlinuz_load_addr.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c b/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c
index 37fe58c..542c3ed 100644
--- a/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c
+++ b/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c
@@ -13,6 +13,7 @@
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
+#include "../../../../include/linux/sizes.h"
int main(int argc, char *argv[])
{
@@ -45,11 +46,11 @@ int main(int argc, char *argv[])
vmlinuz_load_addr = vmlinux_load_addr + vmlinux_size;
/*
- * Align with 16 bytes: "greater than that used for any standard data
- * types by a MIPS compiler." -- See MIPS Run Linux (Second Edition).
+ * Align with 64KB: KEXEC needs load sections to be aligned to PAGE_SIZE,
+ * which may be as large as 64KB depending on the kernel configuration.
*/
- vmlinuz_load_addr += (16 - vmlinux_size % 16);
+ vmlinuz_load_addr += (SZ_64K - vmlinux_size % SZ_64K);
printf("0x%llx\n", vmlinuz_load_addr);
--
2.7.0
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 6cd078702f2f33cb6b19a682de3e9184112f1a46 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Thu, 18 Oct 2018 09:45:49 +0300
Subject: [PATCH] ovl: fix recursive oi->lock in ovl_link()
linking a non-copied-up file into a non-copied-up parent results in a
nested call to mutex_lock_interruptible(&oi->lock). Fix this by copying up
target parent before ovl_nlink_start(), same as done in ovl_rename().
~/unionmount-testsuite$ ./run --ov -s
~/unionmount-testsuite$ ln /mnt/a/foo100 /mnt/a/dir100/
WARNING: possible recursive locking detected
--------------------------------------------
ln/1545 is trying to acquire lock:
00000000bcce7c4c (&ovl_i_lock_key[depth]){+.+.}, at:
ovl_copy_up_start+0x28/0x7d
but task is already holding lock:
0000000026d73d5b (&ovl_i_lock_key[depth]){+.+.}, at:
ovl_nlink_start+0x3c/0xc1
[SzM: this seems to be a false positive, but doing the copy-up first is
harmless and removes the lockdep splat]
Reported-by: syzbot+3ef5c0d1a5cb0b21e6be(a)syzkaller.appspotmail.com
Fixes: 5f8415d6b87e ("ovl: persistent overlay inode nlink for...")
Cc: <stable(a)vger.kernel.org> # v4.13
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index 276914ae3c60..e1a55ecb7aba 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -663,6 +663,10 @@ static int ovl_link(struct dentry *old, struct inode *newdir,
if (err)
goto out_drop_write;
+ err = ovl_copy_up(new->d_parent);
+ if (err)
+ goto out_drop_write;
+
if (ovl_is_metacopy_dentry(old)) {
err = ovl_set_redirect(old, false);
if (err)
We need to actually make sure we check this on resume since otherwise we
won't know whether or not the topology is still there once we've
resumed, which will cause us to still think the topology is connected
even after it's been removed if the removal happens mid-suspend.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6cbbae3f438b..6aa3521b6326 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1255,8 +1255,16 @@ nv50_mstm_fini(struct nv50_mstm *mstm)
static void
nv50_mstm_init(struct nv50_mstm *mstm)
{
- if (mstm && mstm->mgr.mst_state)
- drm_dp_mst_topology_mgr_resume(&mstm->mgr);
+ int ret;
+
+ if (!mstm || !mstm->mgr.mst_state)
+ return;
+
+ ret = drm_dp_mst_topology_mgr_resume(&mstm->mgr);
+ if (ret == -1) {
+ drm_dp_mst_topology_mgr_set_mst(&mstm->mgr, false);
+ drm_kms_helper_hotplug_event(mstm->mgr.dev);
+ }
}
static void
--
2.19.1
The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 908a572b80f6e9577b45e81b3dfe2e22111286b8 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Fri, 28 Sep 2018 16:43:22 +0200
Subject: [PATCH] fuse: fix blocked_waitq wakeup
Using waitqueue_active() is racy. Make sure we issue a wake_up()
unconditionally after storing into fc->blocked. After that it's okay to
optimize with waitqueue_active() since the first wake up provides the
necessary barrier for all waiters, not the just the woken one.
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: 3c18ef8117f0 ("fuse: optimize wake_up")
Cc: <stable(a)vger.kernel.org> # v3.10
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 34976b42f3e1..51eb602a435b 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -391,12 +391,19 @@ static void request_end(struct fuse_conn *fc, struct fuse_req *req)
if (test_bit(FR_BACKGROUND, &req->flags)) {
spin_lock(&fc->lock);
clear_bit(FR_BACKGROUND, &req->flags);
- if (fc->num_background == fc->max_background)
+ if (fc->num_background == fc->max_background) {
fc->blocked = 0;
-
- /* Wake up next waiter, if any */
- if (!fc->blocked && waitqueue_active(&fc->blocked_waitq))
wake_up(&fc->blocked_waitq);
+ } else if (!fc->blocked) {
+ /*
+ * Wake up next waiter, if any. It's okay to use
+ * waitqueue_active(), as we've already synced up
+ * fc->blocked with waiters with the wake_up() call
+ * above.
+ */
+ if (waitqueue_active(&fc->blocked_waitq))
+ wake_up(&fc->blocked_waitq);
+ }
if (fc->num_background == fc->congestion_threshold && fc->sb) {
clear_bdi_congested(fc->sb->s_bdi, BLK_RW_SYNC);
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From db186382af21e926e90df19499475f2552192b77 Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Wed, 26 Sep 2018 22:05:12 -0700
Subject: [PATCH] scsi: qla2xxx: Fix NVMe Target discovery
This patch fixes issue when remoteport registers itself as both FCP and
FC-NVMe with the switch, driver will pick FC-NVMe personality as default when
scanning for targets.
Driver was using comaprative operator instead of bitwise operator to check for
fc4_type for both FCP and FC-NVME.
Fixes: 2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Reviewed-by: Ewan D. Milne <emilne(a)redhat.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 429033ab6897..dba672f87cb2 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -4880,10 +4880,10 @@ void qla24xx_create_new_sess(struct scsi_qla_host *vha, struct qla_work_evt *e)
fcport->d_id = e->u.new_sess.id;
fcport->flags |= FCF_FABRIC_DEVICE;
fcport->fw_login_state = DSC_LS_PLOGI_PEND;
- if (e->u.new_sess.fc4_type == FS_FC4TYPE_FCP)
+ if (e->u.new_sess.fc4_type & FS_FC4TYPE_FCP)
fcport->fc4_type = FC4_TYPE_FCP_SCSI;
- if (e->u.new_sess.fc4_type == FS_FC4TYPE_NVME) {
+ if (e->u.new_sess.fc4_type & FS_FC4TYPE_NVME) {
fcport->fc4_type = FC4_TYPE_OTHER;
fcport->fc4f_nvme = FC4_TYPE_NVME;
}
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 56d942de59ebfa2e970a6cd33299d1984710b6c0 Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Tue, 11 Sep 2018 10:18:22 -0700
Subject: [PATCH] scsi: qla2xxx: Reject bsg request if chip is down.
Reject bsg request if chip is down. This prevent erroneous timeout.
Fixes: d051a5aa1c23 ("[SCSI] qla2xxx: Add an "is reset active" helper.")
Cc: stable(a)vger.kernel.org # 4.10
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index c11a89be292c..4a9fd8d944d6 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -2487,7 +2487,7 @@ qla24xx_bsg_request(struct bsg_job *bsg_job)
vha = shost_priv(host);
}
- if (qla2x00_reset_active(vha)) {
+ if (qla2x00_chip_is_down(vha)) {
ql_dbg(ql_dbg_user, vha, 0x709f,
"BSG: ISP abort active/needed -- cmd=%d.\n",
bsg_request->msgcode);
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 56d942de59ebfa2e970a6cd33299d1984710b6c0 Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Tue, 11 Sep 2018 10:18:22 -0700
Subject: [PATCH] scsi: qla2xxx: Reject bsg request if chip is down.
Reject bsg request if chip is down. This prevent erroneous timeout.
Fixes: d051a5aa1c23 ("[SCSI] qla2xxx: Add an "is reset active" helper.")
Cc: stable(a)vger.kernel.org # 4.10
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index c11a89be292c..4a9fd8d944d6 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -2487,7 +2487,7 @@ qla24xx_bsg_request(struct bsg_job *bsg_job)
vha = shost_priv(host);
}
- if (qla2x00_reset_active(vha)) {
+ if (qla2x00_chip_is_down(vha)) {
ql_dbg(ql_dbg_user, vha, 0x709f,
"BSG: ISP abort active/needed -- cmd=%d.\n",
bsg_request->msgcode);
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f7d61c995df74d6bb57bbff6a2b7b1874c4a2baa Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Wed, 26 Sep 2018 22:05:11 -0700
Subject: [PATCH] scsi: qla2xxx: Fix NVMe session hang on unload
Send aborts only when chip is active.
Fixes: 623ee824e579 ("scsi: qla2xxx: Fix FC-NVMe IO abort during driver reset")
Cc: <stable(a)vger.kernel.org> # 4.14
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Reviewed-by: Ewan D. Milne <emilne(a)redhat.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/qla2xxx/qla_nvme.c b/drivers/scsi/qla2xxx/qla_nvme.c
index 42dc846cc8dd..ad923965be3c 100644
--- a/drivers/scsi/qla2xxx/qla_nvme.c
+++ b/drivers/scsi/qla2xxx/qla_nvme.c
@@ -607,7 +607,7 @@ void qla_nvme_abort(struct qla_hw_data *ha, struct srb *sp, int res)
{
int rval;
- if (!test_bit(ABORT_ISP_ACTIVE, &sp->vha->dpc_flags)) {
+ if (ha->flags.fw_started) {
rval = ha->isp_ops->abort_command(sp);
if (!rval && !qla_nvme_wait_on_command(sp))
ql_log(ql_log_warn, NULL, 0x2112,
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 641a41dbba217ee5bd26abe6be77f8cead9cd00e Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Tue, 30 Oct 2018 15:13:35 +0900
Subject: [PATCH] serial: sh-sci: Fix could not remove dev_attr_rx_fifo_timeout
This patch fixes an issue that the sci_remove() could not remove
dev_attr_rx_fifo_timeout because uart_remove_one_port() set
the port->port.type to PORT_UNKNOWN.
Reported-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Fixes: 5d23188a473d ("serial: sh-sci: make RX FIFO parameters tunable via sysfs")
Cc: <stable(a)vger.kernel.org> # v4.11+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Reviewed-by: Ulrich Hecht <uli+renesas(a)fpond.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index e19bfbba8a01..effba6ce0caa 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3102,6 +3102,7 @@ static struct uart_driver sci_uart_driver = {
static int sci_remove(struct platform_device *dev)
{
struct sci_port *port = platform_get_drvdata(dev);
+ unsigned int type = port->port.type; /* uart_remove_... clears it */
sci_ports_in_use &= ~BIT(port->port.line);
uart_remove_one_port(&sci_uart_driver, &port->port);
@@ -3112,8 +3113,7 @@ static int sci_remove(struct platform_device *dev)
sysfs_remove_file(&dev->dev.kobj,
&dev_attr_rx_fifo_trigger.attr);
}
- if (port->port.type == PORT_SCIFA || port->port.type == PORT_SCIFB ||
- port->port.type == PORT_HSCIF) {
+ if (type == PORT_SCIFA || type == PORT_SCIFB || type == PORT_HSCIF) {
sysfs_remove_file(&dev->dev.kobj,
&dev_attr_rx_fifo_timeout.attr);
}
The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5e1275808630ea3b2c97c776f40e475017535f72 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Wed, 31 Oct 2018 12:15:23 +0100
Subject: [PATCH] ovl: check whiteout in ovl_create_over_whiteout()
Kaixuxia repors that it's possible to crash overlayfs by removing the
whiteout on the upper layer before creating a directory over it. This is a
reproducer:
mkdir lower upper work merge
touch lower/file
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge
rm merge/file
ls -al merge/file
rm upper/file
ls -al merge/
mkdir merge/file
Before commencing with a vfs_rename(..., RENAME_EXCHANGE) verify that the
lookup of "upper" is positive and is a whiteout, and return ESTALE
otherwise.
Reported by: kaixuxia <xiakaixu1987(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: e9be9d5e76e3 ("overlay filesystem")
Cc: <stable(a)vger.kernel.org> # v3.18
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index ce1857fb5434..c6289147c787 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -462,6 +462,10 @@ static int ovl_create_over_whiteout(struct dentry *dentry, struct inode *inode,
if (IS_ERR(upper))
goto out_unlock;
+ err = -ESTALE;
+ if (d_is_negative(upper) || !IS_WHITEOUT(d_inode(upper)))
+ goto out_dput;
+
newdentry = ovl_create_temp(workdir, cattr);
err = PTR_ERR(newdentry);
if (IS_ERR(newdentry))
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5e1275808630ea3b2c97c776f40e475017535f72 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Wed, 31 Oct 2018 12:15:23 +0100
Subject: [PATCH] ovl: check whiteout in ovl_create_over_whiteout()
Kaixuxia repors that it's possible to crash overlayfs by removing the
whiteout on the upper layer before creating a directory over it. This is a
reproducer:
mkdir lower upper work merge
touch lower/file
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge
rm merge/file
ls -al merge/file
rm upper/file
ls -al merge/
mkdir merge/file
Before commencing with a vfs_rename(..., RENAME_EXCHANGE) verify that the
lookup of "upper" is positive and is a whiteout, and return ESTALE
otherwise.
Reported by: kaixuxia <xiakaixu1987(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: e9be9d5e76e3 ("overlay filesystem")
Cc: <stable(a)vger.kernel.org> # v3.18
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index ce1857fb5434..c6289147c787 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -462,6 +462,10 @@ static int ovl_create_over_whiteout(struct dentry *dentry, struct inode *inode,
if (IS_ERR(upper))
goto out_unlock;
+ err = -ESTALE;
+ if (d_is_negative(upper) || !IS_WHITEOUT(d_inode(upper)))
+ goto out_dput;
+
newdentry = ovl_create_temp(workdir, cattr);
err = PTR_ERR(newdentry);
if (IS_ERR(newdentry))
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 6cd078702f2f33cb6b19a682de3e9184112f1a46 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Thu, 18 Oct 2018 09:45:49 +0300
Subject: [PATCH] ovl: fix recursive oi->lock in ovl_link()
linking a non-copied-up file into a non-copied-up parent results in a
nested call to mutex_lock_interruptible(&oi->lock). Fix this by copying up
target parent before ovl_nlink_start(), same as done in ovl_rename().
~/unionmount-testsuite$ ./run --ov -s
~/unionmount-testsuite$ ln /mnt/a/foo100 /mnt/a/dir100/
WARNING: possible recursive locking detected
--------------------------------------------
ln/1545 is trying to acquire lock:
00000000bcce7c4c (&ovl_i_lock_key[depth]){+.+.}, at:
ovl_copy_up_start+0x28/0x7d
but task is already holding lock:
0000000026d73d5b (&ovl_i_lock_key[depth]){+.+.}, at:
ovl_nlink_start+0x3c/0xc1
[SzM: this seems to be a false positive, but doing the copy-up first is
harmless and removes the lockdep splat]
Reported-by: syzbot+3ef5c0d1a5cb0b21e6be(a)syzkaller.appspotmail.com
Fixes: 5f8415d6b87e ("ovl: persistent overlay inode nlink for...")
Cc: <stable(a)vger.kernel.org> # v4.13
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index 276914ae3c60..e1a55ecb7aba 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -663,6 +663,10 @@ static int ovl_link(struct dentry *old, struct inode *newdir,
if (err)
goto out_drop_write;
+ err = ovl_copy_up(new->d_parent);
+ if (err)
+ goto out_drop_write;
+
if (ovl_is_metacopy_dentry(old)) {
err = ovl_set_redirect(old, false);
if (err)
Currently, when checking to see if accessing n bytes starting at
address "ptr" will cause a wraparound in the memory addresses,
the check in check_bogus_address() adds an extra byte, which is
incorrect, as the range of addresses that will be accessed is
[ptr, ptr + (n - 1)].
This can lead to incorrectly detecting a wraparound in the
memory address, when trying to read 4 KB from memory that is
mapped to the the last possible page in the virtual address
space, when in fact, accessing that range of memory would not
cause a wraparound to occur.
Use the memory range that will actually be accessed when
considering if accessing a certain amount of bytes will cause
the memory address to wrap around.
Change-Id: I2563a5988e41122727ede17180f365e999b953e6
Fixes: f5509cc18daa ("mm: Hardened usercopy")
Co-Developed-by: Prasad Sodagudi <psodagud(a)codeaurora.org>
Signed-off-by: Prasad Sodagudi <psodagud(a)codeaurora.org>
Signed-off-by: Isaac J. Manjarres <isaacm(a)codeaurora.org>
Cc: stable(a)vger.kernel.org
---
mm/usercopy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/usercopy.c b/mm/usercopy.c
index 852eb4e..0293645 100644
--- a/mm/usercopy.c
+++ b/mm/usercopy.c
@@ -151,7 +151,7 @@ static inline void check_bogus_address(const unsigned long ptr, unsigned long n,
bool to_user)
{
/* Reject if object wraps past end of memory. */
- if (ptr + n < ptr)
+ if (ptr + (n - 1) < ptr)
usercopy_abort("wrapped address", NULL, to_user, 0, ptr + n);
/* Reject if NULL or ZERO-allocation. */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
stable-rc/linux-3.18.y build: 183 builds: 0 failed, 183 passed, 291 warnings (v3.18.125-63-g90468834bfa7)
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.125-6…
Tree: stable-rc
Branch: linux-3.18.y
Git Describe: v3.18.125-63-g90468834bfa7
Git Commit: 90468834bfa76d1ba14ad2fd13e65fef3f3f3c77
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 4 unique architectures
Warnings Detected:
arm64: gcc version 7.3.0 (Debian 7.3.0-28)
allnoconfig: 2 warnings
defconfig: 2 warnings
tinyconfig: 2 warnings
arm: gcc version 7.3.0 (Debian 7.3.0-28)
acs5k_defconfig: 2 warnings
acs5k_tiny_defconfig: 2 warnings
allnoconfig: 2 warnings
am200epdkit_defconfig: 2 warnings
ape6evm_defconfig: 2 warnings
armadillo800eva_defconfig: 2 warnings
assabet_defconfig: 2 warnings
at91_dt_defconfig: 2 warnings
at91rm9200_defconfig: 2 warnings
at91sam9260_9g20_defconfig: 2 warnings
at91sam9261_9g10_defconfig: 2 warnings
at91sam9263_defconfig: 2 warnings
at91sam9g45_defconfig: 2 warnings
at91sam9rl_defconfig: 2 warnings
at91x40_defconfig: 2 warnings
axm55xx_defconfig: 2 warnings
badge4_defconfig: 2 warnings
bcm2835_defconfig: 2 warnings
bcm_defconfig: 2 warnings
bockw_defconfig: 2 warnings
cerfcube_defconfig: 2 warnings
clps711x_defconfig: 2 warnings
cm_x2xx_defconfig: 2 warnings
cm_x300_defconfig: 2 warnings
cns3420vb_defconfig: 2 warnings
colibri_pxa270_defconfig: 2 warnings
colibri_pxa300_defconfig: 2 warnings
collie_defconfig: 2 warnings
corgi_defconfig: 2 warnings
davinci_all_defconfig: 2 warnings
dove_defconfig: 2 warnings
ebsa110_defconfig: 2 warnings
efm32_defconfig: 2 warnings
em_x270_defconfig: 2 warnings
ep93xx_defconfig: 2 warnings
eseries_pxa_defconfig: 2 warnings
exynos_defconfig: 2 warnings
ezx_defconfig: 2 warnings
footbridge_defconfig: 2 warnings
h3600_defconfig: 2 warnings
h5000_defconfig: 2 warnings
hackkit_defconfig: 2 warnings
hisi_defconfig: 2 warnings
imote2_defconfig: 2 warnings
imx_v4_v5_defconfig: 2 warnings
imx_v6_v7_defconfig: 2 warnings
integrator_defconfig: 2 warnings
iop13xx_defconfig: 2 warnings
iop32x_defconfig: 2 warnings
iop33x_defconfig: 2 warnings
ixp4xx_defconfig: 2 warnings
jornada720_defconfig: 2 warnings
keystone_defconfig: 2 warnings
koelsch_defconfig: 2 warnings
ks8695_defconfig: 2 warnings
kzm9g_defconfig: 2 warnings
lager_defconfig: 2 warnings
lart_defconfig: 2 warnings
lpc32xx_defconfig: 2 warnings
lpd270_defconfig: 2 warnings
lubbock_defconfig: 2 warnings
mackerel_defconfig: 2 warnings
magician_defconfig: 2 warnings
mainstone_defconfig: 2 warnings
marzen_defconfig: 2 warnings
mini2440_defconfig: 2 warnings
mmp2_defconfig: 2 warnings
moxart_defconfig: 2 warnings
msm_defconfig: 2 warnings
multi_v5_defconfig: 2 warnings
multi_v7_defconfig: 2 warnings
mv78xx0_defconfig: 2 warnings
mvebu_v5_defconfig: 2 warnings
mvebu_v7_defconfig: 2 warnings
mxs_defconfig: 2 warnings
neponset_defconfig: 2 warnings
netwinder_defconfig: 2 warnings
netx_defconfig: 2 warnings
nhk8815_defconfig: 2 warnings
nuc910_defconfig: 2 warnings
nuc950_defconfig: 2 warnings
nuc960_defconfig: 2 warnings
omap1_defconfig: 2 warnings
omap2plus_defconfig: 2 warnings
orion5x_defconfig: 2 warnings
palmz72_defconfig: 2 warnings
pcm027_defconfig: 2 warnings
pleb_defconfig: 2 warnings
prima2_defconfig: 2 warnings
pxa168_defconfig: 2 warnings
pxa255-idp_defconfig: 2 warnings
pxa3xx_defconfig: 2 warnings
pxa910_defconfig: 2 warnings
qcom_defconfig: 2 warnings
raumfeld_defconfig: 2 warnings
realview-smp_defconfig: 2 warnings
realview_defconfig: 2 warnings
rpc_defconfig: 2 warnings
s3c2410_defconfig: 2 warnings
s3c6400_defconfig: 2 warnings
s5pv210_defconfig: 2 warnings
sama5_defconfig: 2 warnings
shannon_defconfig: 2 warnings
shmobile_defconfig: 2 warnings
simpad_defconfig: 2 warnings
socfpga_defconfig: 2 warnings
spear13xx_defconfig: 2 warnings
spear3xx_defconfig: 2 warnings
spear6xx_defconfig: 2 warnings
spitz_defconfig: 2 warnings
sunxi_defconfig: 2 warnings
tct_hammer_defconfig: 2 warnings
tegra_defconfig: 2 warnings
tinyconfig: 2 warnings
trizeps4_defconfig: 2 warnings
u300_defconfig: 2 warnings
u8500_defconfig: 2 warnings
versatile_defconfig: 2 warnings
vexpress_defconfig: 2 warnings
viper_defconfig: 2 warnings
vt8500_v6_v7_defconfig: 2 warnings
xcep_defconfig: 2 warnings
zeus_defconfig: 2 warnings
x86: gcc version 7.3.0 (Debian 7.3.0-29)
allnoconfig: 3 warnings
i386_defconfig: 3 warnings
tinyconfig: 3 warnings
x86_64_defconfig: 30 warnings
Warnings summary:
126 scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
126 scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
3 arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
2 include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
1 net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
1 lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
1 kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
1 drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
1 block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
1 block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
allnoconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ape6evm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
armadillo800eva_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
assabet_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91_dt_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91rm9200_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9260_9g20_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9261_9g10_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9263_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9g45_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9rl_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91x40_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ath79_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
badge4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm2835_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bigsur_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bockw_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
capcella_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
clps711x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cns3420vb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cobalt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
collie_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
corgi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
davinci_all_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
db1xxx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
dove_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
e55_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
efm32_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
em_x270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ep93xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
exynos_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ezx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
footbridge_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
h5000_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hackkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hisi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
i386_defconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
imote2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
integrator_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop32x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop33x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ip22_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
jazz_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
keystone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
koelsch_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ks8695_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
kzm9g_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lager_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lasat_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lpd270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ls1b_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mackerel_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
magician_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mainstone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
malta_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
marzen_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mini2440_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
moxart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mpc30x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
msp71xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mv78xx0_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mxs_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
neponset_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netwinder_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nhk8815_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc950_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc960_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap1_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap2plus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
orion5x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
palmz72_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pcm027_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pleb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa168_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qcom_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rb532_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview-smp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
realview_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rm200_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rt305x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s3c6400_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s5pv210_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sama5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3micro_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
shmobile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
simpad_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
socfpga_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear6xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spitz_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sunxi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tb0219_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tegra_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
tinyconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
trizeps4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u8500_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
versatile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vexpress_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
viper_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
workpad_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86) — PASS, 0 errors, 30 warnings, 0 section mismatches
Warnings:
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
--------------------------------------------------------------------------------
xcep_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
xway_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
---
For more info write to <info(a)kernelci.org>
This is a note to let you know that I've just added the patch titled
usb: core: Fix hub port connection events lost
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 22454b79e6de05fa61a2a72d00d2eed798abbb75 Mon Sep 17 00:00:00 2001
From: Dennis Wassenberg <dennis.wassenberg(a)secunet.com>
Date: Tue, 13 Nov 2018 14:40:34 +0100
Subject: usb: core: Fix hub port connection events lost
This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset
only if a device is was attached to the hub port before resetting the hub port.
Using a Lenovo T480s attached to the ultra dock it was not possible to detect
some usb-c devices at the dock usb-c ports because the hub_port_reset code
will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset.
Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the
actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit.
This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the
new device was attached such that it was not detected.
This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is
currently no device attached to the port before the hub port reset.
This will avoid clearing the connection bit for new attached devices.
Signed-off-by: Dennis Wassenberg <dennis.wassenberg(a)secunet.com>
Acked-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/hub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d9bd7576786a..0f9381b69a3b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2850,7 +2850,9 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
USB_PORT_FEAT_C_BH_PORT_RESET);
usb_clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
- usb_clear_port_feature(hub->hdev, port1,
+
+ if (udev)
+ usb_clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
/*
--
2.19.1
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 2fc6d4be35fb1e262f209758e25bfe2b7a113a7f Mon Sep 17 00:00:00 2001
From: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Date: Wed, 1 Aug 2018 09:37:34 +0300
Subject: usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers
When chaining ISOC TRBs together, only the first ISOC TRB should be of
type ISOC_FIRST, all others should be of type ISOC. This patch fixes
that.
Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
Cc: <stable(a)vger.kernel.org> # v4.11+
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/dwc3/gadget.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 06e22afdf3d1..9faad896b3a1 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1081,7 +1081,7 @@ static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
/* Now prepare one extra TRB to align transfer size */
trb = &dep->trb_pool[dep->trb_enqueue];
__dwc3_prepare_one_trb(dep, trb, dwc->bounce_addr,
- maxp - rem, false, 0,
+ maxp - rem, false, 1,
req->request.stream_id,
req->request.short_not_ok,
req->request.no_interrupt);
@@ -1125,7 +1125,7 @@ static void dwc3_prepare_one_trb_linear(struct dwc3_ep *dep,
/* Now prepare one extra TRB to align transfer size */
trb = &dep->trb_pool[dep->trb_enqueue];
__dwc3_prepare_one_trb(dep, trb, dwc->bounce_addr, maxp - rem,
- false, 0, req->request.stream_id,
+ false, 1, req->request.stream_id,
req->request.short_not_ok,
req->request.no_interrupt);
} else if (req->request.zero && req->request.length &&
@@ -1141,7 +1141,7 @@ static void dwc3_prepare_one_trb_linear(struct dwc3_ep *dep,
/* Now prepare one extra TRB to handle ZLP */
trb = &dep->trb_pool[dep->trb_enqueue];
__dwc3_prepare_one_trb(dep, trb, dwc->bounce_addr, 0,
- false, 0, req->request.stream_id,
+ false, 1, req->request.stream_id,
req->request.short_not_ok,
req->request.no_interrupt);
} else {
--
2.19.1
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix NULL pointer exception in dwc3_pci_remove()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7b412b04a0c7000293008231ce8413056abb1982 Mon Sep 17 00:00:00 2001
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy(a)linux.intel.com>
Date: Wed, 17 Oct 2018 11:40:26 -0700
Subject: usb: dwc3: Fix NULL pointer exception in dwc3_pci_remove()
In dwc3_pci_quirks() function, gpiod lookup table is only registered for
baytrail SOC. But in dwc3_pci_remove(), we try to unregistered it
without any checks. This leads to NULL pointer de-reference exception in
gpiod_remove_lookup_table() when unloading the module for non baytrail
SOCs. This patch fixes this issue.
Fixes: 5741022cbdf3 ("usb: dwc3: pci: Add GPIO lookup table on platforms
without ACPI GPIO resources")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy(a)linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/dwc3/dwc3-pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 1286076a8890..842795856bf4 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -283,8 +283,10 @@ static int dwc3_pci_probe(struct pci_dev *pci, const struct pci_device_id *id)
static void dwc3_pci_remove(struct pci_dev *pci)
{
struct dwc3_pci *dwc = pci_get_drvdata(pci);
+ struct pci_dev *pdev = dwc->pci;
- gpiod_remove_lookup_table(&platform_bytcr_gpios);
+ if (pdev->device == PCI_DEVICE_ID_INTEL_BYT)
+ gpiod_remove_lookup_table(&platform_bytcr_gpios);
#ifdef CONFIG_PM
cancel_work_sync(&dwc->wakeup_work);
#endif
--
2.19.1
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Properly check last unaligned/zero chain TRB
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From ba3a51ac32ebcf8d0a54b37f1af268ad8a31c52f Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Thu, 2 Aug 2018 20:17:16 -0700
Subject: usb: dwc3: gadget: Properly check last unaligned/zero chain TRB
Current check for the last extra TRB for zero and unaligned transfers
does not account for isoc OUT. The last TRB of the Buffer Descriptor for
isoc OUT transfers will be retired with HWO=0. As a result, we won't
return early. The req->remaining will be updated to include the BUFSIZ
count of the extra TRB, and the actual number of transferred bytes
calculation will be wrong.
To fix this, check whether it's a short or zero packet and the last TRB
chain bit to return early.
Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/dwc3/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 679c12e14522..06e22afdf3d1 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2259,7 +2259,7 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
* with one TRB pending in the ring. We need to manually clear HWO bit
* from that TRB.
*/
- if ((req->zero || req->unaligned) && (trb->ctrl & DWC3_TRB_CTRL_HWO)) {
+ if ((req->zero || req->unaligned) && !(trb->ctrl & DWC3_TRB_CTRL_CHN)) {
trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
return 1;
}
--
2.19.1
This is a note to let you know that I've just added the patch titled
usb: dwc3: core: Clean up ULPI device
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 08fd9a82fda86529bb2f2af3c2f7cb657b4d3066 Mon Sep 17 00:00:00 2001
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Date: Mon, 27 Aug 2018 18:30:16 +0300
Subject: usb: dwc3: core: Clean up ULPI device
If dwc3_core_init_mode() fails with deferred probe,
next probe fails on sysfs with
sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:11.0/dwc3.0.auto/dwc3.0.auto.ulpi'
To avoid this failure, clean up ULPI device.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/dwc3/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index becfbb87f791..2f2048aa5fde 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1499,6 +1499,7 @@ static int dwc3_probe(struct platform_device *pdev)
err5:
dwc3_event_buffers_cleanup(dwc);
+ dwc3_ulpi_exit(dwc);
err4:
dwc3_free_scratch_buffers(dwc);
--
2.19.1
This reverts commit 8c934095fa2f ("PCI: dwc: Clear MSI interrupt status
after it is handled, not before").
This is a very real race that we observed quickly after switching from
4.13 to 4.16. Using a custom PCI-e endpoint and driver, I was able to
track it to the precise race and verify the fixed behavior, as will be
described below.
This bug was originally fixed in 2013, in commit ca1658921b63 ("PCI:
designware: Fix missing MSI IRQs") The discussion of that commit,
archived in patchwork [1], is informative and worth reading.
The bug was re-added in the '8c934 commit this is reverting, which
appeared in the 4.14 kernel.
Unfortunately, Synopsys appears to consider the operation of this PCI-e
controller secret. They provide no publicly available docs for it nor
allow the references manuals of SoCs using the controller to publish any
documentation of it.
So I can not say certain this code is correctly using the controller's
features. However, extensive testing gives me high confidence in the
accuracy of what is described below.
If an MSI is received by the PCI-e controller while the status register
bit for that MSI is set, the PCI-e controller will NOT generate another
interrupt. In addition, it will NOT queue or otherwise mark the
interrupt as "pending", which means it will NOT generate an interrupt
when the status bit is unmasked.
This gives the following race scenario:
1. An MSI is received by, and the status bit for the MSI is set in, the
DWC PCI-e controller.
2. dw_handle_msi_irq() calls a driver's registered interrupt handler
for the MSI received.
3. At some point, the interrupt handler must decide, correctly, that
there is no more work to do and return.
4. The hardware generates a new MSI. As the MSI's status bit is still
set, this new MSI is ignored.
6. dw_handle_msi_irq() unsets the MSI status bit.
The MSI received at point 4 will never be acted upon. It occurred after
the driver had finished checking the hardware status for interrupt
conditions to act on. Since the MSI status was masked, it does not
generated a new IRQ, neither when it was received nor when the MSI is
unmasked.
It seems clear there is an unsolvable race here.
After this patch, the sequence becomes as follows:
1. An MSI is received and the status bit for the MSI is set in the
DWC PCI-e controller.
2. dw_handle_msi_irq() clears this MSI status bit.
3. dw_handle_msi_irq() calls a driver's registered interrupt handler
for the MSI received.
3. At some point, the interrupt handler must decide, correctly, that
there is no more work to do and return.
4. The hardware generates a new MSI. This sets the MSI status bit and
triggers another interrupt in the interrupt controller(s) above the DWC
PCI-e controller. As the the dwc-pcie handler is not re-entrant, it is
not run again at this time.
6. dw_handle_msi_irq() finishes. The MSI status bit remains set.
7. The IRQ is re-raised and dw_handle_msi_irq() runs again.
8. dw_handle_msi_irq() invokes the MSI's registered interrupt handler
again as the status bit was still set.
The observant will notice that point 4 present the opportunity for the
SoC's interrupt controller to lose the interrupt in the same manner as
the bug in this driver. The driver for that interrupt controller will
be written to properly deal with this. In some cases the hardware
supports an EOI concept, where the 2nd IRQ is masked and internally
queued in the hardware, to be re-raised at EOI in step 7. In other
cases the IRQ will be unmasked and re-raised at step 4, but the kernel
will see the handler is INPROGRESS and not re-invoke it, and instead set
a PENDING flag, which causes the handler to re-run at step 7.
[1] https://patchwork.kernel.org/patch/3333681/
Fixes: 8c934095fa2f ("PCI: dwc: Clear MSI interrupt status after it is handled, not before")
Cc: stable(a)vger.kernel.org
Cc: Vignesh R <vigneshr(a)ti.com>
Cc: Faiz Abbas <faiz_abbas(a)ti.com>
Cc: Jingoo Han <jingoohan1(a)gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel(a)synopsys.com>
Cc: Joao Pinto <jpinto(a)synopsys.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Cc: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Trent Piepho <tpiepho(a)impinj.com>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 29a05759a294..9a3960c95ad3 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -98,10 +98,10 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
irq = irq_find_mapping(pp->irq_domain,
(i * MAX_MSI_IRQS_PER_CTRL) +
pos);
- generic_handle_irq(irq);
dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS +
(i * MSI_REG_CTRL_BLOCK_SIZE),
4, 1 << pos);
+ generic_handle_irq(irq);
pos++;
}
}
--
2.14.4
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code in the _SetupMMU block in
the arch/xtensa/kernel/head.S is supposed to map that physical address to
the virtual address in the configured virtual memory layout.
This code haven't been updated when additional 256+256 and 512+512
memory layouts were introduced and it may produce wrong addresses when
used with these layouts.
Cc: stable(a)vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com>
---
arch/xtensa/kernel/head.S | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/xtensa/kernel/head.S b/arch/xtensa/kernel/head.S
index 2f76118ecf62..9053a5622d2c 100644
--- a/arch/xtensa/kernel/head.S
+++ b/arch/xtensa/kernel/head.S
@@ -88,9 +88,12 @@ _SetupMMU:
initialize_mmu
#if defined(CONFIG_MMU) && XCHAL_HAVE_PTP_MMU && XCHAL_HAVE_SPANNING_WAY
rsr a2, excsave1
- movi a3, 0x08000000
+ movi a3, XCHAL_KSEG_PADDR
+ bltu a2, a3, 1f
+ sub a2, a2, a3
+ movi a3, XCHAL_KSEG_SIZE
bgeu a2, a3, 1f
- movi a3, 0xd0000000
+ movi a3, XCHAL_KSEG_CACHED_VADDR
add a2, a2, a3
wsr a2, excsave1
1:
--
2.11.0
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
I have a Thinkpad X220 Tablet in my hands that is losing vblank
interrupts whenever LP3 watermarks are used.
If I nudge the latency value written to the WM3 register just
by one in either direction the problem disappears. That to me
suggests that the punit will not enter the corrsponding
powersave mode (MPLL shutdown IIRC) unless the latency value
in the register matches exactly what we read from SSKPD. Ie.
it's not really a latency value but rather just a cookie
by which the punit can identify the desired power saving state.
On HSW/BDW this was changed such that we actually just write
the WM level number into those bits, which makes much more
sense given the observed behaviour.
We could try to handle this by disallowing LP3 watermarks
only when vblank interrupts are enabled but we'd first have
to prove that only vblank interrupts are affected, which
seems unlikely. Also we can't grab the wm mutex from the
vblank enable/disable hooks because those are called with
various spinlocks held. Thus we'd have to redesigne the
watermark locking. So to play it safe and keep the code
simple we simply disable LP3 watermarks on all SNB machines.
To do that we simply zero out the latency values for
watermark level 3, and we adjust the watermark computation
to check for that. The behaviour now matches that of the
g4x/vlv/skl wm code in the presence of a zeroed latency
value.
Cc: stable(a)vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/i915/intel_pm.c | 41 ++++++++++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27498ded4949..ef1ae2ede379 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2493,6 +2493,9 @@ static uint32_t ilk_compute_pri_wm(const struct intel_crtc_state *cstate,
uint32_t method1, method2;
int cpp;
+ if (mem_value == 0)
+ return USHRT_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -2522,6 +2525,9 @@ static uint32_t ilk_compute_spr_wm(const struct intel_crtc_state *cstate,
uint32_t method1, method2;
int cpp;
+ if (mem_value == 0)
+ return USHRT_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -2545,6 +2551,9 @@ static uint32_t ilk_compute_cur_wm(const struct intel_crtc_state *cstate,
{
int cpp;
+ if (mem_value == 0)
+ return USHRT_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -3008,6 +3017,34 @@ static void snb_wm_latency_quirk(struct drm_i915_private *dev_priv)
intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
}
+static void snb_wm_lp3_irq_quirk(struct drm_i915_private *dev_priv)
+{
+ /*
+ * On some SNB machines (Thinkpad X220 Tablet at least)
+ * LP3 usage can cause vblank interrupts to be lost.
+ * The DEIIR bit will go high but it looks like the CPU
+ * never gets interrupted.
+ *
+ * It's not clear whether other interrupt source could
+ * be affected or if this is somehow limited to vblank
+ * interrupts only. To play it safe we disable LP3
+ * watermarks entirely.
+ */
+ if (dev_priv->wm.pri_latency[3] == 0 &&
+ dev_priv->wm.spr_latency[3] == 0 &&
+ dev_priv->wm.cur_latency[3] == 0)
+ return;
+
+ dev_priv->wm.pri_latency[3] = 0;
+ dev_priv->wm.spr_latency[3] = 0;
+ dev_priv->wm.cur_latency[3] = 0;
+
+ DRM_DEBUG_KMS("LP3 watermarks disabled due to potential for lost interrupts\n");
+ intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency);
+ intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
+ intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
+}
+
static void ilk_setup_wm_latency(struct drm_i915_private *dev_priv)
{
intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency);
@@ -3024,8 +3061,10 @@ static void ilk_setup_wm_latency(struct drm_i915_private *dev_priv)
intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
- if (IS_GEN6(dev_priv))
+ if (IS_GEN6(dev_priv)) {
snb_wm_latency_quirk(dev_priv);
+ snb_wm_lp3_irq_quirk(dev_priv);
+ }
}
static void skl_setup_wm_latency(struct drm_i915_private *dev_priv)
--
2.18.1
On Mon, Oct 22, 2018 at 11:44:22AM +0200, Torbjorn Jansson wrote:
> On 2018-10-22 10:59, Sean Young wrote:
> > On Sat, Oct 20, 2018 at 11:12:16PM +0200, Hans Verkuil wrote:
> > > Hi Sean,
> > >
> > > Can you take a look at this, it appears to be an RC issue, see my analysis below.
> > >
> > > On 10/20/2018 03:26 PM, Torbjorn Jansson wrote:
> > > > Hello
> > > >
> > > > i'm using the pulse8 usb cec adapter to control my tv.
> > > > i have a few scripts that poll the power status of my tv and after a while it stops working returning errors when trying to check if tv is on or off.
> > > > this i think matches a kernel oops i'm seeing that i suspect is related to this.
> > > >
> > > > i have sometimes been able to recover from this problem by completely cutting power to my tv and also unplugging the usb cec adapter.
> > > > i have a feeling that the tv is at least partly to blame for cec-ctl not working but in any case there shouldn't be a kernel oops.
> > > >
> > > >
> > > > also every now and then i see this in dmesg:
> > > > cec cec0: transmit: failed 05
> > > > cec cec0: transmit: failed 06
> > > > but that doesn't appear to do any harm as far as i can tell.
> > > >
> > > > any idea whats causing the oops?
> > > >
> > > > the ops:
> > > >
> > > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
> > > > PGD 0 P4D 0
> > > > Oops: 0000 [#1] SMP PTI
> > > > CPU: 9 PID: 27687 Comm: kworker/9:2 Tainted: P OE 4.18.12-200.fc28.x86_64 #1
> > > > Hardware name: Supermicro C7X99-OCE-F/C7X99-OCE-F, BIOS 2.1a 06/15/2018
> > > > Workqueue: events pulse8_irq_work_handler [pulse8_cec]
> > > > RIP: 0010:ir_lirc_scancode_event+0x3d/0xb0 [rc_core]
> > >
> > > Huh. ir_lirc_scancode_event() calls spin_lock_irqsave(&dev->lirc_fh_lock, flags);
> > >
> > > The spinlock dev->lirc_fh_lock is initialized in ir_lirc_register(), which is called
> > > from rc_register_device(), except when the protocol is CEC:
> > >
> > > /* Ensure that the lirc kfifo is setup before we start the thread */
> > > if (dev->allowed_protocols != RC_PROTO_BIT_CEC) {
> > > rc = ir_lirc_register(dev);
> > > if (rc < 0)
> > > goto out_rx;
> > > }
> > >
> > > So it looks like ir_lirc_scancode_event() fails because dev->lirc_fh_lock was never
> > > initialized.
> > >
> > > Could this be fall-out from the lirc changes you did not too long ago?
> >
> > Yes, this is broken. My bad, sorry. I think this must have been broken since
> > v4.16. I can write a patch but I don't have a patch but I'm on the train
> > to ELCE in Edinburgh now, with no hardware to test on.
> >
> >
> > Sean
> >
>
> the kernel oops have been happening for a while now.
> yesterday when i checked my logs i can see them at least back a couple of
> months when i was running 4.17
>
> also my scripts to poll status of my tv and turn it on/off works for a while
> so it doesn't crash right away.
> maybe it only crashes when i send cec command to turn on/off tv and only
> polling for status is no problem.
>
>
> i think i have a separate issue too because i had problems even before the
> kernel oopses started.
> but i suspect this is caused by my tv locking up the cec bus because
> unplugging power to tv for a few minutes (i must wait or it will still be
> just as broken) and then back used to resolve the cec errors from my
> scripts.
Would you be able to test the following patch please?
Thanks,
Sean
---
>From 1b8b20b606b30c0e301c80e18af8d77194269bc1 Mon Sep 17 00:00:00 2001
From: Sean Young <sean(a)mess.org>
Date: Mon, 22 Oct 2018 10:01:50 +0100
Subject: [PATCH] media: rc: cec devices do not have a lirc chardev
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This fixes an oops in ir_lirc_scancode_event().
BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 9 PID: 27687 Comm: kworker/9:2 Tainted: P OE 4.18.12-200.fc28.x86_64 #1
Hardware name: Supermicro C7X99-OCE-F/C7X99-OCE-F, BIOS 2.1a 06/15/2018
Workqueue: events pulse8_irq_work_handler [pulse8_cec]
RIP: 0010:ir_lirc_scancode_event+0x3d/0xb0 [rc_core]
Code: 8d ae b4 07 00 00 49 81 c6 b8 07 00 00 53 e8 4a df c3 d5 48 89 ef 49 89 45 00 e8 4e 84 41 d6 49 8b 1e 49 89 c4 4c 39 f3 74 58 <8b> 43 38 8b 53 40 89 c1 2b 4b 3c 39 ca 72 41 21 d0 49 8b 7d 00 49
RSP: 0018:ffffaa10e3c07d58 EFLAGS: 00010017
RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000018
RDX: 0000000000000001 RSI: 00316245397fa93c RDI: ffff966d31c8d7b4
RBP: ffff966d31c8d7b4 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000003 R11: ffffaa10e3c07e28 R12: 0000000000000002
R13: ffffaa10e3c07d88 R14: ffff966d31c8d7b8 R15: 0000000000000073
FS: 0000000000000000(0000) GS:ffff966d3f440000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000038 CR3: 00000009d820a003 CR4: 00000000003606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
ir_do_keydown+0x75/0x260 [rc_core]
rc_keydown+0x54/0xc0 [rc_core]
cec_received_msg_ts+0xaa8/0xaf0 [cec]
process_one_work+0x1a1/0x350
worker_thread+0x30/0x380
? pwq_unbound_release_workfn+0xd0/0xd0
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
Modules linked in: rc_tt_1500 dvb_usb_dvbsky dvb_usb_v2 uas usb_storage fuse vhost_net vhost tap xt_CHECKSUM iptable_mangle ip6t_REJECT nf_reject_ipv6 tun 8021q garp mrp xt_nat macvlan xfs devlink ebta
si2157 si2168 cx25840 cx23885 kvm altera_ci tda18271 joydev ir_rc6_decoder rc_rc6_mce crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore altera_stapl m88ds3103 tveeprom cx2341
mxm_wmi igb crc32c_intel megaraid_sas dca i2c_algo_bit wmi vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio i2c_dev
CR2: 0000000000000038
Cc: <stable(a)vger.kernel.org> # v4.16+
Signed-off-by: Sean Young <sean(a)mess.org>
---
drivers/media/rc/rc-main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 552bbe82a160..877978dbd409 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -695,7 +695,8 @@ void rc_repeat(struct rc_dev *dev)
(dev->last_toggle ? LIRC_SCANCODE_FLAG_TOGGLE : 0)
};
- ir_lirc_scancode_event(dev, &sc);
+ if (dev->allowed_protocols != RC_PROTO_BIT_CEC)
+ ir_lirc_scancode_event(dev, &sc);
spin_lock_irqsave(&dev->keylock, flags);
@@ -735,7 +736,8 @@ static void ir_do_keydown(struct rc_dev *dev, enum rc_proto protocol,
.keycode = keycode
};
- ir_lirc_scancode_event(dev, &sc);
+ if (dev->allowed_protocols != RC_PROTO_BIT_CEC)
+ ir_lirc_scancode_event(dev, &sc);
if (new_event && dev->keypressed)
ir_do_keyup(dev, false);
--
2.17.2
Add the missing adjustment of the month range on alarm reads from the
RTC, correcting an issue coming from commit 9c6dfed92c3e ("rtc: m41t80:
add alarm functionality"). The range is 1-12 for hardware and 0-11 for
`struct rtc_time', and is already correctly handled on alarm writes to
the RTC.
It was correct up until commit 48e9766726eb ("drivers/rtc/rtc-m41t80.c:
remove disabled alarm functionality") too, which removed the previous
implementation of alarm support.
Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org>
Fixes: 9c6dfed92c3e ("rtc: m41t80: add alarm functionality")
References: 48e9766726eb ("drivers/rtc/rtc-m41t80.c: remove disabled alarm functionality")
Cc: stable(a)vger.kernel.org # 4.7+
---
Hi,
I have no means to verify this change at run time as my M41T81 device,
which is the reason for me to use this driver, regrettably hasn't got its
IRQ line routed, due to historical reasons I gathered, as it replaced a
different RTC device, that didn't have an IRQ output at all, used with
earlier revisions of the Broadcom SiByte SWARM board I have been using
this code with. However it should be obvious by code inspection.
Please apply and backport as appropriate.
Maciej
---
drivers/rtc/rtc-m41t80.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
linux-rtc-m41t80-read-alarm-month.diff
Index: linux-20181008-swarm64-eb/drivers/rtc/rtc-m41t80.c
===================================================================
--- linux-20181008-swarm64-eb.orig/drivers/rtc/rtc-m41t80.c
+++ linux-20181008-swarm64-eb/drivers/rtc/rtc-m41t80.c
@@ -393,7 +393,7 @@ static int m41t80_read_alarm(struct devi
alrm->time.tm_min = bcd2bin(alarmvals[3] & 0x7f);
alrm->time.tm_hour = bcd2bin(alarmvals[2] & 0x3f);
alrm->time.tm_mday = bcd2bin(alarmvals[1] & 0x3f);
- alrm->time.tm_mon = bcd2bin(alarmvals[0] & 0x3f);
+ alrm->time.tm_mon = bcd2bin(alarmvals[0] & 0x3f) - 1;
alrm->enabled = !!(alarmvals[0] & M41T80_ALMON_AFE);
alrm->pending = (flags & M41T80_FLAGS_AF) && alrm->enabled;
c2856ae2f315d ("blk-mq: quiesce queue before freeing queue") has
already fixed this race, however the implied synchronize_rcu()
in blk_mq_quiesce_queue() can slow down LUN probe a lot, so caused
performance regression.
Then 1311326cf4755c7 ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
tried to only quiesce queue for avoiding unnecessary synchronize_rcu()
in case that queue isn't initialized done.
However, turns out we still need to quiesce the queue in case that
queue isn't initialized done. Because when one SCSI command is
completed, the user is waken up immediately, then the scsi device
can be removed, meantime the run queue in scsi_end_request() can
be still in-progress, so kernel panic is triggered.
In Red Hat QE lab, there are several reports about this kind of kernel
panic triggered during kernel booting.
Fixes: 1311326cf4755c7 ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
Cc: Andrew Jones <drjones(a)redhat.com>
Cc: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: linux-scsi(a)vger.kernel.org
Cc: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: James E.J. Bottomley <jejb(a)linux.vnet.ibm.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
---
block/blk-core.c | 6 +++---
drivers/scsi/scsi_lib.c | 36 ++++++++++++++++++++++++++++++------
2 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index ce12515f9b9b..cf7742a677c4 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -798,9 +798,9 @@ void blk_cleanup_queue(struct request_queue *q)
* dispatch may still be in-progress since we dispatch requests
* from more than one contexts.
*
- * No need to quiesce queue if it isn't initialized yet since
- * blk_freeze_queue() should be enough for cases of passthrough
- * request.
+ * We rely on driver to deal with the race in case that queue
+ * initialization isn't done.
+ *
*/
if (q->mq_ops && blk_queue_init_done(q))
blk_mq_quiesce_queue(q);
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index c7fccbb8f554..7ec7a8a2d000 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -697,13 +697,37 @@ static bool scsi_end_request(struct request *req, blk_status_t error,
*/
scsi_mq_uninit_cmd(cmd);
- __blk_mq_end_request(req, error);
+ /*
+ * When block queue initialization isn't done, the request
+ * queue won't be quiesced in blk_cleanup_queue() for avoiding
+ * slowing down LUN probe, so queue still may be run even though
+ * its resource is cleaned up, this way can cause kernel panic.
+ *
+ * Workaround this issue by freeing request after running the
+ * queue when queue initialization isn't done, so the queue's
+ * usage counter can be held during running queue.
+ *
+ * This way is safe because sdev->device_busy has been decreased
+ * already, and scsi_queue_rq() may guarantee the forward-progress.
+ *
+ */
+ if (blk_queue_init_done(q)) {
+ __blk_mq_end_request(req, error);
+
+ if (scsi_target(sdev)->single_lun ||
+ !list_empty(&sdev->host->starved_list))
+ kblockd_schedule_work(&sdev->requeue_work);
+ else
+ blk_mq_run_hw_queues(q, true);
+ } else {
- if (scsi_target(sdev)->single_lun ||
- !list_empty(&sdev->host->starved_list))
- kblockd_schedule_work(&sdev->requeue_work);
- else
- blk_mq_run_hw_queues(q, true);
+ if (scsi_target(sdev)->single_lun ||
+ !list_empty(&sdev->host->starved_list))
+ kblockd_schedule_work(&sdev->requeue_work);
+ else
+ blk_mq_run_hw_queues(q, true);
+ __blk_mq_end_request(req, error);
+ }
} else {
unsigned long flags;
--
2.9.5
Please pick this commit for all stable branches:
commit e4f3aa2e1e67bb48dfbaaf1cad59013d5a5bc276
Author: Young_X <YangX92(a)hotmail.com>
Date: Wed Oct 3 12:54:29 2018 +0000
cdrom: fix improper type cast, which can leat to information leak.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
drm_atomic_helper_setup_commit() auto-completes commit->flip_done when
state->legacy_cursor_update is true, but we now for sure that we want
a sync update when we call drm_atomic_helper_setup_commit() from
vc4_atomic_commit().
Explicitly set state->legacy_cursor_update to false to prevent this
auto-completion.
Fixes: 184d3cf4f738 ("drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
---
drivers/gpu/drm/vc4/vc4_kms.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 127468785f74..1f94b9affe4b 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -214,6 +214,12 @@ static int vc4_atomic_commit(struct drm_device *dev,
return 0;
}
+ /* We know for sure we don't want an async update here. Set
+ * state->legacy_cursor_update to false to prevent
+ * drm_atomic_helper_setup_commit() from auto-completing
+ * commit->flip_done.
+ */
+ state->legacy_cursor_update = false;
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
--
2.17.1
selinux_sctp_bind_connect() must verify if the address buffer has
sufficient length before accessing the 'sa_family' field. See
__sctp_connect() for a similar check.
The length of the whole address ('len') is already checked in the
callees.
Reported-by: Qian Cai <cai(a)gmx.us>
Fixes: d452930fd3b9 ("selinux: Add SCTP support")
Cc: <stable(a)vger.kernel.org> # 4.17+
Cc: Richard Haines <richard_c_haines(a)btinternet.com>
Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com>
---
Hi,
On Mon, Nov 12, 2018 at 8:39 PM Qian Cai <cai(a)gmx.us> wrote:
> Running the trinity fuzzer on the latest mainline (rc2) generates this,
>
> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> [15029.887294]
> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G W OE 4.20.0-rc2+ #15
> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> [15000.084786] [15029.887320] Call trace:
> [15029.915511] dump_backtrace+0x0/0x2c8
> [15029.920046] show_stack+0x24/0x30
> [15029.923367] dump_stack+0x118/0x19c
> [15029.927539] print_address_description+0x68/0x2a0
> [15029.932245] kasan_report+0x1b4/0x348
> [15029.938760] __asan_load2+0x7c/0xa0
> [15029.945098] selinux_sctp_bind_connect+0x60/0x150
>
> [15029.950571] security_sctp_bind_connect+0x58/0x90
> [15029.955493] __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> [15029.960943] sctp_setsockopt+0x764/0x2928 [sctp]
> [15029.965564] sock_common_setsockopt+0x6c/0x80
> [15029.969923] __arm64_sys_setsockopt+0x13c/0x1f0
> [15029.974456] el0_svc_handler+0xd4/0x198
> [15029.978293] el0_svc+0x8/0xc
> [15029.981174]
> [15029.982667] Allocated by task 18081:
> [15029.986245] kasan_kmalloc.part.1+0x40/0x108
> [15029.990517] kasan_kmalloc+0xb4/0xc8
> [15029.994094] __kmalloc_node+0x1c4/0x638
> [15029.997933] kvmalloc_node+0x98/0xa8
> [15030.001511] vmemdup_user+0x34/0x128
> [15030.005137] __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> [15030.010586] sctp_setsockopt+0x764/0x2928 [sctp]
> [15030.015205] sock_common_setsockopt+0x6c/0x80
> [15030.019564] __arm64_sys_setsockopt+0x13c/0x1f0
> [15030.024096] el0_svc_handler+0xd4/0x198
> [15030.027933] el0_svc+0x8/0xc
> [15030.030814]
> [15030.032306] Freed by task 3025:
> [15030.035451] __kasan_slab_free+0x114/0x228
> [15030.039548] kasan_slab_free+0x10/0x18
> [15030.043299] kfree+0x114/0x408
> [15030.046357] selinux_sk_free_security+0x38/0x48
> [15030.050888] security_sk_free+0x3c/0x58
> [15030.054727] __sk_destruct+0x3e8/0x570
> [15030.058478] sk_destruct+0x4c/0x58
> [15030.061881] __sk_free+0x68/0x138
> [15030.065197] sk_free+0x3c/0x48
> [15030.068255] unix_release_sock+0x4a8/0x550
> [15030.072353] unix_release+0x34/0x50
> [15030.075843] __sock_release+0x74/0x110
> [15030.079593] sock_close+0x24/0x38
> [15030.082913] __fput+0x1b8/0x368
> [15030.086055] ____fput+0x20/0x30
> [15030.089199] task_work_run+0x14c/0x1a8
> [15030.092951] do_notify_resume+0x1e4/0x200
> [15030.096961] work_pending+0x8/0x14
> [15030.100363]
> [15030.101856] The buggy address belongs to the object at ffff801ec53c5080
> [15030.101856] which belongs to the cache kmalloc-128 of size 128
> [15030.114376] The buggy address is located 0 bytes inside of
> [15030.114376] 128-byte region [ffff801ec53c5080, ffff801ec53c5100)
> [15030.125939] The buggy address belongs to the page:
> [15030.130732] page:ffff7fe007b14f00 count:1 mapcount:0 mapping:ffff8016c0010480 index:0x0
> [15030.138738] flags: 0x5fffff0000000200(slab)
> [15030.142926] raw: 5fffff0000000200 ffff7fe007980608 ffff801ec000fd60 ffff8016c0010480
> [15030.150671] raw: 0000000000000000 0000000000660066 00000001ffffffff 0000000000000000
> [15030.158413] page dumped because: kasan: bad access detected
> [15030.163984]
> [15030.165476] Memory state around the buggy address:
> [15030.170269] ffff801ec53c4f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.177491] ffff801ec53c5000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.184714] >ffff801ec53c5080: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.191934] ^
> [15030.195164] ffff801ec53c5100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.202386] ffff801ec53c5180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [15030.209607] ==================================================================
> [15030.216828] Disabling lock debugging due to kernel taint
I think I found the cause - Qian, can you test this patch if it fixes
the problem?
security/selinux/hooks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 7ce683259357..a67459eb62d5 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5318,6 +5318,9 @@ static int selinux_sctp_bind_connect(struct sock *sk, int optname,
addr_buf = address;
while (walk_size < addrlen) {
+ if (walk_size + sizeof(sa_family_t) > addrlen)
+ return -EINVAL;
+
addr = addr_buf;
switch (addr->sa_family) {
case AF_UNSPEC:
--
2.17.2
From: Jonathan Hunter <jonathanh(a)nvidia.com>
The tps6586x driver creates an irqchip that is used by its various child
devices for managing interrupts. The tps6586x-rtc device is one of its
children that uses the tps6586x irqchip. When using the tps6586x-rtc as
a wake-up device from suspend, the following is seen:
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
Disabling non-boot CPUs ...
Entering suspend state LP1
Enabling non-boot CPUs ...
CPU1 is up
tps6586x 3-0034: failed to read interrupt status
tps6586x 3-0034: failed to read interrupt status
The reason why the tps6586x interrupt status cannot be read is because
the tps6586x interrupt is not masked during suspend and when the
tps6586x-rtc interrupt occurs, to wake-up the device, the interrupt is
seen before the i2c controller has been resumed in order to read the
tps6586x interrupt status.
The tps6586x-rtc driver sets it's interrupt as a wake-up source during
suspend, which gets propagated to the parent tps6586x interrupt.
However, the tps6586x-rtc driver cannot disable it's interrupt during
suspend otherwise we would never be woken up and so the tps6586x must
disable it's interrupt instead.
Prevent the tps6586x interrupt handler from executing on exiting suspend
before the i2c controller has been resumed by disabling the tps6586x
interrupt on entering suspend and re-enabling it on resuming from
suspend.
Cc: stable(a)vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com>
Reviewed-by: Dmitry Osipenko <digetx(a)gmail.com>
Tested-by: Dmitry Osipenko <digetx(a)gmail.com>
Acked-by: Thierry Reding <treding(a)nvidia.com>
---
drivers/mfd/tps6586x.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index b89379782741..9c7925ca13cf 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -592,6 +592,29 @@ static int tps6586x_i2c_remove(struct i2c_client *client)
return 0;
}
+static int __maybe_unused tps6586x_i2c_suspend(struct device *dev)
+{
+ struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+ if (tps6586x->client->irq)
+ disable_irq(tps6586x->client->irq);
+
+ return 0;
+}
+
+static int __maybe_unused tps6586x_i2c_resume(struct device *dev)
+{
+ struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+ if (tps6586x->client->irq)
+ enable_irq(tps6586x->client->irq);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(tps6586x_pm_ops, tps6586x_i2c_suspend,
+ tps6586x_i2c_resume);
+
static const struct i2c_device_id tps6586x_id_table[] = {
{ "tps6586x", 0 },
{ },
@@ -602,6 +625,7 @@ static struct i2c_driver tps6586x_driver = {
.driver = {
.name = "tps6586x",
.of_match_table = of_match_ptr(tps6586x_of_match),
+ .pm = &tps6586x_pm_ops,
},
.probe = tps6586x_i2c_probe,
.remove = tps6586x_i2c_remove,
--
2.7.4
From: Jonathan Hunter <jonathanh(a)nvidia.com>
The tps6586x driver creates an irqchip that is used by its various child
devices for managing interrupts. The tps6586x-rtc device is one of its
children that uses the tps6586x irqchip. When using the tps6586x-rtc as
a wake-up device from suspend, the following is seen:
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
Disabling non-boot CPUs ...
Entering suspend state LP1
Enabling non-boot CPUs ...
CPU1 is up
tps6586x 3-0034: failed to read interrupt status
tps6586x 3-0034: failed to read interrupt status
The reason why the tps6586x interrupt status cannot be read is because
the tps6586x interrupt is not masked during suspend and when the
tps6586x-rtc interrupt occurs, to wake-up the device, the interrupt is
seen before the i2c controller has been resumed in order to read the
tps6586x interrupt status.
The tps6586x-rtc driver sets it's interrupt as a wake-up source during
suspend, which gets propagated to the parent tps6586x interrupt.
However, the tps6586x-rtc driver cannot disable it's interrupt during
suspend otherwise we would never be woken up and so the tps6586x must
disable it's interrupt instead.
Prevent the tps6586x interrupt handler from executing on exiting suspend
before the i2c controller has been resumed by disabling the tps6586x
interrupt on entering suspend and re-enabling it on resuming from
suspend.
Cc: stable(a)vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com>
---
drivers/mfd/tps6586x.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index b89379782741..9c7925ca13cf 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -592,6 +592,29 @@ static int tps6586x_i2c_remove(struct i2c_client *client)
return 0;
}
+static int __maybe_unused tps6586x_i2c_suspend(struct device *dev)
+{
+ struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+ if (tps6586x->client->irq)
+ disable_irq(tps6586x->client->irq);
+
+ return 0;
+}
+
+static int __maybe_unused tps6586x_i2c_resume(struct device *dev)
+{
+ struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+ if (tps6586x->client->irq)
+ enable_irq(tps6586x->client->irq);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(tps6586x_pm_ops, tps6586x_i2c_suspend,
+ tps6586x_i2c_resume);
+
static const struct i2c_device_id tps6586x_id_table[] = {
{ "tps6586x", 0 },
{ },
@@ -602,6 +625,7 @@ static struct i2c_driver tps6586x_driver = {
.driver = {
.name = "tps6586x",
.of_match_table = of_match_ptr(tps6586x_of_match),
+ .pm = &tps6586x_pm_ops,
},
.probe = tps6586x_i2c_probe,
.remove = tps6586x_i2c_remove,
--
2.7.4