Re: [PATCH] Fix a race in pid generation that causes pids to bereused immediately.

[tytso]

On Wed, Jun 09, 2010 at 09:06:37AM -0700, Linus Torvalds wrote:
> 
> That seems to be purely an artifact of the cleverness of avoiding re-doing 
> the whole loop, no? If we _had_ re-done the whole loop (the "normal" 
> cmpxchg model), we would have re-started the whole pid search and handled 
> the overflow in the existing overflow handling code.

This brings up a question.  If we're going to use a cmpxchg() loop, is
there any point to doing the test-and-set game with the bitmap?  It
should be just as fast to just use cmpxchg as it is to do the
test-and-set, and isn't it more likely that various CPU architectures
will have the cmpxchg than test-and-set-bit?

We might be able to radically simplify alloc_pidmap().  Would that
cause a huge problem on some non-Intel architectures, though?

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/