From: Arnd Bergmann <arnd@arndb.de> To: Dave Chinner <david@fromorbit.com> Cc: "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, joseph@codesourcery.com, john.stultz@linaro.org, hch@infradead.org, tglx@linutronix.de, geert@linux-m68k.org, lftan@altera.com, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [RFC 11/32] xfs: convert to struct inode_time Date: Sat, 31 May 2014 17:37:52 +0200 [thread overview] Message-ID: <5507340.nVBP5LFtqn@wuerfel> (raw) In-Reply-To: <20140531011450.GJ14410@dastard> On Saturday 31 May 2014 11:14:50 Dave Chinner wrote: > On Fri, May 30, 2014 at 05:41:14PM -0700, H. Peter Anvin wrote: > > On 05/30/2014 05:37 PM, Dave Chinner wrote: > > > > > > IOWs, the filesystem has to be able to reject any attempt to set a > > > timestamp that is can't represent on disk otherwise Bad Stuff will > > > happen, > > > > Actually it is questionable if it is worse to reject a timestamp or just > > let it wrap. Rejecting a valid timestamp is a bit like "You don't > > exist, go away." > > I think having the new systems calls being able to > return EINVAL if the value cannot be stored permanently on disk > correctly is the right thing to do. Having it silently mangled > by the filesystem and returning "everything is just fine, trust me" > is close to the worst solution I can think of. That's exactly what > leads to overflow bugs occurring.... While going through the file systems, I was wondering whether we should have the times stop at the end of each file systems epoch rather than wrap around. > > > and filesystems have to be able to specify in their on > > > disk format what timestamp encoding is being used. The solution will > > > be different for every filesystem that needs to support time beyond > > > 2038. > > > > Actually the cutoff can be really different for each filesystem, not > > necessarily 2038. However, I maintain the above still holds. > > Sure, but all filesystems are supposed to handle at least the > current unix epoch. In my list at http://kernelnewbies.org/y2038, I found that almost all file systems at least times until 2106, because they treat the on-disk value as unsigned on 64-bit systems, or they use a completely different representation. My guess is that somebody earlier spent a lot of work on making that happen. The exceptions are: * exofs uses signed values, which can probably be changed to be consistent with the others. * isofs has a bug that limits it until 2027 on architectures with a signed 'char' type (otherwise it's 2155). * udf can represent times for many thousands of years through a 16-bit year representation, but the code to convert to epoch uses a const array that ends at 2038. * afs uses signed seconds and can probably be fixed * coda relies on user space time representation getting passed through an ioctl. * I miscategorized xfs/ext2/ext3 as having unsigned 32-bit seconds, where they really use signed. I was confused about XFS since I didn't noticed that there are separate xfs_ictimestamp_t and xfs_timestamp_t types, so I expected XFS to also use the 1970-2106 time range on 64-bit systems today. If we are using the variant of my patch that extends indode_time->tv_sec to s64, nothing should change for XFS at all, the main difference is that we if it gets extended to wider on-disk timestamps, they will work the same way on 32-bit and 64-bit kernels. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de> To: Dave Chinner <david@fromorbit.com> Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, lftan@altera.com, hch@infradead.org, john.stultz@linaro.org, "H. Peter Anvin" <hpa@zytor.com>, linux-fsdevel@vger.kernel.org, geert@linux-m68k.org, tglx@linutronix.de, xfs@oss.sgi.com, joseph@codesourcery.com Subject: Re: [RFC 11/32] xfs: convert to struct inode_time Date: Sat, 31 May 2014 17:37:52 +0200 [thread overview] Message-ID: <5507340.nVBP5LFtqn@wuerfel> (raw) In-Reply-To: <20140531011450.GJ14410@dastard> On Saturday 31 May 2014 11:14:50 Dave Chinner wrote: > On Fri, May 30, 2014 at 05:41:14PM -0700, H. Peter Anvin wrote: > > On 05/30/2014 05:37 PM, Dave Chinner wrote: > > > > > > IOWs, the filesystem has to be able to reject any attempt to set a > > > timestamp that is can't represent on disk otherwise Bad Stuff will > > > happen, > > > > Actually it is questionable if it is worse to reject a timestamp or just > > let it wrap. Rejecting a valid timestamp is a bit like "You don't > > exist, go away." > > I think having the new systems calls being able to > return EINVAL if the value cannot be stored permanently on disk > correctly is the right thing to do. Having it silently mangled > by the filesystem and returning "everything is just fine, trust me" > is close to the worst solution I can think of. That's exactly what > leads to overflow bugs occurring.... While going through the file systems, I was wondering whether we should have the times stop at the end of each file systems epoch rather than wrap around. > > > and filesystems have to be able to specify in their on > > > disk format what timestamp encoding is being used. The solution will > > > be different for every filesystem that needs to support time beyond > > > 2038. > > > > Actually the cutoff can be really different for each filesystem, not > > necessarily 2038. However, I maintain the above still holds. > > Sure, but all filesystems are supposed to handle at least the > current unix epoch. In my list at http://kernelnewbies.org/y2038, I found that almost all file systems at least times until 2106, because they treat the on-disk value as unsigned on 64-bit systems, or they use a completely different representation. My guess is that somebody earlier spent a lot of work on making that happen. The exceptions are: * exofs uses signed values, which can probably be changed to be consistent with the others. * isofs has a bug that limits it until 2027 on architectures with a signed 'char' type (otherwise it's 2155). * udf can represent times for many thousands of years through a 16-bit year representation, but the code to convert to epoch uses a const array that ends at 2038. * afs uses signed seconds and can probably be fixed * coda relies on user space time representation getting passed through an ioctl. * I miscategorized xfs/ext2/ext3 as having unsigned 32-bit seconds, where they really use signed. I was confused about XFS since I didn't noticed that there are separate xfs_ictimestamp_t and xfs_timestamp_t types, so I expected XFS to also use the 1970-2106 time range on 64-bit systems today. If we are using the variant of my patch that extends indode_time->tv_sec to s64, nothing should change for XFS at all, the main difference is that we if it gets extended to wider on-disk timestamps, they will work the same way on 32-bit and 64-bit kernels. Arnd _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-05-31 15:39 UTC|newest] Thread overview: 313+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-05-30 20:01 [RFC 00/32] making inode time stamps y2038 ready Arnd Bergmann 2014-05-30 20:01 ` [Cluster-devel] " Arnd Bergmann 2014-05-30 20:01 ` Arnd Bergmann 2014-05-30 20:01 ` [Ocfs2-devel] " Arnd Bergmann 2014-05-30 20:01 ` Arnd Bergmann 2014-05-30 20:01 ` Arnd Bergmann 2014-05-30 20:01 ` [RFC 01/32] fs: introduce new 'struct inode_time' Arnd Bergmann 2014-05-31 7:56 ` Geert Uytterhoeven 2014-05-31 8:39 ` Andreas Schwab 2014-05-31 8:39 ` Andreas Schwab 2014-05-31 13:19 ` Geert Uytterhoeven 2014-05-31 13:46 ` Andreas Schwab 2014-05-31 13:46 ` Andreas Schwab 2014-05-31 14:54 ` Arnd Bergmann 2014-05-31 16:15 ` Geert Uytterhoeven 2014-05-31 9:03 ` H. Peter Anvin 2014-05-31 14:53 ` Arnd Bergmann 2014-05-31 14:55 ` H. Peter Anvin 2014-05-30 20:01 ` [RFC 02/32] uapi: add struct __kernel_timespec{32,64} Arnd Bergmann 2014-05-30 20:18 ` H. Peter Anvin 2014-05-31 15:09 ` Arnd Bergmann 2014-05-30 20:01 ` [RFC 03/32] fs: introduce sys_utimens64at Arnd Bergmann 2014-05-31 9:22 ` Andreas Schwab 2014-05-31 14:55 ` Arnd Bergmann 2014-05-30 20:01 ` [RFC 04/32] fs: introduce sys_newfstat64/sys_newfstatat64 Arnd Bergmann 2014-05-30 20:01 ` [RFC 05/32] arch: hook up new stat and utimes syscalls Arnd Bergmann 2014-05-30 20:01 ` [RFC 06/32] isofs: fix timestamps beyond 2027 Arnd Bergmann 2014-05-31 7:59 ` Geert Uytterhoeven 2014-05-31 8:47 ` H. Peter Anvin 2014-05-30 20:01 ` [RFC 07/32] fs/nfs: convert to struct inode_time Arnd Bergmann 2014-05-30 20:01 ` [RFC 08/32] fs/ceph: convert to 'struct inode_time' Arnd Bergmann 2014-05-30 20:01 ` [RFC 09/32] fs/pstore: convert to struct inode_time Arnd Bergmann 2014-05-30 21:14 ` Kees Cook 2014-05-30 20:01 ` [RFC 10/32] fs/coda: " Arnd Bergmann 2014-05-30 20:01 ` Arnd Bergmann 2014-05-30 20:01 ` [RFC 11/32] xfs: " Arnd Bergmann 2014-05-30 20:01 ` Arnd Bergmann 2014-05-31 0:37 ` Dave Chinner 2014-05-31 0:37 ` Dave Chinner 2014-05-31 0:41 ` H. Peter Anvin 2014-05-31 0:41 ` H. Peter Anvin 2014-05-31 1:14 ` Dave Chinner 2014-05-31 1:14 ` Dave Chinner 2014-05-31 1:22 ` H. Peter Anvin 2014-05-31 1:22 ` H. Peter Anvin 2014-05-31 5:54 ` Dave Chinner 2014-05-31 5:54 ` Dave Chinner 2014-05-31 8:41 ` H. Peter Anvin 2014-05-31 8:41 ` H. Peter Anvin 2014-05-31 15:46 ` Nicolas Pitre 2014-05-31 15:46 ` Nicolas Pitre 2014-06-01 19:56 ` Arnd Bergmann 2014-06-01 19:56 ` Arnd Bergmann 2014-06-01 20:26 ` H. Peter Anvin 2014-06-01 20:26 ` H. Peter Anvin 2014-06-02 11:02 ` Arnd Bergmann 2014-06-02 11:02 ` Arnd Bergmann 2014-06-02 1:36 ` Nicolas Pitre 2014-06-02 1:36 ` Nicolas Pitre 2014-06-02 2:22 ` Dave Chinner 2014-06-02 2:22 ` Dave Chinner 2014-06-02 7:09 ` Geert Uytterhoeven 2014-06-02 7:09 ` Geert Uytterhoeven 2014-06-02 10:56 ` Arnd Bergmann 2014-06-02 10:56 ` Arnd Bergmann 2014-06-02 11:57 ` Theodore Ts'o 2014-06-02 11:57 ` Theodore Ts'o 2014-06-02 12:38 ` Arnd Bergmann 2014-06-02 12:38 ` Arnd Bergmann 2014-06-02 13:15 ` Theodore Ts'o 2014-06-02 13:15 ` Theodore Ts'o 2014-06-02 12:52 ` Arnd Bergmann 2014-06-02 12:52 ` Arnd Bergmann 2014-06-02 13:07 ` Theodore Ts'o 2014-06-02 13:07 ` Theodore Ts'o 2014-06-02 15:01 ` Arnd Bergmann 2014-06-02 15:01 ` Arnd Bergmann 2014-06-02 14:52 ` H. Peter Anvin 2014-06-02 14:52 ` H. Peter Anvin 2014-06-02 15:04 ` Chuck Lever 2014-06-02 15:04 ` Chuck Lever 2014-06-02 15:31 ` Theodore Ts'o 2014-06-02 15:31 ` Theodore Ts'o 2014-06-02 17:12 ` H. Peter Anvin 2014-06-02 17:12 ` H. Peter Anvin 2014-06-02 18:50 ` Arnd Bergmann 2014-06-02 18:50 ` Arnd Bergmann 2014-06-02 22:29 ` Theodore Ts'o 2014-06-02 22:29 ` Theodore Ts'o 2014-06-02 22:32 ` H. Peter Anvin 2014-06-02 22:32 ` H. Peter Anvin 2014-06-02 23:32 ` Theodore Ts'o 2014-06-02 23:32 ` Theodore Ts'o 2014-06-02 23:33 ` H. Peter Anvin 2014-06-02 23:33 ` H. Peter Anvin 2014-06-03 13:09 ` Roger Willcocks 2014-06-03 13:09 ` Roger Willcocks 2014-06-02 18:52 ` Arnd Bergmann 2014-06-02 18:52 ` Arnd Bergmann 2014-06-02 18:58 ` Roger Willcocks 2014-06-02 18:58 ` Roger Willcocks 2014-06-02 19:04 ` Chuck Lever 2014-06-02 19:04 ` Chuck Lever 2014-06-02 19:04 ` Chuck Lever 2014-06-02 19:10 ` Arnd Bergmann 2014-06-02 19:10 ` Arnd Bergmann 2014-06-01 0:39 ` Dave Chinner 2014-06-01 0:39 ` Dave Chinner 2014-06-02 14:00 ` Joseph S. Myers 2014-06-02 14:00 ` Joseph S. Myers 2014-06-02 14:00 ` Joseph S. Myers 2014-05-31 15:37 ` Arnd Bergmann [this message] 2014-05-31 15:37 ` Arnd Bergmann 2014-06-01 0:24 ` Dave Chinner 2014-06-01 0:24 ` Dave Chinner 2014-06-02 0:28 ` Dave Chinner 2014-06-02 0:28 ` Dave Chinner 2014-06-02 11:35 ` Roger Willcocks 2014-06-02 11:35 ` Roger Willcocks 2014-06-02 11:43 ` Arnd Bergmann 2014-06-02 11:43 ` Arnd Bergmann 2014-06-03 0:32 ` Dave Chinner 2014-06-03 0:32 ` Dave Chinner 2014-06-03 7:33 ` Arnd Bergmann 2014-06-03 7:33 ` Arnd Bergmann 2014-06-03 8:41 ` Dave Chinner 2014-06-03 8:41 ` Dave Chinner 2014-06-03 9:16 ` Arnd Bergmann 2014-06-03 9:16 ` Arnd Bergmann 2014-05-30 20:01 ` [RFC 12/32] btrfs: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 13/32] ext3: " Arnd Bergmann 2014-05-31 9:10 ` H. Peter Anvin 2014-05-31 14:32 ` Arnd Bergmann 2014-05-30 20:01 ` [RFC 14/32] ext4: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 15/32] cifs: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 16/32] ntfs: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 17/32] ubifs: " Arnd Bergmann 2014-05-30 20:01 ` Arnd Bergmann 2014-06-02 7:54 ` Artem Bityutskiy 2014-06-02 7:54 ` Artem Bityutskiy 2014-05-30 20:01 ` [RFC 18/32] ocfs2: " Arnd Bergmann 2014-05-30 20:01 ` [Ocfs2-devel] " Arnd Bergmann 2014-05-30 20:01 ` [RFC 19/32] fs/fat: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 20/32] afs: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 21/32] udf: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 22/32] fs: convert simple fs to inode_time Arnd Bergmann 2014-05-30 23:06 ` Greg Kroah-Hartman 2014-05-30 20:01 ` [RFC 23/32] logfs: convert to struct inode_time Arnd Bergmann 2014-05-30 20:01 ` [RFC 24/32] hfs, hfsplus: " Arnd Bergmann 2014-05-31 14:23 ` Vyacheslav Dubeyko 2014-05-30 20:01 ` [RFC 25/32] gfs2: " Arnd Bergmann 2014-05-30 20:01 ` [Cluster-devel] " Arnd Bergmann 2014-06-02 9:52 ` Steven Whitehouse 2014-06-02 9:52 ` [Cluster-devel] " Steven Whitehouse 2014-05-30 20:01 ` [RFC 26/32] reiserfs: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 27/32] jffs2: " Arnd Bergmann 2014-05-30 20:01 ` Arnd Bergmann 2014-05-30 20:01 ` Arnd Bergmann 2014-05-30 20:01 ` [RFC 28/32] adfs: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 29/32] f2fs: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 30/32] fuse: " Arnd Bergmann 2014-05-30 20:01 ` [RFC 31/32] scsi: fnic: use current_kernel_time() for timestamp Arnd Bergmann 2014-05-30 20:01 ` [RFC 32/32] fs: use new inode_time definition unconditionally Arnd Bergmann 2014-05-31 14:30 ` [RFC 00/32] making inode time stamps y2038 ready Vyacheslav Dubeyko 2014-05-31 14:30 ` [Cluster-devel] " Vyacheslav Dubeyko 2014-05-31 14:30 ` Vyacheslav Dubeyko 2014-05-31 14:30 ` [Ocfs2-devel] " Vyacheslav Dubeyko 2014-05-31 14:30 ` Vyacheslav Dubeyko 2014-05-31 14:30 ` Vyacheslav Dubeyko 2014-06-03 12:21 ` Arnd Bergmann 2014-06-03 12:21 ` [Cluster-devel] " Arnd Bergmann 2014-06-03 12:21 ` Arnd Bergmann 2014-06-03 12:21 ` [Ocfs2-devel] " Arnd Bergmann 2014-06-03 12:21 ` Arnd Bergmann 2014-06-03 12:21 ` Arnd Bergmann 2014-06-03 12:21 ` Arnd Bergmann 2014-05-31 14:51 ` Richard Cochran 2014-05-31 14:51 ` [Cluster-devel] " Richard Cochran 2014-05-31 14:51 ` Richard Cochran 2014-05-31 14:51 ` [Ocfs2-devel] " Richard Cochran 2014-05-31 14:51 ` Richard Cochran 2014-05-31 14:51 ` Richard Cochran 2014-05-31 15:23 ` Arnd Bergmann 2014-05-31 15:23 ` [Cluster-devel] " Arnd Bergmann 2014-05-31 15:23 ` Arnd Bergmann 2014-05-31 15:23 ` [Ocfs2-devel] " Arnd Bergmann 2014-05-31 15:23 ` Arnd Bergmann 2014-05-31 16:20 ` Geert Uytterhoeven 2014-05-31 16:20 ` [Cluster-devel] " Geert Uytterhoeven 2014-05-31 16:20 ` Geert Uytterhoeven 2014-05-31 16:20 ` [Ocfs2-devel] " Geert Uytterhoeven 2014-05-31 16:20 ` Geert Uytterhoeven 2014-05-31 18:22 ` Richard Cochran 2014-05-31 18:22 ` [Cluster-devel] " Richard Cochran 2014-05-31 18:22 ` Richard Cochran 2014-05-31 18:22 ` [Ocfs2-devel] " Richard Cochran 2014-05-31 18:22 ` Richard Cochran 2014-05-31 18:22 ` Richard Cochran 2014-05-31 18:22 ` Richard Cochran 2014-05-31 19:34 ` H. Peter Anvin 2014-05-31 19:34 ` [Cluster-devel] " H. Peter Anvin 2014-05-31 19:34 ` H. Peter Anvin 2014-05-31 19:34 ` [Ocfs2-devel] " H. Peter Anvin 2014-05-31 19:34 ` H. Peter Anvin 2014-06-01 4:46 ` Richard Cochran 2014-06-01 4:46 ` [Cluster-devel] " Richard Cochran 2014-06-01 4:46 ` Richard Cochran 2014-06-01 4:46 ` [Ocfs2-devel] " Richard Cochran 2014-06-01 4:46 ` Richard Cochran 2014-06-01 4:44 ` Richard Cochran 2014-06-01 4:44 ` [Cluster-devel] " Richard Cochran 2014-06-01 4:44 ` Richard Cochran 2014-06-01 4:44 ` [Ocfs2-devel] " Richard Cochran 2014-06-01 4:44 ` Richard Cochran 2014-06-01 4:44 ` Richard Cochran 2014-06-02 13:52 ` Joseph S. Myers 2014-06-02 13:52 ` [Cluster-devel] " Joseph S. Myers 2014-06-02 13:52 ` Joseph S. Myers 2014-06-02 13:52 ` [Ocfs2-devel] " Joseph S. Myers 2014-06-02 13:52 ` Joseph S. Myers 2014-06-02 13:52 ` Joseph S. Myers 2014-06-02 13:52 ` Joseph S. Myers 2014-06-02 19:19 ` Arnd Bergmann 2014-06-02 19:19 ` [Cluster-devel] " Arnd Bergmann 2014-06-02 19:19 ` Arnd Bergmann 2014-06-02 19:19 ` [Ocfs2-devel] " Arnd Bergmann 2014-06-02 19:19 ` Arnd Bergmann 2014-06-02 19:19 ` Arnd Bergmann 2014-06-02 19:19 ` Arnd Bergmann 2014-06-02 19:26 ` H. Peter Anvin 2014-06-02 19:26 ` [Cluster-devel] " H. Peter Anvin 2014-06-02 19:26 ` H. Peter Anvin 2014-06-02 19:26 ` [Ocfs2-devel] " H. Peter Anvin 2014-06-02 19:26 ` H. Peter Anvin 2014-06-02 19:26 ` H. Peter Anvin 2014-06-02 19:55 ` Arnd Bergmann 2014-06-02 19:55 ` [Cluster-devel] " Arnd Bergmann 2014-06-02 19:55 ` Arnd Bergmann 2014-06-02 19:55 ` [Ocfs2-devel] " Arnd Bergmann 2014-06-02 19:55 ` Arnd Bergmann 2014-06-02 21:57 ` H. Peter Anvin 2014-06-02 21:57 ` [Cluster-devel] " H. Peter Anvin 2014-06-02 21:57 ` H. Peter Anvin 2014-06-02 21:57 ` [Ocfs2-devel] " H. Peter Anvin 2014-06-02 21:57 ` H. Peter Anvin 2014-06-02 21:57 ` H. Peter Anvin 2014-06-03 14:22 ` Arnd Bergmann 2014-06-03 14:22 ` [Cluster-devel] " Arnd Bergmann 2014-06-03 14:22 ` Arnd Bergmann 2014-06-03 14:22 ` [Ocfs2-devel] " Arnd Bergmann 2014-06-03 14:22 ` Arnd Bergmann 2014-06-03 14:22 ` Arnd Bergmann 2014-06-03 14:33 ` Joseph S. Myers 2014-06-03 14:33 ` [Cluster-devel] " Joseph S. Myers 2014-06-03 14:33 ` Joseph S. Myers 2014-06-03 14:33 ` [Ocfs2-devel] " Joseph S. Myers 2014-06-03 14:33 ` Joseph S. Myers 2014-06-03 14:33 ` Joseph S. Myers 2014-06-03 14:37 ` Arnd Bergmann 2014-06-03 14:37 ` [Cluster-devel] " Arnd Bergmann 2014-06-03 14:37 ` Arnd Bergmann 2014-06-03 14:37 ` [Ocfs2-devel] " Arnd Bergmann 2014-06-03 14:37 ` Arnd Bergmann 2014-06-03 14:37 ` Arnd Bergmann 2014-06-03 21:38 ` Dave Chinner 2014-06-03 21:38 ` [Cluster-devel] " Dave Chinner 2014-06-03 21:38 ` Dave Chinner 2014-06-03 21:38 ` [Ocfs2-devel] " Dave Chinner 2014-06-03 21:38 ` Dave Chinner 2014-06-03 21:38 ` Dave Chinner 2014-06-04 15:03 ` Arnd Bergmann 2014-06-04 15:03 ` [Cluster-devel] " Arnd Bergmann 2014-06-04 15:03 ` Arnd Bergmann 2014-06-04 15:03 ` [Ocfs2-devel] " Arnd Bergmann 2014-06-04 15:03 ` Arnd Bergmann 2014-06-04 15:03 ` Arnd Bergmann 2014-06-04 17:30 ` Nicolas Pitre 2014-06-04 17:30 ` [Cluster-devel] " Nicolas Pitre 2014-06-04 17:30 ` Nicolas Pitre 2014-06-04 17:30 ` [Ocfs2-devel] " Nicolas Pitre 2014-06-04 17:30 ` Nicolas Pitre 2014-06-04 17:30 ` Nicolas Pitre 2014-06-04 19:24 ` Arnd Bergmann 2014-06-04 19:24 ` [Cluster-devel] " Arnd Bergmann 2014-06-04 19:24 ` Arnd Bergmann 2014-06-04 19:24 ` [Ocfs2-devel] " Arnd Bergmann 2014-06-04 19:24 ` Arnd Bergmann 2014-06-04 19:24 ` Arnd Bergmann 2014-06-05 0:10 ` H. Peter Anvin 2014-06-05 0:10 ` [Cluster-devel] " H. Peter Anvin 2014-06-05 0:10 ` H. Peter Anvin 2014-06-05 0:10 ` [Ocfs2-devel] " H. Peter Anvin 2014-06-05 0:10 ` H. Peter Anvin 2014-06-05 0:10 ` H. Peter Anvin 2014-06-10 9:54 ` Arnd Bergmann 2014-06-10 9:54 ` [Cluster-devel] " Arnd Bergmann 2014-06-10 9:54 ` Arnd Bergmann 2014-06-10 9:54 ` [Ocfs2-devel] " Arnd Bergmann 2014-06-10 9:54 ` Arnd Bergmann 2014-06-10 9:54 ` Arnd Bergmann 2014-06-02 21:02 ` Joseph S. Myers 2014-06-02 21:02 ` [Cluster-devel] " Joseph S. Myers 2014-06-02 21:02 ` Joseph S. Myers 2014-06-02 21:02 ` [Ocfs2-devel] " Joseph S. Myers 2014-06-02 21:02 ` Joseph S. Myers 2014-06-02 21:02 ` Joseph S. Myers 2014-06-02 21:02 ` Joseph S. Myers 2014-06-04 15:05 ` Arnd Bergmann 2014-06-04 15:05 ` [Cluster-devel] " Arnd Bergmann 2014-06-04 15:05 ` Arnd Bergmann 2014-06-04 15:05 ` [Ocfs2-devel] " Arnd Bergmann 2014-06-04 15:05 ` Arnd Bergmann 2014-06-04 15:05 ` Arnd Bergmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5507340.nVBP5LFtqn@wuerfel \ --to=arnd@arndb.de \ --cc=david@fromorbit.com \ --cc=geert@linux-m68k.org \ --cc=hch@infradead.org \ --cc=hpa@zytor.com \ --cc=john.stultz@linaro.org \ --cc=joseph@codesourcery.com \ --cc=lftan@altera.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=tglx@linutronix.de \ --cc=xfs@oss.sgi.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.