A-Team_Digital_Solutions/android_kernel_motorola_sm6375
Watch
2
0
Fork
You've already forked android_kernel_motorola_sm6375
 0
mirror of https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git synced 2026-10-09 13:49:24 -04:00
Code Issues Projects Releases Packages Wiki Activity
No description
884,354 commits 10 branches 0 tags 2.1 GiB
  • C 98.2%
  • Assembly 1%
  • Makefile 0.3%
  • Shell 0.2%
  • Python 0.1%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Minchan Kim f4ed73112f mm/madvise: introduce process_madvise() syscall: an external memory hinting API 
There is usecase that System Management Software(SMS) want to give a
memory hint like MADV_[COLD|PAGEEOUT] to other processes and in the
case of Android, it is the ActivityManagerService.

The information required to make the reclaim decision is not known to
the app.  Instead, it is known to the centralized userspace
daemon(ActivityManagerService), and that daemon must be able to
initiate reclaim on its own without any app involvement.

To solve the issue, this patch introduces a new syscall
process_madvise(2).  It uses pidfd of an external process to give the
hint.

 int process_madvise(int pidfd, void *addr, size_t length, int advice,
			unsigned long flags);

Since it could affect other process's address range, only privileged
process(CAP_SYS_PTRACE) or something else(e.g., being the same UID)
gives it the right to ptrace the process could use it successfully.
The flag argument is reserved for future use if we need to extend the
API.

I think supporting all hints madvise has/will supported/support to
process_madvise is rather risky.  Because we are not sure all hints
make sense from external process and implementation for the hint may
rely on the caller being in the current context so it could be
error-prone.  Thus, I just limited hints as MADV_[COLD|PAGEOUT] in this
patch.

If someone want to add other hints, we could hear hear the usecase and
review it for each hint.  It's safer for maintenance rather than
introducing a buggy syscall but hard to fix it later.

Q.1 - Why does any external entity have better knowledge?

Quote from Sandeep

"For Android, every application (including the special SystemServer)
are forked from Zygote.  The reason of course is to share as many
libraries and classes between the two as possible to benefit from the
preloading during boot.

After applications start, (almost) all of the APIs end up calling into
this SystemServer process over IPC (binder) and back to the
application.

In a fully running system, the SystemServer monitors every single
process periodically to calculate their PSS / RSS and also decides
which process is "important" to the user for interactivity.

So, because of how these processes start _and_ the fact that the
SystemServer is looping to monitor each process, it does tend to *know*
which address range of the application is not used / useful.

Besides, we can never rely on applications to clean things up
themselves.  We've had the "hey app1, the system is low on memory,
please trim your memory usage down" notifications for a long time[1].
They rely on applications honoring the broadcasts and very few do.

So, if we want to avoid the inevitable killing of the application and
restarting it, some way to be able to tell the OS about unimportant
memory in these applications will be useful.

- ssp

Q.2 - How to guarantee the race(i.e., object validation) between when
giving a hint from an external process and get the hint from the target
process?

process_madvise operates on the target process's address space as it
exists at the instant that process_madvise is called.  If the space
target process can run between the time the process_madvise process
inspects the target process address space and the time that
process_madvise is actually called, process_madvise may operate on
memory regions that the calling process does not expect.  It's the
responsibility of the process calling process_madvise to close this
race condition.  For example, the calling process can suspend the
target process with ptrace, SIGSTOP, or the freezer cgroup so that it
doesn't have an opportunity to change its own address space before
process_madvise is called.  Another option is to operate on memory
regions that the caller knows a priori will be unchanged in the target
process.  Yet another option is to accept the race for certain
process_madvise calls after reasoning that mistargeting will do no
harm.  The suggested API itself does not provide synchronization.  It
also apply other APIs like move_pages, process_vm_write.

The race isn't really a problem though.  Why is it so wrong to require
that callers do their own synchronization in some manner?  Nobody
objects to write(2) merely because it's possible for two processes to
open the same file and clobber each other's writes --- instead, we tell
people to use flock or something.  Think about mmap.  It never
guarantees newly allocated address space is still valid when the user
tries to access it because other threads could unmap the memory right
before.  That's where we need synchronization by using other API or
design from userside.  It shouldn't be part of API itself.  If someone
needs more fine-grained synchronization rather than process level,
there were two ideas suggested - cookie[2] and anon-fd[3].  Both are
applicable via using last reserved argument of the API but I don't
think it's necessary right now since we have already ways to prevent
the race so don't want to add additional complexity with more
fine-grained optimization model.

To make the API extend, it reserved an unsigned long as last argument
so we could support it in future if someone really needs it.

Q.3 - Why doesn't ptrace work?

Injecting an madvise in the target process using ptrace would not work
for us because such injected madvise would have to be executed by the
target process, which means that process would have to be runnable and
that creates the risk of the abovementioned race and hinting a wrong
VMA.  Furthermore, we want to act the hint in caller's context, not the
callee's, because the callee is usually limited in cpuset/cgroups or
even freezed state so they can't act by themselves quick enough, which
causes more thrashing/kill.  It doesn't work if the target process are
ptraced(e.g., strace, debugger, minidump) because a process can have at
most one ptracer.

[1] https://developer.android.com/topic/performance/memory"

[2] process_getinfo for getting the cookie which is updated whenever
    vma of process address layout are changed - Daniel Colascione -
    https://lore.kernel.org/lkml/20190520035254.57579-1-minchan@kernel.org/T/#m7694416fd179b2066a2c62b5b139b14e3894e224

[3] anonymous fd which is used for the object(i.e., address range)
    validation - Michal Hocko -
    https://lore.kernel.org/lkml/20200120112722.GY18451@dhcp22.suse.cz/

Conflicts:
	arch/alpha/kernel/syscalls/syscall.tbl
	arch/arm/tools/syscall.tbl
	arch/arm64/include/asm/unistd.h
	arch/arm64/include/asm/unistd32.h
	arch/ia64/kernel/syscalls/syscall.tbl
	arch/m68k/kernel/syscalls/syscall.tbl
	arch/microblaze/kernel/syscalls/syscall.tbl
	arch/mips/kernel/syscalls/syscall_n32.tbl
	arch/mips/kernel/syscalls/syscall_n64.tbl
	arch/parisc/kernel/syscalls/syscall.tbl
	arch/powerpc/kernel/syscalls/syscall.tbl
	arch/s390/kernel/syscalls/syscall.tbl
	arch/sh/kernel/syscalls/syscall.tbl
	arch/sparc/kernel/syscalls/syscall.tbl
	arch/x86/entry/syscalls/syscall_32.tbl
	arch/x86/entry/syscalls/syscall_64.tbl
	arch/xtensa/kernel/syscalls/syscall.tbl
	include/uapi/asm-generic/unistd.h

Link: http://lkml.kernel.org/r/20200302193630.68771-3-minchan@kernel.org
Link: http://lkml.kernel.org/r/20200508183320.GA125527@google.com
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: Daniel Colascione <dancol@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Dias <joaodias@google.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oleksandr Natalenko <oleksandr@redhat.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: SeongJae Park <sj38.park@gmail.com>
Cc: SeongJae Park <sjpark@amazon.de>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Sonny Rao <sonnyrao@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: <linux-man@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Git-commit: 8422ccd91057d2814466d90ed05d44b359e88ba9
Git-Repo: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
[charante@codeaurora.org: Fixed merged conflicts]
Change-Id: I187d2a764db09f0868cd11c7536d7a1ed6a54f3a
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
2020-06-18 17:55:54 +05:30
arch mm/madvise: introduce process_madvise() syscall: an external memory hinting API 2020-06-18 17:55:54 +05:30
block block, bfq: fix use-after-free in bfq_idle_slice_timer_body 2020-05-31 22:25:00 -07:00
certs
crypto
Documentation add documentation about reclaim knob on proc.txt 2020-06-02 21:31:18 -07:00
drivers Merge "scsi: ufs: Dump PA_VS_STATUS_REG1 in eh" 2020-06-17 08:24:01 -07:00
fs sched: Improve the scheduler 2020-06-10 15:35:30 -07:00
include mm/madvise: introduce process_madvise() syscall: an external memory hinting API 2020-06-18 17:55:54 +05:30
init Merge "sched: Improve the scheduler" 2020-06-10 11:30:47 -07:00
ipc
kernel mm/madvise: introduce process_madvise() syscall: an external memory hinting API 2020-06-18 17:55:54 +05:30
lib Merge "lib: stackdepot: Add support to configure STACK_HASH_SIZE" 2020-06-15 06:15:38 -07:00
LICENSES
mm mm/madvise: introduce process_madvise() syscall: an external memory hinting API 2020-06-18 17:55:54 +05:30
net ANDROID: net: bpf: permit redirect from ingress L3 to egress L2 devices at near max mtu 2020-06-15 08:09:10 -06:00
samples
scripts scripts: gki: Add support for qgki-consolidate_defconfig 2020-06-12 13:14:25 -07:00
security RTIC: Move selinux_state to a separate 4k 2020-06-08 15:49:07 +05:30
sound sound: usb: Increase upper bound check for bInterval to 16 2020-06-10 12:46:56 -07:00
techpack
tools
usr
virt
.clang-format
.cocciconfig
.get_maintainer.ignore
.gitattributes
.gitignore .gitignore: ignore GKI generated defconfigs 2020-06-12 13:14:26 -07:00
.mailmap
abi_gki_aarch64.xml
abi_gki_aarch64_5cfdde5ea8.xml aarch64: ABI: Update the QCOM whitelist 2020-06-09 06:37:53 -07:00
abi_gki_aarch64_cuttlefish_whitelist
abi_gki_aarch64_db845c_whitelist
abi_gki_aarch64_goldfish_whitelist
abi_gki_aarch64_hikey960_whitelist
abi_gki_aarch64_qcom_internal_whitelist Merge "ABI: Update internal whitelist with debugfs symbols" 2020-06-15 02:08:39 -07:00
abi_gki_aarch64_qcom_whitelist qcom: whitelist: Remove symbol from whitelist 2020-06-09 22:33:37 -07:00
abi_gki_aarch64_unisoc_whitelist
abi_gki_aarch64_whitelist
Android.bp
build.config.aarch64
build.config.allmodconfig
build.config.allmodconfig.aarch64
build.config.allmodconfig.arm
build.config.allmodconfig.x86_64
build.config.arm
build.config.common build.config: Add build.config files for Lahaina 2020-06-09 14:25:37 -06:00
build.config.db845c
build.config.gki
build.config.gki-debug.aarch64
build.config.gki-debug.x86_64
build.config.gki.aarch64
build.config.gki.x86_64
build.config.hikey960
build.config.msm.common build.config: Add build.config files for Lahaina 2020-06-09 14:25:37 -06:00
build.config.msm.gki build.config: Add build.config files for Lahaina 2020-06-09 14:25:37 -06:00
build.config.msm.lahaina build.config: Add build.config files for Lahaina 2020-06-09 14:25:37 -06:00
build.config.x86_64
build.targets build.config: Add build.config files for Lahaina 2020-06-09 14:25:37 -06:00
COPYING
CREDITS
gen_headers_arm.bp Merge "taskstats: add support for system stats" 2020-06-09 14:25:01 -07:00
gen_headers_arm64.bp Merge "taskstats: add support for system stats" 2020-06-09 14:25:01 -07:00
Kbuild
Kconfig
kernel_headers.py
MAINTAINERS
Makefile Makefile: Add a check of CONFIG_TRIM_UNUSED_KSYMS before remaking vmlinux 2020-05-21 12:53:35 -07:00
modules.list.msm.lahaina build.config: Add build.config files for Lahaina 2020-06-09 14:25:37 -06:00
README
README.md

README.md

How do I submit patches to Android Common Kernels

  1. BEST: Make all of your changes to upstream Linux. If appropriate, backport to the stable releases. These patches will be merged automatically in the corresponding common kernels. If the patch is already in upstream Linux, post a backport of the patch that conforms to the patch requirements below.

  2. LESS GOOD: Develop your patches out-of-tree (from an upstream Linux point-of-view). Unless these are fixing an Android-specific bug, these are very unlikely to be accepted unless they have been coordinated with kernel-team@android.com. If you want to proceed, post a patch that conforms to the patch requirements below.

Common Kernel patch requirements

  • All patches must conform to the Linux kernel coding standards and pass script/checkpatch.pl
  • Patches shall not break gki_defconfig or allmodconfig builds for arm, arm64, x86, x86_64 architectures (see https://source.android.com/setup/build/building-kernels)
  • If the patch is not merged from an upstream branch, the subject must be tagged with the type of patch: UPSTREAM:, BACKPORT:, FROMGIT:, FROMLIST:, or ANDROID:.
  • All patches must have a Change-Id: tag (see https://gerrit-review.googlesource.com/Documentation/user-changeid.html)
  • If an Android bug has been assigned, there must be a Bug: tag.
  • All patches must have a Signed-off-by: tag by the author and the submitter

Additional requirements are listed below based on patch type

Requirements for backports from mainline Linux: UPSTREAM:, BACKPORT:

  • If the patch is a cherry-pick from Linux mainline with no changes at all
    • tag the patch subject with UPSTREAM:.
    • add upstream commit information with a (cherry-picked from ...) line
    • Example:
      • if the upstream commit message is
        important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

    - then Joe Smith would upload the patch for the common kernel as

        UPSTREAM: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry-picked from c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        Signed-off-by: Joe Smith <joe.smith@foo.org>
  • If the patch requires any changes from the upstream version, tag the patch with BACKPORT: instead of UPSTREAM:.
    • use the same tags as UPSTREAM:
    • add comments about the changes under the (cherry-picked from ...) line
    • Example:
        BACKPORT: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry-picked from c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        [ Resolved minor conflict in drivers/foo/bar.c ]
        Signed-off-by: Joe Smith <joe.smith@foo.org>

Requirements for other backports: FROMGIT:, FROMLIST:,

  • If the patch has been merged into an upstream maintainer tree, but has not yet been merged into Linux mainline
    • tag the patch subject with FROMGIT:
    • add info on where the patch came from as (cherry picked from commit <sha1> <repo> <branch>). This must be a stable maintainer branch (not rebased, so don't use linux-next for example).
    • if changes were required, use BACKPORT: FROMGIT:
    • Example:
      • if the commit message in the maintainer tree is
        important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

    - then Joe Smith would upload the patch for the common kernel as

        FROMGIT: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        (cherry picked from commit 878a2fd9de10b03d11d2f622250285c7e63deace
         https://git.kernel.org/pub/scm/linux/kernel/git/foo/bar.git test-branch)
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>
  • If the patch has been submitted to LKML, but not accepted into any maintainer tree
    • tag the patch subject with FROMLIST:
    • add a Link: tag with a link to the submittal on lore.kernel.org
    • if changes were required, use BACKPORT: FROMLIST:
    • Example:
        FROMLIST: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Link: https://lore.kernel.org/lkml/20190619171517.GA17557@someone.com/
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>

Requirements for Android-specific patches: ANDROID:

  • If the patch is fixing a bug to Android-specific code
    • tag the patch subject with ANDROID:
    • add a Fixes: tag that cites the patch with the bug
    • Example:
        ANDROID: fix android-specific bug in foobar.c

        This is the detailed description of the important fix

        Fixes: 1234abcd2468 ("foobar: add cool feature")
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>
  • If the patch is a new feature
    • tag the patch subject with ANDROID:
    • add a Bug: tag with the Android bug (required for android-specific features)