linux-kernel - Re: [RFC][PATCH 00/13] firewire-sbp-target: FireWire SBP-2 SCSI target

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:	Sun, 12 Feb 2012 15:12:47 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Chris Boot <bootc@...tc.net>
Cc:	linux1394-devel@...ts.sourceforge.net,
	target-devel@...r.kernel.org, linux-kernel@...r.kernel.org,
	agrover@...hat.com, clemens@...isch.de, nab@...ux-iscsi.org
Subject: Re: [RFC][PATCH 00/13] firewire-sbp-target: FireWire SBP-2 SCSI
 target

On Feb 11 Chris Boot wrote:
> Well after lots of work I have a working and generally (at least I think)
> sensible starting point for the FireWire target. It appears to work fine in all
> the configurations I've tested it against, including Linux and Mac OS X
> initiators.

I only very quickly scrolled through your patches yet.  Looks all very
readable and well laid out.  Some random thoughts:

Some of the smaller source files could certainly be merged with other
ones without loss of readability.

Some comments about what the code is doing can be removed since the
function names are very well readable on their own.  Example:
+	/* read the peer's GUID */
+	ret = read_peer_guid(&guid, req);

The APIs which you include from "../../firewire/core.h" should eventually
be moved to <linux/firewire.h>.  I think it does not matter whether this
is done before or after mainline merge.  When we do so we should check
whether the affected APIs can be improved for usage in drivers.

Many of the printks should surely be demoted to debug messages with
runtime on-and-off switch.

There are list traversals and list manipulations that make an impression
as if they wanted to be mutex- or lock-protected, but I haven't looked yet
in which contexts these accesses happen.

sbp_proto.c:
+/*
+ * Handlers for Serial Attached SCSI (SBP)
+ */
                 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ Serial Bus Protocol
Though this is also readily apparent from the top comment in the file.

The four EXPORT_SYMBOLs in sbp_proto.c can be removed, it seems.

sbp_login.c:
+			pr_notice("initiator already logged-in\n");
+
+			/*
+			 * SBP-2 R4 says we should return access denied, but
+			 * that can confuse initiators. Instead we need to
+			 * treat this like a reconnect, but send the login
+			 * response block like a fresh login.
+			 */
Are there initiators which don't bother with reconnect but send relogin
straight away?

Kconfig:
"default n" is redundant.
"*older* Apple computers":  They are still manufactured with this feature.
-- 
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/