From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
linuxppc-dev@lists.ozlabs.org
Cc: Michael Ellerman <mpe@ellerman.id.au>,
Madhavan Srinivasan <maddy@linux.ibm.com>
Subject: Re: [PATCH] powerpc: Use printk instead of WARN in change_memory_attr
Date: Tue, 27 Aug 2024 21:36:45 +0530 [thread overview]
Message-ID: <875xrmrluy.fsf@gmail.com> (raw)
In-Reply-To: <a09687b8-184c-40bf-bf5f-b9639dd6d136@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 27/08/2024 à 11:12, Ritesh Harjani (IBM) a écrit :
>> [Vous ne recevez pas souvent de courriers de ritesh.list@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Use pr_warn_once instead of WARN_ON_ONCE as discussed here [1]
>> for printing possible use of set_memory_* on linear map on Hash.
>>
>> [1]: https://lore.kernel.org/all/877cc2fpi2.fsf@mail.lhotse/#t
>>
>> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> ---
>> arch/powerpc/mm/pageattr.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
>> index ac22bf28086f..c8c2d664c6f3 100644
>> --- a/arch/powerpc/mm/pageattr.c
>> +++ b/arch/powerpc/mm/pageattr.c
>> @@ -94,8 +94,11 @@ int change_memory_attr(unsigned long addr, int numpages, long action)
>> if (!radix_enabled()) {
>> int region = get_region_id(addr);
>>
>> - if (WARN_ON_ONCE(region != VMALLOC_REGION_ID && region != IO_REGION_ID))
>> + if (region != VMALLOC_REGION_ID && region != IO_REGION_ID) {
>> + pr_warn_once("%s: possible use of set_memory_* on linear map on Hash from (%ps)\n",
>> + __func__, __builtin_return_address(0));
>
> Is it really only linear map ?
>
> What about "possible user of set_memory_* outside of vmalloc or io region.
"warning: possible user of set_memory_* outside of vmalloc and io region."
I am thinking of adding a word "warning" too. I can make above change and send v2.
>
> Maybe a show_stack() would also be worth it ?
IMO, since we have the caller, we need not pollute the dmesg with the
entire call stack. Besides I am not aware of dump_stack_once() style prints.
>
>
> But in principle I think it would be better to keep the WARN_ONCE until
> we can add __must_check to set_memory_xxx() functions to be sure all
> callers check the result, as mandated by
> https://github.com/KSPP/linux/issues/7
Fixing the callers to check the return value is something that need not
depend on this change no?
The intention of this change is to mainly remove the heavy WARN_ON_ONCE
from powerpc specific change_memory_attr() and convert to printk warn.
-ritesh
next prev parent reply other threads:[~2024-08-27 16:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 9:12 [PATCH] powerpc: Use printk instead of WARN in change_memory_attr Ritesh Harjani (IBM)
2024-08-27 14:41 ` Christophe Leroy
2024-08-27 16:06 ` Ritesh Harjani [this message]
2024-08-30 11:13 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875xrmrluy.fsf@gmail.com \
--to=ritesh.list@gmail.com \
--cc=christophe.leroy@csgroup.eu \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.