From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56D7BC43217 for ; Thu, 1 Dec 2022 15:18:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231509AbiLAPSc (ORCPT ); Thu, 1 Dec 2022 10:18:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230143AbiLAPS3 (ORCPT ); Thu, 1 Dec 2022 10:18:29 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD959A47E4 for ; Thu, 1 Dec 2022 07:18:28 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669907907; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SrY7hzYfEOK2q/hdFn3ec4v1Q9N6ZIdTKpdo+YTUPKo=; b=RbknPhJBPVpMo1//GiCZjwdQyCkwD0stL5GKaoffCL8JRnSH5hht8sb0rsMvY0VeBd9Mld YIQ8vsB5XUfR6eViBeq9W+7+TfW6j5gN7Ry7WiOzl2bqxXLVIgtQBzTjpTuc2K4ExKc6wL C+bLyiGLoBmHf56QZWMjSZlha0aFPQu6mMCE7c0V6OOD31t+AHgI+MC/aNSviKQDkJCtKN f9EAysLK6DFEXt8inuXRRHui+7K5EQG1Z/eO+epyjy6sBuT3LiugmM9IaAtZJAB4PwJP16 QzauIN+7dJjgeGHLxTVvmS7a1ITTCOUlzxjdo1nSXIo6bv6GSuV8a3QCCcycug== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669907907; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SrY7hzYfEOK2q/hdFn3ec4v1Q9N6ZIdTKpdo+YTUPKo=; b=CQKEg9q1ssDtf5cTVF2u8o281141q5m9o2muF6ytphftb3OzXscPMnTD+XGbAIj6zycKXS uMxy06J1nsP4XBBQ== To: Jake Macneal Cc: linux-kernel@vger.kernel.org, John Stultz , Stephen Boyd , arnd@arndb.de Subject: Re: [PATCH] time: copy tai value (International Atomic Time, in seconds) to output __user struct in get_old_timex32(). In-Reply-To: References: <20221121055345.111567-1-jake.macneal@gmail.com> <877czbs0al.ffs@tglx> Date: Thu, 01 Dec 2022 16:18:26 +0100 Message-ID: <87y1rrqhj1.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jake, On Thu, Dec 01 2022 at 10:00, Jake Macneal wrote: >>> 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? > > You're totally right, I managed to mix up the order right off the bat. > >> I'm not against this change per se, but the justification for it really >> boils down to: > >> Make it consistent with the regular syscall > > I agree, that's a better summary. There isn't any effect in the kernel > now due to get_old_timex32() ignoring the tai value from userspace. So > this patch would be purely aesthetic, although one might argue that > copying the userspace tai value into txc is also less likely to lead > to a bug in the future, were any of the functions do_adjtimex(), > __do_adjtimex(), or process_adjtimex_modes() to be changed in a way so > that the userspace tai value became used (I realize this is unlikely). Right. Unlikely or not, consistency is always a good thing. > I apologize for any confusion I caused. No problem. Been there, done that :) Thanks, tglx