Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1625280yba; Fri, 17 May 2019 02:27:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqy9YpMLErhHhRS6X75GbkLXZBNaAfF6GnAsddaVahadtvjWz/PAkLS+KUIxgRMuU3S4ZtHi X-Received: by 2002:a63:ce54:: with SMTP id r20mr57159053pgi.37.1558085279263; Fri, 17 May 2019 02:27:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558085279; cv=none; d=google.com; s=arc-20160816; b=BSoDbL6vzbehHo5PqxTwwubqWTutobZG3BK7S4Y0MG9ngMFQ1OgzFVpMacrSJEC6Cm pCkrSDfrF5odspDOCKsXG32XfKZ4A/K6d0fQGfBOJEwUH6VdUNraNeTNW9/HB82UuDwO xPWa8GpvbOD07RdVTi/4WiUNsULQSZ2nS8nUrt0yOkLpUGh/WV6FPEnudDIiYIFGq8K5 UyziBxYQ1VtUUCovmV0XEPZk154EHTs2TY4pULfI0i1/9b6bysA3FiVqEMR1lDPzvbGK fOrXD7UQ+tLnC2X9oLd3M4bVXXAs9fyqSI+v/dfhncHYmYUpxF51gIEbd6r7AUE2Sg6F JJkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=cULMJDOvF9eVDSo9dp6+c4o/bcGy8xGnvE5CwRJMTP8=; b=UIEQi7tl2GrYny8y/BJGNGl7Zb/Yyx8zJN8AUHYLR88nOP6OpeX3d7Veex3HYtTkCx sWzFc5Ek1pfU8x2ZKkbY3da0+SARvJLWCJyQkY/qZVqTdbomIesvIfrbFQkD3pw+ML55 TgyQY2pRv1T4rRKZg/ZUCRxj5ON+vFtM9mH9pBDIW/6j7CeOHOFkvaC+cotViOWK+hQo 3cvoc1M6P/G/UKEY0NymMbmJ9KU+v/CPkNeLNZzV+PG0RynHLc7xe3yKX394ebyostN5 N5Yjm1lATgZKdVsTKrMuEGxVeURbYS8VsDoSe6g0ho6u/P6UbEWMP1f4uYptJPK4cGa3 k1lQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d5si3293006pfc.131.2019.05.17.02.27.44; Fri, 17 May 2019 02:27:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728830AbfEQIZL (ORCPT + 99 others); Fri, 17 May 2019 04:25:11 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:41809 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727726AbfEQIZK (ORCPT ); Fri, 17 May 2019 04:25:10 -0400 Received: by mail-wr1-f68.google.com with SMTP id g12so5844285wro.8 for ; Fri, 17 May 2019 01:25:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=cULMJDOvF9eVDSo9dp6+c4o/bcGy8xGnvE5CwRJMTP8=; b=jqbzEolKxCRnefy5nr++Wh8X8VBaJ7EKJmGJcfX3vwGSSjYToyaPCVBH+u/eZCr1ff 2eWYXc5kYpqghU2+gp4IyPeVJ7tILMqZ1BdfTGUfDAeNtd9Z707YI8zCeOA88SE0mvoI IAgMEEvnJe6b5TIwBot4gqQoOTQyeFYA25s2IAum1CdrOQmBjB8GK9CtNfzDzV+FkXzc DmlvO5yRJTWLP2ys4vGK0PXMXjrOVvSxulubBm95UTi1E36dFG7NzugO+JUMVb6w6EVk BazkG7BoNyjndneIC3VyE2BZJlw7o/kFCLk8lJfuXYm0wjS8gBz0mKmZ3DKqpewKcFK3 t4xw== X-Gm-Message-State: APjAAAVI5N73CwjDzDU6WNhpo/8RB0nEHoLCpROVxqS4qNZQbJwHFEaP n79qG+5TRUhW5wrpfSYDpT04Dg== X-Received: by 2002:a5d:4f0e:: with SMTP id c14mr17663814wru.91.1558081508824; Fri, 17 May 2019 01:25:08 -0700 (PDT) Received: from steredhat (host151-251-static.12-87-b.business.telecomitalia.it. [87.12.251.151]) by smtp.gmail.com with ESMTPSA id l18sm7415127wrv.38.2019.05.17.01.25.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 May 2019 01:25:08 -0700 (PDT) Date: Fri, 17 May 2019 10:25:05 +0200 From: Stefano Garzarella To: Stefan Hajnoczi Cc: netdev@vger.kernel.org, "David S. Miller" , "Michael S. Tsirkin" , virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Jason Wang Subject: Re: [PATCH v2 1/8] vsock/virtio: limit the memory used per-socket Message-ID: <20190517082505.ibjkuh7zibumen77@steredhat> References: <20190510125843.95587-1-sgarzare@redhat.com> <20190510125843.95587-2-sgarzare@redhat.com> <20190516152533.GB29808@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190516152533.GB29808@stefanha-x1.localdomain> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 16, 2019 at 04:25:33PM +0100, Stefan Hajnoczi wrote: > On Fri, May 10, 2019 at 02:58:36PM +0200, Stefano Garzarella wrote: > > +struct virtio_vsock_buf { > > Please add a comment describing the purpose of this struct and to > differentiate its use from struct virtio_vsock_pkt. > Sure, I'll fix it. > > +static struct virtio_vsock_buf * > > +virtio_transport_alloc_buf(struct virtio_vsock_pkt *pkt, bool zero_copy) > > +{ > > + struct virtio_vsock_buf *buf; > > + > > + if (pkt->len == 0) > > + return NULL; > > + > > + buf = kzalloc(sizeof(*buf), GFP_KERNEL); > > + if (!buf) > > + return NULL; > > + > > + /* If the buffer in the virtio_vsock_pkt is full, we can move it to > > + * the new virtio_vsock_buf avoiding the copy, because we are sure that > > + * we are not use more memory than that counted by the credit mechanism. > > + */ > > + if (zero_copy && pkt->len == pkt->buf_len) { > > + buf->addr = pkt->buf; > > + pkt->buf = NULL; > > + } else { > > + buf->addr = kmalloc(pkt->len, GFP_KERNEL); > > buf and buf->addr could be allocated in a single call, though I'm not > sure how big an optimization this is. > IIUC, in the case of zero-copy I should allocate only the buf, otherwise I should allocate both buf and buf->addr in a single call when I'm doing a full-copy. Is it correct? > > @@ -841,20 +882,24 @@ virtio_transport_recv_connected(struct sock *sk, > > { > > struct vsock_sock *vsk = vsock_sk(sk); > > struct virtio_vsock_sock *vvs = vsk->trans; > > + struct virtio_vsock_buf *buf; > > int err = 0; > > > > switch (le16_to_cpu(pkt->hdr.op)) { > > case VIRTIO_VSOCK_OP_RW: > > pkt->len = le32_to_cpu(pkt->hdr.len); > > - pkt->off = 0; > > + buf = virtio_transport_alloc_buf(pkt, true); > > > > - spin_lock_bh(&vvs->rx_lock); > > - virtio_transport_inc_rx_pkt(vvs, pkt); > > - list_add_tail(&pkt->list, &vvs->rx_queue); > > - spin_unlock_bh(&vvs->rx_lock); > > + if (buf) { > > + spin_lock_bh(&vvs->rx_lock); > > + virtio_transport_inc_rx_pkt(vvs, pkt->len); > > + list_add_tail(&buf->list, &vvs->rx_queue); > > + spin_unlock_bh(&vvs->rx_lock); > > > > - sk->sk_data_ready(sk); > > - return err; > > + sk->sk_data_ready(sk); > > + } > > The return value of this function isn't used but the code still makes an > effort to return errors. Please return -ENOMEM when buf == NULL. > > If you'd like to remove the return value that's fine too, but please do > it for the whole function to be consistent. I'll return -ENOMEM when the allocation fails. Thanks, Stefano