lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 26 Aug 2022 14:34:42 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] serial: dz: xmit buffer is UART_XMIT_SIZE'd

On Thu, 25 Aug 2022, Ilpo Järvinen wrote:

> In theory, the Tx code would be buggy if UART_XMIT_SIZE differs from
> 4096 (occurs when PAGE_SIZE > 4k), however, given the lack of issue
> reports such configuration likely doesn't occur with any real platform
> with dz HW. The inconsisted sizes would cause missing characters and
> never-ending bogus Tx when ->head reaches the region above 4k. The
> issue, if it would be real, would predate git days.

 This is misleading.  There are exactly 3 machine models (2 major ones and 
1 extra submodel) that we currently support which make use of this serial 
port hardware and driver, and they all have their R2000/R3000 MIPS CPU 
soldered onto their respective mainboards.  And the CPUs they use all have 
their page size hardwired to 4KiB, so it's not the lack of reports, but a 
firm assertion that this driver as it stands shall never be used with a 
different page size.

 There exists an option card using a DZ11-compatible chipset that can be 
used with systems we currently support with page sizes of up to 64KiB, but 
to the best of my knowledge only a number of prototype cards has been made 
and I have heard of exactly one person having such a card.  Therefore we 
do not support it and may never do, so it is not a concern for the driver 
as it stands and shall not be mentioned.

 Please just state then that the change is for design consistency with the 
serial core and redefine DZ_XMIT_SIZE in terms of UART_XMIT_SIZE as I 
suggested for v1.  I'll ack such a change.  Please drop 2/2 at this stage 
as it does not fix any bug and does not appear to add any value to this 
driver.

 Thanks,

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ