Yi Zou wrote: > Add tracking the Virtual Link Failure count when either we have found > the FCF as "aged" or we are receiving FIP Clear Virtual Link from the > FCF. > > Signed-off-by: Yi Zou <[email protected]> > --- > > drivers/scsi/fcoe/libfcoe.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/scsi/fcoe/libfcoe.c b/drivers/scsi/fcoe/libfcoe.c > index 9961fd7..e2e0065 100644 > --- a/drivers/scsi/fcoe/libfcoe.c > +++ b/drivers/scsi/fcoe/libfcoe.c > @@ -578,6 +578,7 @@ static void fcoe_ctlr_age_fcfs(struct fcoe_ctlr *fip) > WARN_ON(!fip->fcf_count); > fip->fcf_count--; > kfree(fcf); > + fc_lport_get_stats(fip->lp)->VLinkFailureCount++; > } else if (fcoe_ctlr_mtu_valid(fcf) && > (!sel_time || time_before(sel_time, fcf->time))) { > sel_time = fcf->time; > @@ -989,6 +990,8 @@ static void fcoe_ctlr_recv_clr_vlink(struct fcoe_ctlr > *fip, > } else { > LIBFCOE_FIP_DBG(fip, "performing Clear Virtual Link\n"); > > + fc_lport_get_stats(lport)->VLinkFailureCount++;
A side point, not necessarily part of this patch, but when incrementing a per-cpu counter, it's possible to be pre-empted and resumed on another CPU, resulting in incrementing the counter for the first CPU from the second CPU. That means it should be either atomic, or surrounded by get_cpu(), put_cpu(). It would also be fine to put this inside the fip->lock below, so it didn't need to be atomic as long as the only increments to that particular counter were under the fip->lock. This isn't a critical thing, and it's unlikely that losing a count would be noticed, but I thought I'd point it out anyway. > + > spin_lock_bh(&fip->lock); > fcoe_ctlr_reset(fip); > spin_unlock_bh(&fip->lock); > > _______________________________________________ > devel mailing list > [email protected] > http://www.open-fcoe.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
