On Thu, 8 Jun 2006, Ingo Molnar wrote:
> * Anton Altaparmakov <[email protected]> wrote:
> > > &ni->mrec_lock - a spinlock protecting a particular inode's MFT data.
> > > (finegrained lock for the MFT record) It is
> > > typically taken by map_mft_record() and released by
> > > unmap_mft_record().
> >
> > Correct, except s/spinlock/semaphore/ (that really should become a
> > mutex one day).
>
> yeah - it's in fact a mutex already.
>
> > No it is not as explained above. Something has gotten confused
> > somewhere because the order of events is the wrong way round...
>
> did my second trace make more sense? The dependency that the validator
Which one was that? Could you please quote it again so we both know we
are talking about the same thing?
> recorded can be pretty much taken as granted - it only stores
> dependencies that truly trigger runtime. What shouldnt be taken as
> granted is my explanation of the events :-)
Ok. (-:
> there is a wide array of methods and APIs available to express locking
> semantics to the validator in a natural and non-intrusive way [for cases
> where the validator gets it wrong or simply has no way of auto-learning
> them] - but for that i'll first have to understand the locking semantics
> :-)
Indeed. (-:
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
