win-pvdrivers

changeset 182:1034a8ecd391

xennet: handle if rxrsp status is not positive
remove some ifdefed-out code
comment tweaks
author Andy Grover <andy.grover@oracle.com>
date Mon Feb 11 16:18:30 2008 -0800 (2008-02-11)
parents 762547e8a0db
children f2774dbb6257
files xennet/xennet.c
line diff
     1.1 --- a/xennet/xennet.c	Mon Feb 11 15:54:10 2008 -0800
     1.2 +++ b/xennet/xennet.c	Mon Feb 11 16:18:30 2008 -0800
     1.3 @@ -456,8 +456,15 @@ XenNet_RxBufferCheck(struct xennet_info 
     1.4      KeMemoryBarrier(); /* Ensure we see responses up to 'rp'. */
     1.5  
     1.6      for (cons = xi->rx.rsp_cons; cons != prod; cons++) {
     1.7 +
     1.8        rxrsp = RING_GET_RESPONSE(&xi->rx, cons);
     1.9 -      ASSERT(rxrsp->status > 0);
    1.10 +      if (rxrsp->status <= 0
    1.11 +        || rxrsp->offset + rxrsp->status > PAGE_SIZE)
    1.12 +      {
    1.13 +        KdPrint((__DRIVER_NAME ": Error: rxrsp offset %d, size %d\n",
    1.14 +          rxrsp->offset, rxrsp->status));
    1.15 +        continue;
    1.16 +      }
    1.17  
    1.18        if (!more_frags) // handling the packet's 1st buffer
    1.19        {
    1.20 @@ -474,13 +481,6 @@ XenNet_RxBufferCheck(struct xennet_info 
    1.21          xi->grant_rx_ref[rxrsp->id]);
    1.22        xi->grant_rx_ref[rxrsp->id] = GRANT_INVALID_REF;
    1.23  
    1.24 -#if 0
    1.25 -      KdPrint((__DRIVER_NAME "     Flags = %sNETRXF_data_validated|%sNETRXF_csum_blank|%sNETRXF_more_data|%sNETRXF_extra_info\n",
    1.26 -        (rxrsp->flags&NETRXF_data_validated)?"":"!",
    1.27 -        (rxrsp->flags&NETRXF_csum_blank)?"":"!",
    1.28 -        (rxrsp->flags&NETRXF_more_data)?"":"!",
    1.29 -        (rxrsp->flags&NETRXF_extra_info)?"":"!"));
    1.30 -#endif
    1.31        ASSERT(!(rxrsp->flags & NETRXF_extra_info)); // not used on RX
    1.32  
    1.33        more_frags = rxrsp->flags & NETRXF_more_data;
    1.34 @@ -1544,16 +1544,7 @@ XenNet_SendPackets(
    1.35    PLIST_ENTRY entry;
    1.36    KIRQL OldIrql;
    1.37  
    1.38 -#if 0
    1.39 -  for (i = 0; i < NumberOfPackets; i++)
    1.40 -  {
    1.41 -    curr_packet = PacketArray[i];
    1.42 -    NdisMSendComplete(xi->adapter_handle, curr_packet, NDIS_STATUS_FAILURE);
    1.43 -  }
    1.44 -  return;
    1.45 -#endif
    1.46 -
    1.47 -//  KdPrint((__DRIVER_NAME " --> " __FUNCTION__ "\n"));
    1.48 +  //  KdPrint((__DRIVER_NAME " --> " __FUNCTION__ "\n"));
    1.49    for (i = 0; i < NumberOfPackets; i++)
    1.50    {
    1.51      curr_packet = PacketArray[i];
    1.52 @@ -1583,7 +1574,7 @@ XenNet_SendPackets(
    1.53      InterlockedIncrement(&xi->tx_outstanding);
    1.54    }
    1.55    XenNet_SendQueuedPackets(xi);
    1.56 -//  KdPrint((__DRIVER_NAME " <-- " __FUNCTION__ "\n"));
    1.57 +  //  KdPrint((__DRIVER_NAME " <-- " __FUNCTION__ "\n"));
    1.58  }
    1.59  
    1.60  VOID
    1.61 @@ -1661,7 +1652,7 @@ XenNet_Halt(
    1.62      KeWaitForSingleObject(&xi->backend_state_change_event, Executive,
    1.63        KernelMode, FALSE, NULL);
    1.64  
    1.65 -  // this disables the interrupt
    1.66 +  // Disables the interrupt
    1.67    XenNet_Shutdown(xi);
    1.68  
    1.69    xi->connected = FALSE;
    1.70 @@ -1771,8 +1762,6 @@ DriverEntry(
    1.71    mini_chars.PnPEventNotifyHandler = XenNet_PnPEventNotify;
    1.72    mini_chars.AdapterShutdownHandler = XenNet_Shutdown;
    1.73  
    1.74 -  /* TODO: we don't have hardware, but we have "resources", so do we need to implement fns to handle this? */
    1.75 -
    1.76    /* set up upper-edge interface */
    1.77    status = NdisMRegisterMiniport(ndis_wrapper_handle, &mini_chars, sizeof(mini_chars));
    1.78    if (!NT_SUCCESS(status))