From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Vamshi Gajjela <vamshigajjela@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
linux-serial <linux-serial@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
manugautam@google.com, Subhash Jadavani <sjadavani@google.com>,
Channa Kadabi <kadabi@google.com>
Subject: Re: [PATCH 1/3] serial: core: Potential overflow of frame_time
Date: Mon, 16 Oct 2023 13:33:41 +0300 (EEST) [thread overview]
Message-ID: <6f25e6fb-bebc-3f9b-9876-5e14d2582f6@linux.intel.com> (raw)
In-Reply-To: <20231014104942.856152-2-vamshigajjela@google.com>
[-- Attachment #1: Type: text/plain, Size: 2812 bytes --]
On Sat, 14 Oct 2023, Vamshi Gajjela wrote:
> From: VAMSHI GAJJELA <vamshigajjela@google.com>
>
> uart_update_timeout() sets a u64 value to an unsigned int frame_time.
Yes it does, because uart_update_timeout() does math that requires u64 but
the result is always smaller than what requires u64. If you insist on
doing something add the cast there.
> While it can be cast to u32 before assignment, there's a specific case
> where frame_time is cast to u64.
Because it gets multipled with something that results in a big number
The cast is all correct too because the developer actually thought of
possiblity of an overflow on multiply (something every developer should
be conscious of), so there's nothing to see there either.
> Since frame_time consistently
> participates in u64 arithmetic, its data type is converted to u64 to
> eliminate the need for explicit casting.
You need a way more convincing argument that that since you're not even
converting it to u64 like you falsely stated so the sizes still won't
match on all architectures.
I see you've realized u32 is more than enough to store frame time for the
speeds UART operates with? So why exactly is this patch needed? Should all
the other cases where 64-bit arithmetic needs to be used in the kernel be
similarly upconverted to 64 bits?
Also, did you happen to realize frame_time also participates in 32-bit
arithmetic which you just make much worse with this change? (Yes, there
are 32-bit divides done for it.)
So NACK from me to this "fix" of a non-problem by causing much worse
problems you seem to be entirely unaware.
NACKED-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
--
i.
> Signed-off-by: VAMSHI GAJJELA <vamshigajjela@google.com>
> ---
> include/linux/serial_core.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> 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;
>
next prev parent reply other threads:[~2023-10-16 10:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-14 10:49 [PATCH 0/3] serial core type consistency and overflow checks Vamshi Gajjela
2023-10-14 10:49 ` [PATCH 3/3] serial: core: Update uart_poll_timeout function to return unsigned int Vamshi Gajjela
2023-10-16 11:44 ` Ilpo Järvinen
[not found] ` <20231014104942.856152-2-vamshigajjela@google.com>
2023-10-16 10:33 ` Ilpo Järvinen [this message]
2023-10-18 13:45 ` [PATCH 1/3] serial: core: Potential overflow of frame_time VAMSHI GAJJELA
[not found] ` <20231014104942.856152-3-vamshigajjela@google.com>
2023-10-16 11:39 ` [PATCH 2/3] serial: core: Make local variable size to u64 Ilpo Järvinen
2023-10-18 14:16 ` VAMSHI GAJJELA
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6f25e6fb-bebc-3f9b-9876-5e14d2582f6@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=kadabi@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=manugautam@google.com \
--cc=sjadavani@google.com \
--cc=vamshigajjela@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome