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 <[email protected]>
---
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
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 <[email protected]>
> 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
>>
> >
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 <[email protected]>
>>> 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
>>>>
>>>>
> >
> On Jan 15, 2020, at 1:09 AM, Yang Shi <[email protected]> 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?
On 1/27/20 10:17 AM, Qian Cai wrote:
>
>> On Jan 15, 2020, at 1:09 AM, Yang Shi <[email protected]> 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.
> On Jan 27, 2020, at 2:57 PM, Yang Shi <[email protected]> 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.
On Mon, 27 Jan 2020 15:23:08 -0500 Qian Cai <[email protected]> wrote:
>
>
> > On Jan 27, 2020, at 2:57 PM, Yang Shi <[email protected]> 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.
> On Feb 14, 2020, at 12:26 AM, Andrew Morton <[email protected]> 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.