| Age | Commit message (Collapse) | Author |
|---|
|
If buf[-1] just happens to hold the byte 0x0A, then nread can wrap around
to (size_t)-1, leading to invalid memory accesses.
This has caused segmentation faults when trying to build the latest
kernel snapshots for i686 in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1592374
Signed-off-by: Jerry James <loganjerry@gmail.com>
[alexpl@fedoraproject.org: reformatted patch for submission]
Signed-off-by: Alexander Ploumistos <alexpl@fedoraproject.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Since commit 5d20ee3192a5 ("kbuild: Allow LD_DEAD_CODE_DATA_ELIMINATION
to be selectable if enabled"), HAVE_LD_DEAD_CODE_DATA_ELIMINATION is
supposed to be selected by architectures that are capable of this
functionality. LD_DEAD_CODE_DATA_ELIMINATION is now users' selection.
Update the help message.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Each symbol has a property of type P_SYMBOL since commit
59e89e3ddf85 (kconfig: save location of config symbols).
Handle those properties in print_symbol().
Further, place a pointer to print_symbol() in the comment above the
list of known property type.
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
KMSAN reported an infoleak when reading from /dev/vcs*:
BUG: KMSAN: kernel-infoleak in vcs_read+0x18ba/0x1cc0
Call Trace:
...
kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1253
copy_to_user ./include/linux/uaccess.h:184
vcs_read+0x18ba/0x1cc0 drivers/tty/vt/vc_screen.c:352
__vfs_read+0x1b2/0x9d0 fs/read_write.c:416
vfs_read+0x36c/0x6b0 fs/read_write.c:452
...
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
__kmalloc+0x13a/0x350 mm/slub.c:3818
kmalloc ./include/linux/slab.h:517
vc_allocate+0x438/0x800 drivers/tty/vt/vt.c:787
con_install+0x8c/0x640 drivers/tty/vt/vt.c:2880
tty_driver_install_tty drivers/tty/tty_io.c:1224
tty_init_dev+0x1b5/0x1020 drivers/tty/tty_io.c:1324
tty_open_by_driver drivers/tty/tty_io.c:1959
tty_open+0x17b4/0x2ed0 drivers/tty/tty_io.c:2007
chrdev_open+0xc25/0xd90 fs/char_dev.c:417
do_dentry_open+0xccc/0x1440 fs/open.c:794
vfs_open+0x1b6/0x2f0 fs/open.c:908
...
Bytes 0-79 of 240 are uninitialized
Consistently allocating |vc_screenbuf| with kzalloc() fixes the problem
Reported-by: syzbot+17a8efdf800000@syzkaller.appspotmail.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Make sure to free all resources associated with the ida on module
exit.
Fixes: cd6484e1830b ("serdev: Introduce new bus for serial attached devices")
Cc: stable <stable@vger.kernel.org> # 4.11
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
After the commit
7d8905d06405 ("serial: 8250_pci: Enable device after we check black list")
pure serial multi-port cards, such as CH355, got blacklisted and thus
not being enumerated anymore. Previously, it seems, blacklisting them
was on purpose to shut up pciserial_init_one() about record duplication.
So, remove the entries from blacklist in order to get cards enumerated.
Fixes: 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list")
Reported-by: Matt Turner <mattst88@gmail.com>
Cc: Sergej Pupykin <ml@sergej.pp.ru>
Cc: Alexandr Petrenko <petrenkoas83@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-and-Tested-by: Matt Turner <mattst88@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
syzbot is reporting stalls at __process_echoes() [1]. This is because
since ldata->echo_commit < ldata->echo_tail becomes true for some reason,
the discard loop is serving as almost infinite loop. This patch tries to
avoid falling into ldata->echo_commit < ldata->echo_tail situation by
making access to echo_* variables more carefully.
Since reset_buffer_flags() is called without output_lock held, it should
not touch echo_* variables. And omit a call to reset_buffer_flags() from
n_tty_open() by using vzalloc().
Since add_echo_byte() is called without output_lock held, it needs memory
barrier between storing into echo_buf[] and incrementing echo_head counter.
echo_buf() needs corresponding memory barrier before reading echo_buf[].
Lack of handling the possibility of not-yet-stored multi-byte operation
might be the reason of falling into ldata->echo_commit < ldata->echo_tail
situation, for if I do WARN_ON(ldata->echo_commit == tail + 1) prior to
echo_buf(ldata, tail + 1), the WARN_ON() fires.
Also, explicitly masking with buffer for the former "while" loop, and
use ldata->echo_commit > tail for the latter "while" loop.
[1] https://syzkaller.appspot.com/bug?id=17f23b094cd80df750e5b0f8982c521ee6bcbf40
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+108696293d7a21ab688f@syzkaller.appspotmail.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
syzbot is reporting stalls at n_tty_receive_char_special() [1]. This is
because comparison is not working as expected since ldata->read_head can
change at any moment. Mitigate this by explicitly masking with buffer size
when checking condition for "while" loops.
[1] https://syzkaller.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+18df353d7540aa6b5467@syzkaller.appspotmail.com>
Fixes: bc5a5e3f45d04784 ("n_tty: Don't wrap input buffer indices at buffer size")
Cc: stable <stable@vger.kernel.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
For architectures that do not use per-device dma ops we need to export
the dma_map_ops structure returned from get_arch_dma_ops().
Fixes: 10314e09 ("riscv: add swiotlb support")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Andreas Schwab <schwab@suse.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial fixes for v4.18-rc3
Here are bunch of new device ids for cp210x.
All have been in linux-next with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
If a power failure happens while the qgroup rescan kthread is running,
the next mount operation will always fail. This is because of a recent
regression that makes qgroup_rescan_init() incorrectly return -EINVAL
when we are mounting the filesystem (through btrfs_read_qgroup_config()).
This causes the -EINVAL error to be returned regardless of any qgroup
flags being set instead of returning the error only when neither of
the flags BTRFS_QGROUP_STATUS_FLAG_RESCAN nor BTRFS_QGROUP_STATUS_FLAG_ON
are set.
A test case for fstests follows up soon.
Fixes: 9593bf49675e ("btrfs: qgroup: show more meaningful qgroup_rescan_init error message")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
|
|
The vm_fault_t conversion commit introduced a ret2 variable for tracking
the integer return values from internal btrfs functions. It was
sometimes returning VM_FAULT_LOCKED for pages that were actually invalid
and had been removed from the radix. Something like this:
ret2 = btrfs_delalloc_reserve_space() // returns zero on success
lock_page(page)
if (page->mapping != inode->i_mapping)
goto out_unlock;
...
out_unlock:
if (!ret2) {
...
return VM_FAULT_LOCKED;
}
This ends up triggering this WARNING in btrfs_destroy_inode()
WARN_ON(BTRFS_I(inode)->block_rsv.size);
xfstests generic/095 was able to reliably reproduce the errors.
Since out_unlock: is only used for errors, this fix moves it below the
if (!ret2) check we use to return VM_FAULT_LOCKED for success.
Fixes: a528a2415087 (btrfs: change return type of btrfs_page_mkwrite to vm_fault_t)
Signed-off-by: Chris Mason <clm@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
|
|
Commit ff3d27a048d9 ("btrfs: qgroup: Finish rescan when hit the last leaf
of extent tree") added a new exit for rescan finish.
However after finishing quota rescan, we set
fs_info->qgroup_rescan_progress to (u64)-1 before we exit through the
original exit path.
While we missed that assignment of (u64)-1 in the new exit path.
The end result is, the quota status item doesn't have the same value.
(-1 vs the last bytenr + 1)
Although it doesn't affect quota accounting, it's still better to keep
the original behavior.
Reported-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Fixes: ff3d27a048d9 ("btrfs: qgroup: Finish rescan when hit the last leaf of extent tree")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
|
|
into drm-fixes
Single amdgpu regression fix for stable.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180622203002.26883-1-alexander.deucher@amd.com
|
|
into drm-fixes
Misc set of malidp fixes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180622144444.GD2037@e110455-lin.cambridge.arm.com
|
|
kmemleak reported some memory leak on reading proc files. After adding
some debug lines, find that proc_seq_fops is using seq_release as
release handler, which won't handle the free of 'private' field of
seq_file, while in fact the open handler proc_seq_open could create
the private data with __seq_open_private when state_size is greater
than zero. So after reading files created with proc_create_seq_private,
such as /proc/timer_list and /proc/vmallocinfo, the private mem of a
seq_file is not freed. Fix it by adding the paired proc_seq_release
as the default release handler of proc_seq_ops instead of seq_release.
Fixes: 44414d82cfe0 ("proc: introduce proc_create_seq_private")
Reviewed-by: Christoph Hellwig <hch@lst.de>
CC: Christoph Hellwig <hch@lst.de>
Signed-off-by: Chunyu Hu <chuhu@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
meson-gxl-mali.dtsi is only used on GXL SoCs. Thus it should use the GXL
specific compatible string instead of the GXBB one.
For now this is purely cosmetic since the (out-of-tree) lima driver for
this GPU currently uses the "arm,mali-450" match instead of the SoC
specific one. However, update the .dts to match the documentation since
this driver behavior might change in the future.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
|
|
Like the odroid-c2 and wetek, the s400 uses the RTL8211F and seems to
suffer from the kind of stability issue.
Doing an iperf3 download test, we can see a significant number of LPI
interrupts on the tx path. After a short while (5 to 15 seconds), the
network connection dies. If using rootfs over NFS, the connection may
also break during the boot sequence.
We still don't have a real explanation for this problem so let's disable
EEE once again.
Fixes: f6f6ac914b82 ("ARM64: dts: meson-axg: enable ethernet for A113D S400 board")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
|
|
Vendor firmware/uboot has different reserved regions depending on
firmware version, but current codebase reserves the same regions on
GXL and GXBB, so move the additional reserved memory region to common
.dtsi.
Found when putting a recent vendor u-boot on meson-gxbb-p200.
Suggested-by: Neil Armstrong <narmstrong@baylibre.com>
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
|
|
Like LibreTech-CC, the USB0 needs the 5V regulator to be enabled to power the
devices on the P212 Reference Design based boards.
Fixes: b9f07cb4f41f ("ARM64: dts: meson-gxl-s905x-p212: enable the USB controller")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
|
|
Based on updated information from Amlogic, correct the register range
for the SD/eMMC blocks to the right size.
Reported-by: Yixun Lan <yixun.lan@amlogic.com>
Tested-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
|
|
There is a problem with the sd-uhs mode when doing a soft reboot.
Switching back from 1.8v to 3.3v messes with the card, which no longer
respond (timeout errors). According to the specification, we should
perform a card reset (power cycling the card) but this is something we
cannot control on this design.
Then the only solution to restore the communication with the card is an
"unplug-plug" which is not acceptable
Until we find a solution, if any, disable the sd-uhs modes on this design.
For the people using uhs at the moment, there will a performance drop as
a result.
Fixes: 3cde63ebc85c ("ARM64: dts: meson-gxl: libretech-cc: enable high speed modes")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
|
|
Currently, amdgpu_do_flip() spinlocks crtc->dev->event_lock and
releases it only after committing updates to the stream.
dc_commit_updates_for_stream() should be moved out of
spinlock for the below reasons:
1. event_lock is supposed to protect access to acrct->pflip_status _only_
2. dc_commit_updates_for_stream() has potential sleep's
and also its not appropriate to be in an atomic state
for such long sequences of code.
Signed-off-by: Shirish S <shirish.s@amd.com>
Suggested-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Support new VCN FW version naming convention:
[31, 28] for VEP interface major version if applicable
[27, 24] for decode interface major version
[23, 20] for encode interface major version
[19, 12] for encode interface minor version
[11, 0] for firmware revision
Bit 20-23, it is encode major and non-zero for new naming convention.
This field is part of version minor and DRM_DISABLED_FLAG in old naming
convention. Since the latest version minor is 0x5B and DRM_DISABLED_FLAG
is zero in old naming convention, this field is always zero so far.
These four bits are used to tell which naming convention is present.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Fang, Peter <Peter.Fang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Here is the UBSAN dump:
[ 3.866656] index 2 is out of range for type 'amdgpu_uvd_inst [2]'
[ 3.866693] Workqueue: events work_for_cpu_fn
[ 3.866702] Call Trace:
[ 3.866710] dump_stack+0x85/0xc5
[ 3.866719] ubsan_epilogue+0x9/0x40
[ 3.866727] __ubsan_handle_out_of_bounds+0x89/0x90
[ 3.866737] ? rcu_read_lock_sched_held+0x58/0x60
[ 3.866746] ? __kmalloc+0x26c/0x2d0
[ 3.866846] amdgpu_fence_driver_start_ring+0x259/0x280 [amdgpu]
[ 3.866896] amdgpu_ring_init+0x12c/0x710 [amdgpu]
[ 3.866906] ? sprintf+0x42/0x50
[ 3.866956] amdgpu_gfx_kiq_init_ring+0x1bc/0x3a0 [amdgpu]
[ 3.867009] gfx_v8_0_sw_init+0x1ad3/0x2360 [amdgpu]
[ 3.867062] ? smu7_init+0xec/0x160 [amdgpu]
[ 3.867109] amdgpu_device_init+0x112c/0x1dc0 [amdgpu]
'ring->me' might be set as 2 with 'amdgpu_gfx_kiq_init_ring', that would
cause out of range for 'amdgpu_uvd_inst[2]'.
v2: simplified with ring type
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Pull xfs fixes from Darrick Wong:
"Here are some patches for 4.18 to fix regressions, accounting
problems, overflow problems, and to strengthen metadata validation to
prevent corruption.
This series has been run through a full xfstests run over the weekend
and through a quick xfstests run against this morning's master, with
no major failures reported.
Changes since last update:
- more metadata validation strengthening to prevent crashes.
- fix extent offset overflow problem when insert_range on a 512b
block fs
- fix some off-by-one errors in the realtime fsmap code
- fix some math errors in the default resblks calculation when free
space is low
- fix a problem where stale page contents are exposed via mmap read
after a zero_range at eof
- fix accounting problems with per-ag reservations causing statfs
reports to vary incorrectly"
* tag 'xfs-4.18-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: fix fdblocks accounting w/ RMAPBT per-AG reservation
xfs: ensure post-EOF zeroing happens after zeroing part of a file
xfs: fix off-by-one error in xfs_rtalloc_query_range
xfs: fix uninitialized field in rtbitmap fsmap backend
xfs: recheck reflink state after grabbing ILOCK_SHARED for a write
xfs: don't allow insert-range to shift extents past the maximum offset
xfs: don't trip over negative free space in xfs_reserve_blocks
xfs: allow empty transactions while frozen
xfs: xfs_iflush_abort() can be called twice on cluster writeback failure
xfs: More robust inode extent count validation
xfs: simplify xfs_bmap_punch_delalloc_range
|
|
Timur Tabi no longer works for Qualcomm, and he now has a kernel.org
email address, so update MAINTAINERS accordingly.
Signed-off-by: Timur Tabi <timur@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Commit 7f0b1bf04511 ("arm64: Fix barriers used for page table modifications")
fixed a reported issue with fixmap page-table entries not being visible
to the walker due to a missing DSB instruction. At the same time, it added
ISB instructions to the arm64 set_{pte,pmd,pud} functions, which are not
required by the architecture and make little sense in isolation.
Remove the redundant ISBs.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
The implementation of flush_icache_range() includes instruction sequences
which are themselves patched at runtime, so it is not safe to call from
the patching framework.
This patch reworks the alternatives cache-flushing code so that it rolls
its own internal D-cache maintenance using DC CIVAC before invalidating
the entire I-cache after all alternatives have been applied at boot.
Modules don't cause any issues, since flush_icache_range() is safe to
call by the time they are loaded.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Rohit Khanna <rokhanna@nvidia.com>
Cc: Alexander Van Brunt <avanbrunt@nvidia.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS build fix from Paul Burton:
"A single build fix for 4.18:
Adjust rseq_signal_deliver() & rseq_handle_notify_resume() calls to
add the ksig argument introduced in v4.18-rc2, around the same time as
the unadjusted MIPS rseq support"
* tag 'mips_fixes_4.18_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: Add ksig argument to rseq_{signal_deliver,handle_notify_resume}
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A handful of fixes, nothing really concerning and most touching
devicetree files for various platforms.
I also regenerated the shared multiplatform defconfigs; they have
drifted quite a bit due to Kconfig changes and reordering, and several
platform maintainers tried doing the same which resulted in a lot of
conflict pain -- this way we get everybody onto the same base for next
merge window"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits)
arm64: dts: uniphier: fix widget name of headphone for LD11/LD20 boards
ARM: dts: Fix SPI node for Arria10
arm64: dts: stratix10: Fix SPI nodes for Stratix10
qcom: cmd-db: enforce CONFIG_OF_RESERVED_MEM dependency
ARM: Always build secure_cntvoff.S on ARM V7 to fix shmobile !SMP build
ARM: multi_v7_defconfig: renormalize based on recent additions
arm64: defconfig: renormalize based on recent additions
arm64: dts: msm8916: fix Coresight ETF graph connections
arm64: dts: apq8096-db820c: disable uart0 by default
ARM: dts: imx6sx: fix irq for pcie bridge
arm64: dts: Stingray: Fix I2C controller interrupt type
arm64: dts: ns2: Fix PCIe controller interrupt type
arm64: dts: ns2: Fix I2C controller interrupt type
arm64: dts: specify 1.8V EMMC capabilities for bcm958742t
arm64: dts: specify 1.8V EMMC capabilities for bcm958742k
ARM: dts: Cygnus: Fix PCIe controller interrupt type
ARM: dts: Cygnus: Fix I2C controller interrupt type
ARM: dts: BCM5301x: Fix i2c controller interrupt type
ARM: dts: HR2: Fix interrupt types for i2c and PCIe
ARM: dts: NSP: Fix PCIe controllers interrupt types
...
|
|
Pull microblaze fixes from Michal Simek:
- fix architecture gpio heart beat code
- add new syscalls
- remove unused xlnx,compound handling
- remove platform.c
* tag 'microblaze-v4.18-rc3' of git://git.monstr.eu/linux-2.6-microblaze:
microblaze: consolidate GPIO reset handling
microblaze: remove unecessary of_platform_bus_probe call
microblaze: Add new syscalls io_pgetevents and rseq
microblaze: Remove architecture heart beat code
microblaze: heartbeat: fix missing prom.h include
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Three small bug fixes (barrier elimination, memory leak on unload,
spinlock recursion) and a technical enhancement left over from the
merge window: the TCMU read length support is required for tape
devices read when the length of the read is greater than the tape
block size"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: scsi_debug: Fix memory leak on module unload
scsi: qla2xxx: Spinlock recursion in qla_target
scsi: ipr: Eliminate duplicate barriers
scsi: target: tcmu: add read length support
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input updates from Dmitry Torokhov:
- the main change is a fix for my brain-dead patch to PS/2 button
reporting for some protocols that made it in 4.17
- there is a new driver for Spreadtum vibrator that I intended to send
during merge window but ended up not sending the 2nd pull request.
Given that this is a brand new driver we should not see regressions
here
- a fixup to Elantech PS/2 driver to avoid decoding errors on Thinkpad
P52
- addition of few more ACPI IDs for Silead and Elan drivers
- RMI4 is switched to using IRQ domain code instead of rolling its own
implementation
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: psmouse - fix button reporting for basic protocols
Input: xpad - fix GPD Win 2 controller name
Input: elan_i2c_smbus - fix more potential stack buffer overflows
Input: elan_i2c - add ELAN0618 (Lenovo v330 15IKB) ACPI ID
Input: elantech - fix V4 report decoding for module with middle key
Input: elantech - enable middle button of touchpads on ThinkPad P52
Input: do not assign new tracking ID when changing tool type
Input: make input_report_slot_state() return boolean
Input: synaptics-rmi4 - fix axis-swap behavior
Input: synaptics-rmi4 - fix the error return code in rmi_probe_interrupts()
Input: synaptics-rmi4 - convert irq distribution to irq_domain
Input: silead - add MSSL0002 ACPI HID
Input: goldfish_events - fix checkpatch warnings
Input: add Spreadtrum vibrator driver
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
Pull more security subsystem fixes from James Morris:
"Two further fixes for the keys subsystem"
* 'fixes-v4.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
dh key: fix rounding up KDF output length
certs/blacklist: fix const confusion
|
|
It may not be the actual real stable mailing list address, but the
stable scripts to actually pick up on the traditional way to mark stable
patches.
There are also reasons to explicitly avoid using the actual mailing list
address, since security patches with embargo dates generally do want the
stable marking, but don't want tools etc to mistakenly send the patch
out to the mailing list early.
So don't warn for things that are still actively used and explicitly
supported.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux
* 'perf/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux:
drivers/perf: xgene_pmu: Fix IOB SLOW PMU parser error
|
|
This patch fixes wrong name of headphone widget for receiving events
of insert/remove headphone plug from simple-card or audio-graph-card.
If we use wrong widget name then we get warning messages such as
"asoc-audio-graph-card sound: ASoC: DAPM unknown pin Headphones"
when the plug is inserted or removed from headphone jack.
Fixes: fb21a0acaa2b7 ("arm64: dts: uniphier: add sound node")
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
Discards issued to a DM thin device can complete to userspace (via
fstrim) _before_ the metadata changes associated with the discards is
reflected in the thinp superblock (e.g. free blocks). As such, if a
user constructs a test that loops repeatedly over these steps, block
allocation can fail due to discards not having completed yet:
1) fill thin device via filesystem file
2) remove file
3) fstrim
From initial report, here:
https://www.redhat.com/archives/dm-devel/2018-April/msg00022.html
"The root cause of this issue is that dm-thin will first remove
mapping and increase corresponding blocks' reference count to prevent
them from being reused before DISCARD bios get processed by the
underlying layers. However. increasing blocks' reference count could
also increase the nr_allocated_this_transaction in struct sm_disk
which makes smd->old_ll.nr_allocated +
smd->nr_allocated_this_transaction bigger than smd->old_ll.nr_blocks.
In this case, alloc_data_block() will never commit metadata to reset
the begin pointer of struct sm_disk, because sm_disk_get_nr_free()
always return an underflow value."
While there is room for improvement to the space-map accounting that
thinp is making use of: the reality is this test is inherently racey and
will result in the previous iteration's fstrim's discard(s) completing
vs concurrent block allocation, via dd, in the next iteration of the
loop.
No amount of space map accounting improvements will be able to allow
user's to use a block before a discard of that block has completed.
So the best we can really do is allow DM thinp to gracefully handle such
aggressive use of all the pool's data by degrading the pool into
out-of-data-space (OODS) mode. We _should_ get that behaviour already
(if space map accounting didn't falsely cause alloc_data_block() to
believe free space was available).. but short of that we handle the
current reality that dm_pool_alloc_data_block() can return -ENOSPC.
Reported-by: Dennis Yang <dennisyang@qnap.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
The intc #interrupt-cells is equal to 1. Currently gpio
node has 2 cells per IRQ which is wrong. Remove the additional
cell for each of the interrupts.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Fixes: 2e38b946dc54 ("ARM: davinci: da850: add GPIO DT node")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
|
|
- Remove 'nx_warning' and 'smep_warning', which are just pointless obfuscation.
- Also convert to pr_crit().
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180627090715.28076-1-dvyukov@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Document the recently introduced hwp_dynamic_boost sysfs knob
allowing user space to tell intel_pstate to use iowait boosting
in the active mode with HWP enabled (to improve performance).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
|
|
Fix an incorrect sysfs path in the intel_pstate admin-guide
documentation.
Fixes: 33fc30b47098 (cpufreq: intel_pstate: Document the current behavior and user interface)
Reported-by: Pawit Pornkitprasan <p.pawit@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Fix non-fatal warning triggered during compilation with W=1:
kernel/events/core.c:6106:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
static void __always_inline
^~~~~~
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180626202301.20270-1-malat@debian.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
This reverts the following commits:
1ea66554d3b0 ("x86/mm: Mark p4d_offset() __always_inline")
046c0dbec023 ("x86: Mark native_set_p4d() as __always_inline")
p4d_offset(), native_set_p4d() and native_p4d_clear() were marked
__always_inline in attempt to move __pgtable_l5_enabled into __initdata
section.
It was required as KASAN initialization code is a user of
USE_EARLY_PGTABLE_L5, so all pgtable_l5_enabled() translated to
__pgtable_l5_enabled there. This includes pgtable_l5_enabled() called
from inline p4d helpers.
If compiler would decided to not inline these p4d helpers, but leave
them standalone, we end up with section mismatch.
We don't need __always_inline here anymore. __pgtable_l5_enabled moved
back to be __ro_after_init. See the following commit:
51be13351517 ("Revert "x86/mm: Mark __pgtable_l5_enabled __initdata"")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180626100341.49910-1-kirill.shutemov@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Open-coded page table entry checks don't work correctly when we fold the
page table level at runtime.
pgd_present() on 4-level paging machine always returns true, but
open-coded version of the check may return false-negative result and
we silently skip the rest of the loop body in efi_call_phys_epilog().
Replace open-coded checks with proper helpers.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org # v4.12+
Fixes: 94133e46a0f5 ("x86/efi: Correct EFI identity mapping under 'efi=old_map' when KASLR is enabled")
Link: http://lkml.kernel.org/r/20180625120852.18300-1-kirill.shutemov@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
We have short names for the requested and resulting register values.
Use them instead of spelling out the whole register entry for each
case.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/bb3bc1f923a2f6fe7912d22a1068fe29d6033d38.1530076529.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
When I wrote the sigreturn test, I didn't realize that AMD's busted
IRET behavior was different from Intel's busted IRET behavior:
On AMD CPUs, the CPU leaks the high 32 bits of the kernel stack pointer
to certain userspace contexts. Gee, thanks. There's very little
the kernel can do about it. Modify the test so it passes.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/86e7fd3564497f657de30a36da4505799eebef01.1530076529.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Commit:
8bb2610bc496 ("x86/entry/64/compat: Preserve r8-r11 in int $0x80")
was busted: my original patch had a minor conflict with
some of the nospec changes, but "git apply" is very clever
and silently accepted the patch by making the same changes
to a different function in the same file. There was obviously
a huge offset, but "git apply" for some reason doesn't feel
any need to say so.
Move the changes to the correct function. Now the
test_syscall_vdso_32 selftests passes.
If anyone cares to observe the original problem, try applying the
patch at:
https://lore.kernel.org/lkml/d4c4d9985fbe64f8c9e19291886453914b48caee.1523975710.git.luto@kernel.org/raw
to the kernel at 316d097c4cd4e7f2ef50c40cff2db266593c4ec4:
- "git am" and "git apply" accept the patch without any complaints at all
- "patch -p1" at least prints out a message about the huge offset.
Reported-by: zhijianx.li@intel.com
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org #v4.17+
Fixes: 8bb2610bc496 ("x86/entry/64/compat: Preserve r8-r11 in int $0x80")
Link: http://lkml.kernel.org/r/6012b922485401bc42676e804171ded262fc2ef2.1530078306.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
As Mathieu pointed out, my conversion to time64_t was incorrect and
resulted in negative times to be read from the RTC. The problem is
that during the conversion from a byte array to a time64_t, the
'unsigned char' variable holding the top byte gets turned into a
negative signed 32-bit integer before being assigned to the 64-bit
variable for any times after 1972.
This changes the logic to cast to an unsigned 32-bit number first for
the Macintosh time and then convert that to the Unix time, which then
gives us a time in the documented 1904..2040 year range. I decided not
to use the longer 1970..2106 range that other drivers use, for
consistency with the literal interpretation of the register, but that
could be easily changed if we decide we want to support any Mac after
2040.
Just to be on the safe side, I'm also adding a WARN_ON that will
trigger if either the year 2040 has come and is observed by this
driver, or we run into an RTC that got set back to a pre-1970 date for
some reason (the two are indistinguishable).
For the RTC write functions, Andreas found another problem: both
pmu_request() and cuda_request() are varargs functions, so changing
the type of the arguments passed into them from 32 bit to 64 bit
breaks the API for the set_rtc_time functions. This changes it back to
32 bits.
The same code exists in arch/m68k/ and is patched in an identical way
now in a separate patch.
Fixes: 5bfd643583b2 ("powerpc: use time64_t in read_persistent_clock")
Reported-by: Mathieu Malaterre <malat@debian.org>
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
