Messages in this thread | | | Date | Thu, 17 Sep 2015 19:44:56 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH] kernel: fix data race in put_pid |
| |
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.
| |