KP-6.6-rc1: bytedance: config.aarch64: Increase CONFIG_NR_CPU to 512

KUNPENG 920G has 320C, increase CONFIG_NR_CPU to support it.

Signed-off-by: Songtang Liu <liusongtang@bytedance.com>

KP-5.15-rc1: bytedance: enable CURVE25519 for KAE

KAE driver encryption and decryption depends on
curve25519-generic.ko, enable the corresponding
configs.

Signed-off-by: Peng Zhang <zhangpeng.00@bytedance.com>

v5.15.152.ve.7: bytedance: async_fork: Fix lockdep compilation failure

The 5.15 kernel has renamed mmap_sem to mmap_lock, and async-fork is
still using the old name. Fix async-fork's handling of lockdep,
otherwise enabling lockdep will cause compilation failure.

Signed-off-by: Peng Zhang <zhangpeng.00@bytedance.com>

v5.15.152.ve.6: x86/resctrl: Support Sub-NUMA cluster mode SNC6

commit 9bce6e94c4b39b6baa649784d92f908aa9168a45 upstream.

Support Sub-NUMA cluster mode with 6 nodes per L3 cache (SNC6) on some
Intel platforms.

Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Link: https://lore.kernel.org/r/20241031220213.17991-1-tony.luck@intel.com
Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com>

v5.15.152.ve.5: cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged

commit c47195631960b626058c335aec31f186fa854f97 upstream.

The CPPC performance feedback counters could be 0 or unchanged when the
target cpu is in a low-power idle state, e.g. power-gated or clock-gated.

When the counters are 0, cppc_cpufreq_get_rate() returns 0 KHz, which makes
cpufreq_online() get a false error and fail to generate a cpufreq policy.

When the counters are unchanged, the existing cppc_perf_from_fbctrs()
returns a cached desired perf, but some platforms may update the real
frequency back to the desired perf reg.

For the above cases in cppc_cpufreq_get_rate(), get the latest desired perf
from the CPPC reg to reflect the frequency because some platforms may
update the actual frequency back there; if failed, use the cached desired
perf.

Fixes: 6a4fec4f6d30 ("cpufreq: cppc: cppc_cpufreq_get_rate() returns zero in all error cases.")
Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
Reviewed-by: Zeng Heng <zengheng4@huawei.com>
Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com>
Reviewed-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com>

v5.15.152.ve.3: xfs, iomap: limit individual ioend chain lengths in writeback

commit ebb7fb1557b1d03b906b668aa2164b51e6b7d19a upstream.

Trond Myklebust reported soft lockups in XFS IO completion such as
this:

 watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [kworker/12:1:3106]
 CPU: 12 PID: 3106 Comm: kworker/12:1 Not tainted 4.18.0-305.10.2.el8_4.x86_64 #1
 Workqueue: xfs-conv/md127 xfs_end_io [xfs]
 RIP: 0010:_raw_spin_unlock_irqrestore+0x11/0x20
 Call Trace:
  wake_up_page_bit+0x8a/0x110
  iomap_finish_ioend+0xd7/0x1c0
  iomap_finish_ioends+0x7f/0xb0
  xfs_end_ioend+0x6b/0x100 [xfs]
  xfs_end_io+0xb9/0xe0 [xfs]
  process_one_work+0x1a7/0x360
  worker_thread+0x1fa/0x390
  kthread+0x116/0x130
  ret_from_fork+0x35/0x40

Ioends are processed as an atomic completion unit when all the
chained bios in the ioend have completed their IO. Logically
contiguous ioends can also be merged and completed as a single,
larger unit.  Both of these things can be problematic as both the
bio chains per ioend and the size of the merged ioends processed as
a single completion are both unbound.

If we have a large sequential dirty region in the page cache,
write_cache_pages() will keep feeding us sequential pages and we
will keep mapping them into ioends and bios until we get a dirty
page at a non-sequential file offset. These large sequential runs
can will result in bio and ioend chaining to optimise the io
patterns. The pages iunder writeback are pinned within these chains
until the submission chaining is broken, allowing the entire chain
to be completed. This can result in huge chains being processed
in IO completion context.

We get deep bio chaining if we have large contiguous physical
extents. We will keep adding pages to the current bio until it is
full, then we'll chain a new bio to keep adding pages for writeback.
Hence we can build bio chains that map millions of pages and tens of
gigabytes of RAM if the page cache contains big enough contiguous
dirty file regions. This long bio chain pins those pages until the
final bio in the chain completes and the ioend can iterate all the
chained bios and complete them.

OTOH, if we have a physically fragmented file, we end up submitting
one ioend per physical fragment that each have a small bio or bio
chain attached to them. We do not chain these at IO submission time,
but instead we chain them at completion time based on file
offset via iomap_ioend_try_merge(). Hence we can end up with unbound
ioend chains being built via completion merging.

XFS can then do COW remapping or unwritten extent conversion on that
merged chain, which involves walking an extent fragment at a time
and running a transaction to modify the physical extent information.
IOWs, we merge all the discontiguous ioends together into a
contiguous file range, only to then process them individually as
discontiguous extents.

This extent manipulation is computationally expensive and can run in
a tight loop, so merging logically contiguous but physically
discontigous ioends gains us nothing except for hiding the fact the
fact we broke the ioends up into individual physical extents at
submission and then need to loop over those individual physical
extents at completion.

Hence we need to have mechanisms to limit ioend sizes and
to break up completion processing of large merged ioend chains:

1. bio chains per ioend need to be bound in length. Pure overwrites
go straight to iomap_finish_ioend() in softirq context with the
exact bio chain attached to the ioend by submission. Hence the only
way to prevent long holdoffs here is to bound ioend submission
sizes because we can't reschedule in softirq context.

2. iomap_finish_ioends() has to handle unbound merged ioend chains
correctly. This relies on any one call to iomap_finish_ioend() being
bound in runtime so that cond_resched() can be issued regularly as
the long ioend chain is processed. i.e. this relies on mechanism #1
to limit individual ioend sizes to work correctly.

3. filesystems have to loop over the merged ioends to process
physical extent manipulations. This means they can loop internally,
and so we break merging at physical extent boundaries so the
filesystem can easily insert reschedule points between individual
extent manipulations.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reported-and-tested-by: Trond Myklebust <trondmy@hammerspace.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Li Lei <lilei.777@bytedance.com>

v5.15.152.ve.2: bytedance: cop: fix cpu num not correct when cpu offline

Override id is used for cgroup_override_proc to provide continue cpu num
for container enable this feature. It should not used when not enable COP.

Fixes: de9ed0a ("bytedance: sysfs: override /proc/stat in cgroup")
Signed-off-by: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>

5.15.152.ve.4: fix: revert "block/rq_qos: protect rq_qos apis with a new lock"

This reverts commit 34e489e6112716e266ad2193924281cf481d3344

34e489e6 may cause problem https://meego.larkoffice.com/sys_ste/issue/detail/5285298274,
since 34e489e6 try to fix a corner problem, it's safe to revert.

Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>

v5.10.200-1-velinux1u1: release 5.10.200-1-velinux1u1

Signed-off-by: Qiang Wang <wangqiang.wq.frank@bytedance.com>

v5.15.152.ve.1: rtc: efi: fixed typo in efi_procfs()

commit f5f4c982f7c8a8cffb2663078a40ecd7d82b534d upstream.

After the first check of the value of the "eft" variable
it does not change, it is obvious that a copy-paste
error was made here and the value of variable "alm"
should be checked here.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 501385f2a783 ("rtc: efi: add efi_procfs in efi_rtc_ops")
Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com>
Link: https://lore.kernel.org/r/20231006090444.306729-1-korotkov.maxim.s@gmail.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com>