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: <alpine.DEB.2.21.2309151739290.57368@angie.orcam.me.uk>
Date:   Fri, 15 Sep 2023 18:23:44 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Thomas Gleixner <tglx@...utronix.de>
cc:     John Ogness <john.ogness@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial@...r.kernel.org, Petr Mladek <pmladek@...e.com>,
        linux-kernel@...r.kernel.org, Tobias Klauser <tklauser@...tanz.ch>,
        Thierry Reding <treding@...dia.com>,
        Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>,
        linux-arm-kernel@...ts.infradead.org,
        linux-aspeed@...ts.ozlabs.org, Al Cooper <alcooperx@...il.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        Tony Lindgren <tony@...mide.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Davis <afd@...com>,
        Matthew Howell <matthew.howell@...level.com>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        Johan Hovold <johan@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Chen-Yu Tsai <wenst@...omium.org>,
        linux-mediatek@...ts.infradead.org, Lukas Wunner <lukas@...ner.de>,
        Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        Arnd Bergmann <arnd@...db.de>,
        Kumaravel Thiagarajan <kumaravel.thiagarajan@...rochip.com>,
        Tharun Kumar P <tharunkumar.pasumarthi@...rochip.com>,
        Russell King <linux@...linux.org.uk>,
        Hongyu Xie <xiehongyu1@...inos.cn>,
        Jiamei Xie <jiamei.xie@....com>, Rob Herring <robh@...nel.org>,
        delisun <delisun@...eo.com.cn>,
        Lino Sanfilippo <l.sanfilippo@...bus.com>,
        Yangtao Li <frank.li@...o.com>,
        Vineet Gupta <vgupta@...nel.org>,
        linux-snps-arc@...ts.infradead.org,
        Richard Genoud <richard.genoud@...il.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Claudiu Beznea <claudiu.beznea@...on.dev>,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Baruch Siach <baruch@...s.co.il>,
        Sherry Sun <sherry.sun@....com>,
        Shenwei Wang <shenwei.wang@....com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Sergey Organov <sorganov@...il.com>, Tom Rix <trix@...hat.com>,
        Marek Vasut <marex@...x.de>,
        Karol Gugala <kgugala@...micro.com>,
        Mateusz Holenko <mholenko@...micro.com>,
        Gabriel Somlo <gsomlo@...il.com>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Jacky Huang <ychuang3@...oton.com>,
        Shan-Chun Hung <schung@...oton.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Kevin Hilman <khilman@...libre.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Dmitry Rokosov <ddrokosov@...rdevices.ru>,
        Lucas Tanure <tanure@...ux.com>,
        linux-amlogic@...ts.infradead.org,
        Taichi Sugaya <sugaya.taichi@...ionext.com>,
        Takao Orito <orito.takao@...ionext.com>,
        Liviu Dudau <liviu.dudau@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        linux-arm-msm@...r.kernel.org,
        Pali Rohár <pali@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andreas Färber <afaerber@...e.de>,
        Manivannan Sadhasivam <mani@...nel.org>,
        linux-actions@...ts.infradead.org,
        Xiongfeng Wang <wangxiongfeng2@...wei.com>,
        Yuan Can <yuancan@...wei.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>,
        linuxppc-dev@...ts.ozlabs.org, linux-unisoc@...ts.infradead.org,
        Kevin Cernekee <cernekee@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Alim Akhtar <alim.akhtar@...sung.com>,
        linux-samsung-soc@...r.kernel.org,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Lech Perczak <lech.perczak@...lingroup.com>,
        Hugo Villeneuve <hvilleneuve@...onoff.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Isaac True <isaac.true@...onical.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        linux-tegra@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Nick Hu <nick.hu@...ive.com>,
        Ruan Jinjie <ruanjinjie@...wei.com>,
        Samuel Holland <samuel.holland@...ive.com>,
        linux-riscv@...ts.infradead.org, Orson Zhai <orsonzhai@...il.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        Patrice Chotard <patrice.chotard@...s.st.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Valentin Caron <valentin.caron@...s.st.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        linux-stm32@...md-mailman.stormreply.com,
        "David S. Miller" <davem@...emloft.net>,
        sparclinux@...r.kernel.org, Hammer Hsieh <hammerh0314@...il.com>,
        Timur Tabi <timur@...nel.org>,
        Mukesh Ojha <quic_mojha@...cinc.com>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        Michal Simek <michal.simek@....com>
Subject: Re: [PATCH tty v1 00/74] serial: wrappers for uart port lock

On Fri, 15 Sep 2023, Thomas Gleixner wrote:

> >> Patches 2-74 switch all uart port locking call sites to use the new
> >> wrappers. These patches were automatically generated using coccinelle.
> >
> >  Hmm, no need to do this for drivers/tty/serial/zs.c?
> 
> zs.c does not use port lock at all. It has like a couple of other
> drivers a local homebrewn spinlock.

 Ah, right, that's because there are registers shared between two ports 
within one SCC, so the spinlock has to be shared as well.

 This also indicates that dz.c is wrong and shouldn't be using a per-port 
spinlock as the DZ has a shared register set between all the four ports 
(it's a serial line multiplexer rather than a set discrete ports; up to 8 
lines are architecturally supported, though we don't have support in Linux 
for systems having those), e.g. there's only one 16-bit receiver buffer 
register for all the four ports, supplying the 8-bit character received 
along with the receive status and the number of the line this data arrived 
on, and similarly there's only one transmit data register, which supplies 
data to the next enabled line whose transmit buffer needs servicing, and 
the chip routes the data itself.  Therefore the driver ought to use a 
shared spinlock too.

 I guess it wasn't noticed so far because DZ devices aren't that common 
(and my usual test machine is currently broken too, pending an SRAM chip 
replacement, hopefully in the next few weeks) and then hardly ever more 
than one serial line has been used at a time with these devices.  It looks 
like the first issue for me to look into once the machine has been fixed.

 Maybe dz.c shouldn't be touched by this series then?  (Though obviously 
both drivers will have to be eventually adapted for the ultimate console 
rework.)

 Thanks for your input, as it turns out it has had an unexpected outcome.

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ