Re: rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-18 Thread Xin Long
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

Re: rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-17 Thread Herbert Xu
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

Re: rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-17 Thread Xin Long
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

Re: rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-17 Thread Xin Long
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

Re: rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-17 Thread Xin Long
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

Re: rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-17 Thread David Miller
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

Re: rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-17 Thread Herbert Xu
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

Re: rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-04 Thread David Miller
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

rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-03 Thread Herbert Xu
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

Re: rhashtable: Prevent spurious EBUSY errors on insertion

2015-12-03 Thread Phil Sutter
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