lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Wed, 21 Apr 2010 03:59:00 -0400
From:	Abhinav Duggal <abhinav@...sunysb.edu>
To:	linux-kernel@...r.kernel.org
Subject: Is memory barrier really needed in unlock_new_inode?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ