[CRIU] [PATCH] sk-queue: Use int values in getsockopt
Stanislav Kinsbursky
skinsbursky at parallels.com
Fri Jul 13 10:11:43 EDT 2012
13.07.2012 17:57, Cyrill Gorcunov пишет:
> The kernel threats them as interger values so
> we should declare them this way. Moreover, explicitly
> clean them up to eliminate side effects.
>
> Initially I hit a problem where high bits of long "size"
> variable was containing some crap from stack and in result
> I've got errors like
>
> | Error (sk-queue.c:102): dump_sk_queue: Can't allocate 171798904800 bytes
> | Error (cr-dump.c:1289): Dump files (pid: 2505) failed with -1
>
That's strange...
It looks like kernel bug...
BTW, here is a part of sock_getsockopt():
int sock_getsockopt(struct socket *sock, int level, int optname,
char __user *optval, int __user *optlen)
{
struct sock *sk = sock->sk;
union {
int val;
struct linger ling;
struct timeval tm;
} v;
<--- SNIP --->
memset(&v, 0, sizeof(v)); <=== Doesnt' we zeroing 8 bytes here?
<--- SNIP --->
case SO_PEEK_OFF:
if (!sock->ops->set_peek_off)
return -EOPNOTSUPP;
v.val = sk->sk_peek_off;
break;
> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> ---
> sk-queue.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/sk-queue.c b/sk-queue.c
> index 7c29037..c849951 100644
> --- a/sk-queue.c
> +++ b/sk-queue.c
> @@ -59,14 +59,14 @@ int read_sk_queues(void)
> int dump_sk_queue(int sock_fd, int sock_id)
> {
> struct sk_packet_entry *pe;
> - unsigned long size;
> + int ret, size, orig_peek_off;
> socklen_t tmp;
> - int ret, orig_peek_off;
>
> /*
> * Save original peek offset.
> */
> tmp = sizeof(orig_peek_off);
> + orig_peek_off = 0;
> ret = getsockopt(sock_fd, SOL_SOCKET, SO_PEEK_OFF, &orig_peek_off, &tmp);
> if (ret < 0) {
> pr_perror("getsockopt failed\n");
> @@ -76,6 +76,7 @@ int dump_sk_queue(int sock_fd, int sock_id)
> * Discover max DGRAM size
> */
> tmp = sizeof(size);
> + size = 0;
> ret = getsockopt(sock_fd, SOL_SOCKET, SO_SNDBUF, &size, &tmp);
> if (ret < 0) {
> pr_perror("getsockopt failed\n");
>
--
Best regards,
Stanislav Kinsbursky
More information about the CRIU
mailing list