mm: mempolicy: use VM_BUG_ON_VMA in queue_pages_test_walk()
diff mbox series

Message ID 1579068565-110432-1-git-send-email-yang.shi@linux.alibaba.com
State New
Headers show
Series
  • mm: mempolicy: use VM_BUG_ON_VMA in queue_pages_test_walk()
Related show

Commit Message

Yang Shi Jan. 15, 2020, 6:09 a.m. UTC
The VM_BUG_ON() is already used by queue_pages_test_walk(), it sounds
better to dump more debug information by using VM_BUG_ON_VMA() to help
debugging.

Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
---
 mm/mempolicy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Li Xinhai Jan. 15, 2020, 12:08 p.m. UTC | #1
On 2020-01-15 at 14:09 Yang Shi wrote:
>The VM_BUG_ON() is already used by queue_pages_test_walk(), it sounds
>better to dump more debug information by using VM_BUG_ON_VMA() to help
>debugging.
>
>Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com> 

The .test_walk() is to be called from pagewalk with the rule that 'start'
and 'end' must within range of vma, in case the rule is broke, we detect
it. This is not quite relevant to a bug of particular vma. 

>---
> mm/mempolicy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>index 067cf7d..801d45d 100644
>--- a/mm/mempolicy.c
>+++ b/mm/mempolicy.c
>@@ -621,7 +621,7 @@ static int queue_pages_test_walk(unsigned long start, unsigned long end,
> unsigned long flags = qp->flags;
>
> /* range check first */
>-	VM_BUG_ON((vma->vm_start > start) || (vma->vm_end < end));
>+	VM_BUG_ON_VMA((vma->vm_start > start) || (vma->vm_end < end), vma);
>
> if (!qp->first) {
> qp->first = vma;
>--
>1.8.3.1
>
>
Yang Shi Jan. 15, 2020, 5:27 p.m. UTC | #2
On 1/15/20 4:08 AM, Li Xinhai wrote:
> On 2020-01-15 at 14:09 Yang Shi wrote:
>> The VM_BUG_ON() is already used by queue_pages_test_walk(), it sounds
>> better to dump more debug information by using VM_BUG_ON_VMA() to help
>> debugging.
>>
>> Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
> The .test_walk() is to be called from pagewalk with the rule that 'start'
> and 'end' must within range of vma, in case the rule is broke, we detect
> it. This is not quite relevant to a bug of particular vma.

But when you run into VMA range check failure, isn't it helpful to dump 
the VMA range information to ease debugging? And, VM_BUG_ON is already 
used in the code, I'm supposed the users may prefer more debug 
information dumped for debug kernel.

>
>> ---
>> mm/mempolicy.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>> index 067cf7d..801d45d 100644
>> --- a/mm/mempolicy.c
>> +++ b/mm/mempolicy.c
>> @@ -621,7 +621,7 @@ static int queue_pages_test_walk(unsigned long start, unsigned long end,
>> unsigned long flags = qp->flags;
>>
>> /* range check first */
>> -	VM_BUG_ON((vma->vm_start > start) || (vma->vm_end < end));
>> +	VM_BUG_ON_VMA((vma->vm_start > start) || (vma->vm_end < end), vma);
>>
>> if (!qp->first) {
>> qp->first = vma;
>> --
>> 1.8.3.1
>>
> >
Li Xinhai Jan. 16, 2020, 3:52 p.m. UTC | #3
On 2020-01-16 at 01:27 Yang Shi wrote:
>
>
>On 1/15/20 4:08 AM, Li Xinhai wrote:
>> On 2020-01-15 at 14:09 Yang Shi wrote:
>>> The VM_BUG_ON() is already used by queue_pages_test_walk(), it sounds
>>> better to dump more debug information by using VM_BUG_ON_VMA() to help
>>> debugging.
>>>
>>> Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
>> The .test_walk() is to be called from pagewalk with the rule that 'start'
>> and 'end' must within range of vma, in case the rule is broke, we detect
>> it. This is not quite relevant to a bug of particular vma.
>
>But when you run into VMA range check failure, isn't it helpful to dump
>the VMA range information to ease debugging? And, VM_BUG_ON is already
>used in the code, I'm supposed the users may prefer more debug
>information dumped for debug kernel.
> 
Got your point, it is already used better put more information.
>>
>>> ---
>>> mm/mempolicy.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>>> index 067cf7d..801d45d 100644
>>> --- a/mm/mempolicy.c
>>> +++ b/mm/mempolicy.c
>>> @@ -621,7 +621,7 @@ static int queue_pages_test_walk(unsigned long start, unsigned long end,
>>> unsigned long flags = qp->flags;
>>>
>>> /* range check first */
>>> -	VM_BUG_ON((vma->vm_start > start) || (vma->vm_end < end));
>>> +	VM_BUG_ON_VMA((vma->vm_start > start) || (vma->vm_end < end), vma);
>>>
>>> if (!qp->first) {
>>> qp->first = vma;
>>> --
>>> 1.8.3.1
>>>
>> >
>
Yang Shi Jan. 27, 2020, 4:59 p.m. UTC | #4
On 1/16/20 7:52 AM, Li Xinhai wrote:
> On 2020-01-16 at 01:27 Yang Shi wrote:
>>
>> On 1/15/20 4:08 AM, Li Xinhai wrote:
>>> On 2020-01-15 at 14:09 Yang Shi wrote:
>>>> The VM_BUG_ON() is already used by queue_pages_test_walk(), it sounds
>>>> better to dump more debug information by using VM_BUG_ON_VMA() to help
>>>> debugging.
>>>>
>>>> Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
>>> The .test_walk() is to be called from pagewalk with the rule that 'start'
>>> and 'end' must within range of vma, in case the rule is broke, we detect
>>> it. This is not quite relevant to a bug of particular vma.
>> But when you run into VMA range check failure, isn't it helpful to dump
>> the VMA range information to ease debugging? And, VM_BUG_ON is already
>> used in the code, I'm supposed the users may prefer more debug
>> information dumped for debug kernel.
>>
> Got your point, it is already used better put more information.

Hi Andrew,

Would you like to take this patch for v5.6 or v5.7? It looks Xinhai 
agrees with my point.

Thanks,
Yang

>>>> ---
>>>> mm/mempolicy.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>>>> index 067cf7d..801d45d 100644
>>>> --- a/mm/mempolicy.c
>>>> +++ b/mm/mempolicy.c
>>>> @@ -621,7 +621,7 @@ static int queue_pages_test_walk(unsigned long start, unsigned long end,
>>>> unsigned long flags = qp->flags;
>>>>
>>>> /* range check first */
>>>> -	VM_BUG_ON((vma->vm_start > start) || (vma->vm_end < end));
>>>> +	VM_BUG_ON_VMA((vma->vm_start > start) || (vma->vm_end < end), vma);
>>>>
>>>> if (!qp->first) {
>>>> qp->first = vma;
>>>> --
>>>> 1.8.3.1
>>>>
>>>>
> >
Qian Cai Jan. 27, 2020, 6:17 p.m. UTC | #5
> On Jan 15, 2020, at 1:09 AM, Yang Shi <yang.shi@linux.alibaba.com> wrote:
> 
> The VM_BUG_ON() is already used by queue_pages_test_walk(), it sounds
> better to dump more debug information by using VM_BUG_ON_VMA() to help
> debugging.

What’s the problem this is trying to resolve? Was there an existing bug would trigger this?
Yang Shi Jan. 27, 2020, 7:57 p.m. UTC | #6
On 1/27/20 10:17 AM, Qian Cai wrote:
>
>> On Jan 15, 2020, at 1:09 AM, Yang Shi <yang.shi@linux.alibaba.com> wrote:
>>
>> The VM_BUG_ON() is already used by queue_pages_test_walk(), it sounds
>> better to dump more debug information by using VM_BUG_ON_VMA() to help
>> debugging.
> What’s the problem this is trying to resolve? Was there an existing bug would trigger this?

Dumping more information to help debugging. I don't run into related bug 
personally.
Qian Cai Jan. 27, 2020, 8:23 p.m. UTC | #7
> On Jan 27, 2020, at 2:57 PM, Yang Shi <yang.shi@linux.alibaba.com> wrote:
> 
> Dumping more information to help debugging. I don't run into related bug personally.

This is a relatively weak justification for merging. If we are keeping accepting those mindless debugging patches, the workload will be unbearable for all.
Andrew Morton Feb. 14, 2020, 5:26 a.m. UTC | #8
On Mon, 27 Jan 2020 15:23:08 -0500 Qian Cai <cai@lca.pw> wrote:

> 
> 
> > On Jan 27, 2020, at 2:57 PM, Yang Shi <yang.shi@linux.alibaba.com> wrote:
> > 
> > Dumping more information to help debugging. I don't run into related bug personally.
> 
> This is a relatively weak justification for merging. If we are keeping accepting those mindless debugging patches, the workload will be unbearable for all.

I think it's OK.  If this ever triggers the kernel is dead, so the
volume of output isn't a problem.  And if it triggers, the more info
the better.
Qian Cai Feb. 14, 2020, 12:24 p.m. UTC | #9
> On Feb 14, 2020, at 12:26 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> I think it's OK.  If this ever triggers the kernel is dead, so the
> volume of output isn't a problem.  And if it triggers, the more info
> the better.

Well, I could think of millions of ways to just add more info for those theoretical assertion places where we will eventually be running out of review bandwidth if people start to “abuse” it. Anyway, if maintainers are willing to take risks on that path, I’ll not complain.

Patch
diff mbox series

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 067cf7d..801d45d 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -621,7 +621,7 @@  static int queue_pages_test_walk(unsigned long start, unsigned long end,
 	unsigned long flags = qp->flags;
 
 	/* range check first */
-	VM_BUG_ON((vma->vm_start > start) || (vma->vm_end < end));
+	VM_BUG_ON_VMA((vma->vm_start > start) || (vma->vm_end < end), vma);
 
 	if (!qp->first) {
 		qp->first = vma;