Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Jacob Macneal <jake.macneal@gmail.com>,
        linux-kernel@vger.kernel.org
Cc:     jake.macneal@gmail.com, John Stultz <jstultz@google.com>,
        Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH] time: copy tai value (International Atomic Time, in
 seconds) to output __user struct in get_old_timex32().
In-Reply-To: <20221121055345.111567-1-jake.macneal@gmail.com>
References: <20221121055345.111567-1-jake.macneal@gmail.com>
Date:   Thu, 01 Dec 2022 14:47:46 +0100
Message-ID: <877czbs0al.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Jacob!

On Mon, Nov 21 2022 at 00:53, Jacob Macneal wrote:
> Previously, this value was not copied into the output struct.

Previously has no meaning here.

> This is despite all other fields of the corresponding __kernel_timex
> struct being copied to the old_timex32 __user struct in this function.

This is completely backwards. get_old_timex32() copies from the user
supplied old_timex32 struct to the __kernel_timex struct, no?

> Additionally, the matching function put_old_timex32() expects a tai
> value to be supplied, and copies it appropriately. It would appear to
> be a mistake that this value was never copied over in
> get_old_timex32().

Sure, but the important point is that txc->tai is never used as input
from userspace. It's only ever used as output to userspace, which
explains why this never caused any functional issue.

I'm not against this change per se, but the justification for it really
boils down to:

      Make it consistent with the regular syscall

Thanks,

        tglx