KASAN/pcpu_alloc related panics on v6.0

KASAN/pcpu_alloc related panics on v6.0

[Atish Patra]

Hi All,
Palmer reported some KASAN/pcpu_alloc related panics on v6.0. Here is
one of them

[   39.350391] Unable to handle kernel paging request at virtual
address ffebfffeffff3000
[   39.354419] Oops [#1]
[   39.355081] Modules linked in:
[   39.356203] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0 #36
[   39.357621] Hardware name: riscv-virtio,qemu (DT)
[   39.358773] epc : kasan_check_range+0x9e/0x14e
[   39.361299]  ra : memset+0x1e/0x4c
[   39.362118] epc : ffffffff8030c1f8 ra : ffffffff8030c936 sp :
ff60000003367a80
[   39.363114]  gp : ffffffff82388b40 tp : ff60000003358000 t0 :
ffebffff009d977c
[   39.364264]  t1 : ffebfffeffff301f t2 : ffffffff80783bf6 s0 :
ff60000003367ab0
[   39.365584]  s1 : 0000000000000100 a0 : ffebfffeffff3020 a1 :
0000000000000100
[   39.366538]  a2 : 0000000000000001 a3 : ffffffff802954bc a4 :
ff5ffffffff98000
[   39.367493]  a5 : ffebfffeffff3000 a6 : 0000000400000000 a7 :
ff5ffffffff980ff
[   39.368864]  s2 : ff5ffffffff98000 s3 : 0000000000000000 s4 :
ff6000003fdf1b00
[   39.370208]  s5 : ff600000041b9b38 s6 : ffffffff8238b600 s7 :
0000000000000008
[   39.371168]  s8 : ffffffff823a4060 s9 : 0000000000000000 s10:
ff5ffffffff98000
[   39.372330]  s11: 0000000000000100 t3 : 0000000000000000 t4 :
0000000000000004
[   39.373444]  t5 : ffebfffeffff3020 t6 : 0000000000000003
[   39.374205] status: 0000000200000120 badaddr: ffebfffeffff3000
cause: 000000000000000d
[   39.375783] [<ffffffff802954bc>] pcpu_alloc+0x4c8/0xac4
[   39.377520] [<ffffffff80295ae4>] __alloc_percpu+0x14/0x1c
[   39.378336] [<ffffffff806b30f8>] blk_mq_init_allocated_queue+0xfc/0x87c
[   39.379294] [<ffffffff806b4b00>] __blk_mq_alloc_disk+0x62/0xbc
[   39.380397] [<ffffffff808e03ec>] loop_add+0x24a/0x4fa
[   39.381472] [<ffffffff81033e26>] loop_init+0xfe/0x122
[   39.382394] [<ffffffff80002e2a>] do_one_initcall+0xda/0x460
[   39.383369] [<ffffffff8100166c>] kernel_init_freeable+0x39c/0x404
[   39.384722] [<ffffffff80e7b890>] kernel_init+0x20/0x122
[   39.385605] [<ffffffff8000492e>] ret_from_exception+0x0/0x10
[   39.389031] ---[ end trace 0000000000000000 ]---


This one is easily reproducible with the following additional config enabled.

$ cat configs/linux/kasan_provelock
CONFIG_PROVE_LOCKING=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_KASAN=y
# CONFIG_KASAN_VMALLOC is not set
CONFIG_STRICT_KERNEL_RWX=y

This issue has been there since v5.18. v5.17 works fine though.
Git bisection pointed to a wrong powerpc commit probably because of
the following reason.

RISC-V v5.18 merge window PR was based on v5.17-rc1 which had other
similar kasan issues w.r.to sv48
which confused the bisect. But v5.17 works fine because the issues
were fixed as a part of late PR on top of v5.17-rc7
(https://lore.kernel.org/lkml/164642532157.24805.457490534031372221.pr-tracker-bot@kernel.org/T/)

Inspecting the RISC-V commits manually on 5.18-rc1(also fails) seems
to indicate that there is probably a cause.

Enabling sv57 with kasan triggers this panic. I verified that in two ways.

1. Reverted the below sv57 patches from 5.18-rc1 and it boots fine.

8fbdccd2b173 riscv: mm: Support kasan for sv57
011f09d12052 riscv: mm: Set sv57 on defaultly
677b9eb8810e riscv: mm: Prepare pt_ops helper functions for sv57
d10efa21a937 riscv: mm: Control p4d's folding by pgtable_l5_enabled

2. Disabled sv57 in Qemu on v6.0 and it boots fine.

I am yet to find out the exact fix that would solve the panic pointed
out by Kasan on sv57 though.
@Alexandre Ghiti Is it possible for you to take a look ?

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v1 1/1] riscv: mm: add missing memcpy in kasan_init

[panqinglin2020]

From: Qinglin Pan <panqinglin2020@iscas.ac.cn>

Hi Atish,

It seems that the panic is due to the missing memcpy during kasan_init.
Could you please check whether this patch is helpful?

When doing kasan_populate, the new allocated base_pud/base_p4d should
contain kasan_early_shadow_{pud, p4d}'s content. Add the missing memcpy
to avoid page fault when read/write kasan shadow region.

Tested on:
 - qemu with sv57 and CONFIG_KASAN on.
 - qemu with sv48 and CONFIG_KASAN on.

Signed-off-by: Qinglin Pan <panqinglin2020@iscas.ac.cn>
---
 arch/riscv/mm/kasan_init.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index a22e418dbd82..e1226709490f 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -113,6 +113,8 @@ static void __init kasan_populate_pud(pgd_t *pgd,
 		base_pud = pt_ops.get_pud_virt(pfn_to_phys(_pgd_pfn(*pgd)));
 	} else if (pgd_none(*pgd)) {
 		base_pud = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
+		memcpy(base_pud, (void *)kasan_early_shadow_pud,
+			sizeof(pud_t) * PTRS_PER_PUD);
 	} else {
 		base_pud = (pud_t *)pgd_page_vaddr(*pgd);
 		if (base_pud == lm_alias(kasan_early_shadow_pud)) {
@@ -173,8 +175,11 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
 		base_p4d = pt_ops.get_p4d_virt(pfn_to_phys(_pgd_pfn(*pgd)));
 	} else {
 		base_p4d = (p4d_t *)pgd_page_vaddr(*pgd);
-		if (base_p4d == lm_alias(kasan_early_shadow_p4d))
+		if (base_p4d == lm_alias(kasan_early_shadow_p4d)) {
 			base_p4d = memblock_alloc(PTRS_PER_PUD * sizeof(p4d_t), PAGE_SIZE);
+			memcpy(base_p4d, (void *)kasan_early_shadow_p4d,
+				sizeof(p4d_t) * PTRS_PER_P4D);
+		}
 	}
 
 	p4dp = base_p4d + p4d_index(vaddr);
-- 
2.35.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v1 1/1] riscv: mm: add missing memcpy in kasan_init

[Conor Dooley]

On Sun, Oct 09, 2022 at 04:30:50PM +0800, panqinglin2020@iscas.ac.cn wrote:
> From: Qinglin Pan <panqinglin2020@iscas.ac.cn>
> 
> Hi Atish,
> 
> It seems that the panic is due to the missing memcpy during kasan_init.
> Could you please check whether this patch is helpful?

If this does solve the problem it would be:
Fixes: 8fbdccd2b173 ("riscv: mm: Support kasan for sv57")
right?

Thanks,
Conor.

> 
> When doing kasan_populate, the new allocated base_pud/base_p4d should
> contain kasan_early_shadow_{pud, p4d}'s content. Add the missing memcpy
> to avoid page fault when read/write kasan shadow region.
> 
> Tested on:
>  - qemu with sv57 and CONFIG_KASAN on.
>  - qemu with sv48 and CONFIG_KASAN on.
> 
> Signed-off-by: Qinglin Pan <panqinglin2020@iscas.ac.cn>
> ---
>  arch/riscv/mm/kasan_init.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
> index a22e418dbd82..e1226709490f 100644
> --- a/arch/riscv/mm/kasan_init.c
> +++ b/arch/riscv/mm/kasan_init.c
> @@ -113,6 +113,8 @@ static void __init kasan_populate_pud(pgd_t *pgd,
>  		base_pud = pt_ops.get_pud_virt(pfn_to_phys(_pgd_pfn(*pgd)));
>  	} else if (pgd_none(*pgd)) {
>  		base_pud = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
> +		memcpy(base_pud, (void *)kasan_early_shadow_pud,
> +			sizeof(pud_t) * PTRS_PER_PUD);
>  	} else {
>  		base_pud = (pud_t *)pgd_page_vaddr(*pgd);
>  		if (base_pud == lm_alias(kasan_early_shadow_pud)) {
> @@ -173,8 +175,11 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
>  		base_p4d = pt_ops.get_p4d_virt(pfn_to_phys(_pgd_pfn(*pgd)));
>  	} else {
>  		base_p4d = (p4d_t *)pgd_page_vaddr(*pgd);
> -		if (base_p4d == lm_alias(kasan_early_shadow_p4d))
> +		if (base_p4d == lm_alias(kasan_early_shadow_p4d)) {
>  			base_p4d = memblock_alloc(PTRS_PER_PUD * sizeof(p4d_t), PAGE_SIZE);
> +			memcpy(base_p4d, (void *)kasan_early_shadow_p4d,
> +				sizeof(p4d_t) * PTRS_PER_P4D);
> +		}
>  	}
>  
>  	p4dp = base_p4d + p4d_index(vaddr);
> -- 
> 2.35.1
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v1 1/1] riscv: mm: add missing memcpy in kasan_init

[Qinglin Pan]

On 10/9/22 7:30 PM, Conor Dooley wrote:
> On Sun, Oct 09, 2022 at 04:30:50PM +0800, panqinglin2020@iscas.ac.cn wrote:
>> From: Qinglin Pan <panqinglin2020@iscas.ac.cn>
>>
>> Hi Atish,
>>
>> It seems that the panic is due to the missing memcpy during kasan_init.
>> Could you please check whether this patch is helpful?
> 
> If this does solve the problem it would be:
> Fixes: 8fbdccd2b173 ("riscv: mm: Support kasan for sv57")
> right?
> 
> Thanks,
> Conor.
> 

Hi Conor,

Thanks a lot for notification!
I have change the title and resend it.

Thanks,
Qinglin.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v1 1/1] riscv: mm: add missing memcpy in kasan_init

[Conor Dooley]

On Sun, Oct 09, 2022 at 09:25:31PM +0800, Qinglin Pan wrote:
> On 10/9/22 7:30 PM, Conor Dooley wrote:
> > On Sun, Oct 09, 2022 at 04:30:50PM +0800, panqinglin2020@iscas.ac.cn wrote:
> > > From: Qinglin Pan <panqinglin2020@iscas.ac.cn>
> > > 
> > > Hi Atish,
> > > 
> > > It seems that the panic is due to the missing memcpy during kasan_init.
> > > Could you please check whether this patch is helpful?
> > 
> > If this does solve the problem it would be:
> > Fixes: 8fbdccd2b173 ("riscv: mm: Support kasan for sv57")
> > right?
> > 
> > Thanks,
> > Conor.
> > 
> 
> Hi Conor,
> 
> Thanks a lot for notification!
> I have change the title and resend it.

Unfortunately I was not suggesting a new title for the patch.. A
"Fixes:" tag goes as part of the sign off block to show what commit a
given patch fixes. Your original title looks fine to me.

Thanks,
Conor.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v1 1/1] riscv: mm: add missing memcpy in kasan_init

[Atish Patra]

On Sun, Oct 9, 2022 at 1:31 AM <panqinglin2020@iscas.ac.cn> wrote:
>
> From: Qinglin Pan <panqinglin2020@iscas.ac.cn>
>
> Hi Atish,
>
> It seems that the panic is due to the missing memcpy during kasan_init.
> Could you please check whether this patch is helpful?
>
> When doing kasan_populate, the new allocated base_pud/base_p4d should
> contain kasan_early_shadow_{pud, p4d}'s content. Add the missing memcpy
> to avoid page fault when read/write kasan shadow region.
>
> Tested on:
>  - qemu with sv57 and CONFIG_KASAN on.
>  - qemu with sv48 and CONFIG_KASAN on.
>
> Signed-off-by: Qinglin Pan <panqinglin2020@iscas.ac.cn>
> ---
>  arch/riscv/mm/kasan_init.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
> index a22e418dbd82..e1226709490f 100644
> --- a/arch/riscv/mm/kasan_init.c
> +++ b/arch/riscv/mm/kasan_init.c
> @@ -113,6 +113,8 @@ static void __init kasan_populate_pud(pgd_t *pgd,
>                 base_pud = pt_ops.get_pud_virt(pfn_to_phys(_pgd_pfn(*pgd)));
>         } else if (pgd_none(*pgd)) {
>                 base_pud = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
> +               memcpy(base_pud, (void *)kasan_early_shadow_pud,
> +                       sizeof(pud_t) * PTRS_PER_PUD);
>         } else {
>                 base_pud = (pud_t *)pgd_page_vaddr(*pgd);
>                 if (base_pud == lm_alias(kasan_early_shadow_pud)) {
> @@ -173,8 +175,11 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
>                 base_p4d = pt_ops.get_p4d_virt(pfn_to_phys(_pgd_pfn(*pgd)));
>         } else {
>                 base_p4d = (p4d_t *)pgd_page_vaddr(*pgd);
> -               if (base_p4d == lm_alias(kasan_early_shadow_p4d))
> +               if (base_p4d == lm_alias(kasan_early_shadow_p4d)) {
>                         base_p4d = memblock_alloc(PTRS_PER_PUD * sizeof(p4d_t), PAGE_SIZE);
> +                       memcpy(base_p4d, (void *)kasan_early_shadow_p4d,
> +                               sizeof(p4d_t) * PTRS_PER_P4D);
> +               }
>         }
>
>         p4dp = base_p4d + p4d_index(vaddr);
> --
> 2.35.1
>

Yes. This patch fixes the boot issue for me with Kasan enabled on v6.0.

Tested-by: Atish Patra <atishp@rivosinc.com>

Thanks for the patch. Few nit comments:

You can drop the message addressed to me in the commit text.
Usually, that should be after the last sign off between two  "---"

As conor suggested, there should be a Fixes tag[1] in the commit text.

[1] https://www.kernel.org/doc/html/v4.10/process/submitting-patches.html#:~:text=A%20Fixes%3A%20tag%20indicates%20that,versions%20should%20receive%20your%20fix.
-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v1 1/1] riscv: mm: add missing memcpy in kasan_init

[Palmer Dabbelt]

On Sun, 09 Oct 2022 23:49:36 PDT (-0700), atishp@atishpatra.org wrote:
> On Sun, Oct 9, 2022 at 1:31 AM <panqinglin2020@iscas.ac.cn> wrote:
>>
>> From: Qinglin Pan <panqinglin2020@iscas.ac.cn>
>>
>> Hi Atish,
>>
>> It seems that the panic is due to the missing memcpy during kasan_init.
>> Could you please check whether this patch is helpful?
>>
>> When doing kasan_populate, the new allocated base_pud/base_p4d should
>> contain kasan_early_shadow_{pud, p4d}'s content. Add the missing memcpy
>> to avoid page fault when read/write kasan shadow region.
>>
>> Tested on:
>>  - qemu with sv57 and CONFIG_KASAN on.
>>  - qemu with sv48 and CONFIG_KASAN on.
>>
>> Signed-off-by: Qinglin Pan <panqinglin2020@iscas.ac.cn>
>> ---
>>  arch/riscv/mm/kasan_init.c | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
>> index a22e418dbd82..e1226709490f 100644
>> --- a/arch/riscv/mm/kasan_init.c
>> +++ b/arch/riscv/mm/kasan_init.c
>> @@ -113,6 +113,8 @@ static void __init kasan_populate_pud(pgd_t *pgd,
>>                 base_pud = pt_ops.get_pud_virt(pfn_to_phys(_pgd_pfn(*pgd)));
>>         } else if (pgd_none(*pgd)) {
>>                 base_pud = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
>> +               memcpy(base_pud, (void *)kasan_early_shadow_pud,
>> +                       sizeof(pud_t) * PTRS_PER_PUD);
>>         } else {
>>                 base_pud = (pud_t *)pgd_page_vaddr(*pgd);
>>                 if (base_pud == lm_alias(kasan_early_shadow_pud)) {
>> @@ -173,8 +175,11 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
>>                 base_p4d = pt_ops.get_p4d_virt(pfn_to_phys(_pgd_pfn(*pgd)));
>>         } else {
>>                 base_p4d = (p4d_t *)pgd_page_vaddr(*pgd);
>> -               if (base_p4d == lm_alias(kasan_early_shadow_p4d))
>> +               if (base_p4d == lm_alias(kasan_early_shadow_p4d)) {
>>                         base_p4d = memblock_alloc(PTRS_PER_PUD * sizeof(p4d_t), PAGE_SIZE);
>> +                       memcpy(base_p4d, (void *)kasan_early_shadow_p4d,
>> +                               sizeof(p4d_t) * PTRS_PER_P4D);
>> +               }
>>         }
>>
>>         p4dp = base_p4d + p4d_index(vaddr);
>> --
>> 2.35.1
>>
>
> Yes. This patch fixes the boot issue for me with Kasan enabled on v6.0.
>
> Tested-by: Atish Patra <atishp@rivosinc.com>
>
> Thanks for the patch. Few nit comments:
>
> You can drop the message addressed to me in the commit text.
> Usually, that should be after the last sign off between two  "---"
>
> As conor suggested, there should be a Fixes tag[1] in the commit text.
>
> [1] https://www.kernel.org/doc/html/v4.10/process/submitting-patches.html#:~:text=A%20Fixes%3A%20tag%20indicates%20that,versions%20should%20receive%20your%20fix.

I've got this on not-for-next in a cleaned up state, so no reason to 
resend just for these.  It also fixes my boot issues, but it's not quite 
passing the smell test right now.  I've looked at this a few times and 
every time I do I manage to convince myself that there's a bunch of 
issues in these kasan initialization routines, but my attempts to clean 
them up just result in more breakages.  So I think there's something I 
don't quite get about this yet.

I'll try and find some time this weekend to dig into this further, 
hopefully it's just all the merge window interrupts that are preventing 
me from getting anywhere.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v1 1/1] riscv: mm: add missing memcpy in kasan_init

[Palmer Dabbelt]

On Sun, 9 Oct 2022 16:30:50 +0800, panqinglin2020@iscas.ac.cn wrote:
> From: Qinglin Pan <panqinglin2020@iscas.ac.cn>
> 
> Hi Atish,
> 
> It seems that the panic is due to the missing memcpy during kasan_init.
> Could you please check whether this patch is helpful?
> 
> [...]

Applied, thanks!

[1/1] riscv: mm: add missing memcpy in kasan_init
      https://git.kernel.org/palmer/c/9f2ac64d6ca6

Best regards,
-- 
Palmer Dabbelt <palmer@rivosinc.com>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v1 1/1] Fixes: 8fbdccd2b173 ("riscv: mm: Support kasan for sv57")

[panqinglin2020]

From: Qinglin Pan <panqinglin2020@iscas.ac.cn>

When doing kasan_populate, the new allocated base_pud/base_p4d should
contain kasan_early_shadow_{pud, p4d}'s content. Add the missing memcpy
to avoid page fault when read/write kasan shadow region.

Tested on:
 - qemu with sv57 and CONFIG_KASAN on.
 - qemu with sv48 and CONFIG_KASAN on.

Signed-off-by: Qinglin Pan <panqinglin2020@iscas.ac.cn>
---
 arch/riscv/mm/kasan_init.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index a22e418dbd82..e1226709490f 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -113,6 +113,8 @@ static void __init kasan_populate_pud(pgd_t *pgd,
 		base_pud = pt_ops.get_pud_virt(pfn_to_phys(_pgd_pfn(*pgd)));
 	} else if (pgd_none(*pgd)) {
 		base_pud = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
+		memcpy(base_pud, (void *)kasan_early_shadow_pud,
+			sizeof(pud_t) * PTRS_PER_PUD);
 	} else {
 		base_pud = (pud_t *)pgd_page_vaddr(*pgd);
 		if (base_pud == lm_alias(kasan_early_shadow_pud)) {
@@ -173,8 +175,11 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
 		base_p4d = pt_ops.get_p4d_virt(pfn_to_phys(_pgd_pfn(*pgd)));
 	} else {
 		base_p4d = (p4d_t *)pgd_page_vaddr(*pgd);
-		if (base_p4d == lm_alias(kasan_early_shadow_p4d))
+		if (base_p4d == lm_alias(kasan_early_shadow_p4d)) {
 			base_p4d = memblock_alloc(PTRS_PER_PUD * sizeof(p4d_t), PAGE_SIZE);
+			memcpy(base_p4d, (void *)kasan_early_shadow_p4d,
+				sizeof(p4d_t) * PTRS_PER_P4D);
+		}
 	}
 
 	p4dp = base_p4d + p4d_index(vaddr);
-- 
2.35.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv