egukim [Mon, 3 Jul 2017 04:55:37 +0000 (13:55 +0900)]
ARM64: dts: rpi3: Add optee node
Add device node for optee kernel driver. This based on
https://github.com/linaro-swg/linux/commit/
a3d16523b5c3bd3c21e2009f2af0901b0d6d09dd
Change-Id: I9cc6d97354897b4656b02744076efd91889d7630
Signed-off-by: Joakim Bech <joakim.bech@linaro.org>
[egukim: modified commit from linaro-swg/linux of github]
Signed-off-by: Eunggu kim <egukim@dignsys.com>
Junghoon Kim [Tue, 17 Oct 2017 05:43:04 +0000 (14:43 +0900)]
misc: tizen-inform-reboot: resolve sync failure about reboot parameter
Currently, writing reboot paramter into INFORM partition fails
infrequently.
Resolve this issue by calling sync_filesystem function so that it writes
out and waits upon all dirty data associated with this superblock.
Change-Id: Ic62df0c3c4e565ca7211eb85661ead6979f0ad8d
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>
Łukasz Stelmach [Fri, 29 Sep 2017 13:24:05 +0000 (15:24 +0200)]
misc: make sure Tizen notifier is executed before reset
In case of RaspberryPi the CPU is reset by watchdog triggered from
the bcm2835_restart_notifier_call function. Tizen notifier needs higher
priority to be called before the watchdog.
Change-Id: Ia7f6d895f6f40d1a9b4e57ad41b5bdb55c94f4f2
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
kibak.yoon [Fri, 13 Oct 2017 05:20:48 +0000 (14:20 +0900)]
ARM64: tizen_bcmrpi3_defconfig: add i2c-stub to module
We need a test method for the i2c driver and framework on RPI3.
And using a fake device is more convenient than a physical hardware device.
Therefore it would be good to enable i2c-stub for testing i2c feature on RPI3.
This will be used for testing purposes only.
Change-Id: I279bccabf709631130eae7b257bec6275b6acba0
Signed-off-by: kibak.yoon <kibak.yoon@samsung.com>
Inki Dae [Wed, 27 Sep 2017 08:41:16 +0000 (17:41 +0900)]
ARM64: tizen_bcmrpi3_defconfig: support Western european languages
Add Western european language support.
This language support is required for mounting vfat filesystem with default
language set on USB storage.
Change-Id: Ibf479d540a0df8502cae5af0dc242b1cdce3d6c8
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Junghoon Kim [Tue, 22 Aug 2017 04:46:05 +0000 (13:46 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable TIZEN_INFORM_REBOOT with inform path
Reboot parameter passing is required for determining booting mode for
rpi3.
Activate Tizen reboot parameter passing feature with inform file path.
Change-Id: I67a7c24548dda8e8dd860fa25b2f558dadb83cf5
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>
Junghoon Kim [Mon, 21 Aug 2017 02:04:32 +0000 (11:04 +0900)]
misc: add Tizen reboot notifier for passing reboot parameter
To determine booting mode (e.g, fota or recovery) in u-boot side, reboot
parameter should be passed through inform partition.
Add Tizen reboot notifier for passing reboot parameter.
Change-Id: I5830dcf58ec6905b0bc382599aa9ff1251f817d8
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>
Karol Lewandowski [Fri, 8 Sep 2017 10:13:15 +0000 (12:13 +0200)]
ARM64: tizen_bcmrpi3_defconfig: enable uprobes
This functionality is needed for D-Bus Observability Tools
(developed in platform/tools/bcc).
uprobes allows monitoring userspace processes with eBPF
without code modification.
Change-Id: Ic163b72a8315602b89059f36615b88da892aeb0d
KwangCheol Lee [Mon, 11 Sep 2017 05:09:08 +0000 (14:09 +0900)]
Input: rpi_ft5406 - add enable sysfs attribute
Add enable sysfs attribute for disable/enable the touchscreen input.
This feature is required to turn the touch screen display on or off.
Change-Id: I4d5250c32cc2118f0f19a8a3cfb76ea8574f6937
Signed-off-by: KwangCheol Lee <kclee@dignsys.com>
Maciej Slodczyk [Fri, 8 Sep 2017 12:56:42 +0000 (14:56 +0200)]
ARM64: tizen_bcmrpi3_defconfig: enable BPF and KPROBES
Enable BPF and KPROBES config options.
This functionality is needed for D-Bus Observability Tools,
eBPF (http://www.brendangregg.com/ebpf.html).
Change-Id: I2415ca28695e212ee1d02dd1480613cad8a5455c
Signed-off-by: Maciej Slodczyk <m.slodczyk2@partner.samsung.com>
Seung-Woo Kim [Mon, 11 Sep 2017 05:58:06 +0000 (14:58 +0900)]
ARM64: tizen_bcmrpi3_defconfig: synchronize the defconfig with pwm
It synchronizes the defconfig with pwm backlight to fix the commit
d1b5d090a9f8 ("ARM64: tizen_bcmrpi3_defconfig: enable the RPI touchscreen LCD")
because PWM config option added more config options to backlight.
Change-Id: Ie831a2601807a1f9ba729cf64fb98449147ed018
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Hoegeun Kwon [Thu, 7 Sep 2017 07:24:56 +0000 (16:24 +0900)]
drm/vc4: Workaround for crtc scanout device problem
Currently, the crtc device does not start a scanout, the time of
vblank is always calculated as future value. As a workaround, always
change vpos to a positive number.
Change-Id: I02527a0cfbd03d7713fa992d8ee039ffc8e0c5de
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
KwangCheol Lee [Mon, 7 Aug 2017 07:33:36 +0000 (16:33 +0900)]
ARM64: dts: bcm2710-rpi-3-b: add DT support for DRM relevant devices
Add DTs to support the official RPI touchscreen LCD.
Change-Id: Ibf3b17bfe5d1f0bbe55f941018a489899e8ea9ef
Signed-off-by: KwangCheol Lee <kclee@dignsys.com>
Eric Anholt [Thu, 2 Jun 2016 22:09:35 +0000 (15:09 -0700)]
BCM270X: Enable the DSI panel node in the VC4 overlay.
Change-Id: I46fdcdb53b79bd4f0db5022a415f6d1b9faf28e9
Signed-off-by: Eric Anholt <eric@anholt.net>
KwangCheol Lee [Mon, 7 Aug 2017 07:31:00 +0000 (16:31 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable the RPI touchscreen LCD
Enable following configurations for the official RPI touchscreen LCD.
+ TOUCHSCREEN_RPI_FT5406
+ I2C_GPIO
+ DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
+ BACKLIGHT_RPI
Change-Id: I4c11ef34ea87ddeb120a5bc685905dffb5a8654c
Signed-off-by: KwangCheol Lee <kclee@dignsys.com>
Inki Dae [Tue, 5 Sep 2017 03:09:36 +0000 (12:09 +0900)]
ARM: dts: bcm2710-rpi-3-b: enable spi0 device node
Enable spi0 device node.
This patch is required to create spidev node which is used
by user space to control spi.
Change-Id: I8dec8288f6b35f628b178e0056d664b96f18ac4b
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Seung-Woo Kim [Wed, 30 Aug 2017 02:59:40 +0000 (11:59 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable SQUASHFS
To support compressed readonly image from Tizen, squashfs will be
used. Enable SQUASHFS and realted configuration. For better
performance, also SQUASHFS_DECOMP_MULTI_PERCPU and
SQUASHFS_4K_DEVBLK_SIZE options are set.
Change-Id: I8d7fb37f8b2bbe102fedc6c9d7d9c4c242d6ec32
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Tue, 29 Aug 2017 05:56:16 +0000 (14:56 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable SMACK_NETFILTER
On Tizen, nether service is failed because security smack netfilter
related configs are not enabled. So, enable related configs
including CONFIG_NETWORK_SECMARK, and CONFIG_SECURITY_SMACK_NETFILTER
and others.
Change-Id: Ia886ba9d5dd9bc559633acf3066818e57551f8f4
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Lee Hackseung [Thu, 10 Aug 2017 06:48:39 +0000 (15:48 +0900)]
ARM: dts: bcm2710-rpi-3-b : Change audio node status as "okay"
Start.elf uses dt overlay concept, so each node status can be
overlayed with dtparam=audio=on in config.txt but u-boot does not.
So, change status of on-board audio dt node as "okay" because dt
overlay concept on u-boot requires too huge effort.
Fixing dts file from arm will also change arm64 because arm64 dts
includes arm dts.
Change-Id: I73b3c807968c031ba046f44e937c6828ee7f0119
Signed-off-by: Hackseung Lee <lhs@dignsys.com>
[jcsing.lee@samsung.com: modify commit message more clearly]
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Lee Hackseung [Thu, 10 Aug 2017 05:50:09 +0000 (14:50 +0900)]
arm64: bcmrpi3_defconfig: Enable features related to bcm sound
Enable SND_BCM2835 that has essential functionalities to
play and capture sounds and enable configurations related to PWM
because earjack works through PWM devices.
Change-Id: I04f7ea23b9bdd447a7f8084d8ce5c6f73ebd9992
Signed-off-by: Hackseung Lee <lhs@dignsys.com>
[jcsing.lee@samsung.com: modify commit message more clearly]
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Karol Lewandowski [Wed, 12 Jul 2017 09:54:23 +0000 (11:54 +0200)]
ARM64: tizen_bcmrpi3_defconfig: enable android logger
To support logger driver backend from Tizen dlog framework, enable
android logger.
Change-Id: I24960463efc40637858c0873ac7400fa0e806650
Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Inki Dae [Mon, 4 Jul 2016 08:28:46 +0000 (17:28 +0900)]
staging: logger: fix build error due to removed ki_nbytes
This patch fixes build error. Logger driver was removed
from mainline kernel and after that there was some changes and
one of them is that ki_nbytes member was removed from kiocb structure.
66ee59a fs: remove ki_nbytes
This patch makes count member of iov_iter structure to be used instead.
Change-Id: I11e9ebdac7dd86c02fd692a67562a23e5c685f69
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Jaehoon Chung [Fri, 5 Jan 2018 00:40:02 +0000 (09:40 +0900)]
staging: android: logger: fix the compiler error
Moved signal wakeup & sigpending methods from <linux/sched.h> into
<linux/sched/signal.h>.
Refer to commit
174cd4b1e5fb (sched/headers: Prepare to move signal
wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>
Fix the compiler error about android logger.
Change-Id: Iab1583fe54fef1c76a34673d1d718f73930baa11
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Karol Lewandowski [Mon, 3 Jul 2017 12:01:57 +0000 (14:01 +0200)]
Revert "staging: Remove logger and alarm-dev from android Makefile"
This reverts commit
71e365ed0ca893cae8d72cbd4b476a9589003098.
Change-Id: I190dabd2626ca7cb51d00d9fe186d15da21ae405
Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Karol Lewandowski [Mon, 3 Jul 2017 12:00:55 +0000 (14:00 +0200)]
Revert "staging: Remove the Android logger driver"
This reverts commit
a0a23bbce7818c90c3d3370af966fefce07a8c9b.
rpi3 is going to be used for various profiles - among these
there will be IoT and Headless, which still depend on legacy
android logger driver for application logging.
This commit reverts removal of the driver.
Change-Id: I61ab9e87c5bcbf318aa35ec2f92a470b54a98be1
Requested-by: Hyotaek Shim <hyotaek.shim@samsung.com>
Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Jaehoon Chung [Tue, 22 Aug 2017 03:00:20 +0000 (12:00 +0900)]
ARM64: tizen_bcmrpi3_defconfig: update the defconfig for synchronization
It updates the defconfig for synchronization.
Change-Id: I2f1b2aa7cdcc82c0df0407cde155569884181471
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Lee Hackseung [Mon, 10 Jul 2017 10:36:22 +0000 (19:36 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable BLUETOOTH
Activate Bluetooth related settings.
Change-Id: I6c9496341698aadc66934ab93a3b54d2f82894ad
Signed-off-by: Hackseung Lee <lhs@dignsys.com>
Lee Hackseung [Fri, 11 Aug 2017 06:17:38 +0000 (15:17 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable UVC
Activate all settings related to UVC(USB Video Class)
Change-Id: I6d5d3d388d06fc4b5ae9510db63f4398f8fe84fe
Signed-off-by: Hackseung Lee <lhs@dignsys.com>
Jaechul Lee [Fri, 28 Jul 2017 07:48:32 +0000 (16:48 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable USB audio driver
Activate ALSA USB related settings.
Change-Id: I03d6c9cd9eb6e55667f7bd92717b6beeb304aa1b
Signed-off-by: Hackseung Lee <lhs@dignsys.com>
[jcsing.lee: adjust commit message]
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Joonyoung Shim [Wed, 26 Jul 2017 05:27:19 +0000 (14:27 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable GPIO_BCM_EXP
VC4 DRM hdmi uses HPD gpio controlled by Broadcom expander GPIO driver,
so enable GPIO_BCM_EXP config.
Change-Id: I1457a0d2d9d071363eb2f43225a308eeeaaa3353
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Andi Shyti [Tue, 25 Jul 2017 01:55:38 +0000 (10:55 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable INPUT_EVDEV
Tizen needs the dev/input/eventX to interface for with the mouse,
INPUT_EVDEV enables it.
Change-Id: I3a9566a10b8764fe5af21fc6b1361cf9e8040a23
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Hyeongsik Min [Tue, 11 Jul 2017 11:24:27 +0000 (20:24 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable SPI_BCM2835
Enables support of BCM2835 SPI driver needed by peripheral-io.
Change-Id: Ibf2aaca64462e4046ba155d11783f19f912ef8c3
Signed-off-by: Hyeongsik Min <hyeongsik.min@samsung.com>
Jaehoon Chung [Mon, 27 Mar 2017 07:54:15 +0000 (16:54 +0900)]
ARM64: tizen_bcmrpi3_defconfig: increase the ramdisk size to 12MB
Increase the ramdisk size from 4MB to 12MB. Tizen normal ramdisk
size should be under 8MB and the size of ramdisk-recovery should
be 12MB.
Change-Id: I474a32f8fb1233d36b837806dde54e376a0cafdd
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
[sw0312.kim: squash change size for 8MB and 12MB]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Karol Lewandowski [Thu, 1 Jun 2017 12:17:37 +0000 (14:17 +0200)]
ARM64: tizen_bcmrpi3_defcofig: enable audit subsystem
Syscall auditing is going to be used by fault detection service - faultd.
Change-Id: Ifc6853e12fcc90497bd8a222eecb44fdd09f57ba
Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Jaehoon Chung [Mon, 22 May 2017 23:53:49 +0000 (08:53 +0900)]
ARM64: tizen_bcmrpi3_defcofig: enable the configs relevant to bridge
Enable the configs relevant to BRIDGE and STP.
Change-Id: Iabb67ec49d176ff5fe6083dfc4a48ed40d683d1a
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Fri, 19 May 2017 03:37:59 +0000 (12:37 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable the MAC80211 and RT2X00 configs
To use Ralink driver, enable the configurations relevant to it.
Change-Id: I5122405b297caf1f6f1e56d02a524d504671d910
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Wed, 17 May 2017 05:41:08 +0000 (14:41 +0900)]
ARM64: tizen_bcmrpi3_defconfig: Enable USB_SERIAL configurations
Enable USB_SERIAL configurations.
(CONFIG_SERIAL, CONFIG_SERIAL_GENERIC, CONFIG_SERIAL_CP210X)
Change-Id: Icead3fc34b2e37889a1dd407c24aff1444a5ab20
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Joonyoung Shim [Thu, 23 Mar 2017 06:11:01 +0000 (15:11 +0900)]
drm/vc4: add gem_info node via debugfs
The memps requires gem_info with gem_names to analyze graphics
shared memory, so this patch adds gem_info node via debugfs
interface.
Let's save pid/tgid in private file data only once when gem object is
created or prime_fd is imported and use them on gem_info. This is to
solve the wrong pid problem of gem_info created as different processes
share fd of drm device node.
Change-Id: Iaac2ccd63e124dd11a894f0e88ddbb533750f3d4
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
[sw0312.kim: fix wrong printing format in gem_info debugfs for 32bit arm build with %zx]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Andi Shyti [Fri, 31 Mar 2017 06:23:47 +0000 (15:23 +0900)]
ARM64: tizen_bcmrpi3_defconfig: enable I2C_CHARDEV
The I2C_CHARDEV flag enables the compilation of the i2c-dev
driver which generates a character device of the type /dev/i2c-X
where userspace programs can access to the i2c devices without
the support of any device drivers.
Change-Id: I661d8590bc219c6500bb5fca89df0436aa0efdca
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Andi Shyti [Fri, 31 Mar 2017 06:20:27 +0000 (15:20 +0900)]
ARM64: dts: bcm2710-rpi-3-b: enable i2c1
i2c bus number 1 is mapped in the Raspberry Pi gpio array for
connecting through i2c external devices.
Change-Id: Ia8f72952f4aed1d737ab75c239ead25bb97d2e3c
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Jaehoon Chung [Tue, 7 Feb 2017 07:50:54 +0000 (16:50 +0900)]
ARM64: rpi3: config: enable configurations relevant to WiFi
Enable configurations relevant to WiFi.
These configurations are basic configs for using Network.
If needs to enable more configuration, it should be enabled in future.
To use WiFi, enable the brcmfmac driver as modules.
(Needs to install modules in target.)
Change-Id: Ia9961018f6736e3bc709c0d760f0d2d02994c7c8
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Joonyoung Shim [Tue, 7 Feb 2017 05:01:04 +0000 (14:01 +0900)]
ARM64: tizen_bcmrpi3_defconfig: Disable FB_BCM2708
Disable FB driver because of using DRM driver.
Change-Id: I3bfb899c1e0c71a235952934ecaf749a1d90dd85
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Joonyoung Shim [Mon, 6 Feb 2017 06:55:03 +0000 (15:55 +0900)]
ARM64: tizen_bcmrpi3_defconfig: increase CMA size to 256MiB
CMA size 5MiB or 64MiB are insufficient in tizen platform.
Change-Id: I83fa78d12af93361a87f0819b7b7abcd5b23fb2e
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Joonyoung Shim [Tue, 7 Feb 2017 04:58:35 +0000 (13:58 +0900)]
ARM64: tizen_bcmrpi3_defconfig: Enable I2C_BCM2835
It needs to enable I2C_BCM2835 to bind HDMI from drm driver.
Change-Id: Ifcfbcb7bd3ac5a76c2cbbb1acdec45a48bee0201
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Joonyoung Shim [Tue, 7 Feb 2017 04:57:30 +0000 (13:57 +0900)]
ARM64: tizen_bcmrpi3_defconfig: Enable DRM_VC4
Enable DRM_VC4 driver for tizen platform.
v2: DRM_VC4 need also to enable SND and SND_SOC configs.
Change-Id: I85568d78710d81ffa4cb1ec6373647e31962d1fe
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Hoegeun Kwon [Thu, 19 Jan 2017 04:49:54 +0000 (13:49 +0900)]
arm: dts: Add support for drm vc4 on RPI3
Fixed the DT status to operate drm vc4.
Change-Id: I06aa84303e1a7c10647ace3799ec09d08ca045eb
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Seung-Woo Kim [Tue, 12 Sep 2017 05:55:31 +0000 (14:55 +0900)]
scripts: mkbootimg_rpi3.sh: Add u-boot and optee binaries to boot.img
In boot.img for tizen rpi3 image, u-boot and optee atf binaries
are required, so the files should be also installed in boot.img.
Add u-boot.img with optee os for atf and u-boot received from
download.tizen.org to boot.img.
Change-Id: I9778ea5c72697c3e7d0a534627fc65841bb792a1
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Joonyoung Shim [Thu, 9 Feb 2017 06:40:12 +0000 (15:40 +0900)]
scripts: mkbootimg_rpi3.sh: Add ARM64 kernel/dtb binary to boot.img
Add script to create boot.img having boot related files with fat
file system.
Change-Id: I7a03c11ef155dd3ad5fc935511ae764ef699c145
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
[sw0312.kim: remove not required kernel.img and add sync command before umount]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Joonyoung Shim [Tue, 31 Jan 2017 07:16:38 +0000 (16:16 +0900)]
scripts: Add mkbootimg_rpi3.sh
This script is to make boot.img that is fused at boot partition.
Change-Id: I383fc8dee8460176c825e4ea360d37d62072e6d6
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Joonyoung Shim [Wed, 25 Jan 2017 04:50:37 +0000 (13:50 +0900)]
tools: Add build script for ARM64 kernel of rpi3
This patch adds build script to build the ARM64 kernel for rpi3 board.
v2: Remove codes for creating fit style image from its
Change-Id: Ie7fa6dbf0b6838832b6a05326fa0ca27e3a7a812
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Jaechul Lee [Mon, 30 Jan 2017 23:58:22 +0000 (08:58 +0900)]
packaging: Added '.gbs.conf' for partial build
Added gbs configuration file for enhanced building.
it makes gbs build faster than before.
https://source.tizen.org/documentation/reference/git-build-system/maintenance-models-supported-gbs
Change-Id: I79d57aa5eb49d0fbfa9a3744ec2acb032a274e5e
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Denis Khalikov [Fri, 25 Aug 2017 13:11:14 +0000 (16:11 +0300)]
packaging: Disable UBSan build
UBSan build on kernel will cause build error because kernel has its own
sanitizer build options. So, dislable UBSan build from packaging spec.
Change-Id: Ife910a1e666c6fcafb7ef7bfcc072d88d8549d77
Signed-off-by: Denis Khalikov <d.khalikov@partner.samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Gonzha Dmitriy Evgenevich [Wed, 24 May 2017 10:51:05 +0000 (13:51 +0300)]
packaging: Turn off building with ASan
Turn off ASan for ASan sanitized firmware build
Change-Id: If786306821ff22e994efaba2b00dcabcc5eb8426
Signed-off-by: Gonzha Dmitriy Evgenevich <d.gonzha@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Alexander Aksenov [Thu, 27 Jul 2017 12:53:34 +0000 (15:53 +0300)]
packaging: Add kernel devel package
Kernel devel is used now to build out-of-tree kernel modules
Change-Id: I753edba92042561b50dc6c645f23659a65568976
Signed-off-by: Alexander Aksenov <a.aksenov@samsung.com>
Joonyoung Shim [Tue, 24 Jan 2017 04:19:59 +0000 (13:19 +0900)]
packaging: Add spec file for rpi
This adds linux-rpi3.spec file for ARM64/armv7l rpm packaging.
Change-Id: I428fd32b69d082d935159476ace30c59c14b570d
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
[jh80.chung, sw0312.kim: Update kernel version to v4.14.y in spec file]
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
[sw0312.kim: Rename spec file without arch name]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Joonyoung Shim [Tue, 7 Feb 2017 04:26:20 +0000 (13:26 +0900)]
ARM64: tizen_bcmrpi3_defconfig: Enable SMACK
It needs to enable configs related with SMACK for booting tizen
platform.
Change-Id: If58917b798c1bee0c16cd5e430a065e40852b97b
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Joonyoung Shim [Tue, 7 Feb 2017 04:25:14 +0000 (13:25 +0900)]
ARM64: tizen_bcmrpi3_defconfig: Sync with .config
Change-Id: I4e11df92a40b5f4c48891a6e772d898ff58de6e8
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Hackseung Lee [Wed, 6 Dec 2017 08:33:44 +0000 (17:33 +0900)]
rpi3: config: Enable camera
Add configration to enable the Raspberry Pi Camera Module in config.txt file.
Change-Id: I092851a559ebab462babf8c176a190339285ef9d
Signed-off-by: Hackseung Lee <lhs@dignsys.com>
Seung-Woo Kim [Thu, 26 Oct 2017 03:55:05 +0000 (12:55 +0900)]
rpi3: enable jtag gpio option
Enable jtag gpio option at 1st bootloader level. The option
enables jtag gpio as alt4 mode as like following:
GPIO22 - PIN13 - TRST
GPIO23 - PIN16 - RTCK
GPIO24 - PIN18 - TDO
GPIO25 - PIN22 - TCK
GPIO26 - PIN37 - TDI
GPIO27 - PIN07 - TMS
This is requested for debugging secure world with jtag.
Change-Id: I0e25dd9ecf95fa003e56eb73eae5a668a1f6e3ba
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
r.tyminski [Fri, 6 Oct 2017 15:39:37 +0000 (17:39 +0200)]
rpi3: Enable ARM atf boot for rpi3
Boot rpi3 with u-boot-spl.bin which enables ARM atf.
Other booting options are set as like:
https://github.com/OP-TEE/build/blob/master/rpi3/firmware/config.txt
Change-Id: I0c0559c3f72f252c2cd2716b746b3c49b04fd63e
Signed-off-by: Rafal Tyminski <r.tyminski@partner.samsung.com>
[sw0312.kim: add more options and adjust commit-msg]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Łukasz Stelmach [Fri, 29 Sep 2017 13:51:08 +0000 (15:51 +0200)]
rpi3: enable uart in bootcode.bin
The uart_2ndstage option directs bootcode.bin to print some diagnostics,
that indicate the code is running.
Change-Id: I34a68ae3b5c2467ee58fd81adf687ce367e1ed1c
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Jaehoon Chung [Wed, 12 Jul 2017 04:22:47 +0000 (13:22 +0900)]
rpi3: config: change the 'kernel' parameter from Image to u-boot.bin
It needs to use the u-boot for supporting ramdisk booting.
Current release image is including the u-boot.bin that modified the ramdisk
booting sequence.
Change the kernel parameter from "Image" to "u-boot.bin" in config.txt.
Change-Id: Icc4ddce7e9f9befba59240d02ddd9af111c92a40
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Hyeongsik Min [Tue, 11 Jul 2017 11:55:13 +0000 (20:55 +0900)]
rpi3: config: Enable SPI interface
Uncomment spi=on in config.txt file to enable SPI interface.
Change-Id: I595628838fe9d769b243948e7118d36f4647e490
Signed-off-by: Hyeongsik Min <hyeongsik.min@samsung.com>
Joonyoung Shim [Tue, 31 Jan 2017 01:57:34 +0000 (10:57 +0900)]
rpi3: config: Add loading of arm64 kernel binary & dtb
Change-Id: Ib553d02595e357751d0080d6aa713efe1ce9515d
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Joonyoung Shim [Wed, 25 Jan 2017 07:57:30 +0000 (16:57 +0900)]
rpi3: config: Add boot mode to select ARM or ARM64
Add configration to select boot mode in config.txt file, then we can
determine booting in 32-bit mode or 64-bit mode.
Change-Id: I2a5a1b11c4c83f514a7e8cc4c2f077b0b1d02cdc
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Joonyoung Shim [Wed, 25 Jan 2017 06:58:47 +0000 (15:58 +0900)]
rpi3: config: Enable serial
Add configration to enable serial in config.txt file, then we can serial
log from kernel or u-boot during booting.
Change-Id: Iebe3345b52cb2886daa0d8bdf1e15747dde2af39
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Joonyoung Shim [Wed, 25 Jan 2017 09:41:38 +0000 (18:41 +0900)]
rpi3: Add config.txt extracted from raspbian lite binary
We can get raspbian lite binary from
https://downloads.raspberrypi.org/raspbian_lite_latest
This file that is necessary for booting was extracted from first
partition of 2017-07-05-raspbian-jessie-lite.img.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Joonyoung Shim [Wed, 26 Jul 2017 00:07:51 +0000 (09:07 +0900)]
rpi3: Add boot files from github
We can get boot binaries that are necessary for booting from master
branch of https://github.com/raspberrypi/firmware.
The git base is the commit
83977fe3b6ef ("kernel: Bump to 4.14.98").
LICENCE.broadcom
bootcode.bin
fixup*.dat
start*.elf
TYPES of each firmware:
start.elf / fixup.dat - normal
start_x.elf / fixup_x.dat - with extra feature including camera (start_x=1 in config.txt)
start_cd.elf / fixup_cd.dat - cut-down to minimum gpu set 16M
start_db.elf / fixup_db.dat - debug (start_debug=1 in config.txt)
NOTE:
start_x=1 in config.txt should be specified when using the camera
module and it implies start_file=start_x.elf/fixup_file=fixup_x.dat.
Change-Id: I827b4cb94b3f8baa805938cd9f44947be7865f0e
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
[lhs: Add firmware files for camera]
Signed-off-by: Hackseung Lee <lhs@dignsys.com>
[sw0312.kim: update firmware files including extra, cutdown and debug features]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
popcornmix [Fri, 1 Nov 2019 13:52:14 +0000 (13:52 +0000)]
Merge remote-tracking branch 'stable/linux-4.19.y' into rpi-4.19.y
Serge Schneider [Thu, 31 Oct 2019 13:37:16 +0000 (13:37 +0000)]
rpi-poe-fan: fix def_pwm1 writes
Signed-off-by: Serge Schneider <serge@raspberrypi.org>
Greg Kroah-Hartman [Tue, 29 Oct 2019 08:20:09 +0000 (09:20 +0100)]
Linux 4.19.81
Greg KH [Tue, 1 Oct 2019 16:56:11 +0000 (18:56 +0200)]
RDMA/cxgb4: Do not dma memory off of the stack
commit
3840c5b78803b2b6cc1ff820100a74a092c40cbb upstream.
Nicolas pointed out that the cxgb4 driver is doing dma off of the stack,
which is generally considered a very bad thing. On some architectures it
could be a security problem, but odds are none of them actually run this
driver, so it's just a "normal" bug.
Resolve this by allocating the memory for a message off of the heap
instead of the stack. kmalloc() always will give us a proper memory
location that DMA will work correctly from.
Link: https://lore.kernel.org/r/20191001165611.GA3542072@kroah.com
Reported-by: Nicolas Waisman <nico@semmle.com>
Tested-by: Potnuri Bharat Teja <bharat@chelsio.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Tue, 15 Oct 2019 15:49:27 +0000 (08:49 -0700)]
blk-rq-qos: fix first node deletion of rq_qos_del()
commit
307f4065b9d7c1e887e8bdfb2487e4638559fea1 upstream.
rq_qos_del() incorrectly assigns the node being deleted to the head if
it was the first on the list in the !prev path. Fix it by iterating
with ** instead.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Josef Bacik <josef@toxicpanda.com>
Fixes:
a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt")
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Mon, 14 Oct 2019 11:25:00 +0000 (13:25 +0200)]
PCI: PM: Fix pci_power_up()
commit
45144d42f299455911cc29366656c7324a3a7c97 upstream.
There is an arbitrary difference between the system resume and
runtime resume code paths for PCI devices regarding the delay to
apply when switching the devices from D3cold to D0.
Namely, pci_restore_standard_config() used in the runtime resume
code path calls pci_set_power_state() which in turn invokes
__pci_start_power_transition() to power up the device through the
platform firmware and that function applies the transition delay
(as per PCI Express Base Specification Revision 2.0, Section 6.6.1).
However, pci_pm_default_resume_early() used in the system resume
code path calls pci_power_up() which doesn't apply the delay at
all and that causes issues to occur during resume from
suspend-to-idle on some systems where the delay is required.
Since there is no reason for that difference to exist, modify
pci_power_up() to follow pci_set_power_state() more closely and
invoke __pci_start_power_transition() from there to call the
platform firmware to power up the device (in case that's necessary).
Fixes:
db288c9c5f9d ("PCI / PM: restore the original behavior of pci_set_power_state()")
Reported-by: Daniel Drake <drake@endlessm.com>
Tested-by: Daniel Drake <drake@endlessm.com>
Link: https://lore.kernel.org/linux-pm/CAD8Lp44TYxrMgPLkHCqF9hv6smEurMXvmmvmtyFhZ6Q4SE+dig@mail.gmail.com/T/#m21be74af263c6a34f36e0fc5c77c5449d9406925
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Juergen Gross [Fri, 18 Oct 2019 07:45:49 +0000 (09:45 +0200)]
xen/netback: fix error path of xenvif_connect_data()
commit
3d5c1a037d37392a6859afbde49be5ba6a70a6b3 upstream.
xenvif_connect_data() calls module_put() in case of error. This is
wrong as there is no related module_get().
Remove the superfluous module_put().
Fixes:
279f438e36c0a7 ("xen-netback: Don't destroy the netdev until the vif is shut down")
Cc: <stable@vger.kernel.org> # 3.12
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Tue, 8 Oct 2019 23:29:10 +0000 (01:29 +0200)]
cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown
commit
65650b35133ff20f0c9ef0abd5c3c66dbce3ae57 upstream.
It is incorrect to set the cpufreq syscore shutdown callback pointer
to cpufreq_suspend(), because that function cannot be run in the
syscore stage of system shutdown for two reasons: (a) it may attempt
to carry out actions depending on devices that have already been shut
down at that point and (b) the RCU synchronization carried out by it
may not be able to make progress then.
The latter issue has been present since commit
45975c7d21a1 ("rcu:
Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds"),
but the former one has been there since commit
90de2a4aa9f3 ("cpufreq:
suspend cpufreq governors on shutdown") regardless.
Fix that by dropping cpufreq_syscore_ops altogether and making
device_shutdown() call cpufreq_suspend() directly before shutting
down devices, which is along the lines of what system-wide power
management does.
Fixes:
45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds")
Fixes:
90de2a4aa9f3 ("cpufreq: suspend cpufreq governors on shutdown")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Sat, 5 Oct 2019 11:21:01 +0000 (13:21 +0200)]
memstick: jmb38x_ms: Fix an error handling path in 'jmb38x_ms_probe()'
commit
28c9fac09ab0147158db0baeec630407a5e9b892 upstream.
If 'jmb38x_ms_count_slots()' returns 0, we must undo the previous
'pci_request_regions()' call.
Goto 'err_out_int' to fix it.
Fixes:
60fdd931d577 ("memstick: add support for JMicron jmb38x MemoryStick host controller")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qu Wenruo [Thu, 17 Oct 2019 02:38:37 +0000 (10:38 +0800)]
btrfs: tracepoints: Fix bad entry members of qgroup events
commit
1b2442b4ae0f234daeadd90e153b466332c466d8 upstream.
[BUG]
For btrfs:qgroup_meta_reserve event, the trace event can output garbage:
qgroup_meta_reserve:
9c7f6acc-b342-4037-bc47-
7f6e4d2232d7: refroot=5(FS_TREE) type=DATA diff=2
qgroup_meta_reserve:
9c7f6acc-b342-4037-bc47-
7f6e4d2232d7: refroot=5(FS_TREE) type=0x258792 diff=2
The @type can be completely garbage, as DATA type is not possible for
trace_qgroup_meta_reserve() trace event.
[CAUSE]
Ther are several problems related to qgroup trace events:
- Unassigned entry member
Member entry::type of trace_qgroup_update_reserve() and
trace_qgourp_meta_reserve() is not assigned
- Redundant entry member
Member entry::type is completely useless in
trace_qgroup_meta_convert()
Fixes:
4ee0d8832c2e ("btrfs: qgroup: Update trace events for metadata reservation")
CC: stable@vger.kernel.org # 4.10+
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Filipe Manana [Wed, 16 Oct 2019 15:28:52 +0000 (16:28 +0100)]
Btrfs: check for the full sync flag while holding the inode lock during fsync
commit
ba0b084ac309283db6e329785c1dc4f45fdbd379 upstream.
We were checking for the full fsync flag in the inode before locking the
inode, which is racy, since at that that time it might not be set but
after we acquire the inode lock some other task set it. One case where
this can happen is on a system low on memory and some concurrent task
failed to allocate an extent map and therefore set the full sync flag on
the inode, to force the next fsync to work in full mode.
A consequence of missing the full fsync flag set is hitting the problems
fixed by commit
0c713cbab620 ("Btrfs: fix race between ranged fsync and
writeback of adjacent ranges"), BUG_ON() when dropping extents from a log
tree, hitting assertion failures at tree-log.c:copy_items() or all sorts
of weird inconsistencies after replaying a log due to file extents items
representing ranges that overlap.
So just move the check such that it's done after locking the inode and
before starting writeback again.
Fixes:
0c713cbab620 ("Btrfs: fix race between ranged fsync and writeback of adjacent ranges")
CC: stable@vger.kernel.org # 5.2+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Filipe Manana [Wed, 9 Oct 2019 16:43:45 +0000 (17:43 +0100)]
Btrfs: add missing extents release on file extent cluster relocation error
commit
44db1216efe37bf670f8d1019cdc41658d84baf5 upstream.
If we error out when finding a page at relocate_file_extent_cluster(), we
need to release the outstanding extents counter on the relocation inode,
set by the previous call to btrfs_delalloc_reserve_metadata(), otherwise
the inode's block reserve size can never decrease to zero and metadata
space is leaked. Therefore add a call to btrfs_delalloc_release_extents()
in case we can't find the target page.
Fixes:
8b62f87bad9c ("Btrfs: rework outstanding_extents")
CC: stable@vger.kernel.org # 4.19+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qu Wenruo [Thu, 10 Oct 2019 02:39:26 +0000 (10:39 +0800)]
btrfs: block-group: Fix a memory leak due to missing btrfs_put_block_group()
commit
4b654acdae850f48b8250b9a578a4eaa518c7a6f upstream.
In btrfs_read_block_groups(), if we have an invalid block group which
has mixed type (DATA|METADATA) while the fs doesn't have MIXED_GROUPS
feature, we error out without freeing the block group cache.
This patch will add the missing btrfs_put_block_group() to prevent
memory leak.
Note for stable backports: the file to patch in versions <= 5.3 is
fs/btrfs/extent-tree.c
Fixes:
49303381f19a ("Btrfs: bail out if block group has different mixed flag")
CC: stable@vger.kernel.org # 4.9+
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patrick Williams [Tue, 1 Oct 2019 15:51:38 +0000 (10:51 -0500)]
pinctrl: armada-37xx: swap polarity on LED group
commit
b835d6953009dc350d61402a854b5a7178d8c615 upstream.
The configuration registers for the LED group have inverted
polarity, which puts the GPIO into open-drain state when used in
GPIO mode. Switch to '0' for GPIO and '1' for LED modes.
Fixes:
87466ccd9401 ("pinctrl: armada-37xx: Add pin controller support for Armada 37xx")
Signed-off-by: Patrick Williams <alpawi@amazon.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191001155154.99710-1-alpawi@amazon.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patrick Williams [Tue, 1 Oct 2019 15:46:31 +0000 (10:46 -0500)]
pinctrl: armada-37xx: fix control of pins 32 and up
commit
20504fa1d2ffd5d03cdd9dc9c9dd4ed4579b97ef upstream.
The 37xx configuration registers are only 32 bits long, so
pins 32-35 spill over into the next register. The calculation
for the register address was done, but the bitmask was not, so
any configuration to pin 32 or above resulted in a bitmask that
overflowed and performed no action.
Fix the register / offset calculation to also adjust the offset.
Fixes:
5715092a458c ("pinctrl: armada-37xx: Add gpio support")
Signed-off-by: Patrick Williams <alpawi@amazon.com>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191001154634.96165-1-alpawi@amazon.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Torokhov [Tue, 24 Sep 2019 02:49:58 +0000 (19:49 -0700)]
pinctrl: cherryview: restore Strago DMI workaround for all versions
commit
260996c30f4f3a732f45045e3e0efe27017615e4 upstream.
This is essentially a revert of:
e3f72b749da2 pinctrl: cherryview: fix Strago DMI workaround
86c5dd6860a6 pinctrl: cherryview: limit Strago DMI workarounds to version 1.0
because even with 1.1 versions of BIOS there are some pins that are
configured as interrupts but not claimed by any driver, and they
sometimes fire up and result in interrupt storms that cause touchpad
stop functioning and other issues.
Given that we are unlikely to qualify another firmware version for a
while it is better to keep the workaround active on all Strago boards.
Reported-by: Alex Levin <levinale@chromium.org>
Fixes:
86c5dd6860a6 ("pinctrl: cherryview: limit Strago DMI workarounds to version 1.0")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Alex Levin <levinale@chromium.org>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Christopherson [Tue, 1 Oct 2019 20:50:19 +0000 (13:50 -0700)]
x86/apic/x2apic: Fix a NULL pointer deref when handling a dying cpu
commit
7a22e03b0c02988e91003c505b34d752a51de344 upstream.
Check that the per-cpu cluster mask pointer has been set prior to
clearing a dying cpu's bit. The per-cpu pointer is not set until the
target cpu reaches smp_callin() during CPUHP_BRINGUP_CPU, whereas the
teardown function, x2apic_dead_cpu(), is associated with the earlier
CPUHP_X2APIC_PREPARE. If an error occurs before the cpu is awakened,
e.g. if do_boot_cpu() itself fails, x2apic_dead_cpu() will dereference
the NULL pointer and cause a panic.
smpboot: do_boot_cpu failed(-22) to wakeup CPU#1
BUG: kernel NULL pointer dereference, address:
0000000000000008
RIP: 0010:x2apic_dead_cpu+0x1a/0x30
Call Trace:
cpuhp_invoke_callback+0x9a/0x580
_cpu_up+0x10d/0x140
do_cpu_up+0x69/0xb0
smp_init+0x63/0xa9
kernel_init_freeable+0xd7/0x229
? rest_init+0xa0/0xa0
kernel_init+0xa/0x100
ret_from_fork+0x35/0x40
Fixes:
023a611748fd5 ("x86/apic/x2apic: Simplify cluster management")
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20191001205019.5789-1-sean.j.christopherson@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve Wahl [Tue, 24 Sep 2019 21:03:55 +0000 (16:03 -0500)]
x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area
commit
2aa85f246c181b1fa89f27e8e20c5636426be624 upstream.
Our hardware (UV aka Superdome Flex) has address ranges marked
reserved by the BIOS. Access to these ranges is caught as an error,
causing the BIOS to halt the system.
Initial page tables mapped a large range of physical addresses that
were not checked against the list of BIOS reserved addresses, and
sometimes included reserved addresses in part of the mapped range.
Including the reserved range in the map allowed processor speculative
accesses to the reserved range, triggering a BIOS halt.
Used early in booting, the page table level2_kernel_pgt addresses 1
GiB divided into 2 MiB pages, and it was set up to linearly map a full
1 GiB of physical addresses that included the physical address range
of the kernel image, as chosen by KASLR. But this also included a
large range of unused addresses on either side of the kernel image.
And unlike the kernel image's physical address range, this extra
mapped space was not checked against the BIOS tables of usable RAM
addresses. So there were times when the addresses chosen by KASLR
would result in processor accessible mappings of BIOS reserved
physical addresses.
The kernel code did not directly access any of this extra mapped
space, but having it mapped allowed the processor to issue speculative
accesses into reserved memory, causing system halts.
This was encountered somewhat rarely on a normal system boot, and much
more often when starting the crash kernel if "crashkernel=512M,high"
was specified on the command line (this heavily restricts the physical
address of the crash kernel, in our case usually within 1 GiB of
reserved space).
The solution is to invalidate the pages of this table outside the kernel
image's space before the page table is activated. It fixes this problem
on our hardware.
[ bp: Touchups. ]
Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: dimitri.sivanich@hpe.com
Cc: Feng Tang <feng.tang@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jordan Borgner <mail@jordan-borgner.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: mike.travis@hpe.com
Cc: russ.anderson@hpe.com
Cc: stable@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Link: https://lkml.kernel.org/r/9c011ee51b081534a7a15065b1681d200298b530.1569358539.git.steve.wahl@hpe.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Wed, 16 Oct 2019 13:21:50 +0000 (09:21 -0400)]
dm cache: fix bugs when a GFP_NOWAIT allocation fails
commit
13bd677a472d534bf100bab2713efc3f9e3f5978 upstream.
GFP_NOWAIT allocation can fail anytime - it doesn't wait for memory being
available and it fails if the mempool is exhausted and there is not enough
memory.
If we go down this path:
map_bio -> mg_start -> alloc_migration -> mempool_alloc(GFP_NOWAIT)
we can see that map_bio() doesn't check the return value of mg_start(),
and the bio is leaked.
If we go down this path:
map_bio -> mg_start -> mg_lock_writes -> alloc_prison_cell ->
dm_bio_prison_alloc_cell_v2 -> mempool_alloc(GFP_NOWAIT) ->
mg_lock_writes -> mg_complete
the bio is ended with an error - it is unacceptable because it could
cause filesystem corruption if the machine ran out of memory
temporarily.
Change GFP_NOWAIT to GFP_NOIO, so that the mempool code will properly
wait until memory becomes available. mempool_alloc with GFP_NOIO can't
fail, so remove the code paths that deal with allocation failure.
Cc: stable@vger.kernel.org
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prateek Sood [Tue, 15 Oct 2019 06:17:25 +0000 (11:47 +0530)]
tracing: Fix race in perf_trace_buf initialization
commit
6b1340cc00edeadd52ebd8a45171f38c8de2a387 upstream.
A race condition exists while initialiazing perf_trace_buf from
perf_trace_init() and perf_kprobe_init().
CPU0 CPU1
perf_trace_init()
mutex_lock(&event_mutex)
perf_trace_event_init()
perf_trace_event_reg()
total_ref_count == 0
buf = alloc_percpu()
perf_trace_buf[i] = buf
tp_event->class->reg() //fails perf_kprobe_init()
goto fail perf_trace_event_init()
perf_trace_event_reg()
fail:
total_ref_count == 0
total_ref_count == 0
buf = alloc_percpu()
perf_trace_buf[i] = buf
tp_event->class->reg()
total_ref_count++
free_percpu(perf_trace_buf[i])
perf_trace_buf[i] = NULL
Any subsequent call to perf_trace_event_reg() will observe total_ref_count > 0,
causing the perf_trace_buf to be always NULL. This can result in perf_trace_buf
getting accessed from perf_trace_buf_alloc() without being initialized. Acquiring
event_mutex in perf_kprobe_init() before calling perf_trace_event_init() should
fix this race.
The race caused the following bug:
Unable to handle kernel paging request at virtual address
0000003106f2003c
Mem abort info:
ESR = 0x96000045
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000045
CM = 0, WnR = 1
user pgtable: 4k pages, 39-bit VAs, pgdp =
ffffffc034b9b000
[
0000003106f2003c] pgd=
0000000000000000, pud=
0000000000000000
Internal error: Oops:
96000045 [#1] PREEMPT SMP
Process syz-executor (pid: 18393, stack limit = 0xffffffc093190000)
pstate:
80400005 (Nzcv daif +PAN -UAO)
pc : __memset+0x20/0x1ac
lr : memset+0x3c/0x50
sp :
ffffffc09319fc50
__memset+0x20/0x1ac
perf_trace_buf_alloc+0x140/0x1a0
perf_trace_sys_enter+0x158/0x310
syscall_trace_enter+0x348/0x7c0
el0_svc_common+0x11c/0x368
el0_svc_handler+0x12c/0x198
el0_svc+0x8/0xc
Ramdumps showed the following:
total_ref_count = 3
perf_trace_buf = (
0x0 -> NULL,
0x0 -> NULL,
0x0 -> NULL,
0x0 -> NULL)
Link: http://lkml.kernel.org/r/1571120245-4186-1-git-send-email-prsood@codeaurora.org
Cc: stable@vger.kernel.org
Fixes:
e12f03d7031a9 ("perf/core: Implement the 'perf_kprobe' PMU")
Acked-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Prateek Sood <prsood@codeaurora.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Shishkin [Tue, 22 Oct 2019 07:39:40 +0000 (10:39 +0300)]
perf/aux: Fix AUX output stopping
commit
f3a519e4add93b7b31a6616f0b09635ff2e6a159 upstream.
Commit:
8a58ddae2379 ("perf/core: Fix exclusive events' grouping")
allows CAP_EXCLUSIVE events to be grouped with other events. Since all
of those also happen to be AUX events (which is not the case the other
way around, because arch/s390), this changes the rules for stopping the
output: the AUX event may not be on its PMU's context any more, if it's
grouped with a HW event, in which case it will be on that HW event's
context instead. If that's the case, munmap() of the AUX buffer can't
find and stop the AUX event, potentially leaving the last reference with
the atomic context, which will then end up freeing the AUX buffer. This
will then trip warnings:
Fix this by using the context's PMU context when looking for events
to stop, instead of the event's PMU context.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20191022073940.61814-1-alexander.shishkin@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavel Shilovsky [Wed, 23 Oct 2019 22:37:19 +0000 (15:37 -0700)]
CIFS: Fix use after free of file info structures
commit
1a67c415965752879e2e9fad407bc44fc7f25f23 upstream.
Currently the code assumes that if a file info entry belongs
to lists of open file handles of an inode and a tcon then
it has non-zero reference. The recent changes broke that
assumption when putting the last reference of the file info.
There may be a situation when a file is being deleted but
nothing prevents another thread to reference it again
and start using it. This happens because we do not hold
the inode list lock while checking the number of references
of the file info structure. Fix this by doing the proper
locking when doing the check.
Fixes:
487317c99477d ("cifs: add spinlock for the openFileList to cifsInodeInfo")
Fixes:
cb248819d209d ("cifs: use cifsInodeInfo->open_file_lock while iterating to avoid a panic")
Cc: Stable <stable@vger.kernel.org>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roberto Bergantinos Corpas [Mon, 14 Oct 2019 08:59:23 +0000 (10:59 +0200)]
CIFS: avoid using MID 0xFFFF
commit
03d9a9fe3f3aec508e485dd3dcfa1e99933b4bdb upstream.
According to MS-CIFS specification MID 0xFFFF should not be used by the
CIFS client, but we actually do. Besides, this has proven to cause races
leading to oops between SendReceive2/cifs_demultiplex_thread. On SMB1,
MID is a 2 byte value easy to reach in CurrentMid which may conflict with
an oplock break notification request coming from server
Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Tue, 9 Apr 2019 15:26:21 +0000 (16:26 +0100)]
arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT
commit
93916beb70143c46bf1d2bacf814be3a124b253b upstream.
It appears that the only case where we need to apply the TX2_219_TVM
mitigation is when the core is in SMT mode. So let's condition the
enabling on detecting a CPU whose MPIDR_EL1.Aff0 is non-zero.
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Morse [Mon, 14 Oct 2019 17:19:18 +0000 (18:19 +0100)]
EDAC/ghes: Fix Use after free in ghes_edac remove path
commit
1e72e673b9d102ff2e8333e74b3308d012ddf75b upstream.
ghes_edac models a single logical memory controller, and uses a global
ghes_init variable to ensure only the first ghes_edac_register() will
do anything.
ghes_edac is registered the first time a GHES entry in the HEST is
probed. There may be multiple entries, so subsequent attempts to
register ghes_edac are silently ignored as the work has already been
done.
When a GHES entry is unregistered, it calls ghes_edac_unregister(),
which free()s the memory behind the global variables in ghes_edac.
But there may be multiple GHES entries, the next call to
ghes_edac_unregister() will dereference the free()d memory, and attempt
to free it a second time.
This may also be triggered on a platform with one GHES entry, if the
driver is unbound/re-bound and unbound. The re-bind step will do
nothing because of ghes_init, the second unbind will then do the same
work as the first.
Doing the unregister work on the first call is unsafe, as another
CPU may be processing a notification in ghes_edac_report_mem_error(),
using the memory we are about to free.
ghes_init is already half of the reference counting. We only need
to do the register work for the first call, and the unregister work
for the last. Add the unregister check.
This means we no longer free ghes_edac's memory while there are
GHES entries that may receive a notification.
This was detected by KASAN and DEBUG_TEST_DRIVER_REMOVE.
[ bp: merge into a single patch. ]
Fixes:
0fe5f281f749 ("EDAC, ghes: Model a single, logical memory controller")
Reported-by: John Garry <john.garry@huawei.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Robert Richter <rrichter@marvell.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20191014171919.85044-2-james.morse@arm.com
Link: https://lkml.kernel.org/r/304df85b-8b56-b77e-1a11-aa23769f2e7c@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Fri, 4 Oct 2019 17:23:37 +0000 (19:23 +0200)]
parisc: Fix vmap memory leak in ioremap()/iounmap()
commit
513f7f747e1cba81f28a436911fba0b485878ebd upstream.
Sven noticed that calling ioremap() and iounmap() multiple times leads
to a vmap memory leak:
vmap allocation for size 4198400 failed:
use vmalloc=<size> to increase size
It seems we missed calling vunmap() in iounmap().
Signed-off-by: Helge Deller <deller@gmx.de>
Noticed-by: Sven Schnelle <svens@stackframe.org>
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Max Filippov [Mon, 14 Oct 2019 22:48:19 +0000 (15:48 -0700)]
xtensa: drop EXPORT_SYMBOL for outs*/ins*
commit
8b39da985194aac2998dd9e3a22d00b596cebf1e upstream.
Custom outs*/ins* implementations are long gone from the xtensa port,
remove matching EXPORT_SYMBOLs.
This fixes the following build warnings issued by modpost since commit
15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions"):
WARNING: "insb" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "insw" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "insl" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "outsb" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "outsw" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "outsl" [vmlinux] is a static EXPORT_SYMBOL
Cc: stable@vger.kernel.org
Fixes:
d38efc1f150f ("xtensa: adopt generic io routines")
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jane Chu [Mon, 14 Oct 2019 21:12:29 +0000 (14:12 -0700)]
mm/memory-failure: poison read receives SIGKILL instead of SIGBUS if mmaped more than once
commit
3d7fed4ad8ccb691d217efbb0f934e6a4df5ef91 upstream.
Mmap /dev/dax more than once, then read the poison location using
address from one of the mappings. The other mappings due to not having
the page mapped in will cause SIGKILLs delivered to the process.
SIGKILL succeeds over SIGBUS, so user process loses the opportunity to
handle the UE.
Although one may add MAP_POPULATE to mmap(2) to work around the issue,
MAP_POPULATE makes mapping 128GB of pmem several magnitudes slower, so
isn't always an option.
Details -
ndctl inject-error --block=10 --count=1 namespace6.0
./read_poison -x dax6.0 -o 5120 -m 2
mmaped address 0x7f5bb6600000
mmaped address 0x7f3cf3600000
doing local read at address 0x7f3cf3601400
Killed
Console messages in instrumented kernel -
mce: Uncorrected hardware memory error in user-access at
edbe201400
Memory failure: tk->addr =
7f5bb6601000
Memory failure: address edbe201: call dev_pagemap_mapping_shift
dev_pagemap_mapping_shift: page edbe201: no PUD
Memory failure: tk->size_shift == 0
Memory failure: Unable to find user space address edbe201 in read_poison
Memory failure: tk->addr =
7f3cf3601000
Memory failure: address edbe201: call dev_pagemap_mapping_shift
Memory failure: tk->size_shift = 21
Memory failure: 0xedbe201: forcibly killing read_poison:22434 because of failure to unmap corrupted page
=> to deliver SIGKILL
Memory failure: 0xedbe201: Killing read_poison:22434 due to hardware memory corruption
=> to deliver SIGBUS
Link: http://lkml.kernel.org/r/1565112345-28754-3-git-send-email-jane.chu@oracle.com
Signed-off-by: Jane Chu <jane.chu@oracle.com>
Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Hildenbrand [Sat, 19 Oct 2019 03:20:05 +0000 (20:20 -0700)]
hugetlbfs: don't access uninitialized memmaps in pfn_range_valid_gigantic()
commit
f231fe4235e22e18d847e05cbe705deaca56580a upstream.
Uninitialized memmaps contain garbage and in the worst case trigger
kernel BUGs, especially with CONFIG_PAGE_POISONING. They should not get
touched.
Let's make sure that we only consider online memory (managed by the
buddy) that has initialized memmaps. ZONE_DEVICE is not applicable.
page_zone() will call page_to_nid(), which will trigger
VM_BUG_ON_PGFLAGS(PagePoisoned(page), page) with CONFIG_PAGE_POISONING
and CONFIG_DEBUG_VM_PGFLAGS when called on uninitialized memmaps. This
can be the case when an offline memory block (e.g., never onlined) is
spanned by a zone.
Note: As explained by Michal in [1], alloc_contig_range() will verify
the range. So it boils down to the wrong access in this function.
[1] http://lkml.kernel.org/r/
20180423000943.GO17484@dhcp22.suse.cz
Link: http://lkml.kernel.org/r/20191015120717.4858-1-david@redhat.com
Fixes:
f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [visible after
d0dc12e86b319]
Signed-off-by: David Hildenbrand <david@redhat.com>
Reported-by: Michal Hocko <mhocko@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: <stable@vger.kernel.org> [4.13+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qian Cai [Sat, 19 Oct 2019 03:19:29 +0000 (20:19 -0700)]
mm/page_owner: don't access uninitialized memmaps when reading /proc/pagetypeinfo
commit
a26ee565b6cd8dc2bf15ff6aa70bbb28f928b773 upstream.
Uninitialized memmaps contain garbage and in the worst case trigger
kernel BUGs, especially with CONFIG_PAGE_POISONING. They should not get
touched.
For example, when not onlining a memory block that is spanned by a zone
and reading /proc/pagetypeinfo with CONFIG_DEBUG_VM_PGFLAGS and
CONFIG_PAGE_POISONING, we can trigger a kernel BUG:
:/# echo 1 > /sys/devices/system/memory/memory40/online
:/# echo 1 > /sys/devices/system/memory/memory42/online
:/# cat /proc/pagetypeinfo > test.file
page:
fffff2c585200000 is uninitialized and poisoned
raw:
ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
raw:
ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
There is not page extension available.
------------[ cut here ]------------
kernel BUG at include/linux/mm.h:1107!
invalid opcode: 0000 [#1] SMP NOPTI
Please note that this change does not affect ZONE_DEVICE, because
pagetypeinfo_showmixedcount_print() is called from
mm/vmstat.c:pagetypeinfo_showmixedcount() only for populated zones, and
ZONE_DEVICE is never populated (zone->present_pages always 0).
[david@redhat.com: move check to outer loop, add comment, rephrase description]
Link: http://lkml.kernel.org/r/20191011140638.8160-1-david@redhat.com
Fixes:
f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") # visible after
d0dc12e86b319
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Miles Chen <miles.chen@mediatek.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org> [4.13+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qian Cai [Mon, 14 Oct 2019 21:11:51 +0000 (14:11 -0700)]
mm/slub: fix a deadlock in show_slab_objects()
commit
e4f8e513c3d353c134ad4eef9fd0bba12406c7c8 upstream.
A long time ago we fixed a similar deadlock in show_slab_objects() [1].
However, it is apparently due to the commits like
01fb58bcba63 ("slab:
remove synchronous synchronize_sched() from memcg cache deactivation
path") and
03afc0e25f7f ("slab: get_online_mems for
kmem_cache_{create,destroy,shrink}"), this kind of deadlock is back by
just reading files in /sys/kernel/slab which will generate a lockdep
splat below.
Since the "mem_hotplug_lock" here is only to obtain a stable online node
mask while racing with NUMA node hotplug, in the worst case, the results
may me miscalculated while doing NUMA node hotplug, but they shall be
corrected by later reads of the same files.
WARNING: possible circular locking dependency detected
------------------------------------------------------
cat/5224 is trying to acquire lock:
ffff900012ac3120 (mem_hotplug_lock.rw_sem){++++}, at:
show_slab_objects+0x94/0x3a8
but task is already holding lock:
b8ff009693eee398 (kn->count#45){++++}, at: kernfs_seq_start+0x44/0xf0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (kn->count#45){++++}:
lock_acquire+0x31c/0x360
__kernfs_remove+0x290/0x490
kernfs_remove+0x30/0x44
sysfs_remove_dir+0x70/0x88
kobject_del+0x50/0xb0
sysfs_slab_unlink+0x2c/0x38
shutdown_cache+0xa0/0xf0
kmemcg_cache_shutdown_fn+0x1c/0x34
kmemcg_workfn+0x44/0x64
process_one_work+0x4f4/0x950
worker_thread+0x390/0x4bc
kthread+0x1cc/0x1e8
ret_from_fork+0x10/0x18
-> #1 (slab_mutex){+.+.}:
lock_acquire+0x31c/0x360
__mutex_lock_common+0x16c/0xf78
mutex_lock_nested+0x40/0x50
memcg_create_kmem_cache+0x38/0x16c
memcg_kmem_cache_create_func+0x3c/0x70
process_one_work+0x4f4/0x950
worker_thread+0x390/0x4bc
kthread+0x1cc/0x1e8
ret_from_fork+0x10/0x18
-> #0 (mem_hotplug_lock.rw_sem){++++}:
validate_chain+0xd10/0x2bcc
__lock_acquire+0x7f4/0xb8c
lock_acquire+0x31c/0x360
get_online_mems+0x54/0x150
show_slab_objects+0x94/0x3a8
total_objects_show+0x28/0x34
slab_attr_show+0x38/0x54
sysfs_kf_seq_show+0x198/0x2d4
kernfs_seq_show+0xa4/0xcc
seq_read+0x30c/0x8a8
kernfs_fop_read+0xa8/0x314
__vfs_read+0x88/0x20c
vfs_read+0xd8/0x10c
ksys_read+0xb0/0x120
__arm64_sys_read+0x54/0x88
el0_svc_handler+0x170/0x240
el0_svc+0x8/0xc
other info that might help us debug this:
Chain exists of:
mem_hotplug_lock.rw_sem --> slab_mutex --> kn->count#45
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(kn->count#45);
lock(slab_mutex);
lock(kn->count#45);
lock(mem_hotplug_lock.rw_sem);
*** DEADLOCK ***
3 locks held by cat/5224:
#0:
9eff00095b14b2a0 (&p->lock){+.+.}, at: seq_read+0x4c/0x8a8
#1:
0eff008997041480 (&of->mutex){+.+.}, at: kernfs_seq_start+0x34/0xf0
#2:
b8ff009693eee398 (kn->count#45){++++}, at:
kernfs_seq_start+0x44/0xf0
stack backtrace:
Call trace:
dump_backtrace+0x0/0x248
show_stack+0x20/0x2c
dump_stack+0xd0/0x140
print_circular_bug+0x368/0x380
check_noncircular+0x248/0x250
validate_chain+0xd10/0x2bcc
__lock_acquire+0x7f4/0xb8c
lock_acquire+0x31c/0x360
get_online_mems+0x54/0x150
show_slab_objects+0x94/0x3a8
total_objects_show+0x28/0x34
slab_attr_show+0x38/0x54
sysfs_kf_seq_show+0x198/0x2d4
kernfs_seq_show+0xa4/0xcc
seq_read+0x30c/0x8a8
kernfs_fop_read+0xa8/0x314
__vfs_read+0x88/0x20c
vfs_read+0xd8/0x10c
ksys_read+0xb0/0x120
__arm64_sys_read+0x54/0x88
el0_svc_handler+0x170/0x240
el0_svc+0x8/0xc
I think it is important to mention that this doesn't expose the
show_slab_objects to use-after-free. There is only a single path that
might really race here and that is the slab hotplug notifier callback
__kmem_cache_shrink (via slab_mem_going_offline_callback) but that path
doesn't really destroy kmem_cache_node data structures.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1101.0/02850.html
[akpm@linux-foundation.org: add comment explaining why we don't need mem_hotplug_lock]
Link: http://lkml.kernel.org/r/1570192309-10132-1-git-send-email-cai@lca.pw
Fixes:
01fb58bcba63 ("slab: remove synchronous synchronize_sched() from memcg cache deactivation path")
Fixes:
03afc0e25f7f ("slab: get_online_mems for kmem_cache_{create,destroy,shrink}")
Signed-off-by: Qian Cai <cai@lca.pw>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Roman Gushchin <guro@fb.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Hildenbrand [Sat, 19 Oct 2019 03:19:23 +0000 (20:19 -0700)]
mm/memory-failure.c: don't access uninitialized memmaps in memory_failure()
commit
96c804a6ae8c59a9092b3d5dd581198472063184 upstream.
We should check for pfn_to_online_page() to not access uninitialized
memmaps. Reshuffle the code so we don't have to duplicate the error
message.
Link: http://lkml.kernel.org/r/20191009142435.3975-3-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Fixes:
f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [visible after
d0dc12e86b319]
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <stable@vger.kernel.org> [4.13+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>