f_offset

[Marcel Moolenaar]

On Apr 14, 2008, at 1:27 AM, 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?  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.

I'm working on SMP for PowerPC..

-- 
Marcel Moolenaar
xcllnt at mac.com