「Linux」、バージョン6.1でRustを導入へ--トーバルズ氏が明言
LinuxにRustを導入するかどうかという議論は終わりを迎えた。Rustの実装は既に始まっている。Linuxの父であるLinus Torvalds氏は電子メールによる筆者との対話の中で「何かおかしなことが発生しない限り、それ（Rust）は6.1で導入される」と述べた。 Linuxカーネルの記述言語としてプログラミング言語Rustを導入するという議論は、かなり前から存在していた。Linuxカーネルの開発者らは、年次カンファレンス「Linux Plumbers Conference（LPC）2020」の場で、Linuxの新たなインラインコードでのRustの使用について検討を開始していた。また、「Android」（それ自体がLinuxのディストリビューションだ）の開発言語としてRustを支持しているGoogleは、2021年4月にLinuxカーネルへのRust導入の動きを後押しし始めていた。
20分で分かるDirty Pipe（CVE-2022-0847） - knqyf263's blog
極限まで詳細を省けば何とか20分で雰囲気だけでも伝えられるんじゃないかと思って書きました。書き終えてから見返したら多分無理なので誇大広告となったことを深くお詫び申し上げます。 背景 概要 脆弱性の影響 ページキャッシュやsplice パイプ マージの可否 下準備 攻撃手順 まとめ 背景 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com Linuxのパイプに関する脆弱性なのですが、仕組みは意外とシンプルでぎりぎりブログでも伝わるかもしれないと思ったので自分の理解を書きました。あといつも細かく書きすぎて長くなるので、今回は雰囲気だけでも伝わるようにとにかく説明を簡略化し、ふわっとした概要だけでも理解してもらえるように頑張りました。その結果、若干正確性に欠ける部分があるかもしれませんがお許しください。細かい部分はまた別の記事でま
［速報］Windows上でフル互換のLinuxシステムコールを実現する「WSL 2」発表、Dockerも実行可能に。Microsoft Build 2019
マイクロソフトはWindows上でLinux互換機能を提供するWindows Subsystem for Linux（WSL）の次期版となる「WSL 2」を発表しました。 WSL 2には、最初からWSL 2に最適化されたLinuxカーネルが含まれており、フル互換のLinuxシステムコールを実現。またファイルシステム性能は最大20倍もの劇的な向上も実現しているとのことです。 これによりWSL 2上ではDockerも実行可能だとされています。「Announcing WSL 2」から引用します。 Now that WSL 2 includes its own Linux kernel it has full system call compatibility. This introduces a whole new set of apps that you can run inside of W
ファイルシステムサイズの拡張時にデータベースアクセスがスローダウンする問題の解決 - Cybozu Inside Out | サイボウズエンジニアのブログ
はじめに こんにちは、技術顧問のsatです。 サイボウズでは、ファイルシステムサイズ拡張時にデータベースアクセスがスローダウンするという問題に長年悩まされてきました。本記事では運用本部の藤田と深谷がこの問題を解決した流れについて報告いたします。問題を解決するために2人はLinuxカーネルを修正しました。修正は社内に閉じたものではなく、執筆当時の最新 Linuxカーネルであるv4.17にマージされています。 問題 以下の操作の後にデータベースへのアクセスが一時的にスローダウンする ブロックデバイスのサイズを拡張する 上記デバイス上にあるファイルシステムのサイズを拡張する 原因 linuxカーネルはブロックデバイスのサイズ変更(縮小および拡張)時に、当該デバイス上にあるファイルシステムのページキャッシュ(後述)を無効化する*1 解決方法 ブロックデバイスのサイズ拡張時にはページキャッシュを無効
【お知らせ】メモリ枯渇時の挙動の安定性が改善された Linux カーネル 4.15 が公開されました | NTTデータ先端技術株式会社
Tweet お知らせ - 2018.02.22 Linux カーネルはメモリが枯渇した際の挙動を十分に考慮しておらず、メモリの枯渇が原因でLinux システムがハングアップしてしまうことがあるという問題があります。 この問題に当社ソリューション事業部 半田 哲夫が4年半取り組み続けた結果、メモリの枯渇時にハングアップしてしまう処理の多くが修正されました。現時点までの道のりは、以下の資料／動画でご覧いただけます。 資料：https://elinux.org/images/7/73/CELFJP-Jamboree63-handa-ja.pdf（社外サイト） 動画：https://youtu.be/ZznEyf1PN0Q（社外サイト）
net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita
Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード／ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう（というかできません）。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ
Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign
Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign Final update A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug. Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce
TIME_WAITに関する話
3. 自己紹介 - まぁまぁ MySQL でご飯食べてます - 一時期は Resource Monitoring や KVS にも 力入れてました - ネットワーク的には素人です - Linuxとハードウェアは嗜む程度 - disk I/O にはむかしから興味あります - その他 slideshare はこちら - http://www.slideshare.net/takanorisejima/ 4. 本日のお題 - kernel 新しくしたりすると、TCP的に意識したほ うが良い変化が見つかるので - 今日は、Webアプリケーションサーバの観点か ら、 connect(2) する際に気になる TIME_WAIT について、書いてみようかと思います - 有識者からのマサカリを、強く歓迎いたします 5. 最初に参考資料 - この二つの記事を読んでいただけば、それで概 ね良いと思うんですが
OSカーネルを0から作り始めてみた - Qiita
1. 概要 OSカーネル[^1]をフルスクラッチで（0から）作り始めてみました。 本稿では下記について記載します。 カーネルを自作し始めた背景 カーネル自作における方針 本稿執筆時カーネルの機能概要 カーネルの実行方法 プロセスを起動してみる 今後の課題 2. 背景 私がカーネルを自作し始めた理由は次の2点です。 1.コンピュータがどの様に動いてるのか知りたかった 2.使用しているOSに不満があった 2.1 コンピュータがどの様に動いてるのか知りたかった かれこれ10年以上前に遡りますが、私が大学に入学した頃、VisualBasicやBasic、Cなどの言語を使って簡単なソフトウェアを作ることが出来ましたが、どうして簡単なコードでウィンドウが表示できるのか、どうしてprintf文を書けばコンソールに文字が出力できるのか、コンピュータはいったいどんな風に動いてるのか全く分からず、不思議で仕方
Linux シグナルの基礎
TLPI (The Linux Programming Interface) 再々。 TLPI の輪読の際に @matsumotory よりシグナルセットあたりをまとめるようにと指令が出たので、拙遅な感じでまとめました。 シグナルとは プロセス間通信の一種。「プロセスにシグナルを送信すると、そのプロセスの正常処理に割り込んで、シグナル固有の処理(シグナルハンドラ) が実行される」プロセス側では、シグナルを受信した際の動作(シグナルハンドラ) を設定することや、シグナルをブロックすることも可能。 コンソールで、プロセスを終了させるためにkill -9 <PID>とかCtrl+Cとかした際にも、対象プロセスにシグナルが送信されている。 ちなみに、PID「1」の init や systemd にkill -9 1しても何も起らない。(そういえば昔、oom-killer に init を殺された覚
OOM Killerにであったら何をするべきか?
OOM killerで大事なプロセスが殺される。困りますね。。 google で OOM Killerと入力すると 「無効」とか補完されます。しかしどうするのが良いのか、あまりよく説明されている記事がみあたらなかったので自分の考えをメモしておきます。 OOM Killer の目的は何か? まずは何故OOM Killerが発生しているのかについて、ざっくりイメージをつかみましょう。linux kernelはプロセスからの「メモリくれ」という要求に対してたぶん足りそうだという場合に「OK」といって渡します。実際のメモリ割り当てはアクセスが発生するタイミングまで遅延させます。これを遅延アロケーションといい、だいたいにおいてうまく動きます。ただし必ずうまくいくと保証されているわけではないので破綻することがあります。 OOM Killerはこの遅延アロケーションが破綻しそうなときに、適当にプロセスを
Linux Insides : カーネル起動プロセス part2 | POSTD
カーネルセットアップの第一歩 前回の パート では、Linuxカーネルの内部について探り始め、カーネルをセットアップするコードの最初の部分を見ていきました。前回の投稿は arch/x86/boot/main.c 内の main 関数（C言語で書かれた最初の関数）を呼び出すところまで確認しました。 このパートでは、引き続きカーネルのセットアップコードについて調査し、併せて以下の内容も学びます。 protected mode （プロテクトモード）の概要 * プロテクトモードに移行するための準備 ヒープとコンソールの初期化 メモリの検出、CPUの検証、キーボードの初期化 その他もろもろ それでは始めていきましょう。 プロテクトモード ネイティブのIntel64の ロングモード に移行する前に、カーネルはCPUをプロテクトモードに切り替える必要があります。 では、この プロテクトモード とは何でし
Linux のページ回収まわりのカーネルパラメータ - ablog
Linux(kernel 2.6.32-303 以降)のDBサーバでメモリ16GB、スワップ領域16GBの場合、ざっくりこんな感じが良いかなという妄想メモ。 vm.swapiness=1 vm.overcommit_memory=2 vm.overcommit_ratio=80 vm.min_free_kbytes=524288 vm.extra_free_kbytes=1048576(kernel 3.5以降) vm.swappiness=1 でページアウトよりページキャッシュ解放を優先させる。kernel 2.6.32-303 以降、0 にすると OOM Killer が発動しやすくなるらしいので、1 にする。 vm.overcommit_memory=2 でオーバーコミットしないようにして、OOM Killer が発動しにくくする vm.overcommit_ratio=80 で仮想
Linus Torvals、クソコードにブチギレ
Linux-Kernel Archive: Re: [GIT] Networking Linus TorvalsがGCCの独自拡張を使った整数演算のオーバーフロー検知コードがあまりにクソすぎるためにブチギレしている。 On Wed, Oct 28, 2015 at 3:32 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: リリースサイクルのこの後半に入れるのはちょっと怖いと思われるかもしれないが、小規模なドライバーの修正をあちこちに施しただけだよ。 マジかよテメーら、こりゃクソだ。 コンフリクトはGCCの新しいクソヘッダーファイルのせいなんだが、俺がブチギレてるのはそこじゃなくてこいつがクソなせいだ。 net/ipv6/ip6_output.cの以前のコードはこれだ。 mtu -= hlen + sizeof(struct frag_hdr);
革命の日々！ Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？ の件について
なんかスラドにあげられてしまったので、備忘録てきにちょっとまとめますかね。 きっかけは先月帰国したときに sonots がDeNAをはじめとして、Web企業では広く TCP_TIMEWAIT_LEN を変更してカーネルをリコンパイルして使っているという話を聞いたというもの。以下の様な議論を twitterで行い Togetter: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？: http://togetter.com/li/871768 以下のように、スラドに転載されてしまったわけだ。 スラド： Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？： http://linux.srad.jp/story/15/09/09/0648258/ いつものように、スラド民は元のスレッドなんかまるで読んでいないので、結論だけ書く。 tcp_tw_inter
Linux のページテーブルのサイズの見方と見積式 - ablog
Linux Kernel 2.6 (x86-64) でのページテーブルのサイズの確認方法と見積式を調べてみた。 あっているか自信のないところもある＆まだ書きかけ。 ページテーブルのサイズの見方 OS全体のページテーブルのサイズ $ cat /proc/meminfo MemTotal: 16158544 kB MemFree: 13134056 kB (中略) PageTables: 34428 kB ★ 34MB プロセス毎のページテーブルのサイズ $ cat /proc/10225/status # 10255 は PID Name: zsh State: S (sleeping) Tgid: 10225 Pid: 10225 PPid: 10222 (中略) VmPTE: 124 kB ★ 124KB ページテーブルのサイズの見積式 見積式 (プロセスが使用している物理メモリサイズ
Helpful Linux I/O stack diagram
During one of my regular trips to reddit, I stumbled upon an amazingly helpful Linux I/O stack diagram: It’s quite comprehensive and it can really help if you’re digging through a bottleneck and you’re not quite sure where to look. The original diagram is available in multiple formats from Thomas Krenn’s website. If you combine that with this slide from Brendan Gregg’s Linux Performance Analysis a
Etsukata blog: FreakOut DSP 入札サーバの CPU 使用率を 30% 削減する Performance Tuning
はじめに 勤務先の FreakOut 社では RTB で広告枠を買い付ける DSP の開発・運用を行っています。RTB とは、インターネット広告のインプレッションが生じる毎に、広告枠の競争入札を行う仕組みです。 DSP とは、 RTB において、競争入札をする側のシステムになります。広告枠/広告を見ている人 に対し、最適な広告を、最適なタイミングで届ける機能を広告主に提供する仕組みです。 FreakOut DSP は最適な広告探索・入札価格調整のため、非常に多くのデータを参照し、沢山の演算処理を行います。広告を見ている人が過去にアクセスした Web ページの情報や検索ワード、さらに 広告がクリックされる予測確率(過去のログから機械学習で算出) などを参照し、入札価格を決定するのです。そのため、DSP で入札を担当するサーバは CPU がボトルネックになっており、台数も数百台に嵩んでいます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.makelinux.net/kernel_map/