Re: [PATCH] lpfc: Read buffer overflow

[James Smart <James.Smart@Emulex.Com>]

James Bottomley wrote:
> I'd suggest not:
> 
> jejb@mulgrave:~/git/linux-2.6/drivers/scsi/lpfc> git grep 'max_vports && vports'|wc -l
> 17
> 
> Assuming this secures agreement as a patch, I don't really want to wade
> through another 16 patches for the remaining ones.  You definitely can't
> reduce the vport array length until they're all fixed.
> 
> What I hear is that it's not a problem, but it's a possible
> micro-optimisation.  Assuming the maintainer agrees, it's far better
> just to fix everything at once.  However, I'm equally happy to leave it
> as is since there's no actual problem given the allocation definition.
> 
>> What prevents the loop in lpfc_create_vport_work_array() from wandering
>> off the end of vports[], btw?
> 
> We refuse to create any vports beyond this number ... the iterator
> counts the number of created vports (it's actually a firmware limited
> number, I believe).
> 
> James

Agree. It's a style thing from one of the contributors to the driver.  There 
is no issue, I don't believe that optimizing 1 less pointer's worth of 
allocation is a big deal (good, yes, but...). However, I do recognize it is a 
much better coding style.

I'll roll the changes for it into the next driver patch set.  (Yes, it is a 
firmware limited number).

-- james s