linux-kernel - Re: [RFC PATCH v2 0/7] i2c: core: introduce atomic transfers

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, 25 Mar 2019 14:40:20 +0100
From:   Wolfram Sang <wsa@...-dreams.de>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Wolfram Sang <wsa+renesas@...g-engineering.com>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Keerthy <j-keerthy@...com>, Peter Rosin <peda@...ntia.se>,
        Tony Lindgren <tony@...mide.com>,
        Russell King <linux@...linux.org.uk>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Stefan Lengfeld <contact@...fanchrist.eu>,
        Phil Reid <preid@...ctromag.com.au>,
        Tero Kristo <t-kristo@...com>,
        Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
        linux-tegra@...r.kernel.org
Subject: Re: [RFC PATCH v2 0/7] i2c: core: introduce atomic transfers

> This series seems like a valid approach to me if we still want to
> respect the locking.

And I am leaning to that it is good enough. I think pragmatism is OK
here: The users who want this feature simply want to reboot their
system, mostly development systems. They can't reboot otherwise. Except
for the HW switch they are currently using anyhow.

The panic fault-injector can create an inconsistent situation on the I2C
bus when you want to reboot after an OOPS while a transfer was in
progress. However, if rebooting in such scenarios is critical for you,
you a) shouldn't reboot via I2C, and/or b) should have a watchdog in
place. We can't guarantee to always fix this sitution. At best, we could
just try to be better for some cases. However, this would mean having a
backdoor to skip the locking scheme which doesn't sound right. Maybe
just accepting the deadlock is not too bad because it will reliably
point out a design flaw of the system (hopefully during the development
stage)?

Final call for other thoughts/comments.

PS: I am still interested in the use of in_atomic() here. I wonder if it is
correct. If a change is needed, it should probably be a seperate series,
though.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)