Re: src/etc/Makefile

[Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>]

<E167ts9-0000KE-00@ruri.iri.co.jp>の記事において
tsubai@iri.co.jpさんは書きました。

> 現時点での結論は、pmap_kenter_pa()/pmap_kremove() を実装する、じゃ
> ないかと思われます。(まだ耐久テスト中)

今の powerpc の pmap_kenter_pa()/pmap_kremove() は単に
pmap_enter()/pmap_remove() を呼んでるだけですよね。
それがまずいということでしょうか。
それとも MD のどこかの呼出側が pmap_kenter_pa() を使うべきところで
pmap_enter() を使ってるってことでしょうか。

実は sun3x でも同時期に
panic: kernel diagnostic assertion "rv" failed が出てた
http://mail-index.netbsd.org/port-sun3/2001/09/07/0000.html
んですが、その時は

・pmap_kenter_pa()/pmap_kremove() が「ちゃんと」実装された
  (== pv_list をいじらずに pte だけ更新するように変更)
・同時に pmap.c 中で pv_list を触っている前後の splvm() が削除された
・が、一部 interrupt context の中から pmap_enter(pmap_kernel(), ..) を
  呼んでる部分が残ってた

ということで pv_list がおかしくなってました。このときは chs 氏が
該当の pmap_enter() を pmap_kenter_pa() に変更することで直りました。
http://mail-index.netbsd.org/source-changes/2001/09/11/0069.html

> この genfs_putpages() ってのは pg->flags & (PG_RELEASED|PG_PAGEOUT)
> でないときは問答無用で pmap_page_protect(pg, VM_PROT_NONE) して
> しまいます。
> 
> flags をいじるのは違うような気がするのでちょっと悩んでたんですが、
> pmap_kenter_pa() すれば pv_list に載らないので pmap_page_protect()
> に消されないんじゃないかと思ってやってみたところ、今のところまだ
> 例の assertion panic は出ていません。

これって pmap_kenter_pa()/pmap_kremove() が正しく実装されていないと
(== pmap_kenter_pa()/pmap_kremove() がいまだに vm_prot_t を見てると)
もはや vm system はまともに動かない、ということなんでしょうか。

＃だとすると、いくら NEWPMAP では動いてるからといって
＃vm を変更した chs 氏の側で旧 pmap がほったらかしだった
＃というのは移行の仕方がひどいような……

> # pmap_kenter_pa() は筒井さんが確認済みだったような気もしたけど…

いや、これは pmap.c 中で pv_list を触ってる前後では splvm() されてる
(現状 pmap_kenter_pa() は pmap_enter() を呼んでて pv_list をいじるから) 
というところを見ただけで、確認したとかいうレベルではないです。
「pv_list をさわってはいけない」ということなら問題ありです。

> でも uvm が、pmap_kenter_pa() したページは pmap_page_protect() の
> 対象にならないことを要求するってのは、なんだかなあ…。

まだ pmap(9) はろくに読めてませんが、長々と引用すると

>  Mappings entered with the pmap_enter()
>  function are ``managed'' mappings.  It is possible for ``unmanaged'' map-
>  pings of a page to be created, using the pmap_kenter_pa() function.  The
>  use of ``unmanaged'' mappings should be limited to code which may execute
>  in interrupt context (for example, the kernel memory allocator), or to
>  enter mappings for physical addresses which are not managed by the virtu-
>  al memory system.  ``Unmanaged'' mappings may only be entered into the
>  kernel's virtual address space.  This constraint is placed on the callers
>  of the pmap_kenter_pa() and pmap_kremove() functions so that the pmap im-
>  plementation need not block interrupts when manipulating data structures
>  or holding locks.

pmap_kenter_pa()/pmap_kremove() は interrupt context からいじる page
もしくは uvm で管理しない page (buffer cache とか)のために存在してて、
それは pmap_enter() で扱われる "managed page" とは別、
ってことなんですよねえ。だから pmap_page_protect() と無関係、
ってのは一応仕様通りという気がします。

で、現状ではすでに「無関係でなければならない」ってことならば

> 現時点での結論は、pmap_kenter_pa()/pmap_kremove() を実装する

で正しいと思います。
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp