And that code is actually fairly recent. We _used_ to do this right, and 
the code was

        if (vm_flags & VM_LOCKED) {
                mm->locked_vm += len >> PAGE_SHIFT;
                make_pages_present(addr, addr + len);
        }

and we intentionally did _not_ pass in the vma, but we broke it a couple 
of months ago in commit ba470de43188cdbff795b5da43a1474523c6c2fb ("mmap: 
handle mlocked pages during map, remap, unmap").

Guilty parties added to Cc:

関連記事

• kernel watch １月号 (2009/02/01)
• 犯罪者っすか (2009/01/29)
• Android関係者は本当にクズだな (2009/01/29)

> >> >> static uint32_t lowmem_debug_level = 2;
> >> >> static int lowmem_adj[6] = {
> >> >
> >> > why do you choice [6]?
> >>
> >> We use six levels.
> >
> > if you don't consider other user and other usage case,
> > this file can't merge forever.
>
> I never expected it to be merged. I wrote it to allow us to ship a product.
>
Then, please write "DON'T MERGE ME" on the top of patch description.
we can adjust our viewpoints.

Thx,
-Kame

関連記事

• 犯罪者っすか (2009/01/29)
• Android関係者は本当にクズだな (2009/01/29)
• カーネル開発者からのメッセージ(1)---LWN.net Jonathan Corbet氏 (2009/01/29)

関連記事

• Android関係者は本当にクズだな (2009/01/29)
• カーネル開発者からのメッセージ(1)---LWN.net Jonathan Corbet氏 (2009/01/29)
• LKML名言集 (2009/01/27)

関連記事

• 富士通、HDD用ヘッド事業を3月末に終息 (2009/01/27)
• McAfeeがGPLに対するFUDを行ったという話 (2008/01/09)
• さくらインターネット債務超過の件 (2007/11/28)

As far as I'm concerned, digital cameras have been more useful than kernel dumps to kernel debugging.

関連記事

• カーネル開発者からのメッセージ(1)---LWN.net Jonathan Corbet氏 (2009/01/29)
• LKML名言集 (2009/01/27)
• よっしゃ、kernel watch １月号の校正おわった (2009/01/26)

関連記事

• LKML名言集 (2009/01/27)
• よっしゃ、kernel watch １月号の校正おわった (2009/01/26)
• Fedora11からはmem-cgroupがONになります。 (2009/01/26)

kyle@minerva ~/rpms/kernel/devel $ grep CGROUP config-generic
CONFIG_NET_CLS_CGROUP=y
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_MEM_CONT=y
kyle@minerva ~/rpms/kernel/devel $

関連記事

• よっしゃ、kernel watch １月号の校正おわった (2009/01/26)
• Fedora11からはmem-cgroupがONになります。 (2009/01/26)
• kernel watch 1月号 (2009/01/15)

関連記事

• 連載中止するかも (2009/02/03)
• LinusがKDEからGNOMEに環境変えたらしい (2009/01/26)
• Android マシンで日本で簡単に入手可能なのって何があるの？ (2009/01/16)

関連記事

• OOXMLはRELAX NG に対応しているらしい (2009/01/25)
• LinkedInに招待された (2008/12/22)
• ちょっとまてやゴルァ ＞ XML1.0 5th (2008/12/03)

関連記事

• LinusがKDEからGNOMEに環境変えたらしい (2009/01/26)
• Android マシンで日本で簡単に入手可能なのって何があるの？ (2009/01/16)
• オーストラリア出張申請が難しい情勢らしい (2009/01/15)

関連記事

• Android マシンで日本で簡単に入手可能なのって何があるの？ (2009/01/16)
• オーストラリア出張申請が難しい情勢らしい (2009/01/15)
• 来週の月曜は休みらしい！ (2009/01/09)

関連記事

• Fedora11からはmem-cgroupがONになります。 (2009/01/26)
• kernel watch 1月号 (2009/01/15)
• 2.6.27.11 (2009/01/15)

関連記事

• kernel watch 1月号 (2009/01/15)
• 2.6.27.11 (2009/01/15)
• [告知] 日本セキュアOSユーザ会主催　セキュアOS塾 - 02／02月02日(月) (2009/01/14)

海外です。

表題の件、告知させて頂きます。
複数のメーリングリストに流していますので、何度も読む方はご容赦ください。

昨年10月に引き続き、第２回となるセキュアOS塾を開催する事となりました。
今回は、メインライン化に向けて "熱い" TOMOYO Linux と、非常に長い
歴史を持つ root 特権の話題がテーマです。

参加登録は、下記のURLより『参加登録』のフォームにご記入ください。
http://www.secureos.jp/index.php?events/jsosjk02

※ 懇親会への申し込みを希望される方は、人数確定のため
1月26日(月)までに参加登録をお願いします。

皆様のご参加をお待ちしております。

■開催概要
主催：日本セキュアOSユーザ会
名称：セキュアOS塾-02
案内：http://www.secureos.jp/index.php?events/jsosjk02

日時：2月2日(月) 18:30～20:15

18:15～ 開場
18:30 - 19:15 第１部：TOMOYO LinuxでLinuxの動きを見てみよう
19:15 - 20:00 第２部：Linuxで最小特権を実現する - POSIX Capability
20:00 - 20:15 ライトニングトーク
～22:00 懇親会

場所：港区立 港勤労福祉会館
http://www.3710pic.com/mkf/index.html
都営地下鉄三田線三田駅より、徒歩1分
JR山手線 田町駅より、徒歩3分

■　第１部：TOMOYO LinuxでLinuxの動きを見てみよう
講師：沼口大輔、原田季栄
TOMOYO Linuxは使いこなせるセキュアOSとして開発されました。
セキュアOSというとシステムを攻撃から守るためのものと思われがちです。
しかしTOMOYO Linuxはそれだけではありません。
TOMOYO Linuxでは学習モードというポリシーの自動学習機能を使うことで、
Linux内部の動きを見ることができて、Linux自体の勉強やLinux上で動作する
ソフトウェアの作りこみなどにも活用できます。
今回はTOMOYO Linuxの学習機能の活用方法についてご紹介します。

■　第２部：Linuxで最小特権を実現する - POSIX Capability
講師：海外 浩平
LinuxをはじめUNIX互換OSにおいて、root特権の存在はセキュリティ上の
悪夢でしたが、一方で、多くのプログラムが動作時にroot特権を必要と
する事実も存在します。
Fedora10など最新のディストリビューションでは、POSIX Capabilityと
呼ばれる機能により『root特権の一部だけ』をプログラムに付与する事
が可能となりました。これにより、万が一の脆弱性がシステム全体に波
及するリスクを小さくしています。
今回は、Linuxにおいてroot特権がどのように扱われているのか、POSIX
Capabilityを題材に、基本的な概念と設定方法をご紹介します。

関連記事

• 2.6.27.11 (2009/01/15)
• [告知] 日本セキュアOSユーザ会主催　セキュアOS塾 - 02／02月02日(月) (2009/01/14)
• またやってしまった (2009/01/14)

関連記事

• [告知] 日本セキュアOSユーザ会主催　セキュアOS塾 - 02／02月02日(月) (2009/01/14)
• またやってしまった (2009/01/14)
• spinlockを便器を使ってやさしく解説してみるスレ (2009/01/13)

関連記事

• またやってしまった (2009/01/14)
• spinlockを便器を使ってやさしく解説してみるスレ (2009/01/13)
• seekwatcher (2009/01/13)

関連記事

• spinlockを便器を使ってやさしく解説してみるスレ (2009/01/13)
• seekwatcher (2009/01/13)
• sudo でPATH環境変数の引き継ぎ (2009/01/12)

Shak_0
ふーむ・・・リトルビッグプラネットは、UKじゃあ売れてないのか？

　　　CanaryWundaboy
　　　まあサクっと言っちゃうと、ノーだよ。

　　　GUNJAM
　　　リトルビッグプラネットが売れてる所なんかあるの？

　　　Hellicus
　　　GUNJAMの質問に簡単に答えるなら：No
　　　詳しく答えるなら：Noooooooooooooooooooooo

関連記事

• ベルセルクの今後の展開を書くよ (2009/02/17)
• 詳しく答えるなら (2009/01/13)
• 富山の中学校がネット炎上で119番に通報 (2008/11/16)

alias sudo="sudo env PATH=$PATH"

関連記事

• seekwatcher (2009/01/13)
• sudo でPATH環境変数の引き継ぎ (2009/01/12)
• squashfsがマージされました (2009/01/10)

                               Squashfs                Cramfs

Max filesystem size:            2^64                    256 MiB
Max file size:                  ~ 2 TiB                 16 MiB
Max files:                      unlimited               unlimited
Max directories:                unlimited               unlimited
Max entries per directory:      unlimited               unlimited
Max block size:                 1 MiB                   4 KiB
Metadata compression:           yes                     no
Directory indexes:              yes                     no
Sparse file support:            yes                     no
Tail-end packing (fragments):   yes                     no
Exportable (NFS etc.):          yes                     no
Hard link support:              yes                     no
"." and ".." in readdir:        yes                     no
Real inode numbers:             yes                     no
32-bit uids/gids:               yes                     no
File creation time:             yes                     no
Xattr and ACL support:          no                      no

Merge it!

We've long needed a filesystem named after a vegetable.

関連記事

• sudo でPATH環境変数の引き継ぎ (2009/01/12)
• squashfsがマージされました (2009/01/10)
• btrfsがマージされました (2009/01/10)

関連記事

• squashfsがマージされました (2009/01/10)
• btrfsがマージされました (2009/01/10)
• ext4がいつの間にか結構高速化していた件について (2009/01/08)

関連記事

• オーストラリア出張申請が難しい情勢らしい (2009/01/15)
• 来週の月曜は休みらしい！ (2009/01/09)
• 老舗の英高級陶器「ウェッジウッド」破綻 (2009/01/06)

On Wed, Jan 07, 2009 at 11:29:11AM -0800, Curt Wohlgemuth wrote:
> 
> I ran both iozone and compilebench on the following filesystems, using a
> 2.6.26-based kernel, with most ext4 patches applied.  This is on a x86 based
> 4-core system, with a separate disk for these runs.

Curt, thanks for doing these test runs.  One interesting thing to note
is that even though ext3 was running with barriers disabled, and ext4
was running with barriers enabled, ext4 still showed consistently
better resuls.  (Or was this on an LVM/dm setup where barriers were
getting disabled?)

I took the liberty of reformatting the results so I could look at them
more easily:
   
                                     Iozone, 1 Thread
Average throughput     ext2           ext3            ext4       ext4-nojournal
      Type        Mean    Stddev  Mean   Stddev  Mean    Stddev  Mean    Stddev
 initl_writers: 56.6 MB/s (0.2) 56.3 MB/s (0.2) 65.5 MB/s (0.1) 66.3 MB/s (0.2)
     rewriters: 58.4 MB/s (0.2) 58.2 MB/s (0.1) 65.7 MB/s (0.2) 66.6 MB/s (0.1)
       readers: 66.3 MB/s (0.2) 66.4 MB/s (0.1) 65.8 MB/s (0.2) 66.4 MB/s (0.0)
    re-readers: 66.5 MB/s (0.0) 66.1 MB/s (0.2) 65.6 MB/s (0.3) 66.4 MB/s (0.0)
random_readers: 22.4 MB/s (0.1) 22.1 MB/s (0.1) 21.9 MB/s (0.0) 22.4 MB/s (0.1)
random_writers: 18.8 MB/s (0.0) 18.6 MB/s (0.1) 19.1 MB/s (0.1) 19.4 MB/s (0.2)

                                    Iozone, 8 Threads
Average throughput    ext2           ext3             ext4       ext4-nojournal
      Type        Mean   Stddev   Mean   Stddev   Mean   Stddev   Mean   Stddev
 initl_writers: 28.5 MB/s (0.0) 28.7 MB/s (0.1) 53.7 MB/s (0.2) 56.1 MB/s (0.1)
     rewriters: 43.5 MB/s (0.1) 43.2 MB/s (0.2) 58.3 MB/s (0.1) 60.3 MB/s (0.2)
       readers: 51.5 MB/s (0.1) 51.5 MB/s (0.0) 58.8 MB/s (0.1) 61.0 MB/s (0.0)
    re-readers: 51.8 MB/s (0.2) 51.5 MB/s (0.0) 59.0 MB/s (0.1) 61.0 MB/s (0.0)
random_readers: 20.3 MB/s (0.0) 20.2 MB/s (0.0) 20.2 MB/s (0.0) 20.4 MB/s (0.1)
random_writers: 17.3 MB/s (0.0) 17.3 MB/s (0.0) 18.1 MB/s (0.0) 18.3 MB/s (0.1)

                                     Compilebench
Average values    ext2            ext3              ext4        ext4-nojournal
   Type        Mean   Stddev   Mean   Stddev   Mean    Stddev    Mean    Stddev
init_create: 57.9 MB_s (1.9) 30.6 MB_s (2.2)  59.7 MB_s (0.4)  77.1 MB_s ( 0.2)
 new_create: 13.0 MB_s (0.2) 13.5 MB_s (0.2)  20.5 MB_s (0.0)  22.0 MB_s ( 0.1)
      patch:  7.3 MB_s (0.1) 10.6 MB_s (0.1)  12.5 MB_s (0.0)  13.1 MB_s ( 0.0)
    compile: 25.6 MB_s (0.6) 18.0 MB_s (0.3)  33.9 MB_s (0.2)  36.0 MB_s ( 0.1)
      clean: 70.4 MB_s (1.3) 41.7 MB_s (1.8) 539.5 MB_s (3.6) 592.4 MB_s (39.4)
  read_tree: 22.1 MB_s (0.0) 21.5 MB_s (0.2)  17.1 MB_s (0.1)  17.8 MB_s ( 0.2)
read_compld: 33.3 MB_s (0.2) 20.4 MB_s (1.1)  21.8 MB_s (0.1)  22.1 MB_s ( 0.1)
delete_tree:  6.5 secs (0.2) 13.5 secs (0.3)   2.7 secs (0.1)   2.5 secs ( 0.0)
  stat_tree:  5.2 secs (0.0)  6.7 secs (0.4)   2.4 secs (0.0)   2.2 secs ( 0.0)
stat_compld:  5.7 secs (0.1)  9.6 secs (2.9)   2.5 secs (0.2)   2.5 secs ( 0.0)

A couple of things to note.  If you were testing Frank's patches, I
made one additional optimization to his patch, which removed the
orphaned inode handling.  This wasn't necessary if you're running
without the journal, I'm not sure if this would be measurable in your
benchmarks, since the inodes that would be getting modified were
probably going to be dirtied and require writeback anyway, but you
might get sightly better numbers with the version of the patch I
ultimately pushed to Linus.

The other thing to note is that in Compilebench's read_tree, ext2 and
ext3 are scoring better than ext4.  This is probably related to ext4's
changes in its block/inode allocation hueristics, which is something
that we probably should look at as part of tuning exercises.  The
brtfs.boxacle.net benchmarks showed something similar, which I also
would attribute to changes in ext4's allocation policies.

						- Ted

関連記事

• btrfsがマージされました (2009/01/10)
• ext4がいつの間にか結構高速化していた件について (2009/01/08)
• 当然却下です (2009/01/08)

関連記事

• ext4がいつの間にか結構高速化していた件について (2009/01/08)
• 当然却下です (2009/01/08)
• さらに続々とｃｃが (2009/01/08)

関連記事

• 当然却下です (2009/01/08)
• さらに続々とｃｃが (2009/01/08)
• 2.6.29で siginfo構造体のsi_pid の扱いが変わりました (2009/01/07)

関連記事

• さらに続々とｃｃが (2009/01/08)
• 2.6.29で siginfo構造体のsi_pid の扱いが変わりました (2009/01/07)
• [Lca09_Chat] HPC Linux BoF proposal (2009/01/07)

関連記事

• 2.6.29で siginfo構造体のsi_pid の扱いが変わりました (2009/01/07)
• [Lca09_Chat] HPC Linux BoF proposal (2009/01/07)
• Kawai さんの "coredump_filter: permit changing of the default filter" がmainline入り (2009/01/07)

関連記事

• [Lca09_Chat] HPC Linux BoF proposal (2009/01/07)
• Kawai さんの "coredump_filter: permit changing of the default filter" がmainline入り (2009/01/07)
• 今数えたら (2009/01/07)

関連記事

• Kawai さんの "coredump_filter: permit changing of the default filter" がmainline入り (2009/01/07)
• 今数えたら (2009/01/07)
• "mm: report the MMU pagesize in /proc/pid/smaps" パッチがmainline入り (2009/01/07)

関連記事

• 今数えたら (2009/01/07)
• "mm: report the MMU pagesize in /proc/pid/smaps" パッチがmainline入り (2009/01/07)
• "vmscan: bail out of direct reclaim after swap_cluster_max pages" がmainline入り (2009/01/07)