aboutsummaryrefslogtreecommitdiff
path: root/drivers/soc
diff options
context:
space:
mode:
authorIlya Dryomov2015-09-02 11:37:09 +0300
committerIlya Dryomov2015-09-09 09:52:17 +0300
commitd15f9d694b77fe5e4ea12b3031ecaa13b5aa2b10 (patch)
treec5341ec8d2b91adaa17d4ef3177a0b04ef9581a7 /drivers/soc
parent8b9558aab853e98ba6e3fee0dd8545544966958c (diff)
libceph: check data_len in ->alloc_msg()
Only ->alloc_msg() should check data_len of the incoming message against the preallocated ceph_msg, doing it in the messenger is not right. The contract is that either ->alloc_msg() returns a ceph_msg which will fit all of the portions of the incoming message, or it returns NULL and possibly sets skip, signaling whether NULL is due to an -ENOMEM. ->alloc_msg() should be the only place where we make the skip/no-skip decision. I stumbled upon this while looking at con/osd ref counting. Right now, if we get a non-extent message with a larger data portion than we are prepared for, ->alloc_msg() returns a ceph_msg, and then, when we skip it in the messenger, we don't put the con/osd ref acquired in ceph_con_in_msg_alloc() (which is normally put in process_message()), so this also fixes a memory leak. An existing BUG_ON in ceph_msg_data_cursor_init() ensures we don't corrupt random memory should a buggy ->alloc_msg() return an unfit ceph_msg. While at it, I changed the "unknown tid" dout() to a pr_warn() to make sure all skips are seen and unified format strings. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org>
Diffstat (limited to 'drivers/soc')
0 files changed, 0 insertions, 0 deletions