summaryrefslogtreecommitdiffstats
path: root/firmware
diff options
context:
space:
mode:
authorJay Fenlason <fenlason@redhat.com>2010-05-18 14:02:45 -0400
committerStefan Richter <stefanr@s5r6.in-berlin.de>2010-06-20 23:11:56 +0200
commit08bd34c98d631fe85744d4c920c80f48a1d95f54 (patch)
treecebfda304248a705e2b46f9d105b3c22705169f1 /firmware
parentbdfe273ee54b29498851fc8058516037d284270c (diff)
downloadblackbird-op-linux-08bd34c98d631fe85744d4c920c80f48a1d95f54.tar.gz
blackbird-op-linux-08bd34c98d631fe85744d4c920c80f48a1d95f54.zip
firewire: cdev: fix responses to nodes at different card
My box has two firewire cards in it: card0 and card1. My application opens /dev/fw0 (card 0) and allocates an address space. The core makes the address space available on both cards. Along comes the remote device, which sends a READ_QUADLET_REQUEST to card1. The request gets passed up to my application, which calls ioctl_send_response(). ioctl_send_response() then calls fw_send_response() with card0, because that's the card it's bound to. Card0's driver drops the response, because it isn't part of a transaction that it has outstanding. So in core-cdev: handle_request(), we need to stash the card of the inbound request in the struct inbound_transaction_resource and use that card to send the response to. The hard part will be refcounting the card correctly so it can't get deallocated while we hold a pointer to it. Here's a trivial patch, which does not do the card refcounting, but at least demonstrates what the problem is. Note that we can't depend on the fact that the core-cdev:client structure holds a card open, because in this case the card it holds open is not the card the request came in on. ..and there's no way for the core to tell cdev "this card is gone, kill any inbound transactions on it", while cdev holds the transaction open until userspace issues a SEND_RESPONSE ioctl, which may be a very, very long time. But when it does, it calls fw_send_response(), which will dereference the card... So how unhappy are we about userspace potentially holding a fw_card open forever? Signed-off-by: Jay Fenlason <fenlason@redhat.com> Reference counting to be addressed in a separate change. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace)
Diffstat (limited to 'firmware')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud