Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-15 Thread Arnd Bergmann
On Sat, Apr 8, 2017 at 5:58 PM, Deepa Dinamani wrote: >> I have no problem merging this patch into audit/next for v4.12, would >> you prefer me to do that so at least this patch is merged? > > This would be fine. > But, I think whoever takes the last 2 deletion patches

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-15 Thread Arnd Bergmann
On Sat, Apr 8, 2017 at 5:58 PM, Deepa Dinamani wrote: >> I have no problem merging this patch into audit/next for v4.12, would >> you prefer me to do that so at least this patch is merged? > > This would be fine. > But, I think whoever takes the last 2 deletion patches should also take them. >

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-11 Thread Paul Moore
On Sat, Apr 8, 2017 at 1:58 PM, Deepa Dinamani wrote: >> I have no problem merging this patch into audit/next for v4.12, would >> you prefer me to do that so at least this patch is merged? > > This would be fine. > But, I think whoever takes the last 2 deletion patches

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-11 Thread Paul Moore
On Sat, Apr 8, 2017 at 1:58 PM, Deepa Dinamani wrote: >> I have no problem merging this patch into audit/next for v4.12, would >> you prefer me to do that so at least this patch is merged? > > This would be fine. > But, I think whoever takes the last 2 deletion patches should also take them. >

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-08 Thread Deepa Dinamani
> I have no problem merging this patch into audit/next for v4.12, would > you prefer me to do that so at least this patch is merged? This would be fine. But, I think whoever takes the last 2 deletion patches should also take them. I'm not sure how that part works out. > It would probably make

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-08 Thread Deepa Dinamani
> I have no problem merging this patch into audit/next for v4.12, would > you prefer me to do that so at least this patch is merged? This would be fine. But, I think whoever takes the last 2 deletion patches should also take them. I'm not sure how that part works out. > It would probably make

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-08 Thread Paul Moore
On Fri, Apr 7, 2017 at 8:57 PM, Deepa Dinamani wrote: > struct timespec is not y2038 safe. > Audit timestamps are recorded in string format into > an audit buffer for a given context. > These mark the entry timestamps for the syscalls. > Use y2038 safe struct timespec64 to

Re: [PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-08 Thread Paul Moore
On Fri, Apr 7, 2017 at 8:57 PM, Deepa Dinamani wrote: > struct timespec is not y2038 safe. > Audit timestamps are recorded in string format into > an audit buffer for a given context. > These mark the entry timestamps for the syscalls. > Use y2038 safe struct timespec64 to represent the times. >

[PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-07 Thread Deepa Dinamani
struct timespec is not y2038 safe. Audit timestamps are recorded in string format into an audit buffer for a given context. These mark the entry timestamps for the syscalls. Use y2038 safe struct timespec64 to represent the times. The log strings can handle this transition as strings can hold upto

[PATCH 06/12] audit: Use timespec64 to represent audit timestamps

2017-04-07 Thread Deepa Dinamani
struct timespec is not y2038 safe. Audit timestamps are recorded in string format into an audit buffer for a given context. These mark the entry timestamps for the syscalls. Use y2038 safe struct timespec64 to represent the times. The log strings can handle this transition as strings can hold upto