Due to bug 6393 and lack of portabable DMA mapping, sbp2 is currently only working if ohci1394 was loaded with the parameter phys_dma=1, which is the default. This parameter enables the so-called physical response unit of an OHCI-1394 host adapter which lets remote nodes read and write the lower 4GB of the host bus address range --- without assistance of the interrupt handler. This feature is nice for SBP-2 performance and also has applications in remote debugging and forensics, however it is also a security risc. Solution 1: Add dynamic phys_dma filtering to ohci1394 + sbp2. This should be fast to implement, more secure than unfiltered physical DMA (only SBP-2 targets will be allowed to talk to the physical response unit), and as well performing as unfiltered DMA. Solution 2: Internally to sbp2, implement a mapping of virtual addresses or DMA-mapped addresses to FireWire bus addresses and run all transfers via the normal asynchronous response unit. This is harder to implement, most secure (since no node at all needs to be allowed to talk to the physical response unit), and badly performing (since each FireWire packet will generate an interrupt and will probaly involve a memcopy).
It is not advisable to waste time on bug 6393 before this one.
New plan: See how it goes with the new firewire stack. If it doesn't turn out all bad, switch this bug to WILL_NOT_FIX. The new stack implements dynamic physical DMA filtering. Kristian mentioned he would be interested to also implement Solution 2 for the new stack in the long term.
There are currently no resources to fix this in drivers/ieee1394/. drivers/firewire/ does not feature this problem.