2 function symbol(s) added
  'void* android_debug_per_cpu_symbol(enum android_debug_per_cpu_symbol)'
  'void* android_debug_symbol(enum android_debug_symbol)'

Bug: 377608220
Bug: 287890135
Signed-off-by: xinpei jiang <jiangxinpei@honor.com>
Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
Change-Id: I144dab4b100f38603b507a326c84a9c7a26af7c3
(cherry picked from commit 8cd2dc49)

Bug: 371482271
Test: presubmit
Change-Id: I8981499a97c43caa50626872399a02ecb693ff19
Signed-off-by: Cheng-Cheng Lo <locc@google.com>

Bug: 371482271
Test: presubmit
Change-Id: Id3d03a9ed3d3207f1f710ac6dec17cd7f5445709
Signed-off-by: Cheng-Cheng Lo <locc@google.com>
(cherry picked from commit 712b8abf)

Bug: 371481715
Test: presubmit
Change-Id: I7b4c7d4ea7683f12c140c2ac7fc3ad67f02cd4cb
Signed-off-by: Cheng-Cheng Lo <locc@google.com>
(cherry picked from commit ff4969e8)

Replace can_modify_mm_madv() with a single vma variant, and associated
checks in madvise.

While we're at it, also invert the order of checks in:
 if (unlikely(is_ro_anon(vma) && !can_modify_vma(vma))

Checking if we can modify the vma itself (through vm_flags) is certainly
cheaper than is_ro_anon() due to arch_vma_access_permitted() looking at
e.g pkeys registers (with extra branches) in some architectures.

This patch allows for partial madvise success when finding a sealed VMA,
which historically has been allowed in Linux.

Link: https://lkml.kernel.org/r/20240817-mseal-depessimize-v3-5-d8d2e037df30@gmail.com


Change-Id: I0808016433305eb5e663d1de1cc697cac2c12dd8
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Jeff Xu <jeffxu@chromium.org>
Cc: Kees Cook <kees@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 23c57d1f)

Avoid taking an extra trip down the mmap tree by checking the vmas
directly.  mprotect (per POSIX) tolerates partial failure.

Link: https://lkml.kernel.org/r/20240817-mseal-depessimize-v3-3-d8d2e037df30@gmail.com


Change-Id: I519796354b9c88444854e53a8eea105e3e824010
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Jeff Xu <jeffxu@chromium.org>
Cc: Kees Cook <kees@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 4a2dd02b)

Patch series "mm: Optimize mseal checks", v3.

Optimize mseal checks by removing the separate can_modify_mm() step, and
just doing checks on the individual vmas, when various operations are
themselves iterating through the tree.  This provides a nice speedup and
restores performance parity with pre-mseal[3].

will-it-scale mmap1_process[1] -t 1 results:

commit 3450fe2b574b4345e4296ccae395149e1a357fee:

min:277605 max:277605 total:277605
min:281784 max:281784 total:281784
min:277238 max:277238 total:277238
min:281761 max:281761 total:281761
min:274279 max:274279 total:274279
min:254854 max:254854 total:254854
measurement
min:269143 max:269143 total:269143
min:270454 max:270454 total:270454
min:243523 max:243523 total:243523
min:251148 max:251148 total:251148
min:209669 max:209669 total:209669
min:190426 max:190426 total:190426
min:231219 max:231219 total:231219
min:275364 max:275364 total:275364
min:266540 max:266540 total:266540
min:242572 max:242572 total:242572
min:284469 max:284469 total:284469
min:278882 max:278882 total:278882
min:283269 max:283269 total:283269
min:281204 max:281204 total:281204

After this patch set:

min:280580 max:280580 total:280580
min:290514 max:290514 total:290514
min:291006 max:291006 total:291006
min:290352 max:290352 total:290352
min:294582 max:294582 total:294582
min:293075 max:293075 total:293075
measurement
min:295613 max:295613 total:295613
min:294070 max:294070 total:294070
min:293193 max:293193 total:293193
min:291631 max:291631 total:291631
min:295278 max:295278 total:295278
min:293782 max:293782 total:293782
min:290361 max:290361 total:290361
min:294517 max:294517 total:294517
min:293750 max:293750 total:293750
min:293572 max:293572 total:293572
min:295239 max:295239 total:295239
min:292932 max:292932 total:292932
min:293319 max:293319 total:293319
min:294954 max:294954 total:294954

This was a Completely Unscientific test but seems to show there were
around 5-10% gains on ops per second.

Oliver performed their own tests and showed[3] a similar ~5% gain in them.

[1]: mmap1_process does mmap and munmap in a loop. I didn't bother testing multithreading cases.
[2]: https://lore.kernel.org/all/20240807124103.85644-1-mpe@ellerman.id.au/
[3]: https://lore.kernel.org/all/ZrMMJfe9aXSWxJz6@xsang-OptiPlex-9020/
Link: https://lore.kernel.org/all/202408041602.caa0372-oliver.sang@intel.com/

This patch (of 7):

Move can_modify_vma to vma.h so it can be inlined properly (with the
intent to remove can_modify_mm callsites).

Link: https://lkml.kernel.org/r/20240817-mseal-depessimize-v3-1-d8d2e037df30@gmail.com


Change-Id: I6e239eeed12a16202dcd0ca2c4ca643dd92aaf81
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Jeff Xu <jeffxu@chromium.org>
Cc: Kees Cook <kees@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Pedro Falcato <pedro.falcato@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 4d1b3416)

18 function symbol(s) added
  'u16 vp_modern_config_vector(struct virtio_pci_modern_device*, u16)'
  'u32 vp_modern_generation(struct virtio_pci_modern_device*)'
  'u64 vp_modern_get_features(struct virtio_pci_modern_device*)'
  'u16 vp_modern_get_num_queues(struct virtio_pci_modern_device*)'
  'bool vp_modern_get_queue_enable(struct virtio_pci_modern_device*, u16)'
  'int vp_modern_get_queue_reset(struct virtio_pci_modern_device*, u16)'
  'u16 vp_modern_get_queue_size(struct virtio_pci_modern_device*, u16)'
  'u8 vp_modern_get_status(struct virtio_pci_modern_device*)'
  'void* vp_modern_map_vq_notify(struct virtio_pci_modern_device*, u16, resource_size_t*)'
  'int vp_modern_probe(struct virtio_pci_modern_device*)'
  'void vp_modern_queue_address(struct virtio_pci_modern_device*, u16, u64, u64, u64)'
  'u16 vp_modern_queue_vector(struct virtio_pci_modern_device*, u16, u16)'
  'void vp_modern_remove(struct virtio_pci_modern_device*)'
  'void vp_modern_set_features(struct virtio_pci_modern_device*, u64)'
  'void vp_modern_set_queue_enable(struct virtio_pci_modern_device*, u16, bool)'
  'void vp_modern_set_queue_reset(struct virtio_pci_modern_device*, u16)'
  'void vp_modern_set_queue_size(struct virtio_pci_modern_device*, u16, u16)'
  'void vp_modern_set_status(struct virtio_pci_modern_device*, u8)'

Bug: 287199267
Change-Id: Ic7ad6c5c67ab3b8e48f16b0e1afab2a1584aff52
Signed-off-by: Ulises Mendez Martinez <umendez@google.com>

The call to mtree_insert_range() from insert_ppage() may end up doing
GFP_KERNEL allocations if the mtree's kmem_cache is empty. Sadly this is
all being done from an mmu_lock write critical section, where we can't
sleep.

Fix this by inserting dummy entries via mtree_insert_range() outside the
critical section which can then be overwritten without requiring memory
allocation. This is safe to do as we're using the builtin mtree lock,
but does require checking the validity of the ppage found in the tree
from all observers.

Bug: 278749606
Bug: 278011447
Change-Id: Ifa4a092e6280db4d02f5943a4eab94d958b431ee
Signed-off-by: Quentin Perret <qperret@google.com>

pkvm_mem_abort()'s caller can optionally pass in ipa and size pointers
which are expected to be updated to the address and size of the page
that was faulted in (usually PMD_SIZE or PAGE_SIZE). However, when
pkvm_mem_abort() finds an already faulted in page-size mapping in the
middle of a HP, we fallback to faulting in at page granularity, update
the ipa pointer, but fail to update the size pointer. Fix that.

Bug: 278749606
Bug: 278011447
Change-Id: I672d31e55d5fee6988a8f57a20f76c6fe983653e
Signed-off-by: Quentin Perret <qperret@google.com>

When faulting in a THP, we proactively account the entire huge page
against RLIMIT_MEMLOCK before trying to map it. However, if we happen to
find an already mapped page in the THP range after that, we retry to
fault at page granularity instead and fixup the accounting
accordingly.

Unfortunately the fixing of the accounting is done incorrectly -- we
only substract PAGE_SIZE instead of the full HP size. Fix that.

Bug: 278749606
Bug: 278011447
Change-Id: I20498c42fcba6efa2c80cb63057bbada6ad8fa87
Signed-off-by: Quentin Perret <qperret@google.com>

ARM_LPAE_LVL_IDX() takes into account concatenated PGDs and can return
an index spanning multiple page-table pages given a sufficiently large
input address. However, when the resulting index is used to calculate
the number of remaining entries in the page, the possibility of
concatenation is ignored and we end up computing a negative upper bound:

	max_entries = ARM_LPAE_PTES_PER_TABLE(data) - map_idx_start;

On the map path, this results in a negative 'mapped' value being
returned but on the unmap path we can leak child tables if they are
skipped in __arm_lpae_free_pgtable().

Introduce an arm_lpae_max_entries() helper to convert a table index into
the remaining number of entries within a single page-table page.

Cc: <stable@vger.kernel.org>
Change-Id: If1bcc8c5abc53d4b4f1de102e32bef85badd0fd9
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Link: https://lore.kernel.org/r/20241024162516.2005652-2-smostafa@google.com


[will: Tweaked comment and commit message]
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit d71fa842
https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-joerg/arm-smmu/updates)

Having UFS power info available in sysfs makes it easier to tell the state
of the link during runtime considering we have a bunch of power saving
features and various combinations for backward compatibility.

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Change-Id: I483eeeaaf694ed33fef943a2b413ba9ee223cf86
(cherry picked from commit 4f6dd2a4)
Signed-off-by: Can Guo <quic_cang@quicinc.com>
Link: https://lore.kernel.org/r/1698890324-7374-1-git-send-email-quic_cang@quicinc.com


Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Konstantin Vyshetsky <vkon@google.com>

Each platform might have its own maximum mailbox receive channel timeout
value, so get property max-rx-timeout-ms from device tree and use it. If
the property does not exist, use mailbox 'scmi_desc' fixed value 30ms as
before.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

Bug: 364340026
Link: https://lore.kernel.org/arm-scmi/20240709140957.3171255-2-peng.fan@oss.nxp.com/


Change-Id: If1698ecdf92f2544f126670c552c24c74597c670
Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>

F2FS should understand how the device aliasing file works and support
deleting the file after use. A device aliasing file can be created by
mkfs.f2fs tool and it can map the whole device with an extent, not
using node blocks. The file space should be pinned and normally used for
read-only usages.

Bug: 336319772
Change-Id: Ifbac959ef42e5c8af790bb1e0f9f4da9f5e1b592
Link: https://lore.kernel.org/lkml/20241017173153.980193-1-daeho43@gmail.com/


Signed-off-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 495494c3
https: //git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/ dev)

Update virtual_device symbol list after swapping the android-v virtual
cpufreq driver to use the upstream version instead.

Bug: 284367589
Test: Build and boot aarch64 CF using update kernel
Change-Id: I2816651c23f35e1aa3a43a8f58e4f375fa28e6a7
Signed-off-by: David Dai <davidai@google.com>

Add the pending proc->delivered_freeze work to the debugfs output. This
information was omitted in the original implementation of the freeze
notification and can be valuable for debugging issues.

Fixes: d579b04a ("binder: frozen notification")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240926233632.821189-9-cmllamas@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 366003708
(cherry picked from commit cb2aeb2e
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git


 char-misc-next)
Change-Id: Ifc9a22b52e38c35af661732486fa1f154adb34de
[cmllamas: fix KMI break with proc_wrapper()]
Signed-off-by: Carlos Llamas <cmllamas@google.com>

If a freeze notification is cleared with BC_CLEAR_FREEZE_NOTIFICATION
before calling binder_freeze_notification_done(), then it is detached
from its reference (e.g. ref->freeze) but the work remains queued in
proc->delivered_freeze. This leads to a memory leak when the process
exits as any pending entries in proc->delivered_freeze are not freed:

  unreferenced object 0xffff38e8cfa36180 (size 64):
    comm "binder-util", pid 655, jiffies 4294936641
    hex dump (first 32 bytes):
      b8 e9 9e c8 e8 38 ff ff b8 e9 9e c8 e8 38 ff ff  .....8.......8..
      0b 00 00 00 00 00 00 00 3c 1f 4b 00 00 00 00 00  ........<.K.....
    backtrace (crc 95983b32):
      [<000000000d0582cf>] kmemleak_alloc+0x34/0x40
      [<000000009c99a513>] __kmalloc_cache_noprof+0x208/0x280
      [<00000000313b1704>] binder_thread_write+0xdec/0x439c
      [<000000000cbd33bb>] binder_ioctl+0x1b68/0x22cc
      [<000000002bbedeeb>] __arm64_sys_ioctl+0x124/0x190
      [<00000000b439adee>] invoke_syscall+0x6c/0x254
      [<00000000173558fc>] el0_svc_common.constprop.0+0xac/0x230
      [<0000000084f72311>] do_el0_svc+0x40/0x58
      [<000000008b872457>] el0_svc+0x38/0x78
      [<00000000ee778653>] el0t_64_sync_handler+0x120/0x12c
      [<00000000a8ec61bf>] el0t_64_sync+0x190/0x194

This patch fixes the leak by ensuring that any pending entries in
proc->delivered_freeze are freed during binder_deferred_release().

Fixes: d579b04a ("binder: frozen notification")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20240926233632.821189-8-cmllamas@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 366003708
(cherry picked from commit 1db76ec2
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git


 char-misc-next)
Change-Id: Iafdec3421c521b4b591b94455deba7ee5102c8ca
[cmllamas: drop BINDER_STAT_FREEZE and use proc_wrapper()]
Signed-off-by: Carlos Llamas <cmllamas@google.com>

Alice points out that binder_request_freeze_notification() should not
return EINVAL when the relevant node is dead [1]. The node can die at
any point even if the user input is valid. Instead, allow the request
to be allocated but skip the initial notification for dead nodes. This
avoids propagating unnecessary errors back to userspace.

Fixes: d579b04a ("binder: frozen notification")
Cc: stable@vger.kernel.org
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/all/CAH5fLghapZJ4PbbkC8V5A6Zay-_sgTzwVpwqk6RWWUNKKyJC_Q@mail.gmail.com/

 [1]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20240926233632.821189-7-cmllamas@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 366003708
(cherry picked from commit ca63c669
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git


 char-misc-next)
Change-Id: I03af1eedfeb194f5a775388cbb4e7487e4a5dfc0
Signed-off-by: Carlos Llamas <cmllamas@google.com>

proc 699
context binder-test
  thread 699: l 00 need_return 0 tr 0
  ref 25: desc 1 node 20 s 1 w 0 d 00000000c03e09a3
  unknown work: type 11

proc 640
context binder-test
  thread 640: l 00 need_return 0 tr 0
  ref 8: desc 1 node 3 s 1 w 0 d 000000002bb493e1
  has cleared freeze notification

Fixes: d579b04a ("binder: frozen notification")
Cc: stable@vger.kernel.org
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20240926233632.821189-6-cmllamas@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 366003708
(cherry picked from commit 595ea72e
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git


 char-misc-next)
Change-Id: Ic6311aaea2040aaf4534cdaa4cbfa378afe31869
Signed-off-by: Carlos Llamas <cmllamas@google.com>

The BINDER_WORK_FROZEN_BINDER type is not handled in the binder_logs
entries and it shows up as "unknown work" when logged:

  proc 649
  context binder-test
    thread 649: l 00 need_return 0 tr 0
    ref 13: desc 1 node 8 s 1 w 0 d 0000000053c4c0c3
    unknown work: type 10

This patch add the freeze work type and is now logged as such:

  proc 637
  context binder-test
    thread 637: l 00 need_return 0 tr 0
    ref 8: desc 1 node 3 s 1 w 0 d 00000000dc39e9c6
    has frozen binder

Fixes: d579b04a ("binder: frozen notification")
Cc: stable@vger.kernel.org
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240926233632.821189-5-cmllamas@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 366003708
(cherry picked from commit 830d7db7
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git


 char-misc-next)
Change-Id: I06f888aa5218db19eeda79e315385506af09d9d5
Signed-off-by: Carlos Llamas <cmllamas@google.com>

When a binder reference is cleaned up, any freeze work queued in the
associated process should also be removed. Otherwise, the reference is
freed while its ref->freeze.work is still queued in proc->work leading
to a use-after-free issue as shown by the following KASAN report:

  ==================================================================
  BUG: KASAN: slab-use-after-free in binder_release_work+0x398/0x3d0
  Read of size 8 at addr ffff31600ee91488 by task kworker/5:1/211

  CPU: 5 UID: 0 PID: 211 Comm: kworker/5:1 Not tainted 6.11.0-rc7-00382-gfc6c92196396 #22
  Hardware name: linux,dummy-virt (DT)
  Workqueue: events binder_deferred_func
  Call trace:
   binder_release_work+0x398/0x3d0
   binder_deferred_func+0xb60/0x109c
   process_one_work+0x51c/0xbd4
   worker_thread+0x608/0xee8

  Allocated by task 703:
   __kmalloc_cache_noprof+0x130/0x280
   binder_thread_write+0xdb4/0x42a0
   binder_ioctl+0x18f0/0x25ac
   __arm64_sys_ioctl+0x124/0x190
   invoke_syscall+0x6c/0x254

  Freed by task 211:
   kfree+0xc4/0x230
   binder_deferred_func+0xae8/0x109c
   process_one_work+0x51c/0xbd4
   worker_thread+0x608/0xee8
  ==================================================================

This commit fixes the issue by ensuring any queued freeze work is removed
when cleaning up a binder reference.

Fixes: d579b04a ("binder: frozen notification")
Cc: stable@vger.kernel.org
Acked-by: Todd Kjos <tkjos@android.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240926233632.821189-4-cmllamas@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 366003708
(cherry picked from commit 7e20434c
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git


 char-misc-next)
Change-Id: Icc40e7dd6157981f4adbea7243e55be118552321
[cmllamas: drop BINDER_STAT_FREEZE as it's not supported here]
Signed-off-by: Carlos Llamas <cmllamas@google.com>

In binder_add_freeze_work() we iterate over the proc->nodes with the
proc->inner_lock held. However, this lock is temporarily dropped to
acquire the node->lock first (lock nesting order). This can race with
binder_deferred_release() which removes the nodes from the proc->nodes
rbtree and adds them into binder_dead_nodes list. This leads to a broken
iteration in binder_add_freeze_work() as rb_next() will use data from
binder_dead_nodes, triggering an out-of-bounds access:

  ==================================================================
  BUG: KASAN: global-out-of-bounds in rb_next+0xfc/0x124
  Read of size 8 at addr ffffcb84285f7170 by task freeze/660

  CPU: 8 UID: 0 PID: 660 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #18
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   rb_next+0xfc/0x124
   binder_add_freeze_work+0x344/0x534
   binder_ioctl+0x1e70/0x25ac
   __arm64_sys_ioctl+0x124/0x190

  The buggy address belongs to the variable:
   binder_dead_nodes+0x10/0x40
  [...]
  ==================================================================

This is possible because proc->nodes (rbtree) and binder_dead_nodes
(list) share entries in binder_node through a union:

	struct binder_node {
	[...]
		union {
			struct rb_node rb_node;
			struct hlist_node dead_node;
		};

Fix the race by checking that the proc is still alive. If not, simply
break out of the iteration.

Fixes: d579b04a ("binder: frozen notification")
Cc: stable@vger.kernel.org
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240926233632.821189-3-cmllamas@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 366003708
(cherry picked from commit 011e69a1
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git


 char-misc-next)
Change-Id: I5ec9d49277a23b864862665b52213460750c535e
Signed-off-by: Carlos Llamas <cmllamas@google.com>

In binder_add_freeze_work() we iterate over the proc->nodes with the
proc->inner_lock held. However, this lock is temporarily dropped in
order to acquire the node->lock first (lock nesting order). This can
race with binder_node_release() and trigger a use-after-free:

  ==================================================================
  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c
  Write of size 4 at addr ffff53c04c29dd04 by task freeze/640

  CPU: 5 UID: 0 PID: 640 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #17
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   _raw_spin_lock+0xe4/0x19c
   binder_add_freeze_work+0x148/0x478
   binder_ioctl+0x1e70/0x25ac
   __arm64_sys_ioctl+0x124/0x190

  Allocated by task 637:
   __kmalloc_cache_noprof+0x12c/0x27c
   binder_new_node+0x50/0x700
   binder_transaction+0x35ac/0x6f74
   binder_thread_write+0xfb8/0x42a0
   binder_ioctl+0x18f0/0x25ac
   __arm64_sys_ioctl+0x124/0x190

  Freed by task 637:
   kfree+0xf0/0x330
   binder_thread_read+0x1e88/0x3a68
   binder_ioctl+0x16d8/0x25ac
   __arm64_sys_ioctl+0x124/0x190
  ==================================================================

Fix the race by taking a temporary reference on the node before
releasing the proc->inner lock. This ensures the node remains alive
while in use.

Fixes: d579b04a ("binder: frozen notification")
Cc: stable@vger.kernel.org
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240926233632.821189-2-cmllamas@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 366003708
(cherry picked from commit dc8aea47
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git


 char-misc-next)
Change-Id: I47b053532dd4cd3424d35d6f254ca4d00c426411
Signed-off-by: Carlos Llamas <cmllamas@google.com>

When total_req_power is 0, divvy_up_power() will set granted_power to 0,
and cdev will be limited to the lowest performance. If our polling delay
is set to 200ms, it means that cdev cannot perform better within 200ms
even if cdev has a sudden load. This will affect the performance of cdev
and is not as expected.

For this reason, if nobody requests power, then set the granted power to
the max_power.

Signed-off-by: zhengshaobo1 <zhengshaobo1@xiaomi.com>

Bug: 375959779
(cherry picked from commit 08eb0493
 https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git

 thermal)
Change-Id: I6e7360d8e6b886d9f1f23e9e4fd41f197605d520
Signed-off-by: zhengshaobo1 <zhengshaobo1@xiaomi.com>

Introduce a virtualized cpufreq driver for guest kernels to improve
performance and power of workloads within VMs.

This driver does two main things:

1. Sends the frequency of vCPUs as a hint to the host. The host uses the
hint to schedule the vCPU threads and decide physical CPU frequency.

2. If a VM does not support a virtualized FIE(like AMUs), it queries the
host CPU frequency by reading a MMIO region of a virtual cpufreq device
to update the guest's frequency scaling factor periodically. This enables
accurate Per-Entity Load Tracking for tasks running in the guest.

Bug: 284367589
Test: Boot up with compatible VMM backend emulation
Link: https://lore.kernel.org/all/20240919000837.1004642-3-davidai@google.com/
(cherry picked from commit 4fd06a53
 git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git

 cpufreq/arm/linux-next)
[davidai: fixed up mismatches in the cpufreq's exit/remove function prototypes]
Change-Id: I1d212b4ddb56cc35678d5347a11c0c9e24a4d052
Co-developed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: David Dai <davidai@google.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

Adding bindings to represent a virtual cpufreq device.

Virtual machines may expose MMIO regions for a virtual cpufreq device
for guests to read performance information or to request performance
selection. The virtual cpufreq device has an individual controller for
each performance domain. Performance points for a given domain can be
normalized across all domains for ease of allowing for virtual machines
to migrate between hosts.

Bug: 284367589
Test: Boot up with compatible VMM backend emulation
Link: https://lore.kernel.org/all/20240919000837.1004642-2-davidai@google.com/
(cherry picked from commit 984638e4
 git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git

 cpufreq/arm/linux-next)
Change-Id: Ic67335c69a4b584e9f5008e02f87b4179002375e
Co-developed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: David Dai <davidai@google.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

KUnit configurations include KernelTestModuleController that skips the
tests for mismatching architectures.

Test: ./run_test_only.sh --gcov -s 0.0.0.0:6520 -t \
      'kunit soc-utils-test#soc-utils'
Bug: 358439710
Change-Id: I5b1daee4329c9b9cf1d534d0ea88b41d76cfa7bc
Signed-off-by: Hsin-Yi Chen <hsinyichen@google.com>
(cherry picked from commit 6c455c44)

Update symbol list for honor in android/abi_gki_aarch64_honor

Bug: 375088532
Change-Id: I0e4762d789bb9fba49e9efe434534eac8edaf69a
Signed-off-by: yipeng xiang <yipengxiang@honor.corp-partner.google.com>

Add hooks to solve the priority inversion. while the key thread needs
to update fs data, it should wake and wait for f2fs checkpoint thread
to complete the work. So one scheme is needed to ensure the priority
of checkpoint thread especially in CPU high load scenarios.

Bug: 375088532
Change-Id: Iaa181cd1c8368310d9dd4c78adda6c7add5858b3
Signed-off-by: yipeng xiang <yipengxiang@honor.corp-partner.google.com>

2 function symbol(s) added
  'int ptp_find_pin(struct ptp_clock*, enum ptp_pin_function, unsigned int)'
  'int ptp_schedule_worker(struct ptp_clock*, unsigned long)'

Bug: 376165736
Change-Id: I86c51cec072155cc2ec6eaf1bd54f0a93bec3329
Signed-off-by: Seiya Wang <seiya.wang@mediatek.com>

Adding the following symbols:
  - __bio_add_page
  - bio_add_page
  - bio_alloc_bioset
  - bio_chain
  - bio_endio
  - bio_end_io_acct_remapped
  - bio_init
  - bio_put
  - bio_start_io_acct
  - __blk_alloc_disk
  - blk_check_plugged
  - blkdev_get_by_dev
  - blkdev_put
  - blk_queue_flag_clear
  - blk_queue_flag_set
  - blk_queue_io_min
  - blk_queue_io_opt
  - blk_queue_logical_block_size
  - blk_queue_max_discard_sectors
  - blk_queue_max_write_zeroes_sectors
  - blk_queue_physical_block_size
  - crypto_alloc_base
  - crypto_comp_compress
  - crypto_comp_decompress
  - del_gendisk
  - device_add_disk
  - file_path
  - filp_close
  - filp_open_block
  - flush_dcache_page
  - fs_bio_set
  - memset64
  - put_disk
  - __register_blkdev
  - set_capacity
  - set_capacity_and_notify
  - submit_bio
  - submit_bio_wait
  - sync_blockdev
  - thermal_cooling_device_register
  - __traceiter_android_rvh_sched_setaffinity
  - __tracepoint_android_rvh_sched_setaffinity
  - unregister_blkdev
  - vm_node_stat
  - zs_compact
  - zs_create_pool
  - zs_destroy_pool
  - zs_free
  - zs_get_total_pages
  - zs_huge_class_size
  - zs_malloc
  - zs_map_object
  - zs_pool_stats
  - zs_unmap_object

Bug: 375507940
Change-Id: Ieaf706f1efeaa357efdb5a5d0c7fb4313937bc9a
Signed-off-by: Yong Zhao <yozhao@google.com>

This removes a stray #undef directive.

Bug: 361520241
Change-Id: I8c9b4990985b8b4c5a16bb21f9f1dbe40925b945
Signed-off-by: Giuliano Procida <gprocida@google.com>

Currently, the coredump_task_exit() function sets the task state
to TASK_UNINTERRUPTIBLE|TASK_FREEZABLE, which usually works well.
But a combination of large memory and slow (and/or highly contended)
mass storage can cause application core dumps to take more than
two minutes, which can cause check_hung_task(), which is invoked by
check_hung_uninterruptible_tasks(), to produce task-blocked splats.
There does not seem to be any reasonable benefit to getting these splats.

Furthermore, as Oleg Nesterov points out, TASK_UNINTERRUPTIBLE could
be misleading because the task sleeping in coredump_task_exit() really
is killable, albeit indirectly.  See the check of signal->core_state
in prepare_signal() and the check of fatal_signal_pending()
in dump_interrupted(), which bypass the normal unkillability of
TASK_UNINTERRUPTIBLE, resulting in coredump_finish() invoking
wake_up_process() on any threads sleeping in coredump_task_exit().

Therefore, change that TASK_UNINTERRUPTIBLE to TASK_IDLE.

Bug: 375106936
(cherry picked from commit b8e75312
 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

 master)
Reported-by: Anhad Jai Singh <ffledgling@meta.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Chris Mason <clm@fb.com>
Cc: Rik van Riel <riel@surriel.com>
Change-Id: I2c05f6dd74add156d1541d50d6e3147106c80036
Signed-off-by: Seiya Wang <seiya.wang@mediatek.com>

At the moment, the CD table is allocated for each SID, which wastes
memory for SIDs belonging to the same domain device (domain).

Previously, the lifetime for a CD was allocated only once when the
device was attached and it never got freed, and the CD would be reused
for the next attach(s).

As EL2 doesn't know which SIDs are part of the same device, it can use
the domain as an indication to share the CD table between SIDs which makes
the CD table ownership part of the domain. However that only works
for devices that doesn't use pasid.

The CD table lifecycles is as follows:
For attach:
- PASID != 0, the CD is read from the STE as PASID = 0 must be
  attached first, and it would allocate the CD table before.
- PASID = 0 and PASID_BITs > 0: Devices that support pasids,
  allocate a new CD table as they can't be shared.
- PASID_BITS = 0: Share the CDptr inside the domain if existing,
  otherwise allocate it.

For detach:
- PASID != 0: invalidate that the CD entry.
- PASID = 0 and PASID_BITs > 0: Devices that support pasids, free the
  CD table and invalidate the STE
- PASID_BITS = 0: invalidate the STE, the cd table is per domain would
  be freed at free_domain.

Bug: 366562658
Bug: 277989609
Bug: 278749606

Change-Id: Iffcd448e1802924917c19947d9d3f2abc942975b
Signed-off-by: Mostafa Saleh <smostafa@google.com>

When mapping pages in the identity mapped domain,the driver chooses
the most optimal page size based on the requested size.
However, this must be also be aligned to the address.

Bug: 277989609
Bug: 278749606

Change-Id: Id442198eaf33be6b18f3e5198e2f365e279ff6b5
Signed-off-by: Mostafa Saleh <smostafa@google.com>

The hypervisor keeps track of mapped pages in the IOMMU page tables,
and checks the ownership of the host overthese pages.
There is also a hardening check to prevent mapping a page in the
IOMMU that is shared with the hyp, this mainly an extra hardening
as there shouldn't be such use case.

However, there is a bug in this path where the address passed to the
function was the physical address instead of virtual address. As this
is a hardening check it should lead to security problems, but only
failed IOMMU map pages which should have passed.

Bug: 277989609
Bug: 278749606

Change-Id: Ib571e90c358b2ffd9545c83674c407d0ddc11cb2
Signed-off-by: Mostafa Saleh <smostafa@google.com>

When a domain is freed, it should also free the page table struct
"arm_lpae_io_pgtable" which is per domain, as the domain is freed
and this memory would be leaked.

Bug: 277989609
Bug: 278749606

Change-Id: I6eaf00977d613d203f3918485d4cd8618ec40c9e
Signed-off-by: Mostafa Saleh <smostafa@google.com>

When a device is removed from a bus, it calls "release_device"
then frees the device domain if possible.
However, as "kvm_arm_smmu_release_device" doesn't detach the
device from the domain, it's still refcounted and wouldn't be freed.

On release_device, call detach device to decrement the domain refcount
and also puts the device in blocking state.

Bug: 369495618
Change-Id: I91dfdce7ab2ba4b0abc0569b6da081a3456ba2a8
Signed-off-by: Mostafa Saleh <smostafa@google.com>

1 function symbol(s) added
  'unsigned long sum_mthp_stat(int, enum mthp_stat_item)'

Bug: 359422098
Change-Id: Ib04e8a38e64ac641e46a376385b022e329a27388
Signed-off-by: chunpeng li <lichunpeng@xiaomi.com>