| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
--
yamahata
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home