* [PATCH v7 00/13] selftests/mm: fix failures and robustness improvements
From: Sayali Patil @ 2026-05-21 6:33 UTC (permalink / raw)
To: Andrew Morton, Shuah Khan, linux-mm, linux-kernel,
linux-kselftest, Ritesh Harjani
Cc: David Hildenbrand, Zi Yan, Michal Hocko, Oscar Salvador,
Lorenzo Stoakes, Dev Jain, Liam.Howlett, linuxppc-dev, Miaohe Lin,
Venkat Rao Bagalkote, Sayali Patil
Hi all,
Powerpc systems with a 64K base page size exposed several issues while
running mm selftests. Some tests assume specific hugetlb configurations,
use incorrect interfaces, or fail instead of skipping when the required
kernel features are not available.
This series fixes these issues and improves test robustness.
Please review the patches and provide any feedback or suggestions for
improvement.
Thanks,
Sayali
---
v6->v7
- Rebased onto the latest mm-new branch, top commit of the base is
commit 0cec77cfd531 ("mm/filemap: fix page_cache_prev_miss() when no hole is found")
- Dropped "selftest/mm: align memory size to huge page size in
hugepage-mremap test":
Similar patch has already been merged.
- For "selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero":
Changed format specifier of bytes to %zu as per review
comment.
- For "selftests/mm: move hwpoison setup into run_test() and silence
modprobe output for memory-failure category":
Added condition to avoid executing the test pipeline for skipped tests and assign
ret directly.
v6: https://lore.kernel.org/all/cover.1777877814.git.sayalip@linux.ibm.com/
---
v5->v6
- For "selftests/mm: restore default nr_hugepages value via exit trap
in charge_reserved_hugetlb.sh":
Extended trap to include INT and TERM in hugetlb tests to ensure
nr_hugepages is restored on signal-based exits.
- For "selftests/mm: restore default nr_hugepages value via exit trap
in hugetlb_reparenting_test.sh":
Extended trap to include INT and TERM in hugetlb tests to ensure
nr_hugepages is restored on signal-based exits.
- For "selftests/mm: fix cgroup task placement and drop memory.current
checks in hugetlb_reparenting_test.sh":
Updated the subshell invocation to pass variables as positional arguments
instead of interpolating them into the command string as per review comment.
- For "selftests/mm: move hwpoison setup into run_test() and silence modprobe
output for memory-failure category":
Updated the condition to avoid unconditional module removal and ensures it is
only unloaded if loaded by the test.
v5: https://lore.kernel.org/all/cover.1776150071.git.sayalip@linux.ibm.com/
---
---
v4->v5
- For "selftests/mm: move hwpoison setup into run_test() and silence modprobe
output for memory-failure category":
Renamed LOADED_MOD to LOADED_HWPOISON_INJECT_MOD as per review comment.
- Dropped "selftests/cgroup: extend test_hugetlb_memcg.c to support all huge
page sizes":
Due to intermittent failures observed on some systems.
- Added Tested-by from Venkat for all patches.
- Added Reviewed-by from Zi yan for patches 7,8 and 13.
- Added Acked-by from Zi yan for patches 1 and 3.
v4: https://lore.kernel.org/all/cover.1775466329.git.sayalip@linux.ibm.com/
---
v3->v4
- selftests/mm: restore default nr_hugepages value via EXIT
trap in charge_reserved_hugetlb.sh:
Updated to use an EXIT trap to restore the original nr_hugepages
once at script termination, ensuring reliable restoration on all
exit paths.
- selftest/mm: fix cgroup task placement and drop memory.current checks
in hugetlb_reparenting_test.sh:
Updated to use a deterministic synchronization method by migrating the
workload process within a wrapper subshell before calling exec() to
ensure correct cgroup accounting.
- selftest/mm: align memory size to huge page size in hugepage-mremap
test:
Update test code directly to align memory allocations to the hugepage
size, rather than modifying run_vmtests.sh. This replaces the previous
commit “adjust hugepage-mremap test size for large huge pages” with
a cleaner, direct approach in the test itself.
- selftests/mm: ensure destination is hugetlb-backed in hugepage-mremap:
Updated to remove MAP_POPULATE flag for the mmap call as per review
comment.
- selftests/mm: skip uffd-wp-mremap if UFFD write-protect is unsupported:
Updated as per review comment to initialize features to zero and exit
on all uffd_get_features() failures, avoiding spurious test errors.
- selftests/mm: move hwpoison setup into run_test() and silence
modprobe output for memory-failure category:
Declared LOADED_MOD as local variable and avoided a redundant
skip message when the module is not found.
Updated logic to set exitcode to ksft_skip only when no failure has
been recorded.
- selftests/cgroup: extend test_hugetlb_memcg.c to support all huge
page sizes:
Updated to skip on memory constraints instead of returning
EXIT_FAILURE.
Updated the logic to fully account for the scenario when the
per-CPU stock is empty and a refill charges MEMCG_CHARGE_BATCH.
Updated to avoid overflow on 32-bit systems for memory.max value.
- Included "selftests/mm: restore default nr_hugepages value via
EXIT trap in hugetlb_reparenting_test.sh"
- Included "selftests/mm: free dynamically allocated PMD-sized
buffers in split_huge_page_test"
- Included "selftests/mm: clarify alternate unmapping in compaction_test"
- Dropped "selftests/mm: fix double increment in linked list cleanup in
compaction_test":
The behaviour is intentional.
v3: https://lore.kernel.org/all/cover.1774591179.git.sayalip@linux.ibm.com/
---
v2->v3
- selftests/mm: skip uffd-wp-mremap if UFFD write-protect is unsupported:
Rename function to check_uffd_wp_feature_supported() as suggested in review.
- selftest/mm: fix cgroup task placement and drop memory.current checks
in hugetlb_reparenting_test.sh:
Drop memory.current validation from the hugetlb reparenting test.
Keep tolerance at 7MB (reverting earlier increase to 8MB in v1).
- Included "selftests/mm: allow PUD-level entries in compound testcase of hmm
tests" patch:
Extend the compound testcase checks to accept PUD-level mappings.
- Included "selftests/mm: replace hardcoded THP size with runtime PMD page size in
hmm tests" patch:
Use read_pmd_pagesize() instead of TWOMEG and cap maximum THPs in
benchmarks to avoid integer overflow.
v2: https://lore.kernel.org/all/cover.1773305677.git.sayalip@linux.ibm.com/
---
v1->v2
- For "selftests/mm: ensure destination is hugetlb-backed in hugepage-mremap":
update FLAGS definition to MAP_HUGETLB | MAP_SHARED | MAP_POPULATE and
used it for mmap() calls as suggested during review.
v1: https://lore.kernel.org/all/cover.1773134177.git.sayalip@linux.ibm.com/
---
Sayali Patil (13):
selftests/mm: restore default nr_hugepages value via exit trap in
charge_reserved_hugetlb.sh
selftests/mm: fix hugetlb pathname construction in
charge_reserved_hugetlb.sh
selftests/mm: restore default nr_hugepages value via exit trap in
hugetlb_reparenting_test.sh
selftests/mm: fix hugetlb pathname construction in
hugetlb_reparenting_test.sh
selftests/mm: fix cgroup task placement and drop memory.current checks
in hugetlb_reparenting_test.sh
selftests/mm: size tmpfs according to PMD page size in
split_huge_page_test
selftests/mm: free dynamically allocated PMD-sized buffers in
split_huge_page_test
selftest/mm: register existing mapping with userfaultfd in
hugetlb-mremap
selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap
selftests/mm: skip uffd-wp-mremap if UFFD write-protect is unsupported
selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero
selftests/mm: move hwpoison setup into run_test() and silence modprobe
output for memory-failure category
selftests/mm: clarify alternate unmapping in compaction_test
.../selftests/mm/charge_reserved_hugetlb.sh | 45 +++++++++-----
tools/testing/selftests/mm/compaction_test.c | 3 +
tools/testing/selftests/mm/hugetlb-mremap.c | 32 +++-------
.../selftests/mm/hugetlb_reparenting_test.sh | 60 +++++++++---------
tools/testing/selftests/mm/run_vmtests.sh | 62 ++++++++++++-------
.../selftests/mm/split_huge_page_test.c | 27 +++++---
tools/testing/selftests/mm/uffd-stress.c | 6 +-
tools/testing/selftests/mm/uffd-wp-mremap.c | 13 ++++
8 files changed, 151 insertions(+), 97 deletions(-)
--
2.52.0
^ permalink raw reply
* [PATCHv2 net-next] net: ucc_geth: Batch RX packets before stack handoff
From: Rosen Penev @ 2026-05-21 6:07 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, open list:FREESCALE QUICC ENGINE UCC ETHERNET DRIVER,
open list
Collect received skbs on a local list during RX polling and pass the
completed batch to netif_receive_skb_list(). This lets the networking
stack process packets from a poll cycle in bulk instead of handing each
skb up individually.
Speedup tested with bidirectional iperf3 on a Watchguard Firebox T15-W.
Before:
[ ID][Role] Interval Transfer Bitrate Retr
[ 5][TX-C] 0.00-10.00 sec 490 MBytes 411 Mbits/sec sender
[ 5][TX-C] 0.00-10.01 sec 488 MBytes 409 Mbits/sec receiver
[ 7][RX-C] 0.00-10.00 sec 176 MBytes 147 Mbits/sec 167 sender
[ 7][RX-C] 0.00-10.01 sec 175 MBytes 146 Mbits/sec receiver
After:
[ ID][Role] Interval Transfer Bitrate Retr
[ 5][TX-C] 0.00-10.00 sec 502 MBytes 421 Mbits/sec sender
[ 5][TX-C] 0.00-10.01 sec 501 MBytes 420 Mbits/sec receiver
[ 7][RX-C] 0.00-10.00 sec 212 MBytes 178 Mbits/sec 148 sender
[ 7][RX-C] 0.00-10.01 sec 211 MBytes 177 Mbits/sec receiver
It would be nice to use napi_gro_receive, but the tradeoff is lower
routing performance. There is no support for hardware checksum offload,
which really hurts routing performance.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v2: add extra info in description
drivers/net/ethernet/freescale/ucc_geth.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 7af4b5e3f38e..bce1079fc06a 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -2894,6 +2894,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
u32 bd_status;
u8 *bdBuffer;
struct net_device *dev;
+ LIST_HEAD(rx_list);
ugeth_vdbg("%s: IN", __func__);
@@ -2934,7 +2935,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
dev->stats.rx_bytes += length;
/* Send the packet up the stack */
- netif_receive_skb(skb);
+ list_add_tail(&skb->list, &rx_list);
}
skb = get_new_skb(ugeth, bd);
@@ -2960,6 +2961,8 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
bd_status = in_be32((u32 __iomem *)bd);
}
+ netif_receive_skb_list(&rx_list);
+
ugeth->rxBd[rxQ] = bd;
return howmany;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 6/8] mm/bootmem_info: stop marking mem_section_usage as MIX_SECTION_INFO
From: Lance Yang @ 2026-05-21 5:03 UTC (permalink / raw)
To: david
Cc: davem, andreas, rppt, akpm, agordeev, gerald.schaefer, hca, gor,
borntraeger, svens, maddy, mpe, npiggin, chleroy, ljs, liam,
vbabka, surenb, mhocko, sparclinux, linux-kernel, linux-mm,
linux-s390, linuxppc-dev, Lance Yang
In-Reply-To: <20260511-bootmem_info_prep-v1-6-3fb0be6fc688@kernel.org>
On Mon, May 11, 2026 at 04:05:34PM +0200, David Hildenbrand (Arm) wrote:
>We never free the ms->usage data for boot memory sections (see
>section_deactivate()). And to identify whether ms->usage was allocated
>from memblock, we simply identify it by looking at PG_reserved.
Yep, PageReserved() is already enough to tell that case apart :)
>Consequently, there is no need to mark ms->usage as MIX_SECTION_INFO.
>Let's just stop doing that.
Right, MIX_SECTION_INFO doesn't add much here. For ms->usage, removal
code doesn't use MIX_SECTION_INFO at all :)
>Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>---
LGTM, feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 6ed60999d33d49251b42976a5511f1bb089797ed
From: kernel test robot @ 2026-05-21 2:53 UTC (permalink / raw)
To: Madhavan Srinivasan; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 6ed60999d33d49251b42976a5511f1bb089797ed powerpc: Remove unused functions
elapsed time: 731m
configs tested: 177
configs skipped: 277
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260521 gcc-8.5.0
arc randconfig-002-20260521 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260521 gcc-8.5.0
arm randconfig-002-20260521 gcc-8.5.0
arm randconfig-003-20260521 gcc-8.5.0
arm randconfig-004-20260521 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260521 gcc-8.5.0
arm64 randconfig-002-20260521 gcc-8.5.0
arm64 randconfig-003-20260521 gcc-8.5.0
arm64 randconfig-004-20260521 gcc-8.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260521 gcc-8.5.0
csky randconfig-002-20260521 gcc-8.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260521 gcc-11.5.0
hexagon randconfig-002-20260521 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260521 clang-20
i386 buildonly-randconfig-002-20260521 clang-20
i386 buildonly-randconfig-003-20260521 clang-20
i386 buildonly-randconfig-004-20260521 clang-20
i386 buildonly-randconfig-005-20260521 clang-20
i386 buildonly-randconfig-006-20260521 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260521 clang-20
i386 randconfig-002-20260521 clang-20
i386 randconfig-003-20260521 clang-20
i386 randconfig-004-20260521 clang-20
i386 randconfig-005-20260521 clang-20
i386 randconfig-006-20260521 clang-20
i386 randconfig-007-20260521 clang-20
i386 randconfig-011-20260521 gcc-14
i386 randconfig-012-20260521 gcc-14
i386 randconfig-013-20260521 gcc-14
i386 randconfig-014-20260521 gcc-14
i386 randconfig-015-20260521 gcc-14
i386 randconfig-016-20260521 gcc-14
i386 randconfig-017-20260521 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260521 gcc-11.5.0
loongarch randconfig-002-20260521 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips rt305x_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260521 gcc-11.5.0
nios2 randconfig-002-20260521 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260521 gcc-12.5.0
parisc randconfig-002-20260521 gcc-12.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mgcoge_defconfig clang-23
powerpc randconfig-001-20260521 gcc-12.5.0
powerpc randconfig-002-20260521 gcc-12.5.0
powerpc stx_gp3_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260521 gcc-12.5.0
powerpc64 randconfig-002-20260521 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-15.2.0
riscv randconfig-001-20260521 gcc-15.2.0
riscv randconfig-002 gcc-15.2.0
riscv randconfig-002-20260521 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 debug_defconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-15.2.0
s390 randconfig-001-20260521 gcc-15.2.0
s390 randconfig-002 gcc-15.2.0
s390 randconfig-002-20260521 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001 gcc-15.2.0
sh randconfig-001-20260521 gcc-15.2.0
sh randconfig-002 gcc-15.2.0
sh randconfig-002-20260521 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260521 gcc-8.5.0
sparc randconfig-002-20260521 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260521 gcc-8.5.0
sparc64 randconfig-002-20260521 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260521 gcc-8.5.0
um randconfig-002-20260521 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260521 clang-20
x86_64 buildonly-randconfig-002-20260521 clang-20
x86_64 buildonly-randconfig-003-20260521 clang-20
x86_64 buildonly-randconfig-004-20260521 clang-20
x86_64 buildonly-randconfig-005-20260521 clang-20
x86_64 buildonly-randconfig-006-20260521 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260521 clang-20
x86_64 randconfig-002-20260521 clang-20
x86_64 randconfig-003-20260521 clang-20
x86_64 randconfig-004-20260521 clang-20
x86_64 randconfig-005-20260521 clang-20
x86_64 randconfig-006-20260521 clang-20
x86_64 randconfig-011-20260521 gcc-14
x86_64 randconfig-012-20260521 gcc-14
x86_64 randconfig-013-20260521 gcc-14
x86_64 randconfig-014-20260521 gcc-14
x86_64 randconfig-015-20260521 gcc-14
x86_64 randconfig-016-20260521 gcc-14
x86_64 randconfig-071-20260521 clang-20
x86_64 randconfig-072-20260521 clang-20
x86_64 randconfig-073-20260521 clang-20
x86_64 randconfig-074-20260521 clang-20
x86_64 randconfig-075-20260521 clang-20
x86_64 randconfig-076-20260521 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260521 gcc-8.5.0
xtensa randconfig-002-20260521 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next] net: ucc_geth: Batch RX packets before stack handoff
From: Rosen Penev @ 2026-05-21 0:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
open list:FREESCALE QUICC ENGINE UCC ETHERNET DRIVER, open list
In-Reply-To: <20260520174545.69766438@kernel.org>
On Wed, May 20, 2026 at 5:45 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 20 May 2026 17:39:41 -0700 Rosen Penev wrote:
> > > On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:
> > > > Collect received skbs on a local list during RX polling and pass the
> > > > completed batch to netif_receive_skb_list(). This lets the networking
> > > > stack process packets from a poll cycle in bulk instead of handing each
> > > > skb up individually.
> > >
> > > GRO should be even better.
> > GRO will result in slower routing performance because there is no
> > hardware checksum.
>
> Mention this in the commit message too.
Will do.
> Network adapters without checksum offload are pretty rare these days.
Qualcomm continues to make adapters like these.
> Speaking of being old, do you know if this driver is used in practice?
Yes. In OpenWrt with kernel 6.18.
> Maybe we can delete it.
Way too early. I've tried previously to clean it up some but got rejected.
^ permalink raw reply
* Re: [PATCH net-next] net: ucc_geth: Batch RX packets before stack handoff
From: Jakub Kicinski @ 2026-05-21 0:45 UTC (permalink / raw)
To: Rosen Penev
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
open list:FREESCALE QUICC ENGINE UCC ETHERNET DRIVER, open list
In-Reply-To: <CAKxU2N_vHyqZK8tBbYLo49iOUJSO56rgqbSdw3CnCUZjbs1qNw@mail.gmail.com>
On Wed, 20 May 2026 17:39:41 -0700 Rosen Penev wrote:
> > On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:
> > > Collect received skbs on a local list during RX polling and pass the
> > > completed batch to netif_receive_skb_list(). This lets the networking
> > > stack process packets from a poll cycle in bulk instead of handing each
> > > skb up individually.
> >
> > GRO should be even better.
> GRO will result in slower routing performance because there is no
> hardware checksum.
Mention this in the commit message too.
Network adapters without checksum offload are pretty rare these days.
Speaking of being old, do you know if this driver is used in practice?
Maybe we can delete it.
^ permalink raw reply
* Re: [PATCH net-next] net: ucc_geth: Batch RX packets before stack handoff
From: Rosen Penev @ 2026-05-21 0:39 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
open list:FREESCALE QUICC ENGINE UCC ETHERNET DRIVER, open list
In-Reply-To: <20260520165746.7ed10c7b@kernel.org>
On Wed, May 20, 2026 at 4:57 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:
> > Collect received skbs on a local list during RX polling and pass the
> > completed batch to netif_receive_skb_list(). This lets the networking
> > stack process packets from a poll cycle in bulk instead of handing each
> > skb up individually.
>
> GRO should be even better.
GRO will result in slower routing performance because there is no
hardware checksum.
>
> > Speedup tested with bidirectional iperf3.
>
> Please mention the platform / board as well.
Will do.
> --
> pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next] net: ucc_geth: Batch RX packets before stack handoff
From: Jakub Kicinski @ 2026-05-20 23:57 UTC (permalink / raw)
To: Rosen Penev
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
open list:FREESCALE QUICC ENGINE UCC ETHERNET DRIVER, open list
In-Reply-To: <20260517192856.3925-1-rosenp@gmail.com>
On Sun, 17 May 2026 12:28:56 -0700 Rosen Penev wrote:
> Collect received skbs on a local list during RX polling and pass the
> completed batch to netif_receive_skb_list(). This lets the networking
> stack process packets from a poll cycle in bulk instead of handing each
> skb up individually.
GRO should be even better.
> Speedup tested with bidirectional iperf3.
Please mention the platform / board as well.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-20 23:37 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Matthew Wilcox, Liam R. Howlett, Suren Baghdasaryan,
Lorenzo Stoakes, akpm, linux-mm, vbabka, rppt, mhocko, jack,
pfalcato, wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1,
chrisl, kasong, shikemeng, nphamcs, bhe, youngjun.park,
linux-arm-kernel, linux-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <3be9475b-0e8a-4df8-a130-4262f993973d@kernel.org>
On Thu, May 21, 2026 at 5:35 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 5/20/26 23:15, Matthew Wilcox wrote:
> > On Thu, May 21, 2026 at 05:14:20AM +0800, Barry Song wrote:
> >> My understanding is that we should not blame applications here. This is 2026:
> >> there are basically only two kinds of applications — single-threaded and
> >> multi-threaded — and single-threaded applications are nearly extinct.
> >
> > all of the applications i run are either single threaded or don't fork.
> > what multithreaded applications call fork?
>
> Traditionally the problem was random libraries using fork+execve to launch other
> programs ... instead of using alternatives like posix_spwan (some use cases
> require more work done before execve and cannot yet switch to that). I'd hope
> that that is less of a problem on Android.
>
> I assume Android zygote might be multi threaded? Maybe sshd as well? Systemd?
> But I'd be surprised if there are really performance implications.
I am trying to answer the question above:
1. zygote, multi-threaded on my phone using Android13.
/ # ls /proc/`pidof zygote64`/task/
1359 22728 22729 22730 22731 22732
/proc/1359/task # cat 22728/comm
Jit thread pool
/proc/1359/task # cat 22730/comm
ReferenceQueueD
/proc/1359/task # cat 22731/comm
FinalizerDaemon
/proc/1359/task # cat 22732/comm
FinalizerWatchd
/proc/1359/task # cat 1359/comm
main
But on another phone of mine running Android 16, zygote64 is
single-threaded.
Not sure if it is due to the Android team making some changes
related to threads from Android 13 to Android 16.
2. sshd, multi-processes instead of multi-threads:
$ ps aux | grep sshd
root 1192 0.0 0.0 15444 9032 ? Ss 09:42 0:00
sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root 2465 0.0 0.0 17164 10760 ? Ss 09:42 0:00
sshd: barry [priv]
barry 2632 0.0 0.0 17164 7852 ? S 09:42 0:00
sshd: barry@pts/0
root 3305 2.5 0.0 17164 10772 ? Ss 09:44 0:00
sshd: barry [priv]
barry 3406 0.0 0.0 17164 7940 ? S 09:44 0:00
sshd: barry@pts/1
3. systemd, also multi-processes
$ ps ax | grep systemd
350 ? S<s 0:00 /lib/systemd/systemd-journald
387 ? Ss 0:00 /lib/systemd/systemd-udevd
666 ? Ss 0:00 /lib/systemd/systemd-oomd
667 ? Ss 0:00 /lib/systemd/systemd-resolved
728 ? Ss 0:00 @dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation --syslog-only
751 ? Ss 0:00 /lib/systemd/systemd-logind
753 ? Ssl 0:00 /usr/sbin/thermald --systemd
--dbus-enable --adaptive
1350 ? Ss 0:00 /lib/systemd/systemd --user
1428 ? Ss 0:00 /usr/bin/dbus-daemon --session
--address=systemd: --nofork --nopidfile --systemd-activation
--syslog-only
1900 ? Ssl 0:00 /usr/libexec/gnome-session-binary
--systemd-service --session=ubuntu
2141 ? Ssl 0:00 /lib/systemd/systemd-timesyncd
>
> Not sure about webbroswers .... I think most of them switched to fork servers,
> where I would assume fork servers would be single-threaded.
On my phone, Chrome is multi-process, but its parent process
chrome_zygote (10774) is single-threaded:
ps -A | grep chrome
u0_i15 9883 10774 321066464 119452 do_epoll_wait 0 S
com.android.chrome:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:15
u0_a142 10164 1359 35110548 277640 do_epoll_wait 0 S
com.android.chrome
u0_a278 10724 1359 9779864 104988 do_epoll_wait 0 S
com.google.android.apps.chromecast.app
u0_a142 10774 1359 32803908 64076 do_sys_poll 0 S
com.android.chrome_zygote
u0_a142 11173 1359 34208592 142192 do_epoll_wait 0 S
com.android.chrome:privileged_process0
/proc/10774/task # ls
10774
>
> So, yeah, getting a clear understanding how this ends up being a problem on
> Android would be great.
I guess the real issue is that in the Android market, there
are so many applications that are out of our control？
Here are some trace examples from Nanzhe:
iQIYI plugin
vma reader thread:
PbMisc-0, pid=27183, tgid=26444
vma writer thread:
i.video:plugin1, pid=27298, tgid=26444
writer blocked: 440394938 ns (440 ms)
reader stack:
vma_start_read
lock_vma_under_rcu
do_page_fault
do_translation_fault
do_mem_abort
el0_da
el0t_64_sync_handler
el0t_64_sync
writer stack:
__vma_start_write
dup_mmap
copy_mm
copy_process
kernel_clone
__arm64_sys_clone
invoke_syscall
el0_svc_common
do_el0_svc
el0_svc
Baidu Tieba
vma reader thread:
elastic_pms_pro, pid=7731, tgid=7575
vma writer thread:
com.baidu.tieba, pid=8005, tgid=7575
writer blocked: 514975545 ns(515 ms)
reader stack:
vma_start_read
lock_vma_under_rcu
do_page_fault
do_translation_fault
do_mem_abort
el0_da
el0t_64_sync_handler
el0t_64_sync
writer stack:
__vma_start_write
dup_mmap
copy_mm
copy_process
kernel_clone
__arm64_sys_clone
invoke_syscall
el0_svc_common
do_el0_svc
el0_svc
Thanks
Barry
^ permalink raw reply
* Re: [PATCH] powerpc: define __LITTLE_ENDIAN and __BIG_ENDIAN for math-emu
From: Christophe Leroy (CS GROUP) @ 2026-05-20 22:05 UTC (permalink / raw)
To: David Laight
Cc: Mingcong Bai, linux-kernel, Xi Ruoyao, Kexy Biscuit, stable,
kernel test robot, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, linuxppc-dev
In-Reply-To: <20260520194301.06d96a5f@pumpkin>
Le 20/05/2026 à 20:43, David Laight a écrit :
> On Wed, 20 May 2026 15:14:40 +0200
> "Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
>
>> Le 17/05/2026 à 15:54, David Laight a écrit :
>>> On Sun, 17 May 2026 12:14:21 +0800
>>> Mingcong Bai <jeffbai@aosc.io> wrote:
>>>
>>>> Similar to commit b929926f01f2 ("sh: define __BIG_ENDIAN for math-emu"),
>>>> define __LITTLE_ENDIAN and __BIG_ENDIAN as 0 to mitigate build-time
>>>> warnings:
>>>>
>>>> ./include/math-emu/double.h:59:21: error: ‘__BIG_ENDIAN’ is not defined, evaluates to ‘0’ [-Werror=undef]
>>>> 59 | #if __BYTE_ORDER == __BIG_ENDIAN
>>>> |
>>>>
>>>> Cc: stable@vger.kernel.org
>>>> Fixes: 13da9e200fe4 ("Revert "endian: #define __BYTE_ORDER"")
>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>> Closes: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Foe-kbuild-all%2F202507301656.7FEX6J5W-lkp%40intel.com%2F&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C3ed26b8c3d6449fdc29608deb69fac66%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639148994069314641%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FfFnXxMPXXxoOMM8fYU4df5gMjk3B2dPgQsjwUagaNA%3D&reserved=0
>>>> Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
>>>> ---
>>>> arch/powerpc/include/asm/sfp-machine.h | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/powerpc/include/asm/sfp-machine.h b/arch/powerpc/include/asm/sfp-machine.h
>>>> index 8b957aabb826d..db8525605c026 100644
>>>> --- a/arch/powerpc/include/asm/sfp-machine.h
>>>> +++ b/arch/powerpc/include/asm/sfp-machine.h
>>>> @@ -319,10 +319,12 @@
>>>> #define abort() \
>>>> return 0
>>>>
>>>> -#ifdef __BIG_ENDIAN
>>>> +#ifdef __BIG_ENDIAN__
>>>> #define __BYTE_ORDER __BIG_ENDIAN
>>>> +#define __LITTLE_ENDIAN 0
>>>> #else
>>>> #define __BYTE_ORDER __LITTLE_ENDIAN
>>>> +#define __BIG_ENDIAN 0
>>>> #endif
>>>
>>> I thought the expected/correct value for __BYTE_ORDER__ was either 1234 or 4321.
>>> (apart from pdp11's 2143).
>>
>> That's the case, in include/linux/kconfig.h we have:
>>
>> #ifdef CONFIG_CPU_BIG_ENDIAN
>> #define __BIG_ENDIAN 4321
>> #else
>> #define __LITTLE_ENDIAN 1234
>> #endif
>>
>> But as far as I understand the problem is that math-emu expects
>> __BIG_ENDIAN to be defined at all time as it has tests like:
>>
>> #if __BYTE_ORDER == __BIG_ENDIAN
>
> The gcc docs have (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fcpp%2FCommon-Predefined-Macros.html&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C3ed26b8c3d6449fdc29608deb69fac66%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639148994069350793%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D0BlZT73XnqHXHN2ukPFFUQw5lCCwaKfkmp6vMHz0Gk%3D&reserved=0):
>
> __BYTE_ORDER__
> __ORDER_LITTLE_ENDIAN__
> __ORDER_BIG_ENDIAN__
> __ORDER_PDP_ENDIAN__
>
> __BYTE_ORDER__ is defined to one of the values __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__, or __ORDER_PDP_ENDIAN__ to reflect the layout of multi-byte and multi-word quantities in memory. If __BYTE_ORDER__ is equal to __ORDER_LITTLE_ENDIAN__ or __ORDER_BIG_ENDIAN__, then multi-byte and multi-word quantities are laid out identically: the byte (word) at the lowest address is the least significant or most significant byte (word) of the quantity, respectively. If __BYTE_ORDER__ is equal to __ORDER_PDP_ENDIAN__, then bytes in 16-bit words are laid out in a little-endian fashion, whereas the 16-bit subwords of a 32-bit quantity are laid out in big-endian fashion.
>
> You should use these macros for testing like this:
>
> /* Test for a little-endian machine */
> #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
>
> The doc doesn't mention the value, but __ORDER_BIG_ENDIAN__ is 4321 (decimal).
>
> So the math-emu code is neither following gcc's rules or the kernel ones.
>
> Your change will break anything that currently does:
> #ifdef __BIG_ENDIAN
>
> Any change would have to be limited to code that is implementing math-emu.
asm/sfp-machine.h is only included by math-emu it seems, so the change
should be safe.
Apparently math-emu predates git history, not sure where it comes from.
Christophe
^ permalink raw reply
* Re: [PATCH 1/4] fbdev: Wrap user-invoked calls to fb_set_var() in helper
From: Christophe Leroy (CS GROUP) @ 2026-05-20 21:53 UTC (permalink / raw)
To: Helge Deller, Thomas Zimmermann, simona, airlied, lukas, maddy,
mpe, npiggin
Cc: dri-devel, linux-fbdev, linuxppc-dev
In-Reply-To: <0ce59eaf-1124-48c5-b812-c8e6b58e01d0@gmx.de>
Le 20/05/2026 à 20:51, Helge Deller a écrit :
> On 5/20/26 18:00, Thomas Zimmermann wrote:
>> Handle fbcon during display updates in fb_set_var_from_user(). Check
>> with fbcon if the mode change is possible, update hardware state and
>> finally update fbcon. Update all callers.
>>
>> Only the FBIOPUT_VSCREENINFO ioctl currently does all steps. Other
>> mode-changes callers in sysfs and driver code are missing fbcon-related
>> steps.
>>
>> With the new helper, ps3fb and sh_mobile_lcdcfb no longer maintain
>> fbcon state themselves.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>> drivers/video/fbdev/core/fb_chrdev.c | 6 +-----
>> drivers/video/fbdev/core/fbcon.c | 2 --
>> drivers/video/fbdev/core/fbmem.c | 13 +++++++++++++
>> drivers/video/fbdev/core/fbsysfs.c | 4 +---
>> drivers/video/fbdev/ps3fb.c | 5 +----
>> drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 +----
>> include/linux/fb.h | 2 ++
>> 7 files changed, 19 insertions(+), 18 deletions(-)
>>
>> ...
>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>> index 5178a33c752c..88680a7cabd5 100644
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -533,6 +533,8 @@ extern int fb_set_var(struct fb_info *info, struct
>> fb_var_screeninfo *var);
>> extern int fb_pan_display(struct fb_info *info, struct
>> fb_var_screeninfo *var);
>> extern int fb_blank(struct fb_info *info, int blank);
>> +int fb_set_var_from_user(struct fb_info *info, struct
>> fb_var_screeninfo *var);
>> +
>
> "extern" int fb_set_var_from_user(...) ?
No, 'extern' is pointless for function prototypes and 'checkpatch
--strict' will complain about it.
See following link, search for extern :
https://docs.kernel.org/dev-tools/checkpatch.html
>
> Other than that the series is a nice cleanup!
>
> Thanks!
> Helge
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Yang Shi @ 2026-05-20 21:39 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Lorenzo Stoakes, Suren Baghdasaryan, Barry Song, Matthew Wilcox,
akpm, linux-mm, liam, vbabka, rppt, mhocko, jack, pfalcato,
wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1, chrisl,
kasong, shikemeng, nphamcs, bhe, youngjun.park, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390,
Nanzhe Zhao
In-Reply-To: <e6d1017a-e4c5-493e-bfca-932c6d64eaac@kernel.org>
On Wed, May 20, 2026 at 3:34 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 5/19/26 14:53, Lorenzo Stoakes wrote:
> > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> >
> >>>
> >>> I think we either need to fix `fork()`, or keep the current
> >>> behavior of dropping the VMA lock before performing I/O.
> >>
> >> I see. So, this problem arises from the fact that we are changing the
> >> pagefaults requiring I/O operation to hold VMA lock...
> >> And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> >> is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> >> anonymous and COW VMAs only while holding mmap_write_lock, preventing
> >> any VMA modification. On the surface, that looks ok to me but I might
> >> be missing some corner cases. If nobody sees any obvious issues, I
> >> think it's worth a try.
> >
> > Not sure if you noticed but I did raise concerns ;)
> >
> > I wonder if you've confused the fault path and fork here, as I think Barry has
> > been a little unclear on that.
> >
> > What's being suggested in this thread is to fundamentally change fork behaviour
> > so it's different from the entire history of the kernel (or - presumably - at
> > least recent history :)
> I don't want fork() to become different in that regard.
>
> There is already a slight difference with vs. without per-VMA locks, because
> there is a window in-between us taking the write mmap_lock and all the per-VMA
> locks. I raised that previously [1] and assumed that it is probably fine.
>
> I also raised in the past why I think we must not allow concurrent page faults,
> at least as soon as anonymous memory is involved [2].
Thanks for sharing the context, it is quite helpful to understand the
race conditions. Because Lorenzo also raised the concern about page
fault race, I will reply to all the concerns regarding page fault race
together in this thread.
IIUC, there is already some sort of race with per vma lock. Before per
vma lock, mmap_lock did lock everything. So page fault happened either
before fork or after fork. But page fault can happen on other VMAs
which have not been lock'ed yet during fork with per vma lock. For
example, we have 3 VMAs, we lock the first VMA, but page fault still
can happen on the other 2 VMAs during fork if they already have
anon_vma. This is the status quo now, but it seems not harmful.
The bad race shared by David is caused by racing with copy page. So it
seems like it will be fine as long as we serialize copy page against
page fault if I don't miss anything. Since we decide whether to copy
page or not by checking vma->anon_vma, so it seems fine to not take
vma lock if vma->anon_vma is NULL. This will not introduce more race
either because setting up a new anon_vma in page fault or madvise
requires taking mmap_lock according to the earlier discussions.
Thanks,
Yang
>
> ... and I raised that this is pretty much slower by design right now: "Well, the
> design decision that CONFIG_PER_VMA_LOCK made for now to make page faults fast
> and to make blocking any page faults from happening to be slower ..." [3]
>
> [1] https://lore.kernel.org/all/970295ab-e85d-7af3-76e6-df53a5c52f8b@redhat.com/
> [2] https://lore.kernel.org/all/7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com/
> [3] https://lore.kernel.org/all/2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com/
>
> --
> Cheers,
>
> David
>
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: David Hildenbrand (Arm) @ 2026-05-20 21:35 UTC (permalink / raw)
To: Matthew Wilcox, Barry Song
Cc: Liam R. Howlett, Suren Baghdasaryan, Lorenzo Stoakes, akpm,
linux-mm, vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <ag4kj84EcKqamdB-@casper.infradead.org>
On 5/20/26 23:15, Matthew Wilcox wrote:
> On Thu, May 21, 2026 at 05:14:20AM +0800, Barry Song wrote:
>> My understanding is that we should not blame applications here. This is 2026:
>> there are basically only two kinds of applications — single-threaded and
>> multi-threaded — and single-threaded applications are nearly extinct.
>
> all of the applications i run are either single threaded or don't fork.
> what multithreaded applications call fork?
Traditionally the problem was random libraries using fork+execve to launch other
programs ... instead of using alternatives like posix_spwan (some use cases
require more work done before execve and cannot yet switch to that). I'd hope
that that is less of a problem on Android.
I assume Android zygote might be multi threaded? Maybe sshd as well? Systemd?
But I'd be surprised if there are really performance implications.
Not sure about webbroswers .... I think most of them switched to fork servers,
where I would assume fork servers would be single-threaded.
So, yeah, getting a clear understanding how this ends up being a problem on
Android would be great.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Matthew Wilcox @ 2026-05-20 21:15 UTC (permalink / raw)
To: Barry Song
Cc: Liam R. Howlett, Suren Baghdasaryan, Lorenzo Stoakes, akpm,
linux-mm, david, vbabka, rppt, mhocko, jack, pfalcato, wanglian,
chentao, lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong,
shikemeng, nphamcs, bhe, youngjun.park, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390,
Nanzhe Zhao
In-Reply-To: <CAGsJ_4zA8afu0xXy0WS+tMe-eesDX1W6UBmfAsuouUpcAgK8JQ@mail.gmail.com>
On Thu, May 21, 2026 at 05:14:20AM +0800, Barry Song wrote:
> My understanding is that we should not blame applications here. This is 2026:
> there are basically only two kinds of applications — single-threaded and
> multi-threaded — and single-threaded applications are nearly extinct.
all of the applications i run are either single threaded or don't fork.
what multithreaded applications call fork?
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-20 21:14 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Liam R. Howlett, Suren Baghdasaryan, Lorenzo Stoakes, akpm,
linux-mm, david, vbabka, rppt, mhocko, jack, pfalcato, wanglian,
chentao, lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong,
shikemeng, nphamcs, bhe, youngjun.park, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390,
Nanzhe Zhao
In-Reply-To: <ag4h87CBd-gph9zX@casper.infradead.org>
On Thu, May 21, 2026 at 5:05 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Wed, May 20, 2026 at 06:01:56AM +0800, Barry Song wrote:
> > > implied is that the per-vma locking may stall mmap_lock writes for
> > > longer than if the mmap_lock was taken in read mode? Barry, is that
> > > correct?
> >
> > Not the case — the actual situation is (if we modify the
> > current kernel to perform I/O without releasing VMA read locks):
> >
> > thread 1 PF: lock vma1 read ---- IO ----- ;
> > thread 2 PF: lock vma2 read ----- IO ----- ;
> > thread 3 PF: lock vma3 read ---- IO ----- ;
> > thread 4 fork: mmap_lock_write ---- lock vma1, vma2, vma3 write ;
> > thread 5 : take mmap_lock for any read/write reason
> >
> > Now you can see that thread 4 has to wait for the I/O of
> > VMA1, VMA2, and VMA3 to complete, and thread 5 then has to
> > wait for thread 4 to release mmap_lock. Both thread 4 and
> > thread 5 can become extremely slow, because I/O may be stuck
> > anywhere in the bio/request queue or filesystem GC.
> >
> > So now we have two choices:
> >
> > 1. Change fork() to avoid taking the vma write lock for vma1/2/3 where possible;
> > 2. Keep the current kernel behavior and drop the VMA lock before I/O:
>
> Option 3: Say that this is a very silly thing to optimise for. I have a
> hard time believing that any application will care about the latency of
> fork(), or the latency of page faults while it's in the middle of fork().
> Multithreaded applications just don't fork that often!
My understanding is that we should not blame applications here. This is 2026:
there are basically only two kinds of applications — single-threaded and
multi-threaded — and single-threaded applications are nearly extinct.
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Matthew Wilcox @ 2026-05-20 21:04 UTC (permalink / raw)
To: Barry Song
Cc: Liam R. Howlett, Suren Baghdasaryan, Lorenzo Stoakes, akpm,
linux-mm, david, vbabka, rppt, mhocko, jack, pfalcato, wanglian,
chentao, lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong,
shikemeng, nphamcs, bhe, youngjun.park, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390,
Nanzhe Zhao
In-Reply-To: <CAGsJ_4yKxg1QugcsJi3WD0KVGJKe-zXycgm5D6cRi9vWtNcpDQ@mail.gmail.com>
On Wed, May 20, 2026 at 06:01:56AM +0800, Barry Song wrote:
> > implied is that the per-vma locking may stall mmap_lock writes for
> > longer than if the mmap_lock was taken in read mode? Barry, is that
> > correct?
>
> Not the case — the actual situation is (if we modify the
> current kernel to perform I/O without releasing VMA read locks):
>
> thread 1 PF: lock vma1 read ---- IO ----- ;
> thread 2 PF: lock vma2 read ----- IO ----- ;
> thread 3 PF: lock vma3 read ---- IO ----- ;
> thread 4 fork: mmap_lock_write ---- lock vma1, vma2, vma3 write ;
> thread 5 : take mmap_lock for any read/write reason
>
> Now you can see that thread 4 has to wait for the I/O of
> VMA1, VMA2, and VMA3 to complete, and thread 5 then has to
> wait for thread 4 to release mmap_lock. Both thread 4 and
> thread 5 can become extremely slow, because I/O may be stuck
> anywhere in the bio/request queue or filesystem GC.
>
> So now we have two choices:
>
> 1. Change fork() to avoid taking the vma write lock for vma1/2/3 where possible;
> 2. Keep the current kernel behavior and drop the VMA lock before I/O:
Option 3: Say that this is a very silly thing to optimise for. I have a
hard time believing that any application will care about the latency of
fork(), or the latency of page faults while it's in the middle of fork().
Multithreaded applications just don't fork that often!
^ permalink raw reply
* Re: [PATCH 1/4] fbdev: Wrap user-invoked calls to fb_set_var() in helper
From: Helge Deller @ 2026-05-20 18:51 UTC (permalink / raw)
To: Thomas Zimmermann, simona, airlied, lukas, maddy, mpe, npiggin,
chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev
In-Reply-To: <20260520160744.130841-2-tzimmermann@suse.de>
On 5/20/26 18:00, Thomas Zimmermann wrote:
> Handle fbcon during display updates in fb_set_var_from_user(). Check
> with fbcon if the mode change is possible, update hardware state and
> finally update fbcon. Update all callers.
>
> Only the FBIOPUT_VSCREENINFO ioctl currently does all steps. Other
> mode-changes callers in sysfs and driver code are missing fbcon-related
> steps.
>
> With the new helper, ps3fb and sh_mobile_lcdcfb no longer maintain
> fbcon state themselves.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/core/fb_chrdev.c | 6 +-----
> drivers/video/fbdev/core/fbcon.c | 2 --
> drivers/video/fbdev/core/fbmem.c | 13 +++++++++++++
> drivers/video/fbdev/core/fbsysfs.c | 4 +---
> drivers/video/fbdev/ps3fb.c | 5 +----
> drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 +----
> include/linux/fb.h | 2 ++
> 7 files changed, 19 insertions(+), 18 deletions(-)
>
>...
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 5178a33c752c..88680a7cabd5 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -533,6 +533,8 @@ extern int fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var);
> extern int fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var);
> extern int fb_blank(struct fb_info *info, int blank);
>
> +int fb_set_var_from_user(struct fb_info *info, struct fb_var_screeninfo *var);
> +
"extern" int fb_set_var_from_user(...) ?
Other than that the series is a nice cleanup!
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH 3/4] fbdev: Wrap fbcon updates from vga-switcheroo in helper
From: Helge Deller @ 2026-05-20 18:49 UTC (permalink / raw)
To: Thomas Zimmermann, simona, airlied, lukas, maddy, mpe, npiggin,
chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev
In-Reply-To: <20260520160744.130841-4-tzimmermann@suse.de>
On 5/20/26 18:00, Thomas Zimmermann wrote:
> Handle console remapping in fbcon in fb_switch_output(). Vga-switcheroo
> invokes this functionality before switching physical outputs to a new
> graphics device. Open-coding fbcon state in vga-switcheroo exposed fbdev
> implementation details.
>
> Vga-switcheroo is used for switching physical outputs among graphics
> hardware. This functionality is only supported by DRM drivers. A later
> update will further move fb_switch_output() into DRM's fbdev emulation;
> thus fully decoupling vga-switcheroo from fbdev.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/vga/vga_switcheroo.c | 6 +++---
> drivers/video/fbdev/core/fbmem.c | 10 ++++++++++
> include/linux/fb.h | 1 +
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
> index 8fe1ae3c71bb..805953d0b941 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -31,11 +31,9 @@
> #define pr_fmt(fmt) "vga_switcheroo: " fmt
>
> #include <linux/apple-gmux.h>
> -#include <linux/console.h>
> #include <linux/debugfs.h>
> #include <linux/fb.h>
> #include <linux/fs.h>
> -#include <linux/fbcon.h>
> #include <linux/module.h>
> #include <linux/pci.h>
> #include <linux/pm_domain.h>
> @@ -735,8 +733,10 @@ static int vga_switchto_stage2(struct vga_switcheroo_client *new_client)
> if (!active->driver_power_control)
> set_audio_state(active->id, VGA_SWITCHEROO_OFF);
>
> +#if CONFIG_FB
I think this should be
#ifdef CONFIG_FB
Helge
^ permalink raw reply
* Re: [PATCH] powerpc: define __LITTLE_ENDIAN and __BIG_ENDIAN for math-emu
From: David Laight @ 2026-05-20 18:43 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Mingcong Bai, linux-kernel, Xi Ruoyao, Kexy Biscuit, stable,
kernel test robot, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, linuxppc-dev
In-Reply-To: <eb93d563-7042-458e-a5c0-b5389343d41b@kernel.org>
On Wed, 20 May 2026 15:14:40 +0200
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
> Le 17/05/2026 à 15:54, David Laight a écrit :
> > On Sun, 17 May 2026 12:14:21 +0800
> > Mingcong Bai <jeffbai@aosc.io> wrote:
> >
> >> Similar to commit b929926f01f2 ("sh: define __BIG_ENDIAN for math-emu"),
> >> define __LITTLE_ENDIAN and __BIG_ENDIAN as 0 to mitigate build-time
> >> warnings:
> >>
> >> ./include/math-emu/double.h:59:21: error: ‘__BIG_ENDIAN’ is not defined, evaluates to ‘0’ [-Werror=undef]
> >> 59 | #if __BYTE_ORDER == __BIG_ENDIAN
> >> |
> >>
> >> Cc: stable@vger.kernel.org
> >> Fixes: 13da9e200fe4 ("Revert "endian: #define __BYTE_ORDER"")
> >> Reported-by: kernel test robot <lkp@intel.com>
> >> Closes: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Foe-kbuild-all%2F202507301656.7FEX6J5W-lkp%40intel.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C08977974fb1c495e9bd508deb41bd275%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639146228768693730%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4qGulR%2BL7i7inksEbEH9jNGZS8HG80uvm3I9IyYzZww%3D&reserved=0
> >> Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
> >> ---
> >> arch/powerpc/include/asm/sfp-machine.h | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/powerpc/include/asm/sfp-machine.h b/arch/powerpc/include/asm/sfp-machine.h
> >> index 8b957aabb826d..db8525605c026 100644
> >> --- a/arch/powerpc/include/asm/sfp-machine.h
> >> +++ b/arch/powerpc/include/asm/sfp-machine.h
> >> @@ -319,10 +319,12 @@
> >> #define abort() \
> >> return 0
> >>
> >> -#ifdef __BIG_ENDIAN
> >> +#ifdef __BIG_ENDIAN__
> >> #define __BYTE_ORDER __BIG_ENDIAN
> >> +#define __LITTLE_ENDIAN 0
> >> #else
> >> #define __BYTE_ORDER __LITTLE_ENDIAN
> >> +#define __BIG_ENDIAN 0
> >> #endif
> >
> > I thought the expected/correct value for __BYTE_ORDER__ was either 1234 or 4321.
> > (apart from pdp11's 2143).
>
> That's the case, in include/linux/kconfig.h we have:
>
> #ifdef CONFIG_CPU_BIG_ENDIAN
> #define __BIG_ENDIAN 4321
> #else
> #define __LITTLE_ENDIAN 1234
> #endif
>
> But as far as I understand the problem is that math-emu expects
> __BIG_ENDIAN to be defined at all time as it has tests like:
>
> #if __BYTE_ORDER == __BIG_ENDIAN
The gcc docs have (https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html):
__BYTE_ORDER__
__ORDER_LITTLE_ENDIAN__
__ORDER_BIG_ENDIAN__
__ORDER_PDP_ENDIAN__
__BYTE_ORDER__ is defined to one of the values __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__, or __ORDER_PDP_ENDIAN__ to reflect the layout of multi-byte and multi-word quantities in memory. If __BYTE_ORDER__ is equal to __ORDER_LITTLE_ENDIAN__ or __ORDER_BIG_ENDIAN__, then multi-byte and multi-word quantities are laid out identically: the byte (word) at the lowest address is the least significant or most significant byte (word) of the quantity, respectively. If __BYTE_ORDER__ is equal to __ORDER_PDP_ENDIAN__, then bytes in 16-bit words are laid out in a little-endian fashion, whereas the 16-bit subwords of a 32-bit quantity are laid out in big-endian fashion.
You should use these macros for testing like this:
/* Test for a little-endian machine */
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
The doc doesn't mention the value, but __ORDER_BIG_ENDIAN__ is 4321 (decimal).
So the math-emu code is neither following gcc's rules or the kernel ones.
Your change will break anything that currently does:
#ifdef __BIG_ENDIAN
Any change would have to be limited to code that is implementing math-emu.
-- David
>
> Christophe
>
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Suren Baghdasaryan @ 2026-05-20 16:20 UTC (permalink / raw)
To: Barry Song
Cc: Lorenzo Stoakes, Matthew Wilcox, akpm, linux-mm, david, liam,
vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAGsJ_4zN5ezh9vvvQDQdMF2KuuDGvkhNjTZWc0y0Lsa-P4Aahw@mail.gmail.com>
On Wed, May 20, 2026 at 2:07 AM Barry Song <baohua@kernel.org> wrote:
>
> On Wed, May 20, 2026 at 3:50 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Wed, May 20, 2026 at 05:18:52AM +0800, Barry Song wrote:
> > > On Tue, May 19, 2026 at 8:53 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> > > >
> > > > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> > > >
> > > > > >
> > > > > > I think we either need to fix `fork()`, or keep the current
> > > > > > behavior of dropping the VMA lock before performing I/O.
> > > > >
> > > > > I see. So, this problem arises from the fact that we are changing the
> > > > > pagefaults requiring I/O operation to hold VMA lock...
> > > > > And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> > > > > is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> > > > > anonymous and COW VMAs only while holding mmap_write_lock, preventing
> > > > > any VMA modification. On the surface, that looks ok to me but I might
> > > > > be missing some corner cases. If nobody sees any obvious issues, I
> > > > > think it's worth a try.
> > > >
> > > > Not sure if you noticed but I did raise concerns ;)
> > > >
> > > > I wonder if you've confused the fault path and fork here, as I think Barry has
> > > > been a little unclear on that.
> > >
> > > I think I’ve been absolutely clear :-)
> >
> > On this point sure, I would argue less so around the fork stuff but I responded
> > on that specifically elsewhere so let's keep things moving :>)
> >
> > > We should either stick to the current behavior - drop
> > > the VMA lock before doing I/O, or change fork() so that it
> > > does not wait on vma_start_write().
> >
> > Again, as I said elsewhere, I think there might be a 3rd way possibly. It's a
> > big mistake to assume that there are only specific solutions to problems in the
> > kernel then to present a false dichotomy.
>
> I recalled that when we discussed this part in my slides:
>
> ‘For simplicity, rather than using a whitelist mechanism for
> per-VMA retry, we could use a blacklist instead: default to
> always retry via the VMA lock, and only allow mmap_lock-based
> page-fault retry for specific cases such as
> __vmf_anon_prepare().’
>
> Suren mentioned introducing a FALLBACK flag. With the
> FALLBACK flag, we would retry via mmap_lock; with the RETRY
> flag, we would retry via the VMA lock.
>
> Not sure whether this could really be called a ‘third way,’
> but it seems more like a shift from a whitelist model to a
> blacklist model, without changing the fundamental design, but
> it does change where we would need to touch the source code.
I thought the conclusion of the LSFMM discussion was that this is the
direction we would take. Maybe there were followup discussions which I
missed?
This approach still drops the lock before I/O but after I/O completion
it reacquires the same per-VMA lock instead of falling back to
mmap_lock. IMO it's the simplest fix for the issue you brought up.
>
> >
> > We absolutely hear you on this being a problem and it WILL be addressed one way
> > or another.
>
> Thanks. This is a bit of light in what has felt like a fairly
> dark situation. I really appreciate your thoughtful and
> responsible approach.
>
> >
> > Of the two approaches, as I said elsewhere, I prefer what you've done in this
> > series to anything touching fork.
> >
> > But give me time to look through the series please (I'd also suggest RFC'ing
> > when it's something kinda fundamental that might generate converastion, makes
> > life a bit easier on the review side :)
>
> Thanks! Sure, I’m happy to wait and there’s no urgency.
>
> Last year you made quite a significant contribution to the work
> when I tried to remove mmap_lock in madvise. I really
> appreciated it. Now we’re back to the same lock again, just in
> different places.
>
> Best Regards
> Barry
^ permalink raw reply
* [PATCH 4/4] fbdev: Do not export fbcon from fbdev
From: Thomas Zimmermann @ 2026-05-20 16:00 UTC (permalink / raw)
To: deller, simona, airlied, lukas, maddy, mpe, npiggin, chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev, Thomas Zimmermann
In-Reply-To: <20260520160744.130841-1-tzimmermann@suse.de>
There are no callers of fbcon outside fbdev. Move the declarations
into the internal header.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
MAINTAINERS | 1 -
drivers/video/fbdev/core/fb_chrdev.c | 2 +-
drivers/video/fbdev/core/fbcon.c | 1 -
drivers/video/fbdev/core/fbcon.h | 50 +++++++++++++++++++++++++
drivers/video/fbdev/core/fbmem.c | 2 +-
include/linux/fbcon.h | 55 ----------------------------
6 files changed, 52 insertions(+), 59 deletions(-)
delete mode 100644 include/linux/fbcon.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a80e7f0c25e6..d5058fa2cb54 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10141,7 +10141,6 @@ F: drivers/video/fbdev/core/fbcon_rotate.h
F: drivers/video/fbdev/core/fbcon_ud.c
F: drivers/video/fbdev/core/softcursor.c
F: drivers/video/fbdev/core/tileblit.c
-F: include/linux/fbcon.h
F: include/linux/font.h
F: lib/fonts/
diff --git a/drivers/video/fbdev/core/fb_chrdev.c b/drivers/video/fbdev/core/fb_chrdev.c
index 035e67d2c28f..ba1d0bc214c5 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -3,10 +3,10 @@
#include <linux/compat.h>
#include <linux/console.h>
#include <linux/fb.h>
-#include <linux/fbcon.h>
#include <linux/major.h>
#include "fb_internal.h"
+#include "fbcon.h"
/*
* We hold a reference to the fb_info in file->private_data,
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 50b84cd32938..853b52b40d01 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -70,7 +70,6 @@
#include <linux/printk.h>
#include <linux/slab.h>
#include <linux/fb.h>
-#include <linux/fbcon.h>
#include <linux/vt_kern.h>
#include <linux/selection.h>
#include <linux/font.h>
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 321cc7f44baa..407d207b14f1 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -11,6 +11,7 @@
#ifndef _VIDEO_FBCON_H
#define _VIDEO_FBCON_H
+#include <linux/compiler_types.h>
#include <linux/font.h>
#include <linux/types.h>
#include <linux/vt_buffer.h>
@@ -19,6 +20,11 @@
#include <asm/io.h>
+struct fb_blit_caps;
+struct fb_info;
+struct fb_var_screeninfo;
+struct fb_videomode;
+
/*
* This is the interface between the low-level console driver and the
* low-level frame buffer device
@@ -233,4 +239,48 @@ static inline int get_attribute(struct fb_info *info, u16 c)
(void) (&_r == &_v); \
(i == FB_ROTATE_UR || i == FB_ROTATE_UD) ? _r : _v; })
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE
+void __init fb_console_init(void);
+void __exit fb_console_exit(void);
+int fbcon_fb_registered(struct fb_info *info);
+void fbcon_fb_unregistered(struct fb_info *info);
+void fbcon_fb_unbind(struct fb_info *info);
+void fbcon_suspended(struct fb_info *info);
+void fbcon_resumed(struct fb_info *info);
+int fbcon_mode_deleted(struct fb_info *info,
+ struct fb_videomode *mode);
+void fbcon_delete_modelist(struct list_head *head);
+void fbcon_new_modelist(struct fb_info *info);
+void fbcon_get_requirement(struct fb_info *info,
+ struct fb_blit_caps *caps);
+void fbcon_fb_blanked(struct fb_info *info, int blank);
+int fbcon_modechange_possible(struct fb_info *info,
+ struct fb_var_screeninfo *var);
+void fbcon_update_vcs(struct fb_info *info, bool all);
+void fbcon_remap_all(struct fb_info *info);
+int fbcon_set_con2fb_map_ioctl(void __user *argp);
+int fbcon_get_con2fb_map_ioctl(void __user *argp);
+#else
+static inline void fb_console_init(void) {}
+static inline void fb_console_exit(void) {}
+static inline int fbcon_fb_registered(struct fb_info *info) { return 0; }
+static inline void fbcon_fb_unregistered(struct fb_info *info) {}
+static inline void fbcon_fb_unbind(struct fb_info *info) {}
+static inline void fbcon_suspended(struct fb_info *info) {}
+static inline void fbcon_resumed(struct fb_info *info) {}
+static inline int fbcon_mode_deleted(struct fb_info *info,
+ struct fb_videomode *mode) { return 0; }
+static inline void fbcon_delete_modelist(struct list_head *head) {}
+static inline void fbcon_new_modelist(struct fb_info *info) {}
+static inline void fbcon_get_requirement(struct fb_info *info,
+ struct fb_blit_caps *caps) {}
+static inline void fbcon_fb_blanked(struct fb_info *info, int blank) {}
+static inline int fbcon_modechange_possible(struct fb_info *info,
+ struct fb_var_screeninfo *var) { return 0; }
+static inline void fbcon_update_vcs(struct fb_info *info, bool all) {}
+static inline void fbcon_remap_all(struct fb_info *info) {}
+static inline int fbcon_set_con2fb_map_ioctl(void __user *argp) { return 0; }
+static inline int fbcon_get_con2fb_map_ioctl(void __user *argp) { return 0; }
+#endif
+
#endif /* _VIDEO_FBCON_H */
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index ecadbc58abff..e5221653ec2b 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -14,13 +14,13 @@
#include <linux/console.h>
#include <linux/export.h>
#include <linux/fb.h>
-#include <linux/fbcon.h>
#include <linux/lcd.h>
#include <linux/leds.h>
#include <video/nomodeset.h>
#include "fb_internal.h"
+#include "fbcon.h"
/*
* Frame buffer device initialization and setup routines
diff --git a/include/linux/fbcon.h b/include/linux/fbcon.h
deleted file mode 100644
index f206370060e1..000000000000
--- a/include/linux/fbcon.h
+++ /dev/null
@@ -1,55 +0,0 @@
-#ifndef _LINUX_FBCON_H
-#define _LINUX_FBCON_H
-
-#include <linux/compiler_types.h>
-
-struct fb_blit_caps;
-struct fb_info;
-struct fb_var_screeninfo;
-struct fb_videomode;
-
-#ifdef CONFIG_FRAMEBUFFER_CONSOLE
-void __init fb_console_init(void);
-void __exit fb_console_exit(void);
-int fbcon_fb_registered(struct fb_info *info);
-void fbcon_fb_unregistered(struct fb_info *info);
-void fbcon_fb_unbind(struct fb_info *info);
-void fbcon_suspended(struct fb_info *info);
-void fbcon_resumed(struct fb_info *info);
-int fbcon_mode_deleted(struct fb_info *info,
- struct fb_videomode *mode);
-void fbcon_delete_modelist(struct list_head *head);
-void fbcon_new_modelist(struct fb_info *info);
-void fbcon_get_requirement(struct fb_info *info,
- struct fb_blit_caps *caps);
-void fbcon_fb_blanked(struct fb_info *info, int blank);
-int fbcon_modechange_possible(struct fb_info *info,
- struct fb_var_screeninfo *var);
-void fbcon_update_vcs(struct fb_info *info, bool all);
-void fbcon_remap_all(struct fb_info *info);
-int fbcon_set_con2fb_map_ioctl(void __user *argp);
-int fbcon_get_con2fb_map_ioctl(void __user *argp);
-#else
-static inline void fb_console_init(void) {}
-static inline void fb_console_exit(void) {}
-static inline int fbcon_fb_registered(struct fb_info *info) { return 0; }
-static inline void fbcon_fb_unregistered(struct fb_info *info) {}
-static inline void fbcon_fb_unbind(struct fb_info *info) {}
-static inline void fbcon_suspended(struct fb_info *info) {}
-static inline void fbcon_resumed(struct fb_info *info) {}
-static inline int fbcon_mode_deleted(struct fb_info *info,
- struct fb_videomode *mode) { return 0; }
-static inline void fbcon_delete_modelist(struct list_head *head) {}
-static inline void fbcon_new_modelist(struct fb_info *info) {}
-static inline void fbcon_get_requirement(struct fb_info *info,
- struct fb_blit_caps *caps) {}
-static inline void fbcon_fb_blanked(struct fb_info *info, int blank) {}
-static inline int fbcon_modechange_possible(struct fb_info *info,
- struct fb_var_screeninfo *var) { return 0; }
-static inline void fbcon_update_vcs(struct fb_info *info, bool all) {}
-static inline void fbcon_remap_all(struct fb_info *info) {}
-static inline int fbcon_set_con2fb_map_ioctl(void __user *argp) { return 0; }
-static inline int fbcon_get_con2fb_map_ioctl(void __user *argp) { return 0; }
-#endif
-
-#endif /* _LINUX_FBCON_H */
--
2.54.0
^ permalink raw reply related
* [PATCH 3/4] fbdev: Wrap fbcon updates from vga-switcheroo in helper
From: Thomas Zimmermann @ 2026-05-20 16:00 UTC (permalink / raw)
To: deller, simona, airlied, lukas, maddy, mpe, npiggin, chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev, Thomas Zimmermann
In-Reply-To: <20260520160744.130841-1-tzimmermann@suse.de>
Handle console remapping in fbcon in fb_switch_output(). Vga-switcheroo
invokes this functionality before switching physical outputs to a new
graphics device. Open-coding fbcon state in vga-switcheroo exposed fbdev
implementation details.
Vga-switcheroo is used for switching physical outputs among graphics
hardware. This functionality is only supported by DRM drivers. A later
update will further move fb_switch_output() into DRM's fbdev emulation;
thus fully decoupling vga-switcheroo from fbdev.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/vga/vga_switcheroo.c | 6 +++---
drivers/video/fbdev/core/fbmem.c | 10 ++++++++++
include/linux/fb.h | 1 +
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 8fe1ae3c71bb..805953d0b941 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -31,11 +31,9 @@
#define pr_fmt(fmt) "vga_switcheroo: " fmt
#include <linux/apple-gmux.h>
-#include <linux/console.h>
#include <linux/debugfs.h>
#include <linux/fb.h>
#include <linux/fs.h>
-#include <linux/fbcon.h>
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/pm_domain.h>
@@ -735,8 +733,10 @@ static int vga_switchto_stage2(struct vga_switcheroo_client *new_client)
if (!active->driver_power_control)
set_audio_state(active->id, VGA_SWITCHEROO_OFF);
+#if CONFIG_FB
if (new_client->fb_info)
- fbcon_remap_all(new_client->fb_info);
+ fb_switch_outputs(new_client->fb_info);
+#endif
mutex_lock(&vgasr_priv.mux_hw_lock);
ret = vgasr_priv.handler->switchto(new_client->id);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 1a6758653b64..ecadbc58abff 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -684,6 +684,16 @@ void fb_set_suspend(struct fb_info *info, int state)
}
EXPORT_SYMBOL(fb_set_suspend);
+/**
+ * fb_switch_outputs - framebuffer got the outputs from vga-switcheroo
+ * @info: framebuffer
+ */
+void fb_switch_outputs(struct fb_info *info)
+{
+ fbcon_remap_all(info);
+}
+EXPORT_SYMBOL(fb_switch_outputs);
+
static int __init fbmem_init(void)
{
int ret;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 88680a7cabd5..e9a26e82322a 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -608,6 +608,7 @@ void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, const u8 *src, u32 idx, u32 h
u32 shift_high, u32 shift_low, u32 mod);
void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, const u8 *src, u32 s_pitch, u32 height);
extern void fb_set_suspend(struct fb_info *info, int state);
+extern void fb_switch_outputs(struct fb_info *info);
extern int fb_get_color_depth(struct fb_var_screeninfo *var,
struct fb_fix_screeninfo *fix);
extern int fb_get_options(const char *name, char **option);
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] fbdev: Wrap user-invoked calls to fb_blank() in helper
From: Thomas Zimmermann @ 2026-05-20 16:00 UTC (permalink / raw)
To: deller, simona, airlied, lukas, maddy, mpe, npiggin, chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev, Thomas Zimmermann
In-Reply-To: <20260520160744.130841-1-tzimmermann@suse.de>
Handle fbcon during blanking in fb_blank_from_user(). First blank the
hardware, then blank fbcon. Same for unblanking. Update all callers and
resolve the duplicated logic.
With the new helper, fbdev's sysfb code no longer maintains fbcon state
by itself.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fb_chrdev.c | 4 +---
drivers/video/fbdev/core/fb_internal.h | 1 +
drivers/video/fbdev/core/fbmem.c | 10 ++++++++++
drivers/video/fbdev/core/fbsysfs.c | 5 +----
4 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_chrdev.c b/drivers/video/fbdev/core/fb_chrdev.c
index 54f926fb411b..035e67d2c28f 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -138,9 +138,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
return -EINVAL;
console_lock();
lock_fb_info(info);
- ret = fb_blank(info, arg);
- /* might again call into fb_blank */
- fbcon_fb_blanked(info, arg);
+ ret = fb_blank_from_user(info, arg);
unlock_fb_info(info);
console_unlock();
break;
diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
index 613832d335fe..62e75bf15b9b 100644
--- a/drivers/video/fbdev/core/fb_internal.h
+++ b/drivers/video/fbdev/core/fb_internal.h
@@ -44,6 +44,7 @@ extern struct fb_info *registered_fb[FB_MAX];
extern int num_registered_fb;
struct fb_info *get_fb_info(unsigned int idx);
void put_fb_info(struct fb_info *fb_info);
+int fb_blank_from_user(struct fb_info *info, int blank);
/* fb_procfs.c */
#if defined(CONFIG_FB_DEVICE)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index d37a1039e221..1a6758653b64 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -422,6 +422,16 @@ int fb_blank(struct fb_info *info, int blank)
}
EXPORT_SYMBOL(fb_blank);
+int fb_blank_from_user(struct fb_info *info, int blank)
+{
+ int ret = fb_blank(info, blank);
+
+ /* might again call into fb_blank */
+ fbcon_fb_blanked(info, blank);
+
+ return ret;
+}
+
static int fb_check_foreignness(struct fb_info *fi)
{
const bool foreign_endian = fi->flags & FBINFO_FOREIGN_ENDIAN;
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index 5ece236e6252..d9743ef35355 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -7,7 +7,6 @@
#include <linux/console.h>
#include <linux/fb.h>
-#include <linux/fbcon.h>
#include <linux/major.h>
#include "fb_internal.h"
@@ -229,9 +228,7 @@ static ssize_t store_blank(struct device *device,
arg = simple_strtoul(buf, &last, 0);
console_lock();
- err = fb_blank(fb_info, arg);
- /* might again call into fb_blank */
- fbcon_fb_blanked(fb_info, arg);
+ err = fb_blank_from_user(fb_info, arg);
console_unlock();
if (err < 0)
return err;
--
2.54.0
^ permalink raw reply related
* [PATCH 1/4] fbdev: Wrap user-invoked calls to fb_set_var() in helper
From: Thomas Zimmermann @ 2026-05-20 16:00 UTC (permalink / raw)
To: deller, simona, airlied, lukas, maddy, mpe, npiggin, chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev, Thomas Zimmermann
In-Reply-To: <20260520160744.130841-1-tzimmermann@suse.de>
Handle fbcon during display updates in fb_set_var_from_user(). Check
with fbcon if the mode change is possible, update hardware state and
finally update fbcon. Update all callers.
Only the FBIOPUT_VSCREENINFO ioctl currently does all steps. Other
mode-changes callers in sysfs and driver code are missing fbcon-related
steps.
With the new helper, ps3fb and sh_mobile_lcdcfb no longer maintain
fbcon state themselves.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fb_chrdev.c | 6 +-----
drivers/video/fbdev/core/fbcon.c | 2 --
drivers/video/fbdev/core/fbmem.c | 13 +++++++++++++
drivers/video/fbdev/core/fbsysfs.c | 4 +---
drivers/video/fbdev/ps3fb.c | 5 +----
drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 +----
include/linux/fb.h | 2 ++
7 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_chrdev.c b/drivers/video/fbdev/core/fb_chrdev.c
index 4ebd16b7e3b8..54f926fb411b 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -85,11 +85,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
var.activate &= ~FB_ACTIVATE_KD_TEXT;
console_lock();
lock_fb_info(info);
- ret = fbcon_modechange_possible(info, &var);
- if (!ret)
- ret = fb_set_var(info, &var);
- if (!ret)
- fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
+ ret = fb_set_var_from_user(info, &var);
unlock_fb_info(info);
console_unlock();
if (!ret && copy_to_user(argp, &var, sizeof(var)))
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b0e3e765360d..50b84cd32938 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2699,7 +2699,6 @@ void fbcon_update_vcs(struct fb_info *info, bool all)
else
fbcon_modechanged(info);
}
-EXPORT_SYMBOL(fbcon_update_vcs);
/* let fbcon check if it supports a new screen resolution */
int fbcon_modechange_possible(struct fb_info *info, struct fb_var_screeninfo *var)
@@ -2727,7 +2726,6 @@ int fbcon_modechange_possible(struct fb_info *info, struct fb_var_screeninfo *va
return 0;
}
-EXPORT_SYMBOL_GPL(fbcon_modechange_possible);
int fbcon_mode_deleted(struct fb_info *info,
struct fb_videomode *mode)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 30f2b59c47bf..d37a1039e221 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -346,6 +346,19 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
}
EXPORT_SYMBOL(fb_set_var);
+int fb_set_var_from_user(struct fb_info *info, struct fb_var_screeninfo *var)
+{
+ int ret = fbcon_modechange_possible(info, var);
+
+ if (!ret)
+ ret = fb_set_var(info, var);
+ if (!ret)
+ fbcon_update_vcs(info, var->activate & FB_ACTIVATE_ALL);
+
+ return ret;
+}
+EXPORT_SYMBOL(fb_set_var_from_user);
+
static void fb_lcd_notify_blank(struct fb_info *info)
{
int power;
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index baa2bae0fb5b..5ece236e6252 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -19,9 +19,7 @@ static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var)
var->activate |= FB_ACTIVATE_FORCE;
console_lock();
lock_fb_info(fb_info);
- err = fb_set_var(fb_info, var);
- if (!err)
- fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL);
+ err = fb_set_var_from_user(fb_info, var);
unlock_fb_info(fb_info);
console_unlock();
if (err)
diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
index dbcda307f6a6..1376d19b19ae 100644
--- a/drivers/video/fbdev/ps3fb.c
+++ b/drivers/video/fbdev/ps3fb.c
@@ -29,7 +29,6 @@
#include <linux/freezer.h>
#include <linux/uaccess.h>
#include <linux/fb.h>
-#include <linux/fbcon.h>
#include <linux/init.h>
#include <asm/cell-regs.h>
@@ -830,9 +829,7 @@ static int ps3fb_ioctl(struct fb_info *info, unsigned int cmd,
/* Force, in case only special bits changed */
var.activate |= FB_ACTIVATE_FORCE;
par->new_mode_id = val;
- retval = fb_set_var(info, &var);
- if (!retval)
- fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
+ retval = fb_set_var_from_user(info, &var);
console_unlock();
}
break;
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index 72969fe8e513..e8324b01700f 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -15,7 +15,6 @@
#include <linux/ctype.h>
#include <linux/dma-mapping.h>
#include <linux/delay.h>
-#include <linux/fbcon.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/ioctl.h>
@@ -1768,11 +1767,9 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
var.height = ch->display.height;
var.activate = FB_ACTIVATE_NOW;
- if (fb_set_var(info, &var) < 0)
+ if (fb_set_var_from_user(info, &var) < 0)
/* Couldn't reconfigure, hopefully, can continue as before */
return;
-
- fbcon_update_vcs(info, true);
}
/*
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 5178a33c752c..88680a7cabd5 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -533,6 +533,8 @@ extern int fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var);
extern int fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var);
extern int fb_blank(struct fb_info *info, int blank);
+int fb_set_var_from_user(struct fb_info *info, struct fb_var_screeninfo *var);
+
/*
* Helpers for framebuffers in I/O memory
*/
--
2.54.0
^ permalink raw reply related
* [PATCH 0/4] fbdev: Internalize fbcon
From: Thomas Zimmermann @ 2026-05-20 16:00 UTC (permalink / raw)
To: deller, simona, airlied, lukas, maddy, mpe, npiggin, chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev, Thomas Zimmermann
Turn fbcon into an internal client of fbdev. Manage all interactions
with graphics drivers within fbdev. Add helpers for these tasks and
convert drivers.
Fbdev's PS3 and SH-Mobile drivers update fbcon as part of user-invoked
mode changes. Call the new helpers, which also fix inconsistencies
among the various code paths.
Vga-switcheroo remaps the fbcon terminals when switching physical
outputs. For now, hide this in another helper. The call will later
move into DRM's fbdev emulation.
When all refactoring in place, fbdev manages fbcon interactions by
itself. Remove the public interfaces.
Thomas Zimmermann (4):
fbdev: Wrap user-invoked calls to fb_set_var() in helper
fbdev: Wrap user-invoked calls to fb_blank() in helper
fbdev: Wrap fbcon updates from vga-switcheroo in helper
fbdev: Do not export fbcon from fbdev
MAINTAINERS | 1 -
drivers/gpu/vga/vga_switcheroo.c | 6 +--
drivers/video/fbdev/core/fb_chrdev.c | 12 ++----
drivers/video/fbdev/core/fb_internal.h | 1 +
drivers/video/fbdev/core/fbcon.c | 3 --
drivers/video/fbdev/core/fbcon.h | 50 +++++++++++++++++++++++
drivers/video/fbdev/core/fbmem.c | 35 +++++++++++++++-
drivers/video/fbdev/core/fbsysfs.c | 9 +----
drivers/video/fbdev/ps3fb.c | 5 +--
drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 +--
include/linux/fb.h | 3 ++
include/linux/fbcon.h | 55 --------------------------
12 files changed, 98 insertions(+), 87 deletions(-)
delete mode 100644 include/linux/fbcon.h
base-commit: 121c16f9d8c56ea07263df84ab971cc10870fe88
--
2.54.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox