On Fri, Dec 18, 2015 at 10:26 AM, Herbert Xu
wrote:
> On Fri, Dec 18, 2015 at 12:07:08AM +0800, Xin Long wrote:
>>
>> I'm just wondering, why do not we handle the genuine double rehash
>> issue inside rhashtable? i mean it's just a temporary error that a
>> simple retry may fix it.
>
> Because a d
On Fri, Dec 18, 2015 at 12:07:08AM +0800, Xin Long wrote:
>
> I'm just wondering, why do not we handle the genuine double rehash
> issue inside rhashtable? i mean it's just a temporary error that a
> simple retry may fix it.
Because a double rehash means that someone has cracked your hash
function
From: Xin Long
Date: Thu, 17 Dec 2015 17:00:35 +0800
> On Thu, Dec 17, 2015 at 4:48 PM, Herbert Xu
> wrote:
>> On Thu, Dec 17, 2015 at 04:46:00PM +0800, Xin Long wrote:
>>>
>>> sorry for late test, but unfortunately, my case with rhashtalbe still
>>> return EBUSY.
>>> I added some debug code in
On Thu, Dec 17, 2015 at 5:00 PM, Xin Long wrote:
> On Thu, Dec 17, 2015 at 4:48 PM, Herbert Xu
> wrote:
>> On Thu, Dec 17, 2015 at 04:46:00PM +0800, Xin Long wrote:
>>>
>>> sorry for late test, but unfortunately, my case with rhashtalbe still
>>> return EBUSY.
>>> I added some debug code in rhas
On Thu, Dec 17, 2015 at 4:48 PM, Herbert Xu wrote:
> On Thu, Dec 17, 2015 at 04:46:00PM +0800, Xin Long wrote:
>>
>> sorry for late test, but unfortunately, my case with rhashtalbe still
>> return EBUSY.
>> I added some debug code in rhashtable_insert_rehash(), and found:
>> *future_tbl is null*
>
On Thu, Dec 17, 2015 at 04:46:00PM +0800, Xin Long wrote:
>
> sorry for late test, but unfortunately, my case with rhashtalbe still
> return EBUSY.
> I added some debug code in rhashtable_insert_rehash(), and found:
> *future_tbl is null*
>
> fail:
> /* Do not fail the insert if someone el
On Thu, Dec 3, 2015 at 8:41 PM, Herbert Xu wrote:
> On Mon, Nov 30, 2015 at 06:18:59PM +0800, Herbert Xu wrote:
>>
>> OK that's better. I think I see the problem. The test in
>> rhashtable_insert_rehash is racy and if two threads both try
>> to grow the table one of them may be tricked into doin
From: Herbert Xu
Date: Thu, 3 Dec 2015 20:41:29 +0800
> Thomas and Phil observed that under stress rhashtable insertion
> sometimes failed with EBUSY, even though this error should only
> ever been seen when we're under attack and our hash chain length
> has grown to an unacceptable level, even a
On Thu, Dec 03, 2015 at 08:41:29PM +0800, Herbert Xu wrote:
> On Mon, Nov 30, 2015 at 06:18:59PM +0800, Herbert Xu wrote:
> >
> > OK that's better. I think I see the problem. The test in
> > rhashtable_insert_rehash is racy and if two threads both try
> > to grow the table one of them may be tri
On Mon, Nov 30, 2015 at 06:18:59PM +0800, Herbert Xu wrote:
>
> OK that's better. I think I see the problem. The test in
> rhashtable_insert_rehash is racy and if two threads both try
> to grow the table one of them may be tricked into doing a rehash
> instead.
>
> I'm working on a fix.
OK thi
10 matches
Mail list logo
