in our vendor driver, we need the following three kernel variables:
include/linuc/mm.h:
extern unsigned long stack_guard_gap;
extern int sysctl_legacy_va_layout;
include/linux/security.h:
extern unsigned long mmap_min_addr;
Bug: 191439466
Signed-off-by: xieliujie <xieliujie@oppo.com>
Change-Id: I9d1759d8157ddd214475742e417dfb9e870d4b2e
The Gadget API has a theoretical race when a gadget driver is unbound.
Although the pull-up is turned off before the driver's ->unbind
callback runs, if the USB cable were to be unplugged at just the wrong
moment there would be nothing to prevent the UDC driver from invoking
the ->disconnect callback after the unbind has finished. In theory,
other asynchronous callbacks could also happen during the time before
the UDC driver's udc_stop routine is called, and the gadget driver
would not be prepared to handle any of them.
We need a way to tell UDC drivers to stop issuing asynchronous (that is,
->suspend, ->resume, ->disconnect, ->reset, or ->setup) callbacks at
some point after the pull-up has been turned off and before the
->unbind callback runs. This patch adds a new ->udc_async_callbacks
callback to the usb_gadget_ops structure for precisely this purpose,
and it adds the corresponding support to the UDC core.
Later patches in this series add support for udc_async_callbacks to
several UDC drivers.
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20210520202144.GC1216852@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 192984564
Change-Id: Ib50e7292436fe2067cdd6d9e953549f74a2513a9
(cherry picked from commit 7dc0c55e9f)
Signed-off-by: Jack Pham <jackp@codeaurora.org>
There are a lot of different structures that need to have a "frozen" abi
for the next 5+ years. Add padding to a lot of them in order to be able
to handle any future changes that might be needed due to LTS and
security fixes that might come up.
It's a best guess, based on what has happened in the past from the
5.4.0..5.4.129 release (1 1/2 years). Yes, past changes do not mean
that future changes will also be needed in the same area, but that is a
hint that those areas are both well maintained and looked after, and
there have been previous problems found in them.
Also the list of structures that are being required based on OEM usage
in the android/ symbol lists were consulted as that's a larger list than
what has been changed in the past.
Hopefully we caught everything we need to worry about, only time will
tell...
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I880bbcda0628a7459988eeb49d18655522697664
Try to mitigate potential future driver core api changes by padding to
struct bus_type, struct device_driver, struct class, and struct device.
Based on a patch from Michal Marek <mmarek@suse.cz> from the SLES kernel
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6892cde6481ba775789f0c02239dcfde3a26b56e
Try to mitigate potential future driver core api changes by adding a
padding to struct elevator_mq_ops and struct elevator_type.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia4c2667fd5ca9e6dd2e0d30b95a0f8d5eb7921dc
Try to mitigate potential future driver core api changes by adding a
padding to struct scsi_cmnd, struct scsi_device, and struct
scsi_host_template.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie6a2b91970e8f9063bf00e96a0dff661f77b8e8d
Try to mitigate potential future driver core api changes by adding a
padding to struct work_struct and struct delayed_work
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5492a13e2430c1a5775aec52518144b7aa4f3268
Try to mitigate potential future driver core api changes by adding a
padding to struct user_struct and struct sched_domain.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie8f685122767b690a116193aefd8c5e3b6ef8f17
Try to mitigate potential future driver core api changes by adding a
padding to stuct phy_device and struct phy_driver
Inspired by the upstream changes in 5.4.26 and 4.19.111
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8dbc5f76e9eddfc5741f944168222aedacd0a8bb
Try to mitigate potential future driver core api changes by adding a
padding to a bunch of filesystem structures.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Change-Id: Ida6d98d30f292c980ab07e0250fec5268c4c87ed
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Try to mitigate potential future driver core api changes by adding a
padding to struct dentry and struct dentry_operations.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Idde3c6e99bd4af3a91ba115b8ec148e3e1cdd4a9
Try to mitigate potential future driver core api changes by adding a
padding to struct bio_integrity_payload and struct bio_set.
Based on a change made to the RHEL/CENTOS 8 kernel.
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0397ede2e11560ad9422cd7765434fcd4f7a6dd8
Do not sleep for retrying for __GFP_NORERY since it's failfast
mode approach. User could retry the allocation without the flag
by themselves if they see the failure.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ic6a857978fda8e353b9ed770d1e0ba1808fd201e
alloc_contig_range is supposed to work on max(MAX_ORDER_NR_PAGES,
or pageblock_nr_pages) granularity aligned range. If it fails
at a page and return error to user, user doesn't know what page
makes the allocation failure and keep retrying another allocation
with new range including the failed page and encountered error
again and again until it could escape the out of the granularity
block. Instead, let's make CMA aware of what pfn was troubled in
previous trial and then continue to work new pageblock out of the
failed page so it doesn't see the repeated error repeatedly.
Currently, this option works for only __GFP_NORETRY case for
safe for existing CMA users.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I0959c9df3d4b36408a68920abbb4d52d31026079
I found sometime cma allocation took a long time to be succeeded
because one of the pages is in the middle of zapping(e.g., munmap, exit)
so alloc_contig_range couldn't migrate the page because it was zero
page mapcount. So, CMA allocator need to wait it until tlb batching
frees the page and the batching free happens on the target process's
context which is quite random, sometimes, very low priority process
on little core. It makes CMA allocation very slow up to several hundreds
millisecond.
To solve the issue, let's make the TLB free batching aware of CMA
progress so whenever cma allocation is going on, TLB free batching
should bail out asap to minimize cma allocation latency.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ic76ecff795639085c4372791d922301467563a06
lru_cache_disable is not trivial cost since it should run work
from every cores in the system. Thus, repeated call of the
function whenever alloc_contig_range in the cma's allocation loop
is called is expensive.
This patch makes the lru_cache_disable smarter in that it will
not run __lru_add_drain_all since it knows the cache was already
disabled by someone else.
With that, user of alloc_contig_range can disable the lru cache
in advance in their context so that subsequent alloc_contig_range
for user's operation will avoid the costly function call.
This patch moves lru_cache APIs from swap.h to swap.c and export
it for vendor users.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I23da8599c55db49dc80226285972e4cd80dedcff
Currently, alloc_contig_range expects that even though a page fails
with -EBUSY from __alloc_contig_migrate_range, it want to check
those failed pages in test_pages_isolated again with hope that
those page would be freed soon so cma allocatoin would be succeeded.
However, it depends on the luck and I found sometimes test_page_isolated
constantly fails at the page repeatedly whenever cma_alloc retried.
Rather than burning out CPU to check the page's status in
test_pages_isolated for GFP_NORETRY allocation, just bail out and
relies on the user what they want to do.
Currently, this option works for only __GFP_NORETRY case for safe
of existing other users.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I9211452be06960dc7d8f854537e53b3fc5262c8e
alloc_contig_range is the core worker function for CMA allocation
so it has every information to be able to understand allocation
latency. For example, how many pages are migrated, how many time
unmap was needed to migrate pages, how many times it encountered
errors by some reasons.
This patch adds such statistics in the alloc_contig_range and
return it to user so user can use those information to analyize
latency. The cma_alloc is first user for the statistics, which
export the statistics as new trace event(i.e., cma_alloc_info).
It was really usefuli to optimize cma allocation work.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I7be43cc89d11078e2a324d2d06aada6d8e9e1cc9
Currently, pcplists are drained during set_migratetype_isolate() which
means once per pageblock processed start_isolate_page_range(). This is
somewhat wasteful. Moreover, the callers might need different guarantees,
and the draining is currently prone to races and does not guarantee that
no page from isolated pageblock will end up on the pcplist after the
drain.
Better guarantees are added by later patches and require explicit actions
by page isolation users that need them. Thus it makes sense to move the
current imperfect draining to the callers also as a preparation step.
Link: https://lkml.kernel.org/r/20201111092812.11329-7-vbabka@suse.cz
Suggested-by: David Hildenbrand <david@redhat.com>
Suggested-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 7612921f23)
Change-Id: I10fc574024606c499ddda325d188d181aff7ceec
Add a hook to query from vendor's compress driver if it is support pause
in draining and if the platform need to keep in draining state.
Bug: 184020292
Bug: 178992384
Change-Id: Id2e2ff72d7ee66fc633473ec109ed3d8a2baaeff
Signed-off-by: Robert Lee <lerobert@google.com>
This vendor hook let us initialize payload of the request.
Bug: 188749221
Change-Id: I51d6a3010ac0ab36066dbe1368158592832112b7
Signed-off-by: Yang Yang <yang.yang@vivo.com>
This vendor hook let us attach oem data as payload to the request.
The payload is used by oem driver for debugging purpose.
Bug: 188749221
Change-Id: Iac598bd9cce836dac0efe9198a3e7752928f351a
Signed-off-by: Yang Yang <yang.yang@vivo.com>
We need dump task->stack in kernel module for debug usage,
call try_get_task_stack to lock task->stack, and
try_get_task_stack/put_task_stack should call in pairs,
but put_task_stack is not exported
Bug: 192990535
Change-Id: Ifb2f3d16f93039bffeb3e822bc066e42e2d21d13
Signed-off-by: chunhui.li <chunhui.li@mediatek.com>
Add idr_alloc_u32 to the qcom symbol list.
Bug: 193461266
Change-Id: I7415a67a51041c0f7595f9b5c6d96615f3eecc41
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Add vendor hook android_vh_sound_check_support_cpu_suspend
to allow ACPU to suspend during USB playback/capture,
if this is supported.
Bug: 192206510
Change-Id: Ia8d4c335db27de5fcefab13cab653fd1ae34f691
Signed-off-by: JJ Lee <leejj@google.com>
GKI requires EXPORT_SYMBOL_GPL so change it.
Bug: 192475091
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Iba310d0a78f6ddb1e7980177fe7c624d0a0f254a
This patch is for updating GKI allowed symbol list without adding any
new symbol. Next patch will introduce newly added symbols for Exynosauto
SoC GKI vendor modules.
Bug: 193391505
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: I53206b12887add9ff40003dd09f6ff1afa5c027a
Add some help text for CONFIG_CRYPTO_FIPS140_MOD, add a comment for
CONFIG_CRYPTO_FIPS140, and update the file comment for fips140-module.c.
In particular, mention that the module also does self-tests, and that it
is also intended to meet NIAP requirements -- not just FIPS.
Bug: 153614920
Bug: 188620248
Change-Id: If2c316e54fba2c4594e70a14a5a8fa1dba3589a1
Signed-off-by: Eric Biggers <ebiggers@google.com>
Make fips140.ko run a suite of known answer self-tests at load time to
demonstrate the correct operation of cryptographic functionality, as
required by FIPS 140-2/3 and NIAP FPT_TST_EXT.1.1.
Bug: 153614920
Bug: 173104584
Bug: 188620248
Test: Built and loaded fips140.ko on a HiKey960, and on a Pixel device.
Change-Id: I38e5c8052ff57ddfe44624beb626d38b7706b0a4
Co-developed-by: Elena Petrova <lenaptr@google.com>
Signed-off-by: Elena Petrova <lenaptr@google.com>
[ebiggers: Rewrote most of lenaptr@'s original patch. Added some
missing tests, removed some unnecessary tests in accordance with the
FIPS 140-2 IG, changed most test vectors and added a script to generate
them, removed an unnecessary kconfig option, changed implementation of
error injection, and many other improvements.]
Signed-off-by: Eric Biggers <ebiggers@google.com>
[ardb: add generation of AES-CTR test vector and the associated runtime
selftest]
Signed-off-by: Ard Biesheuvel <ardb@google.com>
The arm64 LSE atomics implementation uses both alternatives patching and
jump label patching, both of which need to be selectively disabled when
building the FIPS140 module, or the hashing of the .text section no
longer works.
We already disable jump labels in generic code, but this uncovers a
rather nasty circular include dependency, as the jump label fallback
code uses atomics, which are provided by the LSE code if enabled.
So let's disable LSE as well when building the FIPS140 module: this does
not have any impact on the code, as no code patching goes on in this
module anyway, but it avoids #include hell.
Bug: 153614920
Bug: 188620248
Change-Id: Ia3d823fa3a309777f0c955d619ae8b139dc74061
Signed-off-by: Ard Biesheuvel <ardb@google.com>
The fips140 module doesn't support jump labels, as they would invalidate
the hash of the .text section. So when building the module, switch to
the generic implementation that does not rely on arch-specific code
patching support.
This fixes a failure in check_fips140_module_hmac() caused by the module
containing a call to crypto_alg_put(), which is an inline function that
calls refcount_dec_and_test(), which on arm64 uses a jump label.
Note that the optimized definition of struct static_key is retained, to
ensure ABI compatibility across the FIPS140 module boundary. To ensure
that static keys and their associated jump labels remain in a consistent
state, the fips140 module will not be able to manipulate static keys,
but only to check their state.
Bug: 153614920
Bug: 188620248
Change-Id: Ie834bbf2eed5d09bfae7f387b711a934bedf390d
Signed-off-by: Eric Biggers <ebiggers@google.com>
[ardb: disable jump labels in generic code not in arm64 arch code]
Signed-off-by: Ard Biesheuvel <ardb@google.com>
This patch provides an ipv6 vendor hook which can be used to
disable kernel auto generate the ipv6 link-local address.
The reasons why the kernel does not need to automatically
generate the ipv6 link-local address are as follows:
(1) In the 3GPP TS 29.061, here is a description as follows:
"in order to avoid any conflict between the link-local address
of the MS and that of the GGSN, the Interface-Identifier used
by the MS to build its link-local address shall be assigned by
the GGSN. The GGSN ensures the uniqueness of this Interface-
Identifier. The MT shall then enforce the use of this
Interface-Identifier by the TE"
In other words, in the cellular network, GGSN determines whether
to reply a solicited RA message by identifying the low 64 bits
of the source address of the received RS message. Therefore,
cellular network device's ipv6 link-local address should be set
as the format of fe80::(GGSN assigned IID).
For example: When using a new kernel and ARPHRD_RAWIP, kernel
will generate an EUI64 format ipv6 link-local address, and the
Linux kernel will uses this link-local address to send RS message.
The result is that the GGSN will not reply to the RS message with
a solicited RA message.
For mobile operators that don't need to support RFC7217, setting
addr_gen_mode == 1 is sufficient, it can avoid the above issue,
but when the addr_gen_mode is changed to the
IN6_ADDR_GEN_MODE_STABLE_PRIVACY, the above problem still exist.
The detail as follows:
(2) For some other mobile operators that need to support RFC7217,
the mobile device's addr_gen_mode will be switched to the
IN6_ADDR_GEN_MODE_STABLE_PRIVACY, instead of using
IN6_ADDR_GEN_MODE_NONE.
The purpose is: in the IN6_ADDR_GEN_MODE_STABLE_PRIVACY mode,
kernel can gererate a stable privacy global ipv6 address after
receiveing RA, and network processes can use this global address
to communicate with the outside network.
Of course, mobile operators that need to support RFC7217 should
also meet the requirement of 3GPP TS 29.061, that is, MT should
use IID assigned by the GGSN to build its ipv6 link-local address
and use this address to send RS. We don't want the kernel to
automatically generate an ipv6 link-local address when
addr_gen_mode == 2. Otherwise, using the stable privacy ipv6
link-local address automatically generated by the kernel to send
RS message, GGSN will not be able to respond to the RS and reply
a RA message.
Therefore, after this patch, the kernel can determine whether to
disable the automatic ipv6 link-local address generation by judging
the net device name.
Bug: 190685002
Change-Id: I93420cacd96789769edc7214fb8a2dd1455ce374
Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
Commit "block: Do not accept any requests while suspended" broke the UFS
driver. In the upstream kernel this has been fixed by commit b294ff3e34
("scsi: ufs: core: Enable power management for wlun"). Backporting that
commit or backporting the entire v5.14-rc1 UFS driver is too risky.
Hence revert the block layer patch that is incompatible with the v5.10
UFS driver power management code.
This reverts commit d55d15a332.
Bug: 193181075
Change-Id: Ic50d4e1df98d7ed393bf9797787225ae22e5d7a3
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Add vm_event_states, which is an already exported symbol, to the list of
whitelisted symbols. No message with 'Leaf changes summary:' is printed
to add to this commit message.
Bug: 187798288
Change-Id: I3c6d39d5b2838ac7fa64db152cca5685b9f43238
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Export is_ashmem_file function which will be used
by the minidump module to get ashmem info.
Bug: 193397560
Change-Id: I5b7816ad4775e5cf2c4f41c28b1c8dacc2c85b7e
Signed-off-by: liuhailong <liuhailong@oppo.com>
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
This is a possibility in android_setup when using cdev leading
to a NULL pointer dereference in spin_lock_irqsave. Using the
spinlock of gadget item to prevent the condition.
Bug: 189800931
Signed-off-by: Ray Chi <raychi@google.com>
Change-Id: Idc4cbcaed7dc6e1e35e8a63de84c1415fb83ef5e
Inline mem_cgroup_try_charge_swap, mem_cgroup_uncharge_swap and
cgroup_throttle_swaprate functions to perform mem_cgroup_disabled static
key check inline before calling the main body of the function. This
minimizes the memcg overhead in the pagefault and exit_mmap paths when
memcgs are disabled using cgroup_disable=memory command-line option.
This change results in ~1% overhead reduction when running PFT test [1]
comparing {CONFIG_MEMCG=n} against {CONFIG_MEMCG=y, cgroup_disable=memory}
configuration on an 8-core ARM64 Android device.
[1] https://lkml.org/lkml/2006/8/29/294 also used in mmtests suite
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Link: https://lore.kernel.org/patchwork/patch/1458908/
Bug: 191223209
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I18d59090ec908037b39324d1f1bb511d06e9c690
Inline mem_cgroup_{charge/uncharge} and mem_cgroup_uncharge_list functions
functions to perform mem_cgroup_disabled static key check inline before
calling the main body of the function. This minimizes the memcg overhead
in the pagefault and exit_mmap paths when memcgs are disabled using
cgroup_disable=memory command-line option.
This change results in ~0.4% overhead reduction when running PFT test [1]
comparing {CONFIG_MEMCG=n} against {CONFIG_MEMCG=y, cgroup_disable=memory}
configuration on an 8-core ARM64 Android device.
[1] https://lkml.org/lkml/2006/8/29/294 also used in mmtests suite
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Conflicts:
include/linux/memcontrol.h
mm/memcontrol.c
1. Trivial merge conflicts in memcontrol.h
2. Did not need to rename __mem_cgroup_charge into memcg_charge as in the
upstream version since in 5.10 __mem_cgroup_charge did not exist
Link: https://lore.kernel.org/patchwork/patch/1458907/
Bug: 191223209
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I9aad72aeabec2fe01f7218d629ec545c47b5d2c3
Add mem_cgroup_disabled check in vmpressure, mem_cgroup_uncharge_swap and
cgroup_throttle_swaprate functions. This minimizes the memcg overhead in
the pagefault and exit_mmap paths when memcgs are disabled using
cgroup_disable=memory command-line option.
This change results in ~2.1% overhead reduction when running PFT test [1]
comparing {CONFIG_MEMCG=n, CONFIG_MEMCG_SWAP=n} against {CONFIG_MEMCG=y,
CONFIG_MEMCG_SWAP=y, cgroup_disable=memory} configuration on an 8-core
ARM64 Android device.
[1] https://lkml.org/lkml/2006/8/29/294 also used in mmtests suite
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Link: https://lore.kernel.org/patchwork/patch/1458906/
Bug: 191223209
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ic1fc75eb1e4d7a9848cf641b9f232ad3262c490b
Android captures per-process system memory state when certain low memory
events (e.g a foreground app kill) occur, to identify potential memory
hoggers. In order to measure how much memory a process actually consumes,
it is necessary to include the DMA buffer sizes for that process in the
memory accounting. Since the handle to DMA buffers are raw FDs, it is
important to be able to identify which processes have FD references to a
DMA buffer.
Currently, DMA buffer FDs can be accounted using /proc/<pid>/fd/* and
/proc/<pid>/fdinfo -- both are only readable by the process owner, as
follows:
1. Do a readlink on each FD.
2. If the target path begins with "/dmabuf", then the FD is a dmabuf FD.
3. stat the file to get the dmabuf inode number.
4. Read/ proc/<pid>/fdinfo/<fd>, to get the DMA buffer size.
Accessing other processes' fdinfo requires root privileges. This limits
the use of the interface to debugging environments and is not suitable for
production builds. Granting root privileges even to a system process
increases the attack surface and is highly undesirable.
Since fdinfo doesn't permit reading process memory and manipulating
process state, allow accessing fdinfo under PTRACE_MODE_READ_FSCRED.
Link: https://lkml.kernel.org/r/20210308170651.919148-1-kaleshsingh@google.com
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Suggested-by: Jann Horn <jannh@google.com>
Acked-by: Christian König <christian.koenig@amd.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Alexey Gladkov <gladkov.alexey@gmail.com>
Cc: Andrei Vagin <avagin@gmail.com>
Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Hridya Valsaraju <hridya@google.com>
Cc: James Morris <jamorris@linux.microsoft.com>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 7bc3fa0172)
Bug: 159126739
Bug: 167141117
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: I842b689670f731138592f45c7124ef446d9aa59a
