From: "Michael S. Tsirkin" <mst@redhat.com>
To: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Eric Van Hensbergen <ericvh@gmail.com>,
Ron Minnich <rminnich@sandia.gov>,
Latchesar Ionkov <lucho@ionkov.net>,
Al Viro <viro@zeniv.linux.org.uk>,
v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, netdev <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Jason Wang <jasowang@redhat.com>,
dgibson@redhat.com
Subject: Re: [PATCH] 9p/trans_virtio: use kvfree() for iov_iter_get_pages_alloc()
Date: Wed, 3 Aug 2016 15:48:57 +0300 [thread overview]
Message-ID: <20160803151757-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <57A1BA31.8030502@oracle.com>
On Wed, Aug 03, 2016 at 11:32:33AM +0200, Vegard Nossum wrote:
> On 07/22/2016 01:12 PM, Vegard Nossum wrote:
> > The memory allocated by iov_iter_get_pages_alloc() can be allocated with
> > vmalloc() if kmalloc() failed -- see get_pages_array().
> >
> > In that case we need to free it with vfree(), so let's use kvfree().
> >
> > The bug manifests like this:
> >
> > BUG: unable to handle kernel paging request at ffffeb0400072da0
> > IP: [<ffffffff8139c67b>] kfree+0x4b/0x140
> > PGD 0
> > Oops: 0000 [#1] PREEMPT SMP KASAN
> > CPU: 2 PID: 675 Comm: trinity-c2 Not tainted 4.7.0-rc7+ #14
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> > task: ffff8800badef2c0 ti: ffff880069208000 task.ti: ffff880069208000
> > RIP: 0010:[<ffffffff8139c67b>] [<ffffffff8139c67b>] kfree+0x4b/0x140
> > RSP: 0000:ffff88006920f3f0 EFLAGS: 00010282
> > RAX: ffffea0000000000 RBX: ffffc90001cb6000 RCX: 0000000000000000
> > RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffffc90001cb6000
> > RBP: ffff88006920f410 R08: 0000000000000000 R09: dffffc0000000000
> > R10: ffff8800badefa30 R11: 0000056a3d3b0d9f R12: ffff88006920f620
> > R13: ffffeb0400072d80 R14: ffff8800baa94078 R15: 0000000000000000
> > FS: 00007fbd2b437700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: ffffeb0400072da0 CR3: 000000006926d000 CR4: 00000000000006e0
> > Stack:
> > 0000000000000001 ffff88006920f620 ffffed001755280f ffff8800baa94078
> > ffff88006920f6a8 ffffffff8310442b dffffc0000000000 ffff8800badefa30
> > ffff8800badefa28 ffff88011af1fba0 1ffff1000d241e98 ffff8800ba892150
> > Call Trace:
> > [<ffffffff8310442b>] p9_virtio_zc_request+0x72b/0xdb0
> > [<ffffffff830f2116>] p9_client_zc_rpc.constprop.8+0x246/0xb10
> > [<ffffffff830f5d79>] p9_client_read+0x4c9/0x750
> > [<ffffffff8175ceac>] v9fs_fid_readpage+0x14c/0x320
> > [<ffffffff8175d0b6>] v9fs_vfs_readpage+0x36/0x50
> > [<ffffffff812c6f13>] filemap_fault+0x9a3/0xe60
> > [<ffffffff81331878>] __do_fault+0x158/0x300
> > [<ffffffff81339e01>] handle_mm_fault+0x1cf1/0x3c80
> > [<ffffffff810c0aaa>] __do_page_fault+0x30a/0x8e0
> > [<ffffffff810c10df>] do_page_fault+0x2f/0x80
> > [<ffffffff810b5b07>] do_async_page_fault+0x27/0xa0
> > [<ffffffff83296c48>] async_page_fault+0x28/0x30
> > Code: 00 80 41 54 53 49 01 fd 48 0f 42 05 b0 39 67 02 48 89 fb 49 01 c5 48 b8 00 00 00 00 00 ea ff ff 49 c1 ed 0c 49 c1 e5 06 49 01 c5 <49> 8b 45 20 48 8d 50 ff a8 01 4c 0f 45 ea 49 8b 55 20 48 8d 42
> > RIP [<ffffffff8139c67b>] kfree+0x4b/0x140
> > RSP <ffff88006920f3f0>
> > CR2: ffffeb0400072da0
> > ---[ end trace f3d59a04bafec038 ]---
> >
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> > ---
> > net/9p/trans_virtio.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> > index 4acb1d5..f24b25c 100644
> > --- a/net/9p/trans_virtio.c
> > +++ b/net/9p/trans_virtio.c
> > @@ -507,8 +507,8 @@ err_out:
> > /* wakeup anybody waiting for slots to pin pages */
> > wake_up(&vp_wq);
> > }
> > - kfree(in_pages);
> > - kfree(out_pages);
> > + kvfree(in_pages);
> > + kvfree(out_pages);
> > return err;
> > }
> >
> >
>
> Ping? Should this go to somebody else? Added a couple of Ccs.
>
>
> Vegard
I'll pick it up, thanks. Is virtio 9p in odd fixes mode?
Anyone interested in maintaining it?
I think it's actually kind of broken in virtio 1 mode,
and probably in IOMMU_PLATFORM mode as well.
The endian-ness also looks questionable - does it actually
pass native endian structures guets to host?
--
MST
prev parent reply other threads:[~2016-08-03 12:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1469185929-476-1-git-send-email-vegard.nossum@oracle.com>
2016-08-03 9:32 ` [PATCH] 9p/trans_virtio: use kvfree() for iov_iter_get_pages_alloc() Vegard Nossum
2016-08-03 12:48 ` Michael S. Tsirkin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160803151757-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=davem@davemloft.net \
--cc=dgibson@redhat.com \
--cc=ericvh@gmail.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=netdev@vger.kernel.org \
--cc=rminnich@sandia.gov \
--cc=v9fs-developer@lists.sourceforge.net \
--cc=vegard.nossum@oracle.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).