* rhashtable: how to deal with that rhashtable_lookup_insert_key return -EBUSY
@ 2015-11-20 5:14 Xin Long
2015-11-20 12:24 ` Phil Sutter
0 siblings, 1 reply; 3+ messages in thread
From: Xin Long @ 2015-11-20 5:14 UTC (permalink / raw)
To: linux-kernel, network dev; +Cc: tgraf, herbert, davem
when I use rhashtable_lookup_insert_key, sometimes it will return -EBUSY.
im not sure if there is a good way to workabout it.
or I should just try again and again until it's inserted successfully ?
I have seen some use in kernel by now, but it seems that no one consider
this issue for their cases. but it indeed exists in my case.
did I use it incorrectly or something else ?
Thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: rhashtable: how to deal with that rhashtable_lookup_insert_key return -EBUSY
2015-11-20 5:14 rhashtable: how to deal with that rhashtable_lookup_insert_key return -EBUSY Xin Long
@ 2015-11-20 12:24 ` Phil Sutter
2015-11-20 12:25 ` Herbert Xu
0 siblings, 1 reply; 3+ messages in thread
From: Phil Sutter @ 2015-11-20 12:24 UTC (permalink / raw)
To: Xin Long; +Cc: linux-kernel, network dev, tgraf, herbert, davem
On Fri, Nov 20, 2015 at 01:14:18PM +0800, Xin Long wrote:
> when I use rhashtable_lookup_insert_key, sometimes it will return -EBUSY.
> im not sure if there is a good way to workabout it.
> or I should just try again and again until it's inserted successfully ?
>
> I have seen some use in kernel by now, but it seems that no one consider
> this issue for their cases. but it indeed exists in my case.
>
> did I use it incorrectly or something else ?
AFAIK, insert returning -EBUSY is a situation users have to be aware of
and retry the insert. I sent a patch[1] to fix this in test_rhashtable.
That patch though retried in case of -ENOMEM as well, which was
considered wrong to do and therefore it wasn't accepted. But in my test
runs, -ENOMEM happened quite frequently and it also wasn't a permanent
error. For details, see the following discussion[2].
Herbert, did you manage to reproduce the problem meanwhile? If so, was
there any progress on fixing rhashtable? Otherwise, I could respin my
patch from [1] to cover only -EBUSY case by default and add a parameter
to make non-permanent -ENOMEM visible.
Cheers, Phil
[1]: https://lkml.org/lkml/2015/8/28/197
[2]: https://lkml.org/lkml/2015/8/28/281
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: rhashtable: how to deal with that rhashtable_lookup_insert_key return -EBUSY
2015-11-20 12:24 ` Phil Sutter
@ 2015-11-20 12:25 ` Herbert Xu
0 siblings, 0 replies; 3+ messages in thread
From: Herbert Xu @ 2015-11-20 12:25 UTC (permalink / raw)
To: Phil Sutter, Xin Long, linux-kernel, network dev, tgraf, davem
On Fri, Nov 20, 2015 at 01:24:01PM +0100, Phil Sutter wrote:
>
> Herbert, did you manage to reproduce the problem meanwhile? If so, was
> there any progress on fixing rhashtable? Otherwise, I could respin my
> patch from [1] to cover only -EBUSY case by default and add a parameter
> to make non-permanent -ENOMEM visible.
No I have not been able to reproduce this yet.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-20 12:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-11-20 5:14 rhashtable: how to deal with that rhashtable_lookup_insert_key return -EBUSY Xin Long
2015-11-20 12:24 ` Phil Sutter
2015-11-20 12:25 ` Herbert Xu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox