Re: Kernel Panic in xen-blkfront.c:blkif_queue_request under 2.6.28

[Greg Harris <greg.harris@metacarta.com>]

----- "Jens Axboe" <jens.axboe@oracle.com> wrote:

Here is what I'm thinking is happening rewritten for clarity:

#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11 
int array[BLKIF_MAX_SEGMENTS_PER_REQUEST]; 

void write_segments( int number_of_segments )
  int nr_segments = 0;
  for( int x = 0; x < number_of_segments; x++ )
  {
    BUG_ON( nr_segments == BLKIF_MAX_SEGMENTS_PER_REQUEST );
    array[nr_segments] = get_segment_value(nr_segments);
    nr_segments ++ ;
  }
}

The BUG_ON is firing because the index into the number of segments is equal to BLKIF_MAX_SEGMENTS_PER_REQUEST which would require an array size of BLKIF_MAX_SEGMENTS_PER_REQUEST + 1 (more than has actually been allocated).

The kernel is being told that it should happily map up to BLKIF_MAX_SEGMENTS_PER_REQUEST segments which will fit in our array as allocated.  The BUG_ON is correctly firing because in the iteration over the number of segments our index has been incremented to a value that now points outside the boundary of our array.

-- Greg

> 
> > It sounds to me like the kernel itself may not be obeying the
> > requested segment limits here?
> 
> It's quite simple - if you tell the kernel that your segment limit is
> 8,
> then it will happily map up to 8 segments for you. So the mixture of
> setting a limit to foo and check calling BUG() if that limit is
> reached
> is crap, of obvious reasons. If you ask for 8 segments but can only
> hold
> 7, well...
> -- 
> Jens Axboe