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
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit c01ce3b5ef)
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
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 675e504598)
Since CMA is getting used more widely, it's more important to
keep monitoring CMA statistics for system health since it's
directly related to user experience.
This feature introduces sysfs statistics for CMA, in order to provide
some basic monitoring of the CMA allocator.
* the number of CMA page successful allocations
* the number of CMA page allocation failures
These two values allow the user to calculate the allocation
failure rate for each CMA area.
Bug: 179256052
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I5c8dc58a5d195d2e1b2e25628545f7d2a9c3b7df
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit f45afb4508)
GKI has CONFIG_DYNAMIC_DEBUG_CORE. Thus, to enable only the
specific alloc_contig_dump_pages without needing all pr_debug
in every source files is using -DCONFIG_DYNAMIC_MODULE
when the page_alloc.o compiled.
Bug: 182195592
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I93266eb4161b3653389c737d4c767fd5d1083339
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 8d03e49505)
Contiguous memory allocation can be stalled due to waiting
on page writeback and/or page lock which causes unpredictable
delay. It's a unavoidable cost for the requestor to get *big*
contiguous memory but it's expensive for *small* contiguous
memory(e.g., order-4) because caller could retry the request
in different range where would have easy migratable pages
without stalling.
This patch introduce __GFP_NORETRY as compaction gfp_mask in
alloc_contig_range so it will fail fast without blocking
when it encounters pages needed waiting.
Bug: 170340257
Bug: 120293424
Link: https://lore.kernel.org/linux-mm/YAnM5PbNJZlk%2F%2FiX@google.com/T/#m1362218ebb69e6e10c20d9361008b079745c4e6f
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I42ba8dd5aeb065d936978ab205e4baf84bf9a321
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 20512940b8)
The upcoming patch will introduce __GFP_NORETRY semantic
in alloc_contig_range which is a failfast mode of the API.
Instead of adding a additional parameter for gfp, replace
no_warn with gfp flag.
To keep old behaviors, it follows the rule below.
no_warn gfp_flags
false GFP_KERNEL
true GFP_KERNEL|__GFP_NOWARN
gfp & __GFP_NOWARN GFP_KERNEL | (gfp & __GFP_NOWARN)
Bug: 170340257
Bug: 120293424
Link: https://lore.kernel.org/linux-mm/YAnM5PbNJZlk%2F%2FiX@google.com/T/#m36b144ff81fe0a8f0ecaf6813de4819ecc41f8fe
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I1ce020ab5d5fff34eb6464be4632ddef72fb43eb
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 23ba990a3e)
The hypervisor memory pool is sized to allow mapping up to 1GiB of data
in the 'private' range of the hypervisor. However, this is currently
not enforced in any way, which might become a problem as private range
mappings are used more and more (e.g. from pKVM modules).
Enforce the 1GiB limit at allocation time, and while at it, rename
__io_map_base to __private_range_base for consistency.
Bug: 244543039
Change-Id: I32c9145ba331309b49428ff461a41c94ea0c1512
Signed-off-by: Quentin Perret <qperret@google.com>
Parse the devicetree during pKVM init to find nodes with the
"pkvm,protected-region" compatible string. These nodes specify a
physical address range in reg that must alway be mapped as invalid in
the host stage-2 page table when running under pKVM.
Example DT:
pkvm_prot_reg: pkvm_prot_reg@80000000 {
compatible = "pkvm,protected-region";
reg = <0x00 0x80000000 0x00 0x200000>;
};
Bug: 244543039
Bug: 244373730
Change-Id: I102cd16c91d96e5283cdd1a4fa58836cc4834eac
Signed-off-by: Quentin Perret <qperret@google.com>
The pKVM memory pool is currently sized to allow page-granularity
mapping in the host stage-2 page-table of all the memory as well as up
to 1GiB of MMIO range. Indeed, pKVM currently assumes that MMIO regions
are completely and solely owned by the host for the entire lifetime of
the system. As such, the pages used to map MMIO regions can always be
recycled to allow forward progress if the memory pool ran out of
pages -- pKVM can unmap MMIO ranges at stage-2 without fearing to loose
important information about the state of the underlying page, and those
mappings can always be reconstructed later.
In order to allow transitioning the ownership of non-memory regions,
introduce a concept of pkvm 'moveable' regions, which represents regions
of the physical address space which can be 'moved' from an ownership
perspective. These moveable regions are used to size the hyp memory
pool. In a first step, the list of moveable regions is equal to the
memblock list, but it will be extended in subsequent changes.
No functional changes intended.
Bug: 244543039
Bug: 244373730
Change-Id: I7f451924b1eed9579868e6ff8c7adc7b4a5a0ae1
Signed-off-by: Quentin Perret <qperret@google.com>
The host_get_page_state() logic has currently a baked in assumption that
it will only be used on memory, and checks against the default memory
permssions to flag pages as having a RESTRICTED_PROT state.
Add support for correctly flagging non-memory pages to prepare the
ground for future patches.
Bug: 244543039
Bug: 244373730
Change-Id: Idaaef96cb98c147c8b793059438064cf770af525
Signed-off-by: Quentin Perret <qperret@google.com>
pKVM uses different default permissions for memory and non-memory
regions of the PA space. To avoid scattering this logic around,
introduce a default_host_prot() helper function.
Non functional changes intended.
Bug: 244543039
Bug: 244373730
Change-Id: I36cdbb26a2cb0d54b5641f945f6ede4ffe371045
Signed-off-by: Quentin Perret <qperret@google.com>
pKVM modules may need to be notified in case of unexpected same-level
EL2 exceptions, which result in a hyp panic. To do so, introduce a new
notifier on the hyp_panic path.
Bug: 244373730
Change-Id: I144609a933d648ddf2aebcd950e64d6035bf8be3
Signed-off-by: Quentin Perret <qperret@google.com>
pKVM modules may need to temporarily map large-ish physically contiguous
regions of memory when bootstrapping themselves. In order to support
this use-case, introduce two new APIs in the module_ops struct allowing
to map and unmap pages in pKVM's linear map range. Since pKVM's page
ownership infrastructure relies on linear map PTEs, this needs to be
done with special care. To avoid any problem, let's count the number of
pages mapped by modules and unsure they have been unmapped before
reaching the point of deprivilege.
Bug: 244373730
Change-Id: I4aecb93f5c9ba08d9f830d1f0976704688b98509
Signed-off-by: Quentin Perret <qperret@google.com>
The rmap locks(i_mmap_rwsem and anon_vma->root->rwsem) could be contended
under memory pressure if processes keep working on their vmas(e.g., fork,
mmap, munmap). It makes reclaim path stuck. In our real workload traces,
we see kswapd is waiting the lock for 300ms+(worst case, a sec) and it
makes other processes entering direct reclaim, which were also stuck on
the lock.
This patch makes lru aging path try_lock mode like shink_page_list so the
reclaim context will keep working with next lru pages without being stuck.
if it found the rmap lock contended, it rotates the page back to head of
lru in both active/inactive lrus to make them consistent behavior, which
is basic starting point rather than adding more heristic.
Since this patch introduces a new "contended" field as out-param along
with try_lock in-param in rmap_walk_control, it's not immutable any longer
if the try_lock is set so remove const keywords on rmap related functions.
Since rmap walking is already expensive operation, I doubt the const
would help sizable benefit( And we didn't have it until 5.17).
In a heavy app workload in Android, trace shows following statistics. It
almost removes rmap lock contention from reclaim path.
Martin Liu reported:
Before:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
1632 0 1631 151.542173 31672 209 page_lock_anon_vma_read
601 0 601 145.544681 28817 198 rmap_walk_file
After:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
NaN NaN NaN NaN NaN 0.0 NaN
0 0 0 0.127645 1 12 rmap_walk_file
[minchan@kernel.org: add comment, per Matthew]
Link: https://lkml.kernel.org/r/YnNqeB5tUf6LZ57b@google.com
Link: https://lkml.kernel.org/r/20220510215423.164547-1-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: John Dias <joaodias@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Martin Liu <liumartin@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Conflicts:
folio->page
Conflicts:
mm/huge_memory.c was refactored by
commit c5b5a3dd2c mm: thp: refactor NUMA fault handling
(cherry picked from commit 6d4675e601)
Bug: 239681156
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I0c63e0291120c8a1b5f2d83b8a7b210cb56c27a2
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit b8762fa265)
If page_pinner is configured with page_pinner_enabled=false and
failure_tracking=true, pp_buffer will be accessed without being
initialized. Prevent this by adding page_pinner_inited checks in
functions that access it.
Fixes: 898cfbf094a2 ("ANDROID: mm: introduce page_pinner")
Bug: 259024332
Bug: 260179017
Change-Id: I8f612cae3e74d36e8a4eee5edec25281246cbe5e
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 23fb3111f63e5fe239a769668275c20493a5849c)
The below is one path where race between page_ext and offline of the
respective memory blocks will cause use-after-free on the access of
page_ext structure.
process1 process2
--------- ---------
a)doing /proc/page_owner doing memory offline
through offline_pages.
b)PageBuddy check is failed
thus proceed to get the
page_owner information
through page_ext access.
page_ext = lookup_page_ext(page);
migrate_pages();
.................
Since all pages are successfully
migrated as part of the offline
operation,send MEM_OFFLINE notification
where for page_ext it calls:
offline_page_ext()-->
__free_page_ext()-->
free_page_ext()-->
vfree(ms->page_ext)
mem_section->page_ext = NULL
c) Check for the PAGE_EXT flags
in the page_ext->flags access
results into the use-after-free(leading
to the translation faults).
As mentioned above, there is really no synchronization between page_ext
access and its freeing in the memory_offline.
The memory offline steps(roughly) on a memory block is as below:
1) Isolate all the pages
2) while(1)
try free the pages to buddy.(->free_list[MIGRATE_ISOLATE])
3) delete the pages from this buddy list.
4) Then free page_ext.(Note: The struct page is still alive as it is
freed only during hot remove of the memory which frees the memmap, which
steps the user might not perform).
This design leads to the state where struct page is alive but the struct
page_ext is freed, where the later is ideally part of the former which
just representing the page_flags (check [3] for why this design is
chosen).
The above mentioned race is just one example __but the problem persists
in the other paths too involving page_ext->flags access(eg:
page_is_idle())__.
Fix all the paths where offline races with page_ext access by
maintaining synchronization with rcu lock and is achieved in 3 steps:
1) Invalidate all the page_ext's of the sections of a memory block by
storing a flag in the LSB of mem_section->page_ext.
2) Wait till all the existing readers to finish working with the
->page_ext's with synchronize_rcu(). Any parallel process that starts
after this call will not get page_ext, through lookup_page_ext(), for
the block parallel offline operation is being performed.
3) Now safely free all sections ->page_ext's of the block on which
offline operation is being performed.
Note: If synchronize_rcu() takes time then optimizations can be done in
this path through call_rcu()[2].
Thanks to David Hildenbrand for his views/suggestions on the initial
discussion[1] and Pavan kondeti for various inputs on this patch.
[1] https://lore.kernel.org/linux-mm/59edde13-4167-8550-86f0-11fc67882107@quicinc.com/
[2] https://lore.kernel.org/all/a26ce299-aed1-b8ad-711e-a49e82bdd180@quicinc.com/T/#u
[3] https://lore.kernel.org/all/6fa6b7aa-731e-891c-3efb-a03d6a700efa@redhat.com/
Bug: 236222283
Bug: 240196534
Link: https://lore.kernel.org/all/1661496993-11473-1-git-send-email-quic_charante@quicinc.com/
Change-Id: Ib439ae19c61a557a5c70ea90e3c4b35a5583ba0d
Suggested-by: David Hildenbrand <david@redhat.com>
Suggested-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Signed-off-by: Minchan Kim <minchan@google.com>
(fixed merge conflicts and still exported lookup_page_ext)
(minchan: fixed page_pinner with new page_ext scheme)
For CMA allocation, it's really critical to migrate a page but
sometimes it fails. One of the reasons is some driver holds a
page refcount for a long time so VM couldn't migrate the page
at that time.
The concern here is there is no way to find the who hold the
refcount of the page effectively. This patch introduces feature
to keep tracking page's pinner. All get_page sites are vulnerable
to pin a page for a long time but the cost to keep track it would
be significat since get_page is the most frequent kernel operation.
Furthermore, the page could be not user page but kernel page which
is not related to the page migration failure.
Thus, this patch keeps tracks of only migration failed pages to
reduce runtime cost. Once page migration fails in CMA allocation
path, those pages are marked as "migration failure" and every
put_page operation against those pages, callstack of the put
are recorded into page_pinner buffer. Later, admin can see
what pages were failed and who released the refcount since the
failure. It really helps effectively to find out longtime refcount
holder to prevent the page migration.
note: page_pinner doesn't guarantee attributing/unattributing are
atomic if they happen at the same time. It's just best effort so
false-positive could happen.
Bug: 183414571
BUg: 240196534
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I603d0c0122734c377db6b1eb95848a6f734173a0
(cherry picked from commit 898cfbf094a2fc13c67fab5b5d3c916f0139833a)
The hardware-wrapped key support in this branch is based on my patch
"[RFC PATCH v3 3/3] fscrypt: add support for hardware-wrapped keys"
(https://lore.kernel.org/r/20211021181608.54127-4-ebiggers@kernel.org)
I've since made several updates to that patch and it is now at v7.
This commit brings in the updates from v3 to v7, to the extent possible
while retaining compatibility with the UAPI and on-disk format used for
this feature in Android. This mainly includes some improved log
messages, and compatibility with the blk-crypto updates.
Bug: 160883801
Link: https://lore.kernel.org/all/20221216203636.81491-5-ebiggers@kernel.org
Change-Id: I1c43ca55ec7e95dd06f8f7944100ffd14771d3a7
Signed-off-by: Eric Biggers <ebiggers@google.com>
Update this code to be compatible with the updated version of
"block: add basic hardware-wrapped key support".
Bug: 160883801
Change-Id: Ic6991ad163035870ace3cd468f53b21a824c5359
Signed-off-by: Eric Biggers <ebiggers@google.com>
The hardware-wrapped key support in this branch is based on my patch
"[RFC PATCH v3 1/3] block: add basic hardware-wrapped key support"
(https://lore.kernel.org/all/20211021181608.54127-2-ebiggers@kernel.org).
I've since made several updates to that patch and it is now at v7.
This commit brings in the updates from v3 to v7. The main change is
making blk_crypto_derive_sw_secret() operate on a struct block_device,
and adding blk_crypto_hw_wrapped_keys_compatible(). This aligns with
changes upstream in v6.1 and v6.2 that removed block-layer internal
structures from the API that blk-crypto exposes to upper layers.
There's also a slight change in prototype for ->derive_sw_secret, so a
couple out-of-tree drivers will need to be updated, but people
maintaining out-of-tree drivers know what they are dealing with anyway.
Bug: 160883801
Link: https://lore.kernel.org/r/20221216203636.81491-2-ebiggers@kernel.org
Change-Id: I0f285c11c2764064cd4a9d6eac0089099a9601ed
Signed-off-by: Eric Biggers <ebiggers@google.com>
The prototypes of blk_crypto_evict_key() and
blk_crypto_start_using_key() changed, so update the callers in
dm-default-key which is not upstream.
Bug: 160885805
Change-Id: Ie39a298d8aca77c042f11bbfa25fd9bf50593c52
Signed-off-by: Eric Biggers <ebiggers@google.com>
blk_crypto_get_keyslot, blk_crypto_put_keyslot, __blk_crypto_evict_key
and __blk_crypto_cfg_supported are only used internally by the
blk-crypto code, so move the out of blk-crypto-profile.h, which is
included by drivers that supply blk-crypto functionality.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20221114042944.1009870-4-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 3569788c08)
Change-Id: I80b07a1c3b6e6f41ffe48adbdb27a3ca4480ff75
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add a blk_crypto_config_supported_natively helper that wraps
__blk_crypto_cfg_supported to retrieve the crypto_profile from the
request queue. With this fscrypt can stop including
blk-crypto-profile.h and rely on the public consumer interface in
blk-crypto.h.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20221114042944.1009870-3-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 6715c98b6c)
(resolved conflicts in blk_crypto_config_supported() and
__blk_crypto_bio_prep())
Change-Id: I40c4ab6bd9a108661c40c837227b6aed64685ae7
Signed-off-by: Eric Biggers <ebiggers@google.com>
Switch all public blk-crypto interfaces to use struct block_device
arguments to specify the device they operate on instead of th
request_queue, which is a block layer implementation detail.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20221114042944.1009870-2-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit fce3caea0f)
(resolved conflict in blk_crypto_config_supported())
Change-Id: Ifde7cf1c8a2a5ddfb2fde4e5fb118269a3bfcdb0
Signed-off-by: Eric Biggers <ebiggers@google.com>
After recent fixes [1], speculative page fault walks are performed with
disabled interrupts, therefore do not depend on ALLOC_SPLIT_PTLOCKS
which would affect them if performed under RCU protection. Remove
unnecessary config dependency.
[1] 5fcb50b0559a ("ANDROID: mm: fix speculative walk which is unsafe under RCU")
Bug: 253557903
Change-Id: Ia1c835c7b08419f8fce61fa4f7e6842fbf786229
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Since Android has pcp list for MIGRATE_CMA[1], it could cause
CMA allocation latency due to not freeing the MIGRATE_ISOLATE
page immediately.
Originally, MIGRATE_ISOLATED page is supposed to go buddy list
with skipping pcp list. Otherwise, the page could be reallocated
from pcp list or staying on the pcp list until the pcp is drained
so that CMA keeps retrying since it couldn't find the freed page
from buddy list. That worked before since the CMA pfnblocks changed
only from MIGRATE_CMA to MIGRATE_ISOLATE and free function logic
in page allocator has checked MIGRATE_ISOLATEness on every CMA
pages using below.
free_unref_page_commit
if (migratetype >= MIGRATE_PCPTYPES)
if(is_migrate_isolate(migratetype))
free_one_page(page);
It worked since enum MIGRATE_CMA was bigger than enum
MIGRATE_PCPTYPES but since [1], the enum MIGRATE_CMA is less than
MIGRATE_PCPTYPES so the logic above doesn't work any more.
It could cause following race
CPU 0 CPU 1
free_unref_page
migratetype = get_pfnblock_migratetype()
set_pcppage_migratetype(MIGRATE_CMA)
cma_alloc
alloc_contig_range
set_migrate_isolate(MIGRATE_ISOLATE)
add the page into pcp list
the page could be reallocated
This patch couldn't fix the race completely due to missing zone->lock
in order-0 page free(for performance reason). However, it's not a new
problem so we need to deal with the issue separately.
[1] ANDROID: mm: add cma pcp list
Bug: 218731671
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ibea20085ce5bfb4b74b83b041f9bda9a380120f9
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit d9e4b67784)
build.config.gki sources a GKI_BUILD_CONFIG_FRAGMENT before all of
the variables that are considered as part of a GKI kernel build are
declared. This reduces the effectiveness of a
GKI_BUILD_CONFIG_FRAGMENT, as it is only able to modify a subset of
the build variables.
Thus, move the logic to source GKI_BUILD_CONFIG_FRAGMENT to the end
of the GKI build config files to provide more flexibility for a
GKI_BUILD_CONFIG_FRAGMENT.
Bug: 262930113
Change-Id: I74abb45f9043acce04cb0052f54fded4340a9366
[isaacmanjarres: Modified build.config.gki.aarch64.fips140, which
did not exist on android13-5.15.]
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
(cherry picked from commit 69fefbb3db711e543ff0676526b7d285a4d10a14)
Introduce a new default trap handler for the host that can be set
from modules.
Bug: 244543039
Bug: 245034629
Change-Id: Iaabfa44f5f2c41af51f36ed4eec8762e7c951c01
Signed-off-by: Quentin Perret <qperret@google.com>
Introduce a notifier allowing a pKVM module to be notified for major
PSCI events: {CPU,SYSTEM}_SUSPEND, as well as on the resume path.
Bug: 244543039
Bug: 245034629
Change-Id: Ia82923445214925fc77e321457c8eab31f9d42e8
Signed-off-by: Quentin Perret <qperret@google.com>
Introduce a new handler allowing to notify pKVM modules when pKVM
detects an illegal access from the host.
Bug: 244543039
Bug: 245034629
Change-Id: I62133a8d967d91437e5216b307e449f8c83dfab6
Signed-off-by: Quentin Perret <qperret@google.com>
Introduce a new default SMC handler for the host that can be set from
modules.
Bug: 244543039
Bug: 245034629
Change-Id: I8481bfb1926a3cb433b15de5c1a99e3550710689
Signed-off-by: Quentin Perret <qperret@google.com>
Changes in 5.15.85
udf: Discard preallocation before extending file with a hole
udf: Fix preallocation discarding at indirect extent boundary
udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
udf: Fix extending file within last block
usb: gadget: uvc: Prevent buffer overflow in setup handler
USB: serial: option: add Quectel EM05-G modem
USB: serial: cp210x: add Kamstrup RF sniffer PIDs
USB: serial: f81232: fix division by zero on line-speed change
USB: serial: f81534: fix division by zero on line-speed change
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N
igb: Initialize mailbox message for VF reset
usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake
HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk
Bluetooth: L2CAP: Fix u8 overflow
selftests: net: Use "grep -E" instead of "egrep"
net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
Linux 5.15.85
Change-Id: Ia398b261925f9370124491034de3bc5e4dcc5022
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Move __pkvm_register_el2_call and __pkvm_load_el2_module out of the
MODULE ifdef so the associated EXPORT_SYMBOL are never alone.
Bug: 244543039
Bug: 244373730
Reported-by: kernel test robot <lkp@intel.com>
Change-Id: Icdac2ccd32d09388472c6500d4af951cc23439fb
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
[ Upstream commit 31d929de5a ]
When the name_assign_type attribute was introduced (commit
685343fc3b, "net: add name_assign_type netdev attribute"), the
loopback device was explicitly mentioned as one which would make use
of NET_NAME_PREDICTABLE:
The name_assign_type attribute gives hints where the interface name of a
given net-device comes from. These values are currently defined:
...
NET_NAME_PREDICTABLE:
The ifname has been assigned by the kernel in a predictable way
that is guaranteed to avoid reuse and always be the same for a
given device. Examples include statically created devices like
the loopback device [...]
Switch to that so that reading /sys/class/net/lo/name_assign_type
produces something sensible instead of returning -EINVAL.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3405a4beaa ]
Commit f7d8e387d9 ("HID: uclogic: Switch to Digitizer usage for
styluses") changed the usage used in UCLogic from "Pen" to "Digitizer".
However, the IS_INPUT_APPLICATION() macro evaluates to false for
HID_DG_DIGITIZER causing issues with the XP-Pen Star G640 tablet.
Add the HID_QUIRK_HIDINPUT_FORCE quirk to bypass the
IS_INPUT_APPLICATION() check.
Reported-by: Torge Matthies <openglfreak@googlemail.com>
Reported-by: Alexander Zhang <alex@alexyzhang.dev>
Tested-by: Alexander Zhang <alex@alexyzhang.dev>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 188c9c2e0c upstream.
The driver leaves the line speed unchanged in case a requested speed is
not supported. Make sure to handle the case where the current speed is
B0 (hangup) without dividing by zero when determining the clock source.
Fixes: 3aacac02f3 ("USB: serial: f81534: add high baud rate support")
Cc: stable@vger.kernel.org # 4.16
Cc: Ji-Ze Hong (Peter Hong) <hpeter@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a08ca6ebaf upstream.
The driver leaves the line speed unchanged in case a requested speed is
not supported. Make sure to handle the case where the current speed is
B0 (hangup) without dividing by zero when determining the clock source.
Fixes: 268ddb5e9b ("USB: serial: f81232: add high baud rate support")
Cc: stable@vger.kernel.org # 5.2
Cc: Ji-Ze Hong (Peter Hong) <hpeter@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e88906b169 upstream.
The RF sniffers are based on cp210x where the RF frontends
are based on a different USB stack.
RF sniffers can analyze packets meta data including power level
and perform packet injection.
Can be used to perform RF frontend self-test when connected to
a concentrator, ex. arch/arm/boot/dts/imx7d-flex-concentrator.dts
Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
