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

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Chris Wright wrote:
> * Stefan Richter (stefanr@s5r6.in-berlin.de) 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/