linux-kernel - Re: [PATCH 00/15] tty: serial: switch from circ

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: Mon, 22 Apr 2024 07:51:52 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: neil.armstrong@...aro.org, gregkh@...uxfoundation.org
Cc: linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
 Al Cooper <alcooperx@...il.com>, Alexander Shiyan <shc_work@...l.ru>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Alim Akhtar <alim.akhtar@...sung.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 "Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>, Baruch Siach
 <baruch@...s.co.il>, Bjorn Andersson <andersson@...nel.org>,
 Claudiu Beznea <claudiu.beznea@...on.dev>,
 "David S. Miller" <davem@...emloft.net>, Fabio Estevam <festevam@...il.com>,
 Hammer Hsieh <hammerh0314@...il.com>,
 Christian König <christian.koenig@....com>,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Chunyan Zhang <zhang.lyra@...il.com>, Jerome Brunet <jbrunet@...libre.com>,
 Jonathan Hunter <jonathanh@...dia.com>, Kevin Hilman <khilman@...libre.com>,
 Konrad Dybcio <konrad.dybcio@...aro.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Kumaravel Thiagarajan <kumaravel.thiagarajan@...rochip.com>,
 Laxman Dewangan <ldewangan@...dia.com>,
 linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
 "Maciej W. Rozycki" <macro@...am.me.uk>,
 Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
 Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
 Matthias Brugger <matthias.bgg@...il.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Michael Ellerman <mpe@...erman.id.au>, Michal Simek <michal.simek@....com>,
 "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
 Nicolas Ferre <nicolas.ferre@...rochip.com>,
 Nicholas Piggin <npiggin@...il.com>, Orson Zhai <orsonzhai@...il.com>,
 Pali Rohár <pali@...nel.org>,
 Patrice Chotard <patrice.chotard@...s.st.com>,
 Peter Korsgaard <jacmet@...site.dk>,
 Richard Genoud <richard.genoud@...il.com>,
 Russell King <linux@...linux.org.uk>, Sascha Hauer <s.hauer@...gutronix.de>,
 Shawn Guo <shawnguo@...nel.org>, Stefani Seibold <stefani@...bold.net>,
 Sumit Semwal <sumit.semwal@...aro.org>,
 Taichi Sugaya <sugaya.taichi@...ionext.com>,
 Takao Orito <orito.takao@...ionext.com>,
 Tharun Kumar P <tharunkumar.pasumarthi@...rochip.com>,
 Thierry Reding <thierry.reding@...il.com>, Timur Tabi <timur@...nel.org>,
 Vineet Gupta <vgupta@...nel.org>, Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH 00/15] tty: serial: switch from circ_buf to kfifo

Hi,

On 19. 04. 24, 17:12, Neil Armstrong wrote:
> On 05/04/2024 08:08, Jiri Slaby (SUSE) wrote:
>> This series switches tty serial layer to use kfifo instead of circ_buf.
>>
>> The reasoning can be found in the switching patch in this series:
>> """
>> Switch from struct circ_buf to proper kfifo. kfifo provides much better
>> API, esp. when wrap-around of the buffer needs to be taken into account.
>> Look at pl011_dma_tx_refill() or cpm_uart_tx_pump() changes for example.
>>
>> Kfifo API can also fill in scatter-gather DMA structures, so it easier
>> for that use case too. Look at lpuart_dma_tx() for example. Note that
>> not all drivers can be converted to that (like atmel_serial), they
>> handle DMA specially.
>>
>> Note that usb-serial uses kfifo for TX for ages.
>> """
..
> This patchset has at least broken all Amlogic and Qualcomm boards so 
> far, only part of them were fixed in next-

So are there still not fixed problems yet?

> but this serie has been 
> merged in v1

Ugh, are you saying that v1 patches are not worth taking? That doesn't 
fit with my experience.

> with no serious testing

Sadly, everyone had a chance to test the series:
   https://lore.kernel.org/all/20240319095315.27624-1-jirislaby@kernel.org/
for more than two weeks before I sent this version for inclusion. And 
then it took another 5 days till this series appeared in -next. But 
noone with this HW apparently cared enough back then. I'd wish they 
(you) didn't. Maybe next time, people will listen more carefully:
===
This is Request for Testing as I cannot test all the changes
(obviously). So please test your HW's serial properly.
===

> and should've been dropped 
> immediately when the first regressions were reported.

Provided the RFT was mostly ignored (anyone who tested that here, or I 
only wasted my time?), how exactly would dropping help me finding 
potential issues in the series? In the end, noone is running -next in 
production, so glitches are sort of expected, right? And I believe I 
smashed them quickly enough (despite I was sidetracked to handle the 
n_gsm issue). But I might be wrong, as usual.

So no, dropping is not helping moving forward, actions taken by e.g. 
Marek Szyprowski <m.szyprowski@...sung.com> do, IMNSHO.

thanks,
-- 
js
suse labs