linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] MIPS: Bounds check virt_addr_valid
@ 2019-05-28 17:05 Paul Burton
  2019-05-28 17:05 ` [PATCH 2/2] MIPS: Make virt_addr_valid() return bool Paul Burton
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: Paul Burton @ 2019-05-28 17:05 UTC (permalink / raw)
  To: linux-mips; +Cc: Paul Burton, Julien Cristau, Yunqiang Su, stable

The virt_addr_valid() function is meant to return true iff
virt_to_page() will return a valid struct page reference. This is true
iff the address provided is found within the unmapped address range
between PAGE_OFFSET & MAP_BASE, but we don't currently check for that
condition. Instead we simply mask the address to obtain what will be a
physical address if the virtual address is indeed in the desired range,
shift it to form a PFN & then call pfn_valid(). This can incorrectly
return true if called with a virtual address which, after masking,
happens to form a physical address corresponding to a valid PFN.

For example we may vmalloc an address in the kernel mapped region
starting a MAP_BASE & obtain the virtual address:

  addr = 0xc000000000002000

When masked by virt_to_phys(), which uses __pa() & in turn CPHYSADDR(),
we obtain the following (bogus) physical address:

  addr = 0x2000

In a common system with PHYS_OFFSET=0 this will correspond to a valid
struct page which should really be accessed by virtual address
PAGE_OFFSET+0x2000, causing virt_addr_valid() to incorrectly return 1
indicating that the original address corresponds to a struct page.

This is equivalent to the ARM64 change made in commit ca219452c6b8
("arm64: Correctly bounds check virt_addr_valid").

This fixes fallout when hardened usercopy is enabled caused by the
related commit 517e1fbeb65f ("mm/usercopy: Drop extra
is_vmalloc_or_module() check") which removed a check for the vmalloc
range that was present from the introduction of the hardened usercopy
feature.

Signed-off-by: Paul Burton <paul.burton@mips.com>
References: ca219452c6b8 ("arm64: Correctly bounds check virt_addr_valid")
References: 517e1fbeb65f ("mm/usercopy: Drop extra is_vmalloc_or_module() check")
Reported-by: Julien Cristau <jcristau@debian.org>
Tested-by: YunQiang Su <ysu@wavecomp.com>
URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929366
Cc: stable@vger.kernel.org # v4.12+
---

 arch/mips/mm/mmap.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index 2f616ebeb7e0..7755a1fad05a 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -203,6 +203,11 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 
 int __virt_addr_valid(const volatile void *kaddr)
 {
+	unsigned long vaddr = (unsigned long)vaddr;
+
+	if ((vaddr < PAGE_OFFSET) || (vaddr >= MAP_BASE))
+		return 0;
+
 	return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
 }
 EXPORT_SYMBOL_GPL(__virt_addr_valid);
-- 
2.21.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 2/2] MIPS: Make virt_addr_valid() return bool
  2019-05-28 17:05 [PATCH 1/2] MIPS: Bounds check virt_addr_valid Paul Burton
@ 2019-05-28 17:05 ` Paul Burton
  2019-05-29 12:39   ` Philippe Mathieu-Daudé
  2019-05-29 12:39 ` [PATCH 1/2] MIPS: Bounds check virt_addr_valid Philippe Mathieu-Daudé
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 8+ messages in thread
From: Paul Burton @ 2019-05-28 17:05 UTC (permalink / raw)
  To: linux-mips; +Cc: Paul Burton

virt_addr_valid() really returns a boolean value, but currently uses an
integer to represent it. Switch to the bool type to make it clearer that
we really are returning a true or false value.

Signed-off-by: Paul Burton <paul.burton@mips.com>
---

 arch/mips/include/asm/page.h | 2 +-
 arch/mips/mm/mmap.c          | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index 6b31c93b5eaa..a25643d258cb 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -249,7 +249,7 @@ static inline int pfn_valid(unsigned long pfn)
 #define virt_to_pfn(kaddr)   	PFN_DOWN(virt_to_phys((void *)(kaddr)))
 #define virt_to_page(kaddr)	pfn_to_page(virt_to_pfn(kaddr))
 
-extern int __virt_addr_valid(const volatile void *kaddr);
+extern bool __virt_addr_valid(const volatile void *kaddr);
 #define virt_addr_valid(kaddr)						\
 	__virt_addr_valid((const volatile void *) (kaddr))
 
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index 7755a1fad05a..50ee7213b432 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -201,12 +201,12 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 	return ret;
 }
 
-int __virt_addr_valid(const volatile void *kaddr)
+bool __virt_addr_valid(const volatile void *kaddr)
 {
 	unsigned long vaddr = (unsigned long)vaddr;
 
 	if ((vaddr < PAGE_OFFSET) || (vaddr >= MAP_BASE))
-		return 0;
+		return false;
 
 	return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
 }
-- 
2.21.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] MIPS: Bounds check virt_addr_valid
  2019-05-28 17:05 [PATCH 1/2] MIPS: Bounds check virt_addr_valid Paul Burton
  2019-05-28 17:05 ` [PATCH 2/2] MIPS: Make virt_addr_valid() return bool Paul Burton
@ 2019-05-29 12:39 ` Philippe Mathieu-Daudé
  2019-05-29 20:35 ` Paul Burton
  2019-06-10 23:41 ` Hauke Mehrtens
  3 siblings, 0 replies; 8+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-05-29 12:39 UTC (permalink / raw)
  To: Paul Burton, linux-mips; +Cc: Paul Burton, Julien Cristau, Yunqiang Su, stable

On 5/28/19 7:05 PM, Paul Burton wrote:
> The virt_addr_valid() function is meant to return true iff
> virt_to_page() will return a valid struct page reference. This is true
> iff the address provided is found within the unmapped address range
> between PAGE_OFFSET & MAP_BASE, but we don't currently check for that
> condition. Instead we simply mask the address to obtain what will be a
> physical address if the virtual address is indeed in the desired range,
> shift it to form a PFN & then call pfn_valid(). This can incorrectly
> return true if called with a virtual address which, after masking,
> happens to form a physical address corresponding to a valid PFN.
> 
> For example we may vmalloc an address in the kernel mapped region
> starting a MAP_BASE & obtain the virtual address:
> 
>   addr = 0xc000000000002000
> 
> When masked by virt_to_phys(), which uses __pa() & in turn CPHYSADDR(),
> we obtain the following (bogus) physical address:
> 
>   addr = 0x2000
> 
> In a common system with PHYS_OFFSET=0 this will correspond to a valid
> struct page which should really be accessed by virtual address
> PAGE_OFFSET+0x2000, causing virt_addr_valid() to incorrectly return 1
> indicating that the original address corresponds to a struct page.
> 
> This is equivalent to the ARM64 change made in commit ca219452c6b8
> ("arm64: Correctly bounds check virt_addr_valid").
> 
> This fixes fallout when hardened usercopy is enabled caused by the
> related commit 517e1fbeb65f ("mm/usercopy: Drop extra
> is_vmalloc_or_module() check") which removed a check for the vmalloc
> range that was present from the introduction of the hardened usercopy
> feature.
> 
> Signed-off-by: Paul Burton <paul.burton@mips.com>
> References: ca219452c6b8 ("arm64: Correctly bounds check virt_addr_valid")
> References: 517e1fbeb65f ("mm/usercopy: Drop extra is_vmalloc_or_module() check")
> Reported-by: Julien Cristau <jcristau@debian.org>
> Tested-by: YunQiang Su <ysu@wavecomp.com>

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

> URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929366
> Cc: stable@vger.kernel.org # v4.12+
> ---
> 
>  arch/mips/mm/mmap.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
> index 2f616ebeb7e0..7755a1fad05a 100644
> --- a/arch/mips/mm/mmap.c
> +++ b/arch/mips/mm/mmap.c
> @@ -203,6 +203,11 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
>  
>  int __virt_addr_valid(const volatile void *kaddr)
>  {
> +	unsigned long vaddr = (unsigned long)vaddr;
> +
> +	if ((vaddr < PAGE_OFFSET) || (vaddr >= MAP_BASE))
> +		return 0;
> +
>  	return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
>  }
>  EXPORT_SYMBOL_GPL(__virt_addr_valid);
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] MIPS: Make virt_addr_valid() return bool
  2019-05-28 17:05 ` [PATCH 2/2] MIPS: Make virt_addr_valid() return bool Paul Burton
@ 2019-05-29 12:39   ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 8+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-05-29 12:39 UTC (permalink / raw)
  To: Paul Burton, linux-mips; +Cc: Paul Burton

On 5/28/19 7:05 PM, Paul Burton wrote:
> virt_addr_valid() really returns a boolean value, but currently uses an
> integer to represent it. Switch to the bool type to make it clearer that
> we really are returning a true or false value.
> 
> Signed-off-by: Paul Burton <paul.burton@mips.com>

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

> ---
> 
>  arch/mips/include/asm/page.h | 2 +-
>  arch/mips/mm/mmap.c          | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
> index 6b31c93b5eaa..a25643d258cb 100644
> --- a/arch/mips/include/asm/page.h
> +++ b/arch/mips/include/asm/page.h
> @@ -249,7 +249,7 @@ static inline int pfn_valid(unsigned long pfn)
>  #define virt_to_pfn(kaddr)   	PFN_DOWN(virt_to_phys((void *)(kaddr)))
>  #define virt_to_page(kaddr)	pfn_to_page(virt_to_pfn(kaddr))
>  
> -extern int __virt_addr_valid(const volatile void *kaddr);
> +extern bool __virt_addr_valid(const volatile void *kaddr);
>  #define virt_addr_valid(kaddr)						\
>  	__virt_addr_valid((const volatile void *) (kaddr))
>  
> diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
> index 7755a1fad05a..50ee7213b432 100644
> --- a/arch/mips/mm/mmap.c
> +++ b/arch/mips/mm/mmap.c
> @@ -201,12 +201,12 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
>  	return ret;
>  }
>  
> -int __virt_addr_valid(const volatile void *kaddr)
> +bool __virt_addr_valid(const volatile void *kaddr)
>  {
>  	unsigned long vaddr = (unsigned long)vaddr;
>  
>  	if ((vaddr < PAGE_OFFSET) || (vaddr >= MAP_BASE))
> -		return 0;
> +		return false;
>  
>  	return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
>  }
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] MIPS: Bounds check virt_addr_valid
  2019-05-28 17:05 [PATCH 1/2] MIPS: Bounds check virt_addr_valid Paul Burton
  2019-05-28 17:05 ` [PATCH 2/2] MIPS: Make virt_addr_valid() return bool Paul Burton
  2019-05-29 12:39 ` [PATCH 1/2] MIPS: Bounds check virt_addr_valid Philippe Mathieu-Daudé
@ 2019-05-29 20:35 ` Paul Burton
  2019-06-10 23:41 ` Hauke Mehrtens
  3 siblings, 0 replies; 8+ messages in thread
From: Paul Burton @ 2019-05-29 20:35 UTC (permalink / raw)
  To: Paul Burton
  Cc: linux-mips, Paul Burton, Julien Cristau, Yunqiang Su, stable, linux-mips

Hello,

Paul Burton wrote:
> The virt_addr_valid() function is meant to return true iff
> virt_to_page() will return a valid struct page reference. This is true
> iff the address provided is found within the unmapped address range
> between PAGE_OFFSET & MAP_BASE, but we don't currently check for that
> condition. Instead we simply mask the address to obtain what will be a
> physical address if the virtual address is indeed in the desired range,
> shift it to form a PFN & then call pfn_valid(). This can incorrectly
> return true if called with a virtual address which, after masking,
> happens to form a physical address corresponding to a valid PFN.
> 
> For example we may vmalloc an address in the kernel mapped region
> starting a MAP_BASE & obtain the virtual address:
> 
> addr = 0xc000000000002000
> 
> When masked by virt_to_phys(), which uses __pa() & in turn CPHYSADDR(),
> we obtain the following (bogus) physical address:
> 
> addr = 0x2000
> 
> In a common system with PHYS_OFFSET=0 this will correspond to a valid
> struct page which should really be accessed by virtual address
> PAGE_OFFSET+0x2000, causing virt_addr_valid() to incorrectly return 1
> indicating that the original address corresponds to a struct page.
> 
> This is equivalent to the ARM64 change made in commit ca219452c6b8
> ("arm64: Correctly bounds check virt_addr_valid").
> 
> This fixes fallout when hardened usercopy is enabled caused by the
> related commit 517e1fbeb65f ("mm/usercopy: Drop extra
> is_vmalloc_or_module() check") which removed a check for the vmalloc
> range that was present from the introduction of the hardened usercopy
> feature.
> 
> Signed-off-by: Paul Burton <paul.burton@mips.com>
> References: ca219452c6b8 ("arm64: Correctly bounds check virt_addr_valid")
> References: 517e1fbeb65f ("mm/usercopy: Drop extra is_vmalloc_or_module() check")
> Reported-by: Julien Cristau <jcristau@debian.org>
> Tested-by: YunQiang Su <ysu@wavecomp.com>
> URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929366
> Cc: stable@vger.kernel.org # v4.12+
> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Series applied to mips-fixes.

Thanks,
    Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.burton@mips.com to report it. ]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] MIPS: Bounds check virt_addr_valid
  2019-05-28 17:05 [PATCH 1/2] MIPS: Bounds check virt_addr_valid Paul Burton
                   ` (2 preceding siblings ...)
  2019-05-29 20:35 ` Paul Burton
@ 2019-06-10 23:41 ` Hauke Mehrtens
  2019-06-11  8:19   ` Thomas Bogendoerfer
  3 siblings, 1 reply; 8+ messages in thread
From: Hauke Mehrtens @ 2019-06-10 23:41 UTC (permalink / raw)
  To: Paul Burton, linux-mips; +Cc: Paul Burton, Julien Cristau, Yunqiang Su, stable

On 5/28/19 7:05 PM, Paul Burton wrote:
> The virt_addr_valid() function is meant to return true iff
> virt_to_page() will return a valid struct page reference. This is true
> iff the address provided is found within the unmapped address range
> between PAGE_OFFSET & MAP_BASE, but we don't currently check for that
> condition. Instead we simply mask the address to obtain what will be a
> physical address if the virtual address is indeed in the desired range,
> shift it to form a PFN & then call pfn_valid(). This can incorrectly
> return true if called with a virtual address which, after masking,
> happens to form a physical address corresponding to a valid PFN.
> 
> For example we may vmalloc an address in the kernel mapped region
> starting a MAP_BASE & obtain the virtual address:
> 
>   addr = 0xc000000000002000
> 
> When masked by virt_to_phys(), which uses __pa() & in turn CPHYSADDR(),
> we obtain the following (bogus) physical address:
> 
>   addr = 0x2000
> 
> In a common system with PHYS_OFFSET=0 this will correspond to a valid
> struct page which should really be accessed by virtual address
> PAGE_OFFSET+0x2000, causing virt_addr_valid() to incorrectly return 1
> indicating that the original address corresponds to a struct page.
> 
> This is equivalent to the ARM64 change made in commit ca219452c6b8
> ("arm64: Correctly bounds check virt_addr_valid").
> 
> This fixes fallout when hardened usercopy is enabled caused by the
> related commit 517e1fbeb65f ("mm/usercopy: Drop extra
> is_vmalloc_or_module() check") which removed a check for the vmalloc
> range that was present from the introduction of the hardened usercopy
> feature.
> 
> Signed-off-by: Paul Burton <paul.burton@mips.com>
> References: ca219452c6b8 ("arm64: Correctly bounds check virt_addr_valid")
> References: 517e1fbeb65f ("mm/usercopy: Drop extra is_vmalloc_or_module() check")
> Reported-by: Julien Cristau <jcristau@debian.org>
> Tested-by: YunQiang Su <ysu@wavecomp.com>
> URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929366
> Cc: stable@vger.kernel.org # v4.12+
> ---
> 
>  arch/mips/mm/mmap.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
> index 2f616ebeb7e0..7755a1fad05a 100644
> --- a/arch/mips/mm/mmap.c
> +++ b/arch/mips/mm/mmap.c
> @@ -203,6 +203,11 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
>  
>  int __virt_addr_valid(const volatile void *kaddr)
>  {
> +	unsigned long vaddr = (unsigned long)vaddr;
> +
> +	if ((vaddr < PAGE_OFFSET) || (vaddr >= MAP_BASE))
> +		return 0;
> +
>  	return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
>  }
>  EXPORT_SYMBOL_GPL(__virt_addr_valid);
> 

Hi Paul,

Someone complained that this compiled to a constant "return 0" for him:
https://bugs.openwrt.org/index.php?do=details&task_id=2305#comment6554

I just checked this on a unmodified 5.2-rc4 with the xway_defconfig and
I get this:

0001915c <__virt_addr_valid>:
   1915c:       03e00008        jr      ra
   19160:       00001025        move    v0,zero

Is this intended?

Hauke

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] MIPS: Bounds check virt_addr_valid
  2019-06-10 23:41 ` Hauke Mehrtens
@ 2019-06-11  8:19   ` Thomas Bogendoerfer
  2019-06-11 22:43     ` Paul Burton
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Bogendoerfer @ 2019-06-11  8:19 UTC (permalink / raw)
  To: Hauke Mehrtens
  Cc: Paul Burton, linux-mips, Paul Burton, Julien Cristau,
	Yunqiang Su, stable

On Tue, Jun 11, 2019 at 01:41:21AM +0200, Hauke Mehrtens wrote:
> On 5/28/19 7:05 PM, Paul Burton wrote:
> > ---
> > 
> >  arch/mips/mm/mmap.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
> > index 2f616ebeb7e0..7755a1fad05a 100644
> > --- a/arch/mips/mm/mmap.c
> > +++ b/arch/mips/mm/mmap.c
> > @@ -203,6 +203,11 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
> >  
> >  int __virt_addr_valid(const volatile void *kaddr)
> >  {
> > +	unsigned long vaddr = (unsigned long)vaddr;

the second vaddr should be better kaddr

> > +
> > +	if ((vaddr < PAGE_OFFSET) || (vaddr >= MAP_BASE))
> > +		return 0;
> > +
> >  	return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
> >  }
> >  EXPORT_SYMBOL_GPL(__virt_addr_valid);
> > 
> 
> Someone complained that this compiled to a constant "return 0" for him:
> https://bugs.openwrt.org/index.php?do=details&task_id=2305#comment6554
> 
> I just checked this on a unmodified 5.2-rc4 with the xway_defconfig and
> I get this:
> 
> 0001915c <__virt_addr_valid>:
>    1915c:       03e00008        jr      ra
>    19160:       00001025        move    v0,zero
> 
> Is this intended?

I don't think so. Interesting what the compiler decides to do here.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] MIPS: Bounds check virt_addr_valid
  2019-06-11  8:19   ` Thomas Bogendoerfer
@ 2019-06-11 22:43     ` Paul Burton
  0 siblings, 0 replies; 8+ messages in thread
From: Paul Burton @ 2019-06-11 22:43 UTC (permalink / raw)
  To: Thomas Bogendoerfer
  Cc: Hauke Mehrtens, linux-mips, Paul Burton, Julien Cristau,
	Yunqiang Su, stable

Hi Hauke & Thomas,

On Tue, Jun 11, 2019 at 10:19:47AM +0200, Thomas Bogendoerfer wrote:
> On Tue, Jun 11, 2019 at 01:41:21AM +0200, Hauke Mehrtens wrote:
> > On 5/28/19 7:05 PM, Paul Burton wrote:
> > > diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
> > > index 2f616ebeb7e0..7755a1fad05a 100644
> > > --- a/arch/mips/mm/mmap.c
> > > +++ b/arch/mips/mm/mmap.c
> > > @@ -203,6 +203,11 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
> > >  
> > >  int __virt_addr_valid(const volatile void *kaddr)
> > >  {
> > > +	unsigned long vaddr = (unsigned long)vaddr;
> 
> the second vaddr should be better kaddr

D'oh..! Right you are...

Returning false all the time is enough to silence the hardened usercopy
warnings but clearly not the right behaviour.

> > Someone complained that this compiled to a constant "return 0" for him:
> > https://bugs.openwrt.org/index.php?do=details&task_id=2305#comment6554
> > 
> > I just checked this on a unmodified 5.2-rc4 with the xway_defconfig and
> > I get this:
> > 
> > 0001915c <__virt_addr_valid>:
> >    1915c:       03e00008        jr      ra
> >    19160:       00001025        move    v0,zero
> > 
> > Is this intended?
> 
> I don't think so. Interesting what the compiler decides to do here.

Yes, this is equivalent to using uninitialized_var() but I'm surprised
the code got discarded entirely...

Thanks,
    Paul

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-06-11 22:43 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-28 17:05 [PATCH 1/2] MIPS: Bounds check virt_addr_valid Paul Burton
2019-05-28 17:05 ` [PATCH 2/2] MIPS: Make virt_addr_valid() return bool Paul Burton
2019-05-29 12:39   ` Philippe Mathieu-Daudé
2019-05-29 12:39 ` [PATCH 1/2] MIPS: Bounds check virt_addr_valid Philippe Mathieu-Daudé
2019-05-29 20:35 ` Paul Burton
2019-06-10 23:41 ` Hauke Mehrtens
2019-06-11  8:19   ` Thomas Bogendoerfer
2019-06-11 22:43     ` Paul Burton

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).