CMA first allocation policy for movable makes CMA(Upstream doesn't)
area always full. It's good for memory efficiency since it could use
up CMA available memory most of time. However, it could cause
cma_alloc slow since it causes a lot page migration all the time.
Let's add vendor hook for someone who want to restore CMA allocation
policy to upstream so they will see less page migration in cma_alloc.
If the vendor_hook returns false, the rmqueue_bulk return 0 without
filling pcp->lists so get_populated_pcp_list will return NULL.
Once get_populated_pcp_list returns NULL, __rmqueue_pcplist will retry
the page allocation with original migratetype(currently, original
migratetype couldn't be MIGRATE_CMA) so the retrial will find
available pages from !MIGRATE_CMA free list.
Bug: 231978523
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ia031d9bc6f34085b892a8d9923bf5b9b1794f94a
The boot-img.tar.gz includes boot.img and boot-lz4.img,
with kernel image: Image and Image.lz4, respectively.
Bug: 222078981
Test: BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
Signed-off-by: Bowgo Tsai <bowgotsai@google.com>
Change-Id: I7f929a73967ce87d0d653d0b9926198cfeedc973
(cherry picked from commit 3361d46a39)
When dwc3_gadget_ep_cleanup_completed_requests() called to
dwc3_gadget_giveback() where the dwc3 lock is released, other thread is
able to execute. In this situation, usb_ep_disable() gets the chance to
clear endpoint descriptor pointer which leds to the null pointer
dereference problem. So needs to move the null pointer check to a proper
place.
Example call stack:
Thread#1:
dwc3_thread_interrupt()
spin_lock
-> dwc3_process_event_buf()
-> dwc3_process_event_entry()
-> dwc3_endpoint_interrupt()
-> dwc3_gadget_endpoint_trbs_complete()
-> dwc3_gadget_ep_cleanup_completed_requests()
...
-> dwc3_giveback()
spin_unlock
Thread#2 executes
Thread#2:
configfs_composite_disconnect()
-> __composite_disconnect()
-> ffs_func_disable()
-> ffs_func_set_alt()
-> ffs_func_eps_disable()
-> usb_ep_disable()
wait for dwc3 spin_lock
Thread#1 released lock
clear endpoint.desc
Fixes: 2628844812 ("usb: dwc3: gadget: Fix null pointer exception")
Cc: stable <stable@kernel.org>
Signed-off-by: Albert Wang <albertccwang@google.com>
Link: https://lore.kernel.org/r/20220518061315.3359198-1-albertccwang@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3c5880745b)
Bug: 224405818
Signed-off-by: Albert Wang <albertccwang@google.com>
Change-Id: I716885b0966711a166d6142417cd6d18fe5c14a8
Device drivers may decide to not load firmware when probed to avoid
slowing down the boot process should the firmware filesystem not be
available yet. In this case, the firmware loading request may be done
when a device file associated with the driver is first accessed. The
credentials of the userspace process accessing the device file may be
used to validate access to the firmware files requested by the driver.
Ensure that the kernel assumes the responsibility of reading the
firmware.
This was observed on Android for a graphic driver loading their firmware
when the device file (e.g. /dev/mali0) was first opened by userspace
(i.e. surfaceflinger). The security context of surfaceflinger was used
to validate the access to the firmware file (e.g.
/vendor/firmware/mali.bin).
Previously, Android configurations were not setting up the
firmware_class.path command line argument and were relying on the
userspace fallback mechanism. In this case, the security context of the
userspace daemon (i.e. ueventd) was consistently used to read firmware
files. More Android devices are now found to set firmware_class.path
which gives the kernel the opportunity to read the firmware directly
(via kernel_read_file_from_path_initns). In this scenario, the current
process credentials were used, even if unrelated to the loading of the
firmware file.
Signed-off-by: Thiébaud Weksteen <tweek@google.com>
Cc: <stable@vger.kernel.org> # 5.10
Reviewed-by: Paul Moore <paul@paul-moore.com>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/20220502004952.3970800-1-tweek@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 581dd69830)
[adelva: merged thru LTS, but LTS merges are paused on a13-5.10]
Bug: 232963476
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Ie24b5ec86451e36e7f982f403446161c326d5fe4
The dmabuf file uses get_next_ino()(through dma_buf_getfile() ->
alloc_anon_inode()) to get an inode number and uses the same as a
directory name under /sys/kernel/dmabuf/buffers/<ino>. This directory is
used to collect the dmabuf stats and it is created through
dma_buf_stats_setup(). At current, failure to create this directory
entry can make the dma_buf_export() to fail.
Now, as the get_next_ino() can definitely give a repetitive inode no
causing the directory entry creation to fail with -EEXIST. This is a
problem on the systems where dmabuf stats functionality is enabled on
the production builds can make the dma_buf_export(), though the dmabuf
memory is allocated successfully, to fail just because it couldn't
create stats entry.
This issue we are able to see on the snapdragon system within 13 days
where there already exists a directory with inode no "122602" so
dma_buf_stats_setup() failed with -EEXIST as it is trying to create
the same directory entry.
To make the dentry name as unique, use the dmabuf fs specific inode
which is based on the simple atomic variable increment. There is tmpfs
subsystem too which relies on its own inode generation rather than
relying on the get_next_ino() for the same reason of avoiding the
duplicate inodes[1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=e809d5f0b5c912fe981dce738f3283b2010665f0
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Cc: <stable@vger.kernel.org> # 5.15.x+
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1652441296-1986-1-git-send-email-quic_charante@quicinc.com
(cherry picked from commit 370704e707
git://anongit.freedesktop.org/drm/drm-misc)
Signed-off-by: Christian König <christian.koenig@amd.com>
Bug: 232887194
Change-Id: If244529c4c54086fe9eb5a4e76f6e8a07eaaa6ab
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
The ioremap hook can be called before slab is initialised, at which time
calling into kmalloc() is not allowed.
Signed-off-by: Keir Fraser <keirf@google.com>
Bug: 232894028
Fixes: f89d2055a3 ("ANDROID: arm64: Implement ioremap/iounmap hooks calling into KVM's MMIO guard")
Change-Id: Ieaf5adbdacdb196e37f4629998164a015e15c6d8
Disable CFI on trace hooks, as this improves some lmbench
microbenchmarks by as much as 12%.
Bug: 200542217
Change-Id: I6ad1d12047c4e69743ff94cf0ea8f70f5023c7da
Signed-off-by: Shaleen Agrawal <shalagra@codeaurora.org>
If a different vcpu from the same vm is loaded on the same
physical CPU, we must flush the CPU context.
This patch ensures that by tracking the vcpu that was last loaded
on this CPU, and flushes if that changes. This could lead to
over-invalidation, which could affect performance but not
correctness.
Bug: 228810735
Signed-off-by: Fuad Tabba <tabba@google.com>
Change-Id: I70976007165ca3b8d293089dbf9c2111b01ca2f7
This field is stale and not being used. Remove it.
Bug: 228810735
Signed-off-by: Fuad Tabba <tabba@google.com>
Change-Id: I5a734c22f246186b81ffd7bc73b46e0b60518306
This reverts commit b9b94e2aca.
Reason for revert: Suspected cause of hyp panic when running suite/user/pkvm_test
Change-Id: I117261a2298c0c59da2b22f8199317cab0635b03
Bug: 232390891
Signed-off-by: Will Deacon <willdeacon@google.com>
Update the generic symbol list.
Bug: 232424854
Change-Id: Ia164a1171bfe4a250e738b885d26f5037408adbb
Signed-off-by: David Kimmel <davidkimmel@google.com>
commit ebe48d368e upstream.
The maximum message size that can be send is bigger than
the maximum site that skb_page_frag_refill can allocate.
So it is possible to write beyond the allocated buffer.
Fix this by doing a fallback to COW in that case.
v2:
Avoid get get_order() costs as suggested by Linus Torvalds.
Bug: 227452856
Fixes: cac2661c53 ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30f6a ("esp6: Avoid skb_cow_data whenever possible")
Reported-by: valis <sec@valis.email>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I2c7f97914138271e7788adfcebbd0b2b8b43cdcb
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This reverts commit f0416df755.
Reason for revert: This was a "temporary" reversion to workaround what is believed to be a user-space issue.
Change-Id: I5322aecfe57cd8237e6657525eb33975c4840059
Bug: 166779391
Signed-off-by: Todd Kjos <tkjos@google.com>
(cherry picked from commit d1c6df6dc8)
[cmllamas: Resolved merge conflict with vendor hook in binder.c]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Some devices may return invalid or zeroed data during an UIC error
condition. In addition, reading these SFRs will clear them. This means the
subsequent error handling will not be able to see them and therefore no
error handling will be scheduled.
Skip reading these SFRs in ufshcd_dump_regs().
Link: https://lore.kernel.org/r/1648689845-33521-1-git-send-email-kwmad.kim@samsung.com
Fixes: d672475664 ("scsi: ufs: Use explicit access size in ufshcd_dump_regs")
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 229358593
(cherry picked from commit ef60031022)
Change-Id: Idc62842c79f948580107f95c65a14e34630a0017
Signed-off-by: Bart Van Assche <bvanassche@google.com>
When dma_buf_stats_setup() fails, it closes the dmabuf file which
results into the calling of dma_buf_file_release() where it does
list_del(&dmabuf->list_node) with out first adding it to the proper
list. This is resulting into panic in the below path:
__list_del_entry_valid+0x38/0xac
dma_buf_file_release+0x74/0x158
__fput+0xf4/0x428
____fput+0x14/0x24
task_work_run+0x178/0x24c
do_notify_resume+0x194/0x264
work_pending+0xc/0x5f0
Fix it by moving the dma_buf_stats_setup() after dmabuf is added to the
list.
Fixes: bdb8d06dfe ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs")
Signed-off-by: Charan Teja Reddy <quic_charante@quicinc.com>
Tested-by: T.J. Mercier <tjmercier@google.com>
Acked-by: T.J. Mercier <tjmercier@google.com>
Cc: <stable@vger.kernel.org> # 5.15.x+
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1652125797-2043-1-git-send-email-quic_charante@quicinc.com
(cherry picked from commit ef3a6b7050 git://anongit.freedesktop.org/drm/drm-misc)
Bug: 231929173
Change-Id: Iaefbae326175483444eaf5dbd3fdf8eb8fcca2aa
Originally, in the FOLL_LONGTERM case, __get_user_pages_remote
returned with __gup_longterm_locked's return value directly
but [1] broke the behavior so keep old behavior.
[1] d5d9a23576, ANDROID: mm: retry GUP with orignal gup_flags on failure
Bug: 231990030
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: If91b01c666cfbeb11d535d282c1ee7eec5700125
[ Upstream commit 4ff2980b6b ]
in tunnel mode, if outer interface(ipv4) is less, it is easily to let
inner IPV6 mtu be less than 1280. If so, a Packet Too Big ICMPV6 message
is received. When send again, packets are fragmentized with 1280, they
are still rejected with ICMPV6(Packet Too Big) by xfrmi_xmit2().
According to RFC4213 Section3.2.2:
if (IPv4 path MTU - 20) is less than 1280
if packet is larger than 1280 bytes
Send ICMPv6 "packet too big" with MTU=1280
Drop packet
else
Encapsulate but do not set the Don't Fragment
flag in the IPv4 header. The resulting IPv4
packet might be fragmented by the IPv4 layer
on the encapsulator or by some router along
the IPv4 path.
endif
else
if packet is larger than (IPv4 path MTU - 20)
Send ICMPv6 "packet too big" with
MTU = (IPv4 path MTU - 20).
Drop packet.
else
Encapsulate and set the Don't Fragment flag
in the IPv4 header.
endif
endif
Packets should be fragmentized with ipv4 outer interface, so change it.
After it is fragemtized with ipv4, there will be double fragmenation.
No.48 & No.51 are ipv6 fragment packets, No.48 is double fragmentized,
then tunneled with IPv4(No.49& No.50), which obey spec. And received peer
cannot decrypt it rightly.
48 2002::10 2002::11 1296(length) IPv6 fragment (off=0 more=y ident=0xa20da5bc nxt=50)
49 0x0000 (0) 2002::10 2002::11 1304 IPv6 fragment (off=0 more=y ident=0x7448042c nxt=44)
50 0x0000 (0) 2002::10 2002::11 200 ESP (SPI=0x00035000)
51 2002::10 2002::11 180 Echo (ping) request
52 0x56dc 2002::10 2002::11 248 IPv6 fragment (off=1232 more=n ident=0xa20da5bc nxt=50)
xfrm6_noneed_fragment has fixed above issues. Finally, it acted like below:
1 0x6206 192.168.1.138 192.168.1.1 1316 Fragmented IP protocol (proto=Encap Security Payload 50, off=0, ID=6206) [Reassembled in #2]
2 0x6206 2002::10 2002::11 88 IPv6 fragment (off=0 more=y ident=0x1f440778 nxt=50)
3 0x0000 2002::10 2002::11 248 ICMPv6 Echo (ping) request
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Bug: 226699354
Change-Id: Ideec82bea6a1efa26352680cb3113f7c36b945ef
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
The patchset adds a new spin_lock field into per_cpu_pages which
breaks KMI so this patch introduces per_cpu_pages_ext and
per_cpu_pageset_ext and changes relavant functions and code
to use the _ext data structures instead of original one.
Bug: 230899966
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ic5156f784223695c9716409036e2973df69ef99b
The patchset includes two additional fields along with lru in struct page
but they were all union so it shouldn't break change the semantic.
However, ABI is broken so this patch reverts the patchset since it
doesn't change runtime behavior difference. Just lose code readability.
Bug: 230899966
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I4eb1a55a9ca52794e136870bfddbd04175f1134b
Some setups, notably NOHZ_FULL CPUs, are too busy to handle the per-cpu
drain work queued by __drain_all_pages(). So introduce new a mechanism
to remotely drain the per-cpu lists. It is made possible by remotely
locking 'struct per_cpu_pages' new per-cpu spinlocks. A benefit of this
new scheme is that drain operations are now migration safe.
There was no observed performance degradation vs. the previous scheme.
Both netperf and hackbench were run in parallel to triggering the
__drain_all_pages(NULL, true) code path around ~100 times per second.
The new scheme performs a bit better (~5%), although the important point
here is there are no performance regressions vs. the previous mechanism.
Per-cpu lists draining happens only in slow paths.
Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/all/20220420095906.27349-7-mgorman@techsingularity.net/
Conflicts:
mm/page_alloc.c
1. aosp doesn't need 9c25cbfcb3, skip it
Bug: 230899966
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I8c4120d215836b04c53d0e4950a821fce4c99075
Currently the PCP lists are protected by using local_lock_irqsave to
prevent migration and IRQ reentrancy but this is inconvenient. Remote
draining of the lists is impossible and a workqueue is required and
every task allocation/free must disable then enable interrupts which is
expensive.
As preparation for dealing with both of those problems, protect the
lists with a spinlock. The IRQ-unsafe version of the lock is used
because IRQs are already disabled by local_lock_irqsave. spin_trylock
is used in preparation for a time when local_lock could be used instead
of lock_lock_irqsave.
The per_cpu_pages still fits within the same number of cache lines after
this patch relative to before the series.
struct per_cpu_pages {
spinlock_t lock; /* 0 4 */
int count; /* 4 4 */
int high; /* 8 4 */
int batch; /* 12 4 */
short int free_factor; /* 16 2 */
short int expire; /* 18 2 */
/* XXX 4 bytes hole, try to pack */
struct list_head lists[13]; /* 24 208 */
/* size: 256, cachelines: 4, members: 7 */
/* sum members: 228, holes: 1, sum holes: 4 */
/* padding: 24 */
} __attribute__((__aligned__(64)));
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/all/20220420095906.27349-6-mgorman@techsingularity.net/
Link: https://lore.kernel.org/all/20220429091321.GB3441@techsingularity.net/
Conflicts:
mm/page_alloc.c
1. per_cpu_pages are updated from 44042b4498 at 5.13 so conflicted
Since we don't need to have high-order page pcp atm, skip the patch.
Bug: 230899966
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I03ff1c22301e7f8735947e71413376ea143e855a
This is a preparation page to allow the buddy removal code to be reused
in a later patch.
No functional change.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/all/20220420095906.27349-4-mgorman@techsingularity.net/
Conflicts:
mm/page_alloc.c
1. Skipped changes in __rmqueue_pcplist which are not present in 5.10 kernel.
2. [1] introduced page allocation path a lot change to support cma first
allocation policy so needed to adapt the change.
[1] ANDROID: cma: redirect page allocation to CMA
Bug: 230899966
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I4584fbfdebf2637534d6a68635a44a81a176c253
The page allocator uses page->lru for storing pages on either buddy or
PCP lists. Create page->buddy_list and page->pcp_list as a union with
page->lru. This is simply to clarify what type of list a page is on
in the page allocator.
No functional change intended.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/all/20220420095906.27349-2-mgorman@techsingularity.net/
Bug: 230899966
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ieef253fa28c2a411008da64b38716f6401a66961
Historically when freeing pages, free_one_page() assumed that callers had
IRQs disabled and the zone->lock could be acquired with spin_lock(). This
confuses the scope of what local_lock_irq is protecting and what
zone->lock is protecting in free_unref_page_list in particular.
This patch uses spin_lock_irqsave() for the zone->lock in free_one_page()
instead of relying on callers to have disabled IRQs.
free_unref_page_commit() is changed to only deal with PCP pages protected
by the local lock. free_unref_page_list() then first frees isolated pages
to the buddy lists with free_one_page() and frees the rest of the pages to
the PCP via free_unref_page_commit(). The end result is that
free_one_page() is no longer depending on side-effects of local_lock to be
correct.
Note that this may incur a performance penalty while memory hot-remove is
running but that is not a common operation.
[lkp@intel.com: Ensure CMA pages get addded to correct pcp list]
Link: https://lkml.kernel.org/r/20210512095458.30632-9-mgorman@techsingularity.net
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit df1acc8569)
Conflicts:
mm/page_alloc.c
1. AOSP has custom change [1] so MIGRATE_PCPTYPES conflicted.
Use MIGRATE_CMA instead of MIGRATE_PCPTYPES.
[1] ANDROID: mm: freeing MIGRATE_ISOLATE page instantly
Bug: 230899966
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I23598cdcd7417e06a3389216ca2230aa446a2647
Supply additional check in order to prevent unexpected results.
Bug: 205573273
Fixes: b892bf75b2 ("ion: Switch ion to use dma-buf")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[Lee: Patch now applies to ion_buffer.c instead of ion.c]
Change-Id: Ia6afdd9ca502caa9cad6619d438fc6c8e8457679
(cherry picked from commit fea24b07ed)
When clatd starts with ebpf offloaing, and NETIF_F_GRO_FRAGLIST is enable,
several skbs are gathered in skb_shinfo(skb)->frag_list. The first skb's
ipv6 header will be changed to ipv4 after bpf_skb_proto_6_to_4,
network_header\transport_header\mac_header have been updated as ipv4 acts,
but other skbs in frag_list didnot update anything, just ipv6 packets.
udp_queue_rcv_skb will call skb_segment_list to traverse other skbs in
frag_list and make sure right udp payload is delivered to user space.
Unfortunately, other skbs in frag_list who are still ipv6 packets are
updated like the first skb and will have wrong transport header length.
e.g.before bpf_skb_proto_6_to_4,the first skb and other skbs in frag_list
has the same network_header(24)& transport_header(64), after
bpf_skb_proto_6_to_4, ipv6 protocol has been changed to ipv4, the first
skb's network_header is 44,transport_header is 64, other skbs in frag_list
didnot change.After skb_segment_list, the other skbs in frag_list has
different network_header(24) and transport_header(44), so there will be 20
bytes different from original,that is difference between ipv6 header and
ipv4 header. Just change transport_header to be the same with original.
Actually, there are two solutions to fix it, one is traversing all skbs
and changing every skb header in bpf_skb_proto_6_to_4, the other is
modifying frag_list skb's header in skb_segment_list. Considering
efficiency, adopt the second one--- when the first skb and other skbs in
frag_list has different network_header length, restore them to make sure
right udp payload is delivered to user space.
Signed-off-by: Lina Wang <lina.wang@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cf3ab8d4a7https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git master)
Bug: 218157620
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I36f2f329ec1a56bb0742141a7fa482cafa183ad3
commit e914d8f003 upstream.
Two processes under CLONE_VM cloning, user process can be corrupted by
seeing zeroed page unexpectedly.
CPU A CPU B
do_swap_page do_swap_page
SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path
swap_readpage valid data
swap_slot_free_notify
delete zram entry
swap_readpage zeroed(invalid) data
pte_lock
map the *zero data* to userspace
pte_unlock
pte_lock
if (!pte_same)
goto out_nomap;
pte_unlock
return and next refault will
read zeroed data
The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't
increase the refcount of swap slot at copy_mm so it couldn't catch up
whether it's safe or not to discard data from backing device. In the
case, only the lock it could rely on to synchronize swap slot freeing is
page table lock. Thus, this patch gets rid of the swap_slot_free_notify
function. With this patch, CPU A will see correct data.
CPU A CPU B
do_swap_page do_swap_page
SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path
swap_readpage original data
pte_lock
map the original data
swap_free
swap_range_free
bd_disk->fops->swap_slot_free_notify
swap_readpage read zeroed data
pte_unlock
pte_lock
if (!pte_same)
goto out_nomap;
pte_unlock
return
on next refault will see mapped data by CPU B
The concern of the patch would increase memory consumption since it
could keep wasted memory with compressed form in zram as well as
uncompressed form in address space. However, most of cases of zram uses
no readahead and do_swap_page is followed by swap_free so it will free
the compressed form from in zram quickly.
Link: https://lkml.kernel.org/r/YjTVVxIAsnKAXjTd@google.com
Fixes: 0bcac06f27 ("mm, swap: skip swapcache for swapin of synchronous device")
Reported-by: Ivan Babrou <ivan@cloudflare.com>
Tested-by: Ivan Babrou <ivan@cloudflare.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: David Hildenbrand <david@redhat.com>
Cc: <stable@vger.kernel.org> [4.14+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Minchan Kim <minchan@google.com>
(cherry picked from commit 20ed94f818)
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
linux-5.10.y)
Bug: 214353194
Change-Id: Iba642f36737c31fb5e9d8fc8a4e2a062bd28c37a
Move the check for protected VMs up to ensure that we don't miss
a KVM_MR_DELETE.
Bug: 231684412
Change-Id: Ia5cecc13232e8c430f2a1747a3cebd7e7bd5e348
Signed-off-by: Fuad Tabba <tabba@google.com>
If a different vcpu from the same vm is loaded on the same
physical CPU, we must flush the CPU context.
This patch ensures that by tracking the vcpu that was last loaded
on this CPU, and flushes if that changes. This could lead to
over-invalidation, which could affect performance but not
correctness.
Bug: 228810735
Signed-off-by: Fuad Tabba <tabba@google.com>
Change-Id: Ic623d98bfe3156591640f6b7908fb836456c2bd0
Add a new symbol to KMI that will be used to simulate the hypervisor
panic. This symbol nvhe_hyp_panic_handler will be used by the
pixel_debug module to collect debug trace information.
Bug: 210011561
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Change-Id: I8cb8035016f7215c71a7ba933010252eb52fed76
Make nvhe_hyp_panic_handler available to the kernel modules.
This is required to simulate the hypervisor panic for debug trace
verification.
Bug: 210011561
Change-Id: I2618cc75db747df8183d76199b69d6e90a62b1d1
Signed-off-by: Sebastian Ene <sebastianene@google.com>
When pKVM is enabled, host memory accesses are translated by an identity
mapping at stage-2, which is populated lazily in response to synchronous
exceptions from 64-bit EL1 and EL0.
Extend this handling to cover exceptions originating from 32-bit EL0 as
well. Although these are very unlikely to occur in practice, as the
kernel typically ensures that user pages are initialised before mapping
them in, drivers could still map previously untouched device pages into
userspace and expect things to work rather than panic the system.
Cc: Quentin Perret <qperret@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220427171332.13635-1-will@kernel.org
(cherry picked from commit 2a50fc5fd0
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git fixes)
Bug: 216811181
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I98ad9d9f0e2a78751ed73cc5d7c481d07a3ed1db
This fixes the kernelci error:
"ERROR: modpost: module configfs uses symbol kern_path from namespace
VFS_internal_I_am_really_a_filesystem_and_am_NOT_a_driver, but does not import it."
Bug: 230913804
Fixes: 0a77fca3aa ("ANDROID: GKI: set vfs-only exports into their own namespace")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Ib4ab1b83c8c8c996b1f15c419fb8ce0549832699
Per Kconfig:
config USB_NET_AX88179_178A
tristate "ASIX AX88179/178A USB 3.0/2.0 to Gigabit Ethernet"
depends on USB_USBNET
select CRC32
select PHYLIB
default y
help
This option adds support for ASIX AX88179 based USB 3.0/2.0
to Gigabit Ethernet adapters.
This driver should work with at least the following devices:
* ASIX AX88179
* ASIX AX88178A
* Sitcomm LN-032
This driver creates an interface named "ethX", where X depends on
what other networking devices you have in use.
This was already enabled on 'db845c_gki.fragment',
which suggests this hardware is reasonably common
(even though I don't have a dongle that requires it).
Test: TreeHugger
Bug: 200269356
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9915cfb54a324f007d508a8e3d2aad1d6fc9e5de
Our test build is broken by KCFLAGS overrided in build.config.comm.
Since Linux Makefile supports 'export KCFLAGS=XXX' to customize the
KCFLAGS, and we should keep this functionality.
Bug: 230818006
Fixes: 4053a1e898 ("ANDROID: Add flag to indicate compiling against ACK")
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Change-Id: I9425d79697bc1fe816ce82d523f91631dee6b8f4
Add a flag: __ANDROID_COMMON_KERNEL__ which out-of-tree vendor drivers
can use to check if they are compiling against an Android Common Kernel.
These out-of-tree vendor drivers can use this flag +
LINUX_KERNEL_VERSION to determine if a feature has been backported.
Bug: 229953929
Change-Id: I832344d63f3639479784753edfb7ac405068312f
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
