On 29/05/2013 23:09, Ben Hutchings wrote:
On Wed, 2013-05-29 at 09:39 +0300, Eliezer Tamir wrote:+void napi_hash_add(struct napi_struct *napi) +{ + if (!test_and_set_bit(NAPI_STATE_HASHED, &napi->state)) { + + spin_lock(&napi_hash_lock); + + /* 0 is not a valid id */ + napi->napi_id = 0; + while (!napi->napi_id) + napi->napi_id = ++napi_gen_id;Suppose we're loading/unloading one driver repeatedly while another one remains loaded the whole time. Then once napi_gen_id wraps around, the same ID can be assigned to multiple contexts. So far as I can see, assigning the same ID twice will just make polling stop working for one of the NAPI contexts; I don't think it causes a crash. And it is exceedingly unlikely to happen in production. But if you're going to the trouble of handling wrap-around at all, you'd better handle this.
OK
[...]+/* must be called under rcu_read_lock(), as we dont take a reference */ +struct napi_struct *napi_by_id(int napi_id) +{ + unsigned int hash = napi_id % HASH_SIZE(napi_hash);[...] napi_id should be declared unsigned int here, as elsewhere. The division can't actually yield a negative result because HASH_SIZE() has type size_t and napi_id is promoted to match, but I had to go and look at hashtable.h to check that.
Good catch, Thanks, Eliezer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
