Linux Kernel の net/ipv4/tcp_input.c は、challenge ACK セグメントの割合を適切に判定しないため、TCP セッションをハイジャックされる脆弱性が存在します。
ブートローダからカーネルまで これまでの私の ブログ投稿 を読まれた方はご存じかと思いますが、しばらく前から低水準言語を使うようになりました。Linux用x8664アセンブリ言語プログラミングについても書いています。また、同時にLinuxのソースコードにも触れるようになりました。下層がどのように機能しているのか、コンピュータでプログラムがどのように実行されるのか、どのようにメモリに配置されるのか、カーネルがどのように処理や記憶をするのか、下層でネットワークスタックがどのように動くのかなどなど、多くのことを理解しようと意欲が湧いています。これをきっかけに、 **x8664** 版Linuxカーネルについてシリーズを書いてみようと思いました。 私はプロのカーネルプログラマではないことと、仕事でもカーネルのコードを書いていないことをご了承ください。個人的な趣味です。私は下層で何が起きているのかと
こんにちわ。せじまです。今年に入ってからアクティビティトラッカーを二回壊しまして、新しい分野の製品って設計いろいろ難しいんだなと、しみじみ思う今日このごろです。 先日、社内勉強会で Ethernet や CPU などの話をしました。前回のCPUに関する話に続き、今回のスライドも幅広い方に読んでいただけそうな内容かと思いましたので、公開させていただくことにしました。前回のスライドを読んでない方は、できればそちらを読んでいただいてからの方が、より理解が深まるのではないかと思います。 忙しい人のために三行でまとめると 2020年代には、サーバのネットワークインターフェースが 40Gbps 超えてそうな予感 もし Ethernet でそれだけ大量のパケットをさばくなら、(標準化されてないけれど) Jumbo Frame 使わないと厳しいかも 2020年代には、NICやブロックデバイス等、CPUを取
Linux OS でキャッシュをクリアする方法 (Kernel 2.6.16〜) 性能の試験をするときにファイルシステムのキャッシュによる影響を排除する。 root もしくはスーパーユーザーコマンドにて行なう。 % su root or sudo # sync # sysctl -w vm.drop_caches=1 # sysctl -w vm.drop_caches=2 # sysctl -w vm.drop_caches=3 or # echo 1 > /proc/sys/vm/drop_caches # echo 2 > /proc/sys/vm/drop_caches # echo 3 > /proc/sys/vm/drop_caches 1 … ページキャッシュのクリア 2 … ディレクトリエントリー(dentry)と inode のクリア 3 … ページキャッシュおよびディレ
Linus Torvalds氏は4月12日、Linuxカーネルの最新版となる「Linuxカーネル4.0」をリリースした。メジャーバージョン番号は4に上がっているが、内容としては「かなり小規模なリリース」としている。これは安定性に主眼を置いたTorvalds氏の方針に沿ったものだという。 2月中旬に公開されたLinuxカーネル3.19に続くリリースとなる。Linuxカーネル3.19の公開後、Torvalds氏はGoogle+にて次期版の名称を「Linux 3.20」とするか、以前構想を明かした通りに「4.0」とするかについてオンライン投票の形で意見を募った。投票では少しの差(56%対44%)で「4.0」が上回っており、その後2月末に初のリリース候補版を「Linux 4.0」として公開した。今回のバージョン番号の変更については「数字が大きくなることを避けること」を目的としており、Torvald
static, benchmarking, tuning: sar, perf-tools, bcc/BPF: bpftrace, BPF book: Images license: creative commons Attribution-ShareAlike 4.0. This page links to various Linux performance material I've created, including the tools maps on the right. These use a large font size to suit slide decks. You can also print them out for your office wall. They show: Linux observability tools, Linux static perfor
LWN.net needs you!Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing The previous article explored the kernel implementation of system calls (syscalls) in its most vanilla form: a normal syscall, on the most common architecture: x86_64. We complete our look at syscalls with variations on that basic theme, covering other
Linuxカーネルに興味があるんだけど特に作りたいものってないんだよなーなんて割とあると思う訳です。俺とか。。。 まあ、kernelnewbiesのメーリングリストでもよく見る話題かと思います。この辺なんかもそうですね。 で、そんな時にオススメできるのがkmemleak。カーネルに組み込まれたメモリーリーク検出ツールです。 使い方は至って簡単でカーネルのコンフィグレーションにあるKernel memory leak detectorを有効にしたカーネルを普通に使えばOK。カーネルはメインラインのrcでもtipでもlinux-nextでも何でも良いと思います。 設定の場所はKernel Hacking -> Memory Debugging -> Kernel memory leak detectorにチェックをするのと、 その下のMaximum kmemleak early log ent
Linux の連続稼働時間が 208.5 日を過ぎた段階で突如 Kernel Panic を引き起こすという過激な挙動で2011年の年の瀬に話題となった "旧208.5日問題" ですが、あれから二年が経った今、Linux Kernel 内の bug と Intel Xeon CPU の bug の合わせ技により再度類似の不具合が発生することが分かっています。 旧 208.5 日問題の発生原理に関しては以下の blog が参考になります。 okkyの銀河制圧奇譚 : sched_clock() overflow after 208.5 days in Linux Kernel 追記(2014/1/4) 新208.5日問題の簡易チェックツールを作成しました。よろしければお使い下さい。 tsc_checker - 新208.5日問題簡易チェックツール また、Linux Kernel における時間
この記事は英語から大ざっぱに翻訳されたものであり、場合によっては不慣れな翻訳者や機械翻訳によって翻訳されたものかもしれません。翻訳を改善してくださる方を募集しています。 SwappinessはLinuxカーネルがスワップ処理を行う頻度を変更するためのパラメータである。 Swappinessには0から100までの値を設定することができる。 低い値を設定するとカーネルは可能な限りスワップを行わないようにし、高い値を設定すると積極的にスワップ領域を利用しようとする。 既定の値は60となっており、たいていのシステムでは100に設定すると全体的なパフォーマンスに悪影響を及ぼし、0を含め低い値に設定すると応答速度が向上する(反応までの遅延が減少する)とされる。[1] 要約すると次のようになる。 値 スワップ頻度
kazeburoさんがCentOS6.2での事例を紹介されていますが、CentOS5系でもkernelを上げればRPS/RFSが使えるようになって、NICの負荷状況が劇的に改善します。 やり方は意外に簡単で、ELRepoからkernel-ml-2.6.35-14.2.el5.elrepo.x86_64.rpmを落としてきてインストール。 あとは、/boot/grub/menu.lstの設定をdefault=0にしてrebootすればOK。 $ uname -r 2.6.35-14.2.el5.elrepo ELRepoはNICのドライバなんかもいろいろ提供してくれるし、古いバージョンのRPMをarchiveで提供してくれて非常にいいですね(kernelの過去RPMはないのかな)。 RPS/RFSを有効にする設定はCentOS6と同様です。 # echo "f" > /sys/class/n
3月18日にLinuxの最新版「Linux 3.3」が公開されました。今回のバージョンではAndroidプロジェクトのコードのマージが大きな特徴の1つですが、ネットワーク関係でも大きな前進がありました。1つはOpen vSwitchがメインラインにマージされ、Linux 3.3から標準サポートとなったこと、そしてネットワークインターフェイスを束ねて帯域幅の拡大を実現する「Teaming」機能が改善されたことです。 LinuxにはすでにLinux bridgeがありますが、Open vSwitchはさらに高度な機能を備えたソフトウェアスイッチとして標準サポートされるとのこと。仮想環境のソフトウェアスイッチとして普及しつつあるOpen vSwitchは、さらにその地位を固めようとしています。 なぜOpen vSwitchがLinuxのメインラインに? ところで、なぜOpen vSwitchがL
えーっと、久しぶりに Linux Kernel にダメダメなバグが発見されて、よりにもよってうちの製品も影響を受けたので、ここに詳細を書くことにした。 つーか。新しい Kernel を使うなら皆で使おうよ。なんだよその「1つだけ」影響を受けて残りは「影響も受けないぐらい古い」ってのは… 概要 大雑把に 208.5日連続運転した Linux Kernel が突如として reboot する。 実機でなおかつ Time Stamp Counter を内包している必要があるので、Pentium4以降のプロセッサ(が、それはようするに今ある Intel 系CPU全部)か、その互換CPUである必要がある。32bit モード、64bit モードの区別はない。 逆に VMware や Xen など、仮想マシン上で動いている kernel に影響はない。これはそもそもバグを内包したルーチンを、仮想マシンで動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く