Re: [PATCH] kernel: fix data race in put_pid

[Oleg Nesterov <oleg@redhat.com>]

On 09/17, Dmitry Vyukov wrote:
>
> What happens here exactly matches what is described in CONTROL
> DEPENDENCIES section of Documentation/memory-barriers.txt. So all the
> bad things described there are possible here.

And I still can't understand how these bad things connect to put_pid().
Probably I should re-read memory-barriers.txt, it changes quite often.

> I don't
> know what to add to that.

OK, let me quote the parts of your changelog,

	For example, if store to the first word of the object to build a freelist
	in kmem_cache_free() hoists above the check, stores to the first word
	in other threads can corrupt the memory allocator freelist.

I simply can't parse this. Yes, this is probably because of my bad
English, but I'll appreciate it if you can explain at least, say,
"stores to the first word in other threads".

Did you mean that a freed pid can be reallocated by another thread,
then overwritten, and this all can happen before atomic_read(count)?


Hmm. or perhaps you meant that the "last" put_pid() which observes
atomic_read() == 1 can race with another thread which writes to this
pid and does put_pid()? This is another story, and if you meant this
the changelog could clearly explain your concerns.

Or what?


So let me repeat. Since I can't understand you, I leave this to other
reviewers. But imho the changelog should be updated in any case.

Oleg.