Grzegorz Milos
2009-Jun-09 16:16 UTC
[Xen-devel] blktap: Indirection in vm_area_struct->vm_private_data
Hi all, The recent patch in linux-2.6.18.hg (878: eba6fe6d8d53) changed the way that the foreign map is stored in vm_area_struct. Currently blktap (not 2) implementation is internally inconsistent, which triggers kernel bug when tap:aio disk is used (dump attached at the end of the email). The problem is that the above patch added an extra level of indirection to how the raw foreign map is stored. mm/memory.c and blktap2/ring.c expect the map to be accessible through vm_area_struct->vm_private_data->map, whereas blktap still assigns vm_area_struct->vm_private_data as if was pointing to the map directly. I''m attaching a patch that fixes one of these assignments, but there are two more (in blktap_vma_open & blktap_vma_close) which need to be fixed (I''m not hitting these in my testing setup). I''m not attempting to fix the two remaining assignments, because the foreign_map structure in tap_blkif_t can not be used there. You''ll know if its better to create foreign_map structure dynamically, every time the assignment is made, or statically, once for each affected vm_area_struct. Thanks Gregor Jun 8 17:59:30 knockout kernel: blktap: ring-ref 1536, event-channel 5, protocol 2 (x86_32-abi) Jun 8 17:59:33 knockout kernel: Unable to handle kernel NULL pointer dereference at 0000000000000008 RIP: Jun 8 17:59:33 knockout kernel: [<ffffffff8026c2b5>] get_user_pages+0x359/0x50b Jun 8 17:59:33 knockout kernel: PGD 1fcd0067 PUD 1fcd1067 PMD 0 Jun 8 17:59:33 knockout kernel: Oops: 0000 [1] SMP Jun 8 17:59:33 knockout kernel: CPU 1 Jun 8 17:59:33 knockout kernel: Modules linked in: ipv6 Jun 8 17:59:33 knockout kernel: Pid: 3528, comm: tapdisk Not tainted 2.6.18.8-xen #4 Jun 8 17:59:33 knockout kernel: RIP: e030:[<ffffffff8026c2b5>] [<ffffffff8026c2b5>] get_user_pages+0x359/0x50b Jun 8 17:59:33 knockout kernel: RSP: e02b:ffff8800202e7bd8 EFLAGS: 00010202 Jun 8 17:59:33 knockout kernel: RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000040a44fb Jun 8 17:59:33 knockout kernel: RDX: 0000000000000001 RSI: 00002b2b4cac4000 RDI: ffff88006f45c780 Jun 8 17:59:33 knockout kernel: RBP: ffff880031883870 R08: 0000000000000001 R09: 0000000000000000 Jun 8 17:59:33 knockout kernel: R10: 0000000000010a17 R11: 0000000000000001 R12: 0000000000000000 Jun 8 17:59:33 knockout kernel: R13: 00002b2b4cac4000 R14: 0000000000000000 R15: 0000000000000009 Jun 8 17:59:33 knockout kernel: FS: 00002b2b4d9d9af0(0000) GS:ffffffff805c9080(0000) knlGS:0000000000000000 Jun 8 17:59:33 knockout kernel: CS: e033 DS: 0000 ES: 0000 Jun 8 17:59:33 knockout kernel: Process tapdisk (pid: 3528, threadinfo ffff8800202e6000, task ffff88002506f820) Jun 8 17:59:33 knockout kernel: Stack: 0000000000000000 0000000000000002 0000000100000001 ffff88006f45c780 Jun 8 17:59:33 knockout kernel: ffff88002506f820 0000000000000001 ffff88006f66d400 0000000000000000 Jun 8 17:59:33 knockout kernel: 0000000000000200 0000000000000000 0000000000000009 ffffffff802a3812 Jun 8 17:59:33 knockout kernel: Call Trace: Jun 8 17:59:33 knockout kernel: [<ffffffff802a3812>] dio_get_page+0x8a/0x1a0 Jun 8 17:59:33 knockout kernel: [<ffffffff802a445c>] __blockdev_direct_IO+0x485/0xb49 Jun 8 17:59:33 knockout kernel: [<ffffffff802c9251>] ext3_direct_IO+0xe3/0x16b Jun 8 17:59:33 knockout kernel: [<ffffffff802c9f54>] ext3_get_block+0x0/0xe4 Jun 8 17:59:33 knockout kernel: [<ffffffff8025ebf1>] generic_file_direct_IO+0x9f/0xe1 Jun 8 17:59:33 knockout kernel: [<ffffffff8025f516>] __generic_file_aio_read+0xc8/0x1b1 Jun 8 17:59:33 knockout kernel: [<ffffffff8027ceae>] cache_alloc_refill+0x9d/0x564 Jun 8 17:59:33 knockout kernel: [<ffffffff8025f7a0>] generic_file_aio_read+0x34/0x39 Jun 8 17:59:33 knockout kernel: [<ffffffff8029d370>] aio_pread+0x34/0x97 Jun 8 17:59:33 knockout kernel: [<ffffffff8029d33c>] aio_pread+0x0/0x97 Jun 8 17:59:33 knockout kernel: [<ffffffff8029e872>] aio_run_iocb+0x108/0x1d1 Jun 8 17:59:33 knockout kernel: [<ffffffff8029f3d5>] io_submit_one+0x274/0x2f5 Jun 8 17:59:33 knockout kernel: [<ffffffff8029f4f7>] sys_io_submit+0xa1/0x10a Jun 8 17:59:33 knockout kernel: [<ffffffff8020a634>] system_call+0x68/0x6d Jun 8 17:59:33 knockout kernel: [<ffffffff8020a5cc>] system_call+0x0/0x6d Jun 8 17:59:33 knockout kernel: Jun 8 17:59:33 knockout kernel: Jun 8 17:59:33 knockout kernel: Code: 48 8b 14 d0 48 85 d2 74 59 48 83 7c 24 60 00 74 1f 48 8b 4c Jun 8 17:59:33 knockout kernel: RIP [<ffffffff8026c2b5>] get_user_pages+0x359/0x50b Jun 8 17:59:33 knockout kernel: RSP <ffff8800202e7bd8> Jun 8 17:59:33 knockout kernel: CR2: 0000000000000008 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Isaku Yamahata
2009-Jun-10 02:29 UTC
Re: [Xen-devel] blktap: Indirection in vm_area_struct->vm_private_data
On Tue, Jun 09, 2009 at 05:16:33PM +0100, Grzegorz Milos wrote:> Hi all, > > The recent patch in linux-2.6.18.hg (878: eba6fe6d8d53) changed the > way that the foreign map is stored in vm_area_struct. Currently blktap > (not 2) implementation is internally inconsistent, which triggers > kernel bug when tap:aio disk is used (dump attached at the end of the > email). > > The problem is that the above patch added an extra level of > indirection to how the raw foreign map is stored. mm/memory.c and > blktap2/ring.c expect the map to be accessible through > vm_area_struct->vm_private_data->map, whereas blktap still assigns > vm_area_struct->vm_private_data as if was pointing to the map > directly. I''m attaching a patch that fixes one of these assignments, > but there are two more (in blktap_vma_open & blktap_vma_close) which > need to be fixed (I''m not hitting these in my testing setup).It is for partial munmap(). blktap (blktap2) daemon doesn''t issue partial munmap(). Anyway blktap2 looks broken when partial munmap(). Also blktap2 drivers remembers vma in struct blktap_ring. It''s wrong because vma can be changed/removed without mm_struct->mmap_sem locked. Probably by using vma_operations::close callback very carefully, it might be possible to remember blktap_ring::vma. It would be error-prone. thanks,> I''m not > attempting to fix the two remaining assignments, because the > foreign_map structure in tap_blkif_t can not be used there. You''ll > know if its better to create foreign_map structure dynamically, every > time the assignment is made, or statically, once for each affected > vm_area_struct. > > Thanks > Gregor > > Jun 8 17:59:30 knockout kernel: blktap: ring-ref 1536, event-channel > 5, protocol 2 (x86_32-abi) > Jun 8 17:59:33 knockout kernel: Unable to handle kernel NULL pointer > dereference at 0000000000000008 RIP: > Jun 8 17:59:33 knockout kernel: [<ffffffff8026c2b5>] > get_user_pages+0x359/0x50b > Jun 8 17:59:33 knockout kernel: PGD 1fcd0067 PUD 1fcd1067 PMD 0 > Jun 8 17:59:33 knockout kernel: Oops: 0000 [1] SMP > Jun 8 17:59:33 knockout kernel: CPU 1 > Jun 8 17:59:33 knockout kernel: Modules linked in: ipv6 > Jun 8 17:59:33 knockout kernel: Pid: 3528, comm: tapdisk Not tainted > 2.6.18.8-xen #4 > Jun 8 17:59:33 knockout kernel: RIP: e030:[<ffffffff8026c2b5>] > [<ffffffff8026c2b5>] get_user_pages+0x359/0x50b > Jun 8 17:59:33 knockout kernel: RSP: e02b:ffff8800202e7bd8 EFLAGS: 00010202 > Jun 8 17:59:33 knockout kernel: RAX: 0000000000000000 RBX: > 0000000000000001 RCX: 00000000040a44fb > Jun 8 17:59:33 knockout kernel: RDX: 0000000000000001 RSI: > 00002b2b4cac4000 RDI: ffff88006f45c780 > Jun 8 17:59:33 knockout kernel: RBP: ffff880031883870 R08: > 0000000000000001 R09: 0000000000000000 > Jun 8 17:59:33 knockout kernel: R10: 0000000000010a17 R11: > 0000000000000001 R12: 0000000000000000 > Jun 8 17:59:33 knockout kernel: R13: 00002b2b4cac4000 R14: > 0000000000000000 R15: 0000000000000009 > Jun 8 17:59:33 knockout kernel: FS: 00002b2b4d9d9af0(0000) > GS:ffffffff805c9080(0000) knlGS:0000000000000000 > Jun 8 17:59:33 knockout kernel: CS: e033 DS: 0000 ES: 0000 > Jun 8 17:59:33 knockout kernel: Process tapdisk (pid: 3528, > threadinfo ffff8800202e6000, task ffff88002506f820) > Jun 8 17:59:33 knockout kernel: Stack: 0000000000000000 > 0000000000000002 0000000100000001 ffff88006f45c780 > Jun 8 17:59:33 knockout kernel: ffff88002506f820 0000000000000001 > ffff88006f66d400 0000000000000000 > Jun 8 17:59:33 knockout kernel: 0000000000000200 0000000000000000 > 0000000000000009 ffffffff802a3812 > Jun 8 17:59:33 knockout kernel: Call Trace: > Jun 8 17:59:33 knockout kernel: [<ffffffff802a3812>] dio_get_page+0x8a/0x1a0 > Jun 8 17:59:33 knockout kernel: [<ffffffff802a445c>] > __blockdev_direct_IO+0x485/0xb49 > Jun 8 17:59:33 knockout kernel: [<ffffffff802c9251>] ext3_direct_IO+0xe3/0x16b > Jun 8 17:59:33 knockout kernel: [<ffffffff802c9f54>] ext3_get_block+0x0/0xe4 > Jun 8 17:59:33 knockout kernel: [<ffffffff8025ebf1>] > generic_file_direct_IO+0x9f/0xe1 > Jun 8 17:59:33 knockout kernel: [<ffffffff8025f516>] > __generic_file_aio_read+0xc8/0x1b1 > Jun 8 17:59:33 knockout kernel: [<ffffffff8027ceae>] > cache_alloc_refill+0x9d/0x564 > Jun 8 17:59:33 knockout kernel: [<ffffffff8025f7a0>] > generic_file_aio_read+0x34/0x39 > Jun 8 17:59:33 knockout kernel: [<ffffffff8029d370>] aio_pread+0x34/0x97 > Jun 8 17:59:33 knockout kernel: [<ffffffff8029d33c>] aio_pread+0x0/0x97 > Jun 8 17:59:33 knockout kernel: [<ffffffff8029e872>] aio_run_iocb+0x108/0x1d1 > Jun 8 17:59:33 knockout kernel: [<ffffffff8029f3d5>] io_submit_one+0x274/0x2f5 > Jun 8 17:59:33 knockout kernel: [<ffffffff8029f4f7>] sys_io_submit+0xa1/0x10a > Jun 8 17:59:33 knockout kernel: [<ffffffff8020a634>] system_call+0x68/0x6d > Jun 8 17:59:33 knockout kernel: [<ffffffff8020a5cc>] system_call+0x0/0x6d > Jun 8 17:59:33 knockout kernel: > Jun 8 17:59:33 knockout kernel: > Jun 8 17:59:33 knockout kernel: Code: 48 8b 14 d0 48 85 d2 74 59 48 > 83 7c 24 60 00 74 1f 48 8b 4c > Jun 8 17:59:33 knockout kernel: RIP [<ffffffff8026c2b5>] > get_user_pages+0x359/0x50b > Jun 8 17:59:33 knockout kernel: RSP <ffff8800202e7bd8> > Jun 8 17:59:33 knockout kernel: CR2: 0000000000000008> > diff -r ca12928cdafe drivers/xen/blktap/blktap.c > --- a/drivers/xen/blktap/blktap.c Mon Jun 08 12:23:24 2009 +0100 > +++ b/drivers/xen/blktap/blktap.c Tue Jun 09 16:40:49 2009 +0100 > @@ -733,7 +733,7 @@ static int blktap_mmap(struct file *filp > goto fail; > } > > - vma->vm_private_data = info->foreign_map.map; > + vma->vm_private_data = &info->foreign_map; > vma->vm_flags |= VM_FOREIGN; > vma->vm_flags |= VM_DONTCOPY; >> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- yamahata _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel