Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Let the vDSO move with mremap

オープン
  • 何か問題がありますか？
#450 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
40/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c, operating-systems
領域
backend, operating-systems

調査の方向性

Start with signal delivery in src/syscall/signal.c and the sys_mremap implementation; the issue names both but gives no test file. Trace how the vDSO address is stored per process and handled across fork and execve, then follow the mremap path for [vdso]. Done means a moved vDSO remains usable for signal returns, including when no SA_RESTORER is set.

索引モデルが issue の本文から書いたものです。

説明

enhancement

mremap of the vDSO page returns EFAULT (#447), because signal delivery returns every handler through the fixed address VDSO_BASE + VDSO_OFF_SIGRET (src/syscall/signal.c). If the vDSO moved, that address would be unmapped and the next handler would fault on return.

Linux lets the vDSO move. The arm64 vDSO mapping has an mremap hook that updates mm->context.vdso, and signal delivery returns through the trampoline at that address when the handler has no SA_RESTORER.

To match Linux, elfuse would need to:

  • keep the vDSO's current address per process, carried across fork and reset by execve
  • set X30 from that address in signal delivery
  • let sys_mremap move [vdso] like any other mapping and update the address

Refs #447

主要言語
C
スター
275
フォーク
29
平均マージ
2日 8時間
マージ済み PR（30日）
17

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sysprog21/elfuse のほかの issue

sysprog21/elfuse の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。