linux-kernel - Re: [PATCH 6/9] firewire: fw-sbp2: don't add scsi

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: <47B0A50D.6060807@s5r6.in-berlin.de>
Date:	Mon, 11 Feb 2008 20:42:05 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Jarod Wilson <jwilson@...hat.com>
CC:	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/9] firewire: fw-sbp2: don't add scsi_device twice

Jarod Wilson wrote:
> Stefan Richter wrote:
>> When a reconnect failed but re-login succeeded, __scsi_add_device was
>> called again.
>>
>> Signed-off-by: Stefan Richter <stefanr@...6.in-berlin.de>
> 
> Was the spurious __scsi_add_device simply failing, or was it causing
> other problems as well? I can't remember if I've hit that or not. In
> either case, not calling it when we know we don't need to makes sense.

SCSI core looks up whether the scsi_target and the scsi_device already
exist.  If so, __scsi_add_device succeeds (there should also be a log
message "scsi scan: device exists on %s\n") and returns the pointer to
the existing scsi_device.

The code in fw-sbp2 before this patch series would then continue
appropriately ... except that it misses to call sbp2_cancel_orbs.  Right
now I am not quite sure which consequences that has; probably no serious
ones right now.  SCSI core would call fw-sbp2's eh_abort_handler
eventually which would reset the fetch agent once more and cancel the
timed out ORBs.  So, besides the needless lookups and temporary
allocations in SCSI core, we avoid the additional stall and timeout
until eh_abort_handler hits.

I shall add this to the changelog.

BTW, since the addition of the blocking and unblocking between bus reset
and reconnect/re-login we also need the unblocking call in the re-login
case but not (necessarily) in the first login case.
-- 
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/