f_offset

[Arthur Hartwig]

ext Jeff Roberson wrote:
>
> On Mon, 14 Apr 2008, Arthur Hartwig wrote:
>
>> ext Jeff Roberson wrote:
>>> So I'm in the midst of working on other filesystem concurrency 
>>> issues and that has brought me back around to f_offset again.  I'm 
>>> working on a method to allow non-overlapping writes and reads to 
>>> proceed concurrently to the same file.  This means the exclusive 
>>> vnode lock can not be used to protect f_offset even in the write case.
>>>
>>> To maintain the existing semantics I'm simply going to add an 
>>> exclusive sx_xlock() around access to f_offset.  This is done 
>>> inconsistently today which is fine from the perspective of the 
>>> updates in most cases being user-space races.  However, f_offset is 
>>> 64bit and can not be written atomically on 32bit systems and so 
>>> requires some extra synchronization there.
>> I'm not sure of the processor family constraints of the i386 builds, 
>> but the Intel IA32 architecture manual says reads and writes of a 
>> quadword (64 bits) aligned on a quadword boundary are atomic (Pentium 
>> and newer CPUs). Guess that leaves out i386, i486 (any others?)
>
> Thanks.  I hadn't seen that.  Do you know which manual and section 
> states this?  
Intel 64 and IA-32 Architectures Software Developer's Manual Vol 3A: 
System Programming Guide, Part 1, section 7.1.1 Guaranteed Atomic 
Operations. You can download this (and other volumes of the Intel 
Architecture manuals) from 
http://www.intel.com/products/processor/manuals/index.htm

> I was intending to simply use cmpxchg8b but it sounds like that may 
> not be necessary.  We still have to handle other 32bit archs like 
> powerpc and mips but I'm not sure if any of those are SMP.
Do you also have to handle i386 and i486?
>
> Jeff