Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp22278956rwd; Fri, 30 Jun 2023 06:15:12 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7hIRGmV5Ujtz6n0mZtbxJfBYHA5PiCft078YO66wVgCZmEKyT5NkZT54Q9Y7ct9ucxjlfS X-Received: by 2002:a05:6a20:7d9a:b0:12b:d525:2cac with SMTP id v26-20020a056a207d9a00b0012bd5252cacmr3992231pzj.17.1688130912282; Fri, 30 Jun 2023 06:15:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688130912; cv=none; d=google.com; s=arc-20160816; b=TS5IRngldN6sR/z4ffBeVeA/BCShN6umJXFwazDBTjY8gFQlWcDG6CSk+XzArvDiU2 uJZ+lxo5v/pIsK9yl2OmVrnXiww4ADicuTnx1uCi8JaoSx8lw+3ZYsmUmwx36aG7tFbG U+trSUnd29G+Y8Y7Uvom5pWuAI8R37dUy4hGTsmsPtZfBcJJkoLA6EHsCdoeXgqVr/yL w6wVki84rp+EbKhnNfGmNmtgQM70/O14FVDuoxMARObzEEsbL5TunHziVbzg9SWWaGVo lZdTuuWJTwcAfULpa20cva1Y1aSy9Gj10GPaYDwDbfD8+zQ5/l5pU968nUMnkGzdbsxZ 5wBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:dkim-signature :dkim-signature:from; bh=j91/nF/TAtkgDhiwgLLKVItWTovmcF2c3HrZwokhsSA=; fh=7+BSne7+Nsu2Q4IouaoanoIP6ArVtkXIHqdpI0+dNj0=; b=EqWGOK3RJlItd99UPanIpKGZe9/BH6J7BE55K67C+igtnKSIq8BtQhwlGhmZl0nYh+ B72a9kZezEBDCSb9kcku4hV99MZfKRBuPekzjZXFQEEnti0Em7Fwc2jAHn7IGnhhn8ja 3KEIp2FQun21Fd9vzz9GkJZjVIo0+qoOa7lYXbEUQJvgkPBULV52nyoEgarP/SjRudyD mb9TY61EV24yrHqAtGiC/dzfYkm+nA8yftdAX4vH3VNUhYX2z4ItiPOYFWRaDR8mTwED BTqgowrjcDWdkFe5IoLMJnwYxym5Oq7WgSRHR/1H6q9+REjXK8TWhs5UXcYbP2GGTcCP sMrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=aYAGYNYp; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b="6vr/4y85"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v10-20020a63610a000000b00553ebb05d16si2421674pgb.12.2023.06.30.06.14.59; Fri, 30 Jun 2023 06:15:12 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=aYAGYNYp; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b="6vr/4y85"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232245AbjF3NHX (ORCPT + 99 others); Fri, 30 Jun 2023 09:07:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231361AbjF3NHV (ORCPT ); Fri, 30 Jun 2023 09:07:21 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB2D4E6A for ; Fri, 30 Jun 2023 06:07:19 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1688130438; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j91/nF/TAtkgDhiwgLLKVItWTovmcF2c3HrZwokhsSA=; b=aYAGYNYpmmwN4K7BMvslpndDJW+uXfah720i49QjPMQZXzTjUmyVMgrbKj7wlcLCzdAFa/ qlIvw21V9/i0zi4oFa2GpUQE2fCPrCgBT7C4uH7C1U0GMvj+Xd7hQpBOv+jYrHRUTP7YFY 22SYmlYJiNVkcgbEq23N3RDcXRRfWG3bTNihuZDV+WIOm1H/jaQ+gdu2NV7JCK/VKBCLy+ 0NGKm5ESsvlM1LYW1h1CVst/Cimv7g/FtaDnWJBvB6KvM3j+ByK3xfLr+dNXFz9MPdJ7R+ l1rtxYcrh3fhx2puneOyGLcL0h0db8Q9JxAW6XKsSMC8f/0AoOCAGCnfUEoAsA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1688130438; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j91/nF/TAtkgDhiwgLLKVItWTovmcF2c3HrZwokhsSA=; b=6vr/4y85cJ0n6Wmu5PtlyffGAZmQPZtgrumXUfykp0OkSdn7MIeYQRJPLSd9aQ4rqQVgTw G3Eq+6LMWT/gCTCA== To: Frederic Weisbecker Cc: LKML , Anna-Maria Behnsen , John Stultz , Peter Zijlstra , Ingo Molnar , Stephen Boyd , Eric Biederman , Oleg Nesterov Subject: Re: [patch 14/45] posix-timers: Consolidate interval retrieval In-Reply-To: References: <20230606132949.068951363@linutronix.de> <20230606142031.816970056@linutronix.de> <87ttuq14xp.ffs@tglx> Date: Fri, 30 Jun 2023 15:07:17 +0200 Message-ID: <875y75yu7u.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 30 2023 at 13:25, Frederic Weisbecker wrote: > On Thu, Jun 29, 2023 at 08:47:30PM +0200, Thomas Gleixner wrote: >> On Wed, Jun 28 2023 at 15:08, Frederic Weisbecker wrote: >>=20 >> > Le Tue, Jun 06, 2023 at 04:37:40PM +0200, Thomas Gleixner a =C3=A9crit= : >> >> There is no point to collect the current interval in the posix clock >> >> specific settime() and gettime() callbacks. Just do it right in the c= ommon >> >> code. >> >>=20 >> >> Signed-off-by: Thomas Gleixner >> > >> > The only difference I see is that we now return the old interval >> > even if the target is reaped, which probably doesn't matter anyway. >>=20 >> But we don't return it to user space because ret !=3D 0 in that case. > > In the case of ->set yes but in the case of ->get there is no error > handling. SYSCALL_DEFINE2(timer_gettime, timer_t, timer_id, struct __kernel_itimerspec __user *, setting) { struct itimerspec64 cur_setting; int ret =3D do_timer_gettime(timer_id, &cur_setting); if (!ret) { if (put_itimerspec64(&cur_setting, setting)) How exactly does this end up being copied to user space if ret !=3D 0? Thanks, tglx