On Mon, Mar 26, 2018 at 05:59:49PM -0400, Yang Shi wrote:
down_read before was a bug ;) And it was not discovered earlier simplySay we've two syscalls running prctl_set_mm_map in parallel, and imagineYes it sounds so. However, it was down_read before
one have @start_brk = 20 @brk = 10 and second caller has @start_brk = 30
and @brk = 20. Since now the call is guarded by _read_ the both calls
unlocked and due to OO engine it may happen then when both finish
we have @start_brk = 30 and @brk = 10. In turn "write" semaphore
has been take to have consistent data on exit, either you have [20;10]
or [30;20] assigned not something mixed.
That said I think using read-lock here would be a bug.
ddf1d398e517e660207e2c807f76a90df543a217 ("prctl: take mmap sem for writing
to protect against others"). And, that commit is for fixing the concurrent
writing to arg_* and env_*. I just checked that commit, but omitted the brk
part. The potential issue mentioned by you should exist before that commit,
but might be just not discovered or very rare to hit.
I will change it back to down_write.
because not that many users of this interface exist, namely only criu
as far as I know by now.