Avoid waking up every thread sleeping in an epoll_wait call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Bug: 77139736
Bug: 120440023
[ccross: This was upstream (https://lkml.org/lkml/2013/5/6/823), but
reverted because it reportedly caused memory corruption on
32-bit x86 (https://patchwork.kernel.org/patch/3162301/).]
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[gregkh: add this back after the 5.11-rc1 merge mess]
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia8268d310c00f0cfa6c01f36f3fa528e04f206e0
It causes big merge issues with a 5.11-rc1 merge point, so revert this
patch for now, hopefully we can add it back at a later point...
Bug: 77139736
Bug: 120440023
Cc: Colin Cross <ccross@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I4915482c510a7c7b19db60161a031b70ec75d66c
Steps on the way to 5.11-rc1
Resolves conflicts in:
drivers/dma-buf/heaps/cma_heap.c
drivers/dma-buf/heaps/system_heap.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iac498252911dd67ee21bba42b3fa5a2324dd43e0
Enable shared memory driver so it can be used by clients
like SCMI on arm64.
Bug: 176065611
Change-Id: Idad0d42bec764ae7ecfa0672d32d4be29b0881d6
Signed-off-by: Amir Vajid <avajid@codeaurora.org>
This reverts commit f1ee68a8f6.
Reason for revert:
The change being reverted adds a new "lockdown" audit class. Support
for this new class needs to be added to Android and the processes
which need to be part of this class have to be annotated. While support
for this class has not yet been added to Android, this lockdown class
will be removed.
Tracefs usage by Android triggers a violation with respect to this new
audit class which prompted the need for this patch.
Bug: 148822198
Change-Id: Ie06f4be699234fb671ec4bcfe11962b2055a0c60
Signed-off-by: Ram Muthiah <rammuthiah@google.com>
The UML random driver creates a dummy device under the guest,
/dev/hw_random. When this file is read from the guest, the driver
reads from the host machine's /dev/random, in-turn reading from
the host kernel's entropy pool. This entropy pool could have been
filled by a hardware random number generator or just the host
kernel's internal software entropy generator.
Currently the driver does not fill the guests kernel entropy pool,
this requires a userspace tool running inside the guest (like
rng-tools) to read from the dummy device provided by this driver,
which then would fill the guest's internal entropy pool.
This all seems quite pointless when we are already reading from an
entropy pool, so this patch aims to register the device as a hwrng
device using the hwrng-core framework. This not only improves and
cleans up the driver, but also fills the guest's entropy pool
without having to resort to using extra userspace tools in the guest.
This is typically a nuisance when booting a guest: the random pool
takes a long time (~200s) to build up enough entropy since the dummy
hwrng is not used to fill the guest's pool.
This port was originally attempted by Alexander Neville "dark" (in CC,
discussion in Link), but the conversation there stalled since the
handling of -EAGAIN errors were no removed and longer handled by the
driver. This patch attempts to use the existing method of error
handling but utilises the new hwrng core.
The issue can be noticed when booting a UML guest:
[ 2.560000] random: fast init done
[ 214.000000] random: crng init done
With the patch applied, filling the pool becomes a lot quicker:
[ 2.560000] random: fast init done
[ 12.000000] random: crng init done
Bug: 176213565
Cc: Alexander Neville <dark@volatile.bz>
Link: https://lore.kernel.org/lkml/20190828204609.02a7ff70@TheDarkness/
Link: https://lore.kernel.org/lkml/20190829135001.6a5ff940@TheDarkness.local/
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 72d3e093af)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I79e16fa07ef93ae32d425e2e19fedd669f853518
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Bug: 176213565
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit db03b42827)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1f77c36f00370d81bb9d1ae37b23c5da350f8061
Something is really b0rked with this branch and tree-hugger, so let's
just revert the whole thing to keep the merges flowing, and we will add
the individual patches back "by hand" to catch up and find the
offender(s).
Bug: 176213565
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id7f84b59824451a35542723790f71b29e4f4df8a
f_accessory: fix CTS test stuck since CTS 9.0.
- Refine acc_read() process.
The data length that user (test program) wants to read is different
from they really requested. This will cause the test flow stuck on the
2nd or the 3rd transfers in accessory test.
(By connecting 2 phones with CtsVerifier.apk and
CtsVerifierUSBCompanion.apk installed.)
Bug: 174729307
Change-Id: I5367c8075ed37534e8bed94b60cc79135ae5aebc
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
CRYPTO_MD5 is needed to guarantee legacy compatibility with 3gpp
infrastructure. This compat is guaranteed by the vts net tests
which are currently failing due to this missing config.
Bug: 171462501
Signed-off-by: Ram Muthiah <rammuthiah@google.com>
Change-Id: Ibb5bff947595058a0970ae8bbd64c5f5eab8ba7d
The MSM_PINCTRL is no longer a selected option but a dependency,
so we need to add the config explictly in the fragment.
Fixes: be117ca322 ("pinctrl: qcom: Kconfig: Rework PINCTRL_MSM to be a depenency rather then a selected config")
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: Ib77f8d645b33c3879afe9e9e4cdf177eecf04b31
This reverts commit 6120a4d780 as it did
not make it into 5.11-rc1 and causes massive merge issues. If needed,
please forward-port and add it back.
Cc: Mark Salyzyn <salyzyn@android.com>
Bug: 133515582
Bug: 136124883
Bug: 129319403
Change-Id: Ib896e744640d570918af498e1f2bd42d66c33471
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 710cc7493c as it
causes massive merge issues with 5.11-rc1.
If needed, please bring it back.
Cc: Mark Salyzyn <salyzyn@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Bug: 169988379
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I24d2a761c537d845cfaabcc89af3a5775ff6a94b
Steps on the way to 5.11-rc1
Resolves conflicts in:
fs/fuse/inode.c
include/uapi/linux/fuse.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1e09e7edd8b8d325db685c58fd9c8e52130b7c59
Steps on the way to 5.11-rc1
Resolves conflicts in:
drivers/soc/qcom/rpmh-rsc.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Idc5921088554d0eb5bed7eca94c7fd7ca0fa6fb5
Steps on the way to 5.11-rc1
Resolves conflicts in:
drivers/pinctrl/qcom/Kconfig
drivers/pinctrl/qcom/pinctrl-msm.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0f4cdb211c039fb09b2f28aa7acedf5d34e774cf
Steps on the way to 5.11-rc1
Fixes merge conflicts with:
arch/arm64/include/asm/thread_info.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I45a74bc1e219850bdbc480e5a309dfc216a5c171
Steps on the way to 5.11-rc1
Resolves conflicts in:
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5805a88768279db9f7d9a0c1b9ce29eb32542b2a
Merge still more updates from Andrew Morton:
"18 patches.
Subsystems affected by this patch series: mm (memcg and cleanups) and
epoll"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm/Kconfig: fix spelling mistake "whats" -> "what's"
selftests/filesystems: expand epoll with epoll_pwait2
epoll: wire up syscall epoll_pwait2
epoll: add syscall epoll_pwait2
epoll: convert internal api to timespec64
epoll: eliminate unnecessary lock for zero timeout
epoll: replace gotos with a proper loop
epoll: pull all code between fetch_events and send_event into the loop
epoll: simplify and optimize busy loop logic
epoll: move eavail next to the list_empty_careful check
epoll: pull fatal signal checks into ep_send_events()
epoll: simplify signal handling
epoll: check for events when removing a timed out thread from the wait queue
mm/memcontrol:rewrite mem_cgroup_page_lruvec()
mm, kvm: account kvm_vcpu_mmap to kmemcg
mm/memcg: remove unused definitions
mm/memcg: warning on !memcg after readahead page charged
mm/memcg: bail early from swap accounting if memcg disabled
Add syscall epoll_pwait2, an epoll_wait variant with nsec resolution that
replaces int timeout with struct timespec. It is equivalent otherwise.
int epoll_pwait2(int fd, struct epoll_event *events,
int maxevents,
const struct timespec *timeout,
const sigset_t *sigset);
The underlying hrtimer is already programmed with nsec resolution.
pselect and ppoll also set nsec resolution timeout with timespec.
The sigset_t in epoll_pwait has a compat variant. epoll_pwait2 needs
the same.
For timespec, only support this new interface on 2038 aware platforms
that define __kernel_timespec_t. So no CONFIG_COMPAT_32BIT_TIME.
Link: https://lkml.kernel.org/r/20201121144401.3727659-3-willemdebruijn.kernel@gmail.com
Signed-off-by: Willem de Bruijn <willemb@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We call ep_events_available() under lock when timeout is 0, and then call
it without locks in the loop for the other cases.
Instead, call ep_events_available() without lock for all cases. For
non-zero timeouts, we will recheck after adding the thread to the wait
queue. For zero timeout cases, by definition, user is opportunistically
polling and will have to call epoll_wait again in the future.
Note that this lock was kept in c5a282e963 because the whole loop was
historically under lock.
This patch results in a 1% CPU/RPC reduction in RPC benchmarks.
Link: https://lkml.kernel.org/r/20201106231635.3528496-9-soheil.kdev@gmail.com
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Khazhismel Kumykov <khazhy@google.com>
Cc: Guantao Liu <guantaol@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Patch series "simplify ep_poll".
This patch series is a followup based on the suggestions and feedback by
Linus:
https://lkml.kernel.org/r/CAHk-=wizk=OxUyQPbO8MS41w2Pag1kniUV5WdD5qWL-gq1kjDA@mail.gmail.com
The first patch in the series is a fix for the epoll race in presence of
timeouts, so that it can be cleanly backported to all affected stable
kernels.
The rest of the patch series simplify the ep_poll() implementation. Some
of these simplifications result in minor performance enhancements as well.
We have kept these changes under self tests and internal benchmarks for a
few days, and there are minor (1-2%) performance enhancements as a result.
This patch (of 8):
After abc610e01c ("fs/epoll: avoid barrier after an epoll_wait(2)
timeout"), we break out of the ep_poll loop upon timeout, without checking
whether there is any new events available. Prior to that patch-series we
always called ep_events_available() after exiting the loop.
This can cause races and missed wakeups. For example, consider the
following scenario reported by Guantao Liu:
Suppose we have an eventfd added using EPOLLET to an epollfd.
Thread 1: Sleeps for just below 5ms and then writes to an eventfd.
Thread 2: Calls epoll_wait with a timeout of 5 ms. If it sees an
event of the eventfd, it will write back on that fd.
Thread 3: Calls epoll_wait with a negative timeout.
Prior to abc610e01c, it is guaranteed that Thread 3 will wake up either
by Thread 1 or Thread 2. After abc610e01c, Thread 3 can be blocked
indefinitely if Thread 2 sees a timeout right before the write to the
eventfd by Thread 1. Thread 2 will be woken up from
schedule_hrtimeout_range and, with evail 0, it will not call
ep_send_events().
To fix this issue:
1) Simplify the timed_out case as suggested by Linus.
2) while holding the lock, recheck whether the thread was woken up
after its time out has reached.
Note that (2) is different from Linus' original suggestion: It do not set
"eavail = ep_events_available(ep)" to avoid unnecessary contention (when
there are too many timed-out threads and a small number of events), as
well as races mentioned in the discussion thread.
This is the first patch in the series so that the backport to stable
releases is straightforward.
Link: https://lkml.kernel.org/r/20201106231635.3528496-1-soheil.kdev@gmail.com
Link: https://lkml.kernel.org/r/CAHk-=wizk=OxUyQPbO8MS41w2Pag1kniUV5WdD5qWL-gq1kjDA@mail.gmail.com
Link: https://lkml.kernel.org/r/20201106231635.3528496-2-soheil.kdev@gmail.com
Fixes: abc610e01c ("fs/epoll: avoid barrier after an epoll_wait(2) timeout")
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Tested-by: Guantao Liu <guantaol@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Guantao Liu <guantaol@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Khazhismel Kumykov <khazhy@google.com>
Reviewed-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A VCPU of a VM can allocate couple of pages which can be mmap'ed by the
user space application. At the moment this memory is not charged to the
memcg of the VMM. On a large machine running large number of VMs or
small number of VMs having large number of VCPUs, this unaccounted
memory can be very significant. So, charge this memory to the memcg of
the VMM. Please note that lifetime of these allocations corresponds to
the lifetime of the VMM.
Link: https://lkml.kernel.org/r/20201106202923.2087414-1-shakeelb@google.com
Signed-off-by: Shakeel Butt <shakeelb@google.com>
Acked-by: Roman Gushchin <guro@fb.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
