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.
> I'm
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.
> I'm
> 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 lif
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.
> T
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
