From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FE9A190046; Tue, 10 Sep 2024 15:48:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725983285; cv=none; b=TfXjlH9VnxbgfrWV9q+TrEzFmqiHRalaDH4IrUOKW6jPMEi/eMmG1B/6YHnXHF77VMqYnxOtx+Y8rhfmm0UYKSJrjHei7nN/xv+Nn3f/btEemjYE510aR8EqaEV84wtvddiZLUzwc/JOaYyqbwTE3QWsJ1scUDyxHVtD7mSrM0E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725983285; c=relaxed/simple; bh=ShuX06qSymKQunBMk30eNESrrW3YZ/yxxr9pbVRfEYo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=a6aUW5U+9g0aUC30wqNt2vKJrukAr4b6PT9Tsi68tH273HebSNbrgHxqpntDSm9UGNTnGsedfMUfpgAOQpDn7J+6Flg/d5/Pwws4LNW71C/6oSPBQxU3EjzceRdrKX6HgXOUg/oXuoGB0kOpJlgATh4UgzXIh5/SrfaA/wyTVI8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=2/hUACql; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=5ZanlrMa; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="2/hUACql"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="5ZanlrMa" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1725983282; 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=SpAW1KO7SPjGxiD5ZFFTluIX7AWVdKtbH+RQpSycHwg=; b=2/hUACqlNzUe2wkoG8sjKAuZbwsOzFw+6kEmlP6SzgBOEOSZh4LejWpw7S1VrpLeOf4gVd nj8pnv42tEFtC53xNbAks7cs/aEtIeuAbmYtQTjMGMDWs+81s/ddAkXl2AWXJV/p8lJp7/ GsDGhoxknnFaSiM9WU5YufZ8XO72CDRxBFAumZmbIwOs8+qLbg5BcDjIINr7Qycxw4ahW2 XnRQ6XvkZkcR4QW0xoOmnOBozVkswKs3z0ibbzxyPl39Yn5c6llHIFSyQgppkUTM8kzyud UDctPPn5Yd9w2cx9PoTtWqBjgbMFjH07+eqhGiFPh/Jy/MzaNniTbHIdKoT7KQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1725983282; 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=SpAW1KO7SPjGxiD5ZFFTluIX7AWVdKtbH+RQpSycHwg=; b=5ZanlrMabloM0VSftqTeiAtQRaYdDEo61S6iNhba3dQXZPpAx6lDJdMOjhE/rmyJLiyXvG 1XKA3ItEnmtMX+Ag== To: Jinjie Ruan , Richard Cochran Cc: bryan.whitehead@microchip.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, anna-maria@linutronix.de, frederic@kernel.org, UNGLinuxDriver@microchip.com, mbenes@suse.cz, jstultz@google.com, andrew@lunn.ch, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -next v3 1/2] posix-timers: Check timespec64 before call clock_set() In-Reply-To: <1cae2765-65cc-7dc5-8321-76c8b7ef1b8c@huawei.com> References: <20240909074124.964907-1-ruanjinjie@huawei.com> <20240909074124.964907-2-ruanjinjie@huawei.com> <875xr3btou.ffs@tglx> <1cae2765-65cc-7dc5-8321-76c8b7ef1b8c@huawei.com> Date: Tue, 10 Sep 2024 17:48:02 +0200 Message-ID: <87r09ra4st.ffs@tglx> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Sep 10 2024 at 20:30, Jinjie Ruan wrote: > On 2024/9/10 20:05, Thomas Gleixner wrote: >> Can you please stop this handwaving and provide proper technical >> arguments? >> >> Why would PTP have less strict requirements than settimeofday()? > > I checked all the PTP driver, most of them use timespec64_to_ns() > convert them to ns which already have a check, but the others not check > them, and lan743x_ptp check them differently and more, so i think this > is a minimum check. It does not matter at all what the PTP drivers do. What matters is what is correct and what not. What they do is actually wrong as they simply cut off an overly large value instead of rejecting it in the first place. That's not a check at all. The cutoff in timespec64_to_ns() is there to saturate the result instead of running into a multiplication overflow. That's correct for some use cases, but not a replacement for an actual useful range check. This is about correctness and correctness is not defined by what a bunch of drivers implement which are all a big copy & pasta orgy. Thanks, tglx