Prev: [RFC PATCH 1/5] HSI: Introducing HSI framework
Next: [RFC] Second OLPC Viafb series
From: Abhinav Duggal on 21 Apr 2010 04:00
Hi all,
I am trying to understand the barrier in unlock_new_inode and I am not
sure whether the barrier is needed or not.
I am looking at kernel 2.6.34-rc2.
According to the Intel Architecture manual the CPU would not reorder
writes from software point of view. So it should not be a problem on
Intel. I think AMD also does not reorder writes. So it should not be a
problem there also. It could be a problem on Alpha or other arch. but
I am not sure. If only Alpha or others need it shouldn't it be changed
to smp_read_barrier_depends or something. I am not an expert on memory
barriers but I am trying to understand their use and look at places
where they might not be necessary.

Anyways, the comment says
However we must emit the memory barrier so that other CPUs reliably
�� * see the clearing of I_NEW after the other inode initialisation has
�� * completed.
�� */
��smp_mb();
��WARN_ON(!(inode->i_state & I_NEW));
��inode->i_state &= ~I_NEW;
I went through the original post on this at
http://lkml.indiana.edu/hypermail/linux/kernel/0909.1/00103.html

So the comment says that this barrier is prevents writes from
reordering i.e. clearing of I_NEW and previous writes to inode fields.
But write reorder cannot happen on Intel and AMD so shouldn't it be
changed to some architecture specific barrier who require it. I am
confused.Could anyone explain this?
The thread says that it solves the problem of corruption of ext3 with
nfs. How could the problem occur if writes are not reordered. Is it
that old Intel CPUs allowed writes reordering and the new ones won't
allow or something?Or the corruption occurs on some other CPUs which
do not have such strong guarantees.
I think we can remove this memory barrier if it is not necessary but I
am not sure.
Please look into this and tell me what are your views.
With Regards,
Abhinav.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [RFC PATCH 1/5] HSI: Introducing HSI framework
Next: [RFC] Second OLPC Viafb series