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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 20 Jun 2016 11:03:01 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Deepa Dinamani <deepa.kernel@...il.com>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Theodore Ts'o" <tytso@....edu>, Al Viro <viro@...iv.linux.org.uk>,
	y2038@...ts.linaro.org,
	"adilger.kernel@...ger.ca" <adilger.kernel@...ger.ca>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Anna Schumaker <anna.schumaker@...app.com>, buchino@...co.com,
	ceph-devel <ceph-devel@...r.kernel.org>,
	Chris Mason <clm@...com>, Changman Lee <cm224.lee@...sung.com>,
	Artem Bityutskiy <dedekind1@...il.com>,
	David Sterba <dsterba@...e.com>, Alex Elder <elder@...nel.org>,
	Eric Paris <eparis@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	hiralpat@...co.com, Ilya Dryomov <idryomov@...il.com>,
	Jan Kara <jack@...e.com>, Jaegeuk Kim <jaegeuk@...nel.org>,
	Josef Bacik <jbacik@...com>, jejb@...ux.vnet.ibm.com,
	jfs-discussion@...ts.sourceforge.net,
	Joel Becker <jlbec@...lplan.org>,
	John Stultz <john.stultz@...aro.org>, linux-audit@...hat.com,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	"Linux F2FS DEV, Mailing List" 
	<linux-f2fs-devel@...ts.sourceforge.net>,
	linux-mtd <linux-mtd@...ts.infradead.org>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Linux SCSI List <linux-scsi@...r.kernel.org>,
	lustre-devel@...ts.lustre.org,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Mark Fasheh <mfasheh@...e.com>, ocfs2-devel@....oracle.com,
	Paul Moore <paul@...l-moore.com>, Sage Weil <sage@...hat.com>,
	Steve French <sfrench@...ba.org>,
	Dave Kleikamp <shaggy@...nel.org>, sramars@...co.com,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	"Yan, Zheng" <zyan@...hat.com>
Subject: Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani <deepa.kernel@...il.com> wrote:
> The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros.

This version now looks ok to me.

I do have a comment (or maybe just a RFD) for future work.

It does strike me that once we actually change over the inode times to
use timespec64, the calling conventions are going to be fairly
horrendous on most 32-bit architectures.

Gcc handles 8-byte structure returns (on most architectures) by
returning them as two 32-bit registers (%edx:%eax on x86). But once it
is timespec64, that will no longer be the case, and the calling
convention will end up using a pointer to the local stack instead.

So for 32-bit code generation, we *may* want to introduce a new model of doing

    set_inode_time(inode, ATTR_ATIME | ATTR_MTIME);

which basically just does

    inode->i_atime = inode->i_mtime = current_time(inode);

but with a much easier calling convention on 32-bit architectures.

But that is entirely orthogonal to this patch-set, and should be seen
as a separate issue.

And maybe it doesn't end up helping anyway, but I do think those
"simple" direct assignments will really generate pretty disgusting
code on 32-bit architectures.

That whole

    inode->i_atime = inode->i_mtime = CURRENT_TIME;

model really made a lot more sense back in the ancient days when inode
times were just simply 32-bit seconds (not even timeval structures).

                  Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ