1. 14 Jul, 2007 4 commits
    • Patrick McHardy's avatar
      [VLAN]: Fix promiscous/allmulti synchronization races · 6c78dcbd
      Patrick McHardy authored
      The set_multicast_list function may be called without holding the rtnl
      mutex, resulting in races when changing the underlying device's promiscous
      and allmulti state. Use the change_rx_mode hook, which is always invoked
      under the rtnl.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Patrick McHardy's avatar
      [NET]: dev_mcast: add multicast list synchronization helpers · a0a400d7
      Patrick McHardy authored
      The method drivers currently use to synchronize multicast lists is not
      very pretty:
      - walk the multicast list
      - search each entry on a copy of the previous list
      - if new add to lower device
      - walk the copy of the previous list
      - search each entry on the current list
      - if removed delete from lower device
      - copy entire list
      This patch adds a new field to struct dev_addr_list to store the
      synchronization state and adds two helper functions for synchronization
      and cleanup.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Patrick McHardy's avatar
      [NET]: Add net_device change_rx_mode callback · 24023451
      Patrick McHardy authored
      Currently the set_multicast_list (and set_rx_mode) callbacks are
      responsible for configuring the device according to the IFF_PROMISC,
      IFF_MULTICAST and IFF_ALLMULTI flags and the mc_list (and uc_list in
      case of set_rx_mode).
      These callbacks can be invoked from BH context without the rtnl_mutex
      by dev_mc_add/dev_mc_delete, which makes reading the device flags and
      promiscous/allmulti count racy. For real hardware drivers that just
      commit all changes to the hardware this is not a real problem since
      the stack guarantees to call them for every change, so at least the
      final call will not race and commit the correct configuration to the
      For software devices that want to synchronize promiscous and multicast
      state to an underlying device however this can cause corruption of the
      underlying device's flags or promisc/allmulti counts.
      When the software device is concurrently put in promiscous or allmulti
      mode while set_multicast_list is invoked from bottem half context, the
      device might synchronize the change to the underlying device without
      holding the rtnl_mutex, which races with concurrent changes to the
      underlying device.
      Add a dev->change_rx_flags hook that is invoked when any of the flags
      that affect rx filtering change (under the rtnl_mutex), which allows
      drivers to perform synchronization immediately and only synchronize
      the address lists in set_multicast_list/set_rx_mode.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Ingo Molnar's avatar
      [RFKILL]: fix net/rfkill/rfkill-input.c bug on 64-bit systems · e6c9116d
      Ingo Molnar authored
      Subject: [patch] net/input: fix net/rfkill/rfkill-input.c bug on 64-bit systems
      this recent commit:
       commit cf4328cd
       Author: Ivo van Doorn <IvDoorn@gmail.com>
       Date:   Mon May 7 00:34:20 2007 -0700
           [NET]: rfkill: add support for input key to control wireless radio
      added this 64-bit bug:
      	unsigned int flags;
       	spin_lock_irqsave(&task->lock, flags);
      irq 'flags' must be unsigned long, not unsigned int. The -rt tree has 
      strict checks about this on 64-bit so this triggered a build failure. 
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 13 Jul, 2007 1 commit
    • Dan Williams's avatar
      dmaengine: make clients responsible for managing channels · d379b01e
      Dan Williams authored
      The current implementation assumes that a channel will only be used by one
      client at a time.  In order to enable channel sharing the dmaengine core is
      changed to a model where clients subscribe to channel-available-events.
      Instead of tracking how many channels a client wants and how many it has
      received the core just broadcasts the available channels and lets the
      clients optionally take a reference.  The core learns about the clients'
      needs at dma_event_callback time.
      In support of multiple operation types, clients can specify a capability
      mask to only be notified of channels that satisfy a certain set of
      * removed DMA_TX_ARRAY_INIT, no longer needed
      * dma_client_chan_free -> dma_chan_release: switch to global reference
        counting only at device unregistration time, before it was also happening
        at client unregistration time
      * clients now return dma_state_client to dmaengine (ack, dup, nak)
      * checkpatch.pl fixes
      * fixup merge with git-ioat
      Cc: Chris Leech <christopher.leech@intel.com>
      Signed-off-by: default avatarShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 11 Jul, 2007 16 commits
  4. 10 Jul, 2007 19 commits