Skip to content
Snippets Groups Projects
  1. Mar 24, 2009
  2. Oct 15, 2008
  3. Aug 02, 2008
    • David Moore's avatar
      firewire: Preserve response data alignment bug when it is harmless · 8401d92b
      David Moore authored
      
      Recently, a bug having to do with the alignment of transaction response
      data was fixed.  However, some apps such as libdc1394 relied on the
      presence of that bug in order to function correctly.  In order to stay
      compatible with old versions of those apps, this patch preserves the bug
      in cases where it is harmless to normal operation (such as the single
      quadlet read) due to a simple duplication of data.  This guarantees
      maximum compatability for those users who are using the old app with the
      fixed kernel.
      
      Signed-off-by: default avatarDavid Moore <dcm@acm.org>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      8401d92b
  4. Jul 20, 2008
    • JiSheng Zhang's avatar
      firewire: queue the right number of data · f9543d0a
      JiSheng Zhang authored
      
      There will be 4 padding bytes in struct fw_cdev_event_response on some platforms
      The member:__u32 data will point to these padding bytes. While queue the
      response and data in complete_transaction in fw-cdev.c, it will queue like this:
      |response(excluding padding bytes)|4 padding bytes|4 padding bytes|data.
      It queue 4 extra bytes. That is to say it use "&response + sizeof(response)"
      while other place of kernel and userspace library use "&response + offsetof
      (typeof(response), data)". So it will lost the last 4 bytes of data. This patch
      can fix it while not changing the struct definition.
      
      Signed-off-by: default avatarJiSheng Zhang <jszhang3@mail.ustc.edu.cn>
      
      This fixes responses to outbound block read requests on 64bit architectures.
      Tested on i686, x86-64, and x86-64 with i686 userland, using firecontrol and
      gscanbus.
      
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      f9543d0a
  5. Jun 18, 2008
    • Stefan Richter's avatar
      firewire: fill_bus_reset_event needs lock protection · 5cb84067
      Stefan Richter authored
      
      Callers of fill_bus_reset_event() have to take card->lock.  Otherwise
      access to node data may oops if node removal is in progress.
      
      A lockless alternative would be
      
      -	event->local_node_id = card->local_node->node_id;
      +	tmp = fw_node_get(card->local_node);
      +	event->local_node_id = tmp->node_id;
      +	fw_node_put(tmp);
      
      and ditto with the other node pointers which fill_bus_reset_event()
      accesses.  But I went the locked route because one of the two callers
      already holds the lock.  As a bonus, we don't need the memory barrier
      anymore because device->generation and device->node_id are written in
      a card->lock protected section.
      
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarKristian Høgsberg <krh@redhat.com>
      5cb84067
  6. May 20, 2008
    • Jay Fenlason's avatar
      firewire: prevent userspace from accessing shut down devices · 551f4cb9
      Jay Fenlason authored
      
      If userspace ignores the POLLERR bit from poll(), and only attempts to
      read() the device when POLLIN is set, it can still make ioctl() calls on
      a device that has been removed from the system.  The node_id and
      generation returned by GET_INFO will be outdated, but INITIATE_BUS_RESET
      would still cause a bus reset, and GET_CYCLE_TIMER will return data.
      And if you guess the correct generation to use, you can send requests to
      a different device on the bus, and get responses back.
      
      This patch prevents open, ioctl, compat_ioctl, and mmap against shutdown
      devices.
      
      Signed-off-by: default avatarJay Fenlason <fenlason@redhat.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      551f4cb9
  7. Apr 18, 2008
    • Stefan Richter's avatar
      firewire: reread config ROM when device reset the bus · c9755e14
      Stefan Richter authored
      
      When a device changes its configuration ROM, it announces this with a
      bus reset.  firewire-core has to check which node initiated a bus reset
      and whether any unit directories went away or were added on this node.
      
      Tested with an IOI FWB-IDE01AB which has its link-on bit set if bus
      power is available but does not respond to ROM read requests if self
      power is off.  This implements
        - recognition of the units if self power is switched on after fw-core
          gave up the initial attempt to read the config ROM,
        - shutdown of the units when self power is switched off.
      
      Also tested with a second PC running Linux/ieee1394.  When the eth1394
      driver is inserted and removed on that node, fw-core now notices the
      addition and removal of the IPv4 unit on the ieee1394 node.
      
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      c9755e14
  8. Feb 21, 2008
  9. Feb 16, 2008
    • Stefan Richter's avatar
      firewire: fix "kobject_add failed for fw* with -EEXIST" · 96b19062
      Stefan Richter authored
      There is a race between shutdown and creation of devices:  fw-core may
      attempt to add a device with the same name of an already existing
      device.  http://bugzilla.kernel.org/show_bug.cgi?id=9828
      
      
      
      Impact of the bug:  Happens rarely (when shutdown of a device coincides
      with creation of another), forces the user to unplug and replug the new
      device to get it working.
      
      The fix is obvious:  Free the minor number *after* instead of *before*
      device_unregister().  This requires to take an additional reference of
      the fw_device as long as the IDR tree points to it.
      
      And while we are at it, we fix an additional race condition:
      fw_device_op_open() took its reference of the fw_device a little bit too
      late, hence was in danger to access an already invalid fw_device.
      
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      96b19062
  10. Jan 30, 2008
  11. Oct 16, 2007
  12. Oct 14, 2007
  13. Jul 09, 2007
  14. Jun 20, 2007
  15. May 31, 2007
  16. May 27, 2007
  17. May 10, 2007
  18. Apr 30, 2007
  19. Mar 28, 2007
  20. Mar 20, 2007
  21. Mar 15, 2007
Loading