Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[Weidong Wang]

On 2015/9/24 13:34, David Miller wrote:
> From: Weidong Wang 
> Date: Thu, 24 Sep 2015 10:00:45 +0800
> 
>> It does affect the intention. Although, the problem exists then makes the
>> system panic within some case.
>>
>> Do you have any idea about it?
> 
> Allocate the statistics block at probe time so that this problem is
> impossible.
> 

It is a good idea.

Yet, what is the intention of the dynamic to alloc/free stats_block?
what will be affected by allocating the statistics block.

Best Regards,
Weidong

> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[Weidong Wang]

On 2015/9/24 13:34, David Miller wrote:
> From: Weidong Wang 
> Date: Thu, 24 Sep 2015 10:00:45 +0800
> 
>> It does affect the intention. Although, the problem exists then makes the
>> system panic within some case.
>>
>> Do you have any idea about it?
> 
> Allocate the statistics block at probe time so that this problem is
> impossible.
> 

It is a good idea.

Yet, what is the intention of the dynamic to alloc/free stats_block?
what will be affected by allocating the statistics block.

Best Regards,
Weidong

> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[David Miller]

From: Weidong Wang 
Date: Thu, 24 Sep 2015 10:00:45 +0800

> It does affect the intention. Although, the problem exists then makes the
> system panic within some case.
> 
> Do you have any idea about it?

Allocate the statistics block at probe time so that this problem is
impossible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[Weidong Wang]

On 2015/9/24 6:31, David Miller wrote:
> From: Weidong Wang 
> Date: Tue, 22 Sep 2015 20:42:40 +0800
> 
>> @@ -880,6 +882,7 @@ bnx2_alloc_mem(struct bnx2 *bp)
>>  }
>>  }
>>
>> +spin_lock(>stats64_lock);
>>  bp->stats_blk = status_blk + status_blk_size;
>>
>>  bp->stats_blk_mapping = bp->status_blk_mapping + status_blk_size;
>> @@ -894,20 +897,23 @@ bnx2_alloc_mem(struct bnx2 *bp)
>>  >ctx_blk_mapping[i],
>>  GFP_KERNEL);
>>  if (bp->ctx_blk[i] == NULL)
>> -goto alloc_mem_err;
>> +goto free_stats64_lock;
>>  }
>>  }
>>
>>  err = bnx2_alloc_rx_mem(bp);
>>  if (err)
>> -goto alloc_mem_err;
>> +goto free_stats64_lock;
> 
> You're holding a spinlock while doing GFP_KERNEL allocations.
> 

hm, yep, I should move it after the allocations. Like this:

@@ -880,7 +882,9 @@ bnx2_alloc_mem(struct bnx2 *bp)
}
}

+   spin_lock(>stats64_lock);
bp->stats_blk = status_blk + status_blk_size;
+   spin_unlock(>stats64_lock);

the allocations won't use the stats_blk, so I shouldn't hold the
lock while doing allocations.

> Second of all, taking a spinlock in get_stats64() defeats the whole
> intention of making statistics acquisition as fast and as SMP scalable
> as possible.
> 

It does affect the intention. Although, the problem exists then makes the
system panic within some case.

Do you have any idea about it?

Best Regards,
Weidong

> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[David Miller]

From: Weidong Wang 
Date: Tue, 22 Sep 2015 20:42:40 +0800

> @@ -880,6 +882,7 @@ bnx2_alloc_mem(struct bnx2 *bp)
>   }
>   }
> 
> + spin_lock(>stats64_lock);
>   bp->stats_blk = status_blk + status_blk_size;
> 
>   bp->stats_blk_mapping = bp->status_blk_mapping + status_blk_size;
> @@ -894,20 +897,23 @@ bnx2_alloc_mem(struct bnx2 *bp)
>   >ctx_blk_mapping[i],
>   GFP_KERNEL);
>   if (bp->ctx_blk[i] == NULL)
> - goto alloc_mem_err;
> + goto free_stats64_lock;
>   }
>   }
> 
>   err = bnx2_alloc_rx_mem(bp);
>   if (err)
> - goto alloc_mem_err;
> + goto free_stats64_lock;

You're holding a spinlock while doing GFP_KERNEL allocations.

Second of all, taking a spinlock in get_stats64() defeats the whole
intention of making statistics acquisition as fast and as SMP scalable
as possible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[David Miller]

From: Weidong Wang 
Date: Tue, 22 Sep 2015 20:42:40 +0800

> @@ -880,6 +882,7 @@ bnx2_alloc_mem(struct bnx2 *bp)
>   }
>   }
> 
> + spin_lock(>stats64_lock);
>   bp->stats_blk = status_blk + status_blk_size;
> 
>   bp->stats_blk_mapping = bp->status_blk_mapping + status_blk_size;
> @@ -894,20 +897,23 @@ bnx2_alloc_mem(struct bnx2 *bp)
>   >ctx_blk_mapping[i],
>   GFP_KERNEL);
>   if (bp->ctx_blk[i] == NULL)
> - goto alloc_mem_err;
> + goto free_stats64_lock;
>   }
>   }
> 
>   err = bnx2_alloc_rx_mem(bp);
>   if (err)
> - goto alloc_mem_err;
> + goto free_stats64_lock;

You're holding a spinlock while doing GFP_KERNEL allocations.

Second of all, taking a spinlock in get_stats64() defeats the whole
intention of making statistics acquisition as fast and as SMP scalable
as possible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[Weidong Wang]

On 2015/9/24 6:31, David Miller wrote:
> From: Weidong Wang 
> Date: Tue, 22 Sep 2015 20:42:40 +0800
> 
>> @@ -880,6 +882,7 @@ bnx2_alloc_mem(struct bnx2 *bp)
>>  }
>>  }
>>
>> +spin_lock(>stats64_lock);
>>  bp->stats_blk = status_blk + status_blk_size;
>>
>>  bp->stats_blk_mapping = bp->status_blk_mapping + status_blk_size;
>> @@ -894,20 +897,23 @@ bnx2_alloc_mem(struct bnx2 *bp)
>>  >ctx_blk_mapping[i],
>>  GFP_KERNEL);
>>  if (bp->ctx_blk[i] == NULL)
>> -goto alloc_mem_err;
>> +goto free_stats64_lock;
>>  }
>>  }
>>
>>  err = bnx2_alloc_rx_mem(bp);
>>  if (err)
>> -goto alloc_mem_err;
>> +goto free_stats64_lock;
> 
> You're holding a spinlock while doing GFP_KERNEL allocations.
> 

hm, yep, I should move it after the allocations. Like this:

@@ -880,7 +882,9 @@ bnx2_alloc_mem(struct bnx2 *bp)
}
}

+   spin_lock(>stats64_lock);
bp->stats_blk = status_blk + status_blk_size;
+   spin_unlock(>stats64_lock);

the allocations won't use the stats_blk, so I shouldn't hold the
lock while doing allocations.

> Second of all, taking a spinlock in get_stats64() defeats the whole
> intention of making statistics acquisition as fast and as SMP scalable
> as possible.
> 

It does affect the intention. Although, the problem exists then makes the
system panic within some case.

Do you have any idea about it?

Best Regards,
Weidong

> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[David Miller]

From: Weidong Wang 
Date: Thu, 24 Sep 2015 10:00:45 +0800

> It does affect the intention. Although, the problem exists then makes the
> system panic within some case.
> 
> Do you have any idea about it?

Allocate the statistics block at probe time so that this problem is
impossible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/