我们一行两辆车,两位甘肃师傅,李玉荣和周华。
李师傅长得比较敦厚,一看就是个实在人,相当有福相,不过这次阿里行,他是吃了苦头的。从冈仁波齐开始有点发烧,到尼玛愈发严重,中间呼呼代开了几段路李师傅休息了会,直到在班戈打了点滴才有好转。塔钦的天气是比较怪,风大,冷,相当冷。我转山回来的路上,就领教过了,也领教够了。
周师傅和李师傅性格相反,开朗健谈,更绝得是他的眼神特好,说是千里眼也不为过,很远的黑颈鹤就一个小点他都能看得出来。一路上多亏了周师傅的一双亮眼,我们才看到众多的小动物,和阿荣的电眼有得一拼。周师傅常走阿里线,和道上的朋友混得不错,我们也沾了不少光,至少在住宿上从未发愁。
还有更妙的,李玉荣和周华是两乔。据阿华说他曾有缘一睹大乔小乔的芳容,这个留待阿华再作讲述。
师傅联系电话:
李玉荣:13322596678
周华: 13889012365
西藏的风景太美了,天蓝云白水清,即便是块石头也有属于它的故事,但最让人感动的还是人,最让人难忘的还是一个个活生生的人和围绕着他所发生的故事。
9个人(两位师傅)14天里大部分时间里都挤在狭小的空间里,行走在颠簸的路上,但美丽的风景让这群人忘了一切人世间的琐事和烦恼 ......
老爷:我们7人小分队的老大,地道的上海男人,有“老爷”的范。老爷足迹遍及大半个中国,你随便说个地方,他都能讲出个故事来,不信你可以试试。(要不要请客由老爷定,要请地话一定带上我,呵呵)。老大说话直来直去,执地有声:“尼泊尔我最熟了,你想去哪里”,两句话就让几位有意去尼泊尔的女生睁大了眼睛。碰到这样的“老爷”,你敢不服?
小莉:我们的CFO,整个队伍的大管家。财政大权交给她我们放心,一路上都在操心怎么替大家省钱。不与天斗,也不与地斗,就只与JS斗。一路下来,我们7个小矮人是越活越老越晒越黑,唯独她这位白雪公主却越活越小,穿起藏胞来也让文布的藏族小伙们笑开了花。
小玥:小玥正在狮城读书,有去cctv9当播音员的潜质,她就像个开心果,有她在,就有笑声,有她在,周师傅开起车来也来劲,特别是在土路上,不晃个七荤八素绝不罢休,因为这是小玥的最爱。小玥喜欢用叠字方式叫人,如华华/莉莉/荣荣,再加上她甜甜的声音和特有的调调,叫起来真让人受用。只可惜她只跟我们走了前半程,从狮泉河分开后,我们两辆车的气氛都相当得沉闷,直到后面遇到“草原三姐妹”后,情况才有所缓解。
华华:一个很有品的男人,要求也不一般,不过不讲究地时候大家可以一起坐吃胡虏肉,讲究地时候定要食不厌精,但无论何时,不洗个澡是不行的!他的组合工具本可以好好修理一头牦牛,但一程下来,全用在苹果和梨子上了。阿华削水果的技术更胜一筹,以至于他说这辈子的苹果都削掉了,还好我们只买了一箱子苹果,否则,下辈子的苹果他也得全给削了。华仔削的苹果,大家是吃在嘴里,甜在心里。
呼呼:来自内蒙的汉子,工作在深圳,但人常驻伊郎,混合型,但绝对是个行动派,雷厉风行,从文布至尼玛路上抓鱼时,路遇一卡车,几名藏族小青年鱼贯而出,呼呼极速跑向李师傅招救援以拯众人于危难。好在是虚惊一场:及集体喝山歌也。呼呼铁汉亦有柔情,在塔钦,一顿晚饭时间就让仁老师的儿子不舍得离开了,任凭我们拿出浑身解数,小家伙还是只认呼呼,直直扑向呼呼温暖的怀抱。
荣荣:阿荣的朋友遍天下,能和阿荣同行,能成为阿荣的朋友是我们的荣幸。来自福州的阿荣泡得一手好茶,我们是走一路喝一路,从铁观音新茶,铁观音老茶,银骏眉,金骏眉到大红袍都尝了个遍。除了茶之外,阿荣的大眼睛还会放电,只是普通话不够标准,分吃阿华削的苹果时说:“你吃一大便(片)我吃一小便(片)”,明着舍已为人,实则是将困难留给别人,将方便留给自己。
小强:我是小强,小强是我。大家这样叫我,一开始我还真不习惯,但后来越觉得亲切。本以为我向来钟爱看风景,但此行让我改变看法,其实我更喜欢看人:有担当,有烦恼,有自嘲,有追求的一群人才是最好的风景,有幸我也是风景的一部分。
MmSetAddressRangeModified用来设置PFN为dirty/modified,并将PTE的dirty位清除。但除此之外,还有个不明显的副作用,看下面的分析:
1: kd> !pte 0xfffff880`0c9e6000
VA fffff8800c9e6000
PXE @ FFFFF6FB7DBEDF88 PPE at FFFFF6FB7DBF1000 PDE at FFFFF6FB7E200320 PTE at FFFFF6FC40064F30
contains 000000003FE84863 contains 000000003FE83863 contains 0000000014516863 contains 000000000FAD7963
pfn 3fe84 ---DA--KWEV pfn 3fe83 ---DA--KWEV pfn 14516 ---DA--KWEV pfn fad7 -G-DA--KWEV
PTE entry 状态为dirty,并且是可写的(writable)。 再看调用MmSetAddressRangeModified后的状态:
1: kd> !pte 0xfffff880`0c9e6000
VA fffff8800c9e6000
PXE @ FFFFF6FB7DBEDF88 PPE at FFFFF6FB7DBF1000 PDE at FFFFF6FB7E200320 PTE at FFFFF6FC40064F30
contains 000000003FE84863 contains 000000003FE83863 contains 0000000014516863 contains 000000000FAD7921
pfn 3fe84 ---DA--KWEV pfn 3fe83 ---DA--KWEV pfn 14516 ---DA--KWEV pfn fad7 -G--A--KREV
PTE entry的dirty位已被清除,但是此pte已被设成了readonly状态了。所以如果再有写操作,必然会导致page fault发生。
这就是我曾遇到的一个Ext2Fsd的bug:Ext2Fsd为了将page cache锁定,创建了MDL并重新映射到系统空间(调用MmMapLockedPagesSpecifyCache)。新映射的va具有dirty及writable属性,故此va在spinlock (DISPATCH_LEVEL)下进行写操作不会导致任何异常。但在提交改动过程中,Ext2Fsd调用了MmSetAddressRangeModified,调用后MmSetAddressRangeModified会将此pte设置为readonly,如果下一次的写操作正好在spinlock下(DISPATCH_LEVEL),将会导致BSOD: DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1),如果在获取spinlock前曾执行过写操作(IRQL < DISPATCH_LEVEL),则会正常触发page fault,然后MmAccessFault会重置pte为writeable,并设置dirty位,此后如果再进入DISPATCH_LEVEL,对此va进行写操作便不会触发page fault了。这就构成了一定的随机性和隐蔽性,给调试带来了很大的麻烦。
明白了问题所在,不妨再做个实验:如果手工将此pte设为writeable的,再进行写操作,cpu应该直接置pte为dirty,而不必调用OS(即page fault)。
对va 0xfffffa60`04ae7000 调用MmSetAddressRangeModified后,
1: kd> !pte 0xfffffa60`04ae7000
VA fffffa6004ae7000
PXE @ FFFFF6FB7DBEDFA0 PPE at FFFFF6FB7DBF4C00 PDE at FFFFF6FB7E980128 PTE at FFFFF6FD30025738
contains 000000007FFC4863 contains 000000007FFC3863 contains 00000000539A2863 contains 00000000149AD921
pfn 7ffc4 ---DA--KWEV pfn 7ffc3 ---DA--KWEV pfn 539a2 ---DA--KWEV pfn 149ad -G--A—KREV
手工修改 0xfffffa60`04ae7000为writeable,不必置dirty标志:
1: kd> dq FFFFF6FD30025738 l1
fffff6fd`30025738 00000000`149ad921
1: kd> eb FFFFF6FD30025738 23
1: kd> !pte 0xfffffa60`04ae7000
VA fffffa6004ae7000
PXE @ FFFFF6FB7DBEDFA0 PPE at FFFFF6FB7DBF4C00 PDE at FFFFF6FB7E980128 PTE at FFFFF6FD30025738
contains 000000007FFC4863 contains 000000007FFC3863 contains 00000000539A2863 contains 00000000149AD923
pfn 7ffc4 ---DA--KWEV pfn 7ffc3 ---DA--KWEV pfn 539a2 ---DA--KWEV pfn 149ad -G--A--KWEV
在进行写操作前可以对KiPageFault或MmAccessFault设置断点,然后进行实验。看断点会不会触发,操作后再检查一下pte的dirty标志是不是已经设置了。具体实验结果,就留给读者自己去验证了。
在DISPATCH_LEVEL中操作paged va无论是已将其page锁定还是重新映射过,都有点如履薄冰的感觉,特别是对file cache,Cache Manager的不少内部操作都会更改pte的属性或调用MmSetAddressRangeModified,到处都可能有陷阱。所以最保险的方式还是不用spinlock ![]()