PD#167816:
When HDMI ARC connected,and the ARC sink support
ATMOS decoder,we need copy the edid bit in HDMIRX edid.
we need interface to set that bit to hdmirx.
Change-Id: Ic19bc17f166f8f10ba15e1e8b0de1f256296f9a5
Signed-off-by: Jian Xu <jian.xu@amlogic.com>
PD#164611: hdmitx: optimize hpll suspend
The BIT definition of RESET / ENABLE in G12A is different from
earlier chips.
HPLL suspend workflow:
1. set RESET as 1
2. delay 50us
3. set ENABLE as 0
Resume workflow is inverse, but no need anymore, it will be set
in set_disp_mode_auto().
Change-Id: I6e178466f865a643b4ef8d32dc59c99d1c96b94d
Signed-off-by: Zongdong Jiao <zongdong.jiao@amlogic.com>
PD#165744: netflix: merge patch for fix 29.97 and 23.97 output evenly
NEEDLEPLAT-2057:
[Netflix][NTS] Video judders are observed during VP9/HEVC playback [1/1]
[Problem]
[Netflix][NTS] Video judders are observed during VP9/HEVC playback.
The problem happens at 'Boardwalk Twirl Ride' scene with seek point at 760
seconds. Seek before the point or the exact point will show stuttery video
display but a seek after the location or a short seek (swim operation in
NF's term) will make the playback smooth again. [Solution] The problem
is identified to be an uneven PTS timestamp for sample frames. In order
to get 29.97fps the timestamp of video samples are switching between a
30fps rate and some samples with longer duration so by average it's
29.97fps. The output rendering control has very strict timestamp comparison
between system time and the timestamp of video frame. When system time passed
the next video frame's timestamp, a new frame is toggled to display. For the
uneven PTS case, some frames have over 2 vsync duration and the others have
less than 2 vsync duration. Depending on the initial vsync offset, there is a
chance to have frames toggled in 13221322 vsync sequence, instead of a normal
always 2 vsync toggle one frame pattern. The change is to do a small adjustment
to the system time, based on initial system time and video timestamp so the "phase"
of the vsync can be set up to avoid such situation.
[Platform]
needle,stark
[Test]
Verify with Netflix Chime S1E8 29.97fps titles, 'Boardwalk Twirl Ride' scene.
Change-Id: I073481ce9e39f49555480a139e3b32d8cc047e1c
Signed-off-by: Tim Yao <tim.yao@amlog
NEEDLEPLAT-2604: [Netflix] Video judders during playback [1/1]
[JIRA] NEEDLEPLAT-2604
[Problem]
FRC caused video judders with 23.97fps source.
[Solution]
When source is 23.97 fps and output is 59.94hz, in order to make it
friendly to TV 3:2 pulldown detection, the video frame output should follow a
323232 patten, which means for each vsync, frames are repeated 3 times, then
switch to a new frame and repeat twice. Such repeating pattern will make the
average vsync toggle rate become 2.5 frame per vsync, to match 23.97 to 59.94
frame conversion rate. And TV side can also detect such patterns and do its best
recovery for MEMC processing. The problem with Netflix is the PTS of each vidoe
frame is not incremented in a constant duration, but with some frames bigger then
1/23.97 seconds and some are smaller. In Jira NEEDLEPLAT-2057 we have a similar
processing for the case when source is 29.97fps and output is 59.94hz and for this
Jira the reason is same. The fix for NEEDLEPLAT-2057 actually caused a side effect
because it tried to set the initial vsync phase to 0.5, to maximumly avoid the
problem, but for the 2:3 situation, a 0.5 phase make it worse because the average
FRC ratio is 2.5, so an initial 0.5 phase will always make the output pattern not
aligned at 232323 pattern when the duration of each frame is not even. This fix
is to move the initial phase to 75% so both cases should work fine.
[Test] Play typical HD source with 23.97fps and observe the playback smoothness.
Also double check Chimera Boardwalk Twirl Ride from seeking point 02:34:14 and
check the playback is smooth also.
Change-Id: I95c35d4ffa563f74b9afa7ae08f7ef22d1227706
Signed-off-by: Tim Yao <tim.yao@amlogic.com>
NEEDLEPLAT-3173: [NTS]Frame stuttering on 4K 60fps [1/1]
[JIRA] NEEDLEPLAT-3173
[Problem] The test clip is 4K 60fps and the output is 4K
59.94hz so a frame dropping always happen every 1000 frame. The clip is special
in that the duration (PTS growing distance) between each frame is not same. The
frame's PTS is incremened by (1530, 1530, 1440) to get an average of 1500 90K
unit increase. (1500 = 90k / 60), which equals two 17ms dutation then followed
by a 16ms duration frame to get an average of 16.6ms duration. The previous
commit for NEEDLEPLAT-2604 and 2057 are the efforts to solve this problem by
setting an initial phase, which can solve the problem for the uneven PTS for
23.97 and 29.97fps cases. However, for 60fps source, the initial phase can not
solve the problem because we can not maintain 1 vsync 1 frame switching always
because eventually we need drop a frame for every 1000 frames. It means that
during the playback, this initial phase will be shiftted. And when the vsync
switching happens at those uneven PTS boundary, the same problem happens.
[Solution] The change is a general frame switching improvement to avoid two
situations: a) In one vsync, there are two frames toggled (frame dropping),
but the next vsync there is no frame flipped because of its PTS has not arrived.
This will cause unnecessary frame dropping and what we do is to move the second
video frame to next vsync window. b) In one vsync, there are no frames be flipped
(frame repeating), but the next vsync will have more than 1 frame flipped. It's
also another frame dropping and what we do is to flip the next video frame in
this vsync instead. So the idea is to make the frame switching at video display
driver more smooth by avoid uneven frame flipping for each vsync. The timestamp
of the test clip is not correct, but we can use this method to make output
sequence smooth and avoid frame dropping.
[Platform]
needle,stark
[Test]
Verify with the special test clip according to the instruction. Verify
NEEDLEPLAT-2604 and 2057 also.
Change-Id: Ic4dfc8aa243cf01acae296ac53fc2587583e601f
Signed-off-by: shuanglong.wang <shuanglong.wang@amlogic.com>
PD#167718: Setup quality in driver probe so that
meson-rng can contribute to entropy pool.
Change-Id: I47aa7c83b9877f5bf08ac6837f36a648624d0040
Signed-off-by: Mingyen Hung <mingyen.hung@amlogic.com>
In:
c5616f2f87 ANDROID: sched/tune: Initialize raw_spin_lock
in boosted_groups
a spin_lock is initialized on each CPU every time a boost_group is
activated (i.e. a cgroup created).
However, those spin_lock are already initialized at boot time by
schedtune_init_cgroups() which also set schedtune_initialized to true
thus enabling the tasks accounting done by schedtune_{en,de}queue_task().
This means that an already initialize and used spin_lock is wrongly
re-initialized thus potentially leading to a:
BUG: spinlock already unlocked on CPU
in the (unlikely in AOSP) case we have a race between schedtune cgroups
creation and tasks enqueue/dequeue.
This probably happened because the fix provided by c5616f2f87 was just
the wrong cure for a different issues: the missing one-time
initialization of the per-CPU spinlocks in schedtune_init_cgroups().
All these fixes happened on v4.4 and have been forward ported to the
current v4.9 base.
Let's better fix this by:
- removing the not necessary spinlock re-initialization in:
schedtune_boostgroup_init()
- add a new "valid" flag to better flag which boost_groups are currently
used to track a valid cgroup.
This patch adds also a better documentation of the used data structures
and the locking strategy in use to synchronize fast and slow paths.
Change-Id: I3c2a256693b12b317373bbc032ed46e620f79ee8
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Reported-by: Stanley Shih <stanley.shih@mstarsemi.com>
[
The first of the two fixes listed above has been already
merged by:
commit f6bec4e8c7 ("Revert "ANDROID: sched/tune:
Initialize raw_spin_lock in boosted_groups")
which, in conjunction with:
commit 751e509391 ("ANDROID: sched: tune:
Fix lacking spinlock initialization")
provides the correct initialization of the boostgroups spinlocks.
Let's keep the changelog as it is to better keep track of the original
intended fix as well as to better document the required locking strategy.
]
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
PD#167814: mtd: set chip type as slc by default.
newlly rebased upstream will report slc/mlc by
bit_per_cell which was not filled before.
Change-Id: Ibe23fcce6ab919cf3ceb19b5870bae13c3a52e0b
Signed-off-by: Yonghui Yu <yonghui.yu@amlogic.com>
This update the definition of these two methods to make more clear their
role.
In this refactored version, the slow path entry functions:
schedtune_css_alloc()
schedtune_css_free()
are in charge just to allocate and release the memory used to track
schedtune boost groups.
These two functions rely respectively on:
schedtune_boostgroup_init()
schedtune_boostgroup_release()
for everything related to setting up data structures and properly
initializing them.
Change-Id: I9336102b5c6a6b5726fd466e99b7d6b28d38f455
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
This value was added in:
e71c425516 ANDROID: sched/tune: Add support for negative boost values
and it's likely coming from a conflict resolution or a merge of some
previous patches used to track negative boost values.
Change-Id: I3b63e99db9232eb6117a561aa61c527986ade8e4
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
PD#167811: hdmitx: fix no output when plugin dvi equipment
In uboot,hdmitx only output hdmi video stream. When plugin dvi
equipments, we choose dvi stream after reading edid.
Change-Id: Ic4dce29e98b9da58e8b79ffec3de933965b23ea3
Signed-off-by: Yi Zhou <yi.zhou@amlogic.com>
Changes in 4.9.107
arm64: lse: Add early clobbers to some input/output asm operands
powerpc/64s: Clear PCR on boot
USB: serial: cp210x: use tcflag_t to fix incompatible pointer type
Revert "pinctrl: msm: Use dynamic GPIO numbering"
xfs: detect agfl count corruption and reset agfl
Revert "ima: limit file hash setting by user to fix and log modes"
Input: elan_i2c_smbus - fix corrupted stack
tracing: Fix crash when freeing instances with event triggers
selinux: KASAN: slab-out-of-bounds in xattr_getsecurity
cfg80211: further limit wiphy names to 64 bytes
dma-buf: remove redundant initialization of sg_table
rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c
ASoC: Intel: sst: remove redundant variable dma_dev_name
platform/chrome: cros_ec_lpc: remove redundant pointer request
x86/amd: revert commit 944e0fc51a
xen: set cpu capabilities from xen_start_kernel()
x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen
tcp: avoid integer overflows in tcp_rcv_space_adjust()
scsi: ufs: fix failure to read the string descriptor
scsi: ufs: refactor device descriptor reading
scsi: ufs: Factor out ufshcd_read_desc_param
arm64: Add hypervisor safe helper for checking constant capabilities
arm64/cpufeature: don't use mutex in bringup path
powerpc/rfi-flush: Move out of HARDLOCKUP_DETECTOR #ifdef
powerpc/pseries: Support firmware disable of RFI flush
powerpc/powernv: Support firmware disable of RFI flush
powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again
powerpc/rfi-flush: Always enable fallback flush on pseries
powerpc/rfi-flush: Differentiate enabled and patched flush types
powerpc/rfi-flush: Call setup_rfi_flush() after LPM migration
powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
powerpc: Add security feature flags for Spectre/Meltdown
powerpc/pseries: Set or clear security feature flags
powerpc/powernv: Set or clear security feature flags
powerpc/64s: Move cpu_show_meltdown()
powerpc/64s: Enhance the information in cpu_show_meltdown()
powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
powerpc/64s: Wire up cpu_show_spectre_v1()
powerpc/64s: Wire up cpu_show_spectre_v2()
powerpc/pseries: Fix clearing of security feature flags
powerpc: Move default security feature flags
powerpc/pseries: Restore default security feature flags on setup
powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()
powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit
net/mlx4_en: fix potential use-after-free with dma_unmap_page
iio:kfifo_buf: check for uint overflow
MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs
MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests
scsi: scsi_transport_srp: Fix shost to rport translation
stm class: Use vmalloc for the master map
hwtracing: stm: fix build error on some arches
IB/core: Fix error code for invalid GID entry
drm/psr: Fix missed entry in PSR setup time table.
drm/i915: Disable LVDS on Radiant P845
sparc64: Fix build warnings with gcc 7.
fix io_destroy()/aio_complete() race
mm: fix the NULL mapping case in __isolate_lru_page()
sparc64: Don't clibber fixed registers in __multi4.
serial: pl011: add console matching function
Linux 4.9.107
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 10879ae5f1 upstream.
This patch adds function pl011_console_match() that implements
method match of struct console. It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.
This patch was merged to tty-next but then reverted because of
conflict with
commit 46e36683f4 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses")
Now it is fixed.
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 79db795833 upstream.
%g4 and %g5 are fixed registers used by the kernel for the thread
pointer and the per-cpu offset. Use %o4 and %g7 instead.
Diagnosis by Anthony Yznaga.
Fixes: 1b4af13ff2 ("sparc64: Add __multi3 for gcc 7.x and later.")
Reported-by: Anatoly Pugachev <matorola@gmail.com>
Tested-by: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4faa99965e upstream.
If io_destroy() gets to cancelling everything that can be cancelled and
gets to kiocb_cancel() calling the function driver has left in ->ki_cancel,
it becomes vulnerable to a race with IO completion. At that point req
is already taken off the list and aio_complete() does *NOT* spin until
we (in free_ioctx_users()) releases ->ctx_lock. As the result, it proceeds
to kiocb_free(), freing req just it gets passed to ->ki_cancel().
Fix is simple - remove from the list after the call of kiocb_cancel(). All
instances of ->ki_cancel() already have to cope with the being called with
iocb still on list - that's what happens in io_cancel(2).
Cc: stable@kernel.org
Fixes: 0460fef2a9 "aio: use cancellation list lazily"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0fde7ad71e upstream.
arch/sparc/kernel/ds.c: In function ‘register_services’:
arch/sparc/kernel/ds.c:912:3: error: ‘strcpy’: writing at least 1 byte
into a region of size 0 overflows the destination
Reported-by: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a840c93ca7 upstream.
When a GID entry is invalid EAGAIN is returned. This is an incorrect error
code, there is nothing that will make this GID entry valid again in
bounded time.
Some user space tools fail incorrectly if EAGAIN is returned here, and
this represents a small ABI change from earlier kernels.
The first patch in the Fixes list makes entries that were valid before
to become invalid, allowing this code to trigger, while the second patch
in the Fixes list introduced the wrong EAGAIN.
Therefore revert the return result to EINVAL which matches the historical
expectations of the ibv_query_gid_type() API of the libibverbs user space
library.
Cc: <stable@vger.kernel.org>
Fixes: 598ff6bae6 ("IB/core: Refactor GID modify code for RoCE")
Fixes: 03db3a2d81 ("IB/core: Add RoCE GID table management")
Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 806e30873f upstream.
Commit b5e2ced9bf ("stm class: Use vmalloc for the master map") caused
a build error on some arches as vmalloc.h was not explicitly included.
Fix that by adding it to the list of includes.
Fixes: b5e2ced9bf ("stm class: Use vmalloc for the master map")
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b5e2ced9bf upstream.
Fengguang is running into a warning from the buddy allocator:
> swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc1 #262
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> Call Trace:
...
> __kmalloc+0x14b/0x180: ____cache_alloc at mm/slab.c:3127
> stm_register_device+0xf3/0x5c0: stm_register_device at drivers/hwtracing/stm/core.c:695
...
Which is basically a result of the stm class trying to allocate ~512kB
for the dummy_stm with its default parameters. There's no reason, however,
for it not to be vmalloc()ed instead, which is what this patch does.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
CC: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c9ddf73476 upstream.
Since an SRP remote port is attached as a child to shost->shost_gendev
and as the only child, the translation from the shost pointer into an
rport pointer must happen by looking up the shost child that is an
rport. This patch fixes the following KASAN complaint:
BUG: KASAN: slab-out-of-bounds in srp_timed_out+0x57/0x110 [scsi_transport_srp]
Read of size 4 at addr ffff880035d3fcc0 by task kworker/1:0H/19
CPU: 1 PID: 19 Comm: kworker/1:0H Not tainted 4.16.0-rc3-dbg+ #1
Workqueue: kblockd blk_mq_timeout_work
Call Trace:
dump_stack+0x85/0xc7
print_address_description+0x65/0x270
kasan_report+0x231/0x350
srp_timed_out+0x57/0x110 [scsi_transport_srp]
scsi_times_out+0xc7/0x3f0 [scsi_mod]
blk_mq_terminate_expired+0xc2/0x140
bt_iter+0xbc/0xd0
blk_mq_queue_tag_busy_iter+0x1c7/0x350
blk_mq_timeout_work+0x325/0x3f0
process_one_work+0x441/0xa50
worker_thread+0x76/0x6c0
kthread+0x1b2/0x1d0
ret_from_fork+0x24/0x30
Fixes: e68ca75200 ("scsi_transport_srp: Reduce failover time")
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Johannes Thumshirn <jthumshirn@suse.de>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Laurence Oberman <loberman@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 28e4213dd3 upstream.
Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e.
Status.FR) is not supported as the lone purpose of Config5.FRE is to
emulate Status.FR=0 handling on FPU hardware that has Status.FR=1
hardwired[1][2]. Also we do not handle this case elsewhere, and assume
throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot
be set both at once for a task, leading to inconsistent behaviour if
this does happen.
Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting
PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear. This corresponds to
modes allowed by `mips_set_personality_fp'.
References:
[1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32
Privileged Resource Architecture", Imagination Technologies,
Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69
"Config5 Register Field Descriptions", p. 262
[2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64
Privileged Resource Architecture", Imagination Technologies,
Document Number: MD00091, Revision 6.03, December 22, 2015, Table
9.72 "Config5 Register Field Descriptions", p. 288
Fixes: 9791554b45 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Signed-off-by: Maciej W. Rozycki <macro@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 4.0+
Patchwork: https://patchwork.linux-mips.org/patch/19327/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d13de4b02 upstream.
Currently, the following causes a kernel OOPS in memcpy:
echo 1073741825 > buffer/length
echo 1 > buffer/enable
Note that using 1073741824 instead of 1073741825 causes "write error:
Cannot allocate memory" but no OOPS.
This is because 1073741824 == 2^30 and 1073741825 == 2^30+1. Since kfifo
rounds up to the nearest power of 2, it will actually call kmalloc with
roundup_pow_of_two(length) * bytes_per_datum.
Using length == 1073741825 and bytes_per_datum == 2, we get:
kmalloc(roundup_pow_of_two(1073741825) * 2
or kmalloc(2147483648 * 2)
or kmalloc(4294967296)
or kmalloc(UINT_MAX + 1)
so this overflows to 0, causing kmalloc to return ZERO_SIZE_PTR and
subsequent memcpy to fail once the device is enabled.
Fix this by checking for overflow prior to allocating a kfifo. With this
check added, the above code returns -EINVAL when enabling the buffer,
rather than causing an OOPS.
Signed-off-by: Martin Kelly <mkelly@xevo.com>
cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Not relevant upstream, therefore no upstream commit. ]
To fix, unmap the page as soon as possible.
When swiotlb is in use, calling dma_unmap_page means that
the original page mapped with dma_map_page must still be valid,
as swiotlb will copy data from its internal cache back to the
originally requested DMA location.
When GRO is enabled, before this patch all references to the
original frag may be put and the page freed before dma_unmap_page
in mlx4_en_free_frag is called.
It is possible there is a path where the use-after-free occurs
even with GRO disabled, but this has not been observed so far.
The bug can be trivially detected by doing the following:
* Compile the kernel with DEBUG_PAGEALLOC
* Run the kernel as a Xen Dom0
* Leave GRO enabled on the interface
* Run a 10 second or more test with iperf over the interface.
This bug was likely introduced in
commit 4cce66cdd1 ("mlx4_en: map entire pages to increase throughput"),
first part of u3.6.
It was incidentally fixed in
commit 34db548bfb ("mlx4: add page recycling in receive path"),
first part of v4.12.
This version applies to the v4.9 series.
Signed-off-by: Sarah Newman <srn@prgmr.com>
Tested-by: Sarah Newman <srn@prgmr.com>
Cc: Tariq Toukan <tariqt@mellanox.com>
Cc: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a048a07d7f upstream.
On some CPUs we can prevent a vulnerability related to store-to-load
forwarding by preventing store forwarding between privilege domains,
by inserting a barrier in kernel entry and exit paths.
This is known to be the case on at least Power7, Power8 and Power9
powerpc CPUs.
Barriers must be inserted generally before the first load after moving
to a higher privilege, and after the last store before moving to a
lower privilege, HV and PR privilege transitions must be protected.
Barriers are added as patch sections, with all kernel/hypervisor entry
points patched, and the exit points to lower privilge levels patched
similarly to the RFI flush patching.
Firmware advertisement is not implemented yet, so CPU flush types
are hard coded.
Thanks to Michal Suchánek for bug fixes and review.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Michal Suchánek <msuchanek@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 501a78cbc1 upstream.
The recent LPM changes to setup_rfi_flush() are causing some section
mismatch warnings because we removed the __init annotation on
setup_rfi_flush():
The function setup_rfi_flush() references
the function __init ppc64_bolted_size().
the function __init memblock_alloc_base().
The references are actually in init_fallback_flush(), but that is
inlined into setup_rfi_flush().
These references are safe because:
- only pseries calls setup_rfi_flush() at runtime
- pseries always passes L1D_FLUSH_FALLBACK at boot
- so the fallback flush area will always be allocated
- so the check in init_fallback_flush() will always return early:
/* Only allocate the fallback flush area once (at boot time). */
if (l1d_flush_fallback_area)
return;
- and therefore we won't actually call the freed init routines.
We should rework the code to make it safer by default rather than
relying on the above, but for now as a quick-fix just add a __ref
annotation to squash the warning.
Fixes: abf110f3e1 ("powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6232774f15 upstream.
After migration the security feature flags might have changed (e.g.,
destination system with unpatched firmware), but some flags are not
set/clear again in init_cpu_char_feature_flags() because it assumes
the security flags to be the defaults.
Additionally, if the H_GET_CPU_CHARACTERISTICS hypercall fails then
init_cpu_char_feature_flags() does not run again, which potentially
might leave the system in an insecure or sub-optimal configuration.
So, just restore the security feature flags to the defaults assumed
by init_cpu_char_feature_flags() so it can set/clear them correctly,
and to ensure safe settings are in place in case the hypercall fail.
Fixes: f636c14790 ("powerpc/pseries: Set or clear security feature flags")
Depends-on: 19887d6a28e2 ("powerpc: Move default security feature flags")
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e7347a8683 upstream.
This moves the definition of the default security feature flags
(i.e., enabled by default) closer to the security feature flags.
This can be used to restore current flags to the default flags.
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0f9bdfe3c7 upstream.
The H_CPU_BEHAV_* flags should be checked for in the 'behaviour' field
of 'struct h_cpu_char_result' -- 'character' is for H_CPU_CHAR_*
flags.
Found by playing around with QEMU's implementation of the hypercall:
H_CPU_CHAR=0xf000000000000000
H_CPU_BEHAV=0x0000000000000000
This clears H_CPU_BEHAV_FAVOUR_SECURITY and H_CPU_BEHAV_L1D_FLUSH_PR
so pseries_setup_rfi_flush() disables 'rfi_flush'; and it also
clears H_CPU_CHAR_L1D_THREAD_PRIV flag. So there is no RFI flush
mitigation at all for cpu_show_meltdown() to report; but currently
it does:
Original kernel:
# cat /sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: RFI Flush
Patched kernel:
# cat /sys/devices/system/cpu/vulnerabilities/meltdown
Not affected
H_CPU_CHAR=0x0000000000000000
H_CPU_BEHAV=0xf000000000000000
This sets H_CPU_BEHAV_BNDS_CHK_SPEC_BAR so cpu_show_spectre_v1() should
report vulnerable; but currently it doesn't:
Original kernel:
# cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Not affected
Patched kernel:
# cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Vulnerable
Brown-paper-bag-by: Michael Ellerman <mpe@ellerman.id.au>
Fixes: f636c14790 ("powerpc/pseries: Set or clear security feature flags")
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d6fbe1c55c upstream.
Add a definition for cpu_show_spectre_v2() to override the generic
version. This has several permuations, though in practice some may not
occur we cater for any combination.
The most verbose is:
Mitigation: Indirect branch serialisation (kernel only), Indirect
branch cache disabled, ori31 speculation barrier enabled
We don't treat the ori31 speculation barrier as a mitigation on its
own, because it has to be *used* by code in order to be a mitigation
and we don't know if userspace is doing that. So if that's all we see
we say:
Vulnerable, ori31 speculation barrier enabled
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 56986016cb upstream.
Add a definition for cpu_show_spectre_v1() to override the generic
version. Currently this just prints "Not affected" or "Vulnerable"
based on the firmware flag.
Although the kernel does have array_index_nospec() in a few places, we
haven't yet audited all the powerpc code to see where it's necessary,
so for now we don't list that as a mitigation.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2e4a16161f upstream.
Now that we have the security flags we can simplify the code in
pseries_setup_rfi_flush() because the security flags have pessimistic
defaults.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 37c0bdd00d upstream.
Now that we have the security flags we can significantly simplify the
code in pnv_setup_rfi_flush(), because we can use the flags instead of
checking device tree properties and because the security flags have
pessimistic defaults.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ff348355e9 upstream.
Now that we have the security feature flags we can make the
information displayed in the "meltdown" file more informative.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8ad3304156 upstream.
This landed in setup_64.c for no good reason other than we had nowhere
else to put it. Now that we have a security-related file, that is a
better place for it so move it.
[mpe: Add extern for rfi_flush to fix bisection break]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
