Messages in this thread | | | From | NeilBrown <> | Date | Sun, 06 May 2018 07:48:20 +1000 | Subject | Re: [PATCH 4/8] rhashtable: fix race in nested_table_alloc() |
| |
On Sat, May 05 2018, Herbert Xu wrote:
> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> If two threads run nested_table_alloc() at the same time >> they could both allocate a new table. >> Best case is that one of them will never be freed, leaking memory. >> Worst case is hat entry get stored there before it leaks, >> and the are lost from the table. >> >> So use cmpxchg to detect the race and free the unused table. >> >> Fixes: da20420f83ea ("rhashtable: Add nested tables") >> Cc: stable@vger.kernel.org # 4.11+ >> Signed-off-by: NeilBrown <neilb@suse.com> > > What about the spinlock that's meant to be held around this > operation?
The spinlock protects 2 or more buckets. The nested table contains at least 512 buckets, maybe more. It is quite possible for two insertions into 2 different buckets to both get their spinlock and both try to instantiate the same nested table.
Thanks, NeilBrown [unhandled content-type:application/pgp-signature] | |