All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abhinav Singh <singhabhinav9051571833@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: brauner@kernel.org, surenb@google.com, mst@redhat.com,
	michael.christie@oracle.com, mathieu.desnoyers@efficios.com,
	mjguzik@gmail.com, npiggin@gmail.com, shakeelb@google.com,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [PATCH] Fixing warning of directly dereferencing __rcu tagged
Date: Thu, 26 Oct 2023 17:48:26 +0530	[thread overview]
Message-ID: <4c171399-87ac-4273-8b73-5d9b440656d2@gmail.com> (raw)
In-Reply-To: <20231025165002.64ab92e6d55d204b66e055f4@linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

On 10/26/23 05:20, Andrew Morton wrote:
> On Thu, 26 Oct 2023 04:57:42 +0530 Abhinav Singh <singhabhinav9051571833@gmail.com> wrote:
> 
>> On 10/26/23 04:08, Andrew Morton wrote:
>>>> +++ b/kernel/fork.c
>>>> @@ -2369,7 +2369,9 @@ __latent_entropy struct task_struct *copy_process(
>>>>    
>>>>    	retval = -EAGAIN;
>>>>    	if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
>>>> -		if (p->real_cred->user != INIT_USER &&
>>>> +		const struct cred *real_cred = rcu_dereference(p->real_cred);
>>>> +
>>>> +		if (real_cred && real_cred->user != INIT_USER &&
>>>>    		    !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
>>>>    			goto bad_fork_cleanup_count;
>>>
>>> The old code assumes that p->read_cred cannot be NULL and the new code
>>> does nothing to make it possible that `real_cred' can be NULL?
>>>
>>> In other words, I see no reason to add this new check for NULL?
>>
>> Thank you for the response!
>>
>> I thought it will be better to have check before accessing it, just so
>> we dont have any segmentation fault in future.
> 
> That would be adding code which has no effect?
> 
>> Also I just noticed there are two more places where direct dereferencing
>> of __rcu pointer is done in this same file. Should I do those changes in
>> this patch ?
> 
> I don't see why.  rcu_dereference(p) cannot return NULL if `p' is non-NULL?


[-- Attachment #2: 0001-Fixing-sparse-warning-cast-removes-address-space-__i.patch --]
[-- Type: text/x-patch, Size: 1298 bytes --]

From 598bf82b611a9af96c5d412855957e378523f529 Mon Sep 17 00:00:00 2001
From: Abhinav Singh <singhabhinav9051571833@gmail.com>
Date: Tue, 24 Oct 2023 15:24:52 +0530
Subject: [PATCH] Fixing warning cast removes address space '__iomem' of
 expression

This patch fixes sparse complaining about the removal of __iomem address
space when casting the return value of this function ioremap_cache(...)
from `void __ioremap*` to `void*`.

I think there are two way of fixing it, first one is changing the
datatype of variable `ghcb_va` from `void*` to `void __iomem*` . 
Second way of fixing it is using the memremap(...) which is 
done in this patch.

Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
---
 arch/x86/hyperv/hv_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 21556ad87f4b..c14161add274 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -70,7 +70,7 @@ static int hyperv_init_ghcb(void)
 
 	/* Mask out vTOM bit. ioremap_cache() maps decrypted */
 	ghcb_gpa &= ~ms_hyperv.shared_gpa_boundary;
-	ghcb_va = (void *)ioremap_cache(ghcb_gpa, HV_HYP_PAGE_SIZE);
+	ghcb_va = memremap(ghcb_gpa, HV_HYP_PAGE_SIZE, MEMREMAP_WB);
 	if (!ghcb_va)
 		return -ENOMEM;
 
-- 
2.39.2


WARNING: multiple messages have this Message-ID (diff)
From: Abhinav Singh <singhabhinav9051571833@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: brauner@kernel.org, mjguzik@gmail.com, mst@redhat.com,
	peterz@infradead.org,
	linux-kernel-mentees@lists.linuxfoundation.org,
	linux-kernel@vger.kernel.org, npiggin@gmail.com,
	mathieu.desnoyers@efficios.com, shakeelb@google.com,
	surenb@google.com, michael.christie@oracle.com
Subject: Re: [PATCH] Fixing warning of directly dereferencing __rcu tagged
Date: Thu, 26 Oct 2023 17:48:26 +0530	[thread overview]
Message-ID: <4c171399-87ac-4273-8b73-5d9b440656d2@gmail.com> (raw)
In-Reply-To: <20231025165002.64ab92e6d55d204b66e055f4@linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

On 10/26/23 05:20, Andrew Morton wrote:
> On Thu, 26 Oct 2023 04:57:42 +0530 Abhinav Singh <singhabhinav9051571833@gmail.com> wrote:
> 
>> On 10/26/23 04:08, Andrew Morton wrote:
>>>> +++ b/kernel/fork.c
>>>> @@ -2369,7 +2369,9 @@ __latent_entropy struct task_struct *copy_process(
>>>>    
>>>>    	retval = -EAGAIN;
>>>>    	if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
>>>> -		if (p->real_cred->user != INIT_USER &&
>>>> +		const struct cred *real_cred = rcu_dereference(p->real_cred);
>>>> +
>>>> +		if (real_cred && real_cred->user != INIT_USER &&
>>>>    		    !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
>>>>    			goto bad_fork_cleanup_count;
>>>
>>> The old code assumes that p->read_cred cannot be NULL and the new code
>>> does nothing to make it possible that `real_cred' can be NULL?
>>>
>>> In other words, I see no reason to add this new check for NULL?
>>
>> Thank you for the response!
>>
>> I thought it will be better to have check before accessing it, just so
>> we dont have any segmentation fault in future.
> 
> That would be adding code which has no effect?
> 
>> Also I just noticed there are two more places where direct dereferencing
>> of __rcu pointer is done in this same file. Should I do those changes in
>> this patch ?
> 
> I don't see why.  rcu_dereference(p) cannot return NULL if `p' is non-NULL?


[-- Attachment #2: 0001-Fixing-sparse-warning-cast-removes-address-space-__i.patch --]
[-- Type: text/x-patch, Size: 1298 bytes --]

From 598bf82b611a9af96c5d412855957e378523f529 Mon Sep 17 00:00:00 2001
From: Abhinav Singh <singhabhinav9051571833@gmail.com>
Date: Tue, 24 Oct 2023 15:24:52 +0530
Subject: [PATCH] Fixing warning cast removes address space '__iomem' of
 expression

This patch fixes sparse complaining about the removal of __iomem address
space when casting the return value of this function ioremap_cache(...)
from `void __ioremap*` to `void*`.

I think there are two way of fixing it, first one is changing the
datatype of variable `ghcb_va` from `void*` to `void __iomem*` . 
Second way of fixing it is using the memremap(...) which is 
done in this patch.

Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
---
 arch/x86/hyperv/hv_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 21556ad87f4b..c14161add274 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -70,7 +70,7 @@ static int hyperv_init_ghcb(void)
 
 	/* Mask out vTOM bit. ioremap_cache() maps decrypted */
 	ghcb_gpa &= ~ms_hyperv.shared_gpa_boundary;
-	ghcb_va = (void *)ioremap_cache(ghcb_gpa, HV_HYP_PAGE_SIZE);
+	ghcb_va = memremap(ghcb_gpa, HV_HYP_PAGE_SIZE, MEMREMAP_WB);
 	if (!ghcb_va)
 		return -ENOMEM;
 
-- 
2.39.2


[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

  parent reply	other threads:[~2023-10-26 12:18 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25 22:28 [PATCH] Fixing warning of directly dereferencing __rcu tagged Abhinav Singh
2023-10-25 22:28 ` Abhinav Singh
2023-10-25 22:38 ` Andrew Morton
2023-10-25 22:38   ` Andrew Morton
2023-10-25 23:27   ` Abhinav Singh
2023-10-25 23:27     ` Abhinav Singh
2023-10-25 23:50     ` Andrew Morton
2023-10-25 23:50       ` Andrew Morton
2023-10-26 12:16       ` [PATCH v2] Fixing directly deferencing a __rcu pointer warning Abhinav Singh
2023-10-26 12:16         ` Abhinav Singh
2023-10-26 13:14         ` Michael S. Tsirkin
2023-10-26 13:14           ` Michael S. Tsirkin
2023-10-26 14:06           ` Mateusz Guzik
2023-10-26 14:06             ` Mateusz Guzik
2023-10-26 14:51             ` Mathieu Desnoyers
2023-10-26 14:51               ` Mathieu Desnoyers
2023-10-26 15:07               ` Mateusz Guzik
2023-10-26 15:07                 ` Mateusz Guzik
2023-10-26 15:17             ` Michael S. Tsirkin
2023-10-26 15:17               ` Michael S. Tsirkin
2023-10-26 15:37               ` Abhinav Singh
2023-10-26 15:37                 ` Abhinav Singh
2023-10-26 15:47                 ` Michael S. Tsirkin
2023-10-26 15:47                   ` Michael S. Tsirkin
2023-10-27  6:37                   ` [PATCH v3] " Abhinav Singh
2023-10-27  6:37                     ` Abhinav Singh
2023-10-27  6:41                     ` Abhinav Singh
2023-10-27  6:41                       ` Abhinav Singh
2023-10-27  7:00                       ` Michael S. Tsirkin
2023-10-27  7:00                         ` Michael S. Tsirkin
2023-10-27  6:50                     ` Michael S. Tsirkin
2023-10-27  6:50                       ` Michael S. Tsirkin
2023-10-26 12:18       ` Abhinav Singh [this message]
2023-10-26 12:18         ` [PATCH] Fixing warning of directly dereferencing __rcu tagged Abhinav Singh
2023-10-26 12:27       ` [PATCH] Fixing directly deferencing a __rcu pointer warning Abhinav Singh
2023-10-26 12:27         ` Abhinav Singh
2023-10-26 15:03         ` Peter Zijlstra
2023-10-26 15:03           ` Peter Zijlstra
2023-10-27 12:22           ` Oleg Nesterov
2023-10-27 12:22             ` Oleg Nesterov
2023-10-28 10:22             ` [PATCH v3] " Abhinav Singh
2023-10-28 10:22               ` Abhinav Singh
2023-10-28 10:31               ` Abhinav Singh
2023-10-28 10:31                 ` Abhinav Singh
2023-10-28 12:20               ` Michael S. Tsirkin
2023-10-28 12:20                 ` Michael S. Tsirkin
2023-10-28 20:43                 ` Abhinav Singh
2023-10-28 20:43                   ` Abhinav Singh
2023-10-28 20:46                   ` Abhinav Singh
2023-10-28 20:46                     ` Abhinav Singh
2023-11-03  6:30                     ` kernel test robot
2023-11-03  6:30                       ` kernel test robot
2023-11-12 19:30                       ` [PATCH v4] " Abhinav Singh
2023-11-12 19:56                         ` Mathieu Desnoyers
2023-11-12 19:58                         ` Peter Zijlstra
2023-11-12 20:18                           ` Abhinav Singh

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=4c171399-87ac-4273-8b73-5d9b440656d2@gmail.com \
    --to=singhabhinav9051571833@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=michael.christie@oracle.com \
    --cc=mjguzik@gmail.com \
    --cc=mst@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=shakeelb@google.com \
    --cc=surenb@google.com \
    /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.