Received: by 10.192.165.148 with SMTP id m20csp5002551imm; Tue, 24 Apr 2018 11:59:04 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/8E1uV0Dr+q7YKvLE9Y0C5Dh4ZEimLAkPZc2T52bNDczXdE7Pj7sspkWvDfxHr4hARYeJy X-Received: by 10.99.147.20 with SMTP id b20mr21237044pge.309.1524596344846; Tue, 24 Apr 2018 11:59:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524596344; cv=none; d=google.com; s=arc-20160816; b=A+7T/5QcbP9ndv58xCXxX+k3qPJLZ1bq4a1n7xZdz+NI5uAW23TsrDUdXrWYChLiXy I/ztwmaquEvmwomzLOlTcSc3hr0IE5JRiM9UB1DYmrKrLB/B5thUJx+gBm7P4XxPb3Vi hOEDLCDRuoqzSiZruSnxriSjQ/MFka4ihN52igLjrvCbuC31RDjIZjBzTN6BIIX+acA+ FrOMtyuKgJcGS0QZAaJzcxv4pzuLg73AG8Seb+R+QFD5DuseJaLPqfn7+Dc2qBspmVOJ B9niXNEqD84cOKAQQ+Q9ZG/jhn2I2TzIdt7Uuu1UMikNlYAL/mgx2+xtpMhB7AXPT2mO M21Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=ay7xTKjgljNZbLfINukKzzOfOoCux4rt9O7HcIgdovo=; b=OKgmd4TTB/udoqZdR5OlRKdxF7mV2mrquUU6TkFXfPoCy4J8wi5SApPw8CJiaC9wn3 64iuRQ6vxQ6cqYYd7tQaoS+1ME+lAU6tdP6HjK7SKhByRrLhcwjw1OVnMrecF5XjNXNI feqFUu/BIb58Bl7Va29oGk4nBDMeb2b2CEShg8hHbathgzdzWYEGMcqiTv8RePNa0Ahy mdrJdXkxL/oeIufu1Z/nkJeEgMg33sqz7lktMCkmvb6PE3arF7u+CzIsxLGoxyjArHU8 XDkAX7hpZCU3xQcmrwRY6sP7Un8vvL6SKHPivDKgIcrjKmm5hryI8Xodw7EMN/qcrcyQ ApFg== 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 x124si12298704pgb.651.2018.04.24.11.58.49; Tue, 24 Apr 2018 11:59:04 -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 S1752276AbeDXS4i (ORCPT + 99 others); Tue, 24 Apr 2018 14:56:38 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:32860 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752049AbeDXS4f (ORCPT ); Tue, 24 Apr 2018 14:56:35 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 993AB40201A2; Tue, 24 Apr 2018 18:56:34 +0000 (UTC) Received: from redhat.com (ovpn-123-127.rdu2.redhat.com [10.10.123.127]) by smtp.corp.redhat.com (Postfix) with SMTP id 26D1B2022EE6; Tue, 24 Apr 2018 18:56:34 +0000 (UTC) Date: Tue, 24 Apr 2018 21:56:33 +0300 From: "Michael S. Tsirkin" To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, Amit Shah , Arnd Bergmann , virtualization@lists.linux-foundation.org, stable@vger.kernel.org, Tiwei Bie , Jason Wang Subject: Re: [PATCH 1/6] virtio_console: don't tie bufs to a vq Message-ID: <20180424215318-mutt-send-email-mst@kernel.org> References: <1524248223-393618-1-git-send-email-mst@redhat.com> <1524248223-393618-2-git-send-email-mst@redhat.com> <20180421073005.GA3744@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180421073005.GA3744@kroah.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 24 Apr 2018 18:56:34 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 24 Apr 2018 18:56:34 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mst@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 21, 2018 at 09:30:05AM +0200, Greg Kroah-Hartman wrote: > On Fri, Apr 20, 2018 at 09:18:01PM +0300, Michael S. Tsirkin wrote: > > an allocated buffer doesn't need to be tied to a vq - > > only vq->vdev is ever used. Pass the function the > > just what it needs - the vdev. > > > > Signed-off-by: Michael S. Tsirkin > > --- > > drivers/char/virtio_console.c | 14 +++++++------- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > > index 468f061..3e56f32 100644 > > --- a/drivers/char/virtio_console.c > > +++ b/drivers/char/virtio_console.c > > @@ -422,7 +422,7 @@ static void reclaim_dma_bufs(void) > > } > > } > > > > -static struct port_buffer *alloc_buf(struct virtqueue *vq, size_t buf_size, > > +static struct port_buffer *alloc_buf(struct virtio_device *vdev, size_t buf_size, > > int pages) > > { > > struct port_buffer *buf; > > @@ -445,16 +445,16 @@ static struct port_buffer *alloc_buf(struct virtqueue *vq, size_t buf_size, > > return buf; > > } > > > > - if (is_rproc_serial(vq->vdev)) { > > + if (is_rproc_serial(vdev)) { > > /* > > * Allocate DMA memory from ancestor. When a virtio > > * device is created by remoteproc, the DMA memory is > > * associated with the grandparent device: > > * vdev => rproc => platform-dev. > > */ > > - if (!vq->vdev->dev.parent || !vq->vdev->dev.parent->parent) > > + if (!vdev->dev.parent || !vdev->dev.parent->parent) > > goto free_buf; > > - buf->dev = vq->vdev->dev.parent->parent; > > + buf->dev = vdev->dev.parent->parent; > > > > /* Increase device refcnt to avoid freeing it */ > > get_device(buf->dev); > > @@ -838,7 +838,7 @@ static ssize_t port_fops_write(struct file *filp, const char __user *ubuf, > > > > count = min((size_t)(32 * 1024), count); > > > > - buf = alloc_buf(port->out_vq, count, 0); > > + buf = alloc_buf(port->portdev->vdev, count, 0); > > if (!buf) > > return -ENOMEM; > > > > @@ -957,7 +957,7 @@ static ssize_t port_fops_splice_write(struct pipe_inode_info *pipe, > > if (ret < 0) > > goto error_out; > > > > - buf = alloc_buf(port->out_vq, 0, pipe->nrbufs); > > + buf = alloc_buf(port->portdev->vdev, 0, pipe->nrbufs); > > if (!buf) { > > ret = -ENOMEM; > > goto error_out; > > @@ -1374,7 +1374,7 @@ static unsigned int fill_queue(struct virtqueue *vq, spinlock_t *lock) > > > > nr_added_bufs = 0; > > do { > > - buf = alloc_buf(vq, PAGE_SIZE, 0); > > + buf = alloc_buf(vq->vdev, PAGE_SIZE, 0); > > if (!buf) > > break; > > > > -- > > MST > > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly. > > Thanks! I have some questions about this one: Cc: # 3.3.x: a1f84a3: sched: Check for idle Cc: # 3.3.x: 1b9508f: sched: Rate-limit newidle Cc: # 3.3.x: fd21073: sched: Fix affinity logic Cc: # 3.3.x Signed-off-by: Ingo Molnar 1. what does the kernel version mean? can I omit it? 2. so when I rebase to add the tag, this changes commit IDs for following tags in the same tree, breaking their tags in the process. Pretty annoying. Any idea how to do it better? Thanks! -- MST