linux-kernel - Re: [PATCH 1/1] serial: dz: Replace DZ_XMIT_SIZE with UART_XMIT

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]

Message-ID: <89359013-85fe-76e1-a425-fabdfa3572f9@linux.intel.com>
Date:   Thu, 25 Aug 2022 15:03:51 +0300 (EEST)
From:   Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial <linux-serial@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] serial: dz: Replace DZ_XMIT_SIZE with
 UART_XMIT_SIZE

On Thu, 25 Aug 2022, Maciej W. Rozycki wrote:

> On Thu, 25 Aug 2022, Ilpo Järvinen wrote:
> 
> > Use the normal UART_XMIT_SIZE directly.
> 
>  I gather this is to fix a potential inconsistency with the size of the 
> buffer allocated by the serial core (though in reality this driver will 
> only be used with 4KiB-page systems), right?  If so, then please state it 
> in the change description.

No idea, but I guess it has to be true because nobody has complained about 
the missing characters such an inconsistency would cause. It could 
seemingly also cause infinite bogus tx as tail cannot never reach head 
when head is about 4k (uart_circ_empty & uart_circ_chars_pending would 
return bogus values).

>  Also I'd rather:
> 
> #define DZ_WAKEUP_CHARS      UART_XMIT_SIZE
> 
> and there's no need to include <linux/serial_core.h> in dz.h as the driver 
> itself already does that (and dz.h is an auxiliary private header).
> 
>  Thanks for your submission.

I have started to becomes more inclined into the direction of dropping 
DZ_WAKEUP_CHARS entirely and use WAKEUP_CHARS like most of the drivers do
after staring now at WAKEUP_CHARS & uart_write_wakeup() lines just now.

There is just a handful of exceptions, rest of the drivers all use 256 as 
WAKEUP_CHARS. dz uses 1024 (4k/4) and rest of the exceptions use 
uart_circ_empty() but I suspect they should also be just converted to 
use WAKEUP_CHARS.

-- 
 i.