Message ID | 20231014181333.2579530-1-vamshigajjela@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp2608038vqb; Sat, 14 Oct 2023 11:14:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG3qoAco3snzDA6kex8ehP4ZZ9sOTtH91W9JokFMIkOOWtMq0BIe3IKky7UzEwgk3ETm/yT X-Received: by 2002:a05:6870:2e09:b0:1e9:95c8:e15d with SMTP id oi9-20020a0568702e0900b001e995c8e15dmr11723261oab.1.1697307273967; Sat, 14 Oct 2023 11:14:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697307273; cv=none; d=google.com; s=arc-20160816; b=udUkwQmeJ7/b7/SU6aRlMmMsW3HKNooZ/0j7wMKXJ5oxxEqZAS2ma3+aglhguFm2NN 7olzrGXA6NIcynyfRRPMrR4q32K5LJbHAbDWNVlslLgJnQn6yTbcRZ6yh2hRqWBcE5kO lu+8kvIvcQfYDDVc1a7iYxivlgP21rDYKX7VAcYJHX8YSaBQMYBig9tYT27naJ7thYFR eTOuIezYT4OXyB4wwBqZg9SlABVHt8G/yCG0I1CMN0Sg42ybpx9OscUZBAcBkjWDREs2 rqIEohiM+pSZdXyzyEcD9QPPSrhjRECWk582sttAdEf9r4NfP8RPoXELX+Iw1KIMzp0b zaUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=rKyrhxaGZv0nPLnMXbvJXkiVEGuU/Lq6wP9rgM/Alfg=; fh=4iPUH3SCaUeHRPwZInlqPLZI8cmh/b74OgcORLvvuVM=; b=QB0Wp2CPNnJOFbZwbDLV4piGXXJI/lq1E7ifJblHmEkGbNdVIKbO3IrQ9R26S2zApW deLCW+7LwvVIe/gNr4J1iLUgIb/2hzt7L+tELPlcAZrNrgDeuR/ATV0J8o69aj10dvzW Q4qEertq9pYpiAO39wDvCc4M+1CTKSSFNmZRatUJslwn/FI7nxeEQtTZhqaIWE9NO7O5 UztQjTptAf+MKbJmM/GrNSn3OfsVF96Uxyh2EUnMDjN/ZUq1iprTThYulplSOw2iTDh9 rYFY2MT+SUkb5zntyGhBy71K1ybij51OrstGGWofSaqThzvvyeN5Mw+CYBRpKMjoCzmF 9IWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b="u/yYNOoj"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id b127-20020a636785000000b00580e32f778csi6972557pgc.506.2023.10.14.11.14.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Oct 2023 11:14:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b="u/yYNOoj"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id F33F4804764B; Sat, 14 Oct 2023 11:14:30 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233237AbjJNSNn (ORCPT <rfc822;hjfbswb@gmail.com> + 19 others); Sat, 14 Oct 2023 14:13:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230016AbjJNSNm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 14 Oct 2023 14:13:42 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 654BBCC for <linux-kernel@vger.kernel.org>; Sat, 14 Oct 2023 11:13:40 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d9a39444700so3606813276.0 for <linux-kernel@vger.kernel.org>; Sat, 14 Oct 2023 11:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697307219; x=1697912019; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=rKyrhxaGZv0nPLnMXbvJXkiVEGuU/Lq6wP9rgM/Alfg=; b=u/yYNOojuWmJosMmEwVDzzax7C8pIpjeMNn6ObQ2JFgunKX5fe3pJvQUIhHaq3wXfx muDTEoWT32bmlJ0SmlSdQjj4DayGooJQ6F1X/SZv0NLDdmcbCb1lyRWbVsEyOz1RWE1Z /5e83rH3pztsq+OrAwowSsXxvfydaRQOUAKDex/lwj2iwlzODSKDhM1myiOOlt0XTzBt gR/qxsCJCPcbObAYBnc3ECzKuxca/dwcoUcoOENHJOoXOSZtHhsKaGZIDVFX0alEXYx5 3FI5Omjd7jEhF/5ukmATWtr67wQgkI/sd3bcLNm+C5xKMwdcqcA5lAodoPOYzxswrBKL ASCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697307219; x=1697912019; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rKyrhxaGZv0nPLnMXbvJXkiVEGuU/Lq6wP9rgM/Alfg=; b=WfrchimKrQJVw12wIye9Fl2jphOSTMQAezY8PM19vDI7pusHai6lwP/TSHAfCW3sUq VL9Wv1FzymaAc1aYT7BMbvgXJzDOpMRj55V1E3YKnW53hi7v6Myn2UlqdjERADGwChIT 8hoT4pFhw9UlTQrWfMt9y4EodGSa2ZbzkzNzCB6aYrYN5c7Bx90aI7OHrFQxyr+P9qgK g5hRoZa4YFrWwK6qPc3+EP0f3R/z5rRtfN0/AwaJBPWChbK95MYC52dF+hOXOX+MkvvZ nY/M1xVU3hIZNIatOgkUx+nrmig9TlNXP7HxxJGarS7pqDraUmPip9z1wNGrU+TFsn5z clrg== X-Gm-Message-State: AOJu0Yw9c3uY4wu3naunuP8l2FlDCQ90nyac7ukMjkOqwbyIulvbsScy vvuhNfQce76FBpFvwNLiamggrr2KP2Vjt6rMMRJJ X-Received: from vamshig51.c.googlers.com ([fda3:e722:ac3:cc00:3:22c1:c0a8:70c]) (user=vamshigajjela job=sendgmr) by 2002:a25:d748:0:b0:d89:cd65:c2b0 with SMTP id o69-20020a25d748000000b00d89cd65c2b0mr95600ybg.6.1697307219523; Sat, 14 Oct 2023 11:13:39 -0700 (PDT) Date: Sat, 14 Oct 2023 23:43:33 +0530 Mime-Version: 1.0 X-Mailer: git-send-email 2.42.0.655.g421f12c284-goog Message-ID: <20231014181333.2579530-1-vamshigajjela@google.com> Subject: [PATCH v2 1/3] serial: core: Potential overflow of frame_time From: Vamshi Gajjela <vamshigajjela@google.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby <jirislaby@kernel.org>, ilpo.jarvinen@linux.intel.com Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, manugautam@google.com, Subhash Jadavani <sjadavani@google.com>, Channa Kadabi <kadabi@google.com>, VAMSHI GAJJELA <vamshigajjela@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Sat, 14 Oct 2023 11:14:31 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779727730342289364 X-GMAIL-MSGID: 1779755672304657333 |
Series |
[v2,1/3] serial: core: Potential overflow of frame_time
|
|
Commit Message
Vamshi Gajjela
Oct. 14, 2023, 6:13 p.m. UTC
From: VAMSHI GAJJELA <vamshigajjela@google.com> uart_update_timeout() sets a u64 value to an unsigned int frame_time. While it can be cast to u32 before assignment, there's a specific case where frame_time is cast to u64. Since frame_time consistently participates in u64 arithmetic, its data type is converted to u64 to eliminate the need for explicit casting. Signed-off-by: VAMSHI GAJJELA <vamshigajjela@google.com> --- v2: - use DIV64_U64_ROUND_UP with frame_time drivers/tty/serial/8250/8250_port.c | 2 +- include/linux/serial_core.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
Comments
On Sat, 14 Oct 2023 23:43:33 +0530 Vamshi Gajjela <vamshigajjela@google.com> wrote: > From: VAMSHI GAJJELA <vamshigajjela@google.com> Hi, your commit title doesn't really explain what this patch is doing. Please see: https://cbea.ms/git-commit/#imperative > uart_update_timeout() sets a u64 value to an unsigned int frame_time. > While it can be cast to u32 before assignment, there's a specific case > where frame_time is cast to u64. Since frame_time consistently > participates in u64 arithmetic, its data type is converted to u64 to > eliminate the need for explicit casting. Again, refering to your title commit message, I would expect that you would describe precisely how a potential overflow can happen here, and I am not seeing it. And based on your log message, it seems that your commit is simply some kind of optimization, not a fix? Hugo. > Signed-off-by: VAMSHI GAJJELA <vamshigajjela@google.com> > --- > v2: > - use DIV64_U64_ROUND_UP with frame_time > > drivers/tty/serial/8250/8250_port.c | 2 +- > include/linux/serial_core.h | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c > index 141627370aab..d1bf794498c4 100644 > --- a/drivers/tty/serial/8250/8250_port.c > +++ b/drivers/tty/serial/8250/8250_port.c > @@ -1510,7 +1510,7 @@ static inline void __stop_tx(struct uart_8250_port *p) > * rather than after it is fully sent. > * Roughly estimate 1 extra bit here with / 7. > */ > - stop_delay = p->port.frame_time + DIV_ROUND_UP(p->port.frame_time, 7); > + stop_delay = p->port.frame_time + DIV64_U64_ROUND_UP(p->port.frame_time, 7); > } > > __stop_tx_rs485(p, stop_delay); > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > index bb6f073bc159..b128513b009a 100644 > --- a/include/linux/serial_core.h > +++ b/include/linux/serial_core.h > @@ -558,7 +558,7 @@ struct uart_port { > > bool hw_stopped; /* sw-assisted CTS flow state */ > unsigned int mctrl; /* current modem ctrl settings */ > - unsigned int frame_time; /* frame timing in ns */ > + unsigned long frame_time; /* frame timing in ns */ > unsigned int type; /* port type */ > const struct uart_ops *ops; > unsigned int custom_divisor; > @@ -764,7 +764,7 @@ unsigned int uart_get_divisor(struct uart_port *port, unsigned int baud); > */ > static inline unsigned long uart_fifo_timeout(struct uart_port *port) > { > - u64 fifo_timeout = (u64)READ_ONCE(port->frame_time) * port->fifosize; > + u64 fifo_timeout = READ_ONCE(port->frame_time) * port->fifosize; > > /* Add .02 seconds of slop */ > fifo_timeout += 20 * NSEC_PER_MSEC; > -- > 2.42.0.655.g421f12c284-goog >
On Sun, Oct 15, 2023 at 4:44 AM Hugo Villeneuve <hugo@hugovil.com> wrote: > > On Sat, 14 Oct 2023 23:43:33 +0530 > Vamshi Gajjela <vamshigajjela@google.com> wrote: > > > From: VAMSHI GAJJELA <vamshigajjela@google.com> > > Hi, > your commit title doesn't really explain what this patch is doing. > > Please see: https://cbea.ms/git-commit/#imperative Thanks Hugo for the review, I will provide details in the following response. > > > > uart_update_timeout() sets a u64 value to an unsigned int frame_time. > > While it can be cast to u32 before assignment, there's a specific case > > where frame_time is cast to u64. Since frame_time consistently > > participates in u64 arithmetic, its data type is converted to u64 to > > eliminate the need for explicit casting. > > Again, refering to your title commit message, I would expect that you > would describe precisely how a potential overflow can happen here, and > I am not seeing it. > > And based on your log message, it seems that your commit is simply some > kind of optimization, not a fix? In the function uart_update_timeout() within serial_core.c, a u64 value is assigned to an "unsigned int" variable frame_time. This raises concerns about potential overflow. While the code in the patch doesn't explicitly manifest the issue in the following line of uart_update_timeout() "port->frame_time = DIV64_U64_ROUND_UP(frame_time, baud);" lacks a u32 typecast for frame_time. In the function "uart_fifo_timeout" has the following line of code u64 fifo_timeout = (u64)READ_ONCE(port->frame_time) * port->fifosize; In the above line frame_time is typecast to u64 also, timeout values in the serial core associated with frame_time are used in the u64 arithmetic. To maintain consistency and readability, I've updated the size of frame_time from "unsigned int" to "unsigned long". This ensures uniformity with typecasts elsewhere in the code, addressing potential issues and enhancing clarity. I hope this provides clarity. Would you find it helpful if I were to provide further details in the commit message? > > Hugo. > > > > > Signed-off-by: VAMSHI GAJJELA <vamshigajjela@google.com> > > --- > > v2: > > - use DIV64_U64_ROUND_UP with frame_time > > > > drivers/tty/serial/8250/8250_port.c | 2 +- > > include/linux/serial_core.h | 4 ++-- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c > > index 141627370aab..d1bf794498c4 100644 > > --- a/drivers/tty/serial/8250/8250_port.c > > +++ b/drivers/tty/serial/8250/8250_port.c > > @@ -1510,7 +1510,7 @@ static inline void __stop_tx(struct uart_8250_port *p) > > * rather than after it is fully sent. > > * Roughly estimate 1 extra bit here with / 7. > > */ > > - stop_delay = p->port.frame_time + DIV_ROUND_UP(p->port.frame_time, 7); > > + stop_delay = p->port.frame_time + DIV64_U64_ROUND_UP(p->port.frame_time, 7); > > } > > > > __stop_tx_rs485(p, stop_delay); > > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > > index bb6f073bc159..b128513b009a 100644 > > --- a/include/linux/serial_core.h > > +++ b/include/linux/serial_core.h > > @@ -558,7 +558,7 @@ struct uart_port { > > > > bool hw_stopped; /* sw-assisted CTS flow state */ > > unsigned int mctrl; /* current modem ctrl settings */ > > - unsigned int frame_time; /* frame timing in ns */ > > + unsigned long frame_time; /* frame timing in ns */ > > unsigned int type; /* port type */ > > const struct uart_ops *ops; > > unsigned int custom_divisor; > > @@ -764,7 +764,7 @@ unsigned int uart_get_divisor(struct uart_port *port, unsigned int baud); > > */ > > static inline unsigned long uart_fifo_timeout(struct uart_port *port) > > { > > - u64 fifo_timeout = (u64)READ_ONCE(port->frame_time) * port->fifosize; > > + u64 fifo_timeout = READ_ONCE(port->frame_time) * port->fifosize; > > > > /* Add .02 seconds of slop */ > > fifo_timeout += 20 * NSEC_PER_MSEC; > > -- > > 2.42.0.655.g421f12c284-goog > >
On 14. 10. 23, 20:13, Vamshi Gajjela wrote: > From: VAMSHI GAJJELA <vamshigajjela@google.com> > > uart_update_timeout() sets a u64 value to an unsigned int frame_time. > While it can be cast to u32 before assignment, there's a specific case > where frame_time is cast to u64. Since frame_time consistently > participates in u64 arithmetic, its data type is converted to u64 to > eliminate the need for explicit casting. And make the divisions by the order of magnutude slower for no good reason? (Hint: have you looked what DIV64_U64_ROUND_UP() looks like on 32bit yet?) Unless you provide a reason it can overflow in real (in fact you spell the opposite in the text above): NACKED-by: Jiri Slaby <jirislaby@kernel.org> > Signed-off-by: VAMSHI GAJJELA <vamshigajjela@google.com> > --- > v2: > - use DIV64_U64_ROUND_UP with frame_time > > drivers/tty/serial/8250/8250_port.c | 2 +- > include/linux/serial_core.h | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c > index 141627370aab..d1bf794498c4 100644 > --- a/drivers/tty/serial/8250/8250_port.c > +++ b/drivers/tty/serial/8250/8250_port.c > @@ -1510,7 +1510,7 @@ static inline void __stop_tx(struct uart_8250_port *p) > * rather than after it is fully sent. > * Roughly estimate 1 extra bit here with / 7. > */ > - stop_delay = p->port.frame_time + DIV_ROUND_UP(p->port.frame_time, 7); > + stop_delay = p->port.frame_time + DIV64_U64_ROUND_UP(p->port.frame_time, 7); > } > > __stop_tx_rs485(p, stop_delay); > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > index bb6f073bc159..b128513b009a 100644 > --- a/include/linux/serial_core.h > +++ b/include/linux/serial_core.h > @@ -558,7 +558,7 @@ struct uart_port { > > bool hw_stopped; /* sw-assisted CTS flow state */ > unsigned int mctrl; /* current modem ctrl settings */ > - unsigned int frame_time; /* frame timing in ns */ > + unsigned long frame_time; /* frame timing in ns */ > unsigned int type; /* port type */ > const struct uart_ops *ops; > unsigned int custom_divisor; > @@ -764,7 +764,7 @@ unsigned int uart_get_divisor(struct uart_port *port, unsigned int baud); > */ > static inline unsigned long uart_fifo_timeout(struct uart_port *port) > { > - u64 fifo_timeout = (u64)READ_ONCE(port->frame_time) * port->fifosize; > + u64 fifo_timeout = READ_ONCE(port->frame_time) * port->fifosize; > > /* Add .02 seconds of slop */ > fifo_timeout += 20 * NSEC_PER_MSEC;
On Mon, 16 Oct 2023, Jiri Slaby wrote: > On 14. 10. 23, 20:13, Vamshi Gajjela wrote: > > From: VAMSHI GAJJELA <vamshigajjela@google.com> > > > > uart_update_timeout() sets a u64 value to an unsigned int frame_time. > > While it can be cast to u32 before assignment, there's a specific case > > where frame_time is cast to u64. Since frame_time consistently > > participates in u64 arithmetic, its data type is converted to u64 to > > eliminate the need for explicit casting. > > And make the divisions by the order of magnutude slower for no good reason? > (Hint: have you looked what DIV64_U64_ROUND_UP() looks like on 32bit yet?) > > Unless you provide a reason it can overflow in real (in fact you spell the > opposite in the text above): > NACKED-by: Jiri Slaby <jirislaby@kernel.org> I sorry but I have to concur Jiri heavily here, NACKED-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> > > Signed-off-by: VAMSHI GAJJELA <vamshigajjela@google.com> > > --- > > v2: > > - use DIV64_U64_ROUND_UP with frame_time Please, I barely managed to read your v1 and it's v2 already, don't send the next version this soon. There's absolutely no need to fill our inboxes with n versions of your patch over a weekend, just remain patient and wait reasonable amount of time to gather feedback, please. ...I know it's often hard to wait, it's hard for me too at times. You even failed to convert the other divide done on ->frame_time to DIV64_u64_ROUND_UP(), which looks a mindboggling oversight to me. So far you've managed to cause so many problems with these two attempts to fix a non-problem I heavily suggest you focus on something that doesn't relate to fixing types. It takes time to understand the related code when doing something as simple as type change, which you clearly did not have as demonstrated by you missing that other divide which can be trivially found with git grep. > > > > drivers/tty/serial/8250/8250_port.c | 2 +- > > include/linux/serial_core.h | 4 ++-- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/tty/serial/8250/8250_port.c > > b/drivers/tty/serial/8250/8250_port.c > > index 141627370aab..d1bf794498c4 100644 > > --- a/drivers/tty/serial/8250/8250_port.c > > +++ b/drivers/tty/serial/8250/8250_port.c > > @@ -1510,7 +1510,7 @@ static inline void __stop_tx(struct uart_8250_port *p) > > * rather than after it is fully sent. > > * Roughly estimate 1 extra bit here with / 7. > > */ > > - stop_delay = p->port.frame_time + > > DIV_ROUND_UP(p->port.frame_time, 7); > > + stop_delay = p->port.frame_time + > > DIV64_U64_ROUND_UP(p->port.frame_time, 7); > > } > > __stop_tx_rs485(p, stop_delay); > > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > > index bb6f073bc159..b128513b009a 100644 > > --- a/include/linux/serial_core.h > > +++ b/include/linux/serial_core.h > > @@ -558,7 +558,7 @@ struct uart_port { > > bool hw_stopped; /* sw-assisted CTS > > flow state */ > > unsigned int mctrl; /* current modem ctrl > > settings */ > > - unsigned int frame_time; /* frame timing in ns > > */ > > + unsigned long frame_time; /* frame timing in ns > > */ As with v1, u64 != unsigned long, I hope you do know that much about different architectures...
On Mon, Oct 16, 2023 at 4:30 PM Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote: > > On Mon, 16 Oct 2023, Jiri Slaby wrote: > > > On 14. 10. 23, 20:13, Vamshi Gajjela wrote: > > > From: VAMSHI GAJJELA <vamshigajjela@google.com> > > > > > > uart_update_timeout() sets a u64 value to an unsigned int frame_time. > > > While it can be cast to u32 before assignment, there's a specific case > > > where frame_time is cast to u64. Since frame_time consistently > > > participates in u64 arithmetic, its data type is converted to u64 to > > > eliminate the need for explicit casting. > > > > And make the divisions by the order of magnutude slower for no good reason? > > (Hint: have you looked what DIV64_U64_ROUND_UP() looks like on 32bit yet?) > > > > Unless you provide a reason it can overflow in real (in fact you spell the > > opposite in the text above): > > NACKED-by: Jiri Slaby <jirislaby@kernel.org> > > I sorry but I have to concur Jiri heavily here, > > NACKED-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> > > > > Signed-off-by: VAMSHI GAJJELA <vamshigajjela@google.com> > > > --- > > > v2: > > > - use DIV64_U64_ROUND_UP with frame_time > > Please, I barely managed to read your v1 and it's v2 already, don't send > the next version this soon. There's absolutely no need to fill our inboxes > with n versions of your patch over a weekend, just remain patient > and wait reasonable amount of time to gather feedback, please. ...I know > it's often hard to wait, it's hard for me too at times. > > You even failed to convert the other divide done on ->frame_time to > DIV64_u64_ROUND_UP(), which looks a mindboggling oversight to me. > So far you've managed to cause so many problems with these two attempts to > fix a non-problem I heavily suggest you focus on something that doesn't > relate to fixing types. It takes time to understand the related code when > doing something as simple as type change, which you clearly did not have > as demonstrated by you missing that other divide which can be trivially > found with git grep. Apologies for the inconvenience caused, I should have waited for the response on v1 before making v2, by leaving a comment about the anticipated change. I have clearly not considered all the architectures in the patch, and the overhead of division on 32-archs, mistake from my side. once again apologies for that. Thanks Jiri Slaby & Ilpo Järvinen for the review. > > > > > > > drivers/tty/serial/8250/8250_port.c | 2 +- > > > include/linux/serial_core.h | 4 ++-- > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/tty/serial/8250/8250_port.c > > > b/drivers/tty/serial/8250/8250_port.c > > > index 141627370aab..d1bf794498c4 100644 > > > --- a/drivers/tty/serial/8250/8250_port.c > > > +++ b/drivers/tty/serial/8250/8250_port.c > > > @@ -1510,7 +1510,7 @@ static inline void __stop_tx(struct uart_8250_port *p) > > > * rather than after it is fully sent. > > > * Roughly estimate 1 extra bit here with / 7. > > > */ > > > - stop_delay = p->port.frame_time + > > > DIV_ROUND_UP(p->port.frame_time, 7); > > > + stop_delay = p->port.frame_time + > > > DIV64_U64_ROUND_UP(p->port.frame_time, 7); > > > } > > > __stop_tx_rs485(p, stop_delay); > > > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > > > index bb6f073bc159..b128513b009a 100644 > > > --- a/include/linux/serial_core.h > > > +++ b/include/linux/serial_core.h > > > @@ -558,7 +558,7 @@ struct uart_port { > > > bool hw_stopped; /* sw-assisted CTS > > > flow state */ > > > unsigned int mctrl; /* current modem ctrl > > > settings */ > > > - unsigned int frame_time; /* frame timing in ns > > > */ > > > + unsigned long frame_time; /* frame timing in ns > > > */ > > As with v1, u64 != unsigned long, I hope you do know that much about > different architectures... > > -- > i. > > > > unsigned int type; /* port type */ > > > const struct uart_ops *ops; > > > unsigned int custom_divisor; > > > @@ -764,7 +764,7 @@ unsigned int uart_get_divisor(struct uart_port *port, > > > unsigned int baud); > > > */ > > > static inline unsigned long uart_fifo_timeout(struct uart_port *port) > > > { > > > - u64 fifo_timeout = (u64)READ_ONCE(port->frame_time) * port->fifosize; > > > + u64 fifo_timeout = READ_ONCE(port->frame_time) * port->fifosize; > > > /* Add .02 seconds of slop */ > > > fifo_timeout += 20 * NSEC_PER_MSEC; > > > >
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 141627370aab..d1bf794498c4 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -1510,7 +1510,7 @@ static inline void __stop_tx(struct uart_8250_port *p) * rather than after it is fully sent. * Roughly estimate 1 extra bit here with / 7. */ - stop_delay = p->port.frame_time + DIV_ROUND_UP(p->port.frame_time, 7); + stop_delay = p->port.frame_time + DIV64_U64_ROUND_UP(p->port.frame_time, 7); } __stop_tx_rs485(p, stop_delay); diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index bb6f073bc159..b128513b009a 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -558,7 +558,7 @@ struct uart_port { bool hw_stopped; /* sw-assisted CTS flow state */ unsigned int mctrl; /* current modem ctrl settings */ - unsigned int frame_time; /* frame timing in ns */ + unsigned long frame_time; /* frame timing in ns */ unsigned int type; /* port type */ const struct uart_ops *ops; unsigned int custom_divisor; @@ -764,7 +764,7 @@ unsigned int uart_get_divisor(struct uart_port *port, unsigned int baud); */ static inline unsigned long uart_fifo_timeout(struct uart_port *port) { - u64 fifo_timeout = (u64)READ_ONCE(port->frame_time) * port->fifosize; + u64 fifo_timeout = READ_ONCE(port->frame_time) * port->fifosize; /* Add .02 seconds of slop */ fifo_timeout += 20 * NSEC_PER_MSEC;