When running the kernel with init_on_alloc=1, calling the default
implementation of __alloc_zeroed_user_highpage() from include/linux/highmem.h
leads to double-initialization of the allocated page (first by the page
allocator, then by clear_user_page().
Calling alloc_page_vma() with __GFP_ZERO, similarly to e.g. x86, seems
to be enough to ensure the user page is zeroed only once.
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 149975351
Link: https://lore.kernel.org/linux-arm-kernel/20200312155920.50067-1-glider@google.com/
Change-Id: I3ff7c3fb082b420491313e0fdd841ce340989d72
Signed-off-by: Alexander Potapenko <glider@google.com>
extcon_get_edev_name() function provides client driver to request
extcon dev's name. If extcon driver and client driver are compiled
as loadable modules, extcon_get_edev_name() function symbol is not
visible to client driver. Hence mark extcon_find_edev_name() function
as exported symbol.
(cherry picked from commit 995bb1092326b8ba8fa29456c334ac6a49765ccd
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git)
Bug: 152643506
Change-Id: Idbeed2cf45cc201d707ccbccdd043d71e3a0c23a
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This patch adds required CONFIG_REMOTEPROC to the gki_defconfig
in order for functionality like wifi to work on the db845c.
Bug: 146449535
Change-Id: I21a233b193b22b84ebb1462daf324bcc6b5c6594
Signed-off-by: John Stultz <john.stultz@linaro.org>
RPMSG is used on various SoC platforms downstream. Enable the subsystem
in the gki_defconfig. This also enables RPMSG_CHAR.
Bug: 146449535
Change-Id: Ib4a6e5a438681a9835398cdb8917045191e1fbe6
Signed-off-by: Alistair Delva <adelva@google.com>
This reverts commit 710da3c8ea.
When changing a thread's scheduling priority, binder calls
sched_setscheduler_nocheck() while holding the node lock and
proc inner lock. This was safe until v5.3 when this change was
introduced where cpuset_read_lock() is called in this path
which can sleep.
This patch was introduced to fix a possible accounting error
in sched deadline (potential oversell of CPU bandwidth) due
to a race condition between cpusets and __sched_setscheduler().
This is not an issue for Android.
This should be fixed in the binder driver, but that may take
some time.
Bug: 151861772
Change-Id: Ica1ef71b3cdcdc509b341ea1b57c41f8ee73794a
Signed-off-by: Todd Kjos <tkjos@google.com>
This reverts commit aefd2d632e.
This patch introduced a race condition reported by Pete Zhang
<pete.zhang@nxp.com> where a thread already selected to handle a
transaction could be selected again by a different client. The signature
was triggering of the WARN_ON() in binder_enqueue_thread_work_ilocked():
static void
binder_enqueue_thread_work_ilocked(...)
{
WARN_ON(!list_empty(&thread->waiting_thread_node));
...
}
which indicates that a thread is unexpectedly enqueued
as a waiting thread when it has been selected and work is
being assigned to it.
There was a 2nd issue introduced by the same patch that could,
at least in theory, cause async transactions to hang.
Bug: 151861772
Change-Id: I0c2bdb4c4a0d57caae1551bcbb4c31a8e09e024b
Signed-off-by: Todd Kjos <tkjos@google.com>
This enables page allocator randomization in both x86
and ar64 gki defconfig
Bug: 151881089
Test: builds
Signed-off-by: Sandeep Patil <sspatil@google.com>
Change-Id: I1d28368f2df6aad47d9e90cc991b7f5dc21d2cfa
This should be unset so that usercopy whitelists are not actually being
enforced.
Bug: 152470236
Cc: Kees Cook <keescook@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I11069fa6d66cf23d38d33ccc52492aaa0915b776
For lots of good security reasons, this config option needs to be
enabled
Bug: 152470236
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I96a88bbee9c4d17be97ed63262dbab2ef31fee79
Fix free_show value is incorrect
Change-Id: If7f36a64afa600c980ee8a25393f8716a6ffd474
Signed-off-by: Dylan Chang <dylan.chang@oneplus.com>
Bug: 152116739
(cherry picked from commit feff0b2236497c0651baa7f59ea50c2377fff053)
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Try to mitigate potential future driver core api changes by adding a
padding to struct work_struct and struct delayed_work
Based on a change made to the RHEL/CENTOS 8 kernel.
Leaf changes summary: 129 artifacts changed
Changed leaf types summary: 129 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
type 'struct work_struct' changed:
type size changed from 256 to 384 (in bits)
2 data member insertions:
'u64 work_struct::android_kabi_reserved1', at offset 256 (in bits) at workqueue.h:110:1
'u64 work_struct::android_kabi_reserved2', at offset 320 (in bits) at workqueue.h:111:1
type 'struct delayed_work' changed:
type size changed from 704 to 960 (in bits)
2 data member insertions:
'u64 delayed_work::android_kabi_reserved1', at offset 832 (in bits) at workqueue.h:126:1
'u64 delayed_work::android_kabi_reserved2', at offset 896 (in bits) at workqueue.h:127:1
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5492a13e2430c1a5775aec52518144b7aa4f3268
To ensure UAPI headers will compile standalone and can (later) be
monitored for API/ABI stability, enable the feature accordingly.
That seams like an additional overhead at compile time, but runs
smoothly while we are waiting for the LTO link to finish :-)
Bug: 73298553
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: Iae4f67f430ee2a3000f9f035aa0cd4392e72460f
(cherry picked from commit 9465730798f95fc5a0f0916ef6bcdfc7a1e839e9)
Try to mitigate potential future driver core api changes by adding a
padding to a bunch of filesystem structures.
Based on a change made to the RHEL/CENTOS 8 kernel.
Leaf changes summary: 12 artifacts changed
Changed leaf types summary: 12 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct address_space at fs.h:445:1' changed:
type size changed from 1280 to 1536 (in bits)
4 data member insertions:
'u64 address_space::android_kabi_reserved1', at offset 1280 (in bits) at fs.h:472:1
'u64 address_space::android_kabi_reserved2', at offset 1344 (in bits) at fs.h:473:1
'u64 address_space::android_kabi_reserved3', at offset 1408 (in bits) at fs.h:474:1
'u64 address_space::android_kabi_reserved4', at offset 1472 (in bits) at fs.h:475:1
'struct address_space_operations at fs.h:362:1' changed:
type size changed from 1344 to 1600 (in bits)
4 data member insertions:
'u64 address_space_operations::android_kabi_reserved1', at offset 1344 (in bits) at fs.h:412:1
'u64 address_space_operations::android_kabi_reserved2', at offset 1408 (in bits) at fs.h:413:1
'u64 address_space_operations::android_kabi_reserved3', at offset 1472 (in bits) at fs.h:414:1
'u64 address_space_operations::android_kabi_reserved4', at offset 1536 (in bits) at fs.h:415:1
'struct block_device at fs.h:473:1' changed:
type size changed from 1728 to 1984 (in bits)
4 data member insertions:
'u64 block_device::android_kabi_reserved1', at offset 1728 (in bits) at fs.h:521:1
'u64 block_device::android_kabi_reserved2', at offset 1792 (in bits) at fs.h:522:1
'u64 block_device::android_kabi_reserved3', at offset 1856 (in bits) at fs.h:523:1
'u64 block_device::android_kabi_reserved4', at offset 1920 (in bits) at fs.h:524:1
'struct file_lock at fs.h:1080:1' changed:
type size changed from 1728 to 1984 (in bits)
3 data member insertions:
'list_head file_lock::android_reserved1', at offset 1728 (in bits) at fs.h:1142:1
'u64 file_lock::android_kabi_reserved1', at offset 1856 (in bits) at fs.h:1143:1
'u64 file_lock::android_kabi_reserved2', at offset 1920 (in bits) at fs.h:1144:1
'struct file_lock_operations at fs.h:1030:1' changed:
type size changed from 128 to 256 (in bits)
2 data member insertions:
'u64 file_lock_operations::android_kabi_reserved1', at offset 128 (in bits) at fs.h:1053:1
'u64 file_lock_operations::android_kabi_reserved2', at offset 192 (in bits) at fs.h:1054:1
'struct file_operations at fs.h:1843:1' changed:
type size changed from 2048 to 2304 (in bits)
4 data member insertions:
'u64 file_operations::android_kabi_reserved1', at offset 2048 (in bits) at fs.h:1918:1
'u64 file_operations::android_kabi_reserved2', at offset 2112 (in bits) at fs.h:1919:1
'u64 file_operations::android_kabi_reserved3', at offset 2176 (in bits) at fs.h:1920:1
'u64 file_operations::android_kabi_reserved4', at offset 2240 (in bits) at fs.h:1921:1
'struct file_system_type at fs.h:2245:1' changed:
type size changed from 640 to 896 (in bits)
4 data member insertions:
'u64 file_system_type::android_kabi_reserved1', at offset 640 (in bits) at fs.h:2322:1
'u64 file_system_type::android_kabi_reserved2', at offset 704 (in bits) at fs.h:2323:1
'u64 file_system_type::android_kabi_reserved3', at offset 768 (in bits) at fs.h:2324:1
'u64 file_system_type::android_kabi_reserved4', at offset 832 (in bits) at fs.h:2325:1
'struct inode at fs.h:628:1' changed:
type size changed from 4800 to 5184 (in bits)
2 data member insertions:
'u64 inode::android_kabi_reserved1', at offset 5056 (in bits) at fs.h:756:1
'u64 inode::android_kabi_reserved2', at offset 5120 (in bits) at fs.h:757:1
'struct inode_operations at fs.h:1885:1' changed:
type size changed from 1536 to 2048 (in bits)
4 data member insertions:
'u64 inode_operations::android_kabi_reserved1', at offset 1472 (in bits) at fs.h:1955:1
'u64 inode_operations::android_kabi_reserved2', at offset 1536 (in bits) at fs.h:1956:1
'u64 inode_operations::android_kabi_reserved3', at offset 1600 (in bits) at fs.h:1957:1
'u64 inode_operations::android_kabi_reserved4', at offset 1664 (in bits) at fs.h:1958:1
'struct lock_manager_operations at fs.h:1035:1' changed:
type size changed from 448 to 576 (in bits)
2 data member insertions:
'u64 lock_manager_operations::android_kabi_reserved1', at offset 448 (in bits) at fs.h:1066:1
'u64 lock_manager_operations::android_kabi_reserved2', at offset 512 (in bits) at fs.h:1067:1
'struct super_block at fs.h:1431:1' changed:
type size changed from 11776 to 12288 (in bits)
4 data member insertions:
'u64 super_block::android_kabi_reserved1', at offset 11648 (in bits) at fs.h:1592:1
'u64 super_block::android_kabi_reserved2', at offset 11712 (in bits) at fs.h:1593:1
'u64 super_block::android_kabi_reserved3', at offset 11776 (in bits) at fs.h:1594:1
'u64 super_block::android_kabi_reserved4', at offset 11840 (in bits) at fs.h:1595:1
'struct super_operations at fs.h:1966:1' changed:
type size changed from 1920 to 2176 (in bits)
4 data member insertions:
'u64 super_operations::android_kabi_reserved1', at offset 1920 (in bits) at fs.h:2048:1
'u64 super_operations::android_kabi_reserved2', at offset 1984 (in bits) at fs.h:2049:1
'u64 super_operations::android_kabi_reserved3', at offset 2048 (in bits) at fs.h:2050:1
'u64 super_operations::android_kabi_reserved4', at offset 2112 (in bits) at fs.h:2051:1
Bug: 151154716
Change-Id: Ida6d98d30f292c980ab07e0250fec5268c4c87ed
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
v4l2_fh struct define differently by CONFIG_V4L2_MEM2MEM_DEV.
If some vendors use CONFIG_V4L2_MEM2MEM_DEV by module,
it can make the mismatch of v4l2_fh sturct.
By the mismatch, the following error occurs.
===============================
[ 7.533506] v4l2_mem2mem: disagrees about version of symbol video_devdata
[ 7.533594] v4l2_mem2mem: Unknown symbol video_devdata (err -22)
[ 7.535319] v4l2_mem2mem: disagrees about version of symbol v4l2_event_pending
[ 7.542532] v4l2_mem2mem: Unknown symbol v4l2_event_pending (err -22)
===============================
So v4l2_fh struct is modified to does not have dependency
for CONFIG_V4L2_MEM2MEM_DEV.
Bug: 151399858
Link: https://lore.kernel.org/linux-media/000601d600bb$0e2d4320$2a87c960$@samsung.com/T/#u
Change-Id: I6481516d5197988e800853a491474b374ed61d36
Signed-off-by: Seungchul Kim <sc377.kim@samsung.com>
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct inode at fs.h:628:1' changed:
type size changed from 4736 to 4800 (in bits)
1 data member insertion:
'atomic64_t inode::i_sequence', at offset 2688 (in bits) at fs.h:701:1
there are data member changes:
861 impacted interfaces:
Change-Id: I58496998ce4fa926345882aa0ec89a7c029575b9
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl57B4gACgkQONu9yGCS
aT6KWQ//ToF4D+fDl1Muf4xuT83HnXe1yA1XFlyC54ZmEaxGFnFMSAgAvitBR7HC
GEczXlvYbbVJl646ynTmX/LFz2d+V0i2zGv2QKN3xfd8GtDrAq/s+Ffhneaskk1k
gKkIUzOyBq0nEAq5vXbCT4LbQDYGLw8BxxvurLim/YywSy5sfnw+hKkYE7cVVSOa
rTIdt5qnuL4pxD8VeCAakoU6SajoxfFqS8pX79LC1UPY+++OaVcJjyJvM4APw0Kr
e2E1BaeZxxCyY57pQY2oqhjG3cCfIcmfln19JRzMCVNo9+J3MEjZI5EUqP/Zcjwz
1V5FHqDmqMGfA9cn+CexDk79bTKW5+YOyYMEG2RJjV5alWJtvv3Wj6dRPVPpBhnJ
O627IuIVGMsHuiEbjziKczaTtYYU5GTpJF+7COH0Jnud0q1w3/RjaJXspnb2Yozh
L9BFqc4aonD+AyW2NXTxuuvc3hnD2YSVgLectm7LF/TbM2YFJVu4tounelFsGG6I
CPH2VF0Tn+yNR2iWf8igvopvYPCjv+QFGXU6kFGxQxLQFTnXHqoO2sPF4awXx7Hv
XF8LrJzPwissX5BbPyhUSIl0FEcmQi6UzSN1/6fpxVq+092OGVacMWpZvwqjUOV/
3k/OrmcYsu7i2UUbms47YHAK0PRkL2ogKgxgcSO4aNZ7MfkXkm8=
=kp1m
-----END PGP SIGNATURE-----
Merge 5.4.28 into android-5.4
Changes in 5.4.28
locks: fix a potential use-after-free problem when wakeup a waiter
locks: reinstate locks_delete_block optimization
spi: spi-omap2-mcspi: Support probe deferral for DMA channels
drm/mediatek: Find the cursor plane instead of hard coding it
phy: ti: gmii-sel: fix set of copy-paste errors
phy: ti: gmii-sel: do not fail in case of gmii
ARM: dts: dra7-l4: mark timer13-16 as pwm capable
spi: qup: call spi_qup_pm_resume_runtime before suspending
powerpc: Include .BTF section
cifs: fix potential mismatch of UNC paths
cifs: add missing mount option to /proc/mounts
ARM: dts: dra7: Add "dma-ranges" property to PCIe RC DT nodes
spi: pxa2xx: Add CS control clock quirk
spi/zynqmp: remove entry that causes a cs glitch
drm/exynos: dsi: propagate error value and silence meaningless warning
drm/exynos: dsi: fix workaround for the legacy clock name
drm/exynos: hdmi: don't leak enable HDMI_EN regulator if probe fails
drivers/perf: fsl_imx8_ddr: Correct the CLEAR bit definition
drivers/perf: arm_pmu_acpi: Fix incorrect checking of gicc pointer
altera-stapl: altera_get_note: prevent write beyond end of 'key'
dm bio record: save/restore bi_end_io and bi_integrity
dm integrity: use dm_bio_record and dm_bio_restore
riscv: avoid the PIC offset of static percpu data in module beyond 2G limits
ASoC: stm32: sai: manage rebind issue
spi: spi_register_controller(): free bus id on error paths
riscv: Force flat memory model with no-mmu
riscv: Fix range looking for kernel image memblock
drm/amdgpu: clean wptr on wb when gpu recovery
drm/amd/display: Clear link settings on MST disable connector
drm/amd/display: fix dcc swath size calculations on dcn1
xenbus: req->body should be updated before req->state
xenbus: req->err should be updated before req->state
block, bfq: fix overwrite of bfq_group pointer in bfq_find_set_group()
parse-maintainers: Mark as executable
binderfs: use refcount for binder control devices too
Revert "drm/fbdev: Fallback to non tiled mode if all tiles not present"
USB: Disable LPM on WD19's Realtek Hub
usb: quirks: add NO_LPM quirk for RTL8153 based ethernet adapters
USB: serial: option: add ME910G1 ECM composition 0x110b
usb: host: xhci-plat: add a shutdown
USB: serial: pl2303: add device-id for HP LD381
usb: xhci: apply XHCI_SUSPEND_DELAY to AMD XHCI controller 1022:145c
usb: typec: ucsi: displayport: Fix NULL pointer dereference
usb: typec: ucsi: displayport: Fix a potential race during registration
USB: cdc-acm: fix close_delay and closing_wait units in TIOCSSERIAL
USB: cdc-acm: fix rounding error in TIOCSSERIAL
ALSA: line6: Fix endless MIDI read loop
ALSA: hda/realtek - Enable headset mic of Acer X2660G with ALC662
ALSA: hda/realtek - Enable the headset of Acer N50-600 with ALC662
ALSA: seq: virmidi: Fix running status after receiving sysex
ALSA: seq: oss: Fix running status after receiving sysex
ALSA: pcm: oss: Avoid plugin buffer overflow
ALSA: pcm: oss: Remove WARNING from snd_pcm_plug_alloc() checks
tty: fix compat TIOCGSERIAL leaking uninitialized memory
tty: fix compat TIOCGSERIAL checking wrong function ptr
iio: chemical: sps30: fix missing triggered buffer dependency
iio: st_sensors: remap SMO8840 to LIS2DH12
iio: trigger: stm32-timer: disable master mode when stopping
iio: accel: adxl372: Set iio_chan BE
iio: magnetometer: ak8974: Fix negative raw values in sysfs
iio: adc: stm32-dfsdm: fix sleep in atomic context
iio: adc: at91-sama5d2_adc: fix differential channels in triggered mode
iio: light: vcnl4000: update sampling periods for vcnl4200
iio: light: vcnl4000: update sampling periods for vcnl4040
mmc: rtsx_pci: Fix support for speed-modes that relies on tuning
mmc: sdhci-of-at91: fix cd-gpios for SAMA5D2
mmc: sdhci-cadence: set SDHCI_QUIRK2_PRESET_VALUE_BROKEN for UniPhier
CIFS: fiemap: do not return EINVAL if get nothing
kbuild: Disable -Wpointer-to-enum-cast
staging: rtl8188eu: Add device id for MERCUSYS MW150US v2
staging: greybus: loopback_test: fix poll-mask build breakage
staging/speakup: fix get_word non-space look-ahead
intel_th: msu: Fix the unexpected state warning
intel_th: Fix user-visible error codes
intel_th: pci: Add Elkhart Lake CPU support
modpost: move the namespace field in Module.symvers last
rtc: max8907: add missing select REGMAP_IRQ
arm64: compat: Fix syscall number of compat_clock_getres
xhci: Do not open code __print_symbolic() in xhci trace events
btrfs: fix log context list corruption after rename whiteout error
drm/amd/amdgpu: Fix GPR read from debugfs (v2)
drm/lease: fix WARNING in idr_destroy
stm class: sys-t: Fix the use of time_after()
memcg: fix NULL pointer dereference in __mem_cgroup_usage_unregister_event
mm, memcg: fix corruption on 64-bit divisor in memory.high throttling
mm, memcg: throttle allocators based on ancestral memory.high
mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
mm: do not allow MADV_PAGEOUT for CoW pages
epoll: fix possible lost wakeup on epoll_ctl() path
mm: slub: be more careful about the double cmpxchg of freelist
mm, slub: prevent kmalloc_node crashes and memory leaks
page-flags: fix a crash at SetPageError(THP_SWAP)
x86/mm: split vmalloc_sync_all()
futex: Fix inode life-time issue
futex: Unbreak futex hashing
ALSA: hda/realtek: Fix pop noise on ALC225
arm64: smp: fix smp_send_stop() behaviour
arm64: smp: fix crash_smp_send_stop() behaviour
nvmet-tcp: set MSG_MORE only if we actually have more to send
drm/bridge: dw-hdmi: fix AVI frame colorimetry
staging: greybus: loopback_test: fix potential path truncation
staging: greybus: loopback_test: fix potential path truncations
Linux 5.4.28
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5d9d15d6236d8ab7374205c6ceda7efa7a9abb70
Sections with double dots, e.g. .data..percpu are named intentionally
to avoid matching rules that apply to .section.*. Change module section
merging rules to skip these.
Bug: 151981957
Change-Id: I23787aa40d69da1c6ca622a5f111704d2459e163
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
commit ae62cf5eb2792d9a818c2d93728ed92119357017 upstream.
Newer GCC warns about possible truncations of two generated path names as
we're concatenating the configurable sysfs and debugfs path prefixes
with a filename and placing the results in buffers of the same size as
the maximum length of the prefixes.
snprintf(d->name, MAX_STR_LEN, "gb_loopback%u", dev_id);
snprintf(d->sysfs_entry, MAX_SYSFS_PATH, "%s%s/",
t->sysfs_prefix, d->name);
snprintf(d->debugfs_entry, MAX_SYSFS_PATH, "%sraw_latency_%s",
t->debugfs_prefix, d->name);
Fix this by separating the maximum path length from the maximum prefix
length and reducing the latter enough to fit the generated strings.
Note that we also need to reduce the device-name buffer size as GCC
isn't smart enough to figure out that we ever only used MAX_STR_LEN
bytes of it.
Fixes: 6b0658f687 ("greybus: tools: Add tools directory to greybus repo and add loopback")
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20200312110151.22028-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f16023834863932f95dfad13fac3fc47f77d2f29 upstream.
Newer GCC warns about a possible truncation of a generated sysfs path
name as we're concatenating a directory path with a file name and
placing the result in a buffer that is half the size of the maximum
length of the directory path (which is user controlled).
loopback_test.c: In function 'open_poll_files':
loopback_test.c:651:31: warning: '%s' directive output may be truncated writing up to 511 bytes into a region of size 255 [-Wformat-truncation=]
651 | snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry, "iteration_count");
| ^~
loopback_test.c:651:3: note: 'snprintf' output between 16 and 527 bytes into a destination of size 255
651 | snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry, "iteration_count");
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix this by making sure the buffer is large enough the concatenated
strings.
Fixes: 6b0658f687 ("greybus: tools: Add tools directory to greybus repo and add loopback")
Fixes: 9250c0ee26 ("greybus: Loopback_test: use poll instead of inotify")
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20200312110151.22028-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e8dca30f7118461d47e1c3510d0e31b277439151 upstream.
CTA-861-F explicitly states that for RGB colorspace colorimetry should
be set to "none". Fix that.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Fixes: def23aa7e9 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings")
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej.skrabec@siol.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 98fd5c723730f560e5bea919a64ac5b83d45eb72 upstream.
When we send PDU data, we want to optimize the tcp stack
operation if we have more data to send. So when we set MSG_MORE
when:
- We have more fragments coming in the batch, or
- We have a more data to send in this PDU
- We don't have a data digest trailer
- We optimize with the SUCCESS flag and omit the NVMe completion
(used if sq_head pointer update is disabled)
This addresses a regression in QD=1 with SUCCESS flag optimization
as we unconditionally set MSG_MORE when we didn't actually have
more data to send.
Fixes: 7058329538 ("nvmet-tcp: implement C2HData SUCCESS optimization")
Reported-by: Mark Wunderlich <mark.wunderlich@intel.com>
Tested-by: Mark Wunderlich <mark.wunderlich@intel.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f50b7dacccbab2b9e3ef18f52a6dcc18ed2050b9 upstream.
On a system configured to trigger a crash_kexec() reboot, when only one CPU
is online and another CPU panics while starting-up, crash_smp_send_stop()
will fail to send any STOP message to the other already online core,
resulting in fail to freeze and registers not properly saved.
Moreover even if the proper messages are sent (case CPUs > 2)
it will similarly fail to account for the booting CPU when executing
the final stop wait-loop, so potentially resulting in some CPU not
been waited for shutdown before rebooting.
A tangible effect of this behaviour can be observed when, after a panic
with kexec enabled and loaded, on the following reboot triggered by kexec,
the cpu that could not be successfully stopped fails to come back online:
[ 362.291022] ------------[ cut here ]------------
[ 362.291525] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
[ 362.292023] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 362.292400] Modules linked in:
[ 362.292970] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted 5.6.0-rc4-00003-gc780b890948a #105
[ 362.293136] Hardware name: Foundation-v8A (DT)
[ 362.293382] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
[ 362.294063] pc : has_cpuid_feature+0xf0/0x348
[ 362.294177] lr : verify_local_elf_hwcaps+0x84/0xe8
[ 362.294280] sp : ffff800011b1bf60
[ 362.294362] x29: ffff800011b1bf60 x28: 0000000000000000
[ 362.294534] x27: 0000000000000000 x26: 0000000000000000
[ 362.294631] x25: 0000000000000000 x24: ffff80001189a25c
[ 362.294718] x23: 0000000000000000 x22: 0000000000000000
[ 362.294803] x21: ffff8000114aa018 x20: ffff800011156a00
[ 362.294897] x19: ffff800010c944a0 x18: 0000000000000004
[ 362.294987] x17: 0000000000000000 x16: 0000000000000000
[ 362.295073] x15: 00004e53b831ae3c x14: 00004e53b831ae3c
[ 362.295165] x13: 0000000000000384 x12: 0000000000000000
[ 362.295251] x11: 0000000000000000 x10: 00400032b5503510
[ 362.295334] x9 : 0000000000000000 x8 : ffff800010c7e204
[ 362.295426] x7 : 00000000410fd0f0 x6 : 0000000000000001
[ 362.295508] x5 : 00000000410fd0f0 x4 : 0000000000000000
[ 362.295592] x3 : 0000000000000000 x2 : ffff8000100939d8
[ 362.295683] x1 : 0000000000180420 x0 : 0000000000180480
[ 362.296011] Call trace:
[ 362.296257] has_cpuid_feature+0xf0/0x348
[ 362.296350] verify_local_elf_hwcaps+0x84/0xe8
[ 362.296424] check_local_cpu_capabilities+0x44/0x128
[ 362.296497] secondary_start_kernel+0xf4/0x188
[ 362.296998] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
[ 362.298652] SMP: stopping secondary CPUs
[ 362.300615] Starting crashdump kernel...
[ 362.301168] Bye!
[ 0.000000] Booting Linux on physical CPU 0x0000000003 [0x410fd0f0]
[ 0.000000] Linux version 5.6.0-rc4-00003-gc780b890948a (crimar01@e120937-lin) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #105 SMP PREEMPT Fri Mar 6 17:00:42 GMT 2020
[ 0.000000] Machine model: Foundation-v8A
[ 0.000000] earlycon: pl11 at MMIO 0x000000001c090000 (options '')
[ 0.000000] printk: bootconsole [pl11] enabled
.....
[ 0.138024] rcu: Hierarchical SRCU implementation.
[ 0.153472] its@2f020000: unable to locate ITS domain
[ 0.154078] its@2f020000: Unable to locate ITS domain
[ 0.157541] EFI services will not be available.
[ 0.175395] smp: Bringing up secondary CPUs ...
[ 0.209182] psci: failed to boot CPU1 (-22)
[ 0.209377] CPU1: failed to boot: -22
[ 0.274598] Detected PIPT I-cache on CPU2
[ 0.278707] GICv3: CPU2: found redistributor 1 region 0:0x000000002f120000
[ 0.285212] CPU2: Booted secondary processor 0x0000000001 [0x410fd0f0]
[ 0.369053] Detected PIPT I-cache on CPU3
[ 0.372947] GICv3: CPU3: found redistributor 2 region 0:0x000000002f140000
[ 0.378664] CPU3: Booted secondary processor 0x0000000002 [0x410fd0f0]
[ 0.401707] smp: Brought up 1 node, 3 CPUs
[ 0.404057] SMP: Total of 3 processors activated.
Make crash_smp_send_stop() account also for the online status of the
calling CPU while evaluating how many CPUs are effectively online: this way
the right number of STOPs is sent and all other stopped-cores's registers
are properly saved.
Fixes: 78fd584cde ("arm64: kdump: implement machine_crash_shutdown()")
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3b36b13d5e69d6f51ff1c55d1b404a74646c9757 upstream.
Commit 317d931392 ("ALSA: hda/realtek - Set default power save node to
0") makes the ALC225 have pop noise on S3 resume and cold boot.
So partially revert this commit for ALC225 to fix the regression.
Fixes: 317d931392 ("ALSA: hda/realtek - Set default power save node to 0")
BugLink: https://bugs.launchpad.net/bugs/1866357
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200311061328.17614-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8d67743653dce5a0e7aa500fcccb237cde7ad88e upstream.
The recent futex inode life time fix changed the ordering of the futex key
union struct members, but forgot to adjust the hash function accordingly,
As a result the hashing omits the leading 64bit and even hashes beyond the
futex key causing a bad hash distribution which led to a ~100% performance
regression.
Hand in the futex key pointer instead of a random struct member and make
the size calculation based of the struct offset.
Fixes: 8019ad13ef7f ("futex: Fix inode life-time issue")
Reported-by: Rong Chen <rong.a.chen@intel.com>
Decoded-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Rong Chen <rong.a.chen@intel.com>
Link: https://lkml.kernel.org/r/87h7yy90ve.fsf@nanos.tec.linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8019ad13ef7f64be44d4f892af9c840179009254 upstream.
As reported by Jann, ihold() does not in fact guarantee inode
persistence. And instead of making it so, replace the usage of inode
pointers with a per boot, machine wide, unique inode identifier.
This sequence number is global, but shared (file backed) futexes are
rare enough that this should not become a performance issue.
Reported-by: Jann Horn <jannh@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 763802b53a427ed3cbd419dbba255c414fdd9e7c upstream.
Commit 3f8fd02b1b ("mm/vmalloc: Sync unmappings in
__purge_vmap_area_lazy()") introduced a call to vmalloc_sync_all() in
the vunmap() code-path. While this change was necessary to maintain
correctness on x86-32-pae kernels, it also adds additional cycles for
architectures that don't need it.
Specifically on x86-64 with CONFIG_VMAP_STACK=y some people reported
severe performance regressions in micro-benchmarks because it now also
calls the x86-64 implementation of vmalloc_sync_all() on vunmap(). But
the vmalloc_sync_all() implementation on x86-64 is only needed for newly
created mappings.
To avoid the unnecessary work on x86-64 and to gain the performance
back, split up vmalloc_sync_all() into two functions:
* vmalloc_sync_mappings(), and
* vmalloc_sync_unmappings()
Most call-sites to vmalloc_sync_all() only care about new mappings being
synchronized. The only exception is the new call-site added in the
above mentioned commit.
Shile Zhang directed us to a report of an 80% regression in reaim
throughput.
Fixes: 3f8fd02b1b ("mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()")
Reported-by: kernel test robot <oliver.sang@intel.com>
Reported-by: Shile Zhang <shile.zhang@linux.alibaba.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Borislav Petkov <bp@suse.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [GHES]
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20191009124418.8286-1-joro@8bytes.org
Link: https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/4D3JPPHBNOSPFK2KEPC6KGKS6J25AIDB/
Link: http://lkml.kernel.org/r/20191113095530.228959-1-shile.zhang@linux.alibaba.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0715e6c516f106ed553828a671d30ad9a3431536 upstream.
Sachin reports [1] a crash in SLUB __slab_alloc():
BUG: Kernel NULL pointer dereference on read at 0x000073b0
Faulting instruction address: 0xc0000000003d55f4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 19 PID: 1 Comm: systemd Not tainted 5.6.0-rc2-next-20200218-autotest #1
NIP: c0000000003d55f4 LR: c0000000003d5b94 CTR: 0000000000000000
REGS: c0000008b37836d0 TRAP: 0300 Not tainted (5.6.0-rc2-next-20200218-autotest)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24004844 XER: 00000000
CFAR: c00000000000dec4 DAR: 00000000000073b0 DSISR: 40000000 IRQMASK: 1
GPR00: c0000000003d5b94 c0000008b3783960 c00000000155d400 c0000008b301f500
GPR04: 0000000000000dc0 0000000000000002 c0000000003443d8 c0000008bb398620
GPR08: 00000008ba2f0000 0000000000000001 0000000000000000 0000000000000000
GPR12: 0000000024004844 c00000001ec52a00 0000000000000000 0000000000000000
GPR16: c0000008a1b20048 c000000001595898 c000000001750c18 0000000000000002
GPR20: c000000001750c28 c000000001624470 0000000fffffffe0 5deadbeef0000122
GPR24: 0000000000000001 0000000000000dc0 0000000000000002 c0000000003443d8
GPR28: c0000008b301f500 c0000008bb398620 0000000000000000 c00c000002287180
NIP ___slab_alloc+0x1f4/0x760
LR __slab_alloc+0x34/0x60
Call Trace:
___slab_alloc+0x334/0x760 (unreliable)
__slab_alloc+0x34/0x60
__kmalloc_node+0x110/0x490
kvmalloc_node+0x58/0x110
mem_cgroup_css_online+0x108/0x270
online_css+0x48/0xd0
cgroup_apply_control_enable+0x2ec/0x4d0
cgroup_mkdir+0x228/0x5f0
kernfs_iop_mkdir+0x90/0xf0
vfs_mkdir+0x110/0x230
do_mkdirat+0xb0/0x1a0
system_call+0x5c/0x68
This is a PowerPC platform with following NUMA topology:
available: 2 nodes (0-1)
node 0 cpus:
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 35247 MB
node 1 free: 30907 MB
node distances:
node 0 1
0: 10 40
1: 40 10
possible numa nodes: 0-31
This only happens with a mmotm patch "mm/memcontrol.c: allocate
shrinker_map on appropriate NUMA node" [2] which effectively calls
kmalloc_node for each possible node. SLUB however only allocates
kmem_cache_node on online N_NORMAL_MEMORY nodes, and relies on
node_to_mem_node to return such valid node for other nodes since commit
a561ce00b0 ("slub: fall back to node_to_mem_node() node if allocating
on memoryless node"). This is however not true in this configuration
where the _node_numa_mem_ array is not initialized for nodes 0 and 2-31,
thus it contains zeroes and get_partial() ends up accessing
non-allocated kmem_cache_node.
A related issue was reported by Bharata (originally by Ramachandran) [3]
where a similar PowerPC configuration, but with mainline kernel without
patch [2] ends up allocating large amounts of pages by kmalloc-1k
kmalloc-512. This seems to have the same underlying issue with
node_to_mem_node() not behaving as expected, and might probably also
lead to an infinite loop with CONFIG_SLUB_CPU_PARTIAL [4].
This patch should fix both issues by not relying on node_to_mem_node()
anymore and instead simply falling back to NUMA_NO_NODE, when
kmalloc_node(node) is attempted for a node that's not online, or has no
usable memory. The "usable memory" condition is also changed from
node_present_pages() to N_NORMAL_MEMORY node state, as that is exactly
the condition that SLUB uses to allocate kmem_cache_node structures.
The check in get_partial() is removed completely, as the checks in
___slab_alloc() are now sufficient to prevent get_partial() being
reached with an invalid node.
[1] https://lore.kernel.org/linux-next/3381CD91-AB3D-4773-BA04-E7A072A63968@linux.vnet.ibm.com/
[2] https://lore.kernel.org/linux-mm/fff0e636-4c36-ed10-281c-8cdb0687c839@virtuozzo.com/
[3] https://lore.kernel.org/linux-mm/20200317092624.GB22538@in.ibm.com/
[4] https://lore.kernel.org/linux-mm/088b5996-faae-8a56-ef9c-5b567125ae54@suse.cz/
Fixes: a561ce00b0 ("slub: fall back to node_to_mem_node() node if allocating on memoryless node")
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Reported-by: PUVICHAKRAVARTHY RAMACHANDRAN <puvichakravarthy@in.ibm.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Tested-by: Bharata B Rao <bharata@linux.ibm.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Christopher Lameter <cl@linux.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200320115533.9604-1-vbabka@suse.cz
Debugged-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5076190daded2197f62fe92cf69674488be44175 upstream.
This is just a cleanup addition to Jann's fix to properly update the
transaction ID for the slub slowpath in commit fd4d9c7d0c71 ("mm: slub:
add missing TID bump..").
The transaction ID is what protects us against any concurrent accesses,
but we should really also make sure to make the 'freelist' comparison
itself always use the same freelist value that we then used as the new
next free pointer.
Jann points out that if we do all of this carefully, we could skip the
transaction ID update for all the paths that only remove entries from
the lists, and only update the TID when adding entries (to avoid the ABA
issue with cmpxchg and list handling re-adding a previously seen value).
But this patch just does the "make sure to cmpxchg the same value we
used" rather than then try to be clever.
Acked-by: Jann Horn <jannh@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b53734bd0b2feed8e7761771b2e76fc9126ea0c upstream.
This fixes possible lost wakeup introduced by commit a218cc4914.
Originally modifications to ep->wq were serialized by ep->wq.lock, but
in commit a218cc4914 ("epoll: use rwlock in order to reduce
ep_poll_callback() contention") a new rw lock was introduced in order to
relax fd event path, i.e. callers of ep_poll_callback() function.
After the change ep_modify and ep_insert (both are called on epoll_ctl()
path) were switched to ep->lock, but ep_poll (epoll_wait) was using
ep->wq.lock on wqueue list modification.
The bug doesn't lead to any wqueue list corruptions, because wake up
path and list modifications were serialized by ep->wq.lock internally,
but actual waitqueue_active() check prior wake_up() call can be
reordered with modifications of ep ready list, thus wake up can be lost.
And yes, can be healed by explicit smp_mb():
list_add_tail(&epi->rdlink, &ep->rdllist);
smp_mb();
if (waitqueue_active(&ep->wq))
wake_up(&ep->wp);
But let's make it simple, thus current patch replaces ep->wq.lock with
the ep->lock for wqueue modifications, thus wake up path always observes
activeness of the wqueue correcty.
Fixes: a218cc4914 ("epoll: use rwlock in order to reduce ep_poll_callback() contention")
Reported-by: Max Neunhoeffer <max@arangodb.com>
Signed-off-by: Roman Penyaev <rpenyaev@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Max Neunhoeffer <max@arangodb.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Christopher Kohlhoff <chris.kohlhoff@clearpool.io>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jes Sorensen <jes.sorensen@gmail.com>
Cc: <stable@vger.kernel.org> [5.1+]
Link: http://lkml.kernel.org/r/20200214170211.561524-1-rpenyaev@suse.de
References: https://bugzilla.kernel.org/show_bug.cgi?id=205933
Bisected-by: Max Neunhoeffer <max@arangodb.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 12e967fd8e4e6c3d275b4c69c890adc838891300 upstream.
Jann has brought up a very interesting point [1]. While shared pages
are excluded from MADV_PAGEOUT normally, CoW pages can be easily
reclaimed that way. This can lead to all sorts of hard to debug
problems. E.g. performance problems outlined by Daniel [2].
There are runtime environments where there is a substantial memory
shared among security domains via CoW memory and a easy to reclaim way
of that memory, which MADV_{COLD,PAGEOUT} offers, can lead to either
performance degradation in for the parent process which might be more
privileged or even open side channel attacks.
The feasibility of the latter is not really clear to me TBH but there is
no real reason for exposure at this stage. It seems there is no real
use case to depend on reclaiming CoW memory via madvise at this stage so
it is much easier to simply disallow it and this is what this patch
does. Put it simply MADV_{PAGEOUT,COLD} can operate only on the
exclusively owned memory which is a straightforward semantic.
[1] http://lkml.kernel.org/r/CAG48ez0G3JkMq61gUmyQAaCq=_TwHbi1XKzWRooxZkv08PQKuw@mail.gmail.com
[2] http://lkml.kernel.org/r/CAKOZueua_v8jHCpmEtTB6f3i9e2YnmX4mqdYVWhV4E=Z-n+zRQ@mail.gmail.com
Fixes: 9c276cc65a ("mm: introduce MADV_COLD")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Daniel Colascione <dancol@google.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: "Joel Fernandes (Google)" <joel@joelfernandes.org>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200312082248.GS23944@dhcp22.suse.cz
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d41e2f3bd54699f85b3d6f45abd09fa24a222cb9 upstream.
In section_deactivate(), pfn_to_page() doesn't work any more after
ms->section_mem_map is resetting to NULL in SPARSEMEM|!VMEMMAP case. It
causes a hot remove failure:
kernel BUG at mm/page_alloc.c:4806!
invalid opcode: 0000 [#1] SMP PTI
CPU: 3 PID: 8 Comm: kworker/u16:0 Tainted: G W 5.5.0-next-20200205+ #340
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
Workqueue: kacpi_hotplug acpi_hotplug_work_fn
RIP: 0010:free_pages+0x85/0xa0
Call Trace:
__remove_pages+0x99/0xc0
arch_remove_memory+0x23/0x4d
try_remove_memory+0xc8/0x130
__remove_memory+0xa/0x11
acpi_memory_device_remove+0x72/0x100
acpi_bus_trim+0x55/0x90
acpi_device_hotplug+0x2eb/0x3d0
acpi_hotplug_work_fn+0x1a/0x30
process_one_work+0x1a7/0x370
worker_thread+0x30/0x380
kthread+0x112/0x130
ret_from_fork+0x35/0x40
Let's move the ->section_mem_map resetting after
depopulate_section_memmap() to fix it.
[akpm@linux-foundation.org: remove unneeded initialization, per David]
Fixes: ba72b4c8cf ("mm/sparsemem: support sub-section hotplug")
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200307084229.28251-2-bhe@redhat.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e26733e0d0ec6798eca93daa300bc3f43616127f upstream.
Prior to this commit, we only directly check the affected cgroup's
memory.high against its usage. However, it's possible that we are being
reclaimed as a result of hitting an ancestor memory.high and should be
penalised based on that, instead.
This patch changes memory.high overage throttling to use the largest
overage in its ancestors when considering how many penalty jiffies to
charge. This makes sure that we penalise poorly behaving cgroups in the
same way regardless of at what level of the hierarchy memory.high was
breached.
Fixes: 0e4b01df86 ("mm, memcg: throttle allocators when failing reclaim over memory.high")
Reported-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: Roman Gushchin <guro@fb.com>
Cc: <stable@vger.kernel.org> [5.4.x+]
Link: http://lkml.kernel.org/r/8cd132f84bd7e16cdb8fde3378cdbf05ba00d387.1584036142.git.chris@chrisdown.name
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d397a45fc741c80c32a14e2de008441e9976f50c upstream.
Commit 0e4b01df86 had a bunch of fixups to use the right division
method. However, it seems that after all that it still wasn't right --
div_u64 takes a 32-bit divisor.
The headroom is still large (2^32 pages), so on mundane systems you
won't hit this, but this should definitely be fixed.
Fixes: 0e4b01df86 ("mm, memcg: throttle allocators when failing reclaim over memory.high")
Reported-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: <stable@vger.kernel.org> [5.4.x+]
Link: http://lkml.kernel.org/r/80780887060514967d414b3cd91f9a316a16ab98.1584036142.git.chris@chrisdown.name
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7d36665a5886c27ca4c4d0afd3ecc50b400f3587 upstream.
An eventfd monitors multiple memory thresholds of the cgroup, closes them,
the kernel deletes all events related to this eventfd. Before all events
are deleted, another eventfd monitors the memory threshold of this cgroup,
leading to a crash:
BUG: kernel NULL pointer dereference, address: 0000000000000004
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 800000033058e067 P4D 800000033058e067 PUD 3355ce067 PMD 0
Oops: 0002 [#1] SMP PTI
CPU: 2 PID: 14012 Comm: kworker/2:6 Kdump: loaded Not tainted 5.6.0-rc4 #3
Hardware name: LENOVO 20AWS01K00/20AWS01K00, BIOS GLET70WW (2.24 ) 05/21/2014
Workqueue: events memcg_event_remove
RIP: 0010:__mem_cgroup_usage_unregister_event+0xb3/0x190
RSP: 0018:ffffb47e01c4fe18 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff8bb223a8a000 RCX: 0000000000000001
RDX: 0000000000000001 RSI: ffff8bb22fb83540 RDI: 0000000000000001
RBP: ffffb47e01c4fe48 R08: 0000000000000000 R09: 0000000000000010
R10: 000000000000000c R11: 071c71c71c71c71c R12: ffff8bb226aba880
R13: ffff8bb223a8a480 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8bb242680000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 000000032c29c003 CR4: 00000000001606e0
Call Trace:
memcg_event_remove+0x32/0x90
process_one_work+0x172/0x380
worker_thread+0x49/0x3f0
kthread+0xf8/0x130
ret_from_fork+0x35/0x40
CR2: 0000000000000004
We can reproduce this problem in the following ways:
1. We create a new cgroup subdirectory and a new eventfd, and then we
monitor multiple memory thresholds of the cgroup through this eventfd.
2. closing this eventfd, and __mem_cgroup_usage_unregister_event ()
will be called multiple times to delete all events related to this
eventfd.
The first time __mem_cgroup_usage_unregister_event() is called, the
kernel will clear all items related to this eventfd in thresholds->
primary.
Since there is currently only one eventfd, thresholds-> primary becomes
empty, so the kernel will set thresholds-> primary and hresholds-> spare
to NULL. If at this time, the user creates a new eventfd and monitor
the memory threshold of this cgroup, kernel will re-initialize
thresholds-> primary.
Then when __mem_cgroup_usage_unregister_event () is called for the
second time, because thresholds-> primary is not empty, the system will
access thresholds-> spare, but thresholds-> spare is NULL, which will
trigger a crash.
In general, the longer it takes to delete all events related to this
eventfd, the easier it is to trigger this problem.
The solution is to check whether the thresholds associated with the
eventfd has been cleared when deleting the event. If so, we do nothing.
[akpm@linux-foundation.org: fix comment, per Kirill]
Fixes: 907860ed38 ("cgroups: make cftype.unregister_event() void-returning")
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/077a6f67-aefa-4591-efec-f2f3af2b0b02@gmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 283f87c0d5d32b4a5c22636adc559bca82196ed3 upstream.
The operands of time_after() are in a wrong order in both instances in
the sys-t driver. Fix that.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Fixes: 39f10239df ("stm class: p_sys-t: Add support for CLOCKSYNC packets")
Fixes: d69d5e8311 ("stm class: Add MIPI SyS-T protocol support")
Cc: stable@vger.kernel.org # v4.20+
Link: https://lore.kernel.org/r/20200317062215.15598-3-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5bbc6604a62814511c32f2e39bc9ffb2c1b92cbe upstream.
The offset into the array was specified in bytes but should
be in terms of 32-bit words. Also prevent large reads that
would also cause a buffer overread.
v2: Read from correct offset from internal storage buffer.
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 236ebc20d9afc5e9ff52f3cf3f365a91583aac10 upstream.
During a rename whiteout, if btrfs_whiteout_for_rename() returns an error
we can end up returning from btrfs_rename() with the log context object
still in the root's log context list - this happens if 'sync_log' was
set to true before we called btrfs_whiteout_for_rename() and it is
dangerous because we end up with a corrupt linked list (root->log_ctxs)
as the log context object was allocated on the stack.
After btrfs_rename() returns, any task that is running btrfs_sync_log()
concurrently can end up crashing because that linked list is traversed by
btrfs_sync_log() (through btrfs_remove_all_log_ctxs()). That results in
the same issue that commit e6c617102c ("Btrfs: fix log context list
corruption after rename exchange operation") fixed.
Fixes: d4682ba03e ("Btrfs: sync log after logging new name")
CC: stable@vger.kernel.org # 4.19+
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>
commit 045706bff837ee89c13f1ace173db71922c1c40b upstream.
libtraceevent (used by perf and trace-cmd) failed to parse the
xhci_urb_dequeue trace event. This is because the user space trace
event format parsing is not a full C compiler. It can handle some basic
logic, but is not meant to be able to handle everything C can do.
In cases where a trace event field needs to be converted from a number
to a string, there's the __print_symbolic() macro that should be used:
See samples/trace_events/trace-events-sample.h
Some xhci trace events open coded the __print_symbolic() causing the
user spaces tools to fail to parse it. This has to be replaced with
__print_symbolic() instead.
CC: stable@vger.kernel.org
Reported-by: Tzvetomir Stoyanov <tstoyanov@vmware.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206531
Fixes: 5abdc2e6e1 ("usb: host: xhci: add urb_enqueue/dequeue/giveback tracers")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200306150858.21904-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3568b88944fef28db3ee989b957da49ffc627ede upstream.
The syscall number of compat_clock_getres was erroneously set to 247
(__NR_io_cancel!) instead of 264. This causes the vDSO fallback of
clock_getres() to land on the wrong syscall for compat tasks.
Fix the numbering.
Cc: <stable@vger.kernel.org>
Fixes: 53c489e1df ("arm64: compat: Add missing syscall numbers")
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5190044c2965514a973184ca68ef5fad57a24670 upstream.
In order to preserve backwards compatability with kmod tools, we have to
move the namespace field in Module.symvers last, as the depmod -e -E
option looks at the first three fields in Module.symvers to check symbol
versions (and it's expected they stay in the original order of crc,
symbol, module).
In addition, update an ancient comment above read_dump() in modpost that
suggested that the export type field in Module.symvers was optional. I
suspect that there were historical reasons behind that comment that are
no longer accurate. We have been unconditionally printing the export
type since 2.6.18 (commit bd5cbcedf4), which is over a decade ago now.
Fix up read_dump() to treat each field as non-optional. I suspect the
original read_dump() code treated the export field as optional in order
to support pre <= 2.6.18 Module.symvers (which did not have the export
type field). Note that although symbol namespaces are optional, the
field will not be omitted from Module.symvers if a symbol does not have
a namespace. In this case, the field will simply be empty and the next
delimiter or end of line will follow.
Cc: stable@vger.kernel.org
Fixes: cb9b55d21f ("modpost: add support for symbol namespaces")
Tested-by: Matthias Maennich <maennich@google.com>
Reviewed-by: Matthias Maennich <maennich@google.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jessica Yu <jeyu@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit add492d2e9446a77ede9bb43699ec85ca8fc1aba upstream.
This adds support for the Trace Hub in Elkhart Lake CPU.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200317062215.15598-7-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
