1. 28 Jul, 2010 6 commits
  2. 27 Jul, 2010 4 commits
    • Joe Eykholt's avatar
      [SCSI] libfc: fix indefinite rport restart · f034260d
      Joe Eykholt authored
      
      
      Remote ports were restarting indefinitely after getting
      rejects in PRLI.
      
      Fix by adding a counter of restarts and limiting that with
      the port login retry limit as well.
      Signed-off-by: default avatarJoe Eykholt <jeykholt@cisco.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      f034260d
    • Joe Eykholt's avatar
      [SCSI] libfc: Fix remote port restart problem · 4b2164d4
      Joe Eykholt authored
      
      
      This patch somewhat combines two fixes to remote port handing in libfc.
      
      The first problem was that rport work could be queued on a deleted
      and freed rport.  This is handled by not resetting rdata->event
      ton NONE if the rdata is about to be deleted.
      
      However, that fix led to the second problem, described by
      Bhanu Gollapudi, as follows:
      > Here is the sequence of events. T1 is first LOGO receive thread, T2 is
      > fc_rport_work() scheduled by T1 and T3 is second LOGO receive thread and
      > T4 is fc_rport_work scheduled by T3.
      >
      > 1. (T1)Received 1st LOGO in state Ready
      > 2. (T1)Delete port & enter to RESTART state.
      > 3. (T1)schdule event_work, since event is RPORT_EV_NONE.
      > 4. (T1)set event = RPORT_EV_LOGO
      > 5. (T1)Enter RESTART state as disc_id is set.
      > 6. (T2)remember to PLOGI, and set event = RPORT_EV_NONE
      > 6. (T3)Received 2nd LOGO
      > 7. (T3)Delete Port & enter to RESTART state.
      > 8. (T3)schedule event_work, since event is RPORT_EV_NONE.
      > 9. (T3)Enter RESTART state as disc_id is set.
      > 9. (T3)set event = RPORT_EV_LOGO
      > 10.(T2)work restart, enter PLOGI state and issues PLOGI
      > 11.(T4)Since state is not RESTART anymore, restart is not set, and the
      > event is not reset to RPORT_EV_NONE. (current event is RPORT_EV_LOGO).
      > 12. Now, PLOGI succeeds and fc_rport_enter_ready() will not schedule
      > event_work, and hence the rport will never be created, eventually losing
      > the target after dev_loss_tmo.
      
      So, the problem here is that we were tracking the desire for
      the rport be restarted by state RESTART, which was otherwise
      equivalent to DELETE.  A contributing factor is that we dropped
      the lock between steps 6 and 10 in thread T2, which allows the
      state to change, and we didn't completely re-evaluate then.
      
      This is hopefully corrected by the following minor redesign:
      
      Simplify the rport restart logic by making the decision to
      restart after deleting the transport rport.  That decision
      is based on a new STARTED flag that indicates fc_rport_login()
      has been called and fc_rport_logoff() has not been called
      since then.  This replaces the need for the RESTART state.
      
      Only restart if the rdata is still in DELETED state
      and only if it still has the STARTED flag set.
      
      Also now, since we clear the event code much later in the
      work thread, allow for the possibility that the rport may
      have become READY again via incoming PLOGI, and if so,
      queue another event to handle that.
      
      In the problem scenario, the second LOGO received will
      cause the LOGO event to occur again.
      Reported-by: default avatarBhanu Gollapudi <bprakash@broadcom.com>
      Signed-off-by: default avatarJoe Eykholt <jeykholt@cisco.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      4b2164d4
    • Bhanu Prakash Gollapudi's avatar
      [SCSI] libfc: Handle unsolicited PRLO request · f8fc6c2c
      Bhanu Prakash Gollapudi authored
      
      
      Resubmitting after incorporating Joe's review comment.
      
      Unsolicited PRLO request is now handled by sending LS_ACC,
      and then relogin to the remote port if an N-port login
      session exists for that remote port.
      
      Note that this patch should be applied on top of Joe Eykholt's
      "Fix remote port restart problem" patch.
      Signed-off-by: default avatarBhanu Prakash Gollapudi <bprakash@broadcom.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      f8fc6c2c
    • Joe Eykholt's avatar
      [SCSI] fcoe: clean up TBD comments in FCoE prototype header · 5d4a2e29
      Joe Eykholt authored
      
      
      Some old comments in fc_fcoe.h say TBD long after the
      standard has been passed by T11.  Clean them up.
      Signed-off-by: default avatarJoe Eykholt <jeykholt@cisco.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      5d4a2e29
  3. 10 Jun, 2010 1 commit
    • John Fastabend's avatar
      net: deliver skbs on inactive slaves to exact matches · 597a264b
      John Fastabend authored
      
      
      Currently, the accelerated receive path for VLAN's will
      drop packets if the real device is an inactive slave and
      is not one of the special pkts tested for in
      skb_bond_should_drop().  This behavior is different then
      the non-accelerated path and for pkts over a bonded vlan.
      
      For example,
      
      vlanx -> bond0 -> ethx
      
      will be dropped in the vlan path and not delivered to any
      packet handlers at all.  However,
      
      bond0 -> vlanx -> ethx
      
      and
      
      bond0 -> ethx
      
      will be delivered to handlers that match the exact dev,
      because the VLAN path checks the real_dev which is not a
      slave and netif_recv_skb() doesn't drop frames but only
      delivers them to exact matches.
      
      This patch adds a sk_buff flag which is used for tagging
      skbs that would previously been dropped and allows the
      skb to continue to skb_netif_recv().  Here we add
      logic to check for the deliver_no_wcard flag and if it
      is set only deliver to handlers that match exactly.  This
      makes both paths above consistent and gives pkt handlers
      a way to identify skbs that come from inactive slaves.
      Without this patch in some configurations skbs will be
      delivered to handlers with exact matches and in others
      be dropped out right in the vlan path.
      
      I have tested the following 4 configurations in failover modes
      and load balancing modes.
      
      # bond0 -> ethx
      
      # vlanx -> bond0 -> ethx
      
      # bond0 -> vlanx -> ethx
      
      # bond0 -> ethx
                  |
        vlanx -> --
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      597a264b
  4. 09 Jun, 2010 1 commit
    • Alan Cox's avatar
      misc: Fix allocation 'borrowed' by vhost_net · 79907d89
      Alan Cox authored
      
      
      10, 233 is allocated officially to /dev/kmview which is shipping in
      Ubuntu and Debian distributions.  vhost_net seem to have borrowed it
      without making a proper request and this causes regressions in the other
      distributions.
      
      vhost_net can use a dynamic minor so use that instead.  Also update the
      file with a comment to try and avoid future misunderstandings.
      
      cc: stable@kernel.org
      Signed-off-by: default avatarAlan Cox <device@lanana.org>
      [ We should have caught this before 2.6.34 got released.  - Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      79907d89
  5. 08 Jun, 2010 2 commits
    • Dave Chinner's avatar
      writeback: pay attention to wbc->nr_to_write in write_cache_pages · 0b564927
      Dave Chinner authored
      If a filesystem writes more than one page in ->writepage, write_cache_pages
      fails to notice this and continues to attempt writeback when wbc->nr_to_write
      has gone negative - this trace was captured from XFS:
      
          wbc_writeback_start: towrt=1024
          wbc_writepage: towrt=1024
          wbc_writepage: towrt=0
          wbc_writepage: towrt=-1
          wbc_writepage: towrt=-5
          wbc_writepage: towrt=-21
          wbc_writepage: towrt=-85
      
      This has adverse effects on filesystem writeback behaviour. write_cache_pages()
      needs to terminate after a certain number of pages are written, not after a
      certain number of calls to ->writepage are made.  This is a regression
      introduced by 17bc6c30
      
       ("vfs: Add
      no_nrwrite_index_update writeback control flag"), but cannot be reverted
      directly due to subsequent bug fixes that have gone in on top of it.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0b564927
    • Oleg Nesterov's avatar
      tracing: Fix null pointer deref with SEND_SIG_FORCED · b9b76dfa
      Oleg Nesterov authored
      
      
      BUG: unable to handle kernel NULL pointer dereference at
      	0000000000000006
      IP: [<ffffffff8107bd37>] ftrace_raw_event_signal_generate+0x87/0x140
      
      TP_STORE_SIGINFO() forgets about SEND_SIG_FORCED, fix.
      
      We should probably export is_si_special() and change TP_STORE_SIGINFO()
      to use it in the longer term.
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarRoland McGrath <roland@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Cc: 2.6.33.x-2.6.34.x <stable@kernel.org>
      LKML-Reference: <20100603213409.GA8307@redhat.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      b9b76dfa
  6. 07 Jun, 2010 2 commits
  7. 04 Jun, 2010 6 commits
  8. 03 Jun, 2010 1 commit
  9. 02 Jun, 2010 4 commits
  10. 01 Jun, 2010 6 commits
  11. 31 May, 2010 7 commits