linux-kernel - [PATCH 0/9] firewire-sbp2: misc hotplug related patches

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-next>] [day] [month] [year] [list]

Message-ID: <tkrat.f34e34fd91a0695f@s5r6.in-berlin.de>
Date:	Sun, 3 Feb 2008 23:00:54 +0100 (CET)
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	linux1394-devel@...ts.sourceforge.net
cc:	linux-kernel@...r.kernel.org
Subject: [PATCH 0/9] firewire-sbp2: misc hotplug related patches

Here is various stuff to hopefully improve fw-sbp2's behavior during bus
resets.  The main piece is patch 9/9 which considerably raises the
chance that ongoing I/O survives plugging and unplugging of other
devices on the same bus as the device which services the I/O.

The other patches are basically side products of patch 9/9 but contain
quite useful fixes as well.

I got quite good results with several OxSemi based SBP-2 devices, also
with an Initio based dual-LU device and LSI based devices.  A Prolific
PL-3505 based device with known buggy firmware didn't work too well; I
don't know if (but doubt that) the ieee1394 stack would do better.  My
two TI StorageLynx based devices, both with somewhat quirky firmware as
well, still almost never survive bus resets if there is also I/O.  These
devices don't show such problems with the old stack.

I simply tested HDDs with dd (read only), and CD/DVD-ROM/R/W with
cdparanoia.  The latter sometimes produced audible gaps in the ripped
audio file due to sometimes long blocked I/O when the bus was recovering
from addition or removal of devices.  I think the ability to recover
from such gaps also depends on the optical drive attached to the SBP-2
bridge.  However, dd apparently never had issues with arbitrarily long
I/O pauses.

It has to be noted that I still encountered various weird things while
abusing the hardware, i.e. all of this needs time for testing.  Also, I
don't have a device with multiple logical units beneath the same target
for testing.  The mentioned dual-LU device exposes the LUs in separate
unit directories, i.e. as separate targets.

Combined diffstat and shortlog:

 drivers/firewire/fw-device.c |   28 ++--
 drivers/firewire/fw-sbp2.c   |  224 ++++++++++++++++++++++++++---------
 drivers/ieee1394/sbp2.c      |   12 +
 drivers/ieee1394/sbp2.h      |    2
 4 files changed, 202 insertions(+), 64 deletions(-)

1/9 firewire: log GUID of new devices
2/9 firewire: fw-sbp2: add INQUIRY delay workaround
3/9 ieee1394: sbp2: add INQUIRY delay workaround
4/9 firewire: fw-sbp2: wait for completion of fetch agent reset
5/9 firewire: fw-sbp2: log bus_id at management request failures
6/9 firewire: fw-sbp2: don't add scsi_device twice
7/9 firewire: fw-sbp2: logout and login after failed reconnect
8/9 firewire: fw-sbp2: sort includes
9/9 firewire: fw-sbp2: fix I/O errors during reconnect
-- 
Stefan Richter
-=====-==--- --=- ---==
http://arcgraph.de/sr/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/