1. 26 Jan, 2008 9 commits
  2. 25 Jan, 2008 1 commit
    • Gautham R Shenoy's avatar
      cpu-hotplug: replace lock_cpu_hotplug() with get_online_cpus() · 86ef5c9a
      Gautham R Shenoy authored
      Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
      get_online_cpus and put_online_cpus instead as it highlights the
      refcount semantics in these operations.
      The new API guarantees protection against the cpu-hotplug operation, but
      it doesn't guarantee serialized access to any of the local data
      structures. Hence the changes needs to be reviewed.
      In case of pseries_add_processor/pseries_remove_processor, use
      cpu_maps_update_begin()/cpu_maps_update_done() as we're modifying the
      cpu_present_map there.
      Signed-off-by: default avatarGautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  3. 24 Jan, 2008 2 commits
  4. 11 Jan, 2008 12 commits
  5. 11 Dec, 2007 1 commit
    • Julia Lawall's avatar
      [S390]: Fix use of skb after netif_rx · 9b3efc01
      Julia Lawall authored
      Recently, Wang Chen submitted a patch
      (d30f53ae) to move a call to netif_rx(skb)
      after a subsequent reference to skb, because netif_rx may call kfree_skb on
      its argument.  netif_rx_ni calls netif_rx, so the same problem occurs in
      the files below.
      I have left the updating of dev->last_rx after the calls to netif_rx_ni
      because it seems time dependent, but moved the other field updates before.
      This was found using the following semantic match.
      // <smpl>
      expression skb, e,e1;
        ... when != skb = e
        skb = e1
      * skb
      // </smpl>
      Signed-off-by: default avatarJulia Lawall <julia@diku.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  6. 04 Dec, 2007 4 commits
  7. 01 Dec, 2007 1 commit
  8. 20 Nov, 2007 2 commits
  9. 16 Nov, 2007 2 commits
    • Martin Peschke's avatar
      [SCSI] zfcp: fix cleanup of dismissed error recovery actions · 86e8dfc5
      Martin Peschke authored
      Calling zfcp_erp_strategy_check_action() after zfcp_erp_action_to_running()
      in zfcp_erp_strategy() might cause an unbalanced up() for erp_ready_sem,
      which makes the zfcp recovery fail somewhere along the way:
      erp thread processing erp_action:
      |	someone waking up erp thread for erp_action
      |	|
      |	|		someone else dismissing erp_action:
      |	|		|
      V	V		V
      	write_lock_irqsave(&adapter->erp_lock, flags);
      	if (zfcp_erp_action_exists(erp_action) == ZFCP_ERP_ACTION_RUNNING) {
      		up(&adapter->erp_ready_sem);	/* first up() for erp_action */
      	write_unlock_irqrestore(&adapter->erp_lock, flags);
      write_lock_irqsave(&adapter->erp_lock, flags);
      write_unlock_restore(&adapter->erp_lock, flags);
      /* processing erp_action */
      			write_lock_irqsave(&adapter->erp_lock, flags);
      			erp_action->status |= ZFCP_STATUS_ERP_DISMISSED;
      			if (zfcp_erp_action_exists(erp_action) ==
      				/* second, unbalanced up() for erp_action */
      			write_unlock_restore(&adapter->erp_lock, flags);
      write_lock_irqsave(&adapter->erp_lock, flags);
      if (erp_action->status & ZFCP_STATUS_ERP_DISMISSED) {
      	retval = ZFCP_ERP_DISMISSED;
      write_unlock_restore(&adapter->erp_lock, flags);
      /* this down() is meant to balance the first up() */
      The erp thread must not dismiss an erp_action after moving that action to
      erp_running_head. Instead it should just go through the down() operation,
      which balances the first up(), and run through zfcp_erp_strategy one more
      time for the second up(), which eventually cleans up erp_action. Which
      is similar to the normal processing of an event for erp_action doing
      something asynchronously (e.g. waiting for the completion of an fsf_req).
      This only works if we make sure that a dismissed erp_action is passed to
      zfcp_erp_strategy() prior to the other action, which caused actions to be
      dismissed. Therefore the patch implements this rule: running actions go to
      the head of the ready list; new actions go to the tail of the ready list;
      the erp thread picks actions to be processed from the ready list's head.
      Signed-off-by: default avatarMartin Peschke <mp3@de.ibm.com>
      Acked-by: default avatarSwen Schillig <swen@vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
    • Martin Peschke's avatar
      [SCSI] zfcp: fix dismissal of error recovery actions · d0076f77
      Martin Peschke authored
      zfcp_erp_action_dismiss() used to ignore any actions in the ready list. This
      is a bug. Any action superseded by a stronger action needs to be dismissed.
      This patch changes zfcp_erp_action_dismiss() so that it dismisses actions
      regardless of their list affiliation. The ERP thread is able to handle this.
      It is important to kick the erp thread only for actions in the running list,
      though, as an imbalance of wakeup signals would confuse the erp thread
      Signed-off-by: default avatarMartin Peschke <mp3@de.ibm.com>
      Acked-by: default avatarSwen Schillig <swen@vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
  10. 05 Nov, 2007 4 commits
  11. 29 Oct, 2007 1 commit
  12. 24 Oct, 2007 1 commit