トップ «前の日(07-06) 最新 次の日(07-08)» 追記

Orz日記 by Akio Morita

ToDo:

  • 15 SAD Fit[]回りの障害事例の解析
  • 10 smart pointer版PEGクラスの再実装(Left Recursionまわり)
2006|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|06|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|09|10|11|12|
2013|01|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|06|07|08|10|12|
2016|01|02|03|05|06|08|10|11|
2017|01|02|03|04|05|06|07|09|10|11|12|
2018|01|02|03|04|06|07|08|09|10|11|12|
2019|01|03|04|05|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|

2008-07-06

_ [SAD]1.0.10.2.8a

なんか、MAIN trunkに Cygwin用の変更が入っているが、 見るからに uglyなコードですねぇ

mk/sad.tcltk.mk

MacOSX上の VMwareで動かす Cygwin on Windosから MaxOSX上の File Systemを見ると:%003Aに化けるそうだが、 VMware3の頃と同様にホストOS側とゲストWindowsのFile System共有に SAMBAを使っているのなら SAMBAの HEX codingが原因に思えるのだが...

だとすると、環境側の問題なので取り込むべきでは無いよね

もしも、Cygwin上で展開したFile Name Space上の:文字が 化けるとしたら、File System層のエミュレートにバグがあることになる

WindowsのローカルなNTFSを bin modeで Cygwin側にマウントしている 状況で、Cygwinな bashからecho foo > bar:zooを実行すると barというファイルが出来る。つまり、:から先の PATH名が 無視されている。unix互換じゃないぞ!(2008-07-08追記)

以前、MacOSX上で shellからでは無く GUI付きのMacアプリな展開ツールで tar.gzを展開すると:が別の文字に変換されるという事例に 遭遇したことがある。 MacOSの PATH Separatorは :だが、unix側のAPIを使うと(unix shell等) unix API側で:/を入れ替える変換を内部的に実施しているが、 昔ながらのMacOS API(おそらく Carbon)ではそのような変換を行わないので アプリ側が変換しているのが原因だった。

.depend

実在しないファイルの依存関係が commitされている

make dependするときは、cleanな source treeで行いましょう

srcまわり

uglyですねぇ...

ucontext_t型

ucontext_tに関しては、SUSv2/POSIX.1-2001辺りに有るらしいし、 sigaction(2)で POSIX SA_SIGINFOなハンドラが使える場合は 第3引数が ucontext_t*なのでその定義が必要で、 SA_SIGINFOマクロが未定義という問題が出ていない以上、 環境依存のucontext_t型を定義するヘッダーは存在しなければならないはず。 したがって、無いのは全面的に Cygwin側が悪いような気がする。

SA_*マクロ

SA_ONSTACK/SA_NOCLDWAITが未定義な際に、 0以外の定数マクロを定義するのは、移植性的に NG。 フラグビットの位置は環境依存だからこそ、マクロで定義している訳で、 これを未定義だからと言って環境を考慮せず 0以外の定数にすると どんな副作用があるか分からない。

そもそも、フラグマクロが未定義ということはサポートされていないと言う ことなので、src/tfProcess_.c側で SA_ONSTACK/SA_NOCLDWAITフラグを 操作するコードを #ifdefで無効化すべきところ

getaddrinfo/getnameinfo/freeaddrinfo関数

IPv6をサポートするための Address Family Independent APIなのですが、 IEEE Std 1003.1-2004(POSIX.1)/RFC 3493らしいので、無いのは Cygwinが悪い。 あと、この手の未実装APIを独自の実装で置き換える場合、 移植性を考えると呼出側に埋め込まずに APIの実装を別ファイルにして リンク時に組み込みを制御すべきところ(置き場的には、src/simの下かな?)

Cygwin/w32api 1.5.25-15 IPv6 extension0.22なんてものが有るらしい。 つまり、Cygwinの libcは IPv6未対応ということ(2008-07-08追記)

_ [LHC]Transfer Matrixの再構築ツール

モデル上でテストした範囲では、軌道残差を共役勾配法で最小化する実装では 収束が遅い、入力される軌道情報の誤差への感度が高いなどの問題が 有るもののアルゴリズムとしては動くようなので、ツールの形に実装開始。


2021-07-06

_ [FreeBSD][IPv6]IPv6 gateway考察

WAN側のIPv6通信は確保したので、LAN側をどうするかの考察

技術的には以下のアイデアがある

  • WAN側から提供されるaddress prefixをLAN側で使う (LAN側にglobal unicast addressを付ける)
    • RA proxyによりWAN側のRAをLAN側に転送する
      • YAMAHA等のルーターアプライアンスにある機能
    • WAN側のNICからaddress prefixを切り出して、LAN側NICのrtadvdで配り直す (非常に稀なケースになると思われるが、途中でaddress prefixが変更された場合の対処を考える必要がある)
    • LAN内のDNS上のIPv6アドレスがWAN側のaddress prefix依存になる
      • IPv6初期に提案されていたDNAME/A6レコードによるaddress prefixとホストアドレスの分離は、非推奨になっているぽぃ
      • address prefix変更をトリガーにして、AAAAを動的に合成する実装が必要
  • LAN側にRFC4193 unique local unicast addressを与えて、境界ルーターでprefixを付け替える
    • ipfwだとNPTv6が該当
    • LAN内のAAAAレコードは、unique local unicastなので動的な変更を考慮しなくてよい

一番手がかからないのはYAMAHAルーターあたりを買ってくる(ついでにMAP-EなIPv4 over IPv6トンネルも開通する)辺りだが、LAN側にDNSで引けるIPv6アドレスを割り当てるなら次点はunique local unicastによる実装か?

_ [FreeBSD]sys/netinet/libalias/alias_db.cエンバグしてるぽぃ

久々にカーネルパニック(Fatal trap 18: integer divide fault while in kernel mode)で死んだ

バックトレースからsys/netinet/libalias/alias_db.cが怪しい

KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b27f30b0
vpanic() at vpanic+0x181/frame 0xfffffe00b27f3100
panic() at panic+0x43/frame 0xfffffe00b27f3160
trap_fatal() at trap_fatal+0x387/frame 0xfffffe00b27f31c0
trap() at trap+0x8b/frame 0xfffffe00b27f32d0
calltrap() at calltrap+0x8/frame 0xfffffe00b27f32d0
--- trap 0x12, rip = 0xffffffff808a68bc, rsp = 0xfffffe00b27f33a0, rbp = 0xfffffe00b27f33b0 ---
HouseKeeping() at HouseKeeping+0x1c/frame 0xfffffe00b27f33b0
LibAliasInLocked() at LibAliasInLocked+0x2f/frame 0xfffffe00b27f3470

おそらく当該コードは stable/13 390866d47effe8f5a11f3f852ae891f14dd4d15cで導入されたHouseKeepingの起床レートを処理パケットレートに基づいて調整するコードのコーナーケースと思われる

コーディング的には、kernel modeでの経時処理が重いので可能な限り処理パケット数で起床レートを制御し、直近約1秒の処理パケット数から平均毎秒3回の起床レートとなるようpacket_limitを制御するのが目的だが、パケットレートが低い場合に穴がある模様

  • packet_limitの更新コードにたどり着いた時点で、packetsはその時点のpacket_limitの整数倍
  • 3 * packet_limit > packets時には、packet_limitが引き下げられる
  • packet_limit3未満のケースでは、packet_limit = 0(非負の整数除算は切り捨て)に設定され、次回の呼び出し時にpackets % packet_limitで整数ゼロ除算で例外になる
  • 1packet/secへ向けて処理レートが減衰するケースでは、packet_limitの最短更新シナリオは、1000(初期値)->333->111->37->12->4->1->0で7秒ほどでpanicに至ると推定される

main現時点 では、治ってないぽぃ

修正は、packet_limitに下限値を設定しておく辺りか

user spaceのnatdを使っている場合は、デーモンが死んでNATが機能しなくなるものと思われる

void
HouseKeeping(struct libalias *la)
{
	static unsigned int packets = 0;
	static unsigned int packet_limit = 1000;

	LIBALIAS_LOCK_ASSERT(la);
	packets++;

	/*
	 * User space time/gettimeofday/... is very expensive.
	 * Kernel space cache trashing is unnecessary.
	 *
	 * Save system time (seconds) in global variable LibAliasTime
	 * for use by other functions. This is done so as not to
	 * unnecessarily waste timeline by making system calls.
	 *
	 * Reduce the amount of house keeping work substantially by
	 * sampling over the packets.
	 */
	if (packets % packet_limit == 0) {
		time_t now;

#ifdef _KERNEL
		now = time_uptime;
#else
		now = time(NULL);
#endif
		if (now != LibAliasTime) {
			/* retry three times a second */
			packet_limit = packets / 3;
			packets = 0;
			LibAliasTime = now;
		}

	}
	/* Do a cleanup for the first packets of the new second only */
	if (packets < (la->udpLinkCount + la->tcpLinkCount)) {
		struct alias_link * lnk = TAILQ_FIRST(&la->checkExpire);

		CleanupLink(la, &lnk, 0);
	}
}

カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記