Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755785Ab2HIJZO (ORCPT ); Thu, 9 Aug 2012 05:25:14 -0400 Received: from mail4.hitachi.co.jp ([133.145.228.5]:35331 "EHLO mail4.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752873Ab2HIJZM (ORCPT ); Thu, 9 Aug 2012 05:25:12 -0400 X-AuditID: b753bd60-8fbf2ba000006b7e-e1-502381f507f7 X-AuditID: b753bd60-8fbf2ba000006b7e-e1-502381f507f7 Message-ID: <502381EA.80805@hitachi.com> Date: Thu, 09 Aug 2012 18:24:58 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Amit Shah Cc: Yoshihiro YUNOMAE , linux-kernel@vger.kernel.org, Anthony Liguori , Arnd Bergmann , Borislav Petkov , "Franch Ch. Eigler" , Frederic Weisbecker , Greg Kroah-Hartman , Herbert Xu , Ingo Molnar , Mathieu Desnoyers , Steven Rostedt , virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org, yrl.pp-manager.tt@hitachi.com Subject: Re: [RFC PATCH 2/6] virtio/console: Add a failback for unstealable pipe buffer References: <20120724023657.6600.52706.stgit@ltc189.sdl.hitachi.co.jp> <20120724023718.6600.68836.stgit@ltc189.sdl.hitachi.co.jp> <20120809090312.GH3280@amit.redhat.com> In-Reply-To: <20120809090312.GH3280@amit.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2331 Lines: 64 (2012/08/09 18:03), Amit Shah wrote: > On (Tue) 24 Jul 2012 [11:37:18], Yoshihiro YUNOMAE wrote: >> From: Masami Hiramatsu >> >> Add a failback memcpy path for unstealable pipe buffer. >> If buf->ops->steal() fails, virtio-serial tries to >> copy the page contents to an allocated page, instead >> of just failing splice(). >> >> Signed-off-by: Masami Hiramatsu >> Cc: Amit Shah >> Cc: Arnd Bergmann >> Cc: Greg Kroah-Hartman >> --- >> >> drivers/char/virtio_console.c | 28 +++++++++++++++++++++++++--- >> 1 files changed, 25 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c >> index fe31b2f..911cb3e 100644 >> --- a/drivers/char/virtio_console.c >> +++ b/drivers/char/virtio_console.c >> @@ -794,7 +794,7 @@ static int pipe_to_sg(struct pipe_inode_info *pipe, struct pipe_buffer *buf, >> struct splice_desc *sd) >> { >> struct sg_list *sgl = sd->u.data; >> - unsigned int len = 0; >> + unsigned int offset, len; >> >> if (sgl->n == MAX_SPLICE_PAGES) >> return 0; >> @@ -807,9 +807,31 @@ static int pipe_to_sg(struct pipe_inode_info *pipe, struct pipe_buffer *buf, >> >> len = min(buf->len, sd->len); >> sg_set_page(&(sgl->sg[sgl->n]), buf->page, len, buf->offset); >> - sgl->n++; >> - sgl->len += len; >> + } else { >> + /* Failback to copying a page */ >> + struct page *page = alloc_page(GFP_KERNEL); > > I prefer zeroing out the page. If there's not enough data to be > filled in the page, the remaining data can be leaked to the host. Yeah, it is really easy to fix that. But out of curiosity, would that be really a problem? I guess that host can access any guest page if need. If that is right, is that really insecure to leak randomly allocated unused page to the host? Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/