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
next prev 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: linkBe 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.