From: "Yan, Zheng" <ukernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>,
John Stultz <john.stultz@linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Al Viro <viro@zeniv.linux.org.uk>,
gregkh <gregkh@linuxfoundation.org>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Chris Mason <clm@fb.com>, David Miller <davem@davemloft.net>,
David Sterba <dsterba@suse.com>,
Evgeniy Dushistov <dushistov@mail.ru>,
Eric Paris <eparis@redhat.com>, Jaegeuk Kim <jaegeuk@kernel.org>,
Josef Bacik <jbacik@fb.com>,
Jeff Layton <jlayton@poochiereds.net>,
James Simmons <jsimmons@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
"Drokin, Oleg" <oleg.drokin@intel.com>,
Paul Moore <paul@paul-moore.com>,
Steven Rostedt <rostedt@goodmis.org>,
yuchao0@huawei.com, ceph-devel <ceph-devel@vger.kernel.org>,
devel@driverdev.osuosl.org, linux-audit@redhat.com,
linux-btrfs <linux-btrfs@vger.kernel.org>,
linux-cifs@vger.kernel.org, "Linux F2FS DEV,
Mailing List" <linux-f2fs-devel@lists.sourceforge.net>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
linux-mtd <linux-mtd@lists.infradead.org>,
LSM List <linux-security-module@vger.kernel.org>,
Lustre Development List <lustre-devel@lists.lustre.org>,
Networking <netdev@vger.kernel.org>,
samba-technical@lists.samba.org,
y2038 Mailman List <y2038@lists.linaro.org>
Subject: Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
Date: Fri, 2 Jun 2017 19:18:53 +0800 [thread overview]
Message-ID: <CAAM7YAk8JNU=XV=sOCczagWjBimO4JSPU08th7E4u6FTJN--9A@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a0D3EXuwBj+sSVL9cmpysdvQWXnkE0zEctBJS8XOqhX7A@mail.gmail.com>
On Fri, Jun 2, 2017 at 6:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>
>>> I believe the bug you see is the result of the two timestamps
>>> currently being almost guaranteed to be different in the latest
>>> kernels.
>>> Changing r_stamp to use current_kernel_time() will make it the
>>> same value most of the time (as it was before Deepa's patch),
>>> but when the timer interrupt happens between the timestamps,
>>> the two are still different, it's just much harder to hit.
>>>
>>> I think the proper solution should be to change __ceph_setattr()
>>> in a way that has req->r_stamp always synchronized with i_ctime.
>>> If we copy i_ctime to r_stamp, that will also take care of the
>>> future issues with the planned changes to current_time().
>>>
>> I already have a patch
>> https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
>
> Looks good to me. In case anyone cares:
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
>>> The part I don't understand is what else r_stamp (i.e. the time
>>> stamp in ceph_msg_data with type==
>>> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
>>> ctime in CEPH_MDS_OP_SETATTR.
>>>
>>> Will this be used to update the stored i_ctime for other operations
>>> too? If so, we would need to synchronize it with the in-memory
>>> i_ctime for all operations that do this.
>>>
>>
>> yes, mds uses it to update ctime of modified inodes. For example,
>> when handling mkdir, mds set ctime of both parent inode and new inode
>> to r_stamp.
>
> I see, so we may have a variation of that problem there as well: From
> my reading of the code, the child inode is not in memory yet, so
> that seems fine, but I could not find where the parent in-memory inode
> i_ctime is updated in ceph, but it is most likely not the same as
> req->r_stamp (assuming it gets updated at all).
i_ctime is updated when handling request reply, by ceph_fill_file_time().
__ceph_setattr() can update the in-memory inode's ctime after request
reply is received. The difference between ktime_get_real_ts() and
current_time() can be larger than round-trip time of request. So it's
still possible that __ceph_setattr() make ctime go back.
Regards
Yan, Zheng
>
> Would it make sense require all callers of ceph_mdsc_do_request()
> to update r_stamp at the same time as i_ctime to keep them in sync?
>
> Arnd
WARNING: multiple messages have this Message-ID (diff)
From: "Yan, Zheng" <ukernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: yuchao0@huawei.com, "J. Bruce Fields" <bfields@fieldses.org>,
Chris Mason <clm@fb.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
Deepa Dinamani <deepa.kernel@gmail.com>,
Evgeniy Dushistov <dushistov@mail.ru>,
Jeff Layton <jlayton@poochiereds.net>,
ceph-devel <ceph-devel@vger.kernel.org>,
devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org,
Paul Moore <paul@paul-moore.com>,
y2038 Mailman List <y2038@lists.linaro.org>,
Ingo Molnar <mingo@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
"Drokin, Oleg" <oleg.drokin@intel.com>,
John Stultz <john.stultz@linaro.org>,
Al Viro <viro@zeniv.linux.org.uk>,
David Sterba <dsterba@suse.com>, Jaegeuk Kim <jaegeuk@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
Josef Bacik <jbacik@fb.com>, gregkh <gregkh@linuxfoundation.org>,
samba-technical@lists.samba.org, Linux Kernel Mailing List
Subject: Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
Date: Fri, 2 Jun 2017 19:18:53 +0800 [thread overview]
Message-ID: <CAAM7YAk8JNU=XV=sOCczagWjBimO4JSPU08th7E4u6FTJN--9A@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a0D3EXuwBj+sSVL9cmpysdvQWXnkE0zEctBJS8XOqhX7A@mail.gmail.com>
On Fri, Jun 2, 2017 at 6:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>
>>> I believe the bug you see is the result of the two timestamps
>>> currently being almost guaranteed to be different in the latest
>>> kernels.
>>> Changing r_stamp to use current_kernel_time() will make it the
>>> same value most of the time (as it was before Deepa's patch),
>>> but when the timer interrupt happens between the timestamps,
>>> the two are still different, it's just much harder to hit.
>>>
>>> I think the proper solution should be to change __ceph_setattr()
>>> in a way that has req->r_stamp always synchronized with i_ctime.
>>> If we copy i_ctime to r_stamp, that will also take care of the
>>> future issues with the planned changes to current_time().
>>>
>> I already have a patch
>> https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
>
> Looks good to me. In case anyone cares:
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
>>> The part I don't understand is what else r_stamp (i.e. the time
>>> stamp in ceph_msg_data with type==
>>> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
>>> ctime in CEPH_MDS_OP_SETATTR.
>>>
>>> Will this be used to update the stored i_ctime for other operations
>>> too? If so, we would need to synchronize it with the in-memory
>>> i_ctime for all operations that do this.
>>>
>>
>> yes, mds uses it to update ctime of modified inodes. For example,
>> when handling mkdir, mds set ctime of both parent inode and new inode
>> to r_stamp.
>
> I see, so we may have a variation of that problem there as well: From
> my reading of the code, the child inode is not in memory yet, so
> that seems fine, but I could not find where the parent in-memory inode
> i_ctime is updated in ceph, but it is most likely not the same as
> req->r_stamp (assuming it gets updated at all).
i_ctime is updated when handling request reply, by ceph_fill_file_time().
__ceph_setattr() can update the in-memory inode's ctime after request
reply is received. The difference between ktime_get_real_ts() and
current_time() can be larger than round-trip time of request. So it's
still possible that __ceph_setattr() make ctime go back.
Regards
Yan, Zheng
>
> Would it make sense require all callers of ceph_mdsc_do_request()
> to update r_stamp at the same time as i_ctime to keep them in sync?
>
> Arnd
WARNING: multiple messages have this Message-ID (diff)
From: ukernel@gmail.com (Yan, Zheng)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
Date: Fri, 2 Jun 2017 19:18:53 +0800 [thread overview]
Message-ID: <CAAM7YAk8JNU=XV=sOCczagWjBimO4JSPU08th7E4u6FTJN--9A@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a0D3EXuwBj+sSVL9cmpysdvQWXnkE0zEctBJS8XOqhX7A@mail.gmail.com>
On Fri, Jun 2, 2017 at 6:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>
>>> I believe the bug you see is the result of the two timestamps
>>> currently being almost guaranteed to be different in the latest
>>> kernels.
>>> Changing r_stamp to use current_kernel_time() will make it the
>>> same value most of the time (as it was before Deepa's patch),
>>> but when the timer interrupt happens between the timestamps,
>>> the two are still different, it's just much harder to hit.
>>>
>>> I think the proper solution should be to change __ceph_setattr()
>>> in a way that has req->r_stamp always synchronized with i_ctime.
>>> If we copy i_ctime to r_stamp, that will also take care of the
>>> future issues with the planned changes to current_time().
>>>
>> I already have a patch
>> https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
>
> Looks good to me. In case anyone cares:
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
>>> The part I don't understand is what else r_stamp (i.e. the time
>>> stamp in ceph_msg_data with type==
>>> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
>>> ctime in CEPH_MDS_OP_SETATTR.
>>>
>>> Will this be used to update the stored i_ctime for other operations
>>> too? If so, we would need to synchronize it with the in-memory
>>> i_ctime for all operations that do this.
>>>
>>
>> yes, mds uses it to update ctime of modified inodes. For example,
>> when handling mkdir, mds set ctime of both parent inode and new inode
>> to r_stamp.
>
> I see, so we may have a variation of that problem there as well: From
> my reading of the code, the child inode is not in memory yet, so
> that seems fine, but I could not find where the parent in-memory inode
> i_ctime is updated in ceph, but it is most likely not the same as
> req->r_stamp (assuming it gets updated at all).
i_ctime is updated when handling request reply, by ceph_fill_file_time().
__ceph_setattr() can update the in-memory inode's ctime after request
reply is received. The difference between ktime_get_real_ts() and
current_time() can be larger than round-trip time of request. So it's
still possible that __ceph_setattr() make ctime go back.
Regards
Yan, Zheng
>
> Would it make sense require all callers of ceph_mdsc_do_request()
> to update r_stamp at the same time as i_ctime to keep them in sync?
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "Yan, Zheng" <ukernel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: yuchao0@huawei.com, "J. Bruce Fields" <bfields@fieldses.org>,
Chris Mason <clm@fb.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
Deepa Dinamani <deepa.kernel@gmail.com>,
Evgeniy Dushistov <dushistov@mail.ru>,
Jeff Layton <jlayton@poochiereds.net>,
ceph-devel <ceph-devel@vger.kernel.org>,
devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org,
Paul Moore <paul@paul-moore.com>,
y2038 Mailman List <y2038@lists.linaro.org>,
Ingo Molnar <mingo@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
"Drokin, Oleg" <oleg.drokin@intel.com>,
John Stultz <john.stultz@linaro.org>,
Al Viro <viro@zeniv.linux.org.uk>,
David Sterba <dsterba@suse.com>, Jaegeuk Kim <jaegeuk@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
Josef Bacik <jbacik@fb.com>, gregkh <gregkh@linuxfoundation.org>,
samba-technical@lists.samba.org, Linux
Subject: Re: [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()
Date: Fri, 2 Jun 2017 19:18:53 +0800 [thread overview]
Message-ID: <CAAM7YAk8JNU=XV=sOCczagWjBimO4JSPU08th7E4u6FTJN--9A@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a0D3EXuwBj+sSVL9cmpysdvQWXnkE0zEctBJS8XOqhX7A@mail.gmail.com>
On Fri, Jun 2, 2017 at 6:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jun 2, 2017 at 12:10 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 5:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Fri, Jun 2, 2017 at 4:09 AM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>> On Fri, Jun 2, 2017 at 8:57 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>>>> On Thu, Jun 1, 2017 at 5:36 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>>>> On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng <ukernel@gmail.com> wrote:
>>>
>>> I believe the bug you see is the result of the two timestamps
>>> currently being almost guaranteed to be different in the latest
>>> kernels.
>>> Changing r_stamp to use current_kernel_time() will make it the
>>> same value most of the time (as it was before Deepa's patch),
>>> but when the timer interrupt happens between the timestamps,
>>> the two are still different, it's just much harder to hit.
>>>
>>> I think the proper solution should be to change __ceph_setattr()
>>> in a way that has req->r_stamp always synchronized with i_ctime.
>>> If we copy i_ctime to r_stamp, that will also take care of the
>>> future issues with the planned changes to current_time().
>>>
>> I already have a patch
>> https://github.com/ceph/ceph-client/commit/24f54cd18e195a002ee3d2ab50dbc952fd9f82af
>
> Looks good to me. In case anyone cares:
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
>>> The part I don't understand is what else r_stamp (i.e. the time
>>> stamp in ceph_msg_data with type==
>>> CEPH_MSG_CLIENT_REQUEST) is used for, other than setting
>>> ctime in CEPH_MDS_OP_SETATTR.
>>>
>>> Will this be used to update the stored i_ctime for other operations
>>> too? If so, we would need to synchronize it with the in-memory
>>> i_ctime for all operations that do this.
>>>
>>
>> yes, mds uses it to update ctime of modified inodes. For example,
>> when handling mkdir, mds set ctime of both parent inode and new inode
>> to r_stamp.
>
> I see, so we may have a variation of that problem there as well: From
> my reading of the code, the child inode is not in memory yet, so
> that seems fine, but I could not find where the parent in-memory inode
> i_ctime is updated in ceph, but it is most likely not the same as
> req->r_stamp (assuming it gets updated at all).
i_ctime is updated when handling request reply, by ceph_fill_file_time().
__ceph_setattr() can update the in-memory inode's ctime after request
reply is received. The difference between ktime_get_real_ts() and
current_time() can be larger than round-trip time of request. So it's
still possible that __ceph_setattr() make ctime go back.
Regards
Yan, Zheng
>
> Would it make sense require all callers of ceph_mdsc_do_request()
> to update r_stamp at the same time as i_ctime to keep them in sync?
>
> Arnd
next prev parent reply other threads:[~2017-06-02 11:18 UTC|newest]
Thread overview: 166+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-08 0:56 [PATCH 00/12] Delete CURRENT_TIME, CURRENT_TIME_SEC and current_fs_time Deepa Dinamani
2017-04-08 0:56 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:56 ` Deepa Dinamani
2017-04-08 0:56 ` Deepa Dinamani
2017-04-08 0:56 ` [PATCH 01/12] fs: f2fs: Use ktime_get_real_seconds for sit_info times Deepa Dinamani
2017-04-08 0:56 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:56 ` Deepa Dinamani
2017-04-08 0:56 ` Deepa Dinamani
2017-04-08 0:57 ` [PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 1:30 ` Steven Rostedt
2017-04-08 1:30 ` Steven Rostedt
2017-04-08 1:30 ` Steven Rostedt
2017-04-08 2:16 ` Deepa Dinamani
2017-04-08 2:16 ` [lustre-devel] " Deepa Dinamani
2017-04-08 2:16 ` Deepa Dinamani
2017-04-08 2:16 ` Deepa Dinamani
2017-04-08 2:16 ` Deepa Dinamani
2017-04-08 2:16 ` Deepa Dinamani
2017-04-08 0:57 ` [PATCH 03/12] fs: cifs: Replace CURRENT_TIME by other appropriate apis Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` [PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts() Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-06-01 9:56 ` Yan, Zheng
2017-06-01 9:56 ` Yan, Zheng
2017-06-01 9:56 ` Yan, Zheng
2017-06-01 10:22 ` Arnd Bergmann
2017-06-01 10:22 ` [lustre-devel] " Arnd Bergmann
2017-06-01 10:22 ` Arnd Bergmann
2017-06-01 10:22 ` Arnd Bergmann
2017-06-01 10:22 ` Arnd Bergmann
2017-06-01 10:22 ` Arnd Bergmann
2017-06-02 0:26 ` Yan, Zheng
2017-06-02 0:26 ` Yan, Zheng
2017-06-02 0:26 ` Yan, Zheng
2017-06-02 0:26 ` Yan, Zheng
2017-06-02 0:26 ` Yan, Zheng
2017-06-02 0:36 ` John Stultz
2017-06-02 0:36 ` John Stultz
2017-06-02 0:36 ` John Stultz
2017-06-02 0:36 ` John Stultz
2017-06-02 0:36 ` John Stultz
2017-06-02 0:36 ` John Stultz
2017-06-02 0:57 ` Deepa Dinamani
2017-06-02 0:57 ` [lustre-devel] " Deepa Dinamani
2017-06-02 0:57 ` Deepa Dinamani
2017-06-02 0:57 ` Deepa Dinamani
2017-06-02 0:57 ` Deepa Dinamani
2017-06-02 0:57 ` Deepa Dinamani
2017-06-02 2:09 ` Yan, Zheng
2017-06-02 2:09 ` Yan, Zheng
2017-06-02 2:09 ` Yan, Zheng
2017-06-02 2:09 ` Yan, Zheng
2017-06-02 9:45 ` Arnd Bergmann
2017-06-02 9:45 ` [lustre-devel] " Arnd Bergmann
2017-06-02 9:45 ` Arnd Bergmann
2017-06-02 9:45 ` Arnd Bergmann
2017-06-02 9:45 ` Arnd Bergmann
2017-06-02 9:45 ` Arnd Bergmann
2017-06-02 10:10 ` Yan, Zheng
2017-06-02 10:10 ` Yan, Zheng
2017-06-02 10:10 ` Yan, Zheng
2017-06-02 10:10 ` Yan, Zheng
2017-06-02 10:10 ` Yan, Zheng
2017-06-02 10:51 ` Arnd Bergmann
2017-06-02 10:51 ` [lustre-devel] " Arnd Bergmann
2017-06-02 10:51 ` Arnd Bergmann
2017-06-02 10:51 ` Arnd Bergmann
2017-06-02 10:51 ` Arnd Bergmann
2017-06-02 10:51 ` Arnd Bergmann
2017-06-02 11:18 ` Yan, Zheng [this message]
2017-06-02 11:18 ` Yan, Zheng
2017-06-02 11:18 ` Yan, Zheng
2017-06-02 11:18 ` Yan, Zheng
2017-06-02 11:18 ` Yan, Zheng
2017-06-02 11:33 ` Arnd Bergmann
2017-06-02 11:33 ` [lustre-devel] " Arnd Bergmann
2017-06-02 11:33 ` Arnd Bergmann
2017-06-02 11:33 ` Arnd Bergmann
2017-06-02 11:33 ` Arnd Bergmann
2017-06-02 11:33 ` Arnd Bergmann
2017-06-02 12:18 ` Yan, Zheng
2017-06-02 12:18 ` Yan, Zheng
2017-06-02 12:18 ` Yan, Zheng
2017-06-02 12:18 ` Yan, Zheng
2017-06-02 12:18 ` Yan, Zheng
2017-06-02 14:18 ` Arnd Bergmann
2017-06-02 14:18 ` [lustre-devel] " Arnd Bergmann
2017-06-02 14:18 ` Arnd Bergmann
2017-06-02 14:18 ` Arnd Bergmann
2017-06-02 14:18 ` Arnd Bergmann
2017-06-02 14:18 ` Arnd Bergmann
2017-06-04 7:54 ` Yan, Zheng
2017-06-04 7:54 ` Yan, Zheng
2017-06-04 7:54 ` Yan, Zheng
2017-06-04 7:54 ` Yan, Zheng
2017-06-04 7:54 ` Yan, Zheng
2017-06-02 0:35 ` Yan, Zheng
2017-06-02 0:35 ` Yan, Zheng
2017-06-02 0:35 ` Yan, Zheng
2017-06-02 0:35 ` Yan, Zheng
2017-06-02 0:35 ` Yan, Zheng
2017-04-08 0:57 ` [PATCH 05/12] fs: ufs: Use ktime_get_real_ts64() for birthtime Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` [PATCH 06/12] audit: Use timespec64 to represent audit timestamps Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 12:40 ` Paul Moore
2017-04-08 12:40 ` Paul Moore
2017-04-08 12:40 ` Paul Moore
2017-04-08 17:58 ` Deepa Dinamani
2017-04-08 17:58 ` [lustre-devel] " Deepa Dinamani
2017-04-08 17:58 ` Deepa Dinamani
2017-04-08 17:58 ` Deepa Dinamani
2017-04-08 17:58 ` Deepa Dinamani
2017-04-08 17:58 ` Deepa Dinamani
2017-04-11 20:12 ` Paul Moore
2017-04-11 20:12 ` Paul Moore
2017-04-11 20:12 ` Paul Moore
2017-04-11 20:12 ` Paul Moore
2017-04-11 20:12 ` Paul Moore
2017-04-15 10:29 ` Arnd Bergmann
2017-04-15 10:29 ` [lustre-devel] " Arnd Bergmann
2017-04-15 10:29 ` Arnd Bergmann
2017-04-15 10:29 ` Arnd Bergmann
2017-04-15 10:29 ` Arnd Bergmann
2017-04-08 0:57 ` [PATCH 07/12] fs: btrfs: Use ktime_get_real_ts for root ctime Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-12 13:42 ` David Sterba
2017-04-12 13:42 ` [lustre-devel] " David Sterba
2017-04-12 13:42 ` David Sterba
2017-04-12 13:42 ` David Sterba
2017-04-08 0:57 ` [PATCH 08/12] fs: ubifs: Replace CURRENT_TIME_SEC with current_time Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` [PATCH 09/12] lustre: Replace CURRENT_TIME macro Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` [PATCH 10/12] apparmorfs: Replace CURRENT_TIME with current_time() Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-06-02 7:29 ` John Johansen
2017-06-02 7:29 ` John Johansen
2017-06-02 7:29 ` John Johansen
2017-04-08 0:57 ` [PATCH 11/12] time: Delete CURRENT_TIME_SEC and CURRENT_TIME Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` [PATCH 12/12] time: Delete current_fs_time() function Deepa Dinamani
2017-04-08 0:57 ` [lustre-devel] " Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
2017-04-08 0:57 ` Deepa Dinamani
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='CAAM7YAk8JNU=XV=sOCczagWjBimO4JSPU08th7E4u6FTJN--9A@mail.gmail.com' \
--to=ukernel@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andreas.dilger@intel.com \
--cc=arnd@arndb.de \
--cc=bfields@fieldses.org \
--cc=ceph-devel@vger.kernel.org \
--cc=clm@fb.com \
--cc=davem@davemloft.net \
--cc=deepa.kernel@gmail.com \
--cc=devel@driverdev.osuosl.org \
--cc=dsterba@suse.com \
--cc=dushistov@mail.ru \
--cc=eparis@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jaegeuk@kernel.org \
--cc=jbacik@fb.com \
--cc=jlayton@poochiereds.net \
--cc=john.stultz@linaro.org \
--cc=jsimmons@infradead.org \
--cc=linux-audit@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=oleg.drokin@intel.com \
--cc=paul@paul-moore.com \
--cc=rostedt@goodmis.org \
--cc=samba-technical@lists.samba.org \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=y2038@lists.linaro.org \
--cc=yuchao0@huawei.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: link
Be 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.