loongson-community / discussions

Cross-community issue tracker & discussions / 跨社区工单追踪 & 讨论场所
11 stars 0 forks source link

Kernel设置为64K PageSize后 无法启动 #47

Open Xinmudotmoe opened 8 months ago

Xinmudotmoe commented 8 months ago

image

同时 大多数elf的配置中对齐为0x4000(16k) 这可能与ld.bfd的代码有关

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000027a6c 0x0000000000027a6c  R E    `0x4000`
  LOAD           0x000000000002af30 0x000000000002af30 0x000000000002af30
                 0x00000000000021f0 0x0000000000002390  RW     `0x4000`
  DYNAMIC        0x000000000002bec0 0x000000000002bec0 0x000000000002bec0
                 0x0000000000000140 0x0000000000000140  RW     0x8
  GNU_EH_FRAME   0x00000000000242b0 0x00000000000242b0 0x00000000000242b0
                 0x000000000000088c 0x000000000000088c  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x000000000002af30 0x000000000002af30 0x000000000002af30
                 0x00000000000010d0 0x00000000000010d0  R      0x1
Xinmudotmoe commented 8 months ago

内核无法构建

复显步骤

  1. 使用 https://github.com/chenhuacai/linux/tree/loongarch-next
  2. 龙架构下执行 make defconfig
  3. 修改Kernel type and options - Page Table Layout - 64KB with 2 levels 注:64KB 3 Levels也会触发
  4. make vmlinux 注:此处跳过ko相关构建,仅以构建内核为目标

报错信息

mm/huge_memory.c: 在函数‘hugepage_init’中:
././include/linux/compiler_types.h:442:45: 错误:call to ‘__compiletime_assert_381’ declared with attribute error: BUILD_BUG_ON failed: ((16 + (16 - 3))-16) > 11
  442 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |                                             ^
././include/linux/compiler_types.h:423:25: 附注:in definition of macro ‘__compiletime_assert’
  423 |                         prefix ## suffix();                             \
      |                         ^~~~~~
././include/linux/compiler_types.h:442:9: 附注:in expansion of macro ‘_compiletime_assert’
  442 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |         ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:39:37: 附注:in expansion of macro ‘compiletime_assert’
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
      |                                     ^~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:50:9: 附注:in expansion of macro ‘BUILD_BUG_ON_MSG’
   50 |         BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
      |         ^~~~~~~~~~~~~~~~
./include/linux/bug.h:24:25: 附注:in expansion of macro ‘BUILD_BUG_ON’
   24 |                         BUILD_BUG_ON(cond);             \
      |                         ^~~~~~~~~~~~
mm/huge_memory.c:686:9: 附注:in expansion of macro ‘MAYBE_BUILD_BUG_ON’
  686 |         MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER > MAX_PAGE_ORDER);
      |         ^~~~~~~~~~~~~~~~~~

目前可能的缓解

避免在以64K页表为目标时编译 mm/huge_memory.c 关闭透明大页特性. 龙架构下 CONFIG_PAGE_SIZE_64KB 与 CONFIG_TRANSPARENT_HUGEPAGE 配置可能冲突.

chenhuacai commented 8 months ago

不能构建那前面的panic从何而来?

Xinmudotmoe commented 8 months ago

不能构建那前面的panic从何而来?

关掉透明大页配置后构建出来的

chenhuacai commented 8 months ago

ARCH_FORCE_MAX_ORDER设置的是多少?

Xinmudotmoe commented 8 months ago

ARCH_FORCE_MAX_ORDER设置的是多少?

CONFIG_ARCH_FORCE_MAX_ORDER=11
CONFIG_PAGE_SIZE_64KB=y

不过看arch/loongarch/Kconfig 的话, ARCH_FORCE_MAX_ORDER有default "13" if PAGE_SIZE_64KB 问题是否出在make defconfig?

chenhuacai commented 8 months ago

make defconfig应该做不到非常智能地解决这个问题。

xry111 commented 8 months ago

Just put a static_assert to reject invalid ARCH_FORCE_MAX_ORDER + PAGE_SIZE combinations and tell the user to adjust ARCH_FORCE_MAX_ORDER?

xry111 commented 1 month ago

IIUC the static assert (actually a BUILD_BUG_ON) is in-place now. I hit it several days ago building a MIPS kernel.

xry111 commented 1 month ago

Ref https://sourceware.org/pipermail/libc-alpha/2024-September/160253.html

xen0n commented 1 month ago

https://sourceware.org/pipermail/binutils/2024-October/137333.html https://sourceware.org/pipermail/binutils/2024-October/137348.html (EDIT: original submission is missing DCO signoff)

IMO it's overall best to just bump the BFD default maximum page size to 64KiB so every new binary would get aligned as such afterwards.