Make the schedutil governor take the initial (default) value of the
rate_limit_us sysfs attribute from the (new) transition_delay_us
policy parameter (to be set by the scaling driver).
That will allow scaling drivers to make schedutil use smaller default
values of rate_limit_us and reduce the default average time interval
between consecutive frequency changes.
Make intel_pstate set transition_delay_us to 500.
BACKPORT: Modified to support the separate up_rate_limit_us and
down_rate_limit_us (upstream just has a single rate_limit_us). Also
dropped the changes for intel_pstate as there's a merge conflict.
Change-Id: I62a8543879a4d8582cdcb31ebd55607705d1c8b1
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
(cherry picked from commit 1b72e7fd30)
Signed-off-by: Brendan Jackman <brendan.jackman@arm.com>
(from https://patchwork.kernel.org/patch/9939409/)
commit 372e3147df ("binder: guarantee txn complete / errors delivered
in-order") incorrectly defined a local ret value. This ret value will
be invalid when out of the if block
Change-Id: If7bd963ac7e67d135aa949133263aac27bf15d1a
Signed-off-by: Xu YiPing <xuyiping@hislicon.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
(from https://patchwork.kernel.org/patch/9939405/)
commit 7a4408c6bd ("binder: make sure accesses to proc/thread are
safe") made a change to enqueue tcomplete to thread->todo before
enqueuing the transaction. However, in err_dead_proc_or_thread case,
the tcomplete is directly freed, without dequeued. It may cause the
thread->todo list to be corrupted.
So, dequeue it before freeing.
Bug: 65333488
Change-Id: Id063a4db18deaa634f4d44aa6ebca47bea32537a
Signed-off-by: Xu YiPing <xuyiping@hisilicon.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
The initial window start needs to be close to ktime ns = 0 to be
aligned with scheduler tick.
Change-Id: Ia91f74efce2f910106622a054a6fcd507e763ca5
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
EAS won't allow NOHZ idle balancer until CPU's over utilized. However
nohz_kick_needed() can return true. This causes idle CPU wake up for
nothing.
Change-Id: I6e548442e29e4f85cda695e4c7101dd591b12fe6
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
In order to calculate energy difference we currently iterates CPUs under
the same sched doamin to accumulate total energy cost and compare before
and after :
for_each_domain(cpu)
total_energy_before += (cpu_util * power) >> SCHED_CAPACITY_SHIFT;
for_each_domain(cpu)
total_energy_after += (cpu_util * power) >> SCHED_CAPACITY_SHIFT;
Doing such can incorrectly calculate and report abs(delta) > 0 when
there is actually no energy delta between before and after because the
same total accumulated cpu_util of all the CPUs can be distributed
differently before and after and it causes different amount of rounding
error.
Fix such incorrectness by shifting just once with accumulated
total_energy.
Change-Id: I82f1e2e358367058960938b4ef81714f57e921cf
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
(moved part to another commit)
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
WALT's function cpu_util(cpu) reports CPU's load without taking into
account of waking task's load. Thus currently cpu_overutilized()
underestimates load on the previous CPU of waking task.
Take into account of task's load to determine whether previous CPU is
overutilzed to bail out early without running energy_diff() which is
expensive.
Change-Id: I30f146984a880ad2cc1b8a4ce35bd239a8c9a607
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
(minor rebase conflicts)
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
With WALT all the scheduler classes' load are accounted in scr->cfs and
update_cpu_capacity_request() adds capacity margin. At present, at tick
path, scheduler also adds capacity margin. Therefore the margin applied
twice.
Fix such error by using margin applied cpu utilization only for checking
whether frequency increase is needed.
Change-Id: Id7d8cc73b2e4eec70b274ca66e09bb0b16bf6f09
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
(trivial rebase conflict)
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
WALT CPU utilization reports CPU load of all the scheduler classes.
Therefore adding RT class's load additionally will cause frequency
overshooting. Fix such issue by not accounting RT class load when
requesting capacity.
Change-Id: I29600d7af7ca8c00e0d2ff1e13872024ccaa72bf
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
WALT accounts two major statistics; CPU load and cumulative tasks
demand.
The CPU load which is account of accumulated each CPU's absolute
execution time is for CPU frequency guidance. Whereas cumulative
tasks demand which is each CPU's instantaneous load to reflect
CPU's load at given time is for task placement decision.
Use cumulative tasks demand for cpu_util() for task placement and
introduce cpu_util_freq() for frequency guidance.
Change-Id: Id928f01dbc8cb2a617cdadc584c1f658022565c5
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
When running tasks's ravg.demand is changed update_history() adjusts
rq->cumulative_runnable_avg to reflect change of CPU load. Currently
this fixup is broken by accumulating task's new demand without
subtracting the task's old demand.
Fix the fixup logic to subtract the task's old demand.
Change-Id: I61beb32a4850879ccb39b733f5564251e465bfeb
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Account cumulative runnable average for WALT CPU utilization accounting.
Change-Id: I56934894e626dec183740eeaf89a57d2ef638143
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
(from https://patchwork.kernel.org/patch/9928611/)
Add the number of active, lru, and free pages for
each binder process in binder stats
Bug: 63926541
Change-Id: I12618e4eb8ecc08f4f05fe4cba454a88830897f9
Signed-off-by: Sherry Yang <sherryy@android.com>
(from https://patchwork.kernel.org/patch/9928613/)
Add tracepoints in binder transaction allocator to
record lru hits and alloc/free page.
Bug: 63926541
Change-Id: I2e24fe8e7b6534349df4a87ff865a6843ac9a30b
Signed-off-by: Sherry Yang <sherryy@android.com>
(from https://patchwork.kernel.org/patch/9928615/)
Hold on to the pages allocated and mapped for transaction
buffers until the system is under memory pressure. When
that happens, use linux shrinker to free pages. Without
using shrinker, patch "android: binder: Move buffer out
of area shared with user space" will cause a significant
slow down for small transactions that fit into the first
page because free list buffer header used to be inlined
with buffer data.
In addition to prevent the performance regression for
small transactions, this patch improves the performance
for transactions that take up more than one page.
Modify alloc selftest to work with the shrinker change.
Test: Run memory intensive applications (Chrome and Camera)
to trigger shrinker callbacks. Binder frees memory as expected.
Test: Run binderThroughputTest with high memory pressure
option enabled.
Bug: 63926541
Change-Id: I3abfc43b405e7e0a6228da37e0689a4b944f0e00
Signed-off-by: Sherry Yang <sherryy@android.com>
(from https://patchwork.kernel.org/patch/9928607/)
Binder driver allocates buffer meta data in a region that is mapped
in user space. These meta data contain pointers in the kernel.
This patch allocates buffer meta data on the kernel heap that is
not mapped in user space, and uses a pointer to refer to the data mapped.
Also move alloc->buffers initialization from mmap to init since it's
now used even when mmap failed or was not called.
Bug: 36007193
Change-Id: Id5136048bdb7b796f59de066de7ea7df410498f5
Signed-off-by: Sherry Yang <sherryy@android.com>
(from https://patchwork.kernel.org/patch/9928609/)
binder_alloc_selftest tests that alloc_new_buf handles page allocation and
deallocation properly when allocate and free buffers. The test allocates 5
buffers of various sizes to cover all possible page alignment cases, and
frees the buffers using a list of exhaustive freeing order.
Test: boot the device with ANDROID_BINDER_IPC_SELFTEST config option
enabled. Allocator selftest passes.
Bug: 36007193
Change-Id: I2fe396232b7dfe4bbc50bdba99ca0de9be63cc37
Signed-off-by: Sherry Yang <sherryy@android.com>
(from https://patchwork.kernel.org/patch/9928605/)
Use helper functions buffer_next and buffer_prev instead
of list_entry to get the next and previous buffers.
Bug: 36007193
Change-Id: I422dce84afde3d2138a6d976593b109a9cc49003
Signed-off-by: Sherry Yang <sherryy@android.com>
USB tethering has a hard dependency on ip6t_rpfilter module now.
So enable IP6_NF_MATCH_RPFILTER config to make it work again,
otherwise we run into following failures when we try to enable
USB tethering on Hikey:
W IptablesRestoreController: iptables-restore process 1893 terminated status=256
E IptablesRestoreController: iptables error:
E IptablesRestoreController: ------- COMMAND -------
E IptablesRestoreController: *raw
E IptablesRestoreController: -A natctrl_raw_PREROUTING -i usb0 -m rpfilter --invert ! -s fe80::/64 -j DROP
E IptablesRestoreController: COMMIT
E IptablesRestoreController:
E IptablesRestoreController: ------- ERROR -------
E IptablesRestoreController: ip6tables-restore: line 319 failed
E IptablesRestoreController: ----------------------
E NatController: Error setting forward rules
E Tethering: [usb0] ERROR Exception enabling NAT: java.lang.IllegalStateException: command '55 nat enable
usb0 wlan0 1 192.168.42.0/24' failed with '400 55 Nat operation failed (No such device)'
Change-Id: I4a4e192ee1c81a7a425eefee9a2a53dd41e1fa0e
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Currently the iowait_boost feature in schedutil makes the frequency go
to max on iowait wakeups. This feature was added to handle a case that
Peter described where the throughput of operations involving continuous
I/O requests [1] is reduced due to running at a lower frequency, however
the lower throughput itself causes utilization to be low and hence
causing frequency to be low hence its "stuck".
Instead of going to max, its also possible to achieve the same effect by
ramping up to max if there are repeated in_iowait wakeups happening.
This patch is an attempt to do that. We start from a lower frequency
(policy->min) and double the boost for every consecutive iowait update
until we reach the maximum iowait boost frequency (iowait_boost_max).
I ran a synthetic test (continuous O_DIRECT writes in a loop) on an x86
machine with intel_pstate in passive mode using schedutil. In this test
the iowait_boost value ramped from 800MHz to 4GHz in 60ms. The patch
achieves the desired improved throughput as the existing behavior.
[1] https://patchwork.kernel.org/patch/9735885/
Change-Id: I4a018434a50f4ca29ec15b03465f6dc212e54423
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Joel Fernandes <joelaf@google.com>
Overflow on memcpy is possible in kernel driver for st21nfca's
NFC HCI layer when handling connectivity events if aid_len or
params_len are bigger than the buffer size.
Memory leak is possible when parameter tag is invalid.
Bug: 62679581
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Check user provided dir value to prevent out-of-bound access
which may occur if dir is not less than XFRM_POLICY_MAX.
(url: http://seclists.org/bugtraq/2017/Jul/30)
Bug: 64257838
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I5bbdf95e14a61bdf5207977d9a5a4465bc848da0
When handling SHDLC I-Frame commands "pipe" field used for indexing
into an array should be checked before usage. If left unchecked it
might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
Bug: 62679701
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Possible buffer overflow when reading next_read_size bytes into
tmp buffer after next_read_size was extracted from a previous packet.
Bug: 62678828
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
Bug: 62679012
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
If the request->length is zero, a ZLP should already be sent due to that
and another ZLP is not needed to terminate the transfer.
(cherry-picked from commit
d9261898a4)
Fixes: 04c03d10e5 ("usb: dwc3: gadget: handle request->zero")
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Bug: 63867169
Change-Id: I97a1801c57dc169b6e9371d5aec599a14f316aff
So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.
Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that detail from
every gadget driver, we have a preallocated buffer
of 1024 bytes (biggest bulk size) to use (and
share) among all endpoints.
(cherry-picked from commit
04c03d10e5)
Reported-by: Ravi B <ravibabu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Bug: 63867169
Change-Id: Ied4093e92dd080f2d9dd1fd9aefb36406f66bb67
The req->complete seems to presist the callback pointer for
the control requests. This causes the serial of the accessory
to be overridden when an accessory function specific out
control request is issued right after the ACCESSORY_SEND_STRING
control request. Therefore, assign a no-op req complete function
when nothing needs to be done once the request is completed.
Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Bug: 63867169
Change-Id: I78c1602e9a044b8718b270b8a068cf5afc83f984
There's a race between usb_gadget_udc_stop() which is likely
to set the gadget driver to NULL in the udc driver and this drivers
gadget disconnect fn which likely checks for the gadget driver to
a null ptr. It happens that unbind (doing set_gadget_data(NULL))
is called before the gadget driver is set to NULL and the udc driver
calls disconnect fn which results in cdev being a null ptr.
As a workaround we check cdev in android_disconnect() to prevent
the following panic:
Unable to handle kernel NULL pointer dereference at virtual address 000000a8
pgd = ffffff800940a000
[000000a8] *pgd=00000000be1fe003, *pud=00000000be1fe003, *pmd=0000000000000000
Internal error: Oops: 96000046 [#1] PREEMPT SMP
CPU: 7 PID: 1134 Comm: kworker/u16:3 Tainted: G S 4.9.41-g75cd2a0231ea-dirty #4
Hardware name: HiKey960 (DT)
Workqueue: events_power_efficient event_work
task: ffffffc0b5f4f000 task.stack: ffffffc0b5b94000
PC is at android_disconnect+0x54/0xa4
LR is at android_disconnect+0x54/0xa4
pc : [<ffffff8008855938>] lr : [<ffffff8008855938>] pstate: 80000185
sp : ffffffc0b5b97bf0
x29: ffffffc0b5b97bf0 x28: 0000000000000003
x27: ffffffc0b5181c54 x26: ffffffc0b5181c68
x25: ffffff8008dc1000 x24: ffffffc0b5181d70
x23: ffffff8008dc18a0 x22: ffffffc0b5f5a018
x21: ffffffc0b5894ad8 x20: 0000000000000000
x19: ffffff8008ddaec8 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 00000000007c9ccd
x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000001
x9 : ffffff800930f1a8 x8 : ffffff800932a133
x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffffffc0b5b97a50 x4 : ffffffc0be19f090
x3 : 0000000000000000 x2 : ffffff80091ca000
x1 : 000000000000002f x0 : 000000000000002f
This happened on a hikey960 with the following backtrace:
[<ffffff8008855938>] android_disconnect+0x54/0xa4
[<ffffff80089def38>] dwc3_disconnect_gadget.part.19+0x114.888119]
[<ffffff80087f7d48>] dwc3_gadget_suspend+0x6c/0x70
[<ffffff80087ee674>] dwc3_suspend_device+0x58/0xa0
[<ffffff80087fb418>] dwc3_otg_work+0x214/0x474
[<ffffff80087fdc74>] event_work+0x3bc/0x5ac
[<ffffff80080e5d88>] process_one_work+0x14c/0x43c
[<ffffff80080e60d4>] worker_thread+0x5c/0x438
[<ffffff80080ece68>] kthread+0xec/0x100
[<ffffff8008083680>] ret_from_fork+0x10/0x50
dwc3_otg_work tries to handle a switch from host to device mode
and therefore calls disconnect on the gadget driver.
To reproduce the issue it is enaugh to enable tethering (rndis gadget),
unplug and plug in again the usb connector which causes the change
from device to host and back to device mode.
Signed-off-by: Danilo Krummrich <danilokrummrich@gmail.com>
Include linux/mm.h for get_cmdline() declaration.
Change-Id: Icad6ef7deef4d93d92d423c96bfa61fb5d66d0b7
Fixes: Change-Id: I30083b757eaef8c61e55a213a883ce8d0c9cf2b1
("uid_sys_stats: log task io with a debug flag")
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Add a hashmap inside each uid_entry to keep track of task name and io.
Task full name is a combination of thread and process name.
Bug: 63739275
Change-Id: I30083b757eaef8c61e55a213a883ce8d0c9cf2b1
Signed-off-by: Yang Jin <yajin@google.com>
commit b31ff3cdf5 upstream.
If using a kernel with CONFIG_XFS_RT=y and we set the RHINHERIT flag on
a directory in a filesystem that does not have a realtime device and
create a new file in that directory, it gets marked as a real time file.
When data is written and a fsync is issued, the filesystem attempts to
flush a non-existent rt device during the fsync process.
This results in a crash dereferencing a null buftarg pointer in
xfs_blkdev_issue_flush():
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: xfs_blkdev_issue_flush+0xd/0x20
.....
Call Trace:
xfs_file_fsync+0x188/0x1c0
vfs_fsync_range+0x3b/0xa0
do_fsync+0x3d/0x70
SyS_fsync+0x10/0x20
do_syscall_64+0x4d/0xb0
entry_SYSCALL64_slow_path+0x25/0x25
Setting RT inode flags does not require special privileges so any
unprivileged user can cause this oops to occur. To reproduce, confirm
kernel is compiled with CONFIG_XFS_RT=y and run:
# mkfs.xfs -f /dev/pmem0
# mount /dev/pmem0 /mnt/test
# mkdir /mnt/test/foo
# xfs_io -c 'chattr +t' /mnt/test/foo
# xfs_io -f -c 'pwrite 0 5m' -c fsync /mnt/test/foo/bar
Or just run xfstests with MKFS_OPTIONS="-d rtinherit=1" and wait.
Kernels built with CONFIG_XFS_RT=n are not exposed to this bug.
Fixes: f538d4da8d ("[XFS] write barrier support")
Signed-off-by: Richard Wareing <rwareing@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 196639ebbe upstream.
The writeback code wants to send a commit after processing the pages,
which is why we want to delay releasing the struct path until after
that's done.
Also, the layout code expects that we do not free the inode before
we've put the layout segments in pnfs_writehdr_free() and
pnfs_readhdr_free()
Fixes: 919e3bd9a8 ("NFS: Ensure we commit after writeback is complete")
Fixes: 4714fb51fd ("nfs: remove pgio_header refcount, related cleanup")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 746a272e44 upstream.
When there's a fatal signal pending, arm's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.
However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.
To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Steve Capper <steve.capper@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e860d2c904 upstream.
Validate the output buffer length for L2CAP config requests and responses
to avoid overflowing the stack buffer used for building the option blocks.
Signed-off-by: Ben Seri <ben@armis.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6c6b5a39c4 upstream.
Several distributions mount the "proper root" as ro during initrd and
then remount it as rw before pivot_root(2). Thus, if a rescan had been
aborted by a previous shutdown, the rescan would never be resumed.
This issue would manifest itself as several btrfs ioctl(2)s causing the
entire machine to hang when btrfs_qgroup_wait_for_completion was hit
(due to the fs_info->qgroup_rescan_running flag being set but the rescan
itself not being resumed). Notably, Docker's btrfs storage driver makes
regular use of BTRFS_QUOTA_CTL_DISABLE and BTRFS_IOC_QUOTA_RESCAN_WAIT
(causing this problem to be manifested on boot for some machines).
Cc: Jeff Mahoney <jeffm@suse.com>
Fixes: b382a324b6 ("Btrfs: fix qgroup rescan resume on mount")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Tested-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f0bfcc22d9 upstream.
When the adv7511 i2c client doesn't have an interrupt line, we observe a
deadlock on caused by trying to lock drm device's mode_config.mutex twice
in the same context.
Here is the sequence that causes it:
ioctl DRM_IOCTL_MODE_GETCONNECTOR from userspace
drm_mode_getconnector (acquires mode_config mutex)
connector->fill_modes()
drm_helper_probe_single_connector_modes
connector_funcs->get_modes
adv7511_encoder_get_modes
adv7511_get_edid_block
adv7511_irq_process
drm_helper_hpd_irq_event (acquires mode_config mutex again)
In adv7511_irq_process, don't call drm_helper_hpd_irq_event when not
called from the interrupt handler. It doesn't serve any purpose there
anyway.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Thong Ho <thong.ho.px@rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d0be8584b0 upstream.
The interrupts for EDID_READY or DDC_ERROR were never enabled in this
driver, so reading EDID always timed out when chip was powered down and
interrupts were used. Fix this and also remove clearing the interrupt
flags, they are cleared in POWER_DOWN mode anyhow (unlike the interrupt
enable flags) according to docs and my tests.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Thong Ho <thong.ho.px@rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8d26f49111 upstream.
Commit 1bc0eb0446 ("scsi: sg: protect accesses to 'reserved' page
array") adds needed concurrency protection for the "reserve" buffer.
Some checks that are initially made outside the lock are replicated once
the lock is taken to ensure the checks and resulting decisions are made
using consistent state.
The check that a request with flag SG_FLAG_MMAP_IO set fits in the
reserve buffer also needs to be performed again under the lock to ensure
the reserve buffer length compared against matches the value in effect
when the request is linked to the reserve buffer. An -ENOMEM should be
returned in this case, instead of switching over to an indirect buffer
as for non-MMAP_IO requests.
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6a8dadcca8 upstream.
Take f_mutex around mmap() processing to protect against races with the
SG_SET_RESERVED_SIZE ioctl. Ensure the reserve buffer length remains
consistent during the mapping operation, and set the "mmap called" flag
to prevent further changes to the reserved buffer size as an atomic
operation with the mapping.
[mkp: fixed whitespace]
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
