Re: [stable] [PATCH] sbp2: fix check of return value of hpsb_allocate_and_register_addrspace

From: Stefan Richter
Date: Sat Jun 03 2006 - 04:47:18 EST


Chris Wright wrote:
* Stefan Richter (stefanr@xxxxxxxxxxxxxxxxx) wrote:
...
+++ linux-2.6.17-rc5/drivers/ieee1394/sbp2.c 2006-06-03 01:54:23.000000000 +0200
@@ -845,7 +845,7 @@ static struct scsi_id_instance_data *sbp
&sbp2_highlevel, ud->ne->host, &sbp2_ops,
sizeof(struct sbp2_status_block), sizeof(quadlet_t),
0x010000000000ULL, CSR1212_ALL_SPACE_END);
- if (!scsi_id->status_fifo_addr) {
+ if (scsi_id->status_fifo_addr == ~0ULL) {
SBP2_ERR("failed to allocate status FIFO address range");
goto failed_alloc;
}



Is that enough?

failed_alloc:
sbp2_remove_device(scsi_id);

sbp2_remove_device(scsi_id)
if (scsi_id->status_fifo_addr)
hpsb_unregister_addrspace()

Suppose status_fifo_addr won't match any as->start.

Thanks, here is another bug. An address space beginning at 0 won't be de-registered. But this is not a big issue because 1. a configuration where a FIFO address space starting from 0 is impractical anyway (can occur if CONFIG_IEEE1394_SBP2_PHYS_DMA=N and physical DMA is unavailable from the host adapter, which won't work at the moment) and 2. the address space is a plenty resource (both as a bus address and with respect to the backing data structures) and 3. would be unregistered if the sbp2 module was unloaded. This is not critical for -stable.

On the other hand, if hpsb_unregister_addrspace(HL_driver, host, address) with address == ~0ULL (i.e. hpsb_allocate_and_register_addrspace failed before), it would do nothing but burn a few CPU cycles unsuccessfully searching for an address space starting at ~0ULL. Valid address spaces start at an address lower than CSR1212_ALL_SPACE_END == 1ULL << 48.

I will post a follow-up patch after breakfast, but it isn't relevant for -stable.

Thanks,
--
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/