Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1312901 > unrolled thread

[PATCH v2] mm: make apply_to_page_range more robust

Started byMika Penttilä <mika.penttila@nextfour.com>
First post2016-01-20 07:00 +0100
Last post2016-01-21 06:20 +0100
Articles 3 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v2] mm: make apply_to_page_range more robust Mika Penttilä <mika.penttila@nextfour.com> - 2016-01-20 07:00 +0100
    Re: [PATCH v2] mm: make apply_to_page_range more robust David Rientjes <rientjes@google.com> - 2016-01-21 00:40 +0100
      Re: [PATCH v2] mm: make apply_to_page_range more robust Rusty Russell <rusty@rustcorp.com.au> - 2016-01-21 06:20 +0100

#1312901 — [PATCH v2] mm: make apply_to_page_range more robust

FromMika Penttilä <mika.penttila@nextfour.com>
Date2016-01-20 07:00 +0100
Subject[PATCH v2] mm: make apply_to_page_range more robust
Message-ID<qSTYe-28T-11@gated-at.bofh.it>
Recent changes (4.4.0+) in module loader triggered oops on ARM. 
    
can be 0 triggering the bug  BUG_ON(addr >= end);.

The call path is SyS_init_module()->set_memory_xx()->apply_to_page_range(),
and apply_to_page_range gets zero length resulting in triggering :
   
  BUG_ON(addr >= end)

This is a consequence of changes in module section handling (Rusty CC:ed).
This may be triggable only with certain modules and/or gcc versions. 

Plus, I think the spirit of the BUG_ON is to catch overflows,
not to bug on zero length legitimate callers. So whatever the
reason for this triggering, some day we have another caller with
zero length. 

Fix by letting call with zero size succeed. 

v2: add more explanation

Signed-off-by: Mika Penttilä mika.penttila@nextfour.com
Reviewed-by: Pekka Enberg <penberg@kernel.org>
---

diff --git a/mm/memory.c b/mm/memory.c
index c387430..c3d1a2e 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1884,6 +1884,9 @@ int apply_to_page_range(struct mm_struct *mm, unsigned long addr,
        unsigned long end = addr + size;
        int err;
 
+       if (!size)
+               return 0;
+
        BUG_ON(addr >= end);
        pgd = pgd_offset(mm, addr);
        do {

[toc] | [next] | [standalone]


#1313705

FromDavid Rientjes <rientjes@google.com>
Date2016-01-21 00:40 +0100
Message-ID<qTaw2-58k-19@gated-at.bofh.it>
In reply to#1312901

[Multipart message — attachments visible in raw view] — view raw

On Wed, 20 Jan 2016, Mika Penttilä wrote:

> Recent changes (4.4.0+) in module loader triggered oops on ARM. 
>     
> can be 0 triggering the bug  BUG_ON(addr >= end);.
> 
> The call path is SyS_init_module()->set_memory_xx()->apply_to_page_range(),
> and apply_to_page_range gets zero length resulting in triggering :
>    
>   BUG_ON(addr >= end)
> 
> This is a consequence of changes in module section handling (Rusty CC:ed).
> This may be triggable only with certain modules and/or gcc versions. 
> 

Well, what module are you loading to cause this crash?  Why would it be 
passing size == 0 to apply_to_page_range()?  Again, that sounds like a 
problem that we _want_ to know about since it is probably the result of 
buggy code and this patch would be covering it up.

Please elaborate on the problem that you are seeing, preferably with a 
stack trace of the BUG so we can fix the problem instead of papering over 
it.

[toc] | [prev] | [next] | [standalone]


#1313886

FromRusty Russell <rusty@rustcorp.com.au>
Date2016-01-21 06:20 +0100
Message-ID<qTfP5-x3-17@gated-at.bofh.it>
In reply to#1313705
David Rientjes <rientjes@google.com> writes:
> On Wed, 20 Jan 2016, Mika Penttilä wrote:
>
>> Recent changes (4.4.0+) in module loader triggered oops on ARM. 
>>     
>> can be 0 triggering the bug  BUG_ON(addr >= end);.
>> 
>> The call path is SyS_init_module()->set_memory_xx()->apply_to_page_range(),
>> and apply_to_page_range gets zero length resulting in triggering :
>>    
>>   BUG_ON(addr >= end)
>> 
>> This is a consequence of changes in module section handling (Rusty CC:ed).
>> This may be triggable only with certain modules and/or gcc versions. 
>> 
>
> Well, what module are you loading to cause this crash?  Why would it be 
> passing size == 0 to apply_to_page_range()?  Again, that sounds like a 
> problem that we _want_ to know about since it is probably the result of 
> buggy code and this patch would be covering it up.

Yes, I'm curious too.  It's certainly possible, since I expected a
zero-length range to do nothing, but let's make sure we're not papering
over some other screwup of mine.

Thanks,
Rusty.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web