Go: ランタイム：シグナルスタックのmlockが失敗しました：12

これは、Goプログラムに大きな影響を与えるカーネルのバグを回避しようとした結果です。 https://github.com/golang/go/issues/35777を参照して

エラーメッセージは、利用可能な既知の修正が2つしかないことを示しています。ulimitを増やすか、新しいカーネルにアップグレードします。

さて、私は公式のアルパインドッカーイメージを実行しています。その目的は、Goプログラムを構築できるようにすることです。 どうやらそれはできません。 IMHOアップストリームイメージは、その目的を達成するために修正されたものである必要があります。アップストリームイメージのバグをハックするためのビルドインフラではありません。

アルパインのイメージはGoチームによって維持されていますか？ （本物の質問です。それについてはわかりません。）いずれにせよ、はい、イメージは修正する必要があります。理想的には、カーネルをアップグレードします。

Dockerイメージ（https://hub.docker.com/_/golang）を誰がどのように維持するかは完全にはわかりませんが、Dockerハブリポジトリは「公式イメージ」であり、ステータスを取得するのは非常に困難です。ですから私は、食物連鎖が責任を負うのに十分な高さの誰かを想定しています。

これは「Dockerコミュニティによって維持されています」。 問題はで提出する必要があります

https://github.com/docker-library/golang/issues

編集：問題はホストカーネルであり、Dockerライブラリイメージではないため、修正できません。

それで、Goクラッシュの公式の解決策は、他のすべての人に指を向けてコードをハックすることですか？ 理にかなっています。

@karalabehttps：//golang.org/conductを思い出させてください。 特に、敬意を払い、慈善活動を行ってください。

質問に答えてください

問題を正しい問題追跡システムにリダイレクトするのが標準的な方法です。

Go側でどのオプションが検討されたかを確認したい場合は、前にリンクした問題で考えられる回避策と修正についての広範な議論があります。

この問題はGo1.13では発生しません。 エルゴ、これはGo1.14で導入されたバグです。

コードの一部を元に戻すと実際に修正されるため、修正できないと言って回避策を使用するように指示するのは不正です。 別の解決策は、問題のあるプラットフォーム/カーネルを検出し、Goに組み込まれたフォールバックメカニズムを提供することです。

別のカーネルを使用するように人々に指示することは、ほとんどの人が周りを回って新しいカーネルを構築できるわけではないため、特に厄介です。 alpineが新しいカーネルをリリースしない場合、ほとんどの開発者ができることはほとんどありません。 そして最後に、プロジェクトが安定したインフラストラクチャに依存していて、カーネルを交換するだけでは不十分な場合は、再び問題が発生します。

問題を正しい問題追跡システムにリダイレクトするのが標準的な方法です。

Goがクラッシュするという事実は、Dockerのせいではありません。 GoクラッシュをDockerリポジトリにリダイレクトするのはたわみです。

実行時にプリエンプティブスケジューリングを無効にすることもできます

$ GODEBUG=asyncpreemptoff=1 ./your_app

@ianlancetaylor影響を受けるカーネルで実行するときに、これを行うことをお勧めします。 それは実行可能ですか？

ところで、Dockerライブラリモジュールがタイムリーな更新を取得しないことは既知の問題であり、これはセキュリティ上の責任です。 買い手責任負担。

カーネルのバグは、Go 1.13でランダムなメモリ破損として現れました（プリエンプティブスケジューリングありとなしの両方）。 Go 1.14の新機能は、バグの存在を検出し、それを回避しようとし、それが不可能な場合は早期に大音量でクラッシュすることを好むことです。 あなたは私があなたに紹介した問題で詳細を見ることができます。

あなたは私を不誠実で厄介だと呼んでいるので、行動規範についてもう一度思い出させます： https ：

@karalabe 、私は間違って話しました、問題はあなたのホストカーネルであり、Dockerイメージではありません。 更新できませんか？

私は最新のUbuntuと利用可能な最新のカーネルを使用しています。 エラーメッセージに基づくと、利用可能なすべてのUbuntuカーネルはGo 1.14https ： //packages.ubuntu.com/search = linux-image-genericには適していないようです。

$ uname -aの出力をメインの問題のテキストに追加できますか？ そして、おそらくゴルーチンスタックトレースを削除しますか？

golang-devにメモを投稿しました。

cc @aclements

あなたが最新のubuntuとカーネルを使用していると言うとき、正確にはどういう意味ですか（つまり、dpkg -l linux-image- *、lsb_release -a、uname -a、そのようなものの出力）。修正は、19.10（現在の安定版リリース）と20.04（開発リリース）の両方のアップデートポケットのカーネルにあります。 18.04のGAカーネルには含まれていませんが、HWEカーネルには含まれていますが、それらはgcc 9でビルドされていないため、影響を受けることはありません。

@networkimprov信号のプリエンプションを無効にすると、バグが発生する可能性が低くなりますが、バグは引き続き存在します。 これは、特定のLinuxカーネルバージョンのバグです。 このバグは、すべての言語のすべてのプログラムに影響します。 信号プリエンプションを使用するGoプログラムで特に観察される可能性がありますが、他のすべてのプログラムにも存在します。

Goは、シグナルスタックをmlockすることでバグを回避しようとします。 mlockの制限に達しない限り、これは正常に機能します。 この回避策の1つの欠点は、mlockを実行しなかった場合に発生するようなランダムなメモリの破損が原因で失敗することがあるのではなく、問題を非常に目立たせることだと思います。

ある時点で、カーネルのバグを回避する方法はありません。

@karalabe

私は最新のUbuntuと利用可能な最新のカーネルを使用しています

$ docker pull -q ubuntu:latest
docker.io/library/ubuntu:latest
$ docker run --rm -i -t ubuntu
root<strong i="9">@e2689d364a25</strong>:/# uname -a
Linux e2689d364a25 5.4.8-050408-generic #202001041436 SMP Sat Jan 4 19:40:55 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

これは最小バージョン要件を満たしています。

同様に：

$ docker pull -q golang:1.14-alpine
docker.io/library/golang:1.14-alpine
$ docker run --rm -i -t golang:1.14-alpine
/go # uname -a
Linux d4a35392c5b8 5.4.8-050408-generic #202001041436 SMP Sat Jan 4 19:40:55 UTC 2020 x86_64 Linux

あなたが見ているものを明確にできますか？

@mwhudson

$ dpkg -l linux-image-*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                   Version      Architecture Description
+++-======================================-============-============-===============================================================
rc  linux-image-4.13.0-16-generic          4.13.0-16.19 amd64        Linux kernel image for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-4.13.0-19-generic          4.13.0-19.22 amd64        Linux kernel image for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-4.13.0-21-generic          4.13.0-21.24 amd64        Linux kernel image for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-4.13.0-25-generic          4.13.0-25.29 amd64        Linux kernel image for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-4.13.0-36-generic          4.13.0-36.40 amd64        Linux kernel image for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-4.13.0-37-generic          4.13.0-37.42 amd64        Linux kernel image for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-4.13.0-38-generic          4.13.0-38.43 amd64        Linux kernel image for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-4.13.0-41-generic          4.13.0-41.46 amd64        Linux kernel image for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-4.13.0-45-generic          4.13.0-45.50 amd64        Linux kernel image for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-4.15.0-23-generic          4.15.0-23.25 amd64        Signed kernel image generic
rc  linux-image-4.15.0-30-generic          4.15.0-30.32 amd64        Signed kernel image generic
rc  linux-image-4.15.0-32-generic          4.15.0-32.35 amd64        Signed kernel image generic
rc  linux-image-4.15.0-34-generic          4.15.0-34.37 amd64        Signed kernel image generic
rc  linux-image-4.15.0-36-generic          4.15.0-36.39 amd64        Signed kernel image generic
rc  linux-image-4.15.0-39-generic          4.15.0-39.42 amd64        Signed kernel image generic
rc  linux-image-4.15.0-42-generic          4.15.0-42.45 amd64        Signed kernel image generic
rc  linux-image-4.15.0-43-generic          4.15.0-43.46 amd64        Signed kernel image generic
rc  linux-image-4.15.0-45-generic          4.15.0-45.48 amd64        Signed kernel image generic
rc  linux-image-4.15.0-47-generic          4.15.0-47.50 amd64        Signed kernel image generic
rc  linux-image-4.18.0-17-generic          4.18.0-17.18 amd64        Signed kernel image generic
rc  linux-image-5.0.0-13-generic           5.0.0-13.14  amd64        Signed kernel image generic
rc  linux-image-5.0.0-15-generic           5.0.0-15.16  amd64        Signed kernel image generic
rc  linux-image-5.0.0-16-generic           5.0.0-16.17  amd64        Signed kernel image generic
rc  linux-image-5.0.0-17-generic           5.0.0-17.18  amd64        Signed kernel image generic
rc  linux-image-5.0.0-19-generic           5.0.0-19.20  amd64        Signed kernel image generic
rc  linux-image-5.0.0-20-generic           5.0.0-20.21  amd64        Signed kernel image generic
rc  linux-image-5.0.0-21-generic           5.0.0-21.22  amd64        Signed kernel image generic
rc  linux-image-5.0.0-25-generic           5.0.0-25.26  amd64        Signed kernel image generic
rc  linux-image-5.0.0-27-generic           5.0.0-27.28  amd64        Signed kernel image generic
rc  linux-image-5.0.0-29-generic           5.0.0-29.31  amd64        Signed kernel image generic
rc  linux-image-5.0.0-32-generic           5.0.0-32.34  amd64        Signed kernel image generic
rc  linux-image-5.3.0-19-generic           5.3.0-19.20  amd64        Signed kernel image generic
rc  linux-image-5.3.0-22-generic           5.3.0-22.24  amd64        Signed kernel image generic
rc  linux-image-5.3.0-23-generic           5.3.0-23.25  amd64        Signed kernel image generic
rc  linux-image-5.3.0-24-generic           5.3.0-24.26  amd64        Signed kernel image generic
rc  linux-image-5.3.0-26-generic           5.3.0-26.28  amd64        Signed kernel image generic
ii  linux-image-5.3.0-29-generic           5.3.0-29.31  amd64        Signed kernel image generic
ii  linux-image-5.3.0-40-generic           5.3.0-40.32  amd64        Signed kernel image generic
rc  linux-image-extra-4.13.0-16-generic    4.13.0-16.19 amd64        Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-extra-4.13.0-19-generic    4.13.0-19.22 amd64        Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-extra-4.13.0-21-generic    4.13.0-21.24 amd64        Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-extra-4.13.0-25-generic    4.13.0-25.29 amd64        Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-extra-4.13.0-36-generic    4.13.0-36.40 amd64        Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-extra-4.13.0-37-generic    4.13.0-37.42 amd64        Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-extra-4.13.0-38-generic    4.13.0-38.43 amd64        Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-extra-4.13.0-41-generic    4.13.0-41.46 amd64        Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
rc  linux-image-extra-4.13.0-45-generic    4.13.0-45.50 amd64        Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
ii  linux-image-generic                    5.3.0.40.34  amd64        Generic Linux kernel image

$ lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 19.10
Release:    19.10
Codename:   eoan

$ uname -a

Linux roaming-parsley 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ sudo apt-get dist-upgrade 

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

@myitcv

FROM golang:1.14-alpine
RUN  apk add --no-cache make gcc musl-dev linux-headers git wget

RUN \
  wget -O geth.tgz "https://github.com/ethereum/go-ethereum/archive/v1.9.11.tar.gz" && \
  mkdir /go-ethereum && tar -C /go-ethereum -xzf geth.tgz --strip-components=1 && \
  cd /go-ethereum && make geth

$ docker build .

Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM golang:1.14-alpine
1.14-alpine: Pulling from library/golang
c9b1b535fdd9: Already exists 
cbb0d8da1b30: Already exists 
d909eff28200: Already exists 
8b9d9d6824f5: Pull complete 
a50ef8b76e53: Pull complete 
Digest: sha256:544b5e7984e7b2e7a2a9b967bbab6264cf91a3b3816600379f5dc6fbc09466cc
Status: Downloaded newer image for golang:1.14-alpine
 ---> 51e47ee4db58

Step 2/3 : RUN  apk add --no-cache make gcc musl-dev linux-headers git wget
 ---> Running in 879f98ddb4ff
[...]
OK: 135 MiB in 34 packages
Removing intermediate container 879f98ddb4ff
 ---> 9132e4dae4c3

Step 3/3 : RUN   wget -O geth.tgz "https://github.com/ethereum/go-ethereum/archive/v1.9.11.tar.gz" &&   mkdir /go-ethereum && tar -C /go-ethereum -xzf geth.tgz --strip-components=1 &&   cd /go-ethereum && make geth
 ---> Running in a24c806c60d3
2020-02-26 07:18:54--  https://github.com/ethereum/go-ethereum/archive/v1.9.11.tar.gz
[...]
2020-02-26 07:18:58 (2.48 MB/s) - 'geth.tgz' saved [8698235]

env GO111MODULE=on go run build/ci.go install ./cmd/geth
runtime: mlock of signal stack failed: 12
runtime: increase the mlock limit (ulimit -l) or
runtime: update your kernel to 5.3.15+, 5.4.2+, or 5.5+
fatal error: mlock failed

申し訳ありませんが、私の前のコメントは誤解を招くものでした。 もちろん、Dockerコンテナ内でuname -aによって返されるカーネルバージョンは、ホストのバージョンになります。

したがって、次のようになります。

$ uname -a

Linux roaming-parsley 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

ホストOSカーネルをアップグレードする必要があります。

FWIW、Alpineを使用してmake gethを使用して上記でレイアウトした手順は、私にとって

...
Done building.
Run "./build/bin/geth" to launch geth.

はい。ただし、以前の投稿で、私はすでに最新のUbuntuを使用しており、パッケージリポジトリから利用可能な最新のカーネルをインストールしていることを強調しました。 ソースからカーネル全体を再構築する以外に、Go1.14で動作するようにカーネルを更新する方法がわかりません。 多分私は何かが欠けていますか？

強調するために、私は回避策が何であるかを理解しています、そして私がそれを機能させたいのであれば、私はそうすることができます。 最終的には他の人にも同じ問題が発生することが予想されるので、この問題レポートを開きました。 システムを更新するだけで問題が解決する場合は、それを解決策として喜んで受け入れますが、何かが足りない場合を除いて、固定カーネルは（最近の）Ubuntuユーザーには利用できないため、かなり大きなユーザーベースが影響を受ける可能性があります。

はい。ただし、以前の投稿で、私はすでに最新のUbuntuを使用しており、パッケージリポジトリから利用可能な最新のカーネルをインストールしていることを強調しました。 ソースからカーネル全体を再構築する以外に、Go1.14で動作するようにカーネルを更新する方法がわかりません。 多分私は何かが欠けていますか？

うーん、はい、私も焦点を合わせて再現しました。 修正はUbuntueoanカーネルのgitにあります： https ：//kernel.ubuntu.com/git/ubuntu/ubuntu-eoan.git/commit/？id = 59e7e6398a9d6d91cd01bc364f9491dc1bf2a426そしてそのコミットは5.3の祖先にあります。 0-40.32なので、修正は使用しているカーネルにあるはずです。 言い換えれば、カーネルチームを巻き込む必要があると思います。そうしようと思います。

@ karalabe-間違いに気づきました。最新のUbuntuを使用していましたが、実際にはeoanます。

@ mwhudson-注意すべきことは1つだけです（おそらくすでにこれを知っているでしょうが）、このスイッチの原因となるコードの表面的な一瞥：

https://github.com/golang/go/blob/20a838ab94178c55bc4dc23ddc332fce8545a493/src/runtime/os_linux_x86.go#L56 -L61

Go側がパッチリリース15以降をチェックしていることを示唆しているようです。 5.3.0-40.32はパッチバージョンとして何を報告しますか？ 私は0を推測していますか？

ここで問題を解決するまで、このディスカッションを再開します。

自分でつなぎ合わせなければならなかったので、少し要約します。

• 根本原因： https ：
• 影響を受けるLinuxカーネル：5.2.x、5.3.0-5.3.14、5.4.0-5.4.1
• 2019-12-05にリリースされたLinuxカーネル5.3.15を修正しました： https ：//lwn.net/Articles/806395/
• 2019-12-05でリリースされたLinuxカーネル5.4.2を修正しました： https ：//lwn.net/Articles/806394/
• Goの部分的な回避策： https ：
• 最新のUbuntuリリースで利用可能なLinuxカーネル： https ： generic
• Ubuntuで利用可能な最新のLinuxカーネルはバージョン5.3.0です。
• ただし、パッチはUbuntuの5.3.0カーネルに厳選されたようです： https ：//kernel.ubuntu.com/git/ubuntu/ubuntu-eoan.git/commit/

したがって、Ubuntuのカーネルにはパッチが適用されているようですが、回避策はとにかく有効になります。

したがって、Ubuntuのカーネルにはパッチが適用されているようですが、回避策はとにかく有効になります。

そうそう、私は実際に失敗を読むべきではありませんか？ これは、回避策が実際には必要ないが、Goがこれを知る良い方法がない場合、元のバグではなく、回避策が失敗することです。 UbuntuでGo1.14パッケージのチェックアウトにパッチを適用できますが、

問題は、現時点で「脆弱な」カーネルを使用しているユーザーの数だと思います。 今のところ、パッチが適用されていないカーネルをgcc9でコンパイルしているディストリビューションはそれほど多くありません。

そんなに多くはありえない...

有名な最後の言葉？ ：D

とはいえ、真面目な話ですが、カーネルを頻繁に更新する人はいないと思います。多くのシステムでは更新できません。 おそらく、どのシステム/ディストリビューションがデフォルトで脆弱なカーネルを使用して

UbuntuでGo1.14パッケージのチェックアウトにパッチを適用できますが、

また、ソースからビルドするユーザーを見逃すことになります。 たとえば、Launchpadのすべてのディストリビューションに最近のGoバンドルがないため、EthereumはPPAのソースビルドを実行します。

Ubuntu（および他のディストリビューション）がLinuxカーネルパッチリリースに従う代わりにチェリーピッキングを使用するのは一般的ですか？ https://packages.ubuntu.com/search?keywords=linux-image-genericでは、すべてのカーネルのパッチリリースがゼロになっています。

Googleですばやく検索する限り、Ubuntuは、ディストリビューションの出荷後に新しいカーネルをリリースするのではなく、セキュリティ修正を選択するだけです（つまり、パッチバージョンのバンプはありません）。 これの例外はLTSバージョン（5年間サポート）で、新しいハードウェアをサポートするために数年ごとにカーネルの更新を取得する可能性があります（ただし、これも非常にまれです）。 他のディストリビューションについては知りません。

今の私の限られた知識では、これは奇妙に思えます。 パッチリリースは、制御された方法でパッチを配布することを目的としているため、ユーザー（この場合はGoランタイム）は、含まれているパッチと含まれていないパッチを知ることができます。 しかし、これは現状なので、私たちはそれと一緒に暮らす必要があります。

未解決の質問：

• この問題の影響を受ける人は何人ですか？
• ulimitは実行可能な回避策ですか？
• Linuxカーネルのパッチ番号を「無視」するディストリビューションはUbuntuだけですか？
• 上記の質問への回答に応じて：Ubuntuに特別な検出を追加することは合理的でしょうか？

@neelance

Ubuntu（および他のディストリビューション）がLinuxカーネルパッチリリースに従う代わりにチェリーピッキングを使用するのは一般的ですか？

Ubuntuだけでなく、多くのディストリビューションがそれを行っています。 Debianがそれを行い、Red Hat Enterprise Linuxがそれを行い、SUSEがエンタープライズディストリビューションに対してもそれを行うことを期待しています。 アップストリームの安定したリリースを積極的にフォローできない場合（およびアップストリームのサポートがなくなると安定したリリースを切り替える場合）、バグ修正を取得する唯一の方法はチェリーピッキングです。 Fedoraは例外です。 少し経つと、最新の安定したリリースのアップストリームカーネルにリベースされます。

コンテナエンジンで使用されるプロプライエタリカーネルの問題もあります。 それらのソースを見ることさえできず、それらのいくつかは過去にカーネルのバージョン番号について嘘をついたことがあります。 さくらんぼ狩りも使っていると思います。

一般に、カーネル機能（またはバグ）のバージョンチェックは本当に悪い考えです。 静的リンクのためにGoの場合はさらに悪いので、アプリケーションの下のランタイムを交換してカーネルの期待を修正することは不可能です。

Ubuntu（および他のディストリビューション）がLinuxカーネルパッチリリースに従う代わりにチェリーピッキングを使用するのは一般的ですか？ https://packages.ubuntu.com/search?keywords=linux-image-genericでは、すべてのカーネルのパッチリリースがゼロになっています。

基本カーネルバージョン文字列は変更されません、それは本当です。 ただし、アップストリームの安定版リリースがマージされないという意味ではありません。コードが変更されると、代わりにABI番号が増加します。

適切な変更ログを表示しないメタパッケージを選択したことに注意してください。ここでは、最新バージョン5.4.0-14.17が5.4.18安定版リリースにマージされていることがわかります。
http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-5.4/linux-5.4_5.4.0-14.17/changelog

すべてのディストリビューションで適切な自動検出を行うことはほぼ不可能のようです。 3つのオプションがあります。

• 何もしない。
• 回避策をオプトインします。
• 回避策をオプトアウトします。

または、5.3.xおよび5.4.xでデフォルトで非同期プリエンプションを無効にし、ユーザーが実行時に有効にするようにします。

https://github.com/golang/go/issues/37436#issuecomment -591237929は、非同期プリエンプションを無効にすることは適切な解決策ではないと述べていますね。

厳密に言えば、非同期プリエンプションが発生する前に問題の報告はありませんでした。

実際、ランタイムは起動時に子プロセス（5.3.xおよび5.4.xの場合）をフォークしてバグをトリガーし、発生した場合は回避策を有効にすることができますか？ IIRCには信頼できる再現機能があります。https： //github.com/golang/go/issues/35326#issuecomment-558690446を参照して

非同期プリエンプションを無効にすることは気を散らすものです。 障害のあるカーネルで実行されているプログラムはまだ壊れています。 カーネルバージョンを指すmlock制限に遭遇したことに関するエラーとしてではなく、奇妙なメモリ破損として表示されるだけです。 明らかに問題を完全に修正したいのですが、明確なエラーまたはランダムなメモリの破損を選択する場合は、常に明確なエラーを選択する必要があると思います。

カーネルバージョンの検出がひどいことに同意します。それは、他のオプションがわからないということだけです。 誰かがその点で何か提案があれば、それは非常に役に立ちます。

できることの1つは、 GODEBUG設定を追加して、シグナルスタックのmlockを無効にすることです。 それは人々に実際の問題に焦点を合わせた回避策を与えるでしょう。 エラーメッセージでその設定について言及することができます。 カーネルにパッチが適用されているかどうかに関係なく、設定をオンにすることにつながるのではないかと心配しています。 しかし、少なくとも、パッチを適用したカーネルを実際に持っている人には、この問題を回避する方法が提供されます。 CC @aclements

実際、ランタイムは起動時に子プロセス（5.3.xおよび5.4.xの場合）をフォークしてバグをトリガーし、発生した場合は回避策を有効にすることができますか？ IIRCには信頼できる再生装置があります。＃35326（コメント）を参照してください。

これは興味深いアイデアですが、この場合、すべてのGoプログラムの起動時にテストを実行するにはコストがかかりすぎると思います。

私は何かを見逃したかもしれませんが（このスレッドは速く長くなりました！）、mlock制限を上げるだけの欠点または難しさは何ですか？無制限に設定する理由はほとんどありませんが、それを望まない場合でも、スレッドごとに4 KiBしか必要ないため、文字通り、単一プロセスのランタイムがmlockできる64MiBよりも多くなります。 。 AFAIK、ほとんどのディストリビューションはデフォルトで無制限のままにします。私が知っている唯一の注目すべき例外はDockerで、これはデフォルトで64 KiBに設定されていますが、これは--ulimit memlock=67108864をDockerに渡すことで発生します。

すでにかなり簡単な回避策が整っているようです。人々がこれをするのを妨げる何かがありますか？

問題のポイントは、可能であれば、手動の回避策を適用する必要がないということです。 1.14のリグレッションのように見えます。

Dockerライブラリ側で修正することはできません： https ：

ulimit回避策の問題は、時限爆弾であるということです。 現在、Go1.13でulimitを上げる必要のある自動プロセスはありません。 更新直後にGo1.14が失敗した場合は、それに気づいて修正します。

より興味深いシナリオは、誰かが影響を受けていない古いバージョンのカーネルを使用し、ある時点でカーネルを新しいバージョンに切り替えた場合に何が起こるかです。 突然すべてが壊れ始めますが、Goはアプリ層であり、カーネルはOS層であるため、接続を確立して修正を見つけるには時間がかかります。 問題は、コストがどうなるかです。

Goコンパイラだけなのか、Goで構築されたすべてのアプリにも問題があるのか​​どうかはすぐにはわかりません。 コンパイラだけの場合、それは幸運なケースであり、放射性降下物を封じ込めることができます。 ただし、1.14でビルドされたすべてのGoアプリがパニックになる傾向がある場合、これはビルド済みのバイナリ移植性を実際に損なう可能性があります。突然、私のコードが別のシステムで動作しなくなる

Goコンパイラだけなのか、Goで構築されたすべてのアプリにも問題があるのか​​どうかはすぐにはわかりません。

LinuxカーネルのバグはGo固有のものではありません。 私が正しく理解していれば、それはすべてのプログラムに影響します— Cで書かれたものでも！ — XMMまたはYMMレジスタを使用し、信号を受信する場合があります。 1.14未満のGoプログラムは、ゴルーチンのプリエンプションに内部的にシグナルを使用するため、他の多くのプログラムよりも深刻な影響を受けます。そのため、Go 1.14ランタイムにはmlock回避策が含まれています。

LinuxカーネルのバグはGo固有のものではありません。

ええ、でも私のカーネルにはパッチが適用されていますが、Goはまだパニックになっています:)

@aclements

私が知っている唯一の注目すべき例外はDockerで、デフォルトで64 KiBに設定されていますが、これは--ulimit memlock = 67108864をDockerに渡すことで発生します。

すでにかなり簡単な回避策が整っているようです。 人々がこれをするのを妨げる何かがありますか？

残念ながらそうです。 ここでの私たちの場合、Dockerコンテナを再構成するようにお客様に指示することはできません。 数が多すぎて、セットアップの環境変化に敏感です。 実際、Dockerコンテナーでアプリケーションを提供することを選択したのはそのためです。そのため、分離ツールのファサードにより、構成オプションの変更に関する心配が軽減されます。 コンテナの内容を変更することは問題ありませんが、コンテナを呼び出す方法はそれほど適切ではない可能性があります。

@aclements

無制限に設定する理由はほとんどありませんが、それを望まない場合でも、スレッドごとに4 KiBしか必要ないため、文字通り、単一プロセスのランタイムがmlockできる64MiBよりも多くなります。 。 AFAIK、ほとんどのディストリビューションはデフォルトで無制限のままにします。

そうではないようです-これは、ロックスペースに6KiBしかないUbuntuLTSです。

~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3795
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3795
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.6 LTS
Release:    16.04
Codename:   xenial
~$ uname -a
Linux bastion0 4.4.0-174-generic #204-Ubuntu SMP Wed Jan 29 06:41:01 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

正しく動作するようにパッチが適用されているが、Goが現在mlockエラーを生成しているカーネルの例の/proc/versionの内容は何ですか？ ありがとう。

@ucirello説明しているシステムでGoプログラムを実行する際に問題が発生しましたか？

$ cat /proc/version
Linux version 5.3.0-40-generic (buildd@lcy01-amd64-026) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020

おそらく、 /proc/version記録された日付を追加のシグナルとして使用できます。 それはおそらくリリース固有であるはずですが、これは苦痛です。 しかし、すべてが苦痛です。

議論は、より多くの誤検知または誤検知を受け入れることについてのようです。 要約は次のとおりです。

誤検知：回避策は、パッチが適用されたカーネルで有効になります。

• 再現性があります。 指示を表示することができます。
• 回帰のように見えます。
• 特定の環境では修正が困難です。
• Goバイナリは、一部の環境では実行できますが、他の環境では実行できません。

フォールスネガティブ：パッチが適用されていないカーネルでは、回避策は有効になっていません。

• 特に非同期プリエンプションが無効になっている場合、障害が発生することはめったにありません。
• メモリの破損による深刻な結果の可能性があります。
• デバッグが難しい。

@ianlancetaylor説明されているシステムに問題はありませんが、これは偶然の一致である可能性があります。つまり、エラーメッセージは5.3.15、5.4.2、または5.5を超えてアップグレードする必要があることを示しており、これは4.4.xです。箱。

いずれにせよ、私が強調したかったのは、ほとんどのディストリビューションが64Mでulimit -lを提供するという仮定は正しくないようだということです。 これは、 ulimit -lが64 KのLinuxボックスであり、標準インストールです。

ulimit設定を検出し、回避策を適用できない場合にクラッシュを回避する方法はありますか？ このようにして、状況を改善することはできますが、新しいクラッシュを引き起こすことはありませんか？ 次に、代わりに、潜在的なメモリ破損に関する警告を出力できます。

ulimit設定を検出し、回避策を適用できない場合にクラッシュを回避する方法はありますか？

実際、現在のコードはすでにulimit設定を検出しています。 直接クエリを実行することはありませんが、実行されたときに検出します。そのため、ユーザーにulimitを上げるように求める特定のエラーメッセージが出力されます。 他の何かがうまくいかない場合、それは実際には別のメッセージを出力します。 ランダムなメモリの破損よりも望ましいと考えたため、クラッシュは意図的なものです。

いずれにせよ、私が強調したかったのは、ほとんどのディストリビューションがulimit -lwith64Mを提供するという仮定は正しくないように思われるということです。 これは、ulimit -lが64K-のLinuxボックスであり、標準インストールです。

@ucirello 、そのデータポイントに感謝します。 私はUbuntuボックスを手元に持っていませんが、Ubuntuインストールで元のデバッグを行い、ulimitが設定されていないことを誓った可能性があります。 これは間違いなくコンテナに入っていませんか？

@ianlancetaylor私は、una​​meのレポートを確認するための迅速でダーティなスクリプトを作成しました： https ： //gist.github.com/Tasssadar/7424860a2764e3ef42c7dcce7ecfd341

これが最新の（まあ、-ish）Debianテストの結果です：

tassadar<strong i="9">@dorea</strong>:~/tmp$ go run gouname.go 
real uname
Linux dorea 5.4.0-3-amd64 #1 SMP Debian 5.4.13-1 (2020-01-19) x86_64 GNU/Linux

our uname
sysname Linux
nodename dorea
release 5.4.0-3-amd64  <-- used by go
version #1 SMP Debian 5.4.13-1 (2020-01-19)
machine x86_64
domainname (none)

Goはリリース文字列のみを使用しているため、パッチバージョンチェックは基本的にどこでも機能しませんが、バニラカーネルで機能します-DebianとRHEL / CentOS（幸運にも古いカーネルがあります）の両方がこの方法でそれを行い、.0を保持して後で実際のパッチバージョン。 残念ながら、 versionは同じ形式を使用していません。

編集：そしてそれをさらに厄介にするために、Ubuntuはおそらくすべての修正が組み込まれているとしても、パッチ番号をunameに入れません。 おそらく最善の行動は、これをクラッシュではなく警告にすることですか？ この時点で、ほとんどのカーネルはおそらくすでに更新されています。

ランダムなメモリの破損よりも望ましいと考えたため、クラッシュは意図的なものです。

@aclementsこの引数には小さな欠陥があります。問題は、ulimitに

@aclements

これは間違いなくコンテナに入っていませんか？

私はそれがコンテナではないと100％確信しています。 ただし、VMです。

$ sudo virt-what
xen
xen-hvm

@ucirello 、そのデータポイントに感謝します。 私はUbuntuボックスを手元に持っていませんが、Ubuntuインストールで元のデバッグを行い、ulimitが設定されていないことを誓った可能性があります。 これは間違いなくコンテナに入っていませんか？

別のデータポイントとして、私のUbuntuEoanメインシステムはデフォルトでulimit -l設定された64MBです。

@ucirello 4.4.xLinuxカーネルでは問題はありません。 このバグは、カーネルバージョン5.2で最初に発生しました。

@ ianlancetaylor-情報をありがとう。 その時、私はエラーメッセージを誤って解析したと思います。 私はこの事実を知りませんでした、そしてエラーメッセージは新しいバイナリが古いカーネルと互換性がないだろうと信じさせました。

Goプログラムは、問題が発生している可能性があることを示すバージョン番号のカーネルでのみエラーメッセージを報告します。

これが私たちにできることです：

1. 今日のように、 unameを使用して、脆弱なカーネルのカーネルバージョンを確認します。
2. カーネルがバージョンに応じて脆弱である場合は、 /proc/version読みください。
3. /proc/versionに文字列"2020"が含まれている場合は、カーネルにパッチが適用されていると想定します。
4. /proc/versionに文字列"gcc version 8" /proc/versionが含まれている場合は、パッチが適用されていてもカーネルが機能すると想定します（このバグは、カーネルがGCC 9以降でコンパイルされている場合にのみ発生するため）。
5. それ以外の場合は、脆弱なカーネルで今日行っているように、シグナルスタックでmlockを呼び出します。

これのポイントは、Goプログラムがmlockスペースを使い果たす回数を減らすことです。

/proc/version文字列"2020"れている可能性のあるパッチが適用されていないカーネルを知っている人はいますか？

安全のために、カーネルが主要なディストリビューション用にパッチを適用された時期を特定するように努める必要があります。 特定のディストリビューションでそれを特定できる人はいますか？ ありがとう。

これがまったく役立つかどうかはわかりませんが、Ubuntuは、標準のカーネルバージョンを探している人が利用できるようにしているようです。

$ cat /proc/version_signature
Ubuntu 5.3.0-1013.14-azure 5.3.18

@jrockwayありがとう、問題はカーネルバージョンがないことではなく、Ubuntuがバグのあるカーネルバージョンを使用していることですが、Ubuntuはバグのパッチを適用しているため、カーネルは実際に機能しますが、その事実を検出する方法がわかりません。

@ianlancetaylorの文字列照合ヒューリスティックに追加して、 /proc/versionをチェックすることもできます
5.3.x && x >= 15 || 5.4.x && x >= 2 （実際のコードではありませんが、アイデアは得られます）

おかげで、私たちはすでにuname結果でそれをチェックしています。

https://github.com/golang/go/issues/37436#issuecomment -591503305を参照してい

release 5.4.0-3-amd64  <-- used by go
version #1 SMP Debian 5.4.13-1 (2020-01-19) <-- has actual version

編集：Ubuntuでは、私が提案したように/proc/version_signatureをチェックできます。

ああ、すみません、それを逃しました。 したがって、一部のシステムに関するそのコメントによると、 releaseフィールドとunameによって返されるversionフィールドは、報告するカーネルバージョンによって異なります。 現在、 releaseフィールドはチェックしていますが、 versionフィールドはチェックしていません。

/proc/versionファイルには、別の情報セットが含まれています。

私のUbuntuシステムには/proc/versionがありますが、 /proc/version_signatureはありません。

@bbarenblatは、いくつかのディストリビューションのいくつかのバージョンからunameと/ proc / versionを収集して、

Debian不安定：

$ uname -v
#1 SMP Debian 5.3.9-3 (2019-11-19)
$ uname -r
5.3.0-2-amd64
$ cat /proc/version
Linux version 5.3.0-2-amd64 ([email protected]) (gcc version 9.2.1 20191109 (Debian 9.2.1-19)) #1 SMP Debian 5.3.9-3 (2019-11-19)

Debian 10.3（現在安定）：

$ uname -v
#1 SMP Debian 4.19.98-1 (2020-01-26)
$ uname -r
4.19.0-8-amd64
# cat /proc/version
Linux version 4.19.0-8-amd64 ([email protected]) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26)

Debian 7（非常に古い）：

$ uname -v
#1 SMP Debian 3.2.78-1
$ uname -r
3.2.0-4-amd64
$ cat /proc/version
Linux version 3.2.0-4-amd64 ([email protected]) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.78-1

Debian「どこか安定していて、時々不安定なパッケージがある」：

$ uname -v
#1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)
$ uname -r
4.19.0-6-amd64
$ cat /proc/version
Linux version 4.19.0-6-amd64 ([email protected]) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)

Ubuntu 19.10：

$ uname -v
#32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020
$ uname -r
5.3.0-40-generic
$ cat /proc/version  
Linux version 5.3.0-40-generic (buildd@lcy01-amd64-026) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020

GCPカーネルを搭載したUbuntu19.10（これは実際には5.3.0です）：

$ uname -v
#9-Ubuntu SMP Mon Nov 11 09:52:23 UTC 2019
$ uname -r
5.3.0-1008-gcp
$ cat /proc/version
Linux version 5.3.0-1008-gcp (buildd@lgw01-amd64-038) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #9-Ubuntu SMP Mon Nov 11 09:52:23 UTC 2019

手作りのカーネルを搭載したUbuntu19.10：

$ uname -v
#36 SMP Wed Feb 26 20:55:52 UTC 2020
$ uname -r
5.3.10
$ cat /proc/version
Linux version 5.3.10 (austin@austin-dev-ubuntu) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #36 SMP Wed Feb 26 20:55:52 UTC 2020

CentOS 7.7：

$ uname -v
#1 SMP Fri Dec 6 15:49:49 UTC 2019
$ uname -r
3.10.0-1062.9.1.el7.x86_64
$ cat /proc/version
Linux version 3.10.0-1062.9.1.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Fri Dec 6 15:49:49 UTC 2019

@aclements投稿したカーネルのうち、回避策が必要なものと、すでにパッチが適用されているものについて、少し混乱しています。 多分あなたはあなたの投稿に注釈を付けることができます。

問題は、潜在的に悪いバージョン範囲内にいる場合は_影響を受ける可能性があります_、バージョン範囲外にある場合は安全であるということです。
最初の破損が見つかったとき、すぐにパッチをプルしてテストし、ロールアウトしました。 したがって、カーネルは100％悪い範囲内にありましたが、パッチが適用されていました。 範囲外にいるということは安全であることを意味しますが、範囲内にいると、バグをテストせずにバグが存在することを証明することはできません。 （言い換えると、誤検知は設計上発生します）

私は今、アップストリームのバージョン番号で別のパッチを当てたubuntuカーネルを構築しています

• make kernelversion
• このバージョンでdebian{,.master}/{changelog,control}パッチを当てる

カーネルバージョンに依存するソフトウェアが、ディストリビューションが安定性を維持したい理由です。バージョン番号を更新すると、以前に機能していたソフトウェアが破損する可能性がある場合は、バージョンを変更しない方がよいでしょう（ただし、パッチを適用してください）。

golang 1.14のせいで新しいカーネルをロールするのは不幸ですが、うまくいくと思います。
制御された環境の外にgolang1.14バイナリを出荷することをすべての人に思いとどまらせます。

@rtrefferの投稿も、誤

すべての誤検知を回避するためにオプトインする必要があると思います。 たとえば、GOWORKAROUNDS env var booleanを追加するか、回避策のリストを追加するか、ヒューリスティックがそれらを見つけられるようにします。

これは、最も邪魔にならないソリューションIMOになります。

@ fcuello-fudo問題は、悪いカーネルで回避策が有効になっていない場合、症状が非常にわかりにくいことです。

Linuxカーネルの「汚染された」概念を再利用するのはどうですか？ Goランタイムは、不良カーネルを検出し続け、mlockの回避策を適用しますが、mlockが失敗した場合（クラッシュしない場合）、自身が汚染されているとマークします。 次に、汚染フラグが設定されている場合は、パニックにメモを追加し、メッセージをスローするようにしてください。

利点は、誤検知によるクラッシュが回避されると同時に、不良カーネルがクラッシュを引き起こした場合に備えて明確な指標を提供することです。

欠点は、悪いカーネルがメモリをサイレントに破壊し、目に見えるクラッシュを引き起こさない可能性があることです。

@ fcuello-fudo問題は、悪いカーネルで回避策が有効になっていない場合、症状が非常にわかりにくいことです。

また、デフォルトで有効のままにしておきますが、ユーザーが必要な場合は回避策を無効にすると便利ですか？

@howardjohn （GoogleのIstioのプライマリ開発者） https://github.com/istio/istio/issues/21672 ：

パーソナルマシンのカーネルにパッチが適用されていません。 しかし、私のマシンが何を持っているかは実際には問題ではありません。Istioを数千人のユーザーに出荷しています。 私は彼らがそれを実行するマシンを制御することができません、そして私はそれをカーネルバージョンのいくつかのサブセットに制限する必要がないことを望みます

Prometheusプロジェクトもgo1.14のアップグレードを控えています： https ：

セルフホストのKubernetesクラスターでgoアプリケーションを実行しているときに、この問題が発生しました。 関連するulimitを増やすことで、_mlock_回避策を有効にすることができました。 ただし、Kubernetesで実行されているDockerコンテナのulimitを変更するプロセスを見つけるのは簡単ではないため、他の誰かがここに詳細を入力すると役立つ場合があります。

1. /etc/security/limits.confを更新して、次のようなものを含めます

* - memlock unlimited

1. /etc/docker/daemon.jsonを更新して含める

"default-ulimits": { "memlock": { "name": "memlock", "hard": -1, "soft": -1 } }

1. docker / kubernetesを再起動し、ポッドを元に戻します。

2. 実行中のコンテナーを入力し、ulimitが増加していることを確認します。

$ kubectl exec -it pod-name -- /bin/sh
/ # ulimit -l
unlimited

_unlimited_ハンマーよりも微妙なものを使用することで逃げることができるかもしれません。 私にとっては、128KiB（131072）の制限が機能しているように見えました。

また、 https：//github.com/RTradeLtd/Temporal on go 1.14のDockerイメージを構築しようとすると、この問題が発生し

そして、山は山積みを続けます。 ほら、これが私がこのスレッドの始めに腹を立てた理由です（これは私の側からの悪い間違いでした、私は同意します）。 これがブロッカーであることを説明し、再現するために多くの努力をしましたが、リリースを妨げないようにシャットダウンされました。 Dockerの問題ではないことが明らかになった後でも。

さまざまなプロジェクトがGo1.14をブラックリストに登録しているため、現在、私たちははるかに悪い状況にあります。 このバグは現在、Go1.15でのみ修正される予定です。 上記の関連する問題に基づいて、これを8か月延期することをお勧めしますか？ messupを認めて、パッチリリースで修正してみてください。さらにプロジェクトが噛まれるのを待つのではなく、いいと思います。

はい、私は自分で修正するのではなく、ここで人々をしつこくしているだけだと知っています。 申し訳ありませんが、これ以上意味のある貢献をすることはできません。エコシステムを断片化したくないだけです。 Goモジュールは、すでに多くのプロジェクトに打撃を与えました。ツールが認識しなければならないさらに別の癖で倍増しないようにしましょう。

Ian Lance-Taylorは、修正があればバックポートされると述べています： https ：

@lmbああ、それは聞いてとてもうれしいです、リンクをありがとう。

参考：Ubuntu 20.04は、来月末から5.4.0を出荷する可能性があります。
最新のUbuntuLTSとgolangは、そのままでは機能しません。

ローレンツバウアー[email protected] schrieb神父、6 MARZ 2020、午前12時42午前：

Ian Lance-Taylorは、修正が行われると修正がバックポートされると述べています
1つ： https ：

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/37436?email_source=notifications&email_token=AAAO66R6S5VOWQBKETLI5UDRGDORJA5CNFSM4K3GBRRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAAO66SH6J4M75WDJ5GO7HTRGDORJANCNFSM4K3GBRRA
。

@karalabeは、私が集めることができる限り強力な言葉で、あなたは「リリースを妨げないようにシャットダウン」されていませんでした。 最初に問題を解決したJoshは、GoogleのGoチームに所属していません（つまり、意思決定者でもありません）。私たちは当初、Dockerプロジェクトがビルドの問題を軽減できる（そして軽減すべきである）と想定していました。 彼らができないことが明らかになったとき、私はすぐにgolang-devでこれを上げました。

さらに、問題の原因はDockerモジュールではなく、ホストカーネルにあることに最初に気づきました。 私がそれを指摘するまで、あなたはあなたがUbuntuにいるとは言いませんでした。

そのメモの後、あなたは私たちにさらに別の謝罪を負っていると思います。

編集：また、ページを読みにくくしたりナビゲートしたりするのが難しくなるため、レポートからゴルーチンスタックトレース（ goroutine x [runnable]始まる）を削除するように依頼しました。 [更新：Russがスタックを編集しました。]

コミュニケーションを成功させるのは難しく、練習する必要のあるスキルであることを誰もが覚えておいてください。 感情は私たちに不利に働き、コミュニケーションを成功させるという私たちの目標を妨げる可能性があります。私はそこにいました。 はい、行動規範の違反があり、それを指摘するのは良いことです。 自発的な謝罪も役に立ちます。 それでは、すべての投稿がコラボレーションとこの問題の解決にプラスの正味の影響を与えることを確認してみましょう。

@rtreffer Ubuntu 20.04で計画されているカーネルバージョンにパッチが含まれるかどうか知っていますか？ Ubuntuの5.3.0カーネル（https://kernel.ubuntu.com/git/ubuntu/ubuntu-eoan.git/commit/?id=59e7e6398a9d6d91cd01bc364f9491dc1bf2a426）にチェリーピックされたようです。 5.4.0カーネルにもあると思いますが、確かにいいと思います。 ありがとう。

@rtreffer Ubuntu 20.04で計画されているカーネルバージョンにパッチが含まれるかどうか知っていますか？ Ubuntuの5.3.0カーネル（https://kernel.ubuntu.com/git/ubuntu/ubuntu-eoan.git/commit/?id=59e7e6398a9d6d91cd01bc364f9491dc1bf2a426）にチェリーピックされたようです。 5.4.0カーネルにもあると思いますが、確かにいいと思います。 ありがとう。

20.04のリリースカーネルに含まれます。はい：

(master)mwhudson<strong i="9">@anduril</strong>:~/src/upstream/linux-2.6$ git log -1 --oneline ad9325e9870914b18b14857c154a0fee0bd77287
ad9325e98709 x86/fpu: Don't cache access to fpu_fpregs_owner_ctx
(master)mwhudson<strong i="10">@anduril</strong>:~/src/upstream/linux-2.6$ git tag --contains ad9325e9870914b18b14857c154a0fee0bd77287
Ubuntu-5.4-5.4.0-10.13
Ubuntu-5.4-5.4.0-11.14
Ubuntu-5.4-5.4.0-12.15
Ubuntu-5.4-5.4.0-13.16
Ubuntu-5.4-5.4.0-14.17
Ubuntu-5.4.0-15.18
Ubuntu-5.4.0-16.19
Ubuntu-5.4.0-17.20
Ubuntu-5.4.0-17.21
Ubuntu-5.4.0-8.11
Ubuntu-5.4.0-9.12
Ubuntu-raspi2-5.4-5.4.0-1002.2
Ubuntu-raspi2-5.4.0-1003.3
Ubuntu-raspi2-5.4.0-1004.4

@ aclements 、 @ dr2chase 、 @ randall77などとの話し合いに基づいて、1.14.1リリースの計画は次のとおりです。

• 問題を説明するwikiページを書く
• バグがある可能性のあるカーネルバージョンでmlockを引き続き使用する
• mlockが失敗した場合は、その事実を黙ってメモし、実行を続けます
• 予期しないSIGSEGVまたはSIGBUSが表示され、 mlock失敗した場合は、クラッシュスタックトレースポイントでwikiページのユーザーが

問題がカーネルなのかプログラムなのか、Go自体のバグなのかを判断するのに役立つ情報を、バグのある可能性のあるカーネルの人々に案内しながら、通常の場合に正しく実行するという良い組み合わせを提供することが期待されます。

これは、 uname versionフィールドに基づいて特定のカーネルにパッチが適用されているかどうかを識別するためのより良い試みと組み合わせることもできます（現在、 releaseフィールドのみをチェックしています）。

もう1つ話し合ったのは、mlockが失敗し、自分自身にシグナルを送信しようとしている場合は、最初にシグナルスタックにタッチすることです。

素晴らしいアイデアのように聞こえる@ianlancetaylor ！

まだ検討していない場合：エラーメッセージからそのWikiページにリンクします（間接参照がもう1つある可能性があります）

たとえば、iPXEはhttp://ipxe.org/1d0c6539のようなリンクを介してそれを行います（それらの出力はブートROM、限られた不動産などに最適化されています）

• 問題を説明するwikiページを書く

• バグがある可能性のあるカーネルバージョンでmlockを引き続き使用する

• mlockが失敗した場合は、その事実を黙ってメモし、実行を続けます

非同期プリエンプションも無効にしたほうがいいのではないでしょうか。 asyncpreemptoff = 1でも問題が発生する可能性があるのは事実ですが、バグは非常にまれであり、それがないと何ヶ月も誰も気付きませんでした。

（Goランタイムの外で）カーネルにパッチが適用されているかどうかをテストする方法はありますか？ ディストロの外で独自のカーネルを維持しているため、これも機能します。

@gopherbotはgo1.14にバックポートしてください。 これは回避策のない深刻な問題です。

開かれたバックポートの問題：＃37807（1.14の場合）。

https://golang.org/wiki/MinorReleasesによると、パッチがマスターに送信されたらすぐに、チェリーピックCLを作成することを忘れないで

@nemithここにChttps ：

@ randall77 @aarzilli検討の結果、シグナルスタックページにmlockを使用することは、常に機能するはずの信頼できる緩和策であるため、試してみるのが妥当です。 プリエンプション信号を送信する前に信号スタックに触れたり、信号プリエンプションを完全に無効にしたりすることは、信頼できる緩和策ではありません。 信頼できない緩和策に頼るべきではないと思います。 カーネルをアップグレードするようにユーザーに指示する必要があります。

カーネルをアップグレードできない人は、 GODEBUG=asyncpreemptoff=1で実行するオプションがあります。これは、他の2つと同じくらい効果的な部分的な軽減になります。

信頼できない緩和策に頼るべきではないと思います。 カーネルをアップグレードするようにユーザーに指示する必要があります。

バグが常にクラッシュで現れた場合、私はあなたに同意します。 しかし、そうではありません-それは単にランダムにメモリを破壊します。 クラッシュするかもしれませんが、プログラムのデータがランダムに破損して実行を続ける可能性があります。 たとえそれが必要なカーネルのアップグレードについて頻繁にメッセージを送らないことを意味するとしても、データの破損を防ぐためにできる限りの対策を講じることは私たちの義務だと思います。

これは、現在と後の決定です。 使用する前に信号ページに触れることで、データの破損を防ぐことができます。 または、クラッシュが発生した場合にユーザーにメッセージを送信することで、後で破損を防ぐことができます。 両方を選択することはできません。

mlockの失敗を検出したときに、クラッシュすることなくメッセージを送信し、ページに触れることで軽減できる方法があればいいのにと思います。 残念ながら、Goプログラムではstdout / stderrでそれを実行できるとは思いません。 たぶん、syslogに何かを投げることができますか？ それはおそらく多くはないsyslogを一瞥する人だけを助けるでしょう。

フェアポイント。

インストール時にメッセージを投稿してみませんか？ これには、バイナリリリースとディストリビューションのインストール手順の変更が伴いますが、それにより、再現機能を実行してバグを確実にテストできます。

@networkimprovそれは良い考えですが、カーネルのバージョンが異なる可能性のあるマシン間でコンパイル済みプログラムを送信する人がいるため、上記のアプローチも必要だと思います。

https://golang.org/wiki/LinuxKernelSignalVectorBugでwikiページを作成しました

変更https://golang.org/cl/223121はこの問題に言及しています： runtime: don't crash on mlock failure

https://golang.org/cl/223121を送信しました

ええと、 @ randall77 / @ianlancetaylor 、私はこれがgolangの問題であることにまったく同意しない傾向があります。 Golangはメモリ破損の問題を発見しましたが、これは非常に深刻なカーネルのバグです。

そのため、カーネルパスを介してエスカレーションする必要があります。
ディストリビューションはパッチを受け取り、出荷しました。 バックポートされました。 新しいインストールはすべて、影響を受けないカーネルを取得します。
独自のカーネルをロールする場合は、それを自分で行う必要があります。 いつものように。

ヒットしたユーザーに役立つようにし、可能な限り役立つようにします。
しかし、カーネルのバグを修正したり、ユーザーにパッチの適用を強制したりすることは、golangの責任ではないと思います。

@rtrefferそれが私たちがやろうとしていることです：可能な限り役立つようにしてください。

バグのあるカーネルでは、Go 1.14でビルドされたGoプログラムは、予期せず、ひどく動作しました。 バグのあるカーネルでもそうすることはしたくありません。 プログラムが迅速かつクリーンに失敗する場合、それは1つのことです。 しかし、私たちが見たのは、あいまいなエラーにつながるメモリの破損でした。 とりわけ、＃35326を参照してください。

私たちが今していることとは違う行動を取るべきだと思いますか？

@rtrefferまあまあ。 gcc9でコンパイルされていないため、影響を受けない本番5.2カーネルがいくつかあります。また、他に影響を与えることなく、修正をカーネルラインに簡単にパッチして、問題なく実行できます。 カーネルのバグは私たちの環境には存在せず、メジャーバージョンをアップグレードするには、より多くのテストとフリート全体への慎重な展開が必要になるため、「カーネルをアップグレードする」だけでは適切な状況ではありません。

反対に、カーネルのバージョン番号に基づく回避策により、ulimitの問題が原因でDIDが失敗するmlockに移行しました。 これはカーネルのバグではありません。

そうは言っても、ここにもっと良い解決策があるかどうかはわかりませんし、Goチームはおそらく正しい電話をかけました。

@ianlancetaylorは、Cカーネルを精査する方法としてwikiページでそれを参照できるかもしれません。

インストール時にメッセージを投稿してみませんか？ これには、バイナリリリースとディストリビューションのインストール手順の変更が伴いますが、それにより、再現機能を実行してバグを確実にテストできます。

これを行うのに十分な注意を払っているディストリビューションは、代わりにカーネルにパッチを適用するだけです。

@ianlancetaylor私は

そもそもgolangsの障害やバグではなく、ディストリビューションが固定カーネルを出荷していることを強調したいと思います。 すでに消えていくはずです。

結果として、提案されたヒント（wiki +パニック）以上のものは必要ないと思います。

@rtrefferすばらしい、ありがとう。

変更https://golang.org/cl/223417はこの問題に言及しています： [release-branch.go1.14]runtime: don't crash on mlock failure

明確にするために、ウィキの内容に基づいて、1.14.1でmlockが失敗した場合、それはプログラムがメモリの破損に対して脆弱であることを意味しますか？

ありがとう

@ smasher164必ずしも限りません。 mlock呼び出しが失敗したときに、「mlockfails」メッセージを出力しなくなりました。 代わりに、失敗したという事実を保存します。 プログラムがクラッシュした場合、エラーテキストにmlockが失敗したという事実が出力されます。 これは、「カーネルにバグがある可能性があると考えています。mlockの回避策を試しましたが、失敗しました。とにかくプログラムを実行したところ、クラッシュしてしまいました。」 カーネルのバグが原因かもしれませんし、プログラムのバグかもしれません。

@ randall77ご返信いただきありがとうございます。 それで、プリエンプション信号を送信する前にスタックに触れたときにmlockが失敗し、プログラムがクラッシュしない場合、非同期プリエンプション関連のメモリ破損はプログラムに存在しないと言っても差し支えありませんか？

残念ながら違います。 mlockが失敗し、カーネルにバグがある場合は、メモリの破損が発生している可能性があります。 プログラムがクラッシュしていないからといって、どこかに破損がなかったわけではありません。 クラッシュはメモリ破損の副作用です。mlockが失敗しただけではクラッシュは発生しません。 （これは1.14で行っていました。これは、1.14.1で変更したことの1つです。）
非同期プリエンプションをオフにしても、メモリの破損が発生している可能性があります。 あなたのプログラムはおそらくまだ他の信号（タイマーなど）を受け取っているので、ちょうど低いレートで。

@ smasher164wikiページhttps://golang.org/wiki/LinuxKernelSignalVectorBugが不明な場合はお知らせください。 ありがとう。

どうすればこれをオプトアウトできますか？

私はlxdによって作成された非特権のlxcコンテナー内にいるので、ホストと同じカーネルを持っていますが、システム全体の制限を設定できません。

# container
$ uname -a
Linux runner-33-project-447-concurrent-0-job-25150 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ /proc/version_signature
/proc/version_signature: Permission denied
$ ulimit -l 123456
ulimit: max locked memory: cannot modify limit: Operation not permitted

# host
$ uname -a
Linux gitlab-ci-runner-lxd-2 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ cat /proc/version_signature 
Ubuntu 5.4.0-31.35-generic 5.4.34

https://github.com/golang/go/issues/37436#issuecomment -595836976によると、ホスト（フォーカル）にはカーネルパッチが含まれています。

Goは、数日前にgo get golang.org/dl/go1.14とgo1.14 downloadを使用して構築されました

$ go version
go version go1.14 linux/amd64

繰り返しますが、どうすればこれをオプトアウトできますか？

他のプログラム/パイプラインが影響を受け、システム全体のオプションを変更する前に、これらすべての可能性について集合的なコンセンサスを作成する必要があるため、システム全体の制限を変更することはできない/したくないかもしれません。

このような検出ができたのは壊れています。 わかっている場合、カーネルには修正されたパッチがあり、検出は誤検知の傾向があります。

@dionysiusこれは、 https： //github.com/golang/go/issues/37436#issuecomment -597360484で説明されているように、1.14.1で修正されました。 新しいバージョンのgoにアップグレードする必要があると思います： https ：

次に、goバージョンを明示的にロードしてみますgo get golang.org/dl/go1.14が最新の1.14をロードすることを期待していました。 報告します。

編集、1.14.3は今日の時点で最新の1.14のようです

更新： go get golang.org/dl/go1.14.3で見栄えが良く、最新のものをロードしていないパッチがなければ、知っておくと予想外です（そうでなければ、この問題に遭遇することはありませんでした）

注意点-Go1.15がリリースされようとしており、ベータ版はすでにリリースされていますが、一時的なパッチはまだ削除されていません（Go1.15で削除するtodoコメントがあります）。

Ubuntu 20.04 LTSはパッチが適用された5.4.0カーネルを使用しているため、回避策を削除することが重要だと思います。 これは、Ubuntu 20.04のすべてのユーザーが依然として不必要にページをmlockすることを意味し、Dockerコンテナーで実行している場合、カーネルが実際にはバグがないという事実を無視して、クラッシュのたびに警告が表示されます。 したがって、これらのユーザーは、このすべての情報を理解して読み込もうとする大げさな追跡に送られる可能性があり、おそらくUbuntu 20.04のライフサイクル全体にわたって、バグとは何の関係もありません。

@DanielShaulovありがとう。 そのための新しい問題を開くことができますか？ これは1.14の問題に関係しています。

@networkimprov sure：＃40184

変更https://golang.org/cl/243658はこの問題に言及しています： runtime: let GODEBUG=mlock=0 disable mlock calls

変更https://golang.org/cl/244059はこの問題に言及しています： runtime: don't mlock on Ubuntu 5.4 systems

この変更でgo1.14.7がリリースされるのは

この修正は、数か月前に出荷された1.14.1以降のすべてのリリースに含まれています。

変更https://golang.org/cl/246200はこの問題に言及しています： runtime: revert signal stack mlocking