使用fcntl与F_OFD_SETLK实现文件范围写入隔离的问题

字节范围锁为什么达不到你的预期 #

你用的fcntl + F_OFD_SETLK实现的是协作式建议锁（advisory lock），内核不会强制阻止无锁的读写操作。
这类锁的作用只是提供互斥判断机制：只有所有访问文件的主体都主动遵守「先申请对应区间的锁，申请成功再操作对应区间」的规则时，锁才能起到并发控制的效果。如果你不管锁有没有申请成功就直接调用写入接口，内核完全不会拦截，这就是你测试里已经加锁的区间照样被其他fd写入的根本原因。
哪怕你开启文件系统的强制锁支持（需要挂载时加mand参数、文件设置特殊权限位），也没法实现「每个fd只能写入自己被允许的范围」的需求：强制锁只会阻止未持有对应区间锁的fd写入，但管不住已经持有某段锁的fd越界写其他区间——比如你测试里firstfd持有0-0x800的锁，照样能毫无阻碍地写到0x900位置，锁对这种行为完全没有约束。而且强制锁本身兼容性差、问题多，不建议在生产环境使用。

可落地的实现方案 #

针对EEPROM分区隔离、防止越界读写的需求，推荐以下几个方案，按实用性排序：

• 封装上层IO接口做强制校验：这是最稳妥、零依赖、行为100%可控的方案。不要把原始文件描述符直接暴露给上层分区操作逻辑，自己封装一层分区句柄，每个句柄绑定原始fd、分区起始偏移、分区长度三个属性，所有读写操作都走你封装的接口：每次写入/读取前先计算操作的实际范围，只要超出当前分区允许的起止偏移，直接返回错误，从入口就拦住越界操作。不需要依赖任何内核特殊特性，不管是操作真实EEPROM设备还是普通模拟文件都能正常工作。
• 用设备映射拆分独立分区设备：如果是Linux环境下操作，可以用dm-linear把EEPROM对应的块设备（或者你用来模拟EEPROM的文件）切分成多个独立的逻辑块设备，每个分区对应一个单独的设备节点。上层打开对应分区的设备节点时，内核会自动把IO范围限制在该分区的区间内，越界访问直接返回错误，不需要你在用户态做额外校验。
• 系统调用劫持拦截：如果必须直接使用原始fd，可以通过LD_PRELOAD劫持pwrite/write/lseek等IO相关函数，在函数内部维护每个fd对应的允许访问范围，越界操作直接返回权限错误。但这种方案侵入性强，容易和其他库产生兼容问题，优先级低于前两种。

测试代码的问题 #

你的测试逻辑不符合建议锁的设计逻辑，所以才会得到和预期不符的结果：

1. firstfd申请了0-0x800的锁之后，直接往0x900位置写入，你并没有给这个fd申请0x900区间的锁，建议锁不会限制fd写自己没持有锁的区间
2. secondfd申请0-0x800锁失败返回EAGAIN之后，你没有终止后续操作，还是直接调用了pwrite往0位置写数据，建议锁不会主动拦截这种无锁写入
3. 你没有在写入前做任何范围判断，锁的申请结果和后续写入操作完全没有绑定，自然起不到权限隔离的作用

内容的提问来源于stack exchange，提问作者hellow