Cleaned up and updated the driver for the
end-to-end scenario of XR reference device
connecting with the Remote VR controllers.
Change-Id: I1cb725c331b808addc7c5b8af0422ce616fa7f03
Signed-off-by: Wei Tan <quic_weitan@quicinc.com>
commit 17839856fd588f4ab6b789f482ed3ffd7c403e1f upstream.
Doing a "get_user_pages()" on a copy-on-write page for reading can be
ambiguous: the page can be COW'ed at any time afterwards, and the
direction of a COW event isn't defined.
Yes, whoever writes to it will generally do the COW, but if the thread
that did the get_user_pages() unmapped the page before the write (and
that could happen due to memory pressure in addition to any outright
action), the writer could also just take over the old page instead.
End result: the get_user_pages() call might result in a page pointer
that is no longer associated with the original VM, and is associated
with - and controlled by - another VM having taken it over instead.
So when doing a get_user_pages() on a COW mapping, the only really safe
thing to do would be to break the COW when getting the page, even when
only getting it for reading.
At the same time, some users simply don't even care.
For example, the perf code wants to look up the page not because it
cares about the page, but because the code simply wants to look up the
physical address of the access for informational purposes, and doesn't
really care about races when a page might be unmapped and remapped
elsewhere.
This adds logic to force a COW event by setting FOLL_WRITE on any
copy-on-write mapping when FOLL_GET (or FOLL_PIN) is used to get a page
pointer as a result.
The current semantics end up being:
- __get_user_pages_fast(): no change. If you don't ask for a write,
you won't break COW. You'd better know what you're doing.
- get_user_pages_fast(): the fast-case "look it up in the page tables
without anything getting mmap_sem" now refuses to follow a read-only
page, since it might need COW breaking. Which happens in the slow
path - the fast path doesn't know if the memory might be COW or not.
- get_user_pages() (including the slow-path fallback for gup_fast()):
for a COW mapping, turn on FOLL_WRITE for FOLL_GET/FOLL_PIN, with
very similar semantics to FOLL_FORCE.
If it turns out that we want finer granularity (ie "only break COW when
it might actually matter" - things like the zero page are special and
don't need to be broken) we might need to push these semantics deeper
into the lookup fault path. So if people care enough, it's possible
that we might end up adding a new internal FOLL_BREAK_COW flag to go
with the internal FOLL_COW flag we already have for tracking "I had a
COW".
Alternatively, if it turns out that different callers might want to
explicitly control the forced COW break behavior, we might even want to
make such a flag visible to the users of get_user_pages() instead of
using the above default semantics.
But for now, this is mostly commentary on the issue (this commit message
being a lot bigger than the patch, and that patch in turn is almost all
comments), with that minimal "enable COW breaking early" logic using the
existing FOLL_WRITE behavior.
[ It might be worth noting that we've always had this ambiguity, and it
could arguably be seen as a user-space issue.
You only get private COW mappings that could break either way in
situations where user space is doing cooperative things (ie fork()
before an execve() etc), but it _is_ surprising and very subtle, and
fork() is supposed to give you independent address spaces.
So let's treat this as a kernel issue and make the semantics of
get_user_pages() easier to understand. Note that obviously a true
shared mapping will still get a page that can change under us, so this
does _not_ mean that get_user_pages() somehow returns any "stable"
page ]
[surenb: backport notes
Replaced (gup_flags | FOLL_WRITE) with write=1 in gup_pgd_range.
Removed FOLL_PIN usage in should_force_cow_break since it's missing in
the earlier kernels.]
Change-Id: I6ae007f29a538767fddccf3306264e892f9134ab
Reported-by: Jann Horn <jannh@google.com>
Tested-by: Christoph Hellwig <hch@lst.de>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Kirill Shutemov <kirill@shutemov.name>
Acked-by: Jan Kara <jack@suse.cz>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[surenb: backport to 4.19 kernel]
Cc: stable@vger.kernel.org # 4.19.x
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 5e24029791
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Srinivasarao Pathipati <quic_c_spathi@quicinc.com>
There is possibility of a momentary SOC jump after we
exit the FVSS loop. Fix this by updating the msoc
on every FVSS soc update to make sure the soc value in
hardware tracks the FVSS scaled value.
Change-Id: I7a5638551615cc0d6da7171b05ffb2496cac4381
Signed-off-by: Rakesh Kota <quic_kotarake@quicinc.com>
In disable datapth API configuring HOLB timer value to zero, it will
help if any pending packets before stop channel it helps. So adding
changes to call disable datapath API before stopping the channel.
Change-Id: Ic053bdd7b1aa45b51b746b69e83808f16e4e12a1
Signed-off-by: Sivakanth Vaka <quic_svaka@quicinc.com>
In msm-4.19, since we are using debugfs there is no struct
as seq_file. seq_file is introduced msm-5.4 onwards where
procfs is used.
Change-Id: I1e4571431f3847b115844e8eae41d6b559e40ef9
Signed-off-by: Sonal Aggarwal <quic_sonaagga@quicinc.com>
Add check for channel ID in fastrpc_buf_alloc to
fix out of bounds access.
Change-Id: I92f2717edcc91c19309589ce7c11c91c8129b71a
Acked-by: Abhinav Parihar <parihar@qti.qualcomm.com>
Signed-off-by: Vamsi Krishna Gattupalli <quic_vgattupa@quicinc.com>
Add ioctrl cmds for writing mac address to eeprom.
Change-Id: If96b0ce23db594c061aacda43c93c12ac187b271
Signed-off-by: Jiaxing Shi <quic_jiaxshi@quicinc.com>
dp aux config change by usb mode & orientation.
Change-Id: Ice36032ad5f7d1c67cf79f43a26fe73726df955b
Signed-off-by: xiangxuy <quic_xiangxuy@quicinc.com>
Untrusted application can attach to guestOS and staticPD if it can
somehow make INIT IOCTL call with ATTACH flag. This is a potential
security issue as the untrusted application can crash guestOS or
staticPD. Restrict attach to guestOS or staticPD request if request
is being made using non-secure device node.
Change-Id: I322c7b242fd0baaf1c1bce2d83b992fecb0ca593
Acked-by: Ekansh Gupta <ekangupt@qti.qualcomm.com>
Signed-off-by: Vamsi Krishna Gattupalli <quic_vgattupa@quicinc.com>
Adding a change to check whether the pipe has been
setup or not first before going to teardown the pipe.
Change-Id: Ibb408fdf3509facd6c18e3238bdbfd7da0b4a643
Signed-off-by: Jagadeesh Ponduru <quic_jponduru@quicinc.com>
We must flush all the dirty data when enabling checkpoint back. Let's guarantee
that first by adding a retry logic on sync_inodes_sb(). In addition to that,
this patch adds to flush data in fsync when checkpoint is disabled, which can
mitigate the sync_inodes_sb() failures in advance.
Change-Id: Ia79be96c2fefceeeb862c7d9c7dffc028a7c2762
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Git-commit: 6608ba097f
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
Signed-off-by: Sayali Lokhande <quic_sayalil@quicinc.com>
During checkpoint=disable period, f2fs bypasses all the synchronous IOs such as
sync and fsync. So, when enabling it back, we must flush all of them in order
to keep the data persistent. Otherwise, suddern power-cut right after enabling
checkpoint will cause data loss.
Change-Id: I60dbaf9c720372c76f1c384446383dd8ff1ea4e9
Fixes: 4354994f097d ("f2fs: checkpoint disabling")
Cc: stable@vger.kernel.org
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Git-commit: 046c59c130
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
Signed-off-by: Sayali Lokhande <quic_sayalil@quicinc.com>
From IPAv4.5 versions IPA_TOS_EQ is considered as not supported
and it made to 0XFF, instead IPA_IS_PURE_ACK is given support.
So, when validating the bitfield equations of them passing
eq_bitfield[i] will throw shift overflow warning as it takes 0xFF.
So, added change to ensure there are no overflow warnings.
Change-Id: I84384723433706784a4ef21b88f33b036edb0a5d
Signed-off-by: Jagadeesh Ponduru <quic_jponduru@quicinc.com>
Add support for getting soc-id and dummy handle
on Kona-7230.
Change-Id: I1c93ffd1d3b2575549d39390f18dddc85bf5d8e8
Signed-off-by: Chetan C R <quic_cchinnad@quicinc.com>
Each cset (css_set) is pinned by its tasks. When we're moving tasks around
across csets for a migration, we need to hold the source and destination
csets to ensure that they don't go away while we're moving tasks about. This
is done by linking cset->mg_preload_node on either the
mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the
same cset->mg_preload_node for both the src and dst lists was deemed okay as
a cset can't be both the source and destination at the same time.
Unfortunately, this overloading becomes problematic when multiple tasks are
involved in a migration and some of them are identity noop migrations while
others are actually moving across cgroups. For example, this can happen with
the following sequence on cgroup1:
#1> mkdir -p /sys/fs/cgroup/misc/a/b
#2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs
#3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &
#4> PID=$!
#5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks
#6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs
the process including the group leader back into a. In this final migration,
non-leader threads would be doing identity migration while the group leader
is doing an actual one.
After #3, let's say the whole process was in cset A, and that after #4, the
leader moves to cset B. Then, during #6, the following happens:
1. cgroup_migrate_add_src() is called on B for the leader.
2. cgroup_migrate_add_src() is called on A for the other threads.
3. cgroup_migrate_prepare_dst() is called. It scans the src list.
4. It notices that B wants to migrate to A, so it tries to A to the dst
list but realizes that its ->mg_preload_node is already busy.
5. and then it notices A wants to migrate to A as it's an identity
migration, it culls it by list_del_init()'ing its ->mg_preload_node and
putting references accordingly.
6. The rest of migration takes place with B on the src list but nothing on
the dst list.
This means that A isn't held while migration is in progress. If all tasks
leave A before the migration finishes and the incoming task pins it, the
cset will be destroyed leading to use-after-free.
This is caused by overloading cset->mg_preload_node for both src and dst
preload lists. We wanted to exclude the cset from the src list but ended up
inadvertently excluding it from the dst list too.
This patch fixes the issue by separating out cset->mg_preload_node into
->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst
preloadings don't interfere with each other.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Mukesh Ojha <quic_mojha@quicinc.com>
Reported-by: shisiyuan <shisiyuan19870131@gmail.com>
Link: http://lkml.kernel.org/r/1654187688-27411-1-git-send-email-shisiyuan@xiaomi.com
Link: https://www.spinics.net/lists/cgroups/msg33313.html
Fixes: f817de9851 ("cgroup: prepare migration path for unified hierarchy")
Cc: stable@vger.kernel.org # v3.16+
(cherry picked from commit 07fd5b6cdf3cc30bfde8fe0f644771688be04447
https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-5.19-fixes)
Bug: 235577024
Change-Id: Ieaf1c0c8fc23753570897fd6e48a54335ab939ce
Signed-off-by: Steve Muckle <smuckle@google.com>
Git-commit: d1faa010ca160216a17435b81c642daf08ecbcbd
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Srinivasarao Pathipati <quic_c_spathi@quicinc.com>
Add Page Read, writeDelayUSEC and Continuous Read support in
camera i2c operations.
Change-Id: I58e269477c8158dd1cc394925cb7a3d175546b0a
Signed-off-by: Gaurav Jindal <quic_gjindal@quicinc.com>
Untrusted application can attach to guestOS and staticPD if it can
somehow make INIT IOCTL call with ATTACH flag. This is a potential
security issue as the untrusted application can crash guestOS or
staticPD. Restrict attach to guestOS or staticPD request if request
is being made using non-secure device node.
Change-Id: I322c7b242fd0baaf1c1bce2d83b992fecb0ca593
Acked-by: Ekansh Gupta <ekangupt@qti.qualcomm.com>
Signed-off-by: Vamsi Krishna Gattupalli <quic_vgattupa@quicinc.com>
Possible divide by zero can occur in wait_active_percent
calculation as reported by UBSAN. Fix this possible
division by zero.
Change-Id: I9068fbcc9347eade8a51c7fc3526491511188f03
Signed-off-by: Pranav Patel <quic_pranavp@quicinc.com>
Map the permission gating RTM_GETNEIGH/RTM_GETNEIGHTBL messages to a
new permission so that it can be distinguished from the other netlink
route permissions in selinux policy. The new permission is triggered by
a flag set in system images T and up.
This change is intended to be backported to all kernels that a T system
image can run on top of.
Bug: 171572148
Test: atest NetworkInterfaceTest
Test: atest CtsSelinuxTargetSdkCurrentTestCases
Test: atest bionic-unit-tests-static
Test: On Cuttlefish, run combinations of:
- Policy bit set or omitted (see https://r.android.com/1701847)
- This patch applied or omitted
- App having nlmsg_readneigh permission or not
Verify that only the combination of this patch + the policy bit being
set + the app not having the nlmsg_readneigh permission prevents the
app from sending RTM_GETNEIGH messages.
Change-Id: I4bcfce4decb34ea9388eeedfc4be67403de8a980
Signed-off-by: Bram Bonné <brambonne@google.com>
(cherry picked from commit fac07550bdac9adea0dbe3edbdbec7a9a690a178)
Git-commit: 19c8fef96d
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Srinivasarao Pathipati <quic_c_spathi@quicinc.com>
Cleaned up the controller driver and formatted the driver.
Change-Id: Iaf6e796503f5c4ad0646511454f2b01960fa7315
Signed-off-by: Rajesh Bharathwaj <quic_rabharat@quicinc.com>
qctecmdr